How best to support BICC-SIP interworking?
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:
- The Signal Transfer Point (STP) that acts as a routing hub for the BICC messages at the SCTP layer
- The Call Mediation Node (CMN) defined in the 3GPP R4 architecture. This is the BICC equivalent of the SIP Proxy Server
- 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.
No related posts.
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.
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?
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.