Hey Paul, Yeah I agree MESSAGE makes a lot of sense for things to be rendered natively/directly to the user.
Regarding using MSRP: while that is obviously possible and for some cases undoubtedly the right thing to do, for some uses it is a crazy amount of overhead. For example if I want to send you a vcard mid-call, it seems silly to send a re-Invite to add an MSRP session, potentially go get msrp-relay info to do so, and/or possibly go through ICE procedures, all just to send you a 100 byte little vcard I could have sent in an INFO. But clearly if I need to send you a 10MB file it will be appropriate. My 2 cents anyway. -hadriel > -----Original Message----- > From: Paul Kyzivat [mailto:[EMAIL PROTECTED] > Sent: Thursday, December 06, 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
