SIP Instance ID in Registration Cache
As defined in RFC 5626, Managing Client-Initiated Connections in the Session Initiation Protocol (SIP), the +sip.instance uniquely identifies a specific user agent instance. The instance-id does not change even when the User Agent is rebooted or power cycled. Using the instance-id from the +sip-instance parameter allows the SBC to locate a registered contact even when the IP address of the UA has changed.
The +sip.instance is a Contact header field parameter that contains a globally unique identifier, generally a Universally Unique Identifier (UUID) Uniform Resource Name (URN) that identifies a specific user agent client.
As defined in RFC 5626, Managing Client-Initiated Connections in the Session Initiation Protocol (SIP), the parameter contains an "instance-id" that uniquely identifies a specific user Agent instance. The instance-id does not change even when the User Agent is rebooted or power cycled (see Section 3.1 of RFC 5626). Using the instance-id from the +sip-instance parameter allows the SBC to locate a registered contact even when the IP address of the UA has changed.
An example REGISTER message containing a +sip-instance parameter and assigned value is shown below.
REGISTER sip:example.com SIP/2.0
Via: SIP/2.0/TCP 192.0.2.2;branch=z9hG4bK-bad0ce-11-1036
Max-Forwards: 70
From: Bob <sip:bob@example.com>;tag=d879h76
To: Bob <sip:bob@example.com>
Call-ID: 8921348ju72je840.204
CSeq: 1 REGISTER
Supported: path, outbound
Contact: <sip:line1@192.0.2.2;transport=tcp>; reg-id=1;
;+sip.instance="<urn:uuid:00000000-0000-1000-8000-000A95A0E128>"
Content-Length: 0The user agent calculates a +sip.instance generally using a time-stamp, a unique string -- such as a MAC address, and/or a randomly generated number. After calculating the value, the user agent saves it to persistent storage, thus ensuring that the value is unchanged by subsequent power cycles.
SIP Instance ID and the Registration Cache
Every assignment of a new IP address to a mobile user agent client results in a new REGISTER request. The receipt of the REGISTER request, in turn, generates an additional entry in the registration cache. The implementation can be simplified by including the +sip.instance value in the criteria used to match incoming REGISTER requests with existing sessions maintained in the registration cache. When a match is found, the SBC re-uses the existing registration cache rather than adding a new one.
If such a +sip.instance match is found and the contact address has changed, the SBC determines if digest authentication has been used in previous associated REGISTER requests. If so, the SBCs forwards the REGISTER request to the registrar for authentication of the new location.