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.

Registration Process

Section 10.3 of RFC 3261, talks about Registration Process flow. I have tried to summaries it into a flowchart.. Please comment on it..

Registration Overview

Overview:
RFC 3261 talks about registration in chapter 10. Registration is one way to populate the location service database. Registration allows SIP to be mobile. Under registration, a person can register more than 1 phone. A person is identified by a unique address called as Address Of Record (AOR). His phones are identified as contacts. An AOR can have multiple contacts binded to it. Lets see what RFC 3261 has to tell about Registration point by point.
1. Registration will use AOR to search for contact and add them.
2. Register can happen through proxy server to a registrar server. Server which handles the REGISTER message and acts to update or query the location service is said to be Registrar.
3. REGISTER request can add, remove, update, query contacts.
4. REGISTER request does not establish a dialog.
5. Record-route header has no meaning with REGISTER message. UAC must ignore this header.
6. A REGISTER message should have the following:
a. Request-URI: Domain for which the registration is done. Difference between the regular SIP Request-URI and REGISTER request-URI is the absence of “userinfo@”.
b. TO: Binding AOR. This AOR is the one for which we query, add, delete, update contact.
c. FROM: AOR of person initiating the contact. SIP supports third party registration.
d. Call-ID: Random unique identified similar to Call-ID used in other methods with a difference. Call-ID should be same between a client to a server all the time. If its different, then registrar would not be able to detect a delayed REGISTER message which arrived out of order.
e. CSEQ: UA must increment CSEQ for subsequent REGISTER messages.
f. Contact (Optional): If no contact header is present its query else, action will be decided on various factor between add, query, refresh etc.
7. UAC must not send any new registration until they have received final response from the registrar for previous one or timed out. Retransmission may happen.
8. Special contact header parameters: expire – specifies how long the binding is valid. If it is not present Expire header will be used.
9. 2xx response from registrar will have all bindings listed in contact header.
10. If neither the Expire header or expire parameter of contact header is present then server is allowed to chose the value.
11. Priority of contact can be set by using the ‘q’ parameter of a contact header.
12. Value is ‘q’ should be less than 1.
13. Higher the ‘q’ value, higher the priority.
14. Binding removal can be done by specifying expire=0.
15. If Contact header field value is *, expire value can only be 0. This means, all bindings to AOR are removed.
16. A successful response for REGISTER message will have all binded contacts listed in the Contact header along with its parameters. In case the REGISTER message does not have Contact header it is a query.
17. Discovery of Registrar can be done in three ways.
a. By configuration
b. By using AOR (only host and domain part of AOR is used)
c. Using multicast (224.0.1.75  sip.mcast.net)
18. Too small expiry time results in 423 – Interval Too Brief response.
19. A registrar must not generate a 6xx response.
20. Accepts only REGISTER message
21. Registrar should know the set of domain for which it maintains binding.
22. REGISTER message should be processed completely and independently.

List of Methods and Response codes

SIP is similar to HTTP in request response transaction model. Each transaction consists of a client request that invokes a particular method or function on the server and at least one response. SIP reuses most of the header fields, encoding rules and status codes of HTTP, providing a readable text-based format.

This blog lists the methods invoked by request and responses.

List of SIP Responses Methods:

Request name	Description	RFC
INVITE	Indicates a client is being invited to participate in a call session.	3261
ACK	Confirms that the client has received a final response to an INVITE request.	3261
BYE	Terminates a call and can be sent by either the caller or the callee.	3261
CANCEL	Cancels any pending request.	3261
OPTIONS	Queries the capabilities of servers.	3261
REGISTER	Registers the address listed in the To header field with a SIP server.	3261
PRACK	Provisional acknowledgement.	3262
SUBSCRIBE	Subscribes for an Event of Notification from the Notifier.	3265
NOTIFY	Notify the subscriber of a new Event.	3265
PUBLISH	publishes an event to the Server.	3903
INFO	Sends mid-session information that does not modify the session state.	2976
REFER	Asks recipient to issue SIP request (call transfer.)	3515
MESSAGE	Transports instant messages using SIP.	3428
UPDATE	Modifies the state of a session without changing the state of the dialog.	3311

1xx—Informational Responses

• 100 Trying

• 180 Ringing
• 181 Call Is Being Forwarded
• 182 Queued
• 183 Session Progress

2xx—Successful Responses

• 200 OK
• 202 accepted: It Indicates that the request has been understood but actually can't be processed

3xx—Redirection Responses

• 300 Multiple Choices
• 301 Moved Permanently
• 302 Moved Temporarily
• 305 Use Proxy
• 380 Alternative Service

4xx—Client Failure Responses

• 400 Bad Request
• 401 Unauthorized (Used only by registrars or user agents. Proxies should use proxy authorization 407)
• 402 Payment Required (Reserved for future use)
• 403 Forbidden
• 404 Not Found (User not found)
• 405 Method Not Allowed
• 406 Not Acceptable
• 407 Proxy Authentication Required
• 408 Request Timeout (Couldn't find the user in time)
• 409 Conflict
• 410 Gone (The user existed once, but is not available here any more.)
• 412 Conditional Request Failed
• 413 Request Entity Too Large
• 414 Request-URI Too Long
• 415 Unsupported Media Type
• 416 Unsupported URI Scheme
• 417 Unknown Resource-Priority
• 420 Bad Extension (Bad SIP Protocol Extension used, not understood by the server)
• 421 Extension Required
• 422 Session Interval Too Small
• 423 Interval Too Brief
• 424 Bad Location Information
• 428 Use Identity Header
• 429 Provide Referrer Identity
• 433 Anonymity Disallowed
• 436 Bad Identity-Info
• 437 Unsupported Certificate
• 438 Invalid Identity Header
• 480 Temporarily Unavailable
• 481 Call/Transaction Does Not Exist
• 482 Loop Detected
• 483 Too Many Hops
• 484 Address Incomplete
• 485 Ambiguous
• 486 Busy Here
• 487 Request Terminated
• 488 Not Acceptable Here
• 489 Bad Event
• 491 Request Pending
• 493 Undecipherable (Could not decrypt S/MIME body part)
• 494 Security Agreement Required

5xx—Server Failure Responses

• 500 Server Internal Error
• 501 Not Implemented: The SIP request method is not implemented here
• 502 Bad Gateway
• 503 Service Unavailable
• 504 Server Time-out
• 505 Version Not Supported: The server does not support this version of the SIP protocol
• 513 Message Too Large
• 580 Precondition Failure

6xx—Global Failure Responses

• 600 Busy Everywhere
• 603 Decline
• 604 Does Not Exist Anywhere
• 606 Not Acceptable

Network Element of SIP

Any communication would have a sender and a receiver. In SIP, these are generally called as User Agents (UA). The sender will initiate the request who is called precisely as User Agent Client (UAC) whereas the receiver who will receive the request is called by User Agent Server (UAS). The role of UAC and UAS are interchangeable and dynamic even within a single dialog.

Other than the UAC and UAS, there are other Network elements that can be involved in Call Routing, Call Processing, Interfacing. They are also called as SIP servers. They are,

Proxy server, which receives SIP request and forwards them on behalf of the requestor. A proxy server primarily plays the role of routing, which means its job is to ensure that a request is sent to another entity "closer" to the targeted user.

Redirect server, which receives a SIP request and generates redirect response, directing the client to contact alternative set of URIs.

Registrar, a server which receives a SIP register request and places the information it receives in those requests into the location service for the domain it handles.

Location Service, can be implemented per the discretion of the designer. A location service is used by a SIP redirect or proxy server to obtain information about a callee’s possible location(s). It contains a list of bindings of address-of record keys to zero or more contact addresses. The bindings can be created and removed in many ways. One way is to use Register request.

Session Border Controllers(SBC), they serve as middle boxes between UA and SIP server for various types of functions, including network topology hiding, and assistance in NAT traversal.

It is an important concept that the segregation of SIP Servers is logical and not physical, which means implementations can integrate them all into one code or into multiple code serving from multiple machines.

What is SIP

SIP - Session Intiation Protocol, a protocol developed by IETF MMUSIC (Multiparty Multimedia Session Control)Working Group (initially defined by RFC 2543 which superseded by RFC 3261) and proposed standard for initiating, modifying, and terminating an interactive user session that involves multimedia elements such as video, voice, instant messaging, online games, and virtual reality.

SIP is primarily used only for setting up, modifying, tearing down the media session (voice, video,..) between 2 (unicast) or more parties (multicast).

SIP is not a vertically integrated communications system. SIP is rather a component that can be used with other IETF protocols to build a complete multimedia architecture. Typically, these architectures will include protocols such as the Real-time Transport Protocol (RTP) for transporting real-time data and providing QoS feedback, the Real-Time streaming protocol (RTSP) for controlling delivery of streaming media, the Media Gateway Control Protocol (MEGACO) for controlling gateways to the Public Switched Telephone Network (PSTN), and the Session Description Protocol (SDP) for describing multimedia sessions. Therefore, SIP should be used in conjunction with other protocols in order to provide complete services to the users. However, the basic functionality and operation of SIP does not depend on any of these protocols.

SIP fits in to Application Layer of TCP/IP Model, which is designed to work independent of the underlying transport layer protocol. SIP is a text based protocol incorporating many elements of HTTP, SMTP.

Outline for functionalities of SIP:

User location: determination of the end system to be used for communication;

User availability: determination of the willingness of the called party to engage in communications;

User capabilities: determination of the media and media parameters to be used;

Session setup: "ringing", establishment of session parameters at both called and calling party;

Session management: including transfer and termination of sessions, modifying session parameters, and invoking services.

Introduction

This Blog is for our experiments and experiences with SIP (Session Initiation Protocol). SIP is defined latest by RFC 3261, though there are many extensions available now.

Label List:
Posts that concerning responses should have resp_[response code] label. eg: resp_404
Posts that concerning requests should have req_[request name] label. eg: reg_invite
Posts can include reference to functionality. (Registration, CallProcessing, etc..)
Posts that include General info about protocol should have label as [Protocol]General eg: SIPGeneral.
Above list is not complete.. Label should be added as and when required at our discretion..