cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
4925
Views
5
Helpful
10
Replies

Media flow-through not working on CUBE

Maxim Denisov
Level 3
Level 3

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

10 Replies 10

Paul McGurn
Level 6
Level 6

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?

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

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?

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.

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

Please rate all useful posts

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

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.

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

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.

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

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: