Paul: In fact if INFO is outlawed for anything but DTMF.... ATIS and tispan 3 will probably use Message in doing the npt book mark stuff... And there are quite a few proprietary use cases that will never show up on the list. Yes I do know the argument that "they are proprietary and we dont care about... Let the devil take them ..." I am not sure about that one Sam
________________________________ From: Paul Kyzivat [mailto:[EMAIL PROTECTED] Sent: Thu 12/6/2007 9:13 PM To: Hadriel Kaplan Cc: [email protected] Subject: Re: [Sip] INFO use-cases Hadriel, I buy some of your use cases, but not others. Comments below. A competitor for INFO in several of these is MESSAGE. I think a good case can be made for that if the information is to be rendered to the recipient. Paul Hadriel Kaplan wrote: [snip] > /**************** > * 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. For this case MESSAGE seems entirely appropriate. (Not so much so for vcard, which probably isn't intended to be directly rendered to the recipient.) > 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). Yes to MESSAGE. > 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. UPDATE with geo-loc is reasonable here, or even reINVITE. > 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? This is very definitely a use case for MESSAGE. Also, all of the above could probably be justifiably sent via MSRP - either directly or via the file transfer extensions. > /***************** > * 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
_______________________________________________ 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
