About the Blog

Subscribe via Email

Your email:

Recent Posts

Most Viewed

Blog Roll

Archive

Blog Authors

Browse by Tag

SIP Sessions

Current Articles | RSS Feed RSS Feed

How best to support BICC-SIP interworking?

Posted by Ravi Ravishankar on Tue, Jun 09, 2009 @ 05:02 PM

It has been nearly two years since 3G Americas published its whitepaper, Why SIP-I - A Switching Core Protocol Recommendation for GSM/UMTS Operators, providing a strong argument for using SIP-I as the recommended voice call control for GSM and 3G networks. The whitepaper compared SIP-I with ISUP encapsulation, SIP-T (IETF standard) with ISUP encapsulation and Bearer Independent Call Control (BICC); and provided a convincing argument in favor of SIP-I. All the standard bodies, including 3GPP, ITU, ETSI and ANSI, have chosen SIP-I as the session control protocol for the reference architecture.

But when we look at network deployments, BICC continues to show strong deployment presence in many 3G networks. Many of the investments in BICC-based core networks are recent and continue today. Therefore, it will be a long time before this infrastructure is written off by operators. However, it is more likely that BICC will remain confined within an administrative network domain, with a Network-to-Network interface between domains using SIP-I. This necessitates interworking between BICC and SIP-I.

While a Softswitch gateway-based solution was suitable for ISUP-SIP interworking, it is not the most efficient solution for BICC-SIP interworking. ISUP-SIP interworking must handle media incompatibility, whereas BICC-SIP interworking could take place purely in the signaling domain (provided there is media compatibility), since both use RTP for voice. The ideal place to implement such interworking is at a Signaling Proxy. There are three potential proxies where such interworking could take place:

    1. The Signal Transfer Point (STP) that acts as a routing hub for the BICC messages at the SCTP layer
    2. The Call Mediation Node (CMN) defined in the 3GPP R4 architecture. This is the BICC equivalent of the SIP Proxy Server
    3. The SIP Proxy Server

With these thoughts, I'd like to open up the discussion to our reader community. Here are a few questions to get the dialogue going:

    • Do you agree that BICC-SIP interworking at the signaling plane makes sense and not in a Softswitch or an MSC Server?
    • If so, in your view, which of the three nodes above is better suited architecturally? And why?
    • Do you think that more standards work is necessary and where should it be done.
Tags: , , , ,

Comments

The majority of the Mobile carriers will not move to SIP-I soon and in our mind SIP-I to BICC will be a required niche. I am from the opinion that interworking should be built on top of your SIP-Proxy;  
 
supporting BICC-to BICC without handling user plain, BICC to SIP-I including threatment of the user plan (RTP is different in BICC) and proxying BICC to SIP-I to BICC proxy in case of cross bordering over multiple prowy hubs (and visa versa). 
 
Lets open this discussion.
Posted @ Friday, December 11, 2009 4:47 AM by Bart
If the media are compatible... 
 
I am no expert in this field - but we're trying to integrate a SIP IVR with a Rel.4 network and it's proving very tricky. If you have a SIP-based system, it won't get far unless it supports half a dozen 3GPP standards, that are quite restrictive. 
 
We've had some fun with this recently. BICC has been sending the codec 96 in the SDP and the actual codec has to be read from the BICC parameters (G.711). The 3GPP standard doesn't allow G.711 to be sent in the SDP.  
 
The system can handle reading the codec now - but we have the issue that the Rel.4 MGWs are expecting an RTP handshake with the codec 96 to start the media streams. Our off-the shelf SIP IVR doesn't do that. 
 
Is SIP-I less restrictive than this? I read that it's between nodes rather than to end-points. Does that mean that it won't allow G.711 as a codec in the SDP? Does it have a special mode of sending RTP?
Posted @ Thursday, January 21, 2010 3:32 AM by DrBoB
The short answer is: SIP-I would not change anything in this case. 
 
The reason is that SIP-I is targeted at bridging scenarios. In this 
context, SIP is used as a transport protocol over which ISUP (or BICC) 
signaling can be tunneled. For anything else than that, I doubt that 
the ISUP payload brings any added value. 
 
With the bridging scenario in mind, BICC only uses RTP as a 
transparent transport protocol for Iu/Nb frames, which is the main 
reason for not allowing anything else than NbFP in the codec 
description. 
 
Regarding the 'RTP handshake', it is related to the fact that BICC and 
SIP have different models for establishing and negotiating media 
bearer/streams. 
 
Accordingly, interworking BICC and SIP beyond bridging scenarios 
always includes some sort of translation on the user plane. Here it 
does not necessarily mean to transcode anything, but to interwork the 
different session description mechanisms. 
 
On the BICC side, most of the session description is implicit, and the 
rest is done inband. On the SIP side, everything is negotiable and has 
to be done explicitly. 
 
But back to the presented scenario: BICC to SIP interworking (not just 
trunking over SIP/SIP-I). 
 
Here I guess it would be much wiser to draw 
a clear demarcation line, instead of propagating packets designed for 
the radio interface to the outer world, and require SIP appliances to 
support Iu/Nb frames. 
 
Posted @ Tuesday, January 26, 2010 4:01 AM by Raphael Coeffic
Post Comment
Name
 *
Email
 *
Website (optional)
Comment
 *

Allowed tags: <a> link, <b> bold, <i> italics