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

From: "Drage, Keith (Keith)" <[email-masked]>
Date: Tue, 10 Jun 2003 12:47:49 +0100

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

---

From: Rohan Mahy <[email-masked]>
Date: Tue, 10 Jun 2003 08:25:05 -0700

Hi Keith,

Hold as a UI concept significantly predated the development of ISDN.  
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.

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