Introduction: The Need for Sessions:
Telecom industry has rapidly adopted IP for its voice & data networks. IP protocols are excellent for data services but are not so suitable for voice, especially when it comes to setting up, modifying or closing a real time session (or call) which is the pre-requisite for a voice call. This function is performed by ISUP (an SS7 Signaling Protocol) in traditional telecom networks.
Examples of available IP based session control protocol include SIP, SIP-I, SIP–T & BICC, which have the capability to establish packet switched based voice calls, hence are used or considered for session control in PSTN/GSM/3G/4G. It is desirable for the industry to adopt a single protocol for a convenient packet based voice (VoIP) development & deployment.
BICC: Bearer Independent Call Control was standardized by ITU-T in 2000 called Q1901 – Capability Set 1 (or CS1) to provide call control functionality. Later in 2001, BICC CS2 was introduced with BCP (Bearer Control Protocol) to provide IP Network Bearer Control & CODEC control. There is no further development after that (why?? Read below). BICC inherits the ISUP messages & parameters, hence providing the same services & allowing natural interworking between ISUP & BICC. It was adopted by 3GPP for UMTS in Rel 4 (2001).
SIP (Session Initiation Protocol) was developed by IETF (RFC 3261). It is most commonly used in the IP world. IETF neither intended nor attempted to make it suitable for PSTN. It had 3 limitations from voice session point of view:
1- No Direct Interworking with PSTN (more precisely ISUP SS7 Signaling).
2- SIP session model is StateLess (no message sequence) whereas PSTN ISUP call model is strictly StateFul i.e. Sequence of messages is important ( e.g. IAM -> ACM -> ANM -> REL -> RLC).
3- PSTN ISUP based features cannot be implemented in SIP because most of that functionality is not available in SIP.
Later on IETF & 3GPP (including ITU) realized that SIP to ISUP interworking is necessary for voice over packet switch (or more precisely IP) network. But two parties, IETF & 3GPP/ITU continued independently developing methods & ways of encapsulating ISUP messages in SIP. The result was two SIP variants as mentioned below:
SIP-T (SIP for Telephony): IETF defined SIP-T in 2002 (RFC 3372, 3393, etc). It provides mechanism of carrying ISUP messages as an attachment to SIP messages.
SIP-I (SIP for ISUP): ITU developed & standardized SIP-I (Q1912.5 Profile C) signaling protocol allowing complete interworking between next generation IP networks & traditional PSTN (or GSM/UMTS) networks. It helped extending the services that can be offered in the VoIP domain. SIP-I encapsulated ISUP messages. Because of its flexibility, 3GPP Mobile networks (3G, 4G) adopted SIP-I as an alternative to BICC. SIP-I was formally adopted by 3GPP for IMS.
Why BICC Dropped in Favour of SIP (I & T):
There are three reasons why SIP is preferred to BICC:
1- There is no further enhancement work done in BICC at any forum making its capabilities stagnant.
2- BICC was intended for voice in GSM/UMTS, hence it is limited to serve these only. When it comes to establishing session for multimedia systems, BICC has nothing to offer.
3- BICC uses specific (proprietary) framing protocol IuFP. It is not widely deployed compared to SIP framing protocol (based on IETF). Even ITU version of BICC uses IETF based framing.
COMPARISON: SIP-I & SIP-T:
Comparing SIP-T (from IEFT) & SIP-I (from ITU) suitability for voice, SIP-I is more suitable for GSM/UMTS/LTE environment due to the following (except pt. 6):
1- ITU has more experience, relevance & future aspirations for voice compared to IETF
2- Trust Zones & Security Environment: SIP-T assumes there is no trusted zone hence more complex. SIP-I is opposite to it.
3- Encapsulation Procedures & Message Mapping: SIP-T is under-specified (under developed) hence still not fully trustworthy for deployment.
4- Support for RFCs & Standards: SIP-I has more developed RFCs & standards.
5- User Plane IOT: SIP-T does not emphasize on user plane interoperability testing.
6- Forking: SIP-T supports Forking feature, the ability to create mid-call multiple streams (or branches) of audio associated with a single call and then send those streams of data to different destinations. It allows service providers to use technologies such as speech recognition, voice authentication, and text-to-speech conversion to provide sophisticated services to their end-user customers. SIP-I does not support this as yet.
Hence there is more uncertainty & an increased risk in deploying SIP-T. SIP-I is more suitable for the converged GSM/UMTS/LTE/NGN/IP networks. SIP-I is adopted by both 3GPP & ANSI. Moreover 3GPP plans to incorporate SIP-I in specifications.
SIP is Layer 5:
SIP ( I & T ) are layer 5 protocol. Hence they need something at layer 4 to work with IP (layer 3). UDP & TCP are available but more reliable is TCP.
No |
Layer |
Protocol SIP ov IP |
Protocol SS7 ov IP |
Protocol BICC ov IP |
ISUP |
||||
5 | Session |
SIP – I , T |
SIP – I , T |
BICC |
4 | Transport | |||
3 | Network |
IP |
IP |
IP |
2 | Data | |||
1 | Physical |
So Which one to Use?
BICC, SCTP, SIP-T or SIP-I are the protocol choices to setup a voice call and carry SIGNTRAN (SS7 Signaling over IP).
The above discussion shows that SIP is a good candidate for voice call setup in IP networks. And SIP-I is the preferred choice for Voice networks to carry Signaling over IP.
NOTE: Above discussion is based on OSI 7 layer model. IP has its own 4 layer model. Its concept is similar but layer numbering may differ.
The end.