Sorry I should have clarified - meant that just as a general comment, but partly because I thought you were saying anything fitting into your use-case-1 would qualify as legitimate use. I didn't mean to imply you weren't in agreement. :)
-hadriel > -----Original Message----- > From: Christer Holmberg [mailto:[EMAIL PROTECTED] > Sent: Friday, December 07, 2007 1:56 PM > To: Hadriel Kaplan; Ganesan Sam-W00184; [email protected] > Subject: RE: [Sip] INFO use-cases > > > Hi, > > >Yeah, but I think we do have to recognize there really are > >use cases that are simply wrong to do using INFO. > > I agree. I've never said anything else :) > > >There's nothing the IETF or anyone can do to stop people from doing > >them (there's no RFC interpol), but that doesn't mean we > >should give them explicit blessing either, and a draft such > >as Eric's really is the best we can do if we can't find > >legitimate use cases. That's why I like Jonathan's proposal > >for finding good use-cases, which is what I wanted to say at > >the mic at the end of that debate. > > Yes, and that is what we are trying to do now. > > The two use-cases I gave I believe are valid use-cases for INFO. > > Or, was your mail a reply to Sam's mail? > > Regards, > > Christer > > > > > > > > > > There is, though, another aspect to this. As we all know, > > interoperability is a major SIP issue, and even if we > > discourage INFO use we know it will be used. So an > > unresolved question in my mind is whether we should define at > > least how such proprietary use can be signaled, to avoid > > vendor-specific static configuration profile proliferation > > making interop harder. In other words: not accept draft > > proposals for INFO use, not be bothered with repeating these > > discussions anymore in the IETF, etc.; but at least give them > > a standardized way to negotiate it so their UAs can > > interoperate with legitimate IETF-following UAs without > > needing configuration. > > > > -hadriel > > > > > > > -----Original Message----- > > > From: Christer Holmberg [mailto:[EMAIL PROTECTED] > > > Sent: Thursday, December 06, 2007 8:22 PM > > > To: Ganesan Sam-W00184; Hadriel Kaplan; [email protected] > > > Subject: VS: [Sip] INFO use-cases > > > > > > Hi, > > > > > > Use-case 1: > > > ----------------- > > > > > > One use-case is the transport of user-to-user information, and the > > > reasons people don't think it's feasible to establish a media plane > > > connection for this are (at least): > > > > > > 1. The information will not be sent for every call, and > > when sent the > > > amount of information is relatively small 2. In > > interworking cases the > > > information may be received out-of-band from the "other > > side", so it > > > is seen as unfeasible to send it down to the MG - in some cases the > > > interworking may even be performed without a MG. > > > > > > > > > Use-case 2: > > > ----------------- > > > > > > Pretty much the same arguments are also used for sending > > DTMF out-of-band. > > > In addition there may be intermediate entities, without > > media access, > > > which are interested in the DTMF information. > > > > > > > > > (I hope we have understood the arguments why people want to > > use INFO > > > instead of SUB/NOT, so I will not go into that again.) > > > > > > Regards, > > > > > > Christer > > > > > > ________________________________ > > > > > > Lähettäjä: Ganesan Sam-W00184 [mailto:[EMAIL PROTECTED] > > > Lähetetty: pe 7.12.2007 1:46 > > > Vastaanottaja: Hadriel Kaplan; [email protected] > > > Aihe: RE: [Sip] INFO use-cases > > > > > > > > > I also know of a use case where video npt bookmarks are > > sent over INFO > > > across the SIP path while using SIP for video stream set > > up. Tispan 3 > > > is actually writing specs on this and so is ATIS... > > > > > > > > > Sam > > > > > > ________________________________ > > > > > > From: Hadriel Kaplan [mailto:[EMAIL PROTECTED] > > > Sent: Thu 12/6/2007 6:38 PM > > > To: [email protected] > > > Subject: [Sip] INFO use-cases > > > > > > > > > > > > Howdy, > > > Jonathan asked for use-cases for what types of things would need an > > > in- dialog SIP message for user-user communication, vs. > > should be done > > > either out of dialog or in the media plane. If the only > > use-case is > > > DTMF, then we could just document the DTMF negotiation/use only and > > > not have to create a general info-events framework. That > > seems a very > > > reasonable argument to me. I also don't want to do work for no use. > > > > > > There is a counter-argument that there are proprietary uses > > of INFO in > > > the wild, and that a framework for negotiation at least removes the > > > manual configuration of vendor-specific profiles, which is > > a problem > > > of interop today - even if the IETF should not bless/document the > > > specific use cases themselves. But that would make the > > draft a very > > > different one than it currently is as well, and I will ask > > that in a separate email thread. > > > > > > The chairs have asked for 3 use cases, and I assume they mean 3 NEW > > > use cases (we already have 3 RFCs which use INFO, as well > > as DTMF). I > > > am not sure if they mean potential future use-cases, or current > > > use-cases (i.e., already implemented). Can I get a > > clarification on that? > > > > > > So anyway, taking the shot-gun approach, here's a first go at some > > > use- cases, and my personal take on whether they should be > > in INFO vs. > > > SUB/NOT vs. media-plane, FWIW. > > > [apologize for formatting ugliness] > > > > > > /*************** > > > * Already standardized use-cases: > > > ***************/ > > > 1) SIP-T/ISUP/QSIG/PSTN > > > -Documented in RFC 3372 and RFC 4497. > > > > > > 2) ECMA TR/87 uaCSTA > > > -Uses INFO to send ECMA-323 XML for monitoring and > > controlling > > > phones from a PC. > > > > > > 3) Sending media server control commands. > > > -Documented in RFC4722 MSCML. > > > > > > > > > /**************** > > > * Use-cases that I think are potentially/possibly valid for INFO: > > > ****************/ > > > 1) Sending a vcard asynchronously. Alice calls Bob, Alice > > says "can > > > you send me John's vcard?", Bob clicks something and voila > > it's sent. > > > -Alternatives: send a re-Invite or Update with a Call-Info, > > > with either a URL reference, data URI, or MIME and CID URL. > > > -Counter-argument: IMO this type of data really belongs in > > > MIME for a number of reasons, including length is less > > restricted for > > > mime attachments; one AD has said the Data URL may be > > deprecated. And > > > sending a re-Invite for this purpose seems odd. > > > > > > -Also, the Call-Info header is really about the caller or > > > callee, and thus Bob shouldn't be sending me John's vcard > > info in it technically. > > > That may sound like a nit, but UA's may well store the call-info > > > vcards into their address-books automatically and so tie it to the > > > wrong user/call. > > > -Pros of using INFO: it's explicit what you're > > doing when you > > > send the vcard, and you can send it knowing the other end > > can accept > > > it, and you can send it based on user input. > > > > > > 2) Sending a user-icon jpeg/bitmap/gif. Alice calls Bob, > > Bob has an > > > icon that represents himself, sends it when he picks up the phone. > > > -Alternatives: send a 200ok, re-Invite, or Update with > > > call-info, which explicitly has a type for icon. > > > -Counter-argument: same as for vcard, plus with call-info > > > there is no way to know which picture format the far-end supports a > > > priori. With a supported-package negotiation one could know. > > > > > > 3) Sending a vcalendar-type invitation. Alice calls Bob, Bob says > > > "hey let's have a con call at time X", clicks and voila his phone > > > sends a vcalendar. > > > -Whether the vcalendar is related to the session or not and > > > thus whether it should be sent in an in-dialog request or not is > > > certainly debatable. Message method can already be used > > for this anyway. > > > > > > 4) Sending an HTTP URL. Alice calls Bob, a sales guy; > > Alice asks for > > > more info or a datasheet and Bob sends a URL for Alice to open with > > > her web- browser. > > > -One could also argue this is just making SIP the > > new SMTP, or > > > this should be sent using MESSAGE (which really is the new SMTP). > > > > > > 5) Sending a session traceroute. Alice calls Bob, Bob > > answers, Alice > > > does a sip-traceroute to figure out the path to Bob, by > > sending Info > > > with an incrementing max-forwards type header starting at 0 > > (but not > > > really max- forwards), with a sip-frag type response body > > or some such. > > > -It's debatable if certain types of B2BUA's (ie, > > SBCs) would > > > ever allow this type of thing to happen, due to security > > concerns, but > > > I think they may do it at domain boundary hops. I think this is a > > > reasonable use for INFO though, maybe. > > > > > > 6) Sending geo-location information after call > > establishment. Alice > > > calls Bob, a hotel receptionist. Alice asks for directions > > to hotel, > > > clicks button and sends him location info of her phone (or > > Bob clicks > > > button and sends her his location). > > > -The location conveyance draft specifically calls > > out INFO as > > > acceptable for geo-loc info. Whether this is a real use-case is > > > debatable, and obviously it could be done with a sub/not. > > > > > > 7) Sending softkey-labels (not digit-match maps, but rather softkey > > > button labels). Alice calls her vmail server. Vmail server sends > > > softkey-labels for the menu items available in the response, Alice > > > presses softkeys and sends them in INFO. > > > -This could (and maybe should) be done with sub/not, a la > > > KPML, where the vmail server sends the softkey labels in the > > > Subscribe, UA sends buttons pressed in Notifies. But this > > is similar > > > to the DTMF use case so may well have the same benefit of lower > > > overhead since buttons are rarely pressed. > > > > > > 8) Sending a screen-pop-up message, e.g., "Do you want to continue > > > with this session?" > > > -There is a patent for doing screen pop-ups using INFO. I > > > guess Alert-Info could be used for this, but it's not clear > > it should? > > > > > > > > > /***************** > > > * Use-cases which have been proposed by others or even implemented, > > > * which are dubious for INFO (IMHO): > > > *****************/ > > > 1) Sending RTP/RTCP statistics during call. > > > -There is an implementation of this, and the > > rationale is the > > > signaling plane box that wants this info is not actually the media > > > plane box that gets RTCP. Again this could (and IMO > > should) be done > > > with sub/not, so it can get stats after the call is over, > > and since it > > > will probably want periodic reports the overhead of the Subscribe > > > should be dwarfed by the number of Notifies. > > > > > > 2) Sending access-location information after call establishment. > > > -There is a P-Access-Network-Info header, and some have > > > proposed to send an update for it as a phone roams access points or > > > cells. But I think this is an odd thing to do inside an Invite > > > session, vs. in a sub/not or Register (and besides half the > > time the > > > network inserts this header, not the UA). > > > > > > 3) Sending media-control indications (ie, remote-control > > > "play/pause/etc.") > > > -This is done today by at least one vendor, but is > > debatable > > > if it's the right model. The argument is it's like SDP > > re-Invite for > > > hold, except at a media content layer above RTP, so not > > done in RTCP nor SDP. > > > > > > 4) Sending video fast update command > > > -This is an informational draft, which documents > > what has been > > > implemented, but states it should really be done in the media plane. > > > > > > 5) Sending peripheral control commands (ie, USB commands) > > > -There is actually a patent on this, amazingly. Someone > > > thinks it makes sense to create a SIP session to your laptop, or > > > vice-versa, and then send USB commands inside MIME in INFO > > messages. > > > Methinks this should be media-plane, if anything. > > > > > > 6) Sending charging information for a call (i.e., minutes > > remaining or > > > cost so far). > > > -There was a proposal to use this for Advice of Charge > > > information in TISPAN. IMO it should be a sub/not though, as they > > > want this to survive the Invite session. > > > > > > -hadriel > > > > > > > > > _______________________________________________ > > > 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 > > > > > > > _______________________________________________ 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
