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
