There are many good books and websites available to help you with learning SIP. A great place to start is the resource center at Tekelec:
http://www.tekelec.com/resource-center/

Be sure to check out the Webinars – there are several focusing on introducing SI
P. You’ll also find the SIP Pocket Guide quite useful.

To start to answer your questions (you can get more detail at the link above):

SIP (the Session Initiation Protocol) is the signaling protocol used to establish real-time sessions on the Internet. It provides two primary services: allowing two endpoints find each other (even when their addresses frequently change), and allowing those endpoints to negotiate how they are going to communicate.

SIP runs on top of other transport protocols. Currently, there are standard defi
nitions for using SIP on UDP, TCP, and SCTP (including protecting the SIP messages on those transports with TLS).

Glad to see you joining in the SIP community. Good luck, and enjoy!

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.

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?

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.

you are naturally right, a lot of fixed operators are basing their transition strategy to all-IP networks on IMS and the will certainly be faster in deploying IMS (in its full glory) than mobile operators -whom IMS was targeting. Still, when checking the transition times of these companies we are still talking about a couple of years till they go into production
Posted @ Monday, October 05, 2009 10:49 AM by Dorgham Sisalem
I personally feel that it is the complexity (because it targets at achieving a wholesome architecture) of the IMS that is making the service providers lazy about implementing it fast. The providers are happy if the change is just a mile away. But, when they see it needs quite a good amount of elements involved, they are probably becoming hesitant.

Cheers!

IMS is a combination of useful clarifications/additions to the IETF standards and dubious design decisions (is tying a SIP layer address to a transport-/network layer address really a sound idea?).