Subject: [Sipping] interactivity caller preferences parameter -- for the dialog package

From: Rohan Mahy <[email-masked]>
Date: Mon, 10 May 2004 14:39:26 -0400

Hi Folks,

Back in Korea, I presented a proposed solution to the dialog package 
"hold" discussion which I never described on the list.  It has been 
several months now, but I would like to describe this proposal now. I 
am extremely sorry and embarrassed that I have taken so long to send 
this out.

The proposal is to add a new caller preferences parameter (these are 
formally called "media feature parameters" in caller prefs).  The 
interactivity parameter indicates if a device is capable of responding 
to media received during a session in an interactive manner and if 
necessary terminating a session in which the UA is no longer interested 
in participating.

For example:

- If you are in a session with an automaton that does not respond to 
media nor run call timers (for example a simple recording service, or 
the "time of day" service in Tokyo Japan), your peer is non-interactive
- If you are in a session with an IVR-style application or an 
application with a media inactivity timeout, your peer is interactive.
- If you are in a session with a human user who just put you "on hold", 
your peer is non-interactive.
- If you are in a active session with a human call center agent in most 
call centers, your peer is interactive.
- If you are in a normal session with another human, you don't (and 
can't) know if your peer is interactive or non-interactive.  [This 
property is quite normal for caller preferences and does not diminish 
the usefulness of this parameter when you do know its value.  For 
example, it is unwise to assume that a peer is not an automata, just 
because the automata parameter is not set; the automata/human status is 
unknown.]

What can you do with this information?  (Note that in many cases 
positive knowledge that a peer is non-interactive has a more immediate 
effect than positive knowledge that a peer in interactive)

- This information can be conveyed in the dialog package and used as 
part of a shared-line implementation.  For example, if a group of 
phones have all subscribed to the dialog package for the same address 
of record, they will receive notifications whenever the local contact 
address changes in any of the dialogs for this address of record. 
Implementations could use the non-interactive parameter on a phone or a 
"parking lot" application as a way to indicate that a shared line is 
"holding" or "parked".

- This proposed property is also incredibly useful in conferencing 
scenarios.  A focus can include in the termination policy of an adhoc 
conference, the interactivity status of the participants.  For example, 
if the only participants in a conference are non-interactive, an adhoc 
conference is unlikely to be especially interesting (ex: a recording 
bot and a human who placed the conference on-hold).

I believe this satisfies all the requirements for indicating if a user 
is on hold, but captures a more fundamental and generic 
mechanism/primitive.  I believe that also maintains the "maximum 
orthogonality among attributes" property of most of the other caller 
preferences media feature parameters.

Please comment.

many thanks,
-rohan

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

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 12 May 2004 14:55:05 -0400

Rohan,

There was lots of discussion on something like this long ago, and there 
were problems getting proper semantics nailed.

What you have proposed here feels right to me.

	Paul

Rohan Mahy wrote:
> several months now, but I would like to describe this proposal now. I am 
> extremely sorry and embarrassed that I have taken so long to send this out.
> 
> part of a shared-line implementation.  For example, if a group of phones 
> have all subscribed to the dialog package for the same address of 
> record, they will receive notifications whenever the local contact 
> conference is unlikely to be especially interesting (ex: a recording bot 
> and a human who placed the conference on-hold).
>

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 14 May 2004 01:55:50 -0400

Rohan,

The definition of this continues to feel vague to me, and in fact blends 
two statements which I think are different:

1. this is an automata that will never generate a BYE on its own,
2. this call has been placed on "hold" by a user, but media is still 
being received

The first of these is a characteristic of the UA. It is not dynamic, 
doesnt change during a call, and is easy to determine whether its true 
or not. It only applies to automata. This is the parameter you had in 
mind for your first and second cases. I think this is a fine callee 
capability and I have no problem with it. I'm not sure its terribly 
useful, though. You're worried about cases where a UA brings an automata 
into a conference, and then the conference ends, but the automata 
remains, and since it never hangs up, the conference persists. Normally, 
the entity that brings in the automata should know to kick it out when 
the conference ends, so we're only talking about cases where the UA or 
user that brought in the automata leaves bfore the conference ends. I 
think this is mostly a corner case. That said, its a valid case, and so 
I am OK with this.

For the second one, I recall asking at the meeting (thought perhaps I 
just thought it and didnt ask it) what the difference was between this 
and the sendonly or inactive SDP attribute, which we've traditionally 
used for call hold. The fact that I'm not receiving media any more is 
something that is easy to determine and define, and would by definition 
make me "non interactive" since I'm not receiving your media in order to 
make a decision. I think you are concerned about cases where an endpoint 
has put a call on hold, and has not bothered to disable reception of 
media. So, my question is, why do that?

To answer my own question, the main case I can think of is actually nat 
traversal. If you stop receiving and sending media, you may end up 
causing timeouts in nat bindings in NATs. You need to keep packets 
flowing to keep those open for the whole duration of the call. As such, 
a fine solution is to use an alternative codec for "hold" periods, which 
causes low packet rates, but enough to keep the bindings open. A no-op 
RTP payload format has been proposed for this; comfort noise would also do.

In such a case, you no longer can use the sendonly/inactive as an 
indicator of hold, either to your peer or in the dialog event package, 
of the call being "on hold", and in that case you would need a 
replacement to signal it.

In such a case, its not clear to me that its actually a callee 
capability parameter. Those are meant to be more static in nature, and 
are defined as UA capabilities and characteristics. This is neither, its 
more like a state for a media stream, perhaps even closer to an 
indication of usage of a particular codec. Indeed, it would seem to me 
to be possible to be 'on hold' for some media streams and not others 
(for example, I still receive your video but not your audio), which 
would make this hard to do as a callee capabilitiy parameter. Indeed, my 
"interactivity" would be hard to define in such a case.

Thanks,
Jonathan R.

-- 
Jonathan D. Rosenberg, Ph.D.                600 Lanidex Plaza
Chief Technology Officer                    Parsippany, NJ 07054-2711
dynamicsoft
[email-masked]                     FAX:   (973) 952-5050
http://www.jdrosen.net                      PHONE: (973) 952-5000
http://www.dynamicsoft.com

---

From: Rohan Mahy <[email-masked]>
Date: Sat, 15 May 2004 08:59:04 -1000

On May 13, 2004, at 7:55 PM, Jonathan Rosenberg wrote:

> Rohan,
>
> The definition of this continues to feel vague to me, and in fact 
> blends two statements which I think are different:
>
> or not. It only applies to automata.

First of all the assertion that this characteristic can't/doesn't 
change during a call is false.  If I have a call center IVR which then 
plays hold music, the interactivity status changes mid-call.  This is a 
very common application.  Likewise most dial-in conference services 
have this property.

Second, I described the distinction between the interactivity status 
being unknown and being set to a specific value, and provided examples 
with humans where the value could be unknown (most calls), interactive 
(live call center agent), or non-interactive (on-hold).

> This is the parameter you had in mind for your first and second cases. 
> I think this is a fine callee capability and I have no problem with 
> it. I'm not sure its terribly useful, though. You're worried about 
> cases where a UA brings an automata into a conference, and then the 
> conference ends, but the automata remains, and since it never hangs 
> up, the conference persists. Normally, the entity that brings in the 
> automata should know to kick it out when the conference ends, so we're 
> only talking about cases where the UA or user that brought in the 
> automata leaves bfore the conference ends. I think this is mostly a 
> corner case. That said, its a valid case, and so I am OK with this.
>
> something that is easy to determine and define, and would by 
> definition make me "non interactive" since I'm not receiving your 
> media in order to make a decision.

certainly knowing that all media are inactive or sendonly is a good 
hint that your peer is non-interactive.  However, there are a number of 
pitfalls associated with this line of reasoning:

- many 3pcc and offer/answer/counter-offer/counter-answer scenarios set 
all media to inactive until they know their ports.  however the peer is 
typically not "non-interactive" at this point.

- this indicator exists per media type, and is embedded in the SDP.  An 
arbitrary peer subscribing to the dialog package would need to request 
session descriptions that they are unlikely to need otherwise.  in 
addition, since the session description itself may contains keys, 
private IP addresses, and other sensitive information, the subscriber 
might not be authorized to receive it.

- to prevent media clipping and to facilitate NAT and FW traversal some 
UAs don't signal sendonly or inactive.

- it is not unreasonable for me to have a software UA on my PC with a 
built-in recording function.  On such a UA, I can continue to record 
the conference I am in, while I receive or place another call.  My UA 
is not strictly an automaton (because both human and automaton use this 
UA).  However it is very clear that my status is non-interactive while 
taking the other call, and reverts to unknown when I return.  My UA 
still needs to receive media while I am taking the other call to 
continue recording.

> I think you are concerned about cases where an endpoint has put a call 
> on hold, and has not bothered to disable reception of media. So, my 
> question is, why do that?

to prevent media clipping among other things.

> To answer my own question, the main case I can think of is actually 
> nat traversal. If you stop receiving and sending media, you may end up 
> flowing to keep those open for the whole duration of the call. As 
> such, a fine solution is to use an alternative codec for "hold" 
> periods, which causes low packet rates, but enough to keep the 
> bindings open. A no-op RTP payload format has been proposed for this; 
> comfort noise would also do.
>

Yes.

> are defined as UA capabilities and characteristics.

But other callee capabilities change during a call as well.  For 
example, the SIP conferencing framework describes adding the ;isfocus 
parameter dynamically.

> This is neither, its more like a state for a media stream, perhaps 
> even closer to an indication of usage of a particular codec. Indeed, 
> it would seem to me to be possible to be 'on hold' for some media 
> streams and not others (for example, I still receive your video but 
> not your audio), which would make this hard to do as a callee 
> capabilitiy parameter. Indeed, my "interactivity" would be hard to 
> define in such a case.

I disagree.  The definition I used for the interactivity parameter 
would effectively require all the interesting media in a session to be 
inactive in the hold case to qualify as positively "non-interactive".  
The UA gets to decide what constitutes "interesting".  The key benefit 
here in the context of the dialog package and conferencing is that the 
UA gets to assert its intent explicitly. We don't descend the slippery 
slope of individual subscribers of the dialog package subscribing to 
session descriptions (that they might not be authorized to see) and 
implicitly interpreting the results.

I summary, I believe that the approach I described technically works, 
causes no harm, has a number of benefits, and is consistent with other 
callee caps parameters (especially ;isfocus).

thanks,
-rohan

>> interactivity parameter indicates if a device is capable of 
>> responding to media received during a session in an interactive 
>> manner and if necessary terminating a session in which the UA is no 
>> longer interested in participating.
>> For example:
>> - If you are in a session with a human user who just put you "on 
>> hold", your peer is non-interactive.
>> - If you are in a active session with a human call center agent in 
>> most call centers, your peer is interactive.
>> because the automata parameter is not set; the automata/human status 
>> is unknown.]
>> positive knowledge that a peer is non-interactive has a more 
>> immediate effect than positive knowledge that a peer in interactive)
>> Implementations could use the non-interactive parameter on a phone or 
>> a "parking lot" application as a way to indicate that a shared line 
>> is "holding" or "parked".
>> conference, the interactivity status of the participants.  For 
>> example, if the only participants in a conference are 
>> non-interactive, an adhoc conference is unlikely to be especially 
>> interesting (ex: a recording bot and a human who placed the 
>> conference on-hold).
>> I believe this satisfies all the requirements for indicating if a 
>> user is on hold, but captures a more fundamental and generic