On Jan 9, 2008, at 3:58 AM, Elwell, John wrote:
Hadriel,
Some possible further use cases:
1. Along the same lines as 6.2/6.3/6.4 (vcard, user-icon,
vcalendar), we
could also consider pictures, movie clips, audio clips, etc.. Of
course,
we don't want to encourage sending anything too big along the
signalling
path, so we would need to consider where to draw the line.
So, how is this different from MESSAGE with the "gruu" as the target?
Does it gain anything from being in-dialog? Does it gain from the
specific content-type and usage negotiation? If so, does this mean we
should fix this problem for MESSAGE too?
2. We already have the conference event package for obtaining
conference
membership details. In many situations the conference focus is also
the
source of such notifications, so the subscribe-initiated dialog
parallels the INVITE-initiate dialog, which is rather wasteful. It
would
be great to subscribe as part of the INVITE transaction and receive
notifications along the INVITE-initiated dialog.
I like this one a lot. It could rip a LOT of the overhead out of
conference setup, especially for conferences with restricted
functionality.
A variant of this is synchronized browsing within the conference --
INFO messages that convey the current URL that should be rendered.
3. Concerning mobility, I like the suggestion in 6.8 (geo-location
information). Also, there may sometimes be intermediaries on the
signalling path (B2BUAs) that are involved in mobility in some way,
and
these might be interested in movement-related notifications (e.g., a
dual mode device moving in or out of WLAN range).
4. The use of offer-answer to achieve hold-retrieve fails to give an
explicit indication of what is happening. An explicit indication of
things like hold, retrieve, microphone mute, speaker mute, camera
on/off, recorder on/off, etc. might be quite helpful. Of course, there
will normally be an offer-answer exchange at the same time, so
inclusion
of the notification in a re-INVITE or UPDATE request might be more
useful than using INFO.
I suspect adding something to the reINVITE to convey explicit
semantics would be much better than an INFO here.
5. Concerning 6.7 (soft-key labels), a problem here is that the
notifying UA might not have knowledge of soft key availability at the
receiving UA. In certain closed environments (e.g., involving a UA and
its local voicemail server) it may work, but I am not sure it would
work
well in general. Having said that, where it does work, perhaps other
parameters at the device can be controlled in this way, e.g.,
microphone
and speaker volume (especially if this control is based on say a web
interface, so the user is really controlling his/her own settings from
the web page rather than directly on the device).
A soft-key INFO package would need to describe availability. This is
a fundamental problem from KPML, and to the extent it is solvable by
KPML in a SUBSCRIBE dialog, it should be solvable in an INVITE dialog.
6. When a B2BUA performs 3PCC there is plenty of scope for the UAs to
lose track of what is happening. For example, when a B2BUA holds,
retrieves, transfers calls, joins calls, pre-empts calls, etc.,
there is
currently no explicit information - only perhaps a re-INVITE request.
Thus it can be difficult to know how to interpret things like
identity.
Say a UA receives a re-INVITE request with a new PAI, it might deduce
that something like call transfer has occurred. However, if it
receives
a re-INVITE request without a PAI, does it mean the previous PAI is
still valid, or does it mean, following transfer, there is no
longer any
identity available? Of course, INFO might not always be the most
appropriate method to use for such notification if an offer-answer
exchange is needed at the same time.
I'm thinking this is totally NOT an INFO problem. If it needs to be
solved, it needs to happen in the 3PCC reINVITE sequence.
7. There might be some usages to do with interworking with TDM, e.g.,
advice of charge during a call, user-to-user information during a
call.
Clearly, all the old TDM interworking mid-call events work better
with the new INFO. Advice-of-charge would appear to be easily solved
with INFO, except that some use cases for it require delivering the
final AOC after the call has completed. There may some flexibility on
this, of course, but a dialog-correlated MESSAGE to the GRUU may be
cleaner.
--
Dean
_______________________________________________
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
