No, the point is you almost always use more messages by NOT using INFO. However, fewer messages and not interoperable is not as good as more messages and interoperable.
On 7/21/07 2:51 PM, "Christer Holmberg (JO/LMF)" <[EMAIL PROTECTED]> wrote: > > > 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
