Re: [Sip] draft-kaplan-sip-info-use-cases-00 - more use cases?

[Dean Willis <[e-mail]>]

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