Re: INFO

Saying, "OK for interworking" does not really say
anything.  If I come up
with a really broken method for interworking, saying that it
is for
interworking does not make it correct.

The problem is, how do the endpoints know they will be able
to communicate?
For the ISUP/Q.sig/DPNSS/mumble case, the endpoints know
they will be able
to interoperate because they know a'priori: they are
configured to work.
However, this means that the devices must be in the same
administrative
domain and configured properly.

Said in a different manner, INFO works fine for
non-inter-network use.  It
would be hard for the IETF to say, "Here is a non-IETF
use.  We will not use
it.  You cannot use it with anyone else.  You cannot use it
between
manufacturers, unless you get them to agree to this
use."  That is a bit
more of what we call the toxic waste warning that
accompanies 3GPP
specifications...


On 8/27/07 8:35 AM, "Peili Xu" <xupeilihuawei.com> wrote:

> Hi Eric,
> 
> Several cases I encounter to use INFO is for
interworking with PSTN signaling,
> or simulate PSTN services at SIP entities such as SIP
UA or SIP GW,
> which require mid-dialog information change.
> 
> For such SIP entities, It's not always possible or
required to support
> encapsulation of ISUP or QSIG package. Just some XML
body with
> application info is enough and light-weight for this
purpose.
> 
> 
> INFO is not an ideal tool for everything, but is an
ideal tool for some thing.
> 
> I'd prpose to at lease allow using INFO for
interworking or simulation
> purpose with legacy system.
> 
> Regards.
> Peili
> 
> 2007/8/22, Eric Burger <eburgerbea.com>:
>> Since list traffic is down, how about something to
spice things up?
>> 
>> 
>> Any thoughts on
>> 
>> http://www.ietf.org/internet-drafts/draft-burger
-sip-info-01.txt
>> 
>> ???
>> 
>> If you like it, say so.  If you hate it, say so.
>> 
>> Text welcome.
>> 
>> 
>> 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
>> 
> 



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 fully understand your concern. But just to forbidden
using INFO does not 
solve the "how do the endpoints know they will be able
to communicate?" problem/requirement either.

I'd suggest we first consider to find solution for the
prolem 
then after that we can say "Don't use INFO for this,
Use
that solution."

Do you think this is a more convising way?

Peili


-----Original Message-----
From: Eric Burger [mailto:eburgerbea.com] 
Sent: Friday, August 31, 2007 6:03 AM
To: Peili Xu
Cc: sip
Subject: Re: [Sip] INFO

Saying, "OK for interworking" does not really say
anything.  If I come up with a really broken method for
interworking, saying that it is for interworking does
not make it correct.

The problem is, how do the endpoints know they will be
able to communicate?
For the ISUP/Q.sig/DPNSS/mumble case, the endpoints know
they will be able to interoperate because they know
a'priori: they are configured to work.
However, this means that the devices must be in the same
administrative domain and configured properly.

Said in a different manner, INFO works fine for
non-inter-network use.  It would be hard for the IETF to
say, "Here is a non-IETF use.  We will not use it. 
You
cannot use it with anyone else.  You cannot use it
between manufacturers, unless you get them to agree to
this use."  That is a bit more of what we call the
toxic
waste warning that accompanies 3GPP specifications...


On 8/27/07 8:35 AM, "Peili Xu" <xupeilihuawei.com>
wrote:

> Hi Eric,
> 
> Several cases I encounter to use INFO is for
interworking with PSTN 
> signaling, or simulate PSTN services at SIP entities
such as SIP UA or 
> SIP GW, which require mid-dialog information change.
> 
> For such SIP entities, It's not always possible or
required to support 
> encapsulation of ISUP or QSIG package. Just some XML
body with 
> application info is enough and light-weight for this
purpose.
> 
> 
> INFO is not an ideal tool for everything, but is an
ideal tool for some thing.
> 
> I'd prpose to at lease allow using INFO for
interworking or simulation 
> purpose with legacy system.
> 
> Regards.
> Peili
> 
> 2007/8/22, Eric Burger <eburgerbea.com>:
>> Since list traffic is down, how about something to
spice things up?
>> 
>> 
>> Any thoughts on
>> 
>>
http://www.ietf.org/internet-drafts/draft-burger-sip-inf

o-01.txt
>> 
>> ???
>> 
>> If you like it, say so.  If you hate it, say so.
>> 
>> Text welcome.
>> 
>> 
>> 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
>> 
> 



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

 

> -----Original Message-----
> From: Eric Burger [mailto:eburgerbea.com] 
> Sent: Thursday, August 30, 2007 5:03 PM
> To: Peili Xu
> Cc: sip
> Subject: Re: [Sip] INFO
> 
> Saying, "OK for interworking" does not really
say anything.  
> If I come up with a really broken method for
interworking, 
> saying that it is for interworking does not make it
correct.
> 
> The problem is, how do the endpoints know they will be
able 
> to communicate?
> For the ISUP/Q.sig/DPNSS/mumble case, the endpoints
know they 
> will be able to interoperate because they know
a'priori: they 
> are configured to work.
> However, this means that the devices must be in the
same 
> administrative domain and configured properly.

...or all of your UAs come from the same vendor or set of
vendors that
have agreed previously to support said mechanism, or you buy
one of
Hadriel's magic boxes to fix it for you.

I realize the same could be said for any protocol scheme,
but it's a
very real fact in the case of how INFO works today,
especially for DTMF.
There's really only a few widely deployed schemes running
around out
there for DTMF via INFO. If we're complaining about using
INFO for DTMF
because of negotiation issues, I think that's a very
solvable problem
without deprecating INFO.

> 
> Said in a different manner, INFO works fine for 
> non-inter-network use.  

It works fine for inter-network use as well depending upon
what you are
trying to use it for. Take for instance trying to figure out
if a
session is still alive by periodically sending an INFO to
the other
endpoint. I know we have a session timer mechanism defined,
but many
endpoints don't support it (yet). Even getting back an error
response,
depending upon the response code, may mean that the session
is still
alive (success). The point of the usage wasn't to convey
anything, and
so no negotiation was necessary. SIP was all you needed.

> It would be hard for the IETF to say, 
> "Here is a non-IETF use.  We will not use it.  You
cannot use 
> it with anyone else.  You cannot use it between 
> manufacturers, unless you get them to agree to this
use."  
> That is a bit more of what we call the toxic waste
warning 
> that accompanies 3GPP specifications...
> 
> 

You could say this for a lot of things. For instance, point
me to the
IETF use of SIP to do call forwarding.

You can't use SIP between manufacturers unless you get them
to agree to
implement it correctly either. I'm not really sure what your
point was
here unless you are against people writing down a common way
of using a
protocol amongst themselves.



Regards,
Brian


_______________________________________________
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