Hi, >No, the point is you almost always use more messages by NOT using INFO.
I think issues like that should also be documented in your draft. >However, fewer messages and not interoperable is not as good >as more messages and interoperable. Well, the initeroperability issue is still under discussion. Regards, Christer > > Hi, > > > >> [Moved to SIP by chair request] > >> > >> MUMBLEBRATZ for UA-to-UA communication will always work if you own > >> the endpoints. Might as well use INFO for MUMBLEBRATZ. > >> > >> If one wants interoperable communication or if you want to deploy > >> equipment from more than one vendor, or at least not having to > >> specify exact behavior (i.e., creating your own proprietary > >> protocol), INFO doesn't work, as already documented. > > > > If you are going to use INFO to carry videoControl > messages, of course > > those messages, and the meaning of those, must be defined and > > documented - in order to make them non-proprietary. > > > > It's the same with ISUP. You use INFO to carry SPECIFIED ISUP > > messages, and endpoints supporting ISUP know the procedures how to > > deal with the messages, because it is defined in standard > documentation. > > > >> For that matter, we can save a ton of messages if we drop all the > >> pesky negotiation in SIP. Why bother if we just "know" > >> what the endpoints will accept. We just need to start sending RTP > >> and things will just work :-) > > > > Please show me message you save by not using INFO. The > negotiation can > > in most cases be "encapsulated" in SIP messages you are > going to send anyway. > > > > But, if you use an event based mechanism, you actually WILL > get more > > SIP messages, because you need to send the NOTIFY request(s). > > > > Regards, > > > > Christer > > > > > > > > > > > > > >> > >> > >> On 7/18/07 10:10 AM, "Jesske, R" <[EMAIL PROTECTED]> wrote: > >> > >>> Dear all, > >>> I'm concerned about the discussion here and the aim of > the draft to > >>> restrict the use of INFO only to SIP-T and Q-SIG. > >>> > >>> If you now change restrict the RFC2976 you will tear down each > >>> implementation already done based on RFC2976. Like for > DTMF that is > >>> broadly used within the world. So you are against backward > >> compatibility? > >>> > >>> The draft is claiming that INFO has to be routed over each > >> proxy where > >>> the INVITE is routed to. I do not know what's the problem > >> with that. A > >>> proxy forwards and the question is how much load will this > >> cause. UA's > >>> can sent re-INVITES or REGISTER, RE-REGISTER a couple of > >> times and nobody claims that. > >>> INFO is used for UA to UA communication so is this not > >> proper enough > >>> that at least the UA's will know what to do with the MIME? > >>> INFO is ideal to sent information that has to correlate with the > >>> Dialog using other mechanisms like an 2nd stream like http or a > >>> MESSAGE or a other control protocol can not fulfil this. > >> Even it could > >>> be get lost when you want to traverse several SIP domains > >> or if you interwork with the PSTN/ISDN. > >>> > >>> The Example of DTMF for INFO can only be done at mid dialog. > >>> > >>> Using KPML --> We have minimum 4 more Messages. No > additional Load? > >>> > >>> > >>> > >>> Best Regards > >>> > >>> Roland > >>> > >>> > >>> > >>>> -----Ursprüngliche Nachricht----- > >>>> Von: Christer Holmberg (JO/LMF) > >>>> [mailto:[EMAIL PROTECTED] > >>>> Gesendet: Mittwoch, 18. Juli 2007 12:18 > >>>> An: Dean Willis > >>>> Cc: IETF Sipping List > >>>> Betreff: RE: [Sipping] comments on draft-burger-sip-info-00 > >>>> > >>>> > >>>> > >>>> Hi, > >>>> > >>>>>>>> - I disagree with the statement in chapter 1 regarding > >>>> the "context > >>>>>>>> for interpreting". The context is associated with the > >>>> content type. > >>>>>>>> > >>>>>>> > >>>>>>> Content type is, as I have repeatedly argued, completely > >>>> insufficient > >>>> > >>>>>>> for interpretation of context in the general case. What, > >>>> for example, > >>>> > >>>>>>> does it mean when an INFO shows up with a wav file > >>>> attached? Play it? > >>>>>>> Record it? Parse it using speech recognition and pass it > >>>> to a command > >>>> > >>>>>>> processor? > >>>>>> > >>>>>> The dialog (you can't send INFOs out-of-dialog, as far as I > >>>> know) will > >>>> > >>>>>> be associated with an application, and if the application > >>>> doesn't know > >>>> > >>>>>> what to do with it, it can promt the user: "You have now > >> received a > >>>>>> file. What do you want to do with it? Save it? Play it? > >> Display it? > >>>>>> Delete it?". > >>>>> > >>>>> And how does the receiver know what the sender intended? > >>>>> > >>>>> Assume you're taking to my "phone" application. You send digits. > >>>>> Should those be rendered to me, or fed into the user > >> interface of a > >>>>> phone-based game we happen to be playing? > >>>> > >>>> How do you solve it with 2833? > >>>> > >>>> How do you solve it with KPML? > >>>> > >>>> You could even have the same problem with normal voice, e.g. > >>>> if the game > >>>> is controlled using voice recognition. Shall the > received voice be > >>>> fed to the speaker, or fed to the game application? > >>>> > >>>> In some cases it may not matter if the data is fed to multiple > >>>> applications. But, if you do need to dispatch data so specific > >>>> applications you either need some kind of application > >> reference, or > >>>> you handle the dispatching locally in your device (the game > >>>> application can tell it wants DTMFs, and/or the device chooses - > >>>> either automatically or manually - which application > will get the > >>>> data etc). Or you use different SIP sessions. > >>>> > >>>> In other cases you will not have the problem. For example, > >>>> videoControl messages would normally be fed to a video control > >>>> application, and nowhere else. > >>>> > >>>> Regards, > >>>> > >>>> Christer > >>>> > >>>> > >>>> > >>>> _______________________________________________ > >>>> Sipping mailing list > >> https://www1.ietf.org/mailman/listinfo/sipping > >>>> This list is for NEW development of the application of SIP Use > >>>> [EMAIL PROTECTED] for questions on > current sip Use > >>>> [email protected] for new developments of core SIP > >>>> > >>> > >>> > >>> _______________________________________________ > >>> Sipping mailing list > https://www1.ietf.org/mailman/listinfo/sipping > >>> This list is for NEW development of the application of SIP Use > >>> [EMAIL PROTECTED] for questions on current sip Use > >>> [email protected] for new developments of core 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. > _______________________________________________ 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
