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

From: "Elwell, John" <[email-masked]>
Date: Wed, 09 Jan 2008 09:58:14 +0000

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.

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.

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.

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

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.

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.

John

_______________________________________________
Sip mailing list  https://www1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use [email-masked] for questions on current sip
Use [email-masked] for new developments on the application of sip

---

From: Dean Willis <[email-masked]>
Date: Wed, 9 Jan 2008 13:26:22 -0600

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

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

> of the notification in a re-INVITE or UPDATE request might be more

I suspect adding something to the reINVITE to convey explicit  
semantics would be much better than an INFO here.

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

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

> advice of charge during a call, user-to-user information during a  

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

---

From: "Elwell, John" <[email-masked]>
Date: Wed, 09 Jan 2008 20:50:45 +0000

Dean,

Thanks for your comments. More below.

John 

> -----Original Message-----
> From: Dean Willis [mailto:[email-masked]] 
> 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?
> 
> 
[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.

> > membership details. In many situations the conference focus 
> is also  
> > the
[JRE] Another good one.

> > signalling path (B2BUAs) that are involved in mobility in 
> some way,  
> > and
[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.

> > its local voicemail server) it may work, but I am not sure 
> it would  
> > work
[JRE] In general, yes. I am not sure whether there are any exceptions
where INFO might still fit.

---

From: Paul Kyzivat <[email-masked]>
Date: Sat, 12 Jan 2008 22:12:10 -0500

inline...

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

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

Same comment as for (4).

	Paul

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