Hoping to get some suggestions on a problem I encounter when CUBE is configured for media flow-through (default behaviour) for an OTT SIP trunk. The problem is simple - when I make either an inbound/outbound call I get no audio in either direction. If I adjust the CUBE configuration such that media (RTP) flows around the CUBE router (ie RTP flows directly between the Cisco IP Phone and the ISP SBC) I get full duplex audio. This is done simply via the media flow-around command when in 'voice service voip' section.
Running a packet capture on the CUBE router, shows that RTP is received from the ISP SBC by the CUBE router but CUBE does not re-transmit the RTP packet to the Cisco IP Phone. The same behaviour happens in the other direction, namely RTP is received from the Cisco IP Phone, but CUBE does no re-transmit the RTP packet to the ISP. This behaviour lines up with what I see on the Cisco IP Phone if I look at call statistics I can see that the Tx packet count is increasing whilst the Rx count remains at 0.
In both instances working and not working, the same codec is negotiated G711alaw. The CUBE router sits behind a Cisco 887 router which is connected to the Internet via ADSL2+ doing NAT + firewall. The configuration of the firewall has been adjust to allow the extension to successful register with the ISP SBC and allow RTP to flow through the firewall. The CUBE router has DSP resources and has been configured to provide MTP and transcoding resources if required in CUCM.
Details as follows:
Cisco 2901V running IOS 154-3.M8 (10.1.1.7) - CUBE
Cisco 887 running IOS 154-3.M8 (10.1.1.1) - default gateway
Cisco IP Phone 8945 running SIP894x.9-4-2SR3-1 (10.1.1.55)
CUCM v11.01 (192.168.1.230)
ISP SBC (220.127.116.11)
CUBE snippet configuration
voice service voip
allow-connections h323 to h323
allow-connections h323 to sip
allow-connections sip to h323
allow-connections sip to sip
no supplementary-service sip moved-temporarily
no supplementary-service sip refer
fax protocol t38 version 0 ls-redundancy 0 hs-redundancy 0 fallback none
bind control source-interface GigabitEthernet0/0
bind media source-interface GigabitEthernet0/0
pass-thru content sdp
ip address 10.1.1.7 255.255.255.0
no ip route-cache
no mop enabled
dsp services dspfarm
voice class codec 1
codec preference 1 transparent
codec preference 2 g711alaw
codec preference 3 g711ulaw
codec preference 4 ilbc
timer receive-rtp 1200
sccp ccm group 1
bind interface GigabitEthernet0/0
associate ccm 1 priority 1
associate profile 2 register CLARK_MTP
dspfarm profile 2 transcode
maximum sessions 1
associate application SCCP
credentials number XXXXXXXXXX username YYYYY password ZZZZ realm A.B.C.D
authentication username YYYYY password ZZZZ realm A.B.C.D
retry invite 2
retry response 3
retry bye 3
retry prack 6
retry register 3
timers expires 300000
timers connect 100
registrar dns:A.B.C.D expires 3600
Any suggestions would be greatly appreciated.
Solved! Go to Solution.
Thanks for your suggestion, I removed both the stun and anti-trombone configuration commands from my configuration, changing the media flow from flow-around to flow-through but this did not rectify the problem (ie no audio in either direction).
One thing I forgot to mention in my original post, when the call is up and I issue #show voip rtp connections, the CUBE router shows two active RTP call legs (see below, note Cisco IP Phone in question for this test was 192.168.1.249) yet the packet capture shows RTP not being sent by CUBE.
VoIP RTP Port Usage Information:
Max Ports Available: 8091, Ports Reserved: 101, Ports in Use: 2
Port range not configured, Min: 16384, Max: 32767
Ports Ports Ports
Media-Address Range Available Reserved In-use
Default Address-Range 8091 101 2
VoIP RTP active connections :
No. CallId dstCallId LocalRTP RmtRTP LocalIP RemoteIP
1 68 69 16388 19582 10.1.1.7 18.104.22.168
2 69 68 16390 17582 10.1.1.7 192.168.1.249
Found 2 active RTP connections
I did the following debug on the CUBE router (debug attached as tar), thinking as my problem is RTP related and not signalling this would capture a fair amount of information.
debug voip rtp all
debug ip icmp
It all looks reasonable from what I can tell. The message 'SIP: Trying to parse unsupported attribute at media level' received four times relates to the unsupported media attribute received in the INVITE+SDP by the Broadsoft soft switch (22.214.171.124) and is harmless from what I have read.
a=bsoft: 1 image udptl t38
I don't know what conditions CUBE needs to meet in order to Tx RTP packets when doing media flow-through. The fact that RTP flows fine when I use media flow-around to me suggests the underlying network is ok?
Thanks for your suggestion - that was something I also thought might be causing the problem but had already ruled it out earlier by explicitly adding both the signalling and media interfaces to the dial peers as well as being present globally. Eg for dial-peer ISP to CUBE:
dial-peer voice 1 voip
description INBOUND PSTN to CUBE
translation-profile incoming INBOUND-SIP
session protocol sipv2
session target dns:XXX.YYY.ZZZ
incoming called-number 08627029..
voice-class codec 1
voice-class sip bind control source-interface GigabitEthernet0/0
voice-class sip bind media source-interface GigabitEthernet0/0
I thought perhaps that for media-flow-around that maybe you have to configure two interfaces - one ingress (LAN) one egress (ISP) but reading around there are other people who have got CUBE working using media-flow-through (default) with a single interface (https://supportforums.cisco.com/t5/ip-telephony/cube-with-one-interface-ip/td-p/3177869). However there are other posts where two interfaces were used (https://supportforums.cisco.com/t5/collaboration-voice-and-video/cube-sip-media-and-signalling-binding-to-an-interface/ba-p/3107153). I haven't really been able to nail down under which deployment scenarios a single interface would be preferred to two interfaces or vice-versa.
I think I will try two interfaces and see if this resolves the problem. Will advise outcome