Yup, it's allowed. Section 4: "A UAC MAY associate a MESSAGE request with an existing dialog." -hadriel
> -----Original Message----- > From: Christer Holmberg [mailto:[EMAIL PROTECTED] > Sent: Friday, December 07, 2007 12:12 AM > To: Paul Kyzivat; Hadriel Kaplan > Cc: [email protected] > Subject: VS: [Sip] INFO use-cases > > Hi, > > Just to clarify, when we talk about MESSAGE I assume we do allow it to be > used within the invite dialog if appropriate (RFC3428 does allow it)? > > 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
