Hi, I guess the MSRP overhead issue applies also to other cases where there may be some small amount of data sent at some point during the session. User-to-user information is one example. But, I fully agree that INFO shall not be used for sending 10MB of data. Regards, Christer
________________________________ Lähettäjä: Paul Kyzivat [mailto:[EMAIL PROTECTED] Lähetetty: pe 7.12.2007 3:48 Vastaanottaja: Hadriel Kaplan Kopio: [email protected] Aihe: Re: [Sip] INFO use-cases Hadriel Kaplan wrote: > 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. Yes, I agree. In some cases even though it is a rediculous amount of overhead it just won't matter and will be the right thing to do anyway if the infrastructure is there to do it. In other cases that isn't so. I'm certainly open to some uses for INFO or for more marginal uses of MESSAGE. Especially if we go ahead with this INFO enhancement I think we need to draw the line carefully between INFO and MESSAGE. Paul > -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 _______________________________________________ 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
