Академический Документы
Профессиональный Документы
Культура Документы
1. Core SIP
1.1 Introduction
SIP is a signalling protocol. Signaling: Establishing a session Terminating a session Update a session (e.g. media codec) Invoke higher services
SIP messages contain SDP (Session Description Protocol) that describes media. Media: Encoded voice stream, video stream
After a SIP session is established, RTP (Real Time Protocol) is exchanged. It conveys the media.
IMS related extensions. Used in conjunction with other IETF protocols o QOS related protocol (e.g. RSVP) o Media transportation protocol (e.g. RTP - RFC 1989) o Others (e.g. SDP - RFC 2327)
SIP architecture
SIP has a client-server model in which the caller (the client) establishes the connection by sending a request message to the callee (the server) who reacts to requests by appropriate response messages. It supports five features: specifying the user location, determination of the user availability, specifying the user device capabilities, initiating session parameters for calling parties, and control sessions.
SIP architecture consists of the following: user agents, proxy, registrar, and redirect servers. User Agent (UA) represents the endpoint entity in the SIP session and the one that starts and ends SIP media sessions by exchanging SIP messages.
UA is capable of playing the role of client (User Agent Client) and server (User Agent Server) depending on its kind of participation in the call. Proxy server: acts as a median entity which routes calls and can play the role of a client and a server at the same time. It forwards requests on behalf of clients after rewriting parts of the message if necessary, forwards responses on behalf of servers to clients, and can be used to apply policies on the exchanged SIP messages. Redirect server: receives SIP requests and maps addresses in the SIP requests to alternate URIs. Unlike the proxy server, it does not route requests to other servers instead it allows proxy servers to forward calls to exterior domains. Registrar server: responsible for receiving REGISTER SIP messages and updating the user information in the location server of its domain. Usually it is located with proxy or redirect servers.. Location server simply manages the database of the architecture. It mainly stores and retrieves SIP URIs (addresses of SIP user devices and other SIP servers).
SIP messages
SIP protocol is a text-based protocol and its messages are readable. SIP has two types of messages: Request- A SIP message initiated by the client. Response- A SIP message initiated by the server.
Message structure
Quite similar to HTTP messages. It consists of start line, headers and body as follows:
The start line indicates the message type, whether it is a request or a response, and the header contains necessary information for routing the message to the destination. The optional body contains the media description (video, audio or data). It conforms to another protocol: the Session Description Protocol (SDP).
SIP requests
The request message consists of a method token, URI address for the destination. RFC3261 introduced six types of request SIP messages as follows:
Purpose Establish a call. Contains information about the participating parties in the call and the media being exchanged. A confirmation message sent by the caller to commit the call establishment To terminate an established call. It can be sent either by the caller or the callee. To end a pending SIP request. To inquire about the capabilities of the other party. Used by a UA to register its address in a registrar server.
SIP responses
A SIP response consists of a three-digit status-code, and a reason expression that indicates the status of the request. The status-code is classified into six different classes with values ranging over 100 - 699. There are two types of SIP response: Provisional: response messages that start with 1xx status-code. Used by the server to indicate the message progress without terminating SIP sessions Final: any response with a status-code other than 1xx can terminate the SIP session: 2xx, 3xx, 4xx, 5xx, 6xx classes. The following table explains the six different response classes:
Status-code 1xx- Provisional 2xx-Success 3xx- Redirection 4xx- Client Error 5xx- Server Error 6xx- Global Failure Description Indicates that the received request is now being processed by the server. Indicates that a message has been received successfully. Indicates the need of intermediate step to complete processing the request. Indicates typography error by the user or a request that could not be done by the server. Indicates that a server could not fulfill a valid client request. Indicates that a request could not be processed/fulfilled by any of the servers.
403 Forbidden The server understood the request, but is refusing to fulfill it. 404 Not Found The server has definitive information that the user does not exist at the domain specified in the Request-URI. 408 Request Timeout The server could not produce a response within a suitable amount of time. 486 Busy Here The callee's end system was contacted successfully, but the callee is currently not willing or able to take additional calls at this end system. 500 Server Internal Error The server encountered an unexpected condition that prevented it from fulfilling the request. 503 Service Unavailable The server is temporarily unable to process the request due to a temporary overloading or maintenance of the server. 603 Decline The callee's machine was successfully contacted but the user explicitly does not wish to or cannot participate.
[http://www.tech-invite.com]
Call-ID Acts as a unique identifier to group together a series of messages. Contact Provides a SIP URI that can be used to contact the UA for subsequent requests.
Contact: "Mr. Watson" <sip:watson@worcester.bell-telephone.com>
Expires Gives the relative time after which the message (or content) expires.
Expires: 1800
Priority Indicates the urgency of the request as perceived by the client. The header field can have the values "non-urgent", "normal", "urgent", and "emergency", but additional values can be defined. It is recommended that the value of "emergency" only be used when life or property are in imminent danger. Subject Provides a summary or indicates the nature of the call, allowing call filtering.
Subject: Weekend plans Priority: non-urgent
Presence service
PUA | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |
SERVER | | | | | | | | | | ---- M5: PUBLISH ---> | | <--- M6: 200 OK ---- | | | | | | ---- M9: PUBLISH ---> | | <--- M10: 200 OK --- | | | --- M11: PUBLISH ---> | | <-- M12: 200 OK ---- | | | | | |
WATCHER
| <---- M1: SUBSCRIBE --- | | ----- M2: 200 OK -----> | | ----- M3: NOTIFY -----> | | <---- M4: 200 OK ------ | | | | | | | ----- M7: NOTIFY -----> | | <---- M8: 200 OK ------ | | | | | | | | | | | ----- M13: NOTIFY ----> | | <---- M14: 200 OK ----- | |
SUBSCRIBE sip:presentity@example.com SIP/2.0 To: <sip:presentity@example.com> From: <sip:watcher@example.com>;tag=12341234 Call-ID: 12345678@host.example.com CSeq: 1 SUBSCRIBE Max-Forwards: 70 Expires: 3600 Event: presence Contact: sip:user@host.example.com Content-Length: 0
PUBLISH sip:presentity@example.com SIP/2.0 Via: SIP/2.0/UDP pua.example.com;branch=z9hG4bK652hsge To: <sip:presentity@example.com> From: <sip:presentity@example.com>;tag=1234wxyz
Call-ID: 81818181@pua.example.com CSeq: 1 PUBLISH Expires: 3600 Event: presence Content-Type: application/pidf+xml Content-Length: ... <?xml version="1.0" encoding="UTF-8"?> <impp:presence xmlns:impp="urn:ietf:params:xml:ns:pidf" entity="presentity@example.com "> <impp:tuple id="sg89ae"> <impp:status> <impp:basic>open</impp:basic> <impp:activities> <impp:on-the-phone/> <impp:busy/> </impp:activities> </impp:status> <impp:contact>tel:+09012345678</impp:contact> </impp:tuple> </impp:presence>
NOTIFY sip:user@host.example.com SIP/2.0 To: <sip:watcher@example.com>;tag=12341234 From: <sip:presentity@example.com>;tag=abcd1234 Call-ID: 12345678@host.example.com CSeq: 2 NOTIFY Event: presence Contact: sip:pa.example.com Content-Type: application/pidf+xml Content-Length: ... <?xml version="1.0" encoding="UTF-8"?> <impp:presence xmlns:impp="urn:ietf:params:xml:ns:pidf" entity="presentity@example.com "> <impp:tuple id="sg89ae"> <impp:status> <impp:basic>open</impp:basic> <impp:activities> <impp:on-the-phone/> <impp:busy/> </impp:activities> </impp:status> <impp:contact>tel:+09012345678</impp:contact> </impp:tuple> </impp:presence>
MESSAGE sip:user2@domain.com SIP/2.0 From: sip:user1@domain.com;tag=49583 To: sip:user2@domain.com Call-ID: asd88asd77a@1.2.3.4 CSeq: 1 MESSAGE Content-Type: text/plain Content-Length: 18 ... text here SIP/2.0 200 OK From: sip:user1@domain.com;tag=49394 To: sip:user2@domain.com;tag=ab8asdasd9 Call-ID: asd88asd77a@1.2.3.4 CSeq: 1 MESSAGE Content-Length: 0