Subject: RE: [Sipping] proposed enhancement to dialog package

From: "Rosen, Brian" <[email-masked]>
Date: Thu, 12 Jun 2003 11:05:01 -0400

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]
> > Subject: RE: [Sipping] proposed enhancement to dialog package
> > 
> > 
> > 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,
> > > >>>>>
> > > >>>>> 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]">
> > > >>
> > > > === message truncated ===
> > > >
> > > >
> > > > __________________________________
> > > > Do you Yahoo!?
> > > > Yahoo! Calendar - Free online calendar with sync to Outlook(TM).
> > > > http://calendar.yahoo.com
> > > 
> > > _______________________________________________
> > > 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
> > 
> > _______________________________________________
> > 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
> > 
> _______________________________________________
> 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
> 
_______________________________________________
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: "Sean Olson" <[email-masked]>
Date: Thu, 12 Jun 2003 08:56:47 -0700

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)

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

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.

Brian

> > > > 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.
> > > 
> > > > 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 ;-)
> > > >
> > > >
> > > >> 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
> > > >> 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.
> > > >>
> > > >> you actually mean by passive, can you elaborate further.
> > > >>
> > > >>
> > > >>>

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 18 Jun 2003 14:57:42 -0400

> Is "passive" enough to cover the variety of possibilities here? (My vote is

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

---

From: Michael Hammer <[email-masked]>
Date: Thu, 19 Jun 2003 10:02:37 -0400

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:
>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
>
>
>>From: Rosen, Brian [mailto:[email-masked]] Sent: Thursday, June 
>>12, 2003 8:05 AM
>>>to pay for audio packets being sent. It might be more interesting for 
>>>the sender to hold the audio that for the receiver.
>>>
>>>Hisham
>>>
>>>
>>>>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.
>>>>
>>>>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.
>>>>
>>>>holding a handset to your ear, your desire for hold audio may be greater.
>>>>
>>>>Brian
>>>>
>>>>
>>>>>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
>>>>>the hold session.  Non-Conformity to current expectations of people 
>>>>>while on
>>>>>>academic sense, but it really does not address the reality of the 
>>>>>>very simple service that is being described here.
>>>>>>
>>>>>propaganda, music, or recorded message claiming that you are important.
>>>>>
>>>>>>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 ;-)
>>>>>>
>>>>>>
>>>>>>>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 
>>>>>>>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.
>>>>>>>

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 19 Jun 2003 10:59:45 -0400

Michael Hammer wrote:
> 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.

I don't think anything I said is inconsistent with the point you are 
making. I suppose the following is the part you are concerned with:

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

Perhaps that should be elaborated to say:

... and B will say he has been put on hold by A.
                                            ^^^^

This is something that is done by A. B *is* affected, but it doesn't 
prevent B from doing other things.

As this relates to Rohan's proposal, I think what I have described as 
attending to media is similar to what Rohan is calling participation. 
The primary difference seems to be that Rohan is applying this property 
to the dialog as a whole rather than to a media stream.

It is convenient to have this as a property of the dialog. The question 
is whether the typical UA knows this. For UAs that support only a single 
medium the distinction is irrelevant. There isn't nearly as much 
experience with multimedia UAs, and I suspect there hasn't been time for 
management of such devices to reach defacto standardization.

The two choices seem to be to report this property on a per-media-stream 
basis, or else to leave it to the UA to figure out on a per-dialog 
basis. (One possibility would be to consider the UA to be participating 
if at least one of its media streams is attended.)

	Paul

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

>> 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.
>>
>>> From: Rosen, Brian [mailto:[email-masked]] Sent: Thursday, 
>>> June 12, 2003 8:05 AM
>>>> Cc: [email-masked]; [email-masked]; 
>>>> [email-masked]; [email-masked]
>>>> to pay for audio packets being sent. It might be more interesting 
>>>> for the sender to hold the audio that for the receiver.
>>>>
>>>> Hisham
>>>>
>>>>
>>>>>> assurance that the receiving party has not terminated their call.  
>>>>>> It could
>>>>>>> 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 ;-)
>>>>>>>
>>>>>>>
>>>>>>>> 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 
>>>>>>> http://calendar.yahoo.com <http://calendar.yahoo.com/>
>>>>>>
>>>>>>