Pages

Monday, February 22, 2010

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

Sunday, February 21, 2010

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..