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.

SIP URI typos and the misleading errors they cause

Posted: March 20th, 2014 | Author: | Filed under: UCMA 4.0 | Tags: , , | 1 Comment »

For a development platform that abstracts away a whole lot of underlying activity, UCMA really does a pretty good job of letting you know the cause when a problem occurs. But there are a few cases where errors in UCMA applications can be utterly bewildering, and probably the most frustrating of these are the ones that result from typos in SIP URIs. Missing a character or misspelling a part of a SIP URI can lead to errors that seem to have no relationship to what is actually going wrong. I wanted to cover a couple of those errors here in the hope of preventing others from tearing their hair out for multiple days trying to troubleshoot these sneaky problems.

Malformed impersonation URIs

One of the cases where this can come up is in applications that use impersonation. The impersonation capability allows trusted application endpoints to send messages or place calls that appear to come from other users: users that may or may not actually exist in Active Directory. Essentially, a trusted application endpoint can make a message appear to come from any arbitrary SIP URI. If the SIP URI is not a valid one, this can cause some pretty serious problems.

As an example, let’s take the following exception:

System.ArgumentException: Invalid Uri: Semantic error:  fTopLabel == true

At first glance, you might interpret this as a sign that the SIP URI you’re calling is somehow incorrect. But in that case, you would normally get a much more helpful description for the exception, saying that the destination SIP URI is invalid. In fact, what is going on in this case is that part of the impersonated SIP URI, the one the application is pretending to call from, is missing. This might be an issue with how the SIP URI is constructed. For instance, if you build the URI by appending “sip:” to the front of the user@domain portion of the address, a missing user@domain will lead to your application impersonating the SIP URI sip: which will result in the above exception.

Typos in SIP domain and the “federated partners” error

Another category of misleading errors is caused by misspelled SIP domains when establishing endpoints for your application. This can lead to an error message saying “Cannot route this type of SIP request to or from federated partners,” which can seem odd when all you’re doing is establishing a UserEndpoint. If you see this error, the first thing you should do is always to check the domain part of the SIP URI. More often than not, the issue is that the domain is misspelled, or you’re unwittingly using a SIP URI that doesn’t belong to the domain in which the application is running (maybe because you’re using a SIP URI from your production environment in your lab, or vice versa.

What’s actually happening under the covers is this: when your UCMA application establishes an endpoint, it sends a SIP REGISTER request to the Front End Server, to “sign in” as that user. You can only register as a user that belongs to the environment where the Front End Servers are located. Generally, if the Front End Server receives a message where the destination SIP URI contains a domain that isn’t supported in that environment, it will pass it along to the Edge Server to be routed to a federated partner if possible. But REGISTER requests can’t go to federated partners, hence the error message.


Both of these issues can be extremely confusing to troubleshoot if you haven’t seen them before (or even if you have!). The most frustrating part is when you realize that a small typo in one SIP URI has been causing what seemed like a massive environment issue. Hopefully this post will save a few people from hours of frustration.

One Comment on “SIP URI typos and the misleading errors they cause”

  1. 1 Guillaume Carre said at 2:22 pm on February 19th, 2016:

    Hi Michael,

    I am pretty new at Lync development. I am trying to build a simple UCMA service to pull the status of a database of Lync users. I am testing my connectivity using a sample code from the UCMA 4.0 SKD “SubscribePresenceView” and it is returning “Unable to perform authentication of credentials.”.
    One thing that I have noticed is that, using the same credential, I am able to connect a 2013 Lync client in auto configuration mode, but not in manual mode. Even when the auto configuration connects to the exact same Lync server address than I am attempting in manual configuration.
    My question is, is there a way to create a UCMA app that uses auto configuration?

    I would greatly appreciate your help.


Leave a Reply

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