Posted: October 3rd, 2013 | Author:Michael | Filed under:MSPL | Tags:Lync Server SDK, MSPL, re-INVITE | 1 Comment »
In my previous article here at SIP Adventures, I introduced you to the work I am doing with smart speakers and IoT. Understanding SIP Re-INVITE DTMF and RFC 2833.
When handling Lync Server activity at a SIP level, it is often important to identify re-INVITE messages and ignore them or handle them differently. I recently found out about a better way of reliably identifying re-INVITEs than the ones I’ve recommended in the past, and wanted to share it here.
First, though, what is a re-INVITE? In Lync Server (and other SIP-based systems), communications sessions, represented by SIP dialogs, are kicked off with a SIP INVITE message. The INVITE typically contains some information about the conversation that is being initiated and the initiator’s preferences for how media is transmitted. If the target user answers, a response is sent back accepting the INVITE and containing more media information. This back-and-forth exchange of media transmission preferences, which is known as the “media negotiation” or “offer-answer” process, allows SIP endpoints to work out the best way for them to communicate based on their different locations, configurations, and capabilities. There are some other wrinkles in this process, such as early media, but I won’t cover those here.
Sometimes, once a SIP dialog has been established, it’s necessary to change some aspect of the media handling for the call; or, in essence, to redo the media negotiation. To initiate this process, one of the endpoints sends a new INVITE message, with the same call ID but with different media information in the body. This does not terminate the existing SIP dialog or start a new one; it simply allows the endpoints to work out a different set of media attributes to be used from that point forward.
It’s important to realize that a re-INVITE is not the same thing as an INVITE with Replaces (a.k.a. call replacement). The re-INVITE is a new INVITE message in the sameSIP dialog; the INVITE with Replaces creates a newSIP dialog that takes over where the “replaced” one left off, with one of the participants changed. The two methods serve different purposes and look very different in SIP logs.
Why might you need to identify re-INVITEs? One place where this is often important is in MSPL scripts or other Lync Server SDK applications. Often these applications need to monitor or redirect calls, and to do this they need to watch for INVITE messages initiating new calls. For these applications, re-INVITEs are “red herrings” in that they are part of existing calls, but look mostly identical to an INVITE for a new call.
Let’s say you have a Lync Server SDK application that counts the number of audio calls placed by each user. If you simply watch for INVITEs that have audio media attributes, any re-INVITEs in those SIP sessions will throw off the number and make it artificially higher.
The best way to identify re-INVITEs is to look at the To header on the INVITE message. The first INVITE in a SIP dialog will have only the SIP URI of the recipient in the To header. Any subsequent INVITEs (re-INVITEs) will have a tag (something that looks like ;tag=2a69b9d51c) on the end of the To header. You can look for a tag on the To header to weed out re-INVITEs, as in the following MSPL example:
In managed code, you could do the same thing like this:
In UCMA, this issue doesn’t generally come up, since you won’t ordinarily see re-INVITEs at all unless you’re operating with the classes in the Microsoft.Rtc.Signaling namespace, in which case you can look for a tag in the To header in much the same way.
Regardless, this is the best and most reliable way to identify re-INVITEs when monitoring new calls in your applications.
| |||||||||||||||||||||||
|