Registrations

0117 Registrations

1 Overview

   SIP offers a discovery capability.  If a user wants to initiate a

   session with another user, SIP must discover the current host(s) at

   which the destination user is reachable.  This discovery process is

   frequently accomplished by SIP network elements such as proxy servers

   and redirect servers which are responsible for receiving a request,

   determining where to send it based on knowledge of the location of

   the user, and then sending it there.  To do this, SIP network

   elements consult an abstract service known as a location service,

   which provides address bindings for a particular domain.  These

   address bindings map an incoming SIP or SIPS URI, sip:bob@biloxi.com,

   for example, to one or more URIs that are somehow "closer" to the

   desired user, sip:bob@engineering.biloxi.com, for example.

   Ultimately, a proxy will consult a location service that maps a

   received URI to the user agent(s) at which the desired recipient is

   currently residing.

 

   Registration creates bindings in a location service for a particular

   domain that associates an address-of-record URI with one or more

   contact addresses.  Thus, when a proxy for that domain receives a

   request whose Request-URI matches the address-of-record, the proxy

   will forward the request to the contact addresses registered to that

   address-of-record.  Generally, it only makes sense to register an

   address-of-record at a domain's location service when requests for

   that address-of-record would be routed to that domain.  In most

   cases, this means that the domain of the registration will need to

   match the domain in the URI of the address-of-record.

 

0116 Server Behavior

   The CANCEL method requests that the TU at the server side cancel a

   pending transaction.  The TU determines the transaction to be

   cancelled by taking the CANCEL request, and then assuming that the

   request method is anything but CANCEL or ACK and applying the

   transaction matching procedures of Section 17.2.3.  The matching

   transaction is the one to be cancelled.

 

   The processing of a CANCEL request at a server depends on the type of

   server.  A stateless proxy will forward it, a stateful proxy might

   respond to it and generate some CANCEL requests of its own, and a UAS

   will respond to it.  See Section 16.10 for proxy treatment of CANCEL.

 

   A UAS first processes the CANCEL request according to the general UAS

   processing described in Section 8.2.  However, since CANCEL requests

   are hop-by-hop and cannot be resubmitted, they cannot be challenged

   by the server in order to get proper credentials in an Authorization

   header field.  Note also that CANCEL requests do not contain a

   Require header field.

 

   If the UAS did not find a matching transaction for the CANCEL

   according to the procedure above, it SHOULD respond to the CANCEL

   with a 481 (Call Leg/Transaction Does Not Exist).  If the transaction

   for the original request still exists, the behavior of the UAS on

   receiving a CANCEL request depends on whether it has already sent a

   final response for the original request.  If it has, the CANCEL

   request has no effect on the processing of the original request, no

   effect on any session state, and no effect on the responses generated

   for the original request.  If the UAS has not issued a final response

   for the original request, its behavior depends on the method of the

   original request.  If the original request was an INVITE, the UAS

   SHOULD immediately respond to the INVITE with a 487 (Request

   Terminated).  A CANCEL request has no impact on the processing of

   transactions with any other method defined in this specification.

 

   Regardless of the method of the original request, as long as the

   CANCEL matched an existing transaction, the UAS answers the CANCEL

   request itself with a 200 (OK) response.  This response is

   constructed following the procedures described in Section 8.2.6

   noting that the To tag of the response to the CANCEL and the To tag

   in the response to the original request SHOULD be the same.  The

   response to CANCEL is passed to the server transaction for

   transmission.