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

["Elwell, John" <[e-mail]>]

Dean,

Thanks for your comments. More below.

John 

> -----Original Message-----
> From: Dean Willis [mailto:[e-mail]] 
> Sent: 09 January 2008 19:26
> To: Elwell, John
> Cc: Hadriel Kaplan; IETF SIP List
> Subject: Re: [Sip] draft-kaplan-sip-info-use-cases-00 - more 
> use cases?
> 
> 
> 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?
[JRE] Not very different, except that it is correlated to the dialog
without having to do extra work such as using Target-Dialog. Whether
dependence on GRUU is seen as a significant problem I am not sure.

> 
> >
> > 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.
[JRE] Another good one.

> 
> >
> > 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.
[JRE] Yes. I guess what I am driving at is that if we had a
INVITE-initiated dialog notification mechanism, it should not be
restricted to INFO, but should be applicable to other mid-dialog methods
where appropriate, e.g., re-INVITE, UPDATE, BYE.

> 
> >
> > 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.
[JRE] In general, yes. I am not sure whether there are any exceptions
where INFO might still fit.

> 
> >
> > 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