scn with smal office problem

[polaroid]

hi
built up a small community netwok between several small office
this way:
release 3.0.40
4 small office
2 ip 403
everithing works until i try to add a small office
the n everything break up as mix cfg
anyone know something about problems with this specific release in this specific situation?

 

[supertech2000]

Are your numbering plans different at all locations? (2XX, 3XX,4XX, etc.) Are all your hunt groups and names different?

 

[polaroid]

there's no duplicate ,the numbers are all complementary(small office A extension from 201 to 208,small office B 209 to 217).

 

[mtechsteve]

Thats the problem!!!!

you Can NOT have any duplicate Ext's or Groups!

Ta

Steve

 

[polaroid]

mtechsteve,i said there are no duplicate
every station has different numbers ,not as 300 ,400 ,500 and so on, but from 201 and on
site A until 208
site b from 209 and so ...

 

[cobragb]

Your dial plans must be completely different. How else would you differentiate SC's or routes between sites? With a SC of 2XX, it couldn't know the location.

 

[big70]

You don,t have to make route,s like 2xx if you are using SCN!!!

You can use 201 until 208 on site A and 209 until 216 at side B and 217 until 226 etc!!

Did you set it up as a star one main side with a ip-trunk to every side.
You can make a trunk to every side but will give at some point problems.

Als0 3.0 (40) is not a good version i shouldt try the next release that come out next week also have no complaints about 3.1(48) with SCN.

Greets Peter

 

[polaroid]

correct big70 ,i did set up a star one main side with a ip trunk to every side .
i suspected 3.0.40 is not a good version ,i'll upgrade ,just wonder if it's only an issue tied to the release version or anything else

 

[5thmsstech]

Also make sure you are not using a cfg from any of the other switches then modifying it. In other words dont pull up cfg from site a modify dial plan then save it to site b.

 

[JeSTeROCK]

Sounds like a big office problem

 

[mtechsteve]

What routers are you using?? (yes it sounds silly!) I would ALWAYS put each IPO on a compleatly different range... Check youur shortcodes... let me know how you get on

 

[CarGoSki]

I would still build specific shortcodes pointing to the specific IP trunks.

You can use Monitor to see where it breaks.

 

[polaroid]

all short codes are complementary,i mean each one has short code to dial to each ip line

 

[hibroth]

Do you still have the trouble Polaroid ?
If yes I could have the solution.

Let us know.

HB

 

[polaroid]

yes hibroth,i still have...

 

[BigNads]

Can i just clarify something here guys.

You can have users in the same number range as long as the numbers and names are totally unique on each site. Putting them in seperate number ranges is just considered "good practice".

Hunt groups are not visible over scn like users are, you need to add short codes to dial these groups over scn. If you dont want to dial the hunt group numbers over scn then you dont need to add any short codes and the hunt group numbers can be the same on each site if you really wanted. The hunt group numbers are not visible over scn like users are so the numbers being the same is not really an issue. Only if you want to dial hunt groups over scn is it an issue, in which case they should be unique numbers with short codes to dial them over the voip trunk. Again putting them in a seperate number range on a site per site basis is "good practice"

When configuring scn the only supported topology is a star topology, that is to say one central site with each branch site as an extension from the main site. Scn from one branch to another should always pass through the main site.

Can you document ip ranges for each site and settings in relation to voip trunks and ip routes that you have set on each system?

 

[hibroth]

Polaroid, I perfectly understood your problem, because I had it on a 4 system based SCN.

The problem appairs ONLY by installing SOEs over SCN, and the numbering plan is mixed despite every site has is own.

The problem is due to data corruption into the whole network, I mean :
The firmware version installed on the different sites was not the same, we saw 3.0(40), 3.0(44), 3.1(48)...
Some systems were set up using 5.0.xx Manager, other ones with 5.1.xx.

Because at SCN activation every system exchange datas each other (learning) we did:

Disconnect EVERY system from SCN
Load 3.1(48) bins to all IPOs
Factory Reset to all IPOs
BY USING 5.1(56) Manager manual new-setup on every system, I mean ANY RESTORE HAS BEEN MADE !
After these activities we re-connect systems to SCN.
Since we did it (nearly 3 weeks) the whole SCN is running without any data merging.

I am quite sure this could solve you too.

Good luck
HB

 

[polaroid]

thank youi'll try immediately!