When it comes to the Cisco Unified Border Element (CUBE), things can get complicated quickly. We all know that CUBE is just an IOS routing device, with simple dial-peers configured in order to route calls from one destination to another.
However, there’s more to it than that, especially when it comes to video calls. That’s where I would like to set our focus for this blog. What are some of the ways to make a video call across CUBE? Or as some students might put it, how are we supposed to make a video call with CUBE in the way :-)?
First off, let’s examine a sample topology. In the below, we have three sites; HQ, SC, and BB, each with 9971 video phones. Both the HQ and BB sites are using CUCM as the call agent (CA) while SC is using the CUCME as the CA. Of course, we are going to try and examine what happens when we try to make a video call across the CUBE in this topology.
In order to connect to CUBE in the first place (from CUCM), we’ll need to configure SIP trunks, since after all, it is SIP that we’re using to make the connection. Given that the BB CUCM cluster already has its configuration in place, we should do this on the HQ CUCM cluster. The below screenshots detail the configuration.
We should remember to add our newly created SIP trunk to a Route Group and a Route List so any eventual Route Patterns that we create in the system can use the SIP Trunk. After this is complete, we can create route patterns pointing toward the DNs at both SC (43002) and BB (689220420).
At this point, we are able to start our CUBE (R1) configuration. First of all, you may have noticed that in the above, the destination is pointing towards the IP address 10.10.1.1. This corresponds to the Loopback 0 address of R1, which we must configure to terminate SIP signaling. This can be configured globally under voice service voip, or at a dial-peer level. In this case, we will add it to the global SIP configuration on the CUBE.
The above configuration first addresses the Toll Fraud Prevention feature, which blocks communication with unknown devices that attempt to communicate with the router. Our best course of action here is to turn it off by issuing the command no ip address trusted authenticate. This opens up the router for any device to successfully connect, which is what we want for the CCIE Collaboration Lab (unless explicitly stated otherwise), even though this isn’t the greatest idea in the real world. You should do this for every IOS device that routes calls. For more on that feature, check out THIS LINK.
Next, we need to enable the router to act as a CUBE by issuing the command mode border-element. This will allow the use of the different “media” commands available when configuring CUBE. Of course, once this command is entered, we will need to reload the router for it to take effect. The allow-connections commands configure the router to accept connections using the different protocols outlined above. This is another set of commands that we can basically copy and paste to every IOS device in the network that is performing call routing. Next, we are at the point where we can bind the Loopback 0 address to the global SIP process on the router. As you can see, this is done for both control and media traffic.
Next, we can start to configure the dial-peers to support calling between systems. Of course we need both inbound and outbound dial-peers for each connection. In the below configuration, we have two dial peers for HQ (for PUB/SUB redundancy) that will be selected as both inbound and outbound dial peers for calls destined toward HQ. We also have dial-peers for the SC CUCME and the BB CUCM cluster. On each dial-peer, we have configured the codec to “transparent”, so the audio codec can be negotiated between each endpoint. This means that whatever codec is offered from one end of the call is forwarded exactly as received to the other endpoint.
With this configuration in place, we are now ready to try a video call. Before we do that however, let’s run a quick refresher on SIP signaling. In a typical SIP call, you might see something like the following diagram. In this example, User A calls User B via SIP.
The above is an example of a “delayed offer” SIP call, where the SDP is negotiated after the initial signaling has taken place. In an “early offer” SIP call, we would see the SDP parameters in the original INVITE message.
Now, let’s place a call from HQ Phone 1 (21001) to the BB PSTN Phone (689220420). We can see that the audio goes through successfully, but video is only being received on the HQ Phone 1 screen. The BB Phone shows a blank screen instead of video. This means that the BB phone is not receiving any video from HQ, but the HQ Phone is receiving the video stream from BB. To troubleshoot, let’s run a debug ccsip messages on the CUBE router.
We can see from the initial SIP INVITE sent from CUBE to BB that this is a “delayed offer” type of call, since the SIP message does not contain an SDP.
Since this is the case, we should expect to receive an SDP in the “200 OK” message from the BB CUCM server when the phone answers the call. We can see that this is indeed the case.
There are a couple of things that we can glean from this output right off the bat. First of all, we know that the BB Phone would like to start a video session, as seen in the “m=video” line in the debug output. This defines the UDP port that should be used for the connection along with the codec and payload types that are supported. The next thing we should notice is the definition of those payload types. Remember, H.264 uses a dynamic payload type, which could be anything between 96 and 127. See THIS LINK for more detail. In this case, we see that the BB CUCM cluster has offered to use either payload type 126 or 97. Next, we should expect to see the CUBE pass this “all-important” SDP message to the HQ CUCM cluster.
In this case, we see the SDP message being sent to the HQ CUCM, but we notice that the RTP payload type has changed. CUBE is now actually trying to negotiate an RTP payload type of 119 with the HQ CUCM cluster, even though it received possible payload types of 126 and 97 from the BB CUCM cluster. What CUBE has offered to the HQ CUCM cluster is still within the realm of possibility, since 119 is a possible dynamic payload type. However, why didn’t CUBE just pass along the video codecs that were offered by the BB CUCM cluster? We will look at that in a bit.
The next message that we see on CUBE is the ACK from the HQ CUCM in response to the “200 OK” message sent from CUBE. In the message, we see that HQ actually offers to communicate using RTP payload type 97. This is because 97 and 126 are the values used by 9971 phones when communicating using the H.264 codec. The phone won’t use the offered RTP payload type of 119 for video reception because it is not programmed to do so.
At this point, CUBE is simply going to forward the ACK message along to the BB CUCM cluster. The BB CUCM cluster will, of course, accept this information and begin to communicate using the information it received from CUBE.
Let’s review what just happened. The call leg between HQ and CUBE has negotiated two different payload types. Since HQ received an offer from CUBE to use RTP payload type 119, HQ will use that type send video. However, since HQ sent RTP payload type 97 to CUBE in the ACK message, it will be using that payload type to receive video. From the perspective of the BB phone, this negotiation resulted in using RTP payload type 97 for both sending and receiving video. Based on these facts, we can see that the BB phone does not receive video because HQ is sending using RTP payload type 119, while BB is expecting to receive video using RTP payload type 97. The HQ phone is receiving video using RTP payload type 97, which is what the BB phone is using to send video.
So how do we fix this problem? Well, there are actually a few ways that we can pull it off. First, we have to realize that we were originally trying to negotiate the video call directly with the CUBE. This is just one of our architectural options when configuring this call flow. We can either negotiate the codec between call legs (HQ to CUBE and CUBE to BB), or we can allow the CUBE to act as a “middle man” and pass the SDP information through to each endpoint. Essentially, the latter option means that we are negotiating directly between endpoints (similar to the codec transparent command under the dial-peer for audio codecs). Let’s take a look at the first option—attempting to negotiate the video call with the CUBE from each endpoint.
We will need to somehow change the way that the CUBE offers the RTP payload type. We saw in the previous example that it offered RTP payload type 119 without success. If we are somehow able to change that, we might be in business. So how can we make the change? If you think about how IOS routes calls, you might think that the first place you should look is the dial-peer—and you would be right! If you run the command show dial-peer voice 689, you see a gigantic output with a lot of information about that specific dial-peer. Scroll to about the middle of that output and you will see a section labeled “RTP dynamic payload type values”. This is going to contain our answer. From the below output, you see that the H.264 codec is programmed to use the RTP payload type of 119 as defined in the dial-peer.
With this information, we now know that we should be able to change the payload type from 119 to 97 and everything should work. Not so fast—notice from the above command that RTP payload type 97 is already in use by something called “fax-ack”. So before we change the H.264 payload type to 97, we must modify the “fax-ack” payload type to another value. The Cisco documentation suggests that we use 111, but you can use whatever is not in use at the moment. See THIS LINK for more information,
Now let’s configure the dial-peer to use the correct payload type using the following commands.
Once the commands are successfully entered, we can run another debug ccsip messages to see what happened. Let’s check out the “200 OK” message that is being sent from CUBE toward the HQ CUCM cluster. That is originally where the H.264 codec was offered using RTP payload type 119. The output below shows that the CUBE is now offering payload type 97.
We have now successfully negotiated the codec between call legs (HQ to CUBE and CUBE to BB). There is still one more way to accomplish the same thing. If we remove the RTP payload commands from dial-peer 689 and instead use the command asymmetric payload full under the global SIP process on the CUBE, this will allow the SDP negotiation to take place as well. This allows CUBE to accept and send different payload types. Of course, when entered on a global level, this applies to every dial-peer on the system. You do, however, have the option to apply this on a specific dial-peer, if desired.
When making the test call, upon examining the “200 OK” message being sent by the CUBE toward the HQ CUCM cluster, we see that both payload types are now offered, even though the RTP payload type on the dial-peer is set to use 119. This, of course, results in a successful video call.
The last method we can use to successfully configure video calling through the CUBE is to simply let the endpoints negotiate the video codec without CUBE interfering at all. We can basically configure CUBE to forward whatever SDP messages it receives to the destination endpoint. Once again, we have the ability to perform this configuration on both a global and dial-peer level in the CUBE. The global command is called pass-thru content sdp and it is applied under the global SIP configuration under voice service voip. See the below snippet for the syntax.
When making the test call, upon examining the “200 OK” message being sent by the CUBE toward the HQ CUCM cluster, we see that both payload types are now offered, even though the RTP payload type on the dial-peer is set to use 119.
At this point, we basically see the same thing that happened when using the command asymmetric payload full. The CUBE offers both 126 and 97 as possible RTP payload types for the HQ CUCM to use when communicating with the BB Phone.
Just to summarize our findings here, we now know that there are three different ways to configure video calling across the CUBE. The first method involves negotiating the video codec directly on the dial-peer using the rtp payload-type commands. The second method also uses dial-peer negotiation, but accomplishes it using the asymmetric payload full command under the global SIP process on the CUBE. The third method basically takes the CUBE out of the equation altogether since it simply passes the SDP information from the sender to the receiver and vice versa. This can be accomplished using the pass-thru content sdp command.
A call across the CUBE will also work the same way when using CUCME as one of the endpoints. The only difference is that since CUCME is an IOS-based device, we’ll need to make a decision on what to do with the RTP payload type, in much the same way as it is done with CUBE. Once again, we can choose the method that we want to use and determine if that will resolve the issue of the dreaded blank video screen.
First, let’s actually set up our dial-peers on CUCME (R3) to communicate with HQ Phone 1 (21001) as well as accept inbound calls.
As you can see in the above, we are using the voice-class codec command as well as the dtmf-relay command. The latter refers to the method being used to exchange “user key presses”, or DTMF digits. In this case, we see that we have a wide range of options to choose from; RTP-NTE (RFC 2833, In-Band), SIP-NOTIFY (Out-of-Band), and SIP-KPML (Out-of-Band). By using this command, we are basically using all options available to us in order to negotiate with the far end. The voice-class codec command refers to a preference list already configured in the router to select the codec for the audio path. In the below case, we prefer to use G.711 if supported by the remote end. Otherwise, we can fall back to G.729.
We also have to configure the global voice settings on the router in a similar fashion to that of CUBE.
As you can see, we have copied the “toll fraud” and “allow connections” commands from CUBE. Also, we have bound the Vlan31 interface to the global SIP process for both control and media traffic. In this configuration, we can place our first test call and use the debug ccsip messages command on R3. Once again, we can see that in the “200 OK” message sent from R3 towards CUBE, we have the same problem; the RTP payload type being offered is 119.
Once again, since this is an IOS device, we can overcome this in one of three ways; change the payload type manually, allow asymmetric payloads, or allow the SDP header to pass through. The only difference here is that the pass-thru content sdp command tends to cause issues with SCCP phone signaling on CUCME, so it is recommended to use one of the other two methods available. The below debug verifies that either the asymmetric payload full or the rtp payload-type commands will fix the issue by sending an RTP payload type of 97.
I hope this has been helpful to all that are studying for the CCIE Collaboration lab exam. Please keep your eye out for many updates to come for both our workbooks and videos. Also, if you’re ever feeling like you need an extra push to get ready for the lab, are hitting roadblocks in your preparation, or just need some direction on how tackle the CCIE Collaboration Lab, give us a call and speak with an iPexpert Training Adviser about attending one of my bootcamps. My goal is to get you ready to pass this exam as quickly as possible!
Thanks again for reading and good luck in your preparation!
Andy Vassar
CCIE #22042 (Collaboration, Voice, R&S)
CCIE Collaboration Instructor – iPexpert, Inc.
About Andy:
Andy Vassar is a triple CCIE who passed the CCIE Routing & Switching lab in September 2008 and the CCIE Voice lab in September 2010. He then passed the CCIE Collaboration in May 2014. Andy also holds a Bachelors Degree in Network Engineering Technology from Purdue University in West Lafayette, Indiana.
Andy has been a part of the networking industry for over ten years, and has recently been focused on corporate voice & video (collaboration) network design, support, and implementation. While working for Cisco as a senior network engineer in Chicago, Andy had the opportunity to work with several highly-visible, large-scale clients where he designed, optimized, and trained various staff departments and employees on how to support their enterprise voice and video networks.
With nearly a decade of hands-on experience with Cisco technologies, as well as Cisco’s Collaboration hardware and application portfolio, Andy is leading iPexpert’s Next Generation CCIE Collaboration training and product development initiatives, and will be delivering live CCIE Collaboration Bootcamps in our newest office, right outside of Chicago.
