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

[Paul Kyzivat <[e-mail]>]

inline...

Dean Willis wrote:
> 
> On Jan 9, 2008, at 3:58 AM, Elwell, John wrote:
> 

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

The problem with giving an explicit indication of what is going on is 
that it requires agreement on the set of things that *can* go on.

This means standardizing a set of features, which probably isn't going 
to happen, because it will have the effect of limiting feature development.

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

Same comment as for (4).

	Paul

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


_______________________________________________
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