Media flow-through not working on CUBE

[Maxim Denisov]

Hello,

There is a CUBE (12.4(25c)) with SIP trunk to telco on public IP. CUCM is connected to CUBE with SIP trunk to private IP on loopback interface. Though the default behavior for media to flow through in voice service voip and dial-peer configuration, in "show call history" I see the MediaSetting=flow-around. This behaviour haven't changed after I explicitly set voice class with media flow-through on terminating dial-peer.

Is there any restriction for media flow-through?

Regards,

Maxim

[Paul McGurn]

I have a 12.4 CUBE set to trunk to public SIP and internal CUCM, but not binding to a loopback address, and I don't see what you're seeing.  Could you post a config snippet of the dial peers and interfaces?

[Maxim Denisov]

Hi Paul,

There are several other working CUBEs where SIP is bound to interface, looks like the problem present if telco trunk connected to WAN interface with public IP and UCM connects to loopback interface with private IP. In show call history voice I see the MediaSetting=flow-around for this call, on IP phone's RTP stream statistics I see CUBE WAN interface IP. Since WAN interface IP is not advertised on my internal routing, IP phone has no route to it.

Is this normal behavior?

Here is my dial-peers:

dial-peer voice 100 voip
 permission term
 description #-- Termination to Intra
 translation-profile outgoing TO-INTRA
 huntstop
 destination-pattern +.T
 voice-class media 1
 session protocol sipv2
 session target ipv4:91.193.224.14
 dtmf-relay rtp-nte digit-drop
 codec g711alaw
 no vad
KRY-GW1#sh run | sec dial-peer voice 20  
dial-peer voice 20 voip
 permission orig
 description #-- Incoming calls from internal network
 translation-profile incoming DP-FROM-INTERNAL
 huntstop
 incoming called-number ^DDACCC#.T
 codec g711alaw
 no vad
KRY-GW1#sh run | sec voice class media
voice class media 1
 media flow-through

Regards,

Maxim

[Paul McGurn]

I'm not sure if it's normal.  I've never set CUBE-related trunks up with a loopback.  Have you tried using a physical interface with an internal IP, or do you have port limitations forcing you to use the loopback?

[Maxim Denisov]

Just tried setting LAN interface for SIP trunk - CUBE chooses WAN IP for RTP termination and still shows media flow-around in show call history. RTP actually flows through, looks like CUBE can't set different IPs for RTP on incoming and outgoing leg.

[Ayodeji Okanlawon]

Maxim,

We have CUBE configured with the same interface configured for sip binding to both CUCM and SIP provider. This IP is a private ip within the provider's cloud. We get flow-through on thsi setting..

show call histroy media

SessionProtocol=sipv2

ProtocolCallId=25c75400-916cb1-c283d-e28690a@10.106.80.14

HiWaterPlayoutDelay=0 ms

LoWaterPlayoutDelay=0 ms

ReceiveDelay=0 ms

LostPackets=0

EarlyPackets=0

LatePackets=0

VAD = disabled

CoderTypeRate=g729r8

CodecBytes=20

cvVoIPCallHistoryIcpif=0

MediaSetting=flow-through

Please rate all useful posts

"'Nature is too thin a screen, the glory of the omnipresent God bursts through it everywhere"-Ralph Waldo Emerson

[Maxim Denisov]

Aokanlawon,

There are other CUBEs where SIP explictly bound to one interface with voice service voip -> sip configuration, this scenario works well. There is a site with CUBE connected to telco via public IP and telco has route to WAN IP only. When I call to destination routed to this telco from another site RTP goes to CUBE WAN IP, not telco IP. So actualy media flows through but I need it to go to private IP on CUBE loopback where signalling comes.

Regards,

Maxim

[Paul McGurn]

Here's what I have for DP's on my CUBe (2851 running 12.4).

dial-peer voice 300 voip

description ***Inbound SIP DID from carrier to CUCM Sub***

preference 1  //this is only needed if you have multiple DP's that overlap matching criteria

destination-pattern +.+$  //match all E.164 calls

voice-class codec 1

voice-class sip early-offer forced

session protocol sipv2

session target ipv4:

dtmf-relay rtp-nte

!

dial-peer voice 400 voip

description *** Outbound dialing via carrier SIP ***

preference 1  //only required if you have multiple DP's that have teh same matching criteria

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

voice-class codec 1

voice-class sip early-offer forced

session protocol sipv2

session target ipv4:

dtmf-relay rtp-nte

!

voice service voip

allow-connections sip to sip

fax protocol cisco

sip

  header-passing error-passthru

  early-offer forced

  midcall-signaling passthru

  no call service stop

voice class codec 1

codec preference 1 g711ulaw

codec preference 2 g729br8

First dial-peer sends SIP signaling and media to our CUCM instance.  Second corresponds to a SIP trunk configured in CUCM (that points at the CUBE LAN interface).  When I debug calls to the log, both signaling and media are pointed at the CUCM, and voice traffic flows as I'd expect.  SIP carrier has no path to CUCM, and CUCM has no path to the carrier.  I haven't debugged at the phone level itself, but since signaling works, and audio wouldn't relay through the CUCM (that's the whole point of the CUBE in this build-out), I'm assuming media passthrough is working as intended.

[Maxim Denisov]

Paul,

In my scenario signaling works as intended. RTP should work too if CUBE WAN IP would be advertised in OSPF but I can't advertise it since this is the only public IP and I need a tunnel to this site.

I just found strange behavior - CUBE can't use different local IPs for RTP on different legs and shows media flow-around though actualy it flows through but with IP on one leg different from signaling IP. I don't know is this a bug or CUBE is not intended to work this way.

I have requested a new public network from ISP. I will bind all SIP to one of it's IPs and will advertise it to internal routing.

Regards,

Maxim

[Paul McGurn]

Ah, now I follow you.  I think ours works because I bound SIP to the internal (physical) interface.  The traffic from the provider is coming in over WAN (MPLS), and then routed to that same interface.  In your scenario, your CUBE is directly connected to the internet, whereas ours routes through a layer 3 switch.  That was really the difference there, and sorry for misreading your original note regarding the difference in our environments.

[etamminga]

voice service voip

sip

address-hiding

This is all I do to make the cube originator/terminator for media.

Regards,

Erik

Sent from Cisco Technical Support iPad App