 |
 |
 |
SIP is a text-based protocol and uses the UTF-8 charset. SIP is a text-based protocol with syntax similar to that of HTTP. There are two different types of SIP messages: requests and responses. The first line of a request has a method, defining the nature of the request, and a Request-URI, indicating where the request should be sent. The first line of a response has a response code.
For SIP requests, RFC 3261 defines the following methods:
* REGISTER: Used by a UA to notify its current IP address and the URLs for which it would like to receive calls.
* INVITE: Used to establish a media session between user agents.
* ACK: Confirms reliable message exchanges.
* CANCEL: Terminates a pending request.
* BYE: Terminates a session between two users in a conference.
* OPTIONS: Requests information about the capabilities of a caller, without setting up a call.
The SIP response types defined in RFC 3261 fall in one of the following categories:
* Provisional (1xx): Request received and being processed.
* Success (2xx): The action was successfully received, understood, and accepted.
* Redirection (3xx): Further action needs to be taken (typically by sender) to complete the request.
* Client Error (4xx): The request contains bad syntax or cannot be fulfilled at the server.
* Server Error (5xx): The server failed to fulfill an apparently valid request.
* Global Failure (6xx): The request cannot be fulfilled at any server.
For SIP requests, RFC 3261 defines the following methods:
* REGISTER: Used by a UA to notify its current IP address and the URLs for which it would like to receive calls.
* INVITE: Used to establish a media session between user agents.
* ACK: Confirms reliable message exchanges.
* CANCEL: Terminates a pending request.
* BYE: Terminates a session between two users in a conference.
* OPTIONS: Requests information about the capabilities of a caller, without setting up a call.
The SIP response types defined in RFC 3261 fall in one of the following categories:
* Provisional (1xx): Request received and being processed.
* Success (2xx): The action was successfully received, understood, and accepted.
* Redirection (3xx): Further action needs to be taken (typically by sender) to complete the request.
* Client Error (4xx): The request contains bad syntax or cannot be fulfilled at the server.
* Server Error (5xx): The server failed to fulfill an apparently valid request.
* Global Failure (6xx): The request cannot be fulfilled at any server.
Applications
Many VoIP phone companies allow customers to bring their own SIP devices, as SIP-capable telephone sets, or softphones. The market for consumer SIP devices continues to expand, there are many devices such as SIP Terminal Adapters, SIP Gateways etc.
The free software community started to provide more and more of the SIP technology required to build both end points as well as proxy and registrar servers leading to a commodification of the technology, which accelerates global adoption. As an example, the open source community at SIPfoundry actively develops a variety of SIP stacks, client applications and SDKs, in addition to entire IP PBX solutions that compete in the market against mostly proprietary IP PBX implementations from established vendors.
The National Institute of Standards and Technology (NIST), Advanced Networking Technologies Division provides a public domain implementation of the JAVA Standard for SIP JAIN-SIP which serves as a reference implementation for the standard. The stack can work in proxy server or user agent scenarios and has been used in numerous commercial and research projects. It supports RFC 3261 in full and a number of extension RFCs including RFC 3265 (Subscribe / Notify) and RFC 3262 (Provisional Reliable Responses) etc.
SIP-ISUP interworking
SIP-I, or the Session Initiation Protocol with encapsulated ISUP, is a protocol used to create, modify, and terminate communication sessions based on ISUP using SIP and IP networks. Services using SIP-I include voice, video telephony, fax and data. SIP-I and SIP-T[14] are two protocols with similar features, notably to allow ISUP messages to be transported over SIP networks. This preserves all of the detail available in the ISUP header, which is important as there are many country-specific variants of ISUP that have been implemented over the last 30 years, and it is not always possible to express all of the same detail using a native SIP message. SIP-I was defined by the ITU-T, where SIP-T was defined via the IETF RFC route.
SIP can be regarded as the enabler protocol for telephony and voice over IP (VoIP) services. The following features of SIP play a major role in the enablement of IP telephony and VoIP:
* Name Translation and User Location - Ensuring that the call reaches the called party wherever they are located. Carrying out any mapping of descriptive information to location information. Ensuring that details of the nature of the call (Session) are supported.
* Feature Negotiation - This allows the group involved in a call (this may be a multi-party call) to agree on the features supported – recognizing that not all the parties can support the same level of features. For example video may or may not be supported; as any form of MIME type is supported by SIP, there is plenty of scope for negotiation. Call Participant Management - During a call a participant can bring other users onto the call or cancel connections to other users. In addition, users could be transferred or placed on hold.
* Call feature changes - A user should be able to change the call characteristics during the course of the call. For example, a call may have been set up as ‘voice-only’, but in the course of the call, the users may need to enable a video function. A third party joining a call may require different features to be enabled in order to participate in the call
* Media negotiation – The inherent SIP mechanisms that enable negotiation of the media used in a call, enable selection of the appropriate codex for establishing a call between the various devices. This way, less advanced devices can participate in the call, provided the appropriate codex is selected.
Below is are some of other SIP features that distinguish it among new signaling protocols
* SIP messages are text based and hence are easy to read and debug. Programming new services is easier and more intuitive for designers.
* SIP re-uses MIME type description in the same way that email clients do, so applications associated with sessions can be launched automatically.
* SIP re-uses several existing and mature internet services and protocols such as DNS, RTP, RSVP etc. No new services have to be introduced to support the SIP infrastructure, as much of it is already in place or available off the shelf.
* SIP extensions are easily defined, enabling service providers to add them for new applications without damaging their networks. Older SIP-based equipment in the network will not impede newer SIP-based services. For example, an older SIP implementation that does not support method/ header utilized by a newer SIP application would simply ignore it. SIP is transport layer independent. Therefore, the underlying transport could be IP over ATM. SIP uses the User Datagram Protocol, (UDP) as well as the Transmission Control Protocol (TCP) protocol, flexibly connecting users independent of the underlying infrastructure.
* SIP supports multi-device feature levelling and negotiation. If a service or session initiates video and voice, voice can still be transmitted to non-video enabled devices, or other device features can be used such as one way video streaming.
SIP sessions utilize up to four major components: SIP User Agents, SIP Registrar Servers, SIP Proxy Servers and SIP Redirect Servers. Together, these systems deliver messages embedded with the SDP protocol defining their content
and characteristics to complete a SIP session.
Many VoIP phone companies allow customers to bring their own SIP devices, as SIP-capable telephone sets, or softphones. The market for consumer SIP devices continues to expand, there are many devices such as SIP Terminal Adapters, SIP Gateways etc.
The free software community started to provide more and more of the SIP technology required to build both end points as well as proxy and registrar servers leading to a commodification of the technology, which accelerates global adoption. As an example, the open source community at SIPfoundry actively develops a variety of SIP stacks, client applications and SDKs, in addition to entire IP PBX solutions that compete in the market against mostly proprietary IP PBX implementations from established vendors.
The National Institute of Standards and Technology (NIST), Advanced Networking Technologies Division provides a public domain implementation of the JAVA Standard for SIP JAIN-SIP which serves as a reference implementation for the standard. The stack can work in proxy server or user agent scenarios and has been used in numerous commercial and research projects. It supports RFC 3261 in full and a number of extension RFCs including RFC 3265 (Subscribe / Notify) and RFC 3262 (Provisional Reliable Responses) etc.
SIP-ISUP interworking
SIP-I, or the Session Initiation Protocol with encapsulated ISUP, is a protocol used to create, modify, and terminate communication sessions based on ISUP using SIP and IP networks. Services using SIP-I include voice, video telephony, fax and data. SIP-I and SIP-T[14] are two protocols with similar features, notably to allow ISUP messages to be transported over SIP networks. This preserves all of the detail available in the ISUP header, which is important as there are many country-specific variants of ISUP that have been implemented over the last 30 years, and it is not always possible to express all of the same detail using a native SIP message. SIP-I was defined by the ITU-T, where SIP-T was defined via the IETF RFC route.
SIP can be regarded as the enabler protocol for telephony and voice over IP (VoIP) services. The following features of SIP play a major role in the enablement of IP telephony and VoIP:
* Name Translation and User Location - Ensuring that the call reaches the called party wherever they are located. Carrying out any mapping of descriptive information to location information. Ensuring that details of the nature of the call (Session) are supported.
* Feature Negotiation - This allows the group involved in a call (this may be a multi-party call) to agree on the features supported – recognizing that not all the parties can support the same level of features. For example video may or may not be supported; as any form of MIME type is supported by SIP, there is plenty of scope for negotiation. Call Participant Management - During a call a participant can bring other users onto the call or cancel connections to other users. In addition, users could be transferred or placed on hold.
* Call feature changes - A user should be able to change the call characteristics during the course of the call. For example, a call may have been set up as ‘voice-only’, but in the course of the call, the users may need to enable a video function. A third party joining a call may require different features to be enabled in order to participate in the call
* Media negotiation – The inherent SIP mechanisms that enable negotiation of the media used in a call, enable selection of the appropriate codex for establishing a call between the various devices. This way, less advanced devices can participate in the call, provided the appropriate codex is selected.
Below is are some of other SIP features that distinguish it among new signaling protocols
* SIP messages are text based and hence are easy to read and debug. Programming new services is easier and more intuitive for designers.
* SIP re-uses MIME type description in the same way that email clients do, so applications associated with sessions can be launched automatically.
* SIP re-uses several existing and mature internet services and protocols such as DNS, RTP, RSVP etc. No new services have to be introduced to support the SIP infrastructure, as much of it is already in place or available off the shelf.
* SIP extensions are easily defined, enabling service providers to add them for new applications without damaging their networks. Older SIP-based equipment in the network will not impede newer SIP-based services. For example, an older SIP implementation that does not support method/ header utilized by a newer SIP application would simply ignore it. SIP is transport layer independent. Therefore, the underlying transport could be IP over ATM. SIP uses the User Datagram Protocol, (UDP) as well as the Transmission Control Protocol (TCP) protocol, flexibly connecting users independent of the underlying infrastructure.
* SIP supports multi-device feature levelling and negotiation. If a service or session initiates video and voice, voice can still be transmitted to non-video enabled devices, or other device features can be used such as one way video streaming.
SIP sessions utilize up to four major components: SIP User Agents, SIP Registrar Servers, SIP Proxy Servers and SIP Redirect Servers. Together, these systems deliver messages embedded with the SDP protocol defining their content
and characteristics to complete a SIP session.
SIP Messages
Instant messaging (IM) and presence
The Session Initiation Protocol for Instant Messaging and Presence Leveraging Extensions (SIMPLE) is the SIP-based suite of standards for instant messaging and presence information. During an instant message session, files can be transferred using, for example, MSRP (Message Session Relay Protocol).
Some efforts have been made to integrate SIP-based VoIP with the XMPP specification. Most notably Google Talk, which extends XMPP to support voice, plans to integrate SIP. Google's XMPP extension is called Jingle and, like SIP, it acts as a Session Description Protocol carrier.
Conformance testing
TTCN-3 test specification language is used for the purposes of specifying conformance tests for SIP implementations. SIP test suite is developed by a Specialist Task Force at ETSI (STF 196).
The Session Initiation Protocol for Instant Messaging and Presence Leveraging Extensions (SIMPLE) is the SIP-based suite of standards for instant messaging and presence information. During an instant message session, files can be transferred using, for example, MSRP (Message Session Relay Protocol).
Some efforts have been made to integrate SIP-based VoIP with the XMPP specification. Most notably Google Talk, which extends XMPP to support voice, plans to integrate SIP. Google's XMPP extension is called Jingle and, like SIP, it acts as a Session Description Protocol carrier.
Conformance testing
TTCN-3 test specification language is used for the purposes of specifying conformance tests for SIP implementations. SIP test suite is developed by a Specialist Task Force at ETSI (STF 196).