Share via

3.1.1.5.1 Processing the SIP REGISTER Response

  • Article

The UAC SHOULD extract the contact GRUU returned by the SIP registrar and use it subsequently as specified in [IETFDRAFT-OUGRUAUSIP-10] section 8.

The UAC MUST retrieve the registration expiry timer value, as specified in [RFC3261] section 10, from the SIP REGISTER response. It MUST then set the registration expiry timer value less than the value specified in the 200 OK response to the REGISTER request.

The UAC SHOULD process the ms-keep-alive header, as specified in [MS-CONMGMT] section 2.2.1, returned by the registrar as specified in [MS-CONMGMT] section 3.4.5, and use it to initialize the keep-alive timer.

If a Presence-State header field is present in the 200 success response, the UAC MUST take the following additional actions:

  • If the value of Register-Action is "added" or "fixed", and if the REGISTER operation is for the purpose of refreshing a binding instead of adding a new binding, the UAC MUST treat this as a registration failure and all existing dialogs SHOULD be considered terminated. The UAC SHOULD restart registration.

  • If the value of Primary-Cluster-Type is "central", the UAC SHOULD<145> treat this as an indication of the user being provisioned on a server at a central site and MUST update the Primary-Cluster-Type field to "central". If the value is "remote", the UAC MUST treat this as an indication that the user is being provisioned at a remote site and MUST update the Primary-Cluster-Type field to "remote".

  • If the value of Is-Connected-to-Primary is "yes", the UAC SHOULD<146> treat the endpoint as being connected to the user’s primary server and MUST update the Is-Connected-to-Primary field to "true". If the value is "no", the UAC MUST<147> treat the endpoint as not being connected to the user’s primary server and MUST update the Is-Connected-to-Primary field to "false".

  • If the value of user-services-state is "unavailable", the UAC SHOULD<148> set the Presence-Service-Available field to "false".

  • If user-services-state is NOT present, the UAC SHOULD<149> set the Presence-Service-Available field to "true".

After the UAC receives a 200 response for the first REGISTER it sent, the UAC SHOULD attempt to establish a contact or group subscription, as specified in [MS-SIP] section 3.3, and SHOULD attempt to establish a self-subscription, as specified in [MS-PRES] section 3.3, to retrieve the user's contact and group information and published presence information.

If the Presence-Service-Available field is set to "false", the UAC SHOULD<150> treat itself to be in survivable mode and SHOULD NOT attempt to establish any subscription except a self-subscription, as specified in [MS-PRES] section 3.3.

If the self-subscription fails to establish, the UAC is not able to retrieve the published presence information, and the UAC SHOULD<151> remove the binding by sending a REGISTER request with Expiry value of 0, as specified in [RFC3261] section 10.2.2. If the contact or group subscription fails, contacts and groups information is not available.

If the self-subscription fails to establish and the UAC is not in survivable mode, the UAC SHOULD<152> retry the self-subscription at a randomized interval. If, however, the self-subscription fails to establish while the UAC is in survivable mode, it SHOULD<153> wait for the retry until the end of survivable mode, as indicated by a response to a future REGISTER with the Presence-Service-Available field set to "false", as described in the preceding paragraphs.

This protocol does not mandate how implementations operate on the Primary-Cluster-Type and Is-Connected-to-Primary fields as long as their external behavior is consistent with that described in this protocol.