Trusted Relay Point (TRP) and QoS for Softphones

Call Control and Media Channels

Whether you are using H.323, MGCP, SIP, or SCCP a typical voice or video call is comprised of a call setup transaction (typically called call control) and (if all is well with the world) a set of media streams carrying the voice or video data.  With MGCP, SIP, and SCCP the call control channel is using TCP or UDP and one or two “well known” ports.  With H.323, the initial call setup uses a well known port but the capabilities exchange can use any port in the ephemeral range.

The media channel (RTP) uses UDP for the transport layer and usually falls within a wide range of ports.  Some vendors or applications allow administrators to customize the port ranges while others do not.  Cisco hard phones use a specific, non-customizable range while their softphones (like CIPC) can be modified to use a more narrow range.

The Problem in a Nutshell

Any respectable unified communications network design is going to attempt a logical separation of voice and data networks across the physical infrastructure.  Which is to say, voice access devices will be logically separated (via VLANs) from data access devices.  Voice services will also be logically separated from data services and should also be logically separated from voice access devices.  I also prefer to logically separate call control, media providers, and voice applications.  Mainly for security purposes but also because the traffic profiles tend to be different in a well-designed UC architecture (a topic for another day to be sure).

So, you go through all of this logical separation with both security and QoS in mind.  Just when you think you have it under control, someone asks: “can I provide QoS for my soft phones?”.   If all you have in your toolkit are QoS ACLs and VLANs then the answer is “not really”.  Or, I should say, not reliably.  While you could use a “trust” model and allow the PCs to mark traffic (assuming the OS allows this), you are really counting on a lot of people to not screw things up.  You could try to use a model where you mark traffic based on port ranges but this isn’t going to be real reliable.  Further, if the approach chosen is not properly executed or maintained not only could you fail to provide QoS protection to the soft phone applications but you could have a negative impact on the larger user base – hard phones.  The negative impact would come in the form of some non-UC application on the PC getting QoS treatment that is reserved for voice applications.  Maybe some UDP file transfer of a large file or Johny playing Suzie’s iTunes library over the network. 

Trusted Relay Point (TRP)

I won’t pretend this is the answer to all of our problems but it could be a component of the solution .  It really depends on what type of QoS model you wish to employ and what applications you have deployed in your UC solution.  TRP is a Cisco concept.  It only applies to voice media at the present time and it requires Cisco Unified Communications Manager (CUCM) 7.0 or later.

TRP is a software function that uses a Media Termination Point (MTP) provider and is dynamically inserted in a call flow by the CUCM call processing agent.  Media streams are “anchored” to the TRP/MTP which can bridge or “stitch” media streams together.  Two applications of this functionality are QoS enforcement and trusted VLAN traversal (a security application that is not discussed herein).  For QoS enforcement this function can be applied not only to software based UC clients (e.g. CIPC, X-Lite, other soft phones), but to any endpoint that is registered to the CUCM cluster.

An overview of the function is provided in the following figure.

As shown in this figure, a soft phone client still communicates directly to the call processing agent for call setup (1). QoS for the call setup can rely on trust policies or marking/re-marking policies.  Since this call setup channel is to a specific set of addresses (CUCM call processing agents) on a specific port (e.g. TCP/2000 or UDP/5060) this isn’t too much of a problem (IMO anyway) and can be handled with QoS ACLs easily enough.

Assuming that the call setup is successful, then the media stream between the soft phone client is anchored to the TRP device (2).  Further, the media stream for the remote call party is also anchored to the TRP device (3) which is responsible for stitching the two media streams together.  This allows the admins to have a deterministic network path for media streams to/from PC based soft phones in a data (untrusted) network.

To further illustrate how the TRP is inserted into the media stream, consider the following call flow.

Breakdown of Call Flow:

1. A soft phone user initiates a call to a station line registered on the CUCM cluster. The remote station rings and the calling station hears a ring-back (alerting) tone.
2. The remote party answers
3. At this point the CUCM begins setting up the media channels.  The CUCM  determines that a TRP is required for one of the devices and will start setting up a media channel to the soft phone and hard phone.  The first step is to query the various endpoints to determine which IP address and port number they expect to receive the RTP stream.
4. At the same time, the CUCM must setup two separate media channels to the TRP device.  One for the soft phone and one for the hard phone.
5. Once the CUCM identifies the preferred IP addresses and port numbers each party prefers, an instruction is sent to the appropriate stations instructing them where to send their RTP streams and which destination ports to use.
6. At this point a talk path is established between the two endpoints with media streams from each endpoint anchored on the TRP.

How Does this Solve the Problem

Again, it isn’t a solution to all scenarios but can play a critical role in the overall solution.  The benefit is the network administrator can ensure that QoS ACLs mark DSCP values based on the assumption that RTP streams will flow from the desktop soft phones to/from the TRP devices.  The TRP devices can be centrally located or distributed across the LAN/MAN/WAN.  The assignment of a TRP provider is controlled by the telecommunication admin via the Media Resource Management configurations on the CUCM.  So, leveraging a TRP solution allows for more centralized control than leveraging desktop configurations.  I am sure folks will disagree on that point, which is fine.

Another benefit is that when a TRP is assigned to a device, any media stream to/from that device may traverse the TRP.  Which means that QoS markings can be applied for soft phone_to_soft phone calls, gateway calls, voicemail calls, e911 calls, contact center calls, etc.  Further, the telecomm admin can also enforce a policy whereby if a TRP is not available the call is not permitted (this is a service wide parameter).

Considerations

TRP leverages a software MTP in IOS. The IOS MTP allows configuration of G.711 and G.729a/ab/b codecs. You can also configure pass-through or “stream pass through”. I have done testing where video can also pass-through the TRP. I used a CUVA client and a 9951 station for my tests. While this proves it is technically possible to have video traverse the TRP, I have not attempted to ascertain if there is an impact on video quality.

IOS limits the maximum configurable sessions to 1000 individual streams. Since each call takes up two streams (minimum, see below) then that would equate to 500 calls. This limit is a hard limit programmed into IOS and does not mean that all platforms can provide this capacity level. I haven’t found a clear sizing reference for TRP or IOS MTP. The Cisco SRND states that 1000 G711 streams generates approximately 10 Mbytes of traffic. They follow this up with the general guideline that “Cisco ISR G2s and ASR routers can support significantly higher numbers”. Suggesting, that you size your router for packet performance. I have pondered the alternate idea of sizing a TRP gateway in a manner similar to CUBE with SW-MTP.

When two stations that are both configured to use a TRP are communicating with each other, a funny thing happens.  In my testing I saw that when two phones were configured with TRP that there were four audio streams terminated on the TRP.  One to each of the end points and two streams to itself.  The same can be seen if two separate TRPs are introduced to a call.  Each TRP will show two media streams.  One to their respective phones and one stream to the other TRP.  This seems like a potential scalability problem and leads me to recommend dedicated TRP resources for large campus environments with lots of soft phone use.  While I would still lean to leveraging multi-purpose devices at WAN sites (to minimize cost).   I hope Cisco adds another layer of intelligence to the TRP solution that allows the CUCM to avoid doubling up on streams.

It may be wise to look at Device Mobility along with a TRP design if the bulk of your soft phone user base is running on laptop devices which may roam to different sites, campuses, or buildings.

Conclusions and Closing Thoughts

TRP is a feature that can be leveraged to provide a more deterministic QoS solution for PC based soft phones and is worth considering in a CUCM environment.   Placement of TRP devices, whether they are deployed in a centralized or distributed fashion, and whether TRP providers are single- or multi-purpose providers should all be considered as part of the overall design.

TRP can also be used for trusted VLAN traversal which plays a significant role in providing proper voice security.  The VLAN traversal functionality is not discussed in this blog but is something I plan on adding at a later date.