Session Initiation Protocol (SIP) Technical Guide

An Introduction to the SIP Protocol

The SIP protocol is an IP telephony control signaling protocol that is used for establishing and terminating media and telephony sessions (voice, video, etc) between one or more participants. The protocol runs on the application layer of the OSI model.

This article covers various topics associated with the Session Initiation Protocol, including history, terminology, codes, the differences between versions 1.0 and 2.0, its basic operation, a look at ports and then a comprehensive list of associated RFCs.

Some History

Session Initiation Protocol was first introduced in March 1999 by IETF RFC 2543. This RFC (Request for Comments) was the original core specification and was obsolete by IETF RFC 3261 in June 2002. These RFC’s are more commonly known as SIP 1.0 (2543) and SIP 2.0 (3261). There are many related RFCs that are summarized at the end of this document.

Terminology

As with most protocols, a number of acronyms are used when referring to session initiation protocol. These are listed as follows:

Components of SIP

• UAC - User Agent Client. Initiates the call signaling
• UAS - User Agent Server. Responds to the signaling from the UAC
• UA - User Agent - Phones, gateways or other devices that act as either a server or client
• URI - Uniform Resource Identifier - Use for SIP identity and is similar to an email address. As example, a SIP URI could be sip:johns@xyzcorp.com
• Proxy Server - Manages connection requests between UA and other proxy servers. Also provides authentication and authorization.
• Redirect Server - Directs client to contact alternate Uniform Resource Identifier's (URI)

Message Requests

• INVITE - request a connection
• ACK - acknowledge the INVITE request. ACK is sent by receiving endpoint
• BYE - terminates the connection
• CANCEL - terminate a connection that has not yet been established
• REGISTER - user agent registration to SIP proxy
• OPTIONS - request for server options
• NOTIFY - notify that an event has occurred
• PRACK - provisional acknowledgement
• SUBSCRIBE - requests current current state and state updates
• PUBLISH - Informs subscriber of the state of the resource
• INFO - sends session information
• REFER - recipient can refer (e.g. request call transfer)
• MESSAGE - extension to SIP used for instant messages
• UPDATE - allows the state of the session to be updated

SIP Codes

SIP response codes are answers to SIP messages that are in digital format. They are used by the Session Initiation Protocol for communication and are responses to SIP requests.

Response Codes

Detailed information on the majority of the response codes can be found in RFC 3261 section 21. There are some SIP codes that are not covered in the aforementioned RFC and are specified in other RFCs. These RFC's have been listed next to the response in the following list to make it easier to obtain more details.

• 1XX - Information messages also know as provisional responses (100 - Trying, 180 - Ringing, 181 - Call is being Forwarded, 182 - Call Queued, 183 - Session Progress, 199 - Early Dialog Terminated)
• 2XX - Successful Request Completion - Received, understood and accepted (200 - OK, 202 - Accepted, 204 - No Notification)
• 3XX - Redirection messages that provide location information or alternative services (300 - Multiple Choices, 301 - Moved Permanently, 302 - Moved Temporarily, 305 - Use Proxy, 380 - Alternative Service)
• 4XX - Request Failure codes (400 - Bad Request, 401 - Unauthorized, 402 - Payment Required, 403 - Forbidden, 404 - Not Found, 405 - Method not Allowed, 406 - Not Acceptable, 407 - Proxy Identification Required, 408 - Request Timeout, 410 - Gone, 412 - Conditional Request Failed (RFC 3903), 413 - Request Entity too Large, 414 - Request URI too Long, 415 - Unsupported Media Type, 416 - Unsupported URI scheme, 417 - Unknown Resource-Priority (RFC 4412), 420 - Bad Extension, 421 - Extension Required, 422- Session Interval too Small (RFC 4028), 423 - Interval too Brief, 424 - Bad Location information (RFC 6442), 428 - Use Identity Header (RFC 4474), 429 - Provide Referrer Identity (RFC 3892), 433 - Anonymity Disallowed (RFC 5079), 436 - Bad Identity Info (RFC 4424), 437 - Unsupported Certificate (RFC 4424), 438 - Invalid Identity Header (RFC 4424), 470 - Consent Needed (RFC 5360), 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 (RFC 3265), 491 - Request Pending, 493 - Undecipherable, 494 - Security Agreement Required (RFC 3329))
• 5XX - Server Failure response codes (501 - Not Implemented, 502 Bad Gateway, 503 - Service Unavailable, 504 - Server Timeout, 505 - Version Not Supported, 513 - Message too Large, 580 - Precondition Failure)
• 6XX - Global Failures (600 - Busy Everywhere, 603 - Decline, 604 - Does not exist Anywhere, 606 - Not Acceptable)

Commonly Used Codes

Although there are a number of response codes available for use, there are some that are more commonly used, as follows:

• 1XX - 100 (Trying), 180 (Ringing), 183 (Progress)
• 2XX - 200 (OK)
• 3XX - 302 (Temporarily Removed, 305 - Use Proxy)
• 4XX - 403 (Forbidden)
• 5XX - 500 (Server Internal Failure), 501 (Not Implemented)
• 6XX - 606 (Not Acceptable)

Differences between SIP 1.0 and 2.0

There is some confusion around the differences between versions 1.0 and 2.0. Although the changes are listed in the SIP 2.0 RFC, it is not the easiest document to comprehend. As such the table below outlines the major functional differences.

Although every newly released SIP endpoint (e.g. phones) should support 2.0, not all will be backward compatible to 1.0. So be aware of this when making purchase decisions. Some of the differences in these protocols are summarized as follows with RFC 3261 section 28 being used as the reference document.

Feature or Specification Change	1.0 (RFC 2543)	2.0 (RFC 3261)
BYE can only be sent on an existing call leg	(can be sent at any time)
BNF is RFC 2234 compliant
BNF was made more general. More characters allowed.
Via hiding was removed.
CANCEL and INVITE transactions	Intermingled	Separated
CANCEL and BYE transactions	Intermingled	Separated
User Agents have to support UDP and TCP	(only has to support UDP)
Proxies must collect all challenges & place into forwards response
Digest Credentials are clarified
SDP processing now a separate specification
Supports IPv6 in URIs & in Via header and square brackets & colons are permitted
DNS SRV now documented in separate specification
Loop detection is now optional. Specification corrected.	(Serious loop detection bug existed)
Tag usage is mandatory	(usage is optional
Supported header field
All Extension parameters exist	(some are missing)
Handling of Route & Record-Route construction reworked.		(this is a major change in SIP 2.0)
Lines in a message can be terminated using only CRLF	(can also use CR and LF)
Route in CANCEL & ACK is now well defined
Multiple requests in single UDP packet are not allowed
Usage of Absolute time in expires header & parameter allowed		(replaced with relative times)
Branch element of Via header mandatory	(optional)
No coupling between TCP connection state and SIP processing	(TCP connection was equivalent to CANCEL)
UA can initiate a new transaction while another in progress. Allowed for non-INVITE request, disallowed for INVITE	(nothing specified)
PGP removed		(Replaced with S/MIME)
"sips" URI scheme added for end-to-end TLS
Additional security added with TLS
Proxy required to forward provisional responses from 101 to 199 upstream	(Not required)	(Mandatory)
Detailed 503 responses code specification
Mutual authentication procedures of RFC 2617 are allowed
UA cannot send a BYE for a call before it receives an ACK for initial INVITE
UA or proxy cannot send CANCEL for a transaction before a response is received.
Action parameter no longer exists
Multicast role is limited	(heavily used)
Basic authentication removed
Proxies cannot forward a 6XX immediately upon receipt.	(forwarding allowed)
New procedures defined for to address request merging issue

The table above focuses on the major functional changes. There are also some minor functional changes that are documented in section 28.2 of RFC3261.

In summary, if you are considering purchasing any equipment that is going to work with SIP, double check that it is SIP 2.0 that is supported.

Basic Operation of SIP

At a very basic level, a typical communication between two SIP phones works as follows:

1. Phone A - Sends an INVITE request to PROXY server.
2. PROXY Server - Forwards INVITE to destination PHONE B and also sends a 100 (Trying) response code to Phone A.
3. Phone B - responds with a 183 (Session Progress) code to PROXY server
4. PROXY Server - receives 183 code and passes it on to Phone A
5. Phone B - responds with a 200 (OK) code to PROXY server
6. PROXY Server - receives 200 code and passes it on to Phone A
7. Phone A - Sends an ACK to PROXY server that is then passed onto Phone B to acknowledge the OK and establish the SIP session.

For SIP to function correctly throughout the network, SIP ports will need to be opened and use consistent values across devices.

SIP Ports

What is a TCP/UDP Port?

If you are looking for information on SIP ports, you most likely are very familiar with what a TCP/UDP port is, but just in case you are not, it is quickly covered here.

Let's start with a simple analogy. For the majority of the population, a port is something that a boat or airplane uses for transfer of passengers and goods. They basically allow (or prevent) entry and exit. Airports have three digit identifier codes such as SFO for San Francisco International airport. So SFO is a good entry and exit point if you want to visit San Francisco and are thinking of flying.

Along the same lines, ports on the Internet (TCP/UDP ports) are numbered codes that are assigned to different protocols and provide access if open. For example if you are trying to telnet into a company's corporate website from outside the company and you do not have permission, the telnet port (23) will be blocked (as well as most others) by corporate security. So ports can be basically blocked or opened depending on the use.

The most commonly used port numbers range from 0 to 1023 but the range does continue into the tens of thousands for less commonly used protocols or for product specific protocols. A good reference for all TCP and UDP port numbers can be found at Wikipedia.

The port numbers and functions are listed as follows:

• 5060 - This is both a TCP and UDP port and is the default used for SIP communications.
• 5061 - This is a TCP only port and SIP over TLS (Transport Layer Security)

Check the ports that each item of equipment is using if you are running into issues.

SIP RFCs

Core

The two core RFCs are:

• RFC 2543 (SIP 1.0)
• RFC 3261 (SIP 2.0)

Related

The following lists the related RFCs.

• RFC 2848 - The PINT Service Protocol: Extensions to SIP and SDP for IP Access to Telephone Call Service
• RFC 2976 - The SIP INFO Method
• RFC 3050 - Common Gateway Interface for SIP
• RFC 3087 - Control of Service Context using SIP Request-URI
• RFC 3262 - Reliability of Provisional Responses in the Session Initiation Protocol
• RFC 3263 - Session Initiation Protocol: Locating SIP Servers
• RFC 3264 - An Offer/Answer Model with the Session Description Protocol (SDP)
• RFC 3265 - Session Initiation Protocol -Specific Event Notification
• RFC 3311 - The Session Initiation Protocol UPDATE Method
• RFC 3312 - Integration of Resource Management and SIP
• RFC 3313 - Private Session Initiation Protocol Extensions for Media Authorization
• RFC 3319 - Dynamic Host Configuration Protocol (DHCPv6) Options for Session Initiation Protocol Servers
• RFC 3323 - A Privacy Mechanism for the Session Initiation Protocol
• RFC 3324 - Short Term Requirements for Network Asserted Identity
• RFC 3325 - Private Extensions to the Session Initiation Protocol for Asserted Identity within Trusted Networks
• RFC 3326 - The Reason Header Field for the Session Initiation Protocol
• RFC 3327 - Session Initiation Protocol Extension Header Field for Registering Non-Adjacent Contacts
• RFC 3329 - Security Mechanism Agreement for the Session Initiation Protocol
• RFC 3361 - Dynamic Host Configuration Protocol (DHCP-for-IPv4) Option for Session Initiation Protocol (SIP) Servers
• RFC 3388 - Grouping of Media Lines in the Session Description Protocol (SDP)
• RFC 3420 - Internet Media Type message/sipfrag
• RFC 3428 - Session Initiation ProtocolExtension for Instant Messaging
• RFC 3485 - The Session Initiation Protocol and Session Description Protocol (SDP) Static Dictionary for Signaling Compression (SigComp)
• RFC 3486 - Compressing the Session Initiation Protocol
• RFC 3487 - Requirements for Resource Priority Mechanisms for the Session Initiation Protocol
• RFC 3515 - The Session Initiation Protocol Refer Method
• RFC 3524 - Mapping of Media Streams to Resource Reservation Flows
• RFC 3966 - The tel URI for Telephone Numbers