Categories

CUC (6) CUCM (26) Jabber (6) Python (2) Routing (3) Solarwinds Orion NPM (4) switching (1) Video (6) voice (2)

Wednesday, 21 December 2016

Cisco SIP CUBE Media Flow Through v. Media Flow Around

Whoever has ever set up a Cisco CUBE might know that these suckers can be set up as either "Media Flow Through" and "Media Flow Around". If you have never set up a CUBE, or were simply not aware that this option even existed or you don't know what the difference is; sit tight and let me do the talking.

The terms Media flow around and Media Flow through, are refering  to, you have guessed it; Media, so Video and Voice. In protocol terms; RTP and H264 (for video for example).


With flow around, the CUBE sits in the signalling path between the calling and called end point. The signalling is aimed at setting up an RTP stream directly between the two endpoints. and once established, the CUBE is no longer required unless additional signalling is required.



Fig 1. - Cisco CUBE Media flow around

With Media Flow through, you guessed it, the RTP stream is set up through the CUBE. This means, that the RTP stream is broken up in to parts: from phone A to CUBE, and from CUBE to phone B.  This means that all RTP packets flow through the CUBE.


How to configure this?

Easy; go into voice service voip on your CUBE:

voipgw(conf-voi-serv)#media ?
  flow-around     The media is to flow around the gateway
  flow-through    The media is to flow through the gateway

The default is media flow through, and once configure will not be visible under voice service voip if you do a show run
  
How would I decide whats best?

Read my lips; there are no silver bullets. So the answer is; it depends. If you are not worried by what the CUBE will use, then, fine, let the default do its work, which is flow through.  Flow through allows you to hide your IP addresses of your phones/endpoints, because your only your CUBE will be announced in the SIP signalling towards your SIP provider. Of course this means, that in terms of routing, your provider will only need to be able to have connectivity to your CUBE's IP address. With flow around this is a whole different matter, because your SIP provider will need to be able to route to each and every phone/endpoint's IP address. This requirement might not suite everyone, or might simply not be possible for a number of reasons.

The second item you need to be aware of when choosing between flow through or around, is bandwidth.  If you for instance deployed a centralised CUBE in on of your data centers, and you use flow through ALL the RTP streams will go through the WAN link to the CUBE and will go out again to be terminated on the actual phone/endpoint.  With flow around this is not the case, because when an external caller calls a phone in branch A, the SIP signalling will be dealt with by the CUBE and the negotiated RTP stream that is part of that call, will be between your SIP provider and the endpoint in Branch A. So the RTP stream will NOT flow through the WAN link of the data centre where the CUBE is at.  You will also keep this in mind when designing your QoS policies. Always keep in the back of your head how RTP actually traverses your WAN, in order for it to connect to the PSTN.


One other reason to use flow through is that you might want to use the CUBE's ability to transcode CODECS, through its Local Transcoding Interface  (LTI).

http://www.cisco.com/c/en/us/support/docs/voice-unified-communications/unified-border-element/115018-configure-cube-lti.html

One last that is worth mentioning, is the added complexity of flow around in terms of SIP 'signalling'. With flow around, SIP is more complex, flow around causes re-invites for instance to signal the phone's IP address. Whereas, flow through does not require this.


How to verify how my CUBE deal with media flow?

There are a few things you can do to check how media flow through your CUBE or around your CUBE. You can debug ccsip messages. This will tell you the contents of your SIP SDP , which will contain an IP address of where the RTP stream should be terminated. This could be the IP address of the CUBE itself (in which case you will most likely be using flow through) or the IP address of a phone/end point in which case your CUBE will most likely be using flow around.  So basically what you need to look at, is the SDP that the CUBE sends TO your SIP provider. If it contains the IP address of your CUBE, its flow though, if it is the IP address of an endpoint, flow around will be attempted.

SDP example below, check the IP address of the RTP connection  c=  



There is an easier way to verify, make a phone call across the CUBE in question, keep the call up and go to CUCM and browse to the phone's IP once you have found the phone that has the current call. Now go to stream 1, for example:




These streaming statistics will tell you straight away between which two IP addresses the RTP stream is set up, if the CUBE's IP address if not in there, then you are definitely using flow around.

Also you could issue the following command on your CUBE:

show voip rtp connections

This will show you the IP addresses of the call leg(s).


This pretty much wraps it up, keep your comments coming.

2 comments:

  1. "One last that is worth mentioning, is the added complexity of flow around in terms of SIP 'signalling'. With flow around, SIP is more complex, flow around causes re-invites for instance to signal the phone's IP address. Whereas, flow through does not require this."

    Could you elaborate more? In what circumstance flow around causes re-invite as such? Is that any references available for further understanding (I can't find it from Cisco books I have).

    ReplyDelete
  2. The reason for this is, that when you have an inbound call into a cube that does flow around and you use SIP early offer. than the cube signals back with its own IP address to terminate the RTP stream. then it signals the cucm and obtains the IP address of the phone, so it need to go back to the caller thru a re-invite containing an SDP with the IP address of the phone to terminate the RTP stream on

    ReplyDelete