I don't think you can really decouple the SIP layer and the encapsulated ISUP/Q.931 body like that, and say that SIP-T is just the tunneling part.
The fact that SIP-T says that SIP headers take precedence over the ISUP/Q.931 means you can't send the INVITE and the IAM over separate channels (for example a TCP or Sigtran tunnel for ISUP) without opening a big can of worms. How do you synchronize those messages at the receiving end; you'd need both the INVITE and the tunneled IAM before you can send something out on the PSTN side. How do you even make sure those two channels reach the same destination after passing through proxies, NATs, SBCs, load balancers, etc.? A proper SIP-T implementation can be fully SIP compliant, it's just that it currently uses a somewhat controversial SIP method. If that particular issue needs to be addressed, let's address it. Bram > -----Original Message----- > From: Eric Burger [mailto:[EMAIL PROTECTED] > Sent: 05 September 2007 17:11 > 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
