Subject: [Sip] INFO

From: Eric Burger <[email-masked]>
Date: Tue, 21 Aug 2007 17:37:22 -0400

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://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: "Peili Xu" <[email-masked]>
Date: Mon, 27 Aug 2007 20:35:23 +0800

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

---

From: [email-masked]
Date: Mon, 27 Aug 2007 15:15:25 -0400

Hi Eric, all, 

I assume the main intent of the post is to determine whether to proceed 
further on the INFO draft or not, and draw any significant early flames. 

> If you like it, say so.  If you hate it, say so.

I like it, and I hate it ;-) 

But, to be slightly more specific, while hopefully vague enough for 
misinterpretation... 

I support the overall effort.  It is certainly useful to write down and 
clarify why INFO is bad in some regards.  And it may be good in some other 
regards of course.  This would remove disinformation and add concrete 
reasoning to any debates.  Such debates have been fairly numerous, and for 
the most part pointlessly vague. 

I agree with most conclusions.  BUT, looking especially at section 4, 
there are other similar uses which are equally valid and equivalent to 
SIP-T/QSig, notably transport of other end-end signalling such as DPNSS or 
similar.  I believe that the doc should allow for the class of similar 
cases, ie say basically: "INFO is ok/good for its original intent, which 
is to carry end-end signalling between ends that understand common 
signalling other than SIP, and need it as part of their gateway (or other) 
functions". 

I also believe the document should be aimed at Informational, or possibly 
BCP, since it gives context, explanation and advice.  Don't see the value 
in updating INFO Method RFC 2976, if that were to mean including the MUST 
NOTs of sec 4 in a rev of that spec or anything functionally equivalent to 
that.  It could not be enforced in any way ("not the protocol police"). 
And besides the cat is already out of that bag anyway. 

-- Peter

Eric Burger <[email-masked]>
21.08.07 17:37
 
        To:     "'sip'" <[email-masked]>
        cc: 
        Subject:        [Sip] INFO

Any thoughts on

???

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.

---

From: Eric Burger <[email-masked]>
Date: Thu, 30 Aug 2007 18:03:15 -0400

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" <[email-masked]> wrote:

>> 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.
>> 
>>

---

From: "Hadriel Kaplan" <[email-masked]>
Date: Fri, 31 Aug 2007 01:41:26 -0400

Hey Eric,
I read the draft and was especially interested in the claim that KPML
consumed less bandwidth than INFO for DTMF.  You cite an IEEE paper, but I
don't think that's freely available.  Can you summarize how you came to such
a conclusion?  When I do the numbers, KPML often loses... in some scenarios
by a LOT.  And it's not even just the extra bandwidth/messages, but also the
state and processing horsepower.  There is one scenario where KPML wins, for
some SIP boxes but not others.
Although that could all be because I either don't correctly understand the
actual way KPML would be used, or because the use cases I am concerned with
are not the same as those in your paper's analysis. 

-hadriel

> -----Original Message-----
> From: Eric Burger [mailto:[email-masked]]
> Sent: Tuesday, August 21, 2007 5:37 PM
> To: 'sip'
> Subject: [Sip] INFO
>

---

From: Peili Xu <[email-masked]>
Date: Fri, 31 Aug 2007 14:31:12 +0800

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:[email-masked]] 
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" <[email-masked]>
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.
> 
http://www.ietf.org/internet-drafts/draft-burger-sip-inf
o-01.txt
>> 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-masked] for questions on
current sip Use 
>> [email-masked] 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://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP
Protocol Use [email-masked] for
questions on current sip Use [email-masked] for new
developments on the application of sip