Issue redirecting inbound sip calls to second sip trunk

[royhog]

Hello,

I'm new to SIP. I have CUCM v14 BE6k with managed SIP as our main phone service.  The SIP provider sends us 4 digits. We are deploying a new IVR service which will connect over sip to our call manager.  I need to redirect inbound calls from an existing DID number on our managed sip service to a sip tie trunk (public ip to public ip) that connects to the new IVR service.  

The SIP tie trunk will egress through the ASA 5516x firewall. I have the IP's natted from the internal cucm to an external IP on port 5060.  I have an inbound acl allowing sip traffic from the IVR vendor IP to CUCM on port 5060. I also have sip and rtsp being inspected.

I configured a translation pattern which translates the inbound 4 digits from the managed sip to 10 digits -> which matches a route pattern -> which goes to a route list -> which goes to a route group -> which lists the sip tie trunk as the device. 

I added a CSS and partition for the sip tie trunk. The CSS lists the new partition and the translation pattern is using that CSS.  The route pattern is in the new IVR partition.

When i call the DID from the managed sip provider, it waits a good 10 seconds, rings once then it sends me to a carrier message saying the called party is temporarily unavailable.

The sip trunk is up and i'm sure the call routing is the issue.  Any suggestions or help would be appreciated.

Thanks

Bill

[b.winter]

What do the logs say? Have you checked the call in RTMT? Have you "traced" the call in the DNA tool of CUCM?
Without logs, it can be basically anything ...
Is the call reaching CUCM? Is it hitting your translation pattern? Is it correctly translated? Does it hit the correct route pattern? Is CUCM sending the outgoing INVITE, does it get a SIP response? ...

[b.winter]

@royhog any update?

[royhog]

Still looking at the logs.

[Maren Mahoney]

If it's waiting a 'good 10 seconds' I bet it is waiting 12 seconds until the T302 timer (interdigit timeout), indicating that there is a longer route pattern that it is matching. That's the first issue.

It sounds like the pattern that is taking you to the carrier is the pattern that 'wins' after the timeout completes. But, as you noted, that call is failing. If you are interested in doing so, you can post your trace/debug files here and we can help look. (If you do, please do so as a text file attachment which make them easier to analyze.)

Maren

[royhog]

Thanks for the replies.  I was thinking of the t302 timer as well.  I attached the logs.  Any help would be appreciated. 

[Maren Mahoney]

I'm assuming you masked your area code with the 2x2. What is the source of the specific call? I see the 480 error, but you mentioned a translation pattern as well. Please be sure to include the inbound call from the provider with the 4-digits.

We should probably also have the 'debug ccsip messages' from the routers as well.

Maren

[royhog]

Thanks Maren,

I actually got it straight. The IVR service had a misconfiguration on there side. 

Thanks again,

Bill

[Maren Mahoney]

Thanks for posting your fix. That's very helpful to those who follow.

Maren

[royhog]

Yw.  If this is helpful to anyone, the issue we found was we were receiving 480 from the other side:

480 Received from the IVR:
71855337.001 |11:25:02.263 |AppInfo |//SIP/SIPUdp/wait_SdlDataInd: Incoming SIP UDP message size 469 from xxx.xxx.16.155:[5060]:
[41174330,NET]
SIP/2.0 480 Temporarily Unavailable
Via: SIP/2.0/UDP xxx.xx.7.4:5060;branch=z9hG4bK43702e2c6ee59f;rport=5060;received=xxx.xx.xx.168
From: "John Smith" <sip:xxx4143627@xxx.xx.7.4>;tag=13007994~b0ddec3c-fac1-4432-ba6c-dfad6c9f87eb-24948288
To: <sip:xxxxxx4970@xxx.xxx.16.155>;tag=323402252ee4
Call-ID: a481e080-1f01243f-26e6a2-407dd0a@10.221.7.4
CSeq: 101 INVITE
Contact: <sip:xxxxxx4970@xxx.xxx.16.155:5060>
User-Agent: VaxServerSDK/4.2
Content-Length: 0