Subject: Re: [Sip] INFO

From: Eric Burger <[email-masked]>
Date: Tue, 04 Sep 2007 10:59:48 -0700

Quite true.  As I recall, sentiment in the room in Chicago was not to "fix"
INFO.  This was because we now have SUBSCRIBE/NOTIFY and control channels.
In fact, one could offer we really should deprecate SIP-T, as a control
channel would be a MUCH better mechanism for transporting Q.931, Q.sig,
DPNSS, etc.  Why?  Because you can put your stack directly on top of a TCP
channel, instead of having to deal with hacking it into SIP messages.

On 8/31/07 12:01 PM, "Hadriel Kaplan" <[email-masked]> wrote:

> I think he's saying it's something that could be resolved by
> standardization. (maybe)
> 
> At least the way I read your draft, the draft makes arguments against INFO
> of two different types, as if they were of similar weight and impact - but
> that's not really the case.  There is one set of problems with INFO that
> exist because of architectural issues, which are probably not fixable, and
> are generally damning.  There is a separate set which are problems merely
> because no standard exists for how to address them, but they could be
> resolved.  This latter type is not really a "Why INFO is bad in general", as
> much as a "what the current problems are with INFO that we should fix if we
> want to keep using INFO".
> 
> -hadriel
> 
>> -----Original Message-----
>> From: Eric Burger [mailto:[email-masked]]
>> Sent: Friday, August 31, 2007 11:33 AM
>> To: Jeroen van Bemmel; Peili Xu
>> Cc: sip
>> Subject: RE: [Sip] INFO
>> 
>> *How* do they signal what they support?  In an INFO?  <jk>
>> 
>> -----Original Message-----
>> From: Jeroen van Bemmel [mailto:[email-masked]]
>> Sent: Friday, August 31, 2007 11:29 AM
>> To: Eric Burger; Peili Xu
>> Cc: sip
>> Subject: RE: [Sip] INFO
>> 
>> Since INFO is mid-dialog, the endpoints can signal what they support. It
>> does not need to be known a priori
>> 
>> Regards,
>> Jeroen
>> 
>> -----Oorspronkelijk bericht -----
>> Van: "Eric Burger" <[email-masked]>
>> Aan: "Peili Xu" <[email-masked]>
>> CC: "sip" <[email-masked]>
>> Verzonden: 31-8-07 00:03
>> Onderwerp: 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.
>>> 
>> 
>> 
>> 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

---

From: Eric Burger <[email-masked]>
Date: Tue, 04 Sep 2007 10:59:48 -0700

---

From: "Christer Holmberg (JO/LMF)" <[email-masked]>
Date: Tue, 11 Sep 2007 11:38:17 +0200

Hi,

I agree with Hadriel. Just because we may have to work on something
("what are the current problems"), e.g. ragarding indication of support,
it doesn't mean we shouldn't do it.

Regards,

Christer

>At least the way I read your draft, the draft makes arguments 
>against INFO of two different types, as if they were of 
>similar weight and impact - but that's not really the case.  
>There is one set of problems with INFO that exist because of 
>architectural issues, which are probably not fixable, and are 
>generally damning.  There is a separate set which are 
>problems merely because no standard exists for how to address 
>them, but they could be resolved.  This latter type is not 
>really a "Why INFO is bad in general", as much as a "what the 
>current problems are with INFO that we should fix if we want 
>to keep using INFO".
> 
> -hadriel
> 
> > Since INFO is mid-dialog, the endpoints can signal what 
> they support. 
> > It does not need to be known a priori
> > 
> > Regards,
> > Jeroen
> > 
> > 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.
> > 
> > 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...
> > 
> > 
> > > signaling, or simulate PSTN services at SIP entities such 
> as SIP UA 
> > > or
> > 
> > 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.
> > 
> > 
> > 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
> 
> 
> 
> This list is for NEW development of the core SIP Protocol Use 
> [email-masked] for questions on current sip