Protocol: SIP ( Session Initiation Protocol )

SIP ( Session Initiation Protocol )

Update: 2005-11-11 15:40:28 I have words to say about this protocol

On this page

SUMMARY
DESCRIPTION
EXAMPLES
PROTOCOL RELATIONS
GLOSSARY
REFERENCES
OTHER PROTOCOLS

SUMMARY
Protocol	:	Session Initiation Protocol
Protocol suite	:	TCP/IP
Layer	:	Application Layer
Ports	:	5060 (SCTP, TCP, UDP) server default 5061 (TLS)
Related protocols	:	UDP, TCP, RTSP, HTTP, SAP, RTP, MEGACO, H.248, H.323
URI	:	sip, sips
MIME subtype	:	message/sip, message/sipfrag
Working groups	:	Enum, Telephone Number Mapping Mmusic, Multiparty Multimedia Session Control Simple, SIP for Instant Messaging and Presence Leveraging Sip, Session Initiation Protocol Sipping, Session Initiation Proposal Investigation

DESCRIPTION

SIP (Session Initiation Protocol) is an application-layer control protocol that can establish, modify, and terminate multimedia sessions such as Internet telephony calls (VOIP). These sessions include Internet multimedia conferences, Internet telephone calls and multimedia distribution. Members in a session can communicate via multicast or via a mesh of unicast relations, or a combination of these. The protocol can be compressed by using Signaling Compression.

SIP invitations used to create sessions carry session descriptions which allow participants to agree on a set of compatible media types. SIP supports user mobility by proxying and redirecting requests to the user's current location. Users can register their current location. SIP is not tied to any particular conference control protocol. SIP is designed to be independent of the lower-layer transport protocol and can be extended with additional capabilities.

Session Initiation Protocol is a protocol developed by the IETF MMUSIC Working Group 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. In November 2000, SIP was accepted as a 3GPP signaling protocol and permanent element of the IMS architecture. It is one of the leading signalling protocols for Voice over IP, along with H.323.

History
A goal for SIP was to provide a superset of the call processing functions and features present in the public switched telephone network (PSTN). As such, features that permit familiar telephone-like operations are present: dialing a number, causing a phone to ring, hearing ringback tones or a busy signal. Implementation and terminology are different.

SIP also implements many of the more advanced call processing features present in Signalling System 7 (SS7), though the two protocols themselves could hardly be more different. SS7 is a highly centralized protocol, characterized by highly complex central network architecture and dumb endpoints (traditional telephone handsets). SIP is a peer-to-peer protocol. As such it requires only a very simple (and thus highly scalable) core network with intelligence distributed to the network edge, embedded in endpoints (terminating devices built in either hardware or software). Many SIP features are implemented in the communicating endpoints as opposed to traditional SS7 features, which are implemented in the network. Although many other VoIP signaling protocols exist, SIP is characterized by its proponents as having roots in the IP community rather than the telecom industry. SIP has been standardized and governed primarily by the IETF while the H.323 VoIP protocol has been traditionally more associated with the ITU. However, the two organizations have endorsed both protocols in some fashion.

SIP works in concert with several other protocols and is only involved in the signaling portion of a communication session. SIP acts as a carrier for the Session Description Protocol (SDP), which describes the media content of the session, e.g. what IP ports to use, the codec being used etc. In typical use, SIP "sessions" are simply packet streams of the Real-time Transport Protocol (RTP). RTP is the carrier for the actual voice or video content itself.

SIP is similar to HTTP and shares some of its design principles: It is human readable and request-response structured. SIP proponents also claim it to be simpler than H.323. However, some would counter that while SIP originally had a goal of simplicity, in its current state it has become as complex as H.323. SIP shares many HTTP status codes, such as the familiar '404 not found'. The promoters of SIP have said that the rapid innovation and application development that has characterized the Web will now mark the telephony industry, too. SIP and H.323 are not limited to voice communication but can mediate any kind of communication session from voice to video or future, unrealized applications.

SIP Functionality
SIP can also invite participants to already existing sessions, such as multicast conferences. Media can be added to (and removed from) an existing session. SIP transparently supports name mapping and redirection services, which supports personal mobility - users can maintain a single externally visible identifier regardless of their network location.

SIP supports five facets of establishing and terminating multimedia communications:

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.

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 MediaGateway 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 does not provide services. Rather, SIP provides primitives that can be used to implement different services. For example, SIP can locate a user and deliver an opaque object to his current location. If this primitive is used to deliver a session description written in SDP, for instance, the endpoints can agree on the parameters of a session. If the same primitive is used to deliver a photo of the caller as well as the session description, a "caller ID" service can be easily implemented. As this example shows, a single primitive is typically used to provide several different services.

SIP does not offer conference control services such as floor control or voting and does not prescribe how a conference is to be managed. SIP can be used to initiate a session that uses some other conference control protocol. Since SIP messages and the sessions they establish can pass through entirely different networks, SIP cannot, and does not, provide any kind of network resource reservation capabilities.

The nature of the services provided make security particularly important. To that end, SIP provides a suite of security services, which include denial-of-service prevention, authentication (both user to user and proxy to user), integrity protection, and encryption and privacy services.

SIP works with both IPv4 and IPv6.

SIP message
SIP is a text-based protocol and uses the UTF-8 character set. A SIP message is either a request from a client to a server, or a response from a server to a client.

Both Request and Response messages use the basic format of RFC 2822 [3], even though the syntax differs in character set and syntax specifics. Both types of messages consist of a start-line, one or more header fields, an empty line indicating the end of the header fields, and an optional message-body.

         generic-message  =  start-line

                             *message-header

                             CRLF

                             [ message-body ]

         start-line       =  Request-Line / Status-Line

The start-line, each message-header line, and the empty line MUST be terminated by a carriage-return line-feed sequence (CRLF). Note that the empty line MUST be present even if the message-body is not.

Requests
SIP requests are distinguished by having a Request-Line for a start- line. A Request-Line contains a method name, a Request-URI, and the protocol version separated by a single space (SP) character.

The Request-Line ends with CRLF. No CR or LF are allowed except in the end-of-line CRLF sequence. No linear whitespace (LWS) is allowed in any of the elements.
Request-Line = Method SP Request-URI SP SIP-Version CRLF

SIP methods

Method	References
ACK	setting up sessions
BYE	terminating sessions
CANCEL	setting up sessions
INFO	communicating mid-session signaling information along the signaling path for the call.
INVITE	setting up sessions
MESSAGE	sending instant messages using a metaphor similar to that of a two-way pager or SMS enabled handset.
NOTIFY	using to notify a SIP node that an event which has been requested by an earlier SUBSCRIBE method has occurred.
OPTIONS	querying servers about their capabilities
PRACK	supporting reliable transmission of provisional responses.
PUBLISH	publishing event state to an entity responsible for compositing this event state.
REFER	allowing the party sending the REFER to be notified of the outcome of the referenced request.
REGISTER	registering contact information
SUBSCRIBE	requesting asynchronous notification of an event or set of events at a later time.
UPDATE	allowing the caller or callee to provide updated session information before a final response to the initial INVITE request is generated.

Request-URI
The Request-URI is a SIP or SIPS URI or a general URI. It indicates the user or service to which this request is being addressed. The Request-URI must not contain unescaped spaces or control characters and must not be enclosed in "<>".

SIP elements may support Request-URIs with schemes other than "sip" and "sips". SIP elements MAY translate non-SIP URIs using any mechanism at their disposal, resulting in SIP URI, SIPS URI, or some other scheme.

SIP-Version
Both request and response messages include the version of SIP in use, regarding version ordering, compliance requirements, and upgrading of version numbers. To be compliant with this specification, applications sending SIP messages must include a SIP-Version of "SIP/2.0". The SIP-Version string is case-insensitive, but implementations must send upper-case.

Unlike HTTP/1.1, SIP treats the version number as a literal string. In practice, this should make no difference.

Responses
SIP responses are distinguished from requests by having a Status-Line as their start-line. A Status-Line consists of the protocol version followed by a numeric Status-Code and its associated textual phrase, with each element separated by a single SP character.

No CR or LF is allowed except in the final CRLF sequence.
Status-Line = SIP-Version SP Status-Code SP Reason-Phrase CRLF

The Status-Code is a 3-digit integer result code that indicates the outcome of an attempt to understand and satisfy a request. The Reason-Phrase is intended to give a short textual description of the Status-Code. The Status-Code is intended for use by automata, whereas the Reason-Phrase is intended for the human user. A client is not required to examine or display the Reason-Phrase.

1xx: Provisional
Request received, continuing to process the request.

Code	Description
100	Trying.
101-179
180	Ringing.
181	Call is being forwarded.
182	Queued.
183	Session progress.

2xx: Success
The action was successfully received, understood, and accepted.

Code	Description
200	OK.
201
202	Accepted.

3xx: Redirection
Further action needs to be taken in order to complete the request.

Code	Description
300	Multiple choices.
301	Moved permanently.
302	Moved temporarily.
303304
305	Use proxy.
306-379
380	Alternative service.

4xx: Client error
The request contains bad syntax or cannot be fulfilled at this server.

Code	Description
400	Bad request.
401	Unauthorized.
402	Payment required.
403	Forbidden.
404	Not found.
405	Method not allowed.
406	Not acceptable.
407	Proxy authentication required.
408	Request timeout.
409
410	Gone.
411
412	Conditional request failed.
413	Request entity too large.
414	Request-URI too long.
415	Unsupported media type.
416	Unsupported URI scheme.
417418419
420	Bad extension.
421	Extension required.
422	Session Interval too small.
423	Interval too brief.
424-428
429	Provide referrer identity.
430-479
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.
490
491	Request pending.
492
493	Undecipherable.
494	Security agreement required.

5xx: Server error
The server failed to fulfill an apparently valid request.

Code	Description
500	Server internal error.
501	Not implemented.
502	Bad gateway.
503	Service unavailable.
504	Server timeout.
505	Version not supported.
506-512
513	Message too large.
514-579
580	Precondition Failure.

6xx: Global failure
The request cannot be fulfilled at any server.

Code	Description
600	Busy everywhere.
601602
603	Decline.
604	Does not exist anywhere.
605
606	Not acceptable.

Header Fields
SIP header fields are similar to HTTP header fields in both syntax and semantics. In particular, SIP header fields follow the [H4.2] definitions of syntax for the message-header and the rules for extending header fields over multiple lines. However, the latter is specified in HTTP with implicit whitespace and folding.

[H4.2] also specifies that multiple header fields of the same field name whose value is a comma-separated list can be combined into one header field. That applies to SIP as well, but the specific rule is different because of the different grammars. Specifically, any SIP header whose grammar is of the form, header = "header-name" HCOLON header-value *(COMMA header-value), allows for combining header fields of the same name into a comma - separated list. The Contact header field allows a comma-separated list unless the header field value is "*".

Top of Page

EXAMPLES

Example 1: Info uses



The following are a few of the potential uses of the INFO message:

          - Carrying mid-call PSTN signaling messages between PSTN gateways.



          - Carrying DTMF digits generated during a SIP session.



          - Carrying wireless signal strength information in support of wireless 

            mobility applications.



          - Carrying account balance information.



          - Carrying images or other non streaming information between the

            participants of a session.



These are just potential uses; this document does not specify such uses nor does it 

necessarily recommend them.



It can also be envisioned that there will be other telephony and non-telephony uses 

of the INFO method.

Example 2: Messages Method



An example message flow is shown in following. The message flow shows an initial IM 

sent from User 1 to User 2, both users in the same domain, "domain", through a single 

proxy.



           |  F1 MESSAGE          |                         |

           |--------------------> |  F2 MESSAGE             |

           |                      | ----------------------->|

           |                      |                         |

           |                      |  F3 200 OK              |

           |                      | <-----------------------|

           |  F4 200 OK           |                         |

           |<-------------------- |                         |

           |                      |                         |

           |                      |                         |

           |                      |                         |

        User 1                  Proxy

                    User 2



Message F1 looks like:

MESSAGE sip:user2@domain.com SIP/2.0

Via: SIP/2.0/TCP user1pc.domain.com;branch=z9hG4bK776sgdkse

Max-Forwards: 70

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



Watson, come here.

User1 forwards this message to the server for domain.com. The proxy receives this 

request, and recognizes that it is the server for domain.com. It looks up user2 in its 

database (built up through registrations), and finds a binding from 

sip:user2@domain.com to sip:user2@user2pc.domain.com.  It forwards the request 

to user2. The resulting message, F2, looks like:



MESSAGE sip:user2@domain.com SIP/2.0

Via: SIP/2.0/TCP proxy.domain.com;branch=z9hG4bK123dsghds

Via: SIP/2.0/TCP user1pc.domain.com;branch=z9hG4bK776sgdkse; received=1.2.3.4

Max-Forwards: 69

From: sip:user1@domain.com;tag=49394

To: sip:user2@domain.com

Call-ID: asd88asd77a@1.2.3.4

CSeq: 1 MESSAGE

Content-Type: text/plain

Content-Length: 18



Watson, come here.

The message is received by user2, displayed, and a response is generated, message 

F3, and sent to the proxy:

SIP/2.0 200 OK

Via: SIP/2.0/TCP proxy.domain.com;branch=z9hG4bK123dsghds; received=192.0.2.1

Via: SIP/2.0/TCP user1pc.domain.com;;branch=z9hG4bK776sgdkse; received=1.2.3.4

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



Note that most of the header fields are simply reflected in the response. The proxy 

receives this response, strips off the top Via, and forwards to the address in the 

next Via, user1pc.domain.com, the result being message F4:

SIP/2.0 200 OK

Via: SIP/2.0/TCP user1pc.domain.com;branch=z9hG4bK776sgdkse; received=1.2.3.4

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

Example 3: Registration



Bob registers on start-up. The message flow is shown in the following figure. Note 

that the authentication usually required for registration is not shown for simplicity.



                  biloxi.com         Bob's

                   registrar       softphone

                      |                |

                      |   REGISTER F1  |

                      |<---------------|

                      |    200 OK F2   |

                      |--------------->|



F1 REGISTER Bob -> Registrar



          REGISTER sip:registrar.biloxi.com SIP/2.0

          Via: SIP/2.0/UDP bobspc.biloxi.com:5060;branch=z9hG4bKnashds7

          Max-Forwards: 70

          To: Bob 

          From: Bob ;tag=456248

          Call-ID: 843817637684230@998sdasdh09

          CSeq: 1826 REGISTER

          Contact: 

          Expires: 7200

          Content-Length: 0



The registration expires after two hours. The registrar responds with a 200 OK:

F2 200 OK Registrar -> Bob



           SIP/2.0 200 OK

           Via: SIP/2.0/UDP bobspc.biloxi.com:5060;branch=z9hG4bKnashds7;

                 received=192.0.2.4

           To: Bob ;tag=2493k59kd

           From: Bob ;tag=456248

           Call-ID: 843817637684230@998sdasdh09

           CSeq: 1826 REGISTER

           Contact: 

           Expires: 7200

           Content-Length: 0

Top of Page

PROTOCOL RELATIONS

■ Parent layer
■ Child layer

TCP/UDP
SIP

Top of Page

GLOSSARY

CRLF
<character> /ker'l*f/, sometimes /kru'l*f/ or /C-R-L-F/ A carriage return (CR, ASCII 13) followed by a line feed (LF, ASCII 10). Under Unix influence this usage has become less common because Unix uses just line feed as its line terminator.
A carriage return (CR, ASCII 0001101) followed by a line feed (LF, ASCII 0001010). More loosely, whatever it takes to get you from the end of one line of text to the beginning of the next line.

Core
Core designates the functions specific to a particular type of SIP entity, i.e., specific to either a stateful or stateless proxy, a user agent or registrar. All cores, except those for the stateless proxy, are transaction users.

Final response
A response that terminates a SIP transaction, as opposed to a provisional response that does not. All 2xx, 3xx, 4xx, 5xx and 6xx responses are final.

H.323
H.323 is an umbrella recommendation from the ITU-T, that defines the protocols to provide audio-visual communication sessions on any packet network. It is currently implemented by various Internet real-time applications such as NetMeeting and GnomeMeeting. It is a part of the H.32x series of protocols which also address communications over ISDN, PSTN or SS7. H.323 is commonly used in Voice over IP (VoIP) and IP-based videoconferencing.

HTTP
HTTP(HyperText Transfer Protocol) defines how messages are formatted and transmitted, and what actions Web servers and browsers should take in response to various commands. For example, when you enter a URL in your browser, this actually sends an HTTP command to the Web server directing it to fetch and transmit the requested Web page.

The other main standard that controls how the World Wide Web works is HTML, which covers how Web pages are formatted and displayed.

HTTP is called a stateless protocol because each command is executed independently, without any knowledge of the commands that came before it. This is the main reason that it is difficult to implement Web sites that react intelligently to user input. This shortcoming of HTTP is being addressed in a number of new technologies, including ActiveX, Java, JavaScript and cookies.

Header field
A component of the SIP message header. A header field can appear as one or more header field rows. Header field rows consist of a header field name and zero or more header field values. Multiple header field values on a given header field row are separated by commas. Some header fields can only have a single header field value, and as a result, always appear as a single header field row.

IETF
IETF (Internet Engineering Task Force) is the main standards organization for the Internet. The IETF is a large open international community of network designers, operators, vendors, and researchers concerned with the evolution of the Internet architecture and the smooth operation of the Internet. It is open to any interested individual.

IMS
The IP Multimedia Subsystem (IMS) is an open, standardised, operator friendly, Next Generation Networking (NGN) multi-media architecture for mobile and fixed IP services. It's a VoIP implementation based on a 3GPP variant of SIP, and runs over the standard Internet protocol (IP). It's used by telecom operators in NGN networks (which combine voice and data in a single packet switched network), to offer network controlled multimedia services.

ITU
The International Telecommunication Union (ITU) is an international organization established to standardize and regulate international radio and telecommunications. It was founded as the International Telegraph Union in Paris in May 17, 1865, and is today the world's oldest international organization. Its main tasks include standardization, allocation of the radio spectrum, and organizing interconnection arrangements between different countries to allow international phone calls. It is one of the specialized agencies of the United Nations, and has its headquarters in Geneva, Switzerland, next to the main United Nations campus.

Instant messaging
Instant messaging is the act of instantly communicating between two or more people over a network such as the Internet.

Loop
Loop is a request that arrives at a proxy, is forwarded, and later arrives back at the same proxy. When it arrives the second time, its Request-URI is identical to the first time, and other header fields that affect proxy operation are unchanged, so that the proxy would make the same processing decision on the request it made the first time. Looped requests are errors, and the procedures for detecting them and handling them are described by the protocol.

MEGACO
Media Gateway Control Protocol (MGCP) is a protocol used within a Voice over IP system. MGCP is defined in an informational (non-standard) IETF document. It superseded the Simple Gateway Control Protocol (SGCP). MGCP is an internal protocol used within a distributed system that can appear to the outside world as a single VoIP gateway.

Multimedia
The use of computers to present text, graphics, video, animation, and sound in an integrated way. Long touted as the future revolution in computing, multimedia applications were, until the mid-90s, uncommon due to the expensive hardware required. With increases in performance and decreases in price, however, multimedia is now commonplace. Nearly all PCs are capable of displaying video, though the resolution available depends on the power of the computer's video adapter and CPU.

PSTN
PSTN (Public Switched Telephone Network), which refers to the international telephone system based on copper wires carrying analog voice data. This is in contrast to newer telephone networks base on digital technologies, such as ISDN and FDDI.

Proxy server
An intermediary entity that acts as both a server and a client for the purpose of making requests on behalf of other clients. 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. Proxies are also useful for enforcing policy (for example, making sure a user is allowed to make a call). A proxy interprets, and, if necessary, rewrites specific parts of a request message before forwarding it.

RTP
RTP (Real-Time Transport Protocol) is an Internet protocol for transmitting real-time data such as audio and video. RTP itself does not guarantee real-time delivery of data, but it does provide mechanisms for the sending and receiving applications to support streaming data. Typically, RTP runs on top of the UDP protocol, although the specification is general enough to support other transport protocols.

RTSP
Real Time Streaming Protocol (RTSP) is a standard for controlling streaming data over the World Wide Web. Like H.323, RTSP uses RTP (Real-Time Transport Protocol) to format packets of multimedia content. But whereas H.323 is designed for videoconferencing of moderately-sized groups, RTSP is designed to efficiently broadcast audio-visual data to large groups.

Ringback
The signaling tone produced by the calling party's application indicating that a called party is being alerted (ringing).

SDP
Session Description Protocol, a protocol that defines a text-based format for describing streaming media sessions and multicast transmissions. SDP is not a transport protocol but a method of describing the details of the transmission. For example, an SDP file contains information about the format, timing and authorship of the transmission, name and purpose of the session, any media, protocols or codec formats, the version number, contact information and broadcast times.

SIP
Session Initiated Protocol (SIP) is an application-layer control protocol; a signaling protocol for Internet Telephony. SIP can establish sessions for features such as audio/videoconferencing, interactive gaming, and call forwarding to be deployed over IP networks, thus enabling service providers to integrate basic IP telephony services with Web, e-mail, and chat services.

Server
A computer or device on a network that manages network resources. For example, a file server is a computer and storage device dedicated to storing files. Any user on the network can store files on the server. A database server is a computer system that processes database queries. Servers are often dedicated, meaning that they perform no other tasks besides their server tasks. On multiprocessing operating systems, however, a single computer can execute several programs at once. A server in this case could refer to the program that is managing resources rather than the entire computer.

Session
The session of activity that a user with a unique IP address spends on a Web site during a specified period of time. The number of user sessions on a site is used in measuring the amount of traffic a Web site gets. The site administrator determines what the time frame of a user session will be (e.g., 30 minutes).

If the visitor comes back to the site within that time period, it is still considered one user session because any number of visits within that 30 minutes will only count as one session. If the visitor returns to the site after the allotted time period has expired, say an hour from the initial visit, then it is counted as a separate user session.

URI
URI (Uniform Resource Identifier) is the generic term for all types of names and addresses that refer to objects on the World Wide Web. A URL is one kind of URI.

UTF-8
UTF(Unicode Transformation Format) preserving the full US-ASCII range, providing compatibility with file systems, parsers and other software that rely on US-ASCII values but are transparent to other values.

UTF-8 encodes UCS-2 or UCS-4 characters as a varying number of octets, where the number of octets, and the value of each, depend on the integer value assigned to the character in ISO/IEC 10646.

VOIP
Voice over Internet Protocol, a category of hardware and software that enables people to use the Internet as the transmission medium for telephone calls by sending voice data in packets using IP rather than by traditional circuit transmissions of the PSTN. One advantage of VoIP is that the telephone calls over the Internet do not incur a surcharge beyond what the user is paying for Internet access, much in the same way that the user doesn't pay for sending individual e-mails over the Internet.

VR
Virtual reality (VR) is an environment that is simulated by a computer. Most virtual reality environments are primarily visual experiences, displayed either on a computer screen or through special stereoscopic displays, but some simulations include additional sensory information, such as sound through speakers or headphones. Some advanced and experimental systems have included limited tactile feedback.

Top of Page

REFERENCES

Related links:
Columbia University of Computer Science SIP page
SIP parameters

RFCs:
[RFC 2848] The PINT Service Protocol: Extensions to SIP and SDP for IP Access to Telephone Call Services.
[RFC 2976] The SIP INFO Method.
[RFC 3027] Protocol Complications with the IP Network Address Translator.
[RFC 3050] Common Gateway Interface for SIP.
[RFC 3087] Control of Service Context using SIP Request-URI.
[RFC 3261] SIP: Session Initiation Protocol.
                Defines URI schemes sip: and sips:.
                Updated by: RFC 3853.
                Obsoletes: RFC 2543.
[RFC 3262] Reliability of Provisional Responses in the Session Initiation Protocol (SIP).
                Obsoletes: RFC 2543.
[RFC 3263] Session Initiation Protocol (SIP): Locating SIP Servers.
                Obsoletes: RFC 2543.
[RFC 3265] Session Initiation Protocol (SIP)-Specific Event Notification.
                Updates: RFC 2543.
[RFC 3311] The Session Initiation Protocol (SIP) UPDATE Method.
                Defines SIP method UPDATE.
[RFC 3312] Integration of Resource Management and Session Initiation Protocol (SIP).
                Updated by: RFC 4032.
                Defines SIP Quality of Service preconditions.
[RFC 3313] Private Session Initiation Protocol (SIP) Extensions for Media Authorization.
                Defines SIP header field P-Media-Authorization.
[RFC 3323] A Privacy Mechanism for the Session Initiation Protocol (SIP).
                Defines SIP header field Privacy and option tag privacy.
[RFC 3324] Short Term Requirements for Network Asserted Identity.
[RFC 3325] Private Extensions to the Session Initiation Protocol (SIP) for Asserted Identity within Trusted Networks.
                Defines SIP header fields P-Asserted-Identity and P-Preferred-Identity.
[RFC 3326] The Reason Header Field for the Session Initiation Protocol (SIP).
                Defines SIP header field Reason.
[RFC 3327] Session Initiation Protocol (SIP) Extension Header Field for Registering Non-Adjacent Contacts.
                Defines SIP header field Path and option tag path.
[RFC 3329] Security Mechanism Agreement for the Session Initiation Protocol (SIP).
                Defines SIP header fields Security-Client, Security-Server, Security-Verify.
[RFC 3351] User Requirements for the Session Initiation Protocol (SIP) in Support of Deaf, Hard of Hearing and Speech-impaired Individuals.
[RFC 3372] Session Initiation Protocol for Telephones (SIP-T): Context and Architectures.
[RFC 3398] Integrated Services Digital Network (ISDN) User Part (ISUP) to Session Initiation Protocol (SIP) Mapping.
[RFC 3420] Internet Media Type message/sipfrag.
                Defines MIME media subtype message/sipfrag.
[RFC 3427] Change Process for the Session Initiation Protocol (SIP).
                BCP: 67.
                Updated by: RFC 3968, RFC 3969.
[RFC 3428] Session Initiation Protocol (SIP) Extension for Instant Messaging.
                Defines SIP method MESSAGE.
[RFC 3455] Private Header (P-Header) Extensions to the Session Initiation Protocol (SIP) for the 3rd-Generation Partnership Project (3GPP).
                Defines SIP header fields P-Associated-URI, P-Called-Party-ID, P-Visited-Network-ID, P-Access-Network-Info, P-Charging-Function-Addresses, P-Charging-Vector.
[RFC 3485] The Session Initiation Protocol (SIP) and Session Description Protocol (SDP) Static Dictionary for Signaling Compression (SigComp).
                Defines the SIP/SDP specific static dictionary for SigComp.
[RFC 3486] Compressing the Session Initiation Protocol (SIP).
[RFC 3487] Requirements for Resource Priority Mechanisms for the Session Initiation Protocol (SIP).
[RFC 3515] The Session Initiation Protocol (SIP) Refer Method.
                Defines SIP method REFER and header field Refer-To.
[RFC 3578] Mapping of Integrated Services Digital Network (ISDN) User Part (ISUP) Overlap Signalling to the Session Initiation Protocol (SIP).
[RFC 3581] An Extension to the Session Initiation Protocol (SIP) for Symmetric Response Routing.
                Defines SIP Via header field parameter rport.
[RFC 3603] Private Session Initiation Protocol (SIP) Proxy-to-Proxy Extensions for Supporting the PacketCable Distributed Call Signaling Architecture.
                Defines SIP extension headers P-DCS-Trace-Party-ID, P-DCS-OSPS, P-DCS-Billing-Info, P-DCS-LAES, P-DCS-Redirect.
[RFC 3608] Session Initiation Protocol (SIP) Extension Header Field for Service Route Discovery During Registration.
                Defines SIP extension header field Service-Route.
[RFC 3665] Session Initiation Protocol (SIP) Basic Call Flow Examples.
                BCP: 75.
[RFC 3666] Session Initiation Protocol (SIP) Public Switched Telephone Network (PSTN) Call Flows.
                BCP: 76.
[RFC 3680] A Session Initiation Protocol (SIP) Event Package for Registrations.
                Defines MIME media subtype application/reginfo+xml.
[RFC 3702] Authentication, Authorization, and Accounting Requirements for the Session Initiation Protocol (SIP).
[RFC 3725] Best Current Practices for Third Party Call Control (3pcc) in the Session Initiation Protocol (SIP).
                BCP: 85.
[RFC 3764] enumservice registration for Session Initiation Protocol (SIP) Addresses-of-Record.
[RFC 3840] Indicating User Agent Capabilities in the Session Initiation Protocol (SIP).
[RFC 3841] Caller Preferences for the Session Initiation Protocol (SIP).
                Defines SIP request header fields Accept-Contact, Reject-Contact and Request-Disposition.
[RFC 3842] A Message Summary and Message Waiting Indication Event Package for the Session Initiation Protocol (SIP).
                Defines MIME media subtype application/simple-message-summary.
[RFC 3856] A Presence Event Package for the Session Initiation Protocol (SIP).
[RFC 3857] A Watcher Information Event Template-Package for the Session Initiation Protocol (SIP).
[RFC 3858] An Extensible Markup Language (XML) Based Format for Watcher Information.
                Defines MIME media subtype application/watcherinfo+xml.
[RFC 3891] The Session Initiation Protocol (SIP) "Replaces" Header.
                Defines SIP request header field Replaces.
[RFC 3892] The Session Initiation Protocol (SIP) Referred-By Mechanism.
                Defines SIP request header field Referred-By.
[RFC 3893] Session Initiation Protocol (SIP) Authenticated Identity Body (AIB) Format.
[RFC 3903] Session Initiation Protocol (SIP) Extension for Event State Publication.
                Defines SIP method PUBLISH.
                Defines SIP header fields SIP-ETag and SIP-If-Match.
[RFC 3911] The Session Initiation Protocol (SIP) "Join" Header.
                Defines SIP header field Join.
[RFC 3959] The Early Session Disposition Type for the Session Initiation Protocol (SIP).
                Defines SIP option tag early-session.
[RFC 3960] Early Media and Ringing Tone Generation in the Session Initiation Protocol (SIP).
[RFC 3968] The Internet Assigned Number Authority (IANA) Header Field Parameter Registry for the Session Initiation Protocol (SIP).
                BCP: 98.
                Updates: RFC 3427.
[RFC 3969] The Internet Assigned Number Authority (IANA) Uniform Resource Identifier (URI) Parameter Registry for the Session Initiation Protocol (SIP).
                BCP: 99.
                Updates: RFC 3427.
[RFC 3976] Interworking SIP and Intelligent Network (IN) Applications.
[RFC 4032] Update to the Session Initiation Protocol (SIP) Preconditions Framework.
                Updates: RFC 3312.
[RFC 4028] Session Timers in the Session Initiation Protocol (SIP).
                Defines SIP header fields Min-SE and Session-Expires.
[RFC 4083] Input 3rd-Generation Partnership Project (3GPP) Release 5 Requirements on the Session Initiation Protocol (SIP).
[RFC 4092] Usage of the Session Description Protocol (SDP) Alternative Network Address Types (ANAT) Semantics in the Session Initiation Protocol (SIP).
                Defines SIP option tag sdp-anat.
[RFC 4117] Transcoding Services Invocation in the Session Initiation Protocol (SIP) Using Third Party Call Control (3pcc).
[RFC 4123] Session Initiation Protocol (SIP)-H.323 Interworking Requirements.
[RFC 4168] The Stream Control Transmission Protocol (SCTP) as a Transport for the Session Initiation Protocol (SIP).

Obsolete RFCs:
[RFC 2543] SIP: Session Initiation Protocol.
Obsoleted by: RFC 3261, RFC 3262, RFC 3263, RFC 3264, RFC 3265.
Defines the SIP protocol.

Publications:
[ISBN 0471413992] Internet Communications Using SIP.
[ISBN 0071373403] SIP Demystified.
[ISBN 1580531687] SIP: Understanding the Session Initiation Protocol.

Top of Page

OTHER PROTOCOLS OF TCP/IP SUITE