Subject: [Sipping] Discussion on parallel operation of the H.323, SIP and BICC call control protocols

From: "Greg Ratta" <[email-masked]>
Date: Wed, 30 May 2001 16:22:22 -0400

<flushboth>This message was agreed to at ITU-T Study  Group 11 meeting  
(Geneva, May 2001) and is  being transmitted on behalf ot Yukio  
Hiramatsu,  Chairman of ITu-T SG 11. For further technical   
clarification, contact the Rapporteur for Q9/11<color><param>0100,0100,0100</param>  (Rolfe Buhrke, Tel:  
+ 1 630 713 7022,  { HYPERLINK mailto:[email-masked]  
<bigger>}<smaller>[email-masked])<FontFamily><param>Courier New</param></flushboth>

<paraindent><param>right</param><smaller>Study Group 11 would like to inform IETF that it  
has  started discussions on the idea of having  
multiple call  control protocols, like H.323, SIP  
and BICC, operating  in parallel and thus  
leveraging the strong points of  each of the  
protocols.</paraindent>

<paraindent><param>right</param>The attached information, extracted from SG11  
delayed  contribution D.213 (Parallel use of BICC  
with other  call control protocols), gives an  
impression of the  proposed idea. </paraindent>

<paraindent><param>right</param>Discussion is underway in SG11 regarding the  
possible  implications for the BICC call control  
protocol.</paraindent>

<paraindent><param>right</param>__________________</paraindent>

<paraindent><param>right</param>1 Introduction</paraindent>

<paraindent><param>right</param>Candidate capabilities to be included in BICC CS3  
were  identified at the last ITU-T SG11 meeting in  
Geneva and  at the ITU-T SG11 BICC interim meeting  
5 in Gold Coast.  The support of multimedia has  
been suggested as new  capability for BICC CS3.</paraindent>

<paraindent><param>right</param>This contribution introduces the idea of having  
call  control protocols, like BICC, H.323 and SIP,  
which  operate in parallel. A combination of the  
protocols  could be used to offer a certain  
service, instead of  extending each protocol with  
capabilities of the other  protocols, or  
constructing complex tunnelling solutions.</paraindent>

<paraindent><param>right</param>2 Co-existence of three call control protocols:  
BICC,  SIP, H.323</paraindent>

<paraindent><param>right</param>SG11, SG16 and IETF have developed three protocols  
 (actually families of standards) for call control, 
  namely</paraindent>

<paraindent><param>right</param>- BICC: Telephony over packet</paraindent>

<paraindent><param>right</param>- H.323: Multimedia over LAN</paraindent>

<paraindent><param>right</param>- SIP: End-to-end sessions over Internet</paraindent>

<paraindent><param>right</param>The three protocols have in common that they can   
initiate voice calls over packet-switched networks. 
  However, each of these protocols has its specific 
  background and strong points.</paraindent>

<paraindent><param>right</param>- BICC supports the full range of ISDN and   
supplementary services over packet networks. Its  
strong  points are complete compatibility with the  
existing  PSTN and good operational support for  
large-scale use  (e.g. billing).</paraindent>

<paraindent><param>right</param>- H.323 has been originally developed for video   
applications. It has a large installed base for   
multimedia over LAN applications. Its strong points 
 are  its wide range of services and its relative  
good  compatibility with PSTN.</paraindent>

<paraindent><param>right</param>- SIP has several techniques to initiate end-end   
sessions over the Internet. Its strong points are  
its  (text-based) simplicity of use, its proxi -  
and  redirect capabilities and its extensibility  
and  openness.</paraindent>

<paraindent><param>right</param>Work is still ongoing on each of these protocols  
and  new capabilities are being added.</paraindent>

<paraindent><param>right</param>We recognise three types of approaches for adding  
new  capabilities to the call control protocols.</paraindent>

<paraindent><param>right</param>1. Convergence between call control protocols</paraindent>

<paraindent><param>right</param>2. Mutual tunnelling of protocols</paraindent>

<paraindent><param>right</param>3. Parallel use of control protocols</paraindent>

<paraindent><param>right</param>Below, we look in more details how these approaches 
  work or could work.</paraindent>

<paraindent><param>right</param>2.1 Convergence between call control protocols</paraindent>

<paraindent><param>right</param>Often, new capabilities are added to protocols by   
copying from one protocol to the others.</paraindent>

<paraindent><param>right</param>- H.323 has been extended with supplementary  
services,  and work is in progress to make H.323  
more scalable.  BICC had all these features already 
 intrinsically. Due  to the Q.931 background of  
H.323, ISUP-specific aspects  are missing, which  
make H.323 unsuited for use in  public networks.  
Also the complexity of H.323 is often  mentioned as 
 negative point, as a multitude of  applications  
have been mixed together: video, basic  voice, and  
recently supplementary services.</paraindent>

<paraindent><param>right</param>- SIP is being extended  to support ATM bearers   
additional to IP bearers. BICC supported ATM  
bearers  already in CS1. Also, SIP is more tailored 
 to the  application layer (quick introduction of  
new services)  and less suited for interconnection  
of public networks  to get a comparable  
functionality as with ISUP or BICC.</paraindent>

<paraindent><param>right</param>- BICC has been extended to support IP bearers,  
which  H.323 and SIP already supported from day  
one. It has  also been suggested to extend BICC  
with multimedia  capabilities, which H.323 and SIP  
have already.</paraindent>

<paraindent><param>right</param>Evidently, there exists a process of convergence   
between the various call control protocols.</paraindent>

<paraindent><param>right</param>The question is whether the process of convergence  
 between the various call control protocols is a  
good  thing. This process takes enormous amounts of 
 resources  of the different standardisation 
bodies.  The resulting  standards are usually 
poorly  compatible and all kinds  of interworking  
specifications are needed to resolve  this.  
Moreover, each of the standards may gradually  lose 
 its strong points. SIP may lose its simplicity and 
  openness. H.323 may lose its wide support. BICC 
may   lose its compatibility with the existing 
PSTN/ISDN   services. Also, the level of 
implementation of  later  capabilities of a 
protocol is usually lower .</paraindent>

<paraindent><param>right</param>2.2 Mutual tunnelling of protocols</paraindent>

<paraindent><param>right</param>A popular approach of incorporating capabilities of 
 one  call control protocol into another is the use 
 of  tunnelling.</paraindent>

<paraindent><param>right</param>- There are SG16 activities on tunnelling ISUP over 
  H.323. As the H.323 message sequence is based on  
Q.931,  there is an evident mismatch with the ISUP  
message  sequences. Also, there are compatibility  
problems  because of different ISUP versions and  
different SS7  domains that have to work together  
over the H.323  tunnel.</paraindent>

<paraindent><param>right</param>- Tunnelling of ISUP over SIP is investigated in  
the  IETF SIP-T activity. Similar mismatches  
between message  sequences and compatibility  
problems should be  expected. Moreover, a lot of  
complexity is introduced,  for example that network 
 points may choose to either  discard the SIP or 
the  ISUP information. Another  problem is that 
BICC, as  successor of ISUP, has new  capabilities 
for UMTS  (e.g. codec negotiation), that  are not 
supported  by ISUP. Therefore, SIP-tunnelling- ISUP 
will miss  some essential BICC capabilities.</paraindent>

<paraindent><param>right</param>- Tunnelling mechanisms have also been studied in  
BICC.  The BICC and CBC protocols have the  
capability to  tunnel the SDP-based IPBCP protocol. 
 Also here, a lot  of problems related to 
mismatches  between message  sequences and 
compatibility  problems have been  recognised, like 
the issues of  the "spontaneous and non- 
spontaneous cases" and  "text versus binary coding".</paraindent>

<paraindent><param>right</param>The question is whether all the mutual tunnelling   
approaches are a good thing. Also this process  
takes  enormous amounts of resources of the  
different  standardisation bodies. Tunnelling often 
 leads to  difficulties related to mismatches  
between message  sequences and compatibility  
problems, as indicated  above. In many cases,  
interworking specifications will  be needed to  
resolve these problems. Tunnelling becomes  then  
much more difficult than "just another way of   
signalling transport". Again, each of the standards 
 may  gradually lose its strong points. </paraindent>

<paraindent><param>right</param>2.3 Parallel use of call control protocols</paraindent>

<paraindent><param>right</param>The previous two sections argued that the parallel  
 development of competing incompatible protocols  
might  not be a good thing. The emerging tunnelling 
 approaches  for call control protocols may not be 
a  good thing  either. We would like to introduce a 
 third alternative  here, namely to use call 
control  protocols in parallel.  This avoids the 
high  complexity of the convergence  process and 
the  tunnelling approaches. Each protocol  may be 
used  for its strong points.</paraindent>

<paraindent><param>right</param>Parallel use of protocols is already well known for 
  bearer protocols. For example, there exist  
"swouters"  that act both as IP router and as ATM  
switch. For IP  routers, it is quite common to  
support multiple routing  protocols in parallel,  
each for their specific domain  and application.  
Also MPLS is based on the idea of  using protocols  
in parallel.</paraindent>

<paraindent><param>right</param>The BICC and SIP protocols may be operational in   
circuit-switched or packet switched network. Such   
combination of BICC and SIP is know from 3GPP work  
on  UMTS. </paraindent>

<paraindent><param>right</param>UMTS has both a circuit-switched - and a packet-  
switched domain. Upcoming UMTS Release 4 </paraindent>

<paraindent><param>right</param>uses BICC or SIP-T for call control in the CS  
domain.  The CS domain can either use IP or ATM as  
transport  option. UMTS Release 5 introduces a  
Internet Multimedia  Core Network Subsystem (IM CN  
Subsystem) based on SIP  call control. The PS  
domain (i.e. the GPRS based core  network) provides 
 (mobile) access for this IM CN  Subsystem. Just  
like in the PS domain, transport in the  IM CN  
Subsystem is based on IP.</paraindent>

<paraindent><param>right</param>In many cases, parallel protocols may work   
independently and each of the protocols is offering 
 its  own set of services. IETF often uses the  
phrase "ships- in-the-night" for protocols  
operating in parallel  independently. </paraindent>

<paraindent><param>right</param>However, there could also be cases where the two   
protocols collaborate. Take for instance a voice   
telephony call using the BICC/ATM network part. The 
  BICC/ATM network part offers PSTN-grade voice  
quality  with mouth-to-ear QoS control,  
supplementary services  and perhaps also the  
billing of the call. At some point  in the call,  
video and data is added. The SIP/IP  network part  
can then initiate the IP session for the  video and 
 data components of the call.</paraindent>

<paraindent><param>right</param>When two protocols work together, as in the above   
example, provisions may be needed to support this   
collaboration. Think of correlation identifiers to  
 correlate instances of the two protocols, for  
example.</paraindent>

<paraindent><param>right</param>2.4 Three approaches: convergence, tunnelling and   
parallel</paraindent>

<paraindent><param>right</param>In the previous section, we have identified three   
approaches for adding new capabilities to the call  
 control protocols.</paraindent>

<paraindent><param>right</param>1. Convergence between call control protocols</paraindent>

<paraindent><param>right</param>2. Mutual tunnelling of protocols</paraindent>

<paraindent><param>right</param>3. Parallel use of control protocols</paraindent>

<paraindent><param>right</param>Currently, the first two approaches are most often  
 used. However, the third approach may overcome 
many  of  the problems associated with the first 
two  approaches.</paraindent>

<paraindent><param>right</param>We think that it could be fruitful to explore the   
possibilities of using call control protocolsin   
parallel. Further study is needed to work out how  
such  combinations could work. </paraindent>

<paraindent><param>right</param>3 Proposal</paraindent>

<paraindent><param>right</param>BICC CS3 should support the parallel use of BICC  
with  other call control protocols like SIP and  
H.323.  Further study is needed to work out how  
such  combinations could work.</paraindent>

<nofill>
Greg Ratta, Vice Chairman, ITU-T SG 11, Signalling requirements and protocols

Lucent Technologies
Tel: +1 732 332 5174, Fax: +1 732 949 1196, [email-masked]

_______________________________________________
Sipping mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/sipping