CUBE RTP problem - media flow-around works media flow-through doesn't

[brmadsen77]

Hi All,

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 (202.147.134.21)

CUBE snippet configuration

voice service voip

rtcp keepalive

mode border-element

media flow-around

media anti-trombone

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

stun

sip

bind control source-interface GigabitEthernet0/0

bind media source-interface GigabitEthernet0/0

nat auto

no update-callerid

midcall-signaling passthru

pass-thru content sdp

!

interface GigabitEthernet0/0

ip address 10.1.1.7 255.255.255.0

no ip route-cache

duplex auto

speed auto

no mop enabled

!

voice-card 0

dspfarm

dsp services dspfarm

!

voice class codec 1

codec preference 1 transparent

codec preference 2 g711alaw

codec preference 3 g711ulaw

codec preference 4 ilbc

!

gateway

media-inactivity-criteria all

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

codec g729abr8

codec g729ar8

codec g711alaw

codec g711ulaw

codec pass-through

codec ilbc

maximum sessions 1

associate application SCCP

!

sip-ua

credentials number XXXXXXXXXX username YYYYY password ZZZZ realm A.B.C.D

authentication username YYYYY password ZZZZ realm A.B.C.D

no remote-party-id

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

sip-server dns:A.B.C.D

connection-reuse

!

Any suggestions would be greatly appreciated.

Kind Regards

Ben

[Mohammed al Baqari]

Remove anti tromboning and stun commands and test

[brmadsen77]

Hi Mohammed,

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                                    202.147.134.21
2     69         68         16390    17582  10.1.1.7                                    192.168.1.249
Found 2 active RTP connections

Kind Regards

Ben

[brmadsen77]

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 (202.147.134.21) and is harmless from what I have read.

a=ptime:20

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?

[MOHIT SINGH]

Can you test by moving the SIP "Bind media.." command under the specific dial peers (to CUBE and CUCM) with correct source interface from voice service voip? May be the media is using wrong interface to send RTP

[brmadsen77]

Hi Mohit,

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
 b2bua
 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
 dtmf-relay rtp-nte
 no vad
!

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

[MOHIT SINGH · Accepted solution]

If you want to use single interface then make sure the network routing is correctly configured so that any traffic coming in from IP phone is routed to ISP and any traffic coming from ISP can be routed to IP phone using same interface.