cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1674
Views
15
Helpful
14
Replies

CUBE SIP Trunk to Provider

mattcalderon
Level 4
Level 4

Here goes another one.

Having an issue with a CUBE deployment and the topology is as such.

CUCM--(H323)---CUBE-(SIP)----Provider

What we are seeing now is when we send a call over to the cube via H323 and then out to the SIP provider is that the remote phone (my cell) will ring and when i go to answer it, the ip phone will immediatly go to fast busy. This tells me that the CUCM is sending the call out the H323 gateway and then the call is going out over the SIP trunk to the provider. The sip provider is telling me that they see upon the call ringing in, is that once i answer on the cell, my cube is sending them a 200 cancel message and the call drops. Hope this enough info, but if you need more, just let me know.

Here is my dial-peer outbound:

dial-peer voice 2 voip

description ** Outgoinging call to SIP trunk **

destination-pattern [2-9].........

session protocol sipv2

session target ipv4:x.x.x.x

session transport udp

dtmf-relay rtp-nte

codec g711ulaw

ip qos dscp cs5 media

ip qos dscp cs4 signaling

clid network-number xxxxxxxxxx

no vad

Running 2821 with IOS spservices 12.4(19)

CUCM 6.1.2

SIP provider is bandwidth.com and they do not require any authentication.

Only outbound calls are a priority at this time.

14 Replies 14

Hi Matt,

This is almost certainly a codec negotiation problem. Any time the call hangs up when media is established usually means you have a codec or resource related problem.

'debug voip dialpeer' and find out what dial peers you are hitting. Then make sure you have compatible codecs on both (the same, which is g711ulaw here).

If you're using outbound fast start with your H323 gateway, make sure your codec is set to G711 as well there.

Also make sure that the region your phone is in has G711 to the region your H323 gateway is in.

You may want to try using 'codec transparent' on both dial peers on your CUBE. If you're hitting dial peer 0, configure a dial peer with 'incoming called-number .' and codec settings.

Hopefully one of these is your problem :)

-nick

Nick,

Great to hear from.

This is what i am seeing on ccsip debug when attempting an outbound call. It seems to me that they negotiate a codec. Is this true?

Mar 5 20:00:43.769: //14865/80841A2E1400/SIP/Call/sipSPICallInfo:

The Call Setup Information is:

Call Control Block (CCB) : 0x45775F30

State of The Call : STATE_RECD_PROCEEDING

TCP Sockets Used : NO

Calling Number : 7704211978

Called Number : 9162765476

Source IP Address (Sig ): 216.206.210.35

Destn SIP Req Addr:Port : 216.82.224.202:5060

Destn SIP Resp Addr:Port : 216.82.224.202:5060

Destination Name : 216.82.224.202

*Mar 5 20:00:43.769: //14865/80841A2E1400/SIP/Call/sipSPIMediaCallInfo:

Number of Media Streams: 1

Media Stream : 1

Negotiated Codec : g711ulaw

Negotiated Codec Bytes : 160

Negotiated Dtmf-relay : 6

Dtmf-relay Payload : 101

Source IP Address (Media): 216.206.210.35

Source IP Port (Media): 0

Destn IP Address (Media): 207.155.147.43

Destn IP Port (Media): 61360

Orig Destn IP Address:Port (Media): 0.0.0.0:0

*Mar 5 20:00:44.389: //14865/80841A2E1400/SIP/Call/sipSPICallInfo:

The Call Setup Information is:

Call Control Block (CCB) : 0x45775F30

State of The Call : STATE_DEAD

TCP Sockets Used : NO

Calling Number : 7704211978

Called Number : 9162765476

Source IP Address (Sig ): 216.206.210.35

Destn SIP Req Addr:Port : 216.82.224.202:5060

Destn SIP Resp Addr:Port : 216.82.224.202:5060

Destination Name : 216.82.224.202

*Mar 5 20:00:44.389: //14865/80841A2E1400/SIP/Call/sipSPIMediaCallInfo:

Number of Media Streams: 1

Media Stream : 1

Negotiated Codec : g711ulaw

Negotiated Codec Bytes : 160

Negotiated Dtmf-relay : 6

Dtmf-relay Payload : 101

Source IP Address (Media): 216.206.210.35

Source IP Port (Media): 0

Destn IP Address (Media): 207.155.147.43

Destn IP Port (Media): 61360

Orig Destn IP Address:Port (Media): 0.0.0.0:0

*Mar 5 20:00:44.389: //14865/80841A2E1400/SIP/Call/sipSPICallInfo:

Disconnect Cause (CC) : 0

Disconnect Cause (SIP) : 200

I did run a debug voip dialpeer and i see it hitting the correct one. This is a MGCP gateway and the only dial-peers other than MGCP specific ones, are the SIP dialpeers to the provider.

The dial-peers are below:

dial-peer voice 1 pots

incoming called-number .

direct-inward-dial

!

dial-peer voice 10 pots

destination-pattern 9[2-9]..[2-9]......

!

dial-peer voice 12 pots

destination-pattern 91[2-9]..[2-9]......

prefix 1

!

dial-peer voice 14 pots

destination-pattern 9911

prefix 911

!

dial-peer voice 16 pots

destination-pattern 9411

prefix 411

!

dial-peer voice 18 pots

destination-pattern 9011T

prefix 011

!

dial-peer voice 999011199 pots

service mgcpapp

port 0/1/1:1

!

dial-peer voice 999001199 pots

service mgcpapp

port 0/0/1:1

!

dial-peer voice 101 voip

description ** Outgoinging call to SIP trunk **

destination-pattern [2-9].........

session protocol sipv2

session target ipv4:216.82.224.202

dtmf-relay rtp-nte

codec g711ulaw

ip qos dscp cs5 media

ip qos dscp cs4 signaling

clid network-number 7704211978

no vad

!

dial-peer voice 2 voip

description ** Outgoinging call to SIP trunk **

destination-pattern [2-9].........

session protocol sipv2

session target ipv4:216.82.224.202

dtmf-relay rtp-nte

codec g711ulaw

ip qos dscp cs5 media

ip qos dscp cs4 signaling

clid network-number 7704211978

no vad

!

sip-ua

!

continued.....

!

I am not using H323 fast start on the config in CUCM.

I did create a new device pool with the newly created region that is 711 to all other regions.

I will try the use of codec transparent command on both dial peers.

Also below is the voice service voip outputs:

!

!

voice service voip

allow-connections h323 to h323

allow-connections h323 to sip

allow-connections sip to h323

allow-connections sip to sip

supplementary-service h450.12

h323

emptycapability

h225 id-passthru

h225 connect-passthru

h245 passthru tcsnonstd-passthru

sip

bind control source-interface GigabitEthernet0/1

bind media source-interface GigabitEthernet0/1

!

Hi Matt,

You can probably benefit from reading this document:

http://www.cisco.com/en/US/tech/tk652/tk90/technologies_tech_note09186a008010ae1c.shtml

What you're missing is an incoming dial peer. Everyone remembers the outgoing dial peer that does the routing, but the incoming dial peer that creates the settings for the incoming call is all too often forgotten. It looks like you're probably hitting an incoming dial peer 0.

Try adding this configuration:

dial-peer voice 555 voip

answer-address

codec transparent

no vad

dtmf-relay h245-alpha rtp-nte

hth,

nick

Excellent Nick. I am now further along on this. The call is now established but i only recieve 1 way audio. The cell phone can receive the call and answer but can not hear the ip phone. Routing issue? I tried sourcing a ping from my outside interface facing the SIP provider and i was able to do so.

You may want to use this document to troubleshoot the one way voice.

It's probably an ACL/firewall/routing issue.

-nick

Thanks for the doc nick.

Currently this router has an external ip on the Gig interface pointing directly to the provider. There are NO ACLS or any other firewall configuration on the interface. Also I verfied routing there is only 1 static route that points out the interface to the next hop downstream. Not too sure what is going on here

I currently have a TAC open on this and we discovered that during the output of debugs and show call active voice, that we are indeed seeing tx/rx traffic and the stats are incrementing. I have just taken a sniffer trace on the interface and am waiting for my engineer to respond back.

Issue is that TAC is saying everything looks good and the SIP provider is saying everything seems in order.

I guess the sniffer trace should get us somewhere and determine if we are getting the RTP stream back.

Also a quick question on this. The phone should only set up a RTP stream to the CUBE and the CUBE then should set up a RTP stream over the to the SIP Provider correct? This is what we are currently seeing on our side.

Hi Matt,

That is correct.

What you're checking for here is empty RTP packets. It sounds like the basics are covered, and it's possible you're just getting RTP packets with nothing in them.

It's worth your time to double-click the little green '?' on your IP phone during the one way audio to see what the RX and TX counters look like. You could also check the phone website under stream statistics.

You may want to check out this post of mine:

http://forum.cisco.com/eforum/servlet/NetProf?page=netprof&forum=Unified%20Communications%20and%20Video&topic=IP%20Telephony&topicID=.ee6c829&CommCmd=MB%3Fcmd%3Dpass_through%26location%3Doutline%40^1%40%40.2cd249ca/3#selected_message

It's related to building custom disconnect tones, but in the process it outlines how to listen to a G.711 packet capture on your PC.

-nick

Nick,

Once again thanks for your help. We have reconstructed the sniffer trace and seeing that as i have the sniffer outside of the network we can pick up the audio leaving the network and play it back. My TAC engineer seems to think its the providers problem. Still looking into it though.

If you construct the audio and it's good leaving your router, then it doesn't leave many other possible causes other than the provider.

If we're sending out good RTP packets to the provider, what else is the router expected to do? :)

-nick

Once again I agree with you. Thanks for your input.

So I sent the sniffer traces back to the SIP provider and they responded back saying they think that the ports are different between the gateway and the SIP proxy. They also mentioned on the SIP Invite that the port negotiation does not happen.

This is the output of one of the SIP messages.

v=0

o=- 1236360374 1236360375 IN IP4 209.247.5.189

s=-

c=IN IP4 209.247.5.189

t=0 0

m=audio 63606 RTP/AVP 0 18 ***CARRIER IS REQUESTING RTP 209.247.5.189 PORT 63606*******

Fri Mar 6 17:26:26 2009 216.206.210.35:59105 ---> 216.82.224.202:5060

ACK sip:+19162765476@209.247.16.221:5060;transport=udp SIP/2.0

Via: SIP/2.0/UDP 216.206.210.35:5060;branch=z9hG4bKCE1CDC

From:<7704211978>;tag=A700BF4-23F

To:<9162765476>;tag=VPST50603522629853

Date: Fri, 06 Mar 2009 17:26:49 GMT

Call-ID: CF53CAFA-9AA11DE-9EFDB93C-9CC5A45E@216.206.210.35

Route:<216.82.224.202>

Max-Forwards: 70

CSeq: 101 ACK

Content-Type: application/sdp

Content-Length: 162

v=0

o=CiscoSystemsSIP-GW-UserAgent 499 2750 IN IP4 216.206.210.35

s=SIP Call

c=IN IP4 216.206.210.35

t=0 0

m=audio 17082 RTP/AVP 0

c=IN IP4 216.206.210.35 ***** YOU ARE REQUSTING TO 216.206.210.35 AND PORT 17082************

All there is to check that is check the last SDP they sent against the packet capture.

If it's the same they're out of excuses.

If it's different you need to look at any possible firewall or NAT configuration on your side, and check a packet capture on the last possible egress interface.

-nick

Nick,

Thanks again for your responses as they are very much appreciated.

I did end up getting this to work.

I first upgraded my IOS to 12.4.22T1 and reloaded. (I was running 12.4(19) and think there may be an issue with that particular IOS)

Secondly, I enabled fast-start both inbound and outbound with a MTP resource registered back to UCM and in the device pool with the CUBE.

Also with the following configurations on the CUBE:

dial-peer voice 101 voip

description ** Outgoinging call to SIP trunk **

destination-pattern [2-9].........

session protocol sipv2

session target ipv4:216.82.224.202

session transport udp

dtmf-relay rtp-nte

codec g711ulaw

ip qos dscp cs5 media

ip qos dscp cs4 signaling

clid network-number ..........

no vad

preference 1

dial-peer voice 102 voip

description ** Outgoinging call to SIP trunk **

destination-pattern [2-9].........

session protocol sipv2

session target ipv4:216.82.225.202

session transport udp

dtmf-relay rtp-nte

codec g711ulaw

ip qos dscp cs5 media

ip qos dscp cs4 signaling

clid network-number ..........

no vad

preference 2

voice service voip

address-hiding

allow-connections h323 to h323

allow-connections h323 to sip

allow-connections sip to h323

allow-connections sip to sip

sip

bind control source-interface GigabitEthernet0/1

bind media source-interface GigabitEthernet0/1

dial-peer voice 555 voip

description Incoming dial-peer for SIP Trunk

answer-address ....

incoming called-number .T

dtmf-relay rtp-nte h245-alphanumeric

codec g711ulaw

ip qos dscp cs5 media

ip qos dscp cs4 signaling

no vad

Hi Matt,

Glad to hear that. 12.4 mainline isn't very good code for CUBE, especially if you're using SIP. There have been large improvements in the SIP stack since 12.4 mainline.

-nick

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: