03-05-2009 12:55 PM - edited 03-15-2019 04:39 PM
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.
03-05-2009 02:33 PM
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
03-05-2009 03:55 PM
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
!
03-05-2009 03:55 PM
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
!
03-05-2009 05:32 PM
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
03-06-2009 07:03 AM
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.
03-06-2009 09:40 AM
03-06-2009 10:54 AM
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.
03-06-2009 11:02 AM
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
03-06-2009 11:30 AM
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.
03-06-2009 12:01 PM
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
03-06-2009 02:29 PM
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-23F7704211978>
To:<9162765476>;tag=VPST506035226298539162765476>
Date: Fri, 06 Mar 2009 17:26:49 GMT
Call-ID: CF53CAFA-9AA11DE-9EFDB93C-9CC5A45E@216.206.210.35
Route:<216.82.224.202>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************
03-06-2009 02:53 PM
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
03-10-2009 01:56 PM
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
03-10-2009 03:26 PM
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
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