The Session Initiation Protocol (SIP) is an application-layer control (signaling) protocol for creating, modifying, and terminating multimedia sessions(voice/video calls) with one or more participants.
SIP support following five facets of establishing and terminating multimedia communications:
1. User Location: Determination of End System to be used for communication.
2. User Availability: Determination of the willingness of the called party to engage in communications
3. User Capabilities: Determination of the media and media parameters to be used.
4. Session Setup: “Ringing”, establishment of session parameters at both called and calling party.
5. Session Management: Including transfer and termination of sessions, modifying session parameters, and invoking services.
BASIC SIP CALL FLOW
Few Terms/Abbreviations
URI: Uniform Resource Identifier – ex: sip:abc@xyz.com
UAC - User Agent Client
UAS - User Agent Server
UA - User Agent
B2BUA - Back To Back Uger Agent (UAC + UAS): It is a logical entity that receives a request and processes it as a user agent server (UAS). In order to determine how the request should be answered, it acts as a user agent client (UAC) and generates requests. Unlike a proxy server, it maintains dialog state and must participate in all requests sent on the dialogs it has established. Since it is a concatenation of a UAC and UAS, no explicit definitions are needed for its behavior.
Dialog: A dialog is a peer-to-peer SIP relationship between two UAs that persists for some time. A dialog is established by SIP messages, such as a 2xx response to an INVITE request. A dialog is identified by a call identifier, local tag, and a remote tag. A dialog was formerly known as a call leg in RFC 2543.
SIP Transaction: A SIP transaction occurs between a client and a server and comprises all messages from the first request sent from the client to the server up to a final (non-1xx) response sent from the server to the client. If the request is INVITE and the final response is a non-2xx, the transaction also includes an ACK to the response. The ACK for a 2xx response to an INVITE request is a separate transaction.
Loose Routing: A proxy is said to be loose routing if it follows the procedures defined in RFC 3261 for processing of the Route header field. These procedures separate the destination of the request (present in the Request-URI) from the set of proxies that need to be visited along the way (present in the Route header field). A proxy compliant to these mechanisms is also known as a loose router.
Strict Routing: A proxy is said to be strict routing if it follows the Route processing rules of RFC 2543 and many prior work in progress versions of this RFC. That rule caused proxies to destroy the contents of the Request-URI when a Route header field was present. Strict routing behavior is not used in RFC 3261, in favor of a loose routing behavior. Proxies that perform strict routing are also known as strict routers.
Few salient points about SIP
- SIP is end-to-end, client-server session signaling protocol
- SIP clients use TCP or UDP typically using port 5060 to connect to SIP servers and other SIP endpoints.Most implementation use UDP.
- Transport-independent, because SIP can be used with UDP, TCP, ATM, TLS,SCTP & so on.
- Lightweight, in that SIP has only six methods, reducing complexity.
- Text-based, allowing for humans to read SIP messages.
- Involved only in the signaling portion of a communication session.
SIP Proxy Server
Relays call signaling, i.e. acts as both client and server operates in a transactional manner, i.e., it keeps no session state (stateless/stateful proxies??).
It helps route requests to the user's current location, authenticates and authorizes users for services, implements provider call-routing policies, and provides features to users."
Forking proxies needs to be stateful
SIP Redirect Server
Redirects callers to other servers
SIP Registrar
Accept registration requests (REGISTER) from users maintains user’s whereabouts at a Location Server (like GSM's HLR)
SIP Location Server
Used by a SIP redirect or proxy server to obtain information about a called party’s possible location (s)
SIP Call Flow (SIP Trapezoid)
SIP Methods
INVITE - Requests a session
ACK - Final response to the INVITE
OPTIONS - Ask for server capabilities
CANCEL - Cancels a pending request
BYE - Terminates a session
REGISTER - Sends user’s address to server
SIP Responses
1XX Provisional 100 Trying
2XX Successful 200 OK
3XX Redirection 302 Moved Temporarily
4XX Client Error 404 Not Found
5XX Server Error 504 Server Time-out
6XX Global Failure 603 Decline
SIP Header Fields
Request Line:
INVITE sip:marconi@radio.org SIP/2.0
(Method) Rx-URI SIP-VERSION
To:
The To header field first and foremost specifies the desired "logical" recipient of the request, or the address-of-record of the user or resource that is the target of this request. This may or maynot be the ultimate recipient of the request.
From:
The From header field indicates the logical identity of the initiator of the request, possibly the user's address-of-record.
Call-ID:
The Call-ID header field acts as a unique identifier to group together a series of messages. It MUST be the same for all requests and responses sent by either UA in a dialog. It SHOULD be the same in each registration from a UA.
From SIP RFC 3261 - The Call-ID header field uniquely identifies a particular invitation or all registrations of a particular client. A single multimedia conference can give rise to several calls with different Call-IDs, for example, if a user invites a single individual several times to the same (long-running) conference. Call-IDs are case-sensitive and are simply compared byte-by-byte.
The compact form of the Call-ID header field is i.
Examples:
Call-ID: f81d4fae-7dec-11d0-a765-00a0c91e6bf6@biloxi.com
i:f81d4fae-7dec-11d0-a765-00a0c91e6bf6@192.0.2.4
CSeq: (32 it)
The CSeq header field serves as a way to identify and order transactions. It consists of a sequence number and a method. The method MUST match that of the request.
From SIP RFC 3261 - A CSeq header field in a request contains a single decimal sequence number and the request method. The sequence number MUST be expressible as a 32-bit unsigned integer. The method part of CSeq is case-sensitive. The CSeq header field serves to order transactions within a dialog, to provide a means to uniquely identify transactions, and to differentiate between new requests and request retransmissions. Two CSeq header fields are considered equal if the sequence number and the request method are identical.
Example: CSeq: 4711 INVITE
Max-Forwards: (Default Value 70??)
The Max-Forwards header field serves to limit the number of hops a request can transit on the way to its destination. It consists of an integer that is decremented by one at each hop. If the Max-Forwards value reaches 0 before the request reaches its destination, it will be rejected with a 483(Too Many Hops) error response.
VIA:
The Via header field indicates the transport used for the transaction and identifies the location where the response is to be sent.
When the UAC creates a request, it MUST insert a Via into that request. The protocol name and protocol version in the header field MUST be SIP and 2.0, respectively. The Via header field value MUST contain a branch parameter. This parameter is used to identify the transaction created by that request. This parameter is used by both the client and the server.
The branch parameter value MUST be unique across space and time all requests sent by the UA.
The branch ID inserted by an element compliant with RFC3261 MUST always begin with the characters "z9hG4bK".
Via: SIP/2.0/UDP lab.high-voltage.org:5060;branch=z9hG4bKfw19b
Contact:
The Contact header field provides a SIP or SIPS URI that can be used to contact that specific instance of the UA for subsequent requests. The Contact header field MUST be present and contain exactly one SIP or SIPS URI in any request that can result in the establishment of a dialog. For the methods defined in Rfc3261 specification, that includes only the INVITE request.
Contact: ~~sip:n.tesla@lab.high-voltage.org~~ (~~X~~ encloes in angular bracket)
SIP Registeration
~~~~~ TBD~~~~~
SIP Redirection
SIP Routing
- A request from User Agent – A to User Agent – B may be routed through several proxies.
- Via Header: Each time a proxy forwards a message it appends a ‘Via’ Header to the list of forwarding proxies. It is useful to detect the routing loops.
- SIP Clients can add a Contact header so that each client can send them requests directly and therefore proxies are not guaranteed to be in the path of all request.
- Record Route Header: It may be desirable to follow the same route back. For example, proxy might be Billing Proxy and needs to have access to all the information regarding the call. When the proxies get the request then they insert the Record-Route header inserting their SIP URL.
More SIP Call Flows
TBD
FAQs
How SIP request is distinguished from response?
No comments:
Post a Comment