RE: INFO

> 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


_______________________________________________
Sip mailing list  https://ww
w1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementorscs.columbia.edu for questions on current
sip
Use sippingietf.org for new developments on the application of
sip

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" <bramvocaltec.com> 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.


_______________________________________________
Sip mailing list  https://ww
w1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementorscs.columbia.edu for questions on current
sip
Use sippingietf.org for new developments on the application of
sip

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:eburgerbea.com] 
> 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"
<bramvocaltec.com> 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.
> 


_______________________________________________
Sip mailing list  https://ww
w1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementorscs.columbia.edu for questions on current
sip
Use sippingietf.org for new developments on the application of
sip

I don't think those (and there are quite a few of them)
doing DTMF with INFO will abandon it at this late date...

> -----Original Message-----
> From: Eric Burger [mailto:eburgerbea.com]
> Sent: 5. syyskuuta 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"
<bramvocaltec.com> 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.
>
>
> _______________________________________________
> Sip mailing list  https://ww
w1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP
Protocol Use
> sip-implementorscs.columbia.edu for questions on current
sip
> Use sippingietf.org for new developments on the
application of sip
> 



_______________________________________________
Sip mailing list  https://ww
w1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementorscs.columbia.edu for questions on current
sip
Use sippingietf.org for new developments on the application of
sip

Which is to say that you don't have to do DTMF exclusively
with INFO.
You could use 2833/4733 in conjunction or exclusion to INFO
depending
upon your needs. It becomes messy when nobody wants to
acknowledge and
describe these mechanisms (with the goal of coming up with
something
coherent as a means of using them).

Regards,
Brian 

> -----Original Message-----
> From: Christer Holmberg (JO/LMF) 
> [mailto:christer.holmbergericsson.com] 
> Sent: Monday, September 10, 2007 2:00 PM
> To: Eric Burger; Bram Verburg
> Cc: sip
> Subject: RE: [Sip] INFO
> 
> 
> I don't think those (and there are quite a few of them)
doing 
> DTMF with INFO will abandon it at this late date...
> 
> > -----Original Message-----
> > From: Eric Burger [mailto:eburgerbea.com]
> > Sent: 5. syyskuuta 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"
<bramvocaltec.com> 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.
> >
> >
> > _______________________________________________
> > Sip mailing list  https://ww
w1.ietf.org/mailman/listinfo/sip
> > This list is for NEW development of the core SIP
Protocol Use 
> > sip-implementorscs.columbia.edu for
questions on current sip Use 
> > sippingietf.org for new developments on the
application of sip
> > 
> 
> 
> 
> _______________________________________________
> Sip mailing list  https://ww
w1.ietf.org/mailman/listinfo/sip
> This list is for NEW development of the core SIP
Protocol Use 
> sip-implementorscs.columbia.edu for questions on current
sip 
> Use sippingietf.org for new developments on the
application of sip
> 


_______________________________________________
Sip mailing list  https://ww
w1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementorscs.columbia.edu for questions on current
sip
Use sippingietf.org for new developments on the application of
sip