Cisco Unified Border Element CUBE
In this blog I am displaying examples of protocol interworking performed by Cisco Unified Border Element and then display the output with some “show” CLI commands.
The lab setting we are going to use is as follows:
In this topology, all the following routers act as Cisco Unified Border Elements:
- the HQ GW
- the emulated PSTN
- the MongiShop router
In case you need a refresher on H323 configuration or packet analysis, then please read this post.
Protocol interworking example 1: H.323 to SIP and SIP to H.323
The HQ Cisco Unified Border Element receives a H.323 call leg from CUCM, since I configured it as a H.323 gateway on CUCM.
To reach MongiShop phones, I configured a dial peer 5000 on HQ CUBE and with session protocol SIP.
We allow H.323 to SIP interworking:
At the PSTN router, the inbound dial-peer 9999 uses session protocol SIP. The outbound dial peer towards MongiShop uses a H.323 dial peer.
We allow SIP to H.323 interworking on PSTN router because the outbound matched dial peer for a call to MongiShop uses H.323.
On the MongiShop router, the inbound matched dial peer must be of session protocol H.323:
The call from a phone in HQ to MongiShop succeeds:
Protocol interworking example 2: H.323 Slow Start to H.323 Fast Start
- On HQ CUBE:
- the inbound matched dial peer has protocol H.323
- I configured H.323 Slow Start at the voice service voip
- I added the allow-connection statement to allow interworking from H.323 to H.323
- On Emulated PSTN CUBE:
- I configured H.323 Slow Start too
- I added the allow-connection statement to allow interworking from H.323 to H.323
- On MongiShop:
- I configured a voice class H323 that sets H.323 to Fast Start mode
- I configured the inbound dial peer with the voice class H.323
The call succeeds.
Similar results can be obtained with call start interwork, whether at the voice service voip level or voice class level.
CUBE codec filtering and codec transparent
There is no special command for codec filtering on CUBE; whenever a codec -or a codec preference list- is configured on CUBE, then it is called codec filtering.
Codec filtering is NOT configuring a codec that is different from the codecs on the attached VOIP networks. We’ll see below how this affects the call.
Let’s take router HQ and router Emulated-PSTN which has attached to it a couple of lines. We will examine the codec filtering feature on the path from HQ to a national number.
When we make a voip call from HQ to PSTN, the call is connected:
And we can determine the codec used in RTP flows, with “show call active voice brief
G.729r8 is used between the HQ phone and the emulated-PSTN phone. Let’s make the HQ router (which is the CUBE) configured with a totally different codec than the VOIP networks: codec G.728 at the outbound dial peer:
And we make the call again. As soon as I lift the handset on Emulated-PSTN phone, the call is disrupted, but the calling party phone at HQ still rings. Weird.
The correct way to do codec filtering is:
- either to define a codec that is supported by the inbound call leg and another one that is supported by the outbound call leg, or
- to define a codec preference list which has common codecs with the inbound and outbound call legs.
Back to the example. Instead of having g728, I set the codec to transparent with the command codec transparent, under the outbound dial peer. And this tells the CUBE to “make peace not war” and let VOIP networks agree on a common codec. RTP flows are established correctly.
Show voip rtp connections
show voip rtp connections detail
Show cube calls all
show cube calls all detail
show call active voice compact
If you want to discover how to configure Cisco CUBE first hand, take a look at Pasha’s UCPros blog post.
Comments
Post a Comment