Session Manager Routing to CM 1

[wpetilli]

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?

 

[kyle555]

Oh, and maybe enable layer 3 test in your sig group. It sends sip options that way instead of pinging. Could be a thing

 

[wpetilli]

layer 3 test was already enabled. The other thing is the call from SM to CM is still coming in via TG5 and not TG6. wondering if that's part of the issue. The CM is setup as a SIP entity with an entity link to SM. In CM I have the 2 TG/SG's both setup and linked to that SM. They're both in-service, but not sure why SM sends the call down that 1 TG and not the other.

 

[kyle555]

if trunk 5/6 have sig 5/6, it's hitting 5 because whatever is in far end domain of sig 5 completely fits into the invite that came down from SM on that IP/port.

So, kyle@subdomain.subdomain2.domain.com and sig 5 is domain.com, and 6 is subdomain.subdomain2.domain.com, I'll always hit 5.
Your most specific subdomains have to be the lowest # sig groups, least specific, highest # sig group.

 

[wpetilli]

both tg/sg 5/6 using the same 5061 port couldn't be the issue?

 

[kyle555]

No, that's how it should be. CM has a max of 16 TLS connections for SIP trunks (and maybe AES, can't remember) so you need to use the same ports

So, when you go out a sig/trunk, it's easy, CM knows.

When SM sends a call down to CM, the sig group CM picks it like I said above

 

[wpetilli]

hmmm the only sg/tg in front of the one I want to use (6) is (5) and I changed that domain from gateway.com to thisstinks.gateway.com and still got the same result. These traces don't really say much.

 

[kyle555]

I dunno, busy/release 'em. Shouldn't be a big deal or getting the results like you're getting.
Are there no denial events if you display events for that, or maybe in /var/ecs/log some other error when you try those calls?

 

[wpetilli]

Spent a bunch more time on this again today.. The tracSM has the 503/500 signaling resources unavailable in the 'service' exchange messages. At the same time of this trace I tried tracing each tac of both TG's at the CM level.. trying both /s and just regular traces. Nothing displayed in the CM trace at all. I don't know what else to try. You mentioned a catch all SG with the root domain, but I'm not really following that. If the call I want to come through the first few SG's that match a sub-domain.. aren't I going to have the same problem where the call follows the wrong path and finds the catch all?

There are 2 SG's.. 5 and 6. As soon as I change the far end domain on SG5 to a subdomain.gateway.com the calls fail. I'm trying to make the call go out SG/TG6 to prove off the whole theory of this. As soon as I change back SG5 to gateway.com the calls work again, but only via that TG even though the sub-domain coming in matches SG6.

 

[kyle555]

the first sig group with that IP port pair where exactly what's in "far end sig group" fits into the domain of the request will be picked to take the incoming call. So, sig 5 customer.com will matching anything.in.any.subdomain.customer.com

You'd have to match the sig group first to see anything in a TAC trace, so maybe /var/log/ecs would show something as to why that message was dropped or not processed.

 

[wpetilli]

After probably 100+ attempts, traces and disrupted sleep I finally got this to work.

@Kyle -- I understood what you were explaining in this thread, but I thought I had everything as it should have been with subdomains assigned to the early numbered signaling groups. As a last ditch effort, today I decided to create another SIP TG/SG to the same SM w/SG 7 (higher than 5 and 6) and the root domain 'gateway.com' as the far end domain. Going along with your catch all domain. Call I wanted to work came in TG6 and out the location ars table I wanted.. I still can't wrap my head around the need for that last TG/SG being the fix, but omg.. the thrill of victory. These things are reasons I love this stuff so much. Thanks again, until the next saga.

So this brings up another question.. does using the NRP groups to sync up the NR's to SM locations required CM to be a managed element? Right now I'm not using SMGR to manage CM, aside from a lab system. I know it's easy to sync up and I'm not opposed to it, but curious what the consensus is with moving that direction. I'm still in an Evolution setup with still tons of h.323 endpoints.

 

[kyle555]

I'm glad you got it working! I think that's a requirement at the end and I'm sorry I missed it, but yeah, I think you need the last sig group being the root.domain and not lastsub.domain.com.