Sip trunk problem on cme 3825 but works on AsteriksWin32 server

Unanswered Question
Oct 9th, 2009


I need help.

Im trying to configure a sip trunk on my cme 3825, but i cant get works.

i made a call and the other side ring but thats all. just noise in both sides.

i debug the ccsip messages and i saw that i sent invite messages, but never recived

ack or any message from the sip-server.

The weird thing is that the trunk is tested by the local provider with

a asteriksWin32 Pbx and the calls incoming and recive are just fine!!!

so pls, what wrong with mi router !!!

the provider told the parameters of the sip trunk

- its sip-server A.B.C.D

- its a ip athenticate based (

- the sip server recive a 53197010 as calling number.

this is mi configuration:

Router#show run

Building configuration...


voice service voip




voice class codec 1

codec preference 1 g729br8

codec preference 2 g729r8

codec preference 3 g723ar63

codec preference 4 g711ulaw

codec preference 5 g711alaw


voice translation-rule 1

rule 1 /^.*/ /53197010/


voice translation-profile out5

translate calling 1


interface GigabitEthernet0/0

description TRONCAL SIP

ip address


interface GigabitEthernet0/1

description LAN_SOFTPHONE

ip address


ip route


dial-peer voice 11 voip

description outgoing sip calls

translation-profile outgoing out5

service session

destination-pattern T

voice-class codec 1

session protocol sipv2

session target ipv4:A.B.C.D

dtmf-relay rtp-nte

clid network-number 53197010

no vad


dial-peer voice 200000 voip

description incoming sip calls

voice-class codec 1

session protocol sipv2

incoming called-number T

dtmf-relay sip-notify rtp-nte



registrar ipv4:A.B.C.D expires 3600


----------------------------------------the debug ccsip messages

mi debug cccsip show that i send sip invite packets but no response from the server openser.


INVITE sip:[email protected]:5060 SIP/2.0

Via: SIP/2.0/UDP;branch=z9hG4bK1B37F

Remote-Party-ID: <sip:[email protected]>;party=calling;screen=yes;privacy=of


From: <sip:[email protected]>;tag=3A9BCB4-17CA

To: <sip:[email protected]>

Date: Wed, 07 Oct 2009 22:12:26 GMT

Call-ID: [email protected]

Supported: 100rel,timer,resource-priority,replaces,sdp-anat

Min-SE: 1800

Cisco-Guid: 970522294-2999259614-2162464803-3960326021

User-Agent: Cisco-SIPGateway/IOS-12.x



CSeq: 101 INVITE

Max-Forwards: 70

Timestamp: 1254953546

Contact: <sip:[email protected]:5060>

Expires: 180

Allow-Events: telephone-event

Content-Type: application/sdp

Content-Disposition: session;handling=required

Content-Length: 245


finally shows...

*Oct 7 22:12:58.199: //74/39D8FEB680E4/SIP/Call/sipSPICallInfo:

The Call Setup Information is:

Call Control Block (CCB) : 0x65EC0340

State of The Call : STATE_DEAD

TCP Sockets Used : NO

Calling Number : 53197010

Called Number : 3592867

Source IP Address (Sig ):

Destn SIP Req Addr:Port : A.B.C.D:5060

Destn SIP Resp Addr:Port : A.B.C.D:5060

Destination Name : A.B.C.D

*Oct 7 22:12:58.199: //74/39D8FEB680E4/SIP/Call/sipSPIMediaCallInfo:

Number of Media Streams: 1

Media Stream : 1

Negotiated Codec : No Codec

Negotiated Codec Bytes : 0

Nego. Codec payload : 255 (tx), 255 (rx)

Negotiated Dtmf-relay : 0

Dtmf-relay Payload : 0 (tx), 0 (rx)

Source IP Address (Media):

Source IP Port (Media): 16446

Destn IP Address (Media): -

Destn IP Port (Media): 0

Orig Destn IP Address:Port (Media): [ - ]:0

*Oct 7 22:12:58.199: //74/39D8FEB680E4/SIP/Call/sipSPICallInfo:

Disconnect Cause (CC) : 102

Disconnect Cause (SIP) : 200

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 4.5 (2 ratings)
Nicholas Matthews Tue, 10/13/2009 - 05:32

This would be the problem:


If like Paolo said and you are behind NAT, you need to have SIP fix-up enabled. As well, sometimes providers will do NAT traversal. You may want to add this command:



Otherwise, you need a router capable of doing NAT fixup.


Paolo Bevilacqua Tue, 10/13/2009 - 06:38



That is hidden and undocumented, so one would need to know a bit more about it :)

Nicholas Matthews Tue, 10/13/2009 - 08:48

Normally when a router initiates a SIP request the source port will be a random port above 1024.

This is in contrast to many SIP endpoints which use 5060 as the source and destination port, even though the application only depends on the destination port.

Many SIP providers will automatically contact the source port when they see a NAT address hoping that they can get through the firewall.

It's a long shot, but I've seen it work before.



This Discussion