Subject: [Sipping] proposed enhancement to dialog package

From: Rohan Mahy <[email-masked]>
Date: Tue, 3 Jun 2003 14:18:25 -0700

Hi,

There have been many requests for the dialog package to express the 
concept of hold. The problem is that nobody had an especially good 
definition of what "on-hold" meant.  Some suggested that all media 
streams being inactive implied that you are "held", but this doesn't 
work for a service such as music-on-hold.

I believe that folks actually want a slightly different concept--that 
the semantics we want instead are already described in the call control 
framework:

> Participants may also be active or passive. Active participants are 
> expected to be intelligent enough to leave a conversation space when 
> they no longer desire to participate. (An attentive human participant 
> is obviously active.) Some robotic participants (such as a voice 
> messaging system, an instant messaging agent, or a voice dialog 
> system) may be active participants if they can leave the conversation 
> space when there is no human interaction. Other robots (for example 
> our tone generating robot from the previous example) are passive 
> participants. A human participant "on-hold" is passive.

I think we should add a new attribute to the dialog package that 
expresses this property. My proposal is to express this property only 
for the local side of each dialog by adding an attribute to the state 
tag in the dialog-info notification body.  The example below includes a 
proposed (optional) participation attribute in the state tag.

    <?xml version="1.0"?>
    <dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info"
                 version="3"
                 state="partial"
                 entity="sip:[email-masked]">
      <dialog id="as7d900as8" call-id="[email-masked]"
              local-tag="123" remote-tag="789" direction="initiator">
        <state participation="active" event="2xx">confirmed</state>
      </dialog>
    </dialog-info>

Participation status could change during a session without otherwise 
changing the state of the call.

    <?xml version="1.0"?>
    <dialog-info xmlns="urn:ietf:params:xml:ns:dialog-info"
                 version="4"
                 state="partial"
                 entity="sip:[email-masked]">
      <dialog id="as7d900as8" call-id="[email-masked]"
              local-tag="123" remote-tag="789" direction="initiator">
        <state participation="passive">confirmed</state>
      </dialog>
    </dialog-info>

this proposal would of course require a small addition to the XML 
schema to support the new attribute:

<xs:attribute name="participation" use="optional">
<xs:simpleType>
   <xs:restriction base="xs:string">
   <xs:enumeration value="active"/>
   <xs:enumeration value="passive"/>
   </xs:restriction>
</xs:simpleType>
</xs:attribute>

comments welcome.  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: Szelényi Csaba <[email-masked]>
Date: Wed, 4 Jun 2003 08:59:38 +0200

Hi,

 | 
 | There have been many requests for the dialog package to express the 
 | concept of hold. The problem is that nobody had an especially good 
 | definition of what "on-hold" meant.  Some suggested that all media 
 | streams being inactive implied that you are "held", but this doesn't 
 | work for a service such as music-on-hold.
.....
 | 
 | I think we should add a new attribute to the dialog package that 
 | expresses this property. My proposal is to express this 
 | property only 
 | for the local side of each dialog by adding an attribute to 
 | the state 
 | tag in the dialog-info notification body.  The example below 

IMHO the 'hold' and 'music-on-hold' functionalities are the same: 'hold' delivers 'silence' type of music. So the hold functionality should be implemented in a way, that the streams transport something different then the recorded media: music or silence.

From philosophical view: the hold functions (simple hold and music-on-hold) should be additions to the normal protocol, i.e. this type of functions should be marked with extra header (the two types with one, the name could be 'hold'), and the normal behavior should not be marked with anything. (This way also the earlier implementations could work further.) 

Your suggestion has a philosophy like there were two types of operations: normal and hold. I don't think this is the philosophy of hold functionalities in traditional telephony.

Csaba

---

From: "Rosen, Brian" <[email-masked]>
Date: Thu, 12 Jun 2003 09:15:30 -0400

May I add some interesting observational data?
We now have about a year experience with sip videophones that
implement hold.  When you are on hold, you see a gray screen that
has text indicating the other party put you on hold.  We deliver
silence on the audio channel.

We have lots and lots of feature requests from users.  No one has
ever asked for audio on hold.  The visual information is sufficient.

I suspect that you don't need to be entertained, or pitched.  You need
to know what is happening.  If your UA tells you you are on hold,
then audio when you are on hold may not be important.

One caveat; almost everyone uses our videophone handsfree.  If you are
holding a handset to your ear, your desire for hold audio may be
greater.

Brian

> -----Original Message-----
> From: Jason Arnold [mailto:[email-masked]]
> Sent: Wednesday, June 11, 2003 7:21 PM
> To: Rohan Mahy; Sean Olson
> Cc: Drage, Keith (Keith); 'Jonathan Rosenberg'; 
> [email-masked];
> [email-masked]
> Subject: RE: [Sipping] proposed enhancement to dialog package
> 
> 
> I agree to an extent.
> 
> If the hold presents "dead air", most people will feel lost 
> with out some
> indication that they are on hold.  It would seem that people 
> require the
> assurance that the receiving party has not terminated their 
> call.  It could
> be assumed that if the hold period is for an extended period 
> of time, only
> presenting silence to the calling party, people may think 
> they have been
> accidentally "disconnected" and terminate their call.
> 
> It is important to supply a media stream (even irritating 
> propaganda) during
> the hold session.  Non-Conformity to current expectations of 
> people while on
> hold would seem illogical.
> 
> Thanks,
> 
> Jason
> 
> On Wednesday, June 11, 2003, at 09:40 AM, Sean Olson wrote:
> 
> > This is an interesting discussion in an almost
> > academic sense, but it really does not address the
> > reality of the very simple service that is being
> > described here.
> >
> > "hold", "passive", whatever else you want to call it
> > means not sending/receiving media.
> 
> I disagree.
> 
> If you call someone on the average PBX or Key System, and ask them to
> put you on hold, you will typically still receive media  
> (music, tones,
> irritating announcements).  Likewise, if you call a call center or a
> big store, you are likely to wait "on hold" with some type of
> propaganda, music, or recorded message claiming that you are 
> important.
> 
> Clearly the user experience of the user-visible feature "Hold" is that
> hold does not typically equate to "no media".
> 
> I believe that from a feature perspective the existence or presence of
> no media being sent/received is irrelevant.  It does not affect my
> perception that I am on hold, nor does it affect the perception of my
> peer if I am on hold or not, since I can receive or not receive media
> and still know that I am on hold.
> 
> My assertion is that what users really want to know is if the 
> other end
> is actively participating.  Do they care if I am still around?  Is
> there the potential for interaction between me and my peer?
> 
> With this concept, I can build useful features that users can relate
> to.  For example,  I would like "passive" participants (participants
> that cannot interact with me, like inane robots sending me 
> Musak) to be
> automatically muted in my conference.
> 
> I would like to express this property. If the name "passive" is too
> confusing, then feel free to suggest other terms.   "interactivity"
> EQUAL ( "yes" / "no" ) ?
> 
> thanks,
> -rohan
> 
> 
> > We've all
> > experienced this. And, yes, this can be independent of
> > the ability to do SIP signaling.
> >
> > I think we are focusing too much on signaling here and
> > not enough on the user experience that is being built.
> > And I certainly don't want a history lesson in ISDN
> > signaling ;-)
> >
> >
> > --- "Drage, Keith (Keith)" <[email-masked]> wrote:
> >> See below
> >>
> >> regards
> >>
> >> Keith
> >>
> >> Keith Drage
> >> Lucent Technologies
> >> Tel: +44 1793 776249
> >> Email: [email-masked]
> >>
> >>> -----Original Message-----
> >>> From: Rohan Mahy [mailto:[email-masked]]
> >>> Sent: 10 June 2003 16:25
> >>> To: Drage, Keith (Keith)
> >>> Cc: 'Jonathan Rosenberg'; [email-masked];
> >> [email-masked]'
> >>> Subject: Re: [Sipping] proposed enhancement to
> >> dialog package
> >>>
> >>>
> >>> Hi Keith,
> >>>
> >>> Hold as a UI concept significantly predated the
> >> development of ISDN.
> >>
> >> Agreed, and my initial message identified in that
> >> case (analogue PSTN terminals) that Hold was
> >> originally to recall the register (and there was a
> >> manual board equivalent as well) to allow access
> >> resources to be used for signalling, as a result of
> >> that signalling, the access resources might be used
> >> for communication with another party, and only as a
> >> by product of that did it necessarily result in loss
> >> of communication path with the other party.
> >>
> >>> In any case, an ISDN user (Alice) who requests an
> >> ISDN hold
> >>> is still a
> >>> passive participant by my definition.  When
> >> Alice's call is connected
> >>> to a conference server and all the active
> >> participants say "ok, we're
> >>> leaving now, good bye", Alice is not active enough
> >> to be able to hang
> >>> up.
> >>
> >> Assuming your last statement still refers to an ISDN
> >> user, then I can think of nothing in the above
> >> scenario that prevents Alice sending a DISCONNECT,
> >> and receiving a RELEASE back. Can you clarify. The
> >> DSS1 basic call state machine is totally independent
> >> of any subsidiary state machine relating to
> >> hold/retrieve.
> >>
> >> If you are referring to hanging up the conference
> >> bridge resources, then this is dependent on the
> >> concept of ownership, which varies based on the
> >> conference service provided, and also between public
> >> and private networks.
> >>
> >> As a result, I think I am now confused about what
> >> you actually mean by passive, can you elaborate
> >> further.
> >>
> >>
> >>>
> >>> I agree that whatever we do, we need to describe
> >> the semantics very
> >>> crisply.
> >>>
> >>> thanks,
> >>> -rohan
> >>>
> >>>
> >>> On Tuesday, June 10, 2003, at 04:47 AM, Drage,
> >> Keith (Keith) wrote:
> >>>
> >>>> I fail to see how thw property you are proposing
> >> correlates in some
> >>>> way to any concept of hold. I agree that "hold"
> >> has many meanings,
> >>>> based on which type of signalling you are using.
> >>>>
> >>>> To clarify, the prime function of hold in the
> >> PSTN was never to
> >>>> interrupt the communication, that was a side
> >> effect of grabbing the
> >>>> access resources to signal to another party.
> >> Thus for ISDN, hold
> >>>> therefore was only a removal of access resources
> >> (the
> >>> bearer) so that
> >>>> that bearer could be reused for another call;
> >> again the side effect
> >>>> was to interrupt the communication. The sole
> >> function of
> >>> hold for SIP
> >>>> is to interrupt the communication.
> >>>>
> >>>> Certainly, if an ISDN user places another user
> >> on hold, I
> >>> would regard
> >>>> neither user as "passive" as you seem to be
> >> defining here.
> >>>>
> >>>> If we are going to do this, can we make sure we
> >> define the
> >>> semantics
> >>>> correctly. Otherwise we will surely create
> >> confusion,
> >>> particularly if
> >>>> people try and equate this concept with that of
> >> hold, and in
> >>>> particular with the PSTN concept.
> >>>>
> >>>> regards
> >>>>
> >>>> Keith
> >>>>
> >>>>
> >>>> Keith Drage
> >>>> Lucent Technologies
> >>>> Tel: +44 1793 776249
> >>>> Email: [email-masked]
> >>>>
> >>>>> -----Original Message-----
> >>>>> From: Rohan Mahy [mailto:[email-masked]]
> >>>>> Sent: 03 June 2003 22:18
> >>>>> To: 'Jonathan Rosenberg'
> >>>>> Cc: [email-masked]; [email-masked];
> >> [email-masked]'
> >>>>> Subject: [Sipping] proposed enhancement to
> >> dialog package
> >>>>>
> >>>>>
> >>>>> Hi,
> >>>>>
> >>>>> streams being inactive implied that you are
> >> "held", but
> >>> this doesn't
> >>>>> I believe that folks actually want a slightly
> >> different
> >>> concept--that
> >>>>> the semantics we want instead are already
> >> described in the
> >>>>> call control
> >>>>> framework:
> >>>>>
> >>>>>> Participants may also be active or passive.
> >> Active
> >>> participants are
> >>>>>> expected to be intelligent enough to leave a
> >> conversation
> >>>>> space when
> >>>>>> they no longer desire to participate. (An
> >> attentive human
> >>>>> participant
> >>>>>> system) may be active participants if they can
> >> leave the
> >>>>> conversation
> >>>>>> space when there is no human interaction.
> >> Other robots
> >>> (for example
> >>>>> expresses this property. My proposal is to
> >> express this
> >>> property only
> >>>>> for the local side of each dialog by adding an
> >> attribute
> >>> to the state
> >>>>> tag in the dialog-info notification body.  The
> >> example below
> >>>>> includes a
> >>>>>     <dialog-info
> >> xmlns="urn:ietf:params:xml:ns:dialog-info"
> >>>>>                  version="3"
> >>>>>                  state="partial"
> > === message truncated ===
> >
> >
> > __________________________________
> > Do you Yahoo!?
> > Yahoo! Calendar - Free online calendar with sync to Outlook(TM).
> > http://calendar.yahoo.com
>

---

From: [email-masked]
Date: Thu, 12 Jun 2003 17:30:59 +0300

Your desire to hold audio may also be greater when you have to pay for audio packets being sent. It might be more interesting for the sender to hold the audio that for the receiver.

Hisham

> From: ext Rosen, Brian [mailto:[email-masked]]
> Sent: Thursday, June 12, 2003 4:16 PM
> To: 'Jason Arnold'; Rohan Mahy; Sean Olson

---

From: "Drage, Keith (Keith)" <[email-masked]>
Date: Sat, 14 Jun 2003 21:28:09 +0100

It seems to me that Michael has managed to put into the words the thoughts I was trying to express in my previous mail.

The only reason we were talking about hold is that that is what Rohan used to describe it. From the further text I have seen so far, I am coming to the conclusion that what is desired has absolutely nothing whatsoever to do with hold at all, under whatever definition is being used.

I am also coming to the conclusion that the state that is being represented is buried somewhere in the application above the SIP protocol entity, rather than in the SIP protocol entity itself. Which leads me to the question of whether the dialog state package (which represents SIP entity state) is the appropriate place to put it.

(Or do we put everything we might want to say about the state of the end user as an extension to the dialog state package?)

regards

Keith Drage

-----Original Message-----
From: Michael Hammer [mailto:[email-masked]]
Sent: 12 June 2003 15:47
To: Sean Olson
Cc: Drage, Keith (Keith); 'Rohan Mahy'; 'Jonathan Rosenberg'; [email-masked]; [email-masked]'
Subject: RE: [Sipping] proposed enhancement to dialog package

Sean,

At 09:40 AM 6/11/2003 -0700, Sean Olson wrote:

You mean that the active call/conference is not sending/receiving media to the party on hold, not that the held party was not receiving media.

I don't understand the need for the term such as "passive".  What is wrong with the term "hold"?  If I am listening to a call, but not saying anything, I would consider myself passive.  So can I conclude that you are after something that is not on hold, but not entirely responsive to the call?

So what is the characteristic you are looking for?

Ability to respond to signaling?  It would appear that both parties on hold and automata could respond to such requests, i.e. a BYE.

Ability to respond to media?  I suppose this means a Turing machine equivalent.  That could mean both human listeners and perhaps IVR systems.  (Not looking for fool-proof human equivalent.)

So, are you looking for a term that describes a party that is connected to the call, receiving media, but won't react to it?

I think I'm missing the driving motivation here, but the above is what I am gleaning from the conversation thus far.

Mike

We've all

---

From: "Rosen, Brian" <[email-masked]>
Date: Thu, 19 Jun 2003 10:15:22 -0400

Please also make sure that we don't conflate "hold" with "mute".  
They are different.  To make it more interesting, we discovered 
that users insisted that video mute be two way (you can't see me 
if I can't see you).  The difference between hold and two
way mute is that hold really does make the call inactive, 
while mute does not.  Users expectations for what they can do, 
and what is presented to them, are quite different.

Brian
-----Original Message-----
From: Michael Hammer [mailto:[email-masked]]
Sent: Thursday, June 19, 2003 10:03 AM
To: Paul Kyzivat
Cc: [email-masked]; 'Rosen, Brian'; [email-masked];
[email-masked]; [email-masked]; [email-masked];
[email-masked]; [email-masked]; [email-masked]
Subject: Re: [Sipping] proposed enhancement to dialog package

Paul,

One subtle modification.  Extend the hold situation to a conference.  When a
user hits the hold button, does he put the conference (all the other
parties) on hold?  Not really.  They may still talk to each other.  He is
really putting himself on hold.  Shouldn't the actions that one party takes
be a reflection on himself only?  E.g., I put myself on hold from the
call/conference.  I am indicating that I am not attending to media, etc.

Mike

At 02:57 PM 6/18/2003 -0400, Paul Kyzivat wrote:

Sean Olson wrote:

For these different experiences at the UA, do you think you need different
indications in the dialog package?
Is "passive" enough to cover the variety of possibilities here? (My vote is
yes)

There are different possibilities that ought to be reflected uniquely.
Consider a call from A to B:

- A may be attending to the media from B, and visa versa.
- A is ignoring the media stream from B, and either
  sending nothing, sending MoH, progaganda, etc.
  Meanwhile B is attending to the media stream from A,
  waiting for A to begin attending again. Typically B
  is transmitting media, for no particular reason.
- A is ignoring the media stream from B and visa versa.
  Each may or may not be sending junk to the other.
- there are a bunch of other permutations, not commonly used.

From A's perspective these correspond to a=sendrecv, a=sendonly, a=inactive
in the SDP it has provided to B. The 2nd and 3rd both correspond in some
sense to HOLD.

We don't have great terminology for this. If A pushes the HOLD button on his
phone, then he will say he as put the call on hold and B will say he has
been put on hold. You put someone on hold when you want to cease attending
to the call. If you are put on hold you generally have a social obligation
to continue attending, awaiting the return of the other party.

My first thought was simply to use the sendrecv/sendonly/recvonly/inactive
indications for this purpose. The advantage is that they are coupled to
signaling and so are easily accessible. But they lack something, because
they don't directly say whether a received stream is being attended to.
Unfortunately that requires information from the application above the
signaling, and possibly from the actual user.

        Paul

-----Original Message-----
From: Rosen, Brian [mailto:[email-masked]] Sent: Thursday, June 12,
2003 8:05 AM
To: [email-masked]'; [email-masked]; [email-masked];
[email-masked]
Cc: [email-masked]; [email-masked]; [email-masked];
[email-masked]
Subject: RE: [Sipping] proposed enhancement to dialog package

I've always thought that "music on hold" should be local i.e. my choice of
music for me to listen to, not your choice of music for me to hear.
Eliminates promotional material also :)
Brian

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Thursday, June 12, 2003 10:31 AM
To: [email-masked]; [email-masked]; [email-masked];
[email-masked]
Cc: [email-masked]; [email-masked]; [email-masked];
[email-masked]
Subject: RE: [Sipping] proposed enhancement to dialog package

Your desire to hold audio may also be greater when you have
to pay for audio packets being sent. It might be more interesting for the
sender to hold the audio that for the receiver.

Hisham

-----Original Message-----
From: ext Rosen, Brian [mailto:[email-masked]]
Sent: Thursday, June 12, 2003 4:16 PM
To: 'Jason Arnold'; Rohan Mahy; Sean Olson
Cc: Drage, Keith (Keith); 'Jonathan Rosenberg';
[email-masked];
[email-masked]

May I add some interesting observational data?
We now have about a year experience with sip videophones that implement
hold.  When you are on hold, you see a gray screen that has text indicating
the other party put you on hold.  We deliver silence on the audio channel.

We have lots and lots of feature requests from users.  No one has ever asked
for audio on hold.  The visual information is sufficient.

I suspect that you don't need to be entertained, or

pitched.  You need

to know what is happening.  If your UA tells you you are on hold, then audio
when you are on hold may not be important.

One caveat; almost everyone uses our videophone handsfree.

If you are

holding a handset to your ear, your desire for hold audio may be greater.

Brian

-----Original Message-----
From: Jason Arnold [mailto:[email-masked]]
Sent: Wednesday, June 11, 2003 7:21 PM
To: Rohan Mahy; Sean Olson
Cc: Drage, Keith (Keith); 'Jonathan Rosenberg';
[email-masked];
[email-masked]

I agree to an extent.

If the hold presents "dead air", most people will feel lost
with out some
indication that they are on hold.  It would seem that people require the
assurance that the receiving party has not terminated their call.  It could
be assumed that if the hold period is for an extended period of time, only
presenting silence to the calling party, people may think they have been
accidentally "disconnected" and terminate their call.

It is important to supply a media stream (even irritating
propaganda) during
the hold session.  Non-Conformity to current expectations of people while on
hold would seem illogical.

Thanks,

Jason

This is an interesting discussion in an almost
academic sense, but it really does not address the reality of the very
simple service that is being described here.

"hold", "passive", whatever else you want to call it means not
sending/receiving media.

I disagree.

If you call someone on the average PBX or Key System, and

ask them to

put you on hold, you will typically still receive media
(music, tones,
irritating announcements).  Likewise, if you call a call 
center or a

big store, you are likely to wait "on hold" with some type of propaganda,
music, or recorded message claiming that you are important.

Clearly the user experience of the user-visible feature

"Hold" is that

I believe that from a feature perspective the existence or

presence of

no media being sent/received is irrelevant.  It does not affect my
perception that I am on hold, nor does it affect the

perception of my

peer if I am on hold or not, since I can receive or not

receive media

With this concept, I can build useful features that users
can relate

to.  For example,  I would like "passive" participants
(participants

I would like to express this property. If the name
"passive" is too

confusing, then feel free to suggest other terms.   
"interactivity"

EQUAL ( "yes" / "no" ) ?

thanks,
-rohan

We've all
experienced this. And, yes, this can be independent of the ability to do SIP
signaling.

I think we are focusing too much on signaling here and not enough on the
user experience that is being built. And I certainly don't want a history
lesson in ISDN signaling ;-)

See below

regards

Keith

Keith Drage
Lucent Technologies
Tel: +44 1793 776249
Email: [email-masked]

-----Original Message-----
From: Rohan Mahy [mailto:[email-masked]]
Sent: 10 June 2003 16:25
To: Drage, Keith (Keith)
Cc: 'Jonathan Rosenberg'; [email-masked];

[email-masked]'

dialog package

Hi Keith,

development of ISDN.

Agreed, and my initial message identified in that
case (analogue PSTN terminals) that Hold was originally to recall the
register (and there was a manual board equivalent as well) to allow access
resources to be used for signalling, as a result of that signalling, the
access resources might be used
for communication with another party, and only as a
by product of that did it necessarily result in loss
of communication path with the other party.

ISDN hold

is still a

to be able to hang

up.

Assuming your last statement still refers to an ISDN user, then I can think
of nothing in the above scenario that prevents Alice sending a DISCONNECT,
and receiving a RELEASE back. Can you clarify. The DSS1 basic call state
machine is totally independent of any subsidiary state machine relating to
hold/retrieve.

If you are referring to hanging up the conference bridge resources, then
this is dependent on the concept of ownership, which varies based on the
conference service provided, and also between public and private networks.

As a result, I think I am now confused about what
you actually mean by passive, can you elaborate further.

the semantics very

crisply.

thanks,
-rohan

Keith (Keith) wrote:

bearer) so that

hold for SIP

would regard

semantics

particularly if

regards

Keith

Keith Drage
Lucent Technologies
Tel: +44 1793 776249
Email: [email-masked]

-----Original Message-----
From: Rohan Mahy [mailto:[email-masked]]
Sent: 03 June 2003 22:18
To: 'Jonathan Rosenberg'
Cc: [email-masked]; [email-masked];
[email-masked]'

Hi,

There have been many requests for the dialog
package to express the

concept of hold. The problem is that nobody had
an especially good

definition of what "on-hold" meant.  Some
suggested that all media

this doesn't

concept--that

call control
framework:

participants are

space when

participant

is obviously active.) Some robotic
participants (such as a voice

messaging system, an instant messaging agent,
or a voice dialog

conversation

(for example

our tone generating robot from the previous
example) are passive

participants. A human participant "on-hold" is
passive.

I think we should add a new attribute to the
dialog package that

property only

to the state

includes a
proposed (optional) participation attribute in
the state tag.

   <?xml version="1.0"?>
   <dialog-info

                version="3"
                state="partial"

_______________________________________________
Sipping mailing list  
https://www1.ietf.org/mailman/listinfo/sipping