Re: [Sip] INFO use-cases

[Paul Kyzivat <[e-mail]>]

I'm including some comments to Jonathan's comments, inline.

	Paul

Jonathan Rosenberg wrote:
> Hadriel,
[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 argument is bogus since RFC 3261 clearly says call-info is about 
> the caller or callee:
> 
>    The Call-Info header field provides additional information about the
>    caller or callee, depending on whether it is found in a request or
>    response.
> 
> There is also a purpose parameter (a close cousin to the info-event, 
> I'll note), which is specifically about vcard.
> 
> That said, I agree data URI is bad so the real use case for call-info is 
> when the vcard is to be sent by indirection. But its clear that 
> indirection is much more of a pain than just sending the darn thing; you 
> need to store it somewhere, get a URL, and then make sure that URL is 
> derefenceable from the target, figure out when its retrieved, and then 
> delete the content once retrieved at some point. Thats clearly a lot 
> harder than just including it.

Apparently the data url has been declared politically incorrect.

But an Alert-Info or Call-Info with a CID URI should be quite reasonable 
in cases where you want to include the content in the message. (We just 
have to get settled what the Content-Disposition should be.)

> Another alternative would be MESSAGE, but I think thats wrong. The 
> reason is that MESSAGE should only be used when the one and only purpose 
> of the content is to *render*. A vcard isn't just rendered; one can 
> imagine a UA saying to a user, "bob has sent his vcard, would you like 
> to add to your contacts?" and that is NOT rendering. So MESSAGE is wrong.
> 
> ANother choice is the media channel. I agree here the overhead is high 
> for that relative to the size of the content.
> 
> So I think this is a reasonable use case in fact.
> 
>> 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.
> 
> Well, here I think the arguments are a bit more compelling for a 
> media-path channel. This could be big, very possibly bigger than 1500 
> bytes, and this puts us into issues with SIP.

3261 defines both a Call-Info purpose of "icon" and a 
Content-Disposition of "icon" as ways to send a picture of the caller.

>> 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.
> 
> Well, I'll disagree with MESSAGE again under the argument that the 
> intention here is not to render, but to have some kind of automated 
> handling which depends on the purpose of the content (and not just the 
> type). But I think this also passes the litmus test for cases where the 
> other choices besides INFO are going to add complexity, overhead, or 
> latency for no benefit; SUB/NOT is a lot of work when you have no idea 
> if you would ever even receive it. Media-path setup would be overly 
> complex and a lot of messages for something which is very likely to 
> never be sent. The size of these is small, so in the signaling path is 
> reasonable.

Frankly the whole Content-Disposition meaning is still a bit up in the 
air IMO. It may be worth a discussion of what it means to have a content 
disposition other than "render" in a MESSAGE.

>> 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).
> 
> Well, here we already have something defined - REFER with an http URL. 
> See draft-ietf-sipping-app-interaction-framework.
> 
> 
>>
>> 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),
> 
> Max-FOrwards 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.
> 
> I'm much less convinced here. This would require handling at proxies and 
> we haven't been discussing usage of INFO at proxies like this. Only e2e.
> 
>>
>> 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.
> 
> SUB/NOT seems a bit better here, I think, since the recipient knows that 
> they want it.
> 
>>
>> 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.
> 
> Rarely pressed yes, but this is an application specifically looking for 
> them. This is squarely in the territory of 
> draft-ietf-sipping-app-interaction-framework and is better handled by 
> those mechanisms.
> 
>>
>> 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?
> 
> See discussion on indirection above. I think this is reasonable for INFO 
> also.

Why isn't this a place that where MESSAGE *is* appropriate? Sure seems 
like it is to me.

>>
>> /***************** *  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.
> 
> Agree SUB/NOT is better. Its already been defined that way.
> 
>>
>> 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.
> 
> I think this is much better done via a media-plane session. There is a 
> requirement for low latency here and there will be a lot of these that 
> get sent.
> 
>>
>> 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.
> 
> Agree.
> 
> 
>>
>> 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.
> 
> Agree.
> 
> -Jonathan R.


_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [e-mail] for questions on current sip
Use [e-mail] for new developments on the application of sip