The term “GRUU” comes up fairly often in Lync development, and I wanted to use this post to give a brief overview of what it means and why you would use one.
Contrary to what you may have been led to believe, a GRUU is not a large herd animal or a part of the small intestine. The initials actually stand for “Globally Routable User-Agent URI,” which may or may not clarify things for you at all. The definition of a GRUU is explained in an IETF document which you can find here. In a nutshell, a GRUU is a SIP URI which has a few properties:
- It identifies a specific user agent — in other words, a specific endpoint where a user is signed on.
- It is (in theory) routable to that specific endpoint from anywhere.
- It remains valid for a long time.
You’ll find a GRUU in the Contact header on SIP INVITE messages; the GRUU identifies the specific endpoint where the request is coming from. You can identify a GRUU in the wild by looking for a format like the following:
Let’s say this user, with the SIP URI sip:user@domain, is logged into three devices. If you were to send a message to sip:user@domain, the request would be “forked” to all three locations where the user is logged in.
If, however, you sent the request to sip:user@domain;opaque=user:epid:UghFocauauCHBHoLhAAA;gruu, it would go to the specific device identified by the GRUU, and not to any of the others.
Let’s take a couple of examples of where this comes in handy. The example the IETF document uses is a call transfer. The way a transfer works in SIP is this: User A is on a call with User B, and wants to transfer User B to User C. User A sends a REFER message to User B, with User C’s SIP URI included in the message. User B then places a new call to User C.
Here’s the problem: User A may be talking to User C at the moment, and may need to transfer User B to a specific endpoint where User C is registered. If the SIP URI provided to User B is just a regular SIP URI, User B’s new call will end up going to all of the endpoints for User C. To solve this problem, User A can provide User B with the GRUU for a specific endpoint for User C.
Another example which applies to Lync is multimodal communication. Let’s say I’m on a Lync audio call with you on your laptop, and I want to add application sharing. When I click the button in the Lync client to add application sharing, that app sharing call shouldn’t go to ALL of the endpoints where you’re logged on — it should only go to your laptop, right? So to avoid this, I can send an INVITE message for the application sharing session to the GRUU associated with the Lync client on your laptop. Make sense?
One place where GRUUs come up often in Lync development is in creating a trusted application instance for your UCMA application. A trusted application always uses a GRUU because the application is tied to a specific server, and so it is always receiving messages from Lync at the same location.
The way Lync handles message routing for UCMA applications, and particularly application endpoints, is an interesting topic of its own, and I plan to cover that in my next post, so let me know if you have specific questions in that area that you would like to see answered.