Showing results for 
Search instead for 
Did you mean: 

Sip Trunk to CUCM calling outbound to the PSTN not working



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@ SIP/2.0

Via: SIP/2.0/UDP;branch=z9hG4bK401057c5

Max-Forwards: 70

From: "5820-DisplayName" <sip:5820@>;tag=as4fdcce1f

To: <sip:918011111111@>

Contact: <sip:5820@>

Call-ID: 08545f7a0bf7dd2226a06010235215a6@

CSeq: 102 INVITE

User-Agent: FPBX-2.9.0(

Date: Thu, 08 Mar 2012 21:39:52 GMT


Supported: replaces, timer

Content-Type: application/sdp

Content-Length: 354


o=root 78130406 78130406 IN IP4

s=Asterisk PBX

c=IN IP4

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




    -- Called SIP/To Cisco SIP/918011111111

<--- SIP read from UDP: --->

SIP/2.0 100 Trying

Date: Thu, 08 Mar 2012 21:41:20 GMT

From: "5820-DisplayName" <sip:5820@>;tag=as4fdcce1f

Allow-Events: presence

Content-Length: 0

To: <sip:918011111111@>

Call-ID: 08545f7a0bf7dd2226a06010235215a6@

Via: SIP/2.0/UDP;branch=z9hG4bK401057c5

CSeq: 102 INVITE


--- (9 headers 0 lines) ---

<--- SIP read from UDP: --->

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@>;tag=as4fdcce1f

Allow-Events: presence

Content-Length: 0

To: <sip:918011111111@>;tag=6fe197cb-c8da-4e3d-90b1-0e3ca992bc4d-23265460

Call-ID: 08545f7a0bf7dd2226a06010235215a6@

Via: SIP/2.0/UDP;branch=z9hG4bK401057c5

CSeq: 102 INVITE

Is there anyone out there that could help us figure out why we cant route out the gateway?

5 Replies 5

VIP Alumni
VIP Alumni


The called number is :-


What does this mean to your CUCM on address

Does this number match any device on the incoming CSS/Partitions of the

SIP trunk



Regards, Alex. Please rate useful posts.

The CUCM on 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.

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...


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



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.

Saurabh Sareen

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.

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community: