Pages

Tuesday, December 28, 2010

UAC General behavior outside the dialog

UAC General behavior outside the dialog:

This excerpt is a method independent rules for initiating request and handling response.

At the least, a valid request should have the following headers. To, From, CSeq, Call-ID, Max forward, Via. These 6 headers form the fundamental building block of SIP.

Formation of request:

What is the format of Request line?

Format of SIP request line: METHOD Space Request_URI Space SIPVersion

How a request URI should be?

Initial Request URI should be set to the value of URI in To field. Exception is REGISTER method.

A preexisting route set could affect the Request URI.

Specifies desired logical recipient or address of record of target.

May contain SIP or SIPS URI.

What is a Route set?

It is an ordered set of URI that identifies a chain of server through which outgoing request outside dialog are sent to.

How a ‘To’ should be?

A request outside a dialog must not and cannot contain a ‘To tag’.

Populating URI is done by any method desirable by user and application. Example URI would be SIP:useridentity@fqdn_domain_or_IPaddress

How ‘From’ should be?

It should be a logical identity of initiator of request.

If initiator wants to remain anonymous, he got to use syntactically correct but meaningless URI.

From should have a From tag.

How ‘Call ID’ should be?

Call ID is a global unique_id for message series.

Cryptographically random ID can be used.

Can use Cryptographically_random_Id@host

Whats a CSeq?

Must be 32 bit unsigned int less than 2 power 31. Ie 2147483648

How Max forward should be?

This field is used to limit the number of hops.

It is going to be decremented by 1 for each hops.

If it reaches ‘0’ then that hop would send ‘483 Too many hops’ error response.

How Via should be?

Identify the transport protocol used.

Identify where response to be sent.

Via added after transport is determined

Must contain branch parameter unique for method and time.

Exception is CANCEL and ACK for non-200 responses.

Implementation in compliance with RFC 3261 should have branch parameter value that begins with ‘z9hG4bk’.

Via header parameters maddr, ttl, sent-by would be set while processing.

How Contact should be?

Should have SIP or SIPS URI which would be used for contacting the specific UA for subsequent response.

Must be present and should have only one SIP / SIPS URI. Exception is REGISTER method.

What about ‘Supported and Require’ headers?

If UAC supports extension to SIP that can be applied to the response, supported header with option tag should be included.

If UAC insist UAS support an extension, Require header is used.

If UAC insists proxy to support and extension, then Proxy-Require header is used.

Sending the request

Destination is determined after applying DNS.

If Request URI has SIPS, all other should be processed as if they are also SIPS.

UAC configured with outbound proxy should attempt to send the request to location indicated in the first Route header. This will ensure that the proxies that does not add record route will be left out subsequently.

Processing of response

A response would first be processed by Transport layer then transaction layer then to Transaction User.

Most of the TU processing is based on the method.

Sometimes instead of response, transaction layer will return an error message to TU.

When a timeout is received from Transaction layer, it should be considered as 408 Request Timeout.

If fatal transport error due to ICMP errors in UDP or connection failure in TCP, the condition must be treated as 503 Service Unavailable.

Any final response that is not recognizable can be deemed equivalent to X00 response code. For ex 431. If not recognizable, should be treated equivalent to 400 Bad request.

UAC should discard message if it has more than one via header field.

Processing 3xx response

On 3xx response, client should use URI in the contact field.

Each contact should be tried only once.

Order of try can be based on the Q parameter of the contact.

Equal Q values can be processed in parallel.

If one address fails, next has to be selected.

If all fails, the request has failed.

For some response codes above 399 can mean retries, which should not be considered as failures.

Entire Request URI can be copied from contact header

UAC can reuse the same To, From, Call-ID used in the original redirected request but UAC may also chose to retain them.

Once the new message is framed it marks new transaction.

Processing 4xx response

Certain 4xx responses require UA processing independent of method.

401 – Unauthorised, 407 – Proxy-Authentication Required UAC should follow authorization procedure.

413 – Request Entity too large, the response has body which is too large for UAC to handle.

415 – Unsupported media type, UAC should send a request containing media type which is listed in Accept header field with encoding listed in Accept-encoding header.

416 – Unsupported URI scheme. UAC should retry with SIP URI.

420 – Bad extension, UAC should retry sending request by omitting unsupported extension listed in Unsupported header in response.

Retry is a new transaction and should have same Call-Id, To, From.

CSeq should have new sequence number.