In regard to your use case 1, then if we follow the Alan Johnston draft, this would be a header being transported rather than a body, whereas all the cases we have been discussing so far have been message body transport issues. If you mean something different, then it would be probably be better to use a different term that "user to user".
Regards Keith > -----Original Message----- > From: Christer Holmberg [mailto:[EMAIL PROTECTED] > Sent: Friday, December 07, 2007 1:22 AM > 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 > _______________________________________________ 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
