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 [EMAIL PROTECTED] for questions on current sip
Use [EMAIL PROTECTED] for new developments on the application of sip
