Hi, I would rather treat SIP-T (ISUP encapsulation) as an enhancement for SIP in case of interworking.
Basically, it's a SIP session which route the call to the destination (GW) and carry out SDP offer/answer negotiation. The reason why encapsulation is just to guarantee minimum information lost. I don't think the control channel concept for SIP is proper to replace SIP-T, because we need SIP to do SDP exchange and most of the ISUP information is semantically related to SIP dialog setup messages. Peili 2007/9/5, Henry Sinnreich <[EMAIL PROTECTED]>: > > Actually, using the SIP-T protocol for tunneling SS7 is a designer > choice, though I would be interested to hear what other options there > are and what may be the best option. Are there reasons for SIP-T to be > the best option? > > I still dislike to the use of "SIP" in the "SIP-T" name as mentioned > below. > > Thanks, Henry > > ===================================== > Thanks Eric! :-) > > The guidelines for the usage of SIP don't have as far as I remember any > recommendation for SIP to be used as a tunneling protocol. In this > respect, the use of SIP for a "tunneling convention" is non-truth in > advertising. > > As for the most effective way of carrying SS7 over IP networks, I would > be interested to hear how VoIP providers are actually doing it. Can > anyone share such information? > > Oh yes,... > > I do see a place for communications service providers > So do I. Aren't we all here in the IETF to communicate over the Internet > or in private IP networks? > > >> The fact that the INFO method has a > >> problem doesn't mean that SIP-T is an inappropriate use of SIP. > > Yes, it is inappropriate since people attempting to connect with a SIP > end device such as a SIP phone or PSTN gateway on the SIP side will > fail. > > Henry > > -----Original Message----- > From: Eric Burger [mailto:[EMAIL PROTECTED] > Sent: Wednesday, September 05, 2007 9:11 AM > To: Bram Verburg > Cc: sip > Subject: Re: [Sip] INFO > > The use of INFO part. Hey, I'm not totally Henry - I do see a place for > communications service providers and I recognize the importance of > interworking with the PSTN for the next 15 years. > > SIP-T is not a session initiation protocol. It is a set of conventions > for > TUNNELING proprietary signaling events over SIP. Key word there is > TUNNELING. That is the clue that section 3.3 applies. > > > On 9/5/07 6:46 AM, "Bram Verburg" <[EMAIL PROTECTED]> wrote: > > > OK, SIP-T is not going away, but I'm still not sure whether you are > > trying to say that all of SIP-T is bad, or only its use of INFO? If > all > > of SIP-T is bad, then let's not fix it and wait till it does go away > > eventually. If the problem is specifically with INFO, then let's > define > > an event package that allows endpoints to request mid-call > 'proprietary' > > signaling events, and then we can deprecate INFO altogether. > > > > My point was that SIP-T is not simply a tunnel that could be replaced > by > > any other transport layer, which is what section 3.3 seems to > describe. > > It is a 'session initiation protocol' that does exactly what SIP is > > designed to do: initiate sessions. The fact that the INFO method has a > > problem doesn't mean that SIP-T is an inappropriate use of SIP. > > > > Bram > > > > > >> -----Original Message----- > >> From: Eric Burger [mailto:[EMAIL PROTECTED] > >> Sent: 05 September 2007 16:09 > >> To: Bram Verburg > >> Cc: sip > >> Subject: Re: [Sip] INFO > >> > >> SIP-T suffers *all* of the issues with INFO. > >> > >> Read section 3.3 for the 'right' way of doing SIP-T. > >> > >> That said, let's be real: I don't think anyone will abandon > >> SIP-T at this late date. Although this really is a counter > >> example, I would liken this to the story in: > >> http://www.snopes.com/history/american/gauge.htm > >> > >> > >> > >> > >> On 9/5/07 4:56 AM, "Bram Verburg" <[EMAIL PROTECTED]> wrote: > >> > >>>> That is the point of the draft. All of the uses of INFO > >> today have > >>>> alternatives that do not have the same problems. > >>>> > >>>> In fact, I am really thinking the draft should point out > >> the use of > >>>> INFO for SIP-T is also incorrect. SIP-T should use a control > >>>> channel, not the "SIP" > >>>> channel, for transporting proprietary signaling. The only thing > >>>> SIP-T does is re-create TCP over SIP. Not a very useful > >> use of SIP. > >>> > >>> I don't think that's a fair assessment of SIP-T, since you > >> seem to be > >>> ignoring the fact that SIP-T also (primarily) uses other > >> methods than > >>> INFO. > >>> > >>> The encapsulation of 'proprietary' signaling is done to convey > >>> information that cannot currently be conveyed in pure SIP. > >> But other > >>> than that, within the VoIP domain the regular SIP dialog > >> model is used > >>> to establish and tear down sessions. SIP headers take > >> precedence over > >>> the contents of the ISUP/Q.931 message, so the 'tunneled' > >> message is > >>> only used to fill in some blanks at the receiving end. For the most > >>> part proxies and even user agents can safely ignore the > >> message body > >>> and still participate in the SIP dialog. > >>> > >>> Some ISUP/Q.931 messages arrive at a stage in the session where SIP > >>> doesn't define any interaction between UAs, so currently > >> INFO is used > >>> as a tunnel. If you believe it should be replaced by something less > >>> ambiguous, that won't be abused outside the scope of SIP-T the same > >>> way INFO is today, I guess that's fair enough. But saying > >> that SIP-T > >>> should use TCP tunnels instead seems a bit harsh. > >>> > >>> Bram > >>> > >> > >> > >> > >> Notice: This email message, together with any attachments, > >> may contain information of BEA Systems, Inc., its > >> subsidiaries and affiliated entities, that may be > >> confidential, proprietary, copyrighted and/or legally > >> privileged, and is intended solely for the use of the > >> individual or entity named in this message. If you are not > >> the intended recipient, and have received this message in > >> error, please immediately return this by email and then delete it. > >> > > > > > > Notice: This email message, together with any attachments, may contain > information of BEA Systems, Inc., its subsidiaries and affiliated > entities, that may be confidential, proprietary, copyrighted and/or > legally privileged, and is intended solely for the use of the individual > or entity named in this message. If you are not the intended recipient, > and have received this message in error, please immediately return this > by email and then delete it. > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use [EMAIL PROTECTED] for questions on current sip > Use [EMAIL PROTECTED] for new developments on the application of sip > > > _______________________________________________ > Sip mailing list https://www1.ietf.org/mailman/listinfo/sip > This list is for NEW development of the core SIP Protocol > Use [EMAIL PROTECTED] for questions on current sip > Use [EMAIL PROTECTED] for new developments on the application of sip > _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use [EMAIL PROTECTED] for questions on current sip Use [EMAIL PROTECTED] for new developments on the application of sip
