Microsoft Lync and Skype for Business have a rich set of .NET APIs which make it easy to extend the platform and integrate it with other applications. This blog helps explain how to use those APIs.

Identifying re-INVITEs

Posted: October 3rd, 2013 | Author: | Filed under: MSPL | Tags: , , | 1 Comment »

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 same SIP dialog; the INVITE with Replaces creates a new SIP 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:

toHeader = sipRequest.To;
toTag = GetParameterValue(toHeader, "tag");

if (toTag != null)
{
    // This is a re-INVITE.
}

In managed code, you could do the same thing like this:

Header toHeader = request.AllHeaders.FindFirst("To");

foreach (string key in toHeader.Parameters.Keys)
{
    if (key == "tag")
    {
        // This is a re-INVITE.
    }
}

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.


One Comment on “Identifying re-INVITEs”

  1. 1 Bas van Leeuwen said at 6:00 am on May 2nd, 2014:

    Hi Michael,
    We have an application monitoring call-flows by analysing the sip from the front-end servers. This way we can create realtime call-history.
    We have an issue in following a blind transfer.
    We are trying to match the INVITE to the new destination to the original REFER. We want to use the referred-by header, because it is in both the REFER and the INVITE, but they do not match.
    Do you know a way to match those correctly?

    Kind regards,
    Bas


Leave a Reply

  • Note: Comment moderation is in use because of excessive spam. Your comment may not appear immediately.

  •