I have a cisco vcs with globally dispersed h.323 video endpoints registered to it. I have a SIP trunk setup between the VCS and Session Manager. When users make any type of call from the video endpoints other than among themselves they route via AVAYA to get to an internal avaya user or out via the CM PSTN trunks. I know how to get the calls from Session Manager to a specific CM, but the calls always use the main CM's ARS table. I have several multinational LSP's with local PSTN circuits in each and setup with location based ARS. Is there a way when the digits arrive in CM.. either over the SIP TG from SM or in CM itself that will have the call go out an LSP's ARS table?
Tek-Tips is the largest IT community on the Internet today!
Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!
-
Congratulations Chriss Miller on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
Session Manager Routing to CM 1
- Thread starter wpetilli
- Start date
Not an LSPs ARS table, but you can go out the table of the location they're closest to.
You can do it in SM, or more easily in CM - but you can have IP ranges in SM "Locations" and CM's network regions and they would apply to whatever comes in to CM/SM.
That's to say if whatever segment those Cisco devices are, if you add the IPs to the CM network map, it'll tag calls from those as originating in the network region/location that owns that subnet. For argument's sake if 10.x.x.x was Avaya, 9.x.x.x was Cisco, x.1.x.x NA, x.2.x.x England, x.3.x.x Japan, you could have 9.3.x.x/16 be in the region that goes out your Tokyo HQ.
You could just as well do that with Location-based routing in SM - where say a +x for any e164 number is dialed from "originating location - Tokyo" the routing destination can be to your Tokyo CM, or main int'l CM on a subdomain of tokyooutbound.you.com.
It's probably easier with CM. Nonetheless, I'd encourage you to correlate your network regions and SM locations. Somewhere in release 7, I'm hearing Avaya will add a feature to consolidate bandwidth management. Today, even if your network regions are correlated, analog/h323 phones between regions use CM bandwidth, but would never tell SM if there's no SIP. Just as 2 non-Avaya devices that go thru SM trunks in subnets CM controls would never notify CM of the bandwidth used. That should be addressed in the not too distant future, but having all your ducks in a row in being able to use all the bandwidth management mechanisms would be a bit of a prerequisite. Seems like you might be a use case that fits in that category
You can do it in SM, or more easily in CM - but you can have IP ranges in SM "Locations" and CM's network regions and they would apply to whatever comes in to CM/SM.
That's to say if whatever segment those Cisco devices are, if you add the IPs to the CM network map, it'll tag calls from those as originating in the network region/location that owns that subnet. For argument's sake if 10.x.x.x was Avaya, 9.x.x.x was Cisco, x.1.x.x NA, x.2.x.x England, x.3.x.x Japan, you could have 9.3.x.x/16 be in the region that goes out your Tokyo HQ.
You could just as well do that with Location-based routing in SM - where say a +x for any e164 number is dialed from "originating location - Tokyo" the routing destination can be to your Tokyo CM, or main int'l CM on a subdomain of tokyooutbound.you.com.
It's probably easier with CM. Nonetheless, I'd encourage you to correlate your network regions and SM locations. Somewhere in release 7, I'm hearing Avaya will add a feature to consolidate bandwidth management. Today, even if your network regions are correlated, analog/h323 phones between regions use CM bandwidth, but would never tell SM if there's no SIP. Just as 2 non-Avaya devices that go thru SM trunks in subnets CM controls would never notify CM of the bandwidth used. That should be addressed in the not too distant future, but having all your ducks in a row in being able to use all the bandwidth management mechanisms would be a bit of a prerequisite. Seems like you might be a use case that fits in that category
- Thread starter
- #3
So is practice for this type of setup to create a SM location for every site whether it's an lsp or not, and the corresponding subnets within each? These Cisco endpoints don't register with CM or SM, so how would the ip-network-map in CM ever see those or SM for that matter? Since this is also a core site w/LSP's there's a SIP TG to SM with the one domain assigned to the signaling group, which all the lsp's funnel through. I haven't tried, but can the same CM have multiple SIP TG's to the same SM and use different domain names for each NR and SG. Perhaps that's what I'm missing. I can also from the cisco VCS based on the source of a call insert steering digits and even a domain that when it goes down the SIP TG to SM could match the domains in SM / CM.
Sending internal calls from CM up to SM and over to those other endpoints and back is easy. It's these endpoints requiring the PSTN from AVAYA for outbound calls, with sites all over the world.
Sending internal calls from CM up to SM and over to those other endpoints and back is easy. It's these endpoints requiring the PSTN from AVAYA for outbound calls, with sites all over the world.
Check a SIP invite traversing SM. SM and CM will look at the oldest IP in a via header to determine location/network region in their routing model.
That means you could, in theory, have audiocodes mp112 analog gateways at sites 1-100, locations 1-100 in SM with IP patterns 192.168.1.0/24 thru 192.168.100.0/24, and routing policies for "911 from location 1 go to sip trunk to audiocodes on site 1" etc. Now, suppose you put a Asterisk system trunked and it passed the set IP in a via header, then SM could get calls from all those subnets across a single Asterisk trunk and still use that to make routing decisions.
Same with CM. A trunk-to-trunk SIP call will be assigned to the NR of the oldest via header in the invite and analyzed accordingly. In the absence of that definition, it'll use the NR/location of the trunk it came in on - so, for CM, that'd be the "far end NR" of the sig group to SM and in SMs case, the location of the SIP entity the call came in on.
Whether you want to use it for bandwidth control or digit analysis, if that endpoint info is passed from the VCS to SM, you can work with it to treat those different VCS locations behind that 1 trunk to your SM accordingly.
That means you could, in theory, have audiocodes mp112 analog gateways at sites 1-100, locations 1-100 in SM with IP patterns 192.168.1.0/24 thru 192.168.100.0/24, and routing policies for "911 from location 1 go to sip trunk to audiocodes on site 1" etc. Now, suppose you put a Asterisk system trunked and it passed the set IP in a via header, then SM could get calls from all those subnets across a single Asterisk trunk and still use that to make routing decisions.
Same with CM. A trunk-to-trunk SIP call will be assigned to the NR of the oldest via header in the invite and analyzed accordingly. In the absence of that definition, it'll use the NR/location of the trunk it came in on - so, for CM, that'd be the "far end NR" of the sig group to SM and in SMs case, the location of the SIP entity the call came in on.
Whether you want to use it for bandwidth control or digit analysis, if that endpoint info is passed from the VCS to SM, you can work with it to treat those different VCS locations behind that 1 trunk to your SM accordingly.
- Thread starter
- #5
This CM also trunks up to SM for a 3rd party Voicemail system, which is priced out based on ports. We matched the SIP TG ports to match those voicemail sessions, but now with additional traffic that's unrelated to VM is that a guestimate game on how many additional members to add? Or am I allowed to have multiple SIP TG's from the same CM to the same SM?
Yup, usually you'd have separate trunks from CM to SM for various things, or even then, SM has no concept of trunk members or groups. It'll keep passing invites to the voicemail and if your ports are full, it'll pass the rejection along to CM. You can have your AAR routing for voicemail to a trunk group just for that purpose and never go over.
Still, you'd need to account for return traffic for call screening/find me follow me/outdial and have that come down to CM on the same trunk you go out to voicemail on. It's really not worth hashing out in the PBX I don't think.
Remember I was saying SM has 1 entity to that IP/port to CM despite CM having many sig/trunk groups to the same SM? And that CM picks the lowest numbered sig group with a match of "far end domain" in the sig group?
That's how you make far end domain in sig 1 voicemail.company.com and sig 2 pstn.company.com and sig 3 ciscovcs.company.com and sig 4 company.com and have the traffic in from voicemail or pstn or cisco grab their respective sig/trunk groups and everything else grab sig 4
Still, you'd need to account for return traffic for call screening/find me follow me/outdial and have that come down to CM on the same trunk you go out to voicemail on. It's really not worth hashing out in the PBX I don't think.
Remember I was saying SM has 1 entity to that IP/port to CM despite CM having many sig/trunk groups to the same SM? And that CM picks the lowest numbered sig group with a match of "far end domain" in the sig group?
That's how you make far end domain in sig 1 voicemail.company.com and sig 2 pstn.company.com and sig 3 ciscovcs.company.com and sig 4 company.com and have the traffic in from voicemail or pstn or cisco grab their respective sig/trunk groups and everything else grab sig 4
- Thread starter
- #7
Now it's coming together. the only SIP elements in the enterprise was vm, but now branching out to the video environment and about to start mobility. Then trunking a bit later. I think my other issue is I have 4 SM's all linked. I think 4 is prob too many. Thinking of peeling one out for a lab.
General best design practices now are have sets and trunks on separate SMs. So, for 2 data centers, 1 trunk/1 set SM each.
Makes the traces easier to read and not see a SIP set go thru SM1 down to CM up to SM1 to voicemail to 0 out to SM1 to CM to another SIP set to SM1 and to the destination
Makes the traces easier to read and not see a SIP set go thru SM1 down to CM up to SM1 to voicemail to 0 out to SM1 to CM to another SIP set to SM1 and to the destination
The existing trunk at each location is available for any location to use. You just need the correct ars entry in the location of the source of the call and a route to manipulate the digits so that when the call is dialed as international it will go out as a local call.
There should already be a route in the system that directs calls out the local trunks at the international locations that have trunks. The ARS table of the location that hosts your CM connection to SM should have entries for the country codes of each remote media gateway that use routes that use the remote trunks.
In other words, the media gateway let say it is in London, has a PRI and let's say London is location 40. It has a trunk, call it trunk 40. It has a lsp but that is irrelevant unless the network is down. It is just a remote media gateway connected to the main CM. There is a route defined to send calls out trunk 40 that is available for any location to use. Call it route 40. The ars table for location 40 sends calls from telephones that are in location 40 out to route 40 which sends them out trunk 40. That route probably does not change any of the dialed digits.
In our case the main CM is in Dallas which is location 10. SM is in Dallas on a SIP trunk. I put an entry in the ars table for location 10 that matches international calls to the UK 01144 and sends it to route 41. Route 41 looks like route 40 only it deletes 5 digits before sending the call out. It also has a second line referencing the local Dallas trunk that does not delete the 5 digits.
There was a little confusion here because in the uk they put a 0 in front of the number when dialing in country, which is what this call will look like, so in my route 41 I inserted a 0, but it seems like It didn't work until I stopped inserting it. You may have to work through the digit manipulation for each country you are working with. You also need to have the users place the call as normal international call. That way if the connection to the London media gateway is down the call will go out the local trunk correctly.
Since the call is coming into CM on one trunk and being directed out another trunk you need to allow that kind of trunk to trunk connection. I cannot remember where that is. Maybe in the COS.
REJ
There should already be a route in the system that directs calls out the local trunks at the international locations that have trunks. The ARS table of the location that hosts your CM connection to SM should have entries for the country codes of each remote media gateway that use routes that use the remote trunks.
In other words, the media gateway let say it is in London, has a PRI and let's say London is location 40. It has a trunk, call it trunk 40. It has a lsp but that is irrelevant unless the network is down. It is just a remote media gateway connected to the main CM. There is a route defined to send calls out trunk 40 that is available for any location to use. Call it route 40. The ars table for location 40 sends calls from telephones that are in location 40 out to route 40 which sends them out trunk 40. That route probably does not change any of the dialed digits.
In our case the main CM is in Dallas which is location 10. SM is in Dallas on a SIP trunk. I put an entry in the ars table for location 10 that matches international calls to the UK 01144 and sends it to route 41. Route 41 looks like route 40 only it deletes 5 digits before sending the call out. It also has a second line referencing the local Dallas trunk that does not delete the 5 digits.
There was a little confusion here because in the uk they put a 0 in front of the number when dialing in country, which is what this call will look like, so in my route 41 I inserted a 0, but it seems like It didn't work until I stopped inserting it. You may have to work through the digit manipulation for each country you are working with. You also need to have the users place the call as normal international call. That way if the connection to the London media gateway is down the call will go out the local trunk correctly.
Since the call is coming into CM on one trunk and being directed out another trunk you need to allow that kind of trunk to trunk connection. I cannot remember where that is. Maybe in the COS.
REJ
- Thread starter
- #10
Thanks for all this info.. I've been reading non stop on this and mapping out the best way for me to start implementing w/o causing too much chaos.
One thing I'm not clear on is the intervening/ghost region. I do have my remote LSP's with direct access to that region, which in turn that region is directly connected to NR1. If I have to begin using different sub-domains in SM, the CM SG's and NR's, what do I specify in the intervening region as a domain?
One thing I'm not clear on is the intervening/ghost region. I do have my remote LSP's with direct access to that region, which in turn that region is directly connected to NR1. If I have to begin using different sub-domains in SM, the CM SG's and NR's, what do I specify in the intervening region as a domain?
authoritative domain is used to determine whether the numbering format for a sip sig group is public or private. Basically, if FROM, PAI or contact on an incoming call on a sig group matches the authoritative domain of the NR of the called party, it's considered private numbering, or else it's public. It's pretty complicated!
To say, it doesn't really matter what the authoritative domain is of any given intervening region overall, but given the most likely case is the procr region at one end of your SIP trunks, it's a very important concept to have on procr and should be fine for anything else you want to do.
If you want to understand how CM manages its numbering formats, look at this PSN. It's a doozy!
To say, it doesn't really matter what the authoritative domain is of any given intervening region overall, but given the most likely case is the procr region at one end of your SIP trunks, it's a very important concept to have on procr and should be fine for anything else you want to do.
If you want to understand how CM manages its numbering formats, look at this PSN. It's a doozy!
- Thread starter
- #12
ha-- yes that was a tough read
In running a traceSM to see what's coming in from these cisco endpoints, I'm getting the alias unit name @ the IP of the actual Cisco appliance and not of the actual endpoints IP. It's not included in any of the SIP msg's pertaining to the call. That's going to hamstring me from being able to lineup these units to a proper location.
In running a traceSM to see what's coming in from these cisco endpoints, I'm getting the alias unit name @ the IP of the actual Cisco appliance and not of the actual endpoints IP. It's not included in any of the SIP msg's pertaining to the call. That's going to hamstring me from being able to lineup these units to a proper location.
- Thread starter
- #13
I'm struggling to find how that correlate field gets flagged in Session Manager/Locations. No matter what I try I cannot flag that or find what setting turns it on. Nor am I finding any documentation or threads about it other than a description. My SM is 6.3.18 and CM 6.3.15, if that matters.
- Thread starter
- #15
I'm name matched between the SM location and CM NR, location and TG.. still nothing. Made sure I did a sync as well.
More setup info is I'm using location 2, NR 2 and have 2 SIP TG's to this SM. the ip-network-map entries match what I have in the SM locations as well. In the SG's for the 2 trunks I am differentiating by the domain name. In SM.. location name matches the name for the previous info, entity link to this CM and assigned to this location.
More setup info is I'm using location 2, NR 2 and have 2 SIP TG's to this SM. the ip-network-map entries match what I have in the SM locations as well. In the SG's for the 2 trunks I am differentiating by the domain name. In SM.. location name matches the name for the previous info, entity link to this CM and assigned to this location.
I knew it was weird...738
gotta do it when adding the CM I think
gotta do it when adding the CM I think
- Thread starter
- #17
I got that part setup now with the correlation. I've now been able to get a call from one of these external endpoints through. I'm dialing as the user current does, with 9 1 xxx-xxx-xxxx and using search rules on that Cisco system. I'm inserting steering digits and adding the domain of the local AVAYA site it should be going out through.... ex 9 1 xxx-xxx-xxxx ---> 831 1 xxx-xxx-xxxx@lab.gateway.com with a destination of the Session Manager trunk.
In SM this location is setup with correlation to the CM network region 2 that has lab.gateway.com as the domain in the SG and NR. There is a defined domain lab.gateway.com in SM as well. I've then created an adaptation that strips the 831 and inserts 9 on the 'outgoing calls from SM' section and applied this to the CM entity link.
In CM, I have multiple SIP trunks setup that point to this same SM, with different domains defined in each SG. In SM, unless this is configured wrong I only have the 1 sip entity and entity link created to CM. I wasn't sure how adding multiple of the same was even possible for the different sip trunks. I'm using location 2, NR 2, SG/TG 6. For testing, in ars ana loc 2 the full test number is defined.
The call makes it from the starting point and hits my cell phone successfully, so I have it fully working. But the traces show the call is not coming in on the SIP TG 6 that is setup between CM and SM with this matching domain. It is coming in via SIP TG 5 that has domain gateway.com and it is not using the ars table defined for loc 2 and using 1/all. I then changed SIG 5 and NR 1 to domain main.gateway.com to avoid having gateway.com as the lowest #'d SG. When I make test calls with this setup I get 500/503 (signaling resources unavailable) using traceSM as nothing is getting to CM. If I change the domains back to gateway.com the calls work again, but using the wrong TG and ARS table.
In SM this location is setup with correlation to the CM network region 2 that has lab.gateway.com as the domain in the SG and NR. There is a defined domain lab.gateway.com in SM as well. I've then created an adaptation that strips the 831 and inserts 9 on the 'outgoing calls from SM' section and applied this to the CM entity link.
In CM, I have multiple SIP trunks setup that point to this same SM, with different domains defined in each SG. In SM, unless this is configured wrong I only have the 1 sip entity and entity link created to CM. I wasn't sure how adding multiple of the same was even possible for the different sip trunks. I'm using location 2, NR 2, SG/TG 6. For testing, in ars ana loc 2 the full test number is defined.
The call makes it from the starting point and hits my cell phone successfully, so I have it fully working. But the traces show the call is not coming in on the SIP TG 6 that is setup between CM and SM with this matching domain. It is coming in via SIP TG 5 that has domain gateway.com and it is not using the ars table defined for loc 2 and using 1/all. I then changed SIG 5 and NR 1 to domain main.gateway.com to avoid having gateway.com as the lowest #'d SG. When I make test calls with this setup I get 500/503 (signaling resources unavailable) using traceSM as nothing is getting to CM. If I change the domains back to gateway.com the calls work again, but using the wrong TG and ARS table.
Yes. That's the quirk. CM matches on the lowest numbered sig group that matches IP and port and has a match of what's in the far end domain in the sig group.
That means incoming potato.customer.com, tomato.customer.com, apple.customer.com will always match sig group 1 if it's domain is customer.com.
The customer.com sig group must be later and subdomain.customer.com earlier
That means incoming potato.customer.com, tomato.customer.com, apple.customer.com will always match sig group 1 if it's domain is customer.com.
The customer.com sig group must be later and subdomain.customer.com earlier
- Thread starter
- #19
I've changed the far end domain name in the signaling group that came before the one I wanted my calls to follow from gateway.com to thisstinks.gateway.com. I'm still getting the 503 (signaling resoures unavailable). When I change thisstinks.gateway.com back to gateway.com the call goes all the way through. Not how I want it to go through, but goes through nonetheless. I'm not seeing what could be wrong...
- Status
Similar threads
- Locked
- Question
- Locked
- Question