Network Region configuration for SM and wireless.

[Kwick18]

Thank you all for your time. I am fixing all of our Network Regions(NR) that are now direct connect to each other. I do have some questions that are not easily spelled out in Avaya documentation.
1. We have 2 session managers. one at our main site, were CM lives, and another at a data center. Do session managers need NR defined to them? I am thinking no but would like some other opinions on it.
2. We have a wireless network with equinox sip clients. Should I map the wireless IPs as a stub network off of our main site? That is where the wireless lives as well.

Thanks again

 

[avayaguy23]

are you routing your sip phones through CM or directly through SM to your SBC?

 

[Kwick18]

SIP phones will always go thru SM first. We do have 3 SBC-E feeding vendor SIP trunks and 80% of our DIDs are SIP. Hope that answers your question.

 

[t2true]

I am no expert by any means. But, I can tell how mine is set.

We have two sites with a Session Manager (ASM) in each. I have a network region (NR) set for each ASM. The signaling groups use each NR for routing traffic to the specified ASM depending on the location (ASM) to where I want the call routed.

We use one intervening NR and all other NRs are a stub from it.

 

[kyle555]

Your network region in the signaling group for the far end node is used strictly for codec selection. So, if SIP sig group 10 had far end network region 10, and a phone in region 9 calls out that sig group, the SIP media offer will be according to the codec set defined of how region 9 talks to 10.

Dealing with locations and regions in CM and SM are very similar and not all that complicated once you get your head around it. There are specifics you can set per region/area/floor/location/planet and then there are global settings that take effect in the absence of more specific definitions.

So, in CM, you might have ip-network-region 9 and in the top left of page 1 it might have location 9 specified. ARS calls from phones in that subnet would look in ARS location 9 first and use that unless there was a more specific match for the number in the ARS ALL table.

If you left that location field blank, then those phones with IPs in network-region 9 (or those analog/digital phones on gateways in NR9) would only use the ARS ALL table.

Now, say you have a H323 phone with an IP that's not defined in the network map - it will inherit the region of procr - the thing it's registered to.

Contrasting that to Session Manager, it has the concept of 'locations' which are very similar to ip-network-regions. Locations can have IPs mapped to them.
So, let's map out some SM locations:
2.2.2.x = Florida
3.3.3.x = Texas
4.4.4.x = NY

Let's say your core is in NY with SM and CM1. Say you have a 2nd separate CM that's main site is in Texas and supporting sites in Florida.
When CM2 sends a SIP invite to SM, SM will analyze the real IP of the phone making the call. So, if that's a phone with IP 2.2.2.5 in Florida going to CM in Texas, SM will consider that call from location Florida as long as SM has location Florida with IP 2.2.2.x defined.
Now, say another location in Florida opens up with IPs 6.6.6.x that noone adds as a location in SM. the SIP entity for CM2 has location Texas - well, now SM interprets that call not from the most specific IP of the endpoint which is unknown, but of the next most specific location which is that of the SIP entity that sent it to SM - CM2.
And say someone forgot to add locations Florida and Texas entirely and your SM in NY has location NY, then SM considers that call from location NY.

You can also correlate network regions between CM and locations in SM so that when you sync your CM to your SM, everything in the ip-network-regions and ip-network-map gets a location created in SM to keep things consistent.

So, to your question about having a separate network region wireless, I'd be inclined to say yes if its not too unwieldy for you. It's not entirely necessary - you can have many entries in the ip-network-map with different subnets going to the same region - that's fine. You can also specify separate Emergency Location Extension per subnet. So, you can have 10 floors with 10 subnets with 10 different DIDs you send as CLID to 911 and wireless can just be an 11th - and if your wifi is different subnets per floor, you can follow that flow - but if your subnet on wifi is the same across the building, you'd be best to put your main # in there.

If you're dialing 911 out SIP, you can also have emergency application sequences and might have some different stuff you can do at the SM level with wifi phones. If you can keep that separate now, it might make new things in the future easier to implement. You always try to design in a way to leave doors open and not close any even if you don't know where stuff's going. Everything still works all in 1 mishmash region location all to itself, but you know your environment best - if you don't see it ever coming up, keep it simple!

 

[Kwick18]

Thank you Kyle555!! I was not aware that locations in SM are equivalent to network regions in CM. We are much smaller in size. Multiple physical locations but all within one area code. We set all users/station with a home location of CM. I assume doing this, location definition within SM is less important? When I test my new network-regions it appears thru traces that SIP phones take on the correct network-region as defined in CM.
I am still fuzzy on if Session managers actually need defined within CMs network-regions? Being that SM provide no media and only routing it probably makes no difference.

"You can also correlate network regions between CM and locations in SM so that when you sync your CM to your SM, everything in the ip-network-regions and ip-network-map gets a location created in SM to keep things consistent."
I will definatly have to fix this!!!!! Appreciate it.

I think I will go ahead and define the wireless network. It just seems to make sense.

 

[kyle555]

Yeah, so they're 2 completely different paradigms that can be linked together.

With multiple locations, even in the same area code, in CM you have location based ARS, so users in location 1 pick ARS matches in location 1 to routes that map to trunks in location 1, and not the trunks at location 2 across town.

Now, you can use the IP-network-map to associate IPs to regions, and regions to locations, or you could hard-code the location on page 1 of the station form - unless they're SIP phones - so you'll eventually have to get used to using the network map.

From the SM perspective, its IP address doesn't need to be defined in the network map to a network region. If you think about it, SM is never the "end point" making the call, it's just a pass-through for a set or a trunk. You can give the SIP sig group's far end node a network region - and that's used exclusively for what codecs CM will offer on an invite, but has no other bearing on things.

It's also important to understand how location is determined. On both CM and SM, for an incoming SIP invite, they will both look at the IP address of the oldest (furthest down) via header in the invite.

So, suppose you had no TDM trunks - all SIP - but you had H323 phones. A H323 phone calling 911 would have the oldest via header being the IP of the H323 phone. You might have carrier PSTN SIP trunks on a SBC for everything, but you might also have a little audiocodes analog gateway at each site with a copper trunk for 911. In that case, SM would see 911 called "from" the location of the H323 phone and could trigger on routing to say "send this call to the audiocodes at this guy's location in NY so it calls NYPD out the copper trunk there"

Take the opposite situation: all SIP phones, all PRI trunks. You have sites all across the country and only 1 SM. It stands to reason that all those SIP phones hitting CM are coming from the same SM IP, but you'd want the SIP set's IP address to determine its location just like a H323 would. CM, like SM, will look at the oldest via header of that invite from the phone-->SM-->CM and know the IP of the phone calling and associate it to the appropriate network region.

For your case, I'd just be worried about what happens when someone calls 911 and how important that is to you.
You said you're all in the same area code - is that also the same PSAP area by chance?
Do you have anything fancier than just "main billing number = 123 main st" per site and that's all that gets to the PSAP?
Are you dead certain that you can avoid location mixups when people call 911 from those wireless phones?
Does Bob have his extension at his desk and on his wireless phone and he goes in the warehouse sometimes and when he calls 911 and reception sees it on the console they'd direct the ambulance to Bob's desk and not the warehouse?

That's the Nth degree of uptight i'm talking about with the things that are accounted for in a solid design that accounts for all use cases. It might be overkill in the context of your little itty bitty question, but the examples help illustrate the configuration elements in CM and SM, why they're there and how to use them. That, and it's all stuff that'll get asked one day if someone ever gets a misdirected 911 call - the network guy adds a new wifi subnet you didn't know about that defaults to location 1 instead of location 2 and you call a different PSAP in the same area code but on the west side of town instead of the east side of town or whatever.

And if it was just a plain old office environment, you'd have probably bought DECT headsets on deskphones. Wireless to me means something that isn't a static fixed work area and might well have some extra safety requirements that you could use a little CYA for. Either just to make yourself look good, or because someone might actually count on that config in a life or death situation.