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 PROTECTED]> 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 PROTECTED] >> 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 PROTECTED] >> 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 PROTECTED]> >> Aan: "Peili Xu" <[EMAIL PROTECTED]> >> CC: "sip" <[email protected]> >> 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 PROTECTED]> 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 PROTECTED] for questions on current sip >> Use [EMAIL PROTECTED] 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 PROTECTED] for questions on current sip Use [EMAIL PROTECTED] for new developments on the application of sip
