Hi, >By Internet, I mean a network of nodes with different >implementations (vendors) across different administrative >domains (service providers and enterprises). If you have a >Sonus softswitch talking to a Sonus softswitch life is good. >If you have a Nortel softswitch talking to a Nortel >softswitch life is good. If you have a Cisco MGC talking to a >Cisco MGC life is good.
For that you don't need to standardize anything. You don't even need SIP. >If you want to mix and match, life is good for Acme and NexTone, to name a few. I do want to mix - it's good for me too :) >AFAIK, only MSCML (RFC 4722) bothers to even try to negotiate >content and understanding of the INFO messages. > >I would very quickly concede that one could fix INFO. That >was the point of Dean's draft. However, I think it is way >too late to go that route. I think it's way too late to start restricting the usage of INFO. I agree that we should have fixed it earlier, so that people using INFO would have some standard ground to stand on. Regards, Christer -- Mail sent from my desktop device - using INFO - and Eric is able to read it :) And, we all need beer... > -- > Sent from my wireless e-mail device. Sorry if terse. We all > need lemonade: see > <http://www.standardstrack.com/ietf/lemonade> for what lemonade is. > > -----Original Message----- > From: Christer Holmberg (JO/LMF) <[EMAIL PROTECTED]> > To: Eric Burger; [email protected] <[email protected]> > Sent: Mon Jun 18 13:10:42 2007 > Subject: RE: [Sip] INFO usage (or not) > > > Hi, > > >I agree: in a limited deployment scenario, like an > application server > >connected to a media server using a yellow cable as a proxy and an > >application bought from a single systems integrator, there is no > >interoperability problem. > >However, the info incompatibility problem is real - I have > experienced > >it in the wild. > > So, why don't you explain what problems you have seen? > > Because, I have seen implementations - from different vendors > - working fine togheter. > > Of course, maybe there are also implementations which do NOT > interop widely, but they probably have been implemented > without any use of the negotiation mechanisms etc that we > have in SIP, with a very limited deployment scope in mind. > There is not much we can do about that, but those kind of > scenarios are not what I have been talking about. > > >You are correct in asserting that one can make INFO work - we were > >doing it in 2001. However, working in the Internet is a > different case > >altoghether. > > What do you mean by "Internet"? > > Regards, > > Christer > > > > > > > Sent from my wireless e-mail device. Sorry if terse. We all need > > lemonade: see <http://www.standardstrack.com/ietf/lemonade> > for what > > lemonade is. > > > > -----Original Message----- > > From: Christer Holmberg (JO/LMF) <[EMAIL PROTECTED]> > > To: Eric Burger; Keith Drage <[EMAIL PROTECTED]>; > IETF SIP List > > <[email protected]> > > Sent: Mon Jun 18 02:19:55 2007 > > Subject: RE: [Sip] INFO usage (or not) > > > > > > Hi, > > > > I am very concerned some some people use the word > "newbies", and make > > it sound that people using INFO are beginners which have no > clue about > > SIP. > > > > Also, I have never heard about interoperability problems with INFO. > > One reason people are using INFO for certain things IS in order to > > interop with other implementations. > > > > I am also confused that people seem to think that INFOs will start > > flying around for no reason, without the sender having any > clue about > > whether the receiver will understand them or not. As we have > > discussed, there ARE mechanisms in SIP to negotiate what > content types > > etc entities support. Yes, MAYBE we need to extend that (e.g. being > > able to indicate which methods can be used to carry a > specific content > > type), if what we have is not enough. But, to me that is > not the same > > thing has having "tons of problem". > > > > Having said that, if there are issues with INFO, I have nothing > > against discussing them. But, if you are going to talk about > > alternative solutions, you also need to look at possible > issues with > > those (having to set up multiple dialogs just in order to send some > > DTMFs associated with another dialog etc). > > > > We can sit in our <insert-your-favorite-Hilton-hotel> meeting rooms > > and write whatever you-must-to-this-and-you-must-not-do-that > > documents, but if we don't care about the feedback we get from the > > real world OUTSIDE the meeting room it won't help much. In the long > > run it will cause more harm than good. > > > > Regards, > > > > Christer > > > > > > > > > > > > > -----Original Message----- > > > From: Eric Burger [mailto:[EMAIL PROTECTED] > > > Sent: 17. kesäkuuta 2007 12:53 > > > To: Keith Drage; IETF SIP List > > > Subject: Re: [Sip] INFO usage (or not) > > > > > > How about this: > > > > > > This document describes why the Session Initiation Protocol > > > (SIP) INFO method, introduced in RFC 2976, has serious > > issues with any > > > use outside its use as a transport mechanism for ISDN User > > Part (ISUP) > > > call signaling in SIP-signaled networks. In the years since the > > > introduction of the INFO method, the IETF has published numerous, > > > interoperable extensions to SIP. > > > This document explains why there are INFO-based, > > proprietary protocols > > > in the wild; the flaws of using INFO; and prescriptions for > > how to use > > > existing, interoperable SIP mechanisms to accomplish most > > any of these > > > tasks. > > > > > > > > > My personal preference is for the document to be Standards > > Track and > > > be a Work Group chartered item. The reason is that for > > this document > > > to be useful, it MUST update RFC 2976. If it updates RFC > > 2976, then > > > newbies get the pointer when the download RFC 2976, > > pointing them to > > > this document, before they go off, create > > draft-mumble-foo-over-INFO, > > > and get flamed on the list. The essence of the normative > > content of > > > the document is, "one MUST NOT use INFO for anything other than > > > transporting ISUP or QSIG messages." > > > > > > Because the normative content is so thin, I could understand not > > > saying that and making the document Informational (or BCP). > > However, > > > I really and truly believe that will significantly reduce > > the impact > > > the document will have. > > > > > > > > > Outline: > > > Introduction > > > - Requirements for UA-to-UA signaling > > > - The INFO method > > > - The INFO method for ISUP signaling Issues with INFO > > > - No or incomplete negotiation > > > - No real identification of payload purpose on receipt > > Alternatives to > > > INFO > > > - State Updates: SUBSCRIBE / NOTIFY > > > - DTMF Transport: KPML (an example of state updates) > > > - Establishment of direct UA-to-UA signaling channel: MRCPv2, MSRP > > > - Prescriptions for deciding which method is appropriate > under what > > > circumstances Update to RFC 2976 > > > - Limiting use of INFO to ISUP transport only Security > > Considerations > > > > > > > > > > > > > > > > > > On 6/13/07 9:28 AM, "DRAGE, Keith (Keith)" > > > <[EMAIL PROTECTED]> wrote: > > > > > > > (As WG chair) > > > > > > > > We have got a number of threads floating round on INFO > > > usage, and it > > > > would be nice to identify this into a potential body of > > > work, and see > > > > if there is support for it. > > > > > > > > We have two previous drafts that never went anywhere, although > > > > contents of both carried support in the WG at the time: > > > > > > > > http://tools.ietf.org/html/draft-rosenberg-sip-info-harmful-00 > > > > > > > > The Session Initiation Protocol (SIP) INFO method > > > defines a means for > > > > transporting mid-dialog application layer data between > > > user agents. > > > > Its initial use was to support the transport of ISUP mid-call > > > > messages which could not be mapped to any other SIP > > > request method. > > > > However, since its initial usage for that purpose, > > INFO has seen > > > > widespread abuse as a means for introducing non-standard and > > > > non-interoperable extensions to SIP. For this reason, > > > we now believe > > > > INFO should be considered harmful, and therefore, > > > deprecated in its > > > > current form. > > > > > > > > http://tools.ietf.org/html/draft-willis-sip-infopackage-00 > > > > > > > > The SIP INFO method (RFC 2976) establishes a method by which > > > > applications may transfer application-specific > > > information within a > > > > SIP dialog. However, RFC 2976 does not provide a > mechanism for > > > > describing and documenting an application of INFO, > nor does it > > > > provide a mechanism by which applications may negotiate > > > such uses. > > > > This document provides a framework for documenting and naming > > > > specific uses of INFO (called INFO packages), for > > > registering those > > > > package names with IANA, and for negotiating the support > > > for various > > > > INFO packages between applications using SIP. > > > > > > > > In the thread so far there have also been suggestions > that cover: > > > > > > > > - support to mediactrl for their discussion on requirements > > > > - something for hitchhiker's guide to point to: > > > > - something that answers all the questions that recur on > > > this list on > > > > INFO usage > > > > - "I've been getting a lot of offline questions asking for > > > the "right" > > > > way to carry information related to the session-usage (often > > > > information that's being tunneled around from companion or > > > gatewayed > > > > protocols)." > > > > - INVITE dialog usage only, or already covered by RFC 2976 > > > > - It would be OK with me if we ALSO had this type of > > > guidance ("don't > > > > look HERE, look over THERE") available ("stated strongly > > > enough in an > > > > easy to stumble across place"), but if coming up with > > that guidance > > > > takes more than about a week, I don't see a lot of reason > > > to hold up > > > > on "don't go there" > > > > while we explore alternatives. > > > > - INFO and DTMF > > > > - XML payloads > > > > - But people really need is guidance on when to use INFO, > > > when to use > > > > events, and when to use something entirely different. > > > > - identification of purpose of info (Content-Type? - impacted by > > > > multipart/mixed) > > > > - any framework for control of usages (IANA registration? - RFC > > > > 3427 update) > > > > > > > > Would anybody out there like to have a go at drafting an > > > abstract for > > > > a potential WG deliverable (and also identifying level - > > Info, BCP, > > > > standards track) and submitting it to the list for discussion. > > > > Remember an abstract needs to: > > > > > > > > > > > > > > ---------------------------------------------------------------------- > > > > -- > > > > ------- > > > > Every RFC must have an Abstract section following the > > > Copyright notice. > > > > An Abstract will typically be 5-10 lines. An Abstract of > > > more than 20 > > > > lines is generally not acceptable. > > > > > > > > The Abstract section should provide a concise and comprehensive > > > > overview of the purpose and contents of the entire > > > document, to give a > > > > technically knowledgeable reader a general overview of the > > > function of > > > > the document. In addition to its function in the RFC > itself, the > > > > Abstract section text will appear in publication > > > announcements and in > > > > the online index of RFCs. > > > > > > > > Composing a useful Abstract generally requires thought > and care. > > > > Usually an Abstract should begin with a phrase like "This > > > memo ..." or > > > > "This document ...". A satisfactory abstract can often be > > > constructed > > > > in part from material within the Introduction section, > but a good > > > > abstract will be shorter, less detailed, and perhaps > > > broader in scope > > > > than the Introduction. Simply copying and pasting the first few > > > > paragraphs of the Introduction is tempting, but it may > > result in an > > > > Abstract that is both incomplete and redundant. Note > also that an > > > > Abstract is not a substitute for an Introduction; the RFC > > should be > > > > self-contained as if there were no Abstract section. > > > > > > > > An Abstract should be complete in itself; it should not contain > > > > citations unless they are completely defined within the > Abstract. > > > > Abbreviations appearing in the Abstract should generally be > > > expanded > > > > in parentheses. There is a small set of reasonable > > > exceptions to this > > > > rule (see guidelines on abbreviations, above.) > > > > > > > > > > ---------------------------------------------------------------------- > > > > -- > > > > ------ > > > > > > > > And as such should give a clear idea of whether there is > > > anything we > > > > should charter here or not. > > > > > > > > Regards > > > > > > > > Keith > > > > > > > > > > > > _______________________________________________ > > > > 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 > > > > > > > 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. > > > > 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
