0102 Processing 3xx Responses

 

Any new request may receive 3xx responses themselves containing

      the original URI as a contact.  Two locations can be configured to

      redirect to each other.  Placing any given URI in the target set

      only once prevents infinite redirection loops.

 

   As the target set grows, the client MAY generate new requests to the

   URIs in any order.  A common mechanism is to order the set by the "q"

   parameter value from the Contact header field value.  Requests to the

   URIs MAY be generated serially or in parallel.  One approach is to

   process groups of decreasing q-values serially and process the URIs

   in each q-value group in parallel.  Another is to perform only serial

   processing in decreasing q-value order, arbitrarily choosing between

   contacts of equal q-value.

 

   If contacting an address in the list results in a failure, as defined

   in the next paragraph, the element moves to the next address in the

   list, until the list is exhausted.  If the list is exhausted, then

   the request has failed.

Note that in some instances, header fields that have been

   communicated in the contact address may instead append to existing

   request header fields in the original redirected request.  As a

   general rule, if the header field can accept a comma-separated list

   of values, then the new header field value MAY be appended to any

   existing values in the original redirected request.  If the header

   field does not accept multiple values, the value in the original

   redirected request MAY be overwritten by the header field value

   communicated in the contact address.  For example, if a contact

   address is returned with the following value:

 

      sip:user@host?Subject=foo&Call-Info=<http://www.foo.com>

 

   Then any Subject header field in the original redirected request is

   overwritten, but the HTTP URL is merely appended to any existing

   Call-Info header field values.

 

   It is RECOMMENDED that the UAC reuse the same To, From, and Call-ID

   used in the original redirected request, but the UAC MAY also choose

   to update the Call-ID header field value for new requests, for

   example.

 

   Finally, once the new request has been constructed, it is sent using

   a new client transaction, and therefore MUST have a new branch ID in

   the top Via field as discussed in Section 8.1.1.7.