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

From: "Drage, Keith (Keith)" <[email-masked]>
Date: Wed, 11 Jun 2003 13:04:48 +0100

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]">
> >>       <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
>>
> _______________________________________________
> 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: Wed, 11 Jun 2003 09:40:40 -0700 (PDT)

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. 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:
> 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.
>  
> 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.
> 
> 
> > 
> > >>     <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
_______________________________________________
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: Rohan Mahy <[email-masked]>
Date: Wed, 11 Jun 2003 10:56:20 -0700

On Wednesday, June 11, 2003, at 09:40 AM, Sean Olson wrote:

> 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

---

From: "Jason Arnold" <[email-masked]>
Date: Wed, 11 Jun 2003 16:20:56 -0700

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

I disagree.

thanks,
-rohan

---

From: Sean Olson <[email-masked]>
Date: Wed, 11 Jun 2003 17:14:31 -0700 (PDT)

I don't get it. What we are talking about is an
INDICATION of what is happening on a dialog. I
certaingly am not proposing CONTROL of what happens on
that dialog. i.e. I don't care whether you play hold
music or not. The important thing is that I know one
of the parties in a dialog is "on hold". From my
perspective, "on hold" means that the two parties on
either end of the dialog are not actively engaged in
communication. This is what I mean by "no media" (no
relevant media being exchanged). From this point of
view, "passive" sounds perfectly reasonable to me. And
it does really relate to the availability of that
party to potentially take part in another dialog ---
but then we start splitting hairs over the best way to
reproduce the PSTN experience.

--- Jason Arnold <[email-masked]> wrote:
> >>> Cc: 'Jonathan Rosenberg';
> [email-masked];
> >> [email-masked]'
> >>> In any case, an ISDN user (Alice) who requests
> an
> >> ISDN hold
> >>> is still a
> >>> leaving now, good bye", Alice is not active
> enough
> >> to be able to hang
> >>> up.
> >>
> >>>> I fail to see how thw property you are
> proposing
> >> correlates in some

---

From: Rohan Mahy <[email-masked]>
Date: Wed, 11 Jun 2003 17:23:04 -0700

On Wednesday, June 11, 2003, at 05:14 PM, Sean Olson wrote:

> INDICATION of what is happening on a dialog.

What I am describing is an indication of a PROPERTY of a dialog or the 
associated participant.

> I certaingly am not proposing CONTROL of what happens on
> communication.

exactly.

> This is what I mean by "no media" (no
> relevant media being exchanged).

well, the difference between no media and no relevant media is a 
completely different kettle of fish.

> From this point of

I don't think we need to reproduce the PSTN definition of hold, or the 
existing experience of being on a conference call listening to 
someone's Musak.  ;-)

thx,
-r

---

From: "James M. Polk" <[email-masked]>
Date: Wed, 11 Jun 2003 19:55:04 -0500

At 04:20 PM 6/11/2003 -0700, Jason Arnold wrote:

>the hold session.

Is this asking that media be mandatory when a UA is placed on hold? There 
are many times where there is no propaganda playing while someone is on 
hold (though I wish was more often the case). Creating a mechanism that 
must satisfy "media always streaming" will break when there isn't media 
(which will be during some sessions), especially when media isn't necessary 
or wanted (for whatever reason).

Might I suggest some form of a "hold keep-alive" indicator (periodically) 
sent to the UA that was put on hold so that UI experience demonstrates this 
session wasn't disconnected in times that there is no media.

>Non-Conformity to current expectations of people while on

cheers,
James

                                *******************
                    The answer is "42", what's the question?

---

From: Jason Arnold <[email-masked]>
Date: Wed, 11 Jun 2003 22:50:40 -0700

>It is important to supply a media stream (even irritating propaganda)
during

Is this asking that media be mandatory when a UA is placed on hold?
<No, it would not make sense that media be mandatory.>

Might I suggest some form of a "hold keep-alive" indicator (periodically)
sent to the UA that was put on hold so that UI experience demonstrates this
session wasn't disconnected in times that there is no media.
< In some cases of PSTN hold, there are indicators assuring UA of continued
call connection.  A simple stutter sound (beep, beep) eases a typical user
that they are still connected.
Jason

cheers,
James

                                *******************

---

From: Michael Hammer <[email-masked]>
Date: Thu, 12 Jun 2003 10:46:57 -0400

Sean,

>means not sending/receiving media.

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