03-08-2012 01:51 PM - edited 03-16-2019 10:01 AM
Greetings,
We're having trouble with a CUCM 6.1(2) that we upgraded from a 4.1 install.
When we attempt make a call from an OnNet sip trunk to the PSTN, which is a Cisco 2811 Gateway, we receive back a 404 Not Found with a reason of Q.850;cause=1
The routing patterns are in place, and appear to be working properly. In fact, if we take the current routing pattern, and change only the Gateway/Route List field from the 2811 to another sip trunk, the call will route and complete successfully. Only when we route to the PSTN does it fail.
Additionally, if we call from a SCCP phone connected directly to the CUCM, it will route out the PSTN without any issue. It is only when traffic originates from a sip trunk that we have this issue.
Prior to the upgrade, this sip trunk was routing calls out the PSTN fine.
Here's a sample sip trace, in this case from an asterisk. We have also tried from a Dialogic HMP server with the same results.
INVITE sip:918011111111@10.16.1.11:5060 SIP/2.0
Via: SIP/2.0/UDP 10.16.0.23:5060;branch=z9hG4bK401057c5
Max-Forwards: 70
From: "5820-DisplayName" <sip:5820@10.16.0.23>;tag=as4fdcce1f
To: <sip:918011111111@10.16.1.11:5060>
Contact: <sip:5820@10.16.0.23:5060>
Call-ID: 08545f7a0bf7dd2226a06010235215a6@10.16.0.23:5060
CSeq: 102 INVITE
User-Agent: FPBX-2.9.0(1.8.7.1)
Date: Thu, 08 Mar 2012 21:39:52 GMT
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO, PUBLISH
Supported: replaces, timer
Content-Type: application/sdp
Content-Length: 354
v=0
o=root 78130406 78130406 IN IP4 10.16.0.23
s=Asterisk PBX 1.8.7.1
c=IN IP4 10.16.0.23
t=0 0
m=audio 12180 RTP/AVP 0 8 3 9 5 111 101
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:3 GSM/8000
a=rtpmap:9 G722/8000
a=rtpmap:5 DVI4/8000
a=rtpmap:111 G726-32/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=ptime:20
a=sendrecv
---
-- Called SIP/To Cisco SIP/918011111111
<--- SIP read from UDP:10.16.1.11:5060 --->
SIP/2.0 100 Trying
Date: Thu, 08 Mar 2012 21:41:20 GMT
From: "5820-DisplayName" <sip:5820@10.16.0.23>;tag=as4fdcce1f
Allow-Events: presence
Content-Length: 0
To: <sip:918011111111@10.16.1.11:5060>
Call-ID: 08545f7a0bf7dd2226a06010235215a6@10.16.0.23:5060
Via: SIP/2.0/UDP 10.16.0.23:5060;branch=z9hG4bK401057c5
CSeq: 102 INVITE
<------------->
--- (9 headers 0 lines) ---
<--- SIP read from UDP:10.16.1.11:5060 --->
SIP/2.0 404 Not Found
Reason: Q.850;cause=1
Date: Thu, 08 Mar 2012 21:41:20 GMT
From: "5820-DisplayName" <sip:5820@10.16.0.23>;tag=as4fdcce1f
Allow-Events: presence
Content-Length: 0
To: <sip:918011111111@10.16.1.11:5060>;tag=6fe197cb-c8da-4e3d-90b1-0e3ca992bc4d-23265460
Call-ID: 08545f7a0bf7dd2226a06010235215a6@10.16.0.23:5060
Via: SIP/2.0/UDP 10.16.0.23:5060;branch=z9hG4bK401057c5
CSeq: 102 INVITE
Is there anyone out there that could help us figure out why we cant route out the gateway?
03-08-2012 03:58 PM
Hi,
The called number is :-
918011111111
What does this mean to your CUCM on address
10.16.1.11
Does this number match any device on the incoming CSS/Partitions of the
SIP trunk
Regards
Alex
03-09-2012 07:43 AM
The CUCM on 10.16.1.11 has a routing pattern for 91.[2-9]XXXXXXXXX that routes the number out to the gw2811. That route pattern is in the "unrestricted" partition and is OffNet.
The inbound SIP Trunk is in the "unrestricted" partition and is OnNet.
Again, if we change the associated device from this route pattern from gw2811 to a different sip trunk, it will route the call to that sip trunk without issue.
03-09-2012 08:24 AM
Hi Clinton,
Do you have a translation profile to strip the digit "9" before it is being send out to the PSTN?
ALso, please post your dial peer config for the outbound call...
sample
voice translation-rule 10
rule 2 /^9\(.*\)/ /\1/
!
!
voice translation-profile DIGITSTRIP-9
translate called 10
dial-peer voice 1 voip
description From Cucm to Service Provider
translation-profile outgoing DIGITSTRIP-9
destination-pattern *.T
voice-class sip early-offer forced
session protocol sipv2
session target ipv4:x.x.x.x
dtmf-relay rtp-nte
no vad
hope this helps
Mark
03-09-2012 03:47 PM
The problem was caused by the mask for the outbound route pattern using a Calling Party Transformation Mask to mask the final 4 digits on the phone number for outbound caller-id.
It appears that on call manager 4.1, this information wasn't masked using the information passed in the sip header, but in 6.1 it is passed directly through. The "extension" that the devices on our sip trunks were passing were not witnin the DID range used by our provider.
We enabled debugging on our PRI gateway, and watched the rejection of Q.850 cause=1 come from our provider, which was the giveaway.
To solve this, we added a second Route Partition, and placed some of our sip trunks (and a few devices as well) within this Route Partition, and added an additional Route Pattern for this partition that hardcodes the calling party transformation mask.
If you find this through your internet searching, I hope this answer helps you.
01-02-2013 08:24 PM
I had the same problem but i got it fixed with the below configuration change on CUBE -
voice service voip
allow-connections sip to h323
Use debug voice dial command to find out more on this.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide