TR/87 (Technical Report 87) is an interesting off-shoot from SIP. In the most basic sense, it is used for remote call control between two SIP-based systems. If you have a SIP service somewhere in your network that needs to control a SIP entity somewhere else in your network, TR/87 can provide the glue. Unlike traditional PBX systems where intelligence is kept in one place (i.e. the PBX call server), SIP distributes intelligence and decision making throughout its network of devices and services. For example, there is no reason why two SIP phones can’t make calls, release calls, and even conference and transfer calls without anything between them other than an Ethernet connection. They have the smarts to do it all on their own.
Unlike the rest of SIP, TR/87 is not controlled by the Internet Engineering Taskforce (IETF) – the folks who create and manage all the protocols used to build the Internet. Instead, TR/87 is the product of the European Computer Manufacturers Association (ECMA). The ECMA are the folks who brought you telephony protocols such at ISDN and Q.931. The ECMA is also the owner of the Telephony Services Applications Programming Interface (TSAPI) which is an implementation of Computer Supported Telecommunications Applications (CSTA). I tell you this because by understanding the owners of a protocol, you get a feel for the intention and direction for that protocol. While the IETF concerns itself with the Internet and web-based protocols and services, the ECMA is firmly rooted in the world of traditional telephony.
Command and Status
TR/87 is fairly easy to understand if you think of it in terms of commands and status messages. You send TR/87 commands in order to make something happen. For instance, Make Call and Clear Connection are TR/87 commands used to make and release telephone calls. Status messages tell you when something has happened. The Delivered Event informs you that a call is ringing. The Established Event informs you that a call has been answered. The Connection Cleared Event informs you that a call has been released. Using command and status messages, TR/87 aware applications or services can force a SIP device to do just about anything that an actual user can do by pressing buttons or touching keys.
So, how is this accomplished with SIP? As you already know, SIP has a set of methods (SIP commands) and responses. Of interest to TR/87 is the SIP Info method. The SIP Info method is used to send in-session information. For example, the Info method has been used by some implementations to send DTMF (touch tones) for an active call. In TR/87, the Info method is used for both commands and status messages. There is no Invite to make a call, no 200 OK response when a call has been answered, and no Bye to end a call. Info methods do all of that in TR/87.
Of course, an Info method by itself isn’t enough. You need something else to describe exactly what this Info is trying to accomplish. TR/87 uses the SIP message body for that. Specifically, it uses an XML encoded message body to describe the command or status message. For instance, the following might be embedded in the body of an Info method used to answer an incoming call.
<?xml version=”1.0″ encoding=”UTF-8″?>
<AnswerCall xmlns=“http://www.ecma-international.org/standards/ecma-323/csta/ed3″>
<callToBeAnswered>
<callID>call-id:123456789, remote-tag=1222, local-tag=7777</callID>
<deviceID>sip:tom@domain.com</deviceID>
</callToBeAnswered>
</AnswerCall>
Similar XML encodings are used for releasing an active call, informing an application of an incoming call, etc. The TR/87 specification has XML encodings for every command and status message that it supports.
So, who uses TR/87? For one, it’s used when you connect a Microsoft Lync system to an Avaya PBX and you want to use a Lync client to remote control an Avaya telephone. TR/87 commands are sent from Lync telling the Avaya phone to do something (make a call, release a call, etc.) and TR/87 status messages are sent from the Avaya PBX (specifically the Application Enablement Server — AES) when something has happened (call is ringing, call has been released, etc.). TR/87 is also used by other SIP applications such as call recorders.
Lastly, the CSTA has defined five profiles for TR/87. A profile defines the extent an application will use TR/87. These levels are Minimal, Basic, Advanced, Conference, and Device Feature. A click-to-call application may only require the Minimal profile while a sophisticated soft phone will need the Device Feature profile. Clearly, the complexity increases as you move up the profile chain.
Well, that’s about it. Now, when you read that a product requires TR/87 I hope you have an understanding as to why. It wants to tell a SIP entity to do something, learn what a SIP entity is doing, or both.
Hello. I love your blog.
I’m working on an application that leverages UACSTA (TR-87) to send call control commands to Snom 710 phones. While the phone registers on port 5060, my application connects to the phone from port 50946 to send the INVITE/INFO requests. This works great on a private network, but when the phone is behind a firewall I’m not able to send the initial INVITE request to the phone to establish this connection. The SIP stack (registrar) and my application are running on the same machine. Is there any way I can make this configuration work without special firewall/NAT rules? Do STUN servers come into the mix?
Firewalls can play havoc on SIP. Is the Firewall messing with the INVITE or not passing it through?
Thank for sharing the information related to TR-87 commands and status
I have question here,
We have built (standard TR-87 spec) an application which talks to presence server through SIP with CSTA+xml.
For a SIP INFO request (MakeCall/ClearCall in Body) it receives 481 call does not exist response.
(For same call-ID, i could see the successful call before)
Please let me know, what could be the reason ? and any solution..
Thank you