Subject: Re: [splices] INVOKE Actions Scope

From: "Shekh-Yusef, Rifaat (Rifaat)" <[email-masked]>
Date: Wed, 13 Jul 2011 11:12:43 -0400

Hi,

The following is the authors attempt to clearly define the scope of the INVOKE actions.
We would appreciate any comments.

Regards,
 Rifaat

An action can manipulate the state of an INVITE-based dialog. The following are the only allowed actions:

  1) Initiate: 
     This action instructs the UA to send an INVITE with specific characteristics to a specific target.
     i.   Target: <AOR>
     ii.  Media: audio, video, or both
     iii. Direction: recvonly, sendonly, sendrecv

  2) Answer: 
     This action instructs the UA to answer a call by sending a 200 OK with specific characteristics
     i.  Media: audio, video, or both
     ii. Direction: recvonly, sendonly, sendrecv

  3) Join: 
     This action instructs the UA to join an existing dialog by sending an INVITE with Join header and with specific characteristics
     i.  Media: audio, video, or both
     ii. Direction: recvonly, sendonly, sendrecv

  4) Terminate: 
     This action instructs the UA to terminate a dialog of an outgoing call. 
     If the dialog is in an early state, then the UA must send a CANCEL request. 
     If the dialog is in an active state, then the UA must send a BYE request.

  5) Decline: 
     This action instructs the UA to decline an incoming call by sending a 603 response

  6) Send to VM: 
     This action instructs the UA to stop ringing and send the incoming call to the VM system by sending a 302 response.

  7) Hold/Unhold: 
     This action instructs the UA to hold/unhold a call by sending a re-INVITE with the characteristics of the new state of the session. 
     The action allows for hold/unhold of audio, video, or both.

  8) Conference: Add/Remove
     This action instructs the UA to create a local conference and add or remove parties as needed. 
     To add a party, the UA sends a REFER request to that party with the local focus. The UA can remove a party by sending a BYE request to that party.

> -----Original Message-----
> From: Cullen Jennings [mailto:[email-masked]]
> Sent: Wednesday, June 22, 2011 1:11 PM
> To: [email-masked]
> Cc: Shekh-Yusef, Rifaat (Rifaat)
> Subject: Re: [splices] INVOKE Actions Scope
> 
> 
> There are a few features that most PBX can do today there is no standardized
> way to use SIP to signal the changes to sip dialog state needed to implement
> these features.  I think we should pick an initial small set of features that
> are often used and supported and do theses - that was what I hoped this draft
> did. It proposes a few things, probably some need to be specified in more
> detail, perhaps there are a few more that people think should be added,
> perhaps a few proposed should be removed.
> 
> So my proposal for scope is just the scope we have in this draft which I would
> argue is a subset of the "An Action can manipulate a dialog or a multimedia
> session." I view all the action here as changing the SIP dialog state and what
> changes happen to the multimedia session being a side effect of that.
> 
> On Jun 18, 2011, at 6:37 , Shekh-Yusef, Rifaat (Rifaat) wrote:
> 
> > Hi,
> >
> > I would like to start a discussion that I hope would allow us to converge on
> an approriate scope for the first release of this draft.
> > The following is my first attempt at defining this scope:
> >
> > 1. An Action can manipulate a dialog or a multimedia session.
> > 2. An Action can manipulate one or more dialogs or sessions at the same
> time.
> > 3. An Action can manipulate the state of a physical "feature" of a device,
> e.g. transducer.
> > 4. An Action can invoke a well-defined telephony "feature" on the UA,
> e.g.hold.
> > 5. An Action cannot replace an existing SIP mechanism, e.g. offer/answer.
> > 6. An Action cannot dictate the UI behavior of the target UA.
> >
> > Any thoughts?
> >
> > Thanks,
> > Rifaat
> > _______________________________________________
> > splices mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/splices
> 
> 
> Cullen Jennings
> For corporate legal information go to:
> http://www.cisco.com/web/about/doing_business/legal/cri/index.html
>

---

From: Peter Musgrave <[email-masked]>
Date: Thu, 14 Jul 2011 13:52:07 -0400

Hi Rifaat,

This is a good start. I think there is an implicit set of assumptions about
some of these. In (4) there are conditions applied to what the UA does based
on it's dialog state - but this will need to be generalized to all states.

e.g. action Initiate sent to a UA which has decided on it's own to start a
call (or has received a call) does what? (Or, the flip - "only applies if UA
is IDLE, otherwise rejected") etc.

Also in the case of initiate a more general offer may be needed (i.e. 2nd
video line for presentation, multiple video lines for continuous presence
mult-streams etc. etc. )

Peter

On Wed, Jul 13, 2011 at 11:12 AM, Shekh-Yusef, Rifaat (Rifaat) <
[email-masked]> wrote:

>     This action instructs the UA to join an existing dialog by sending an
> INVITE with Join header and with specific characteristics
>     This action instructs the UA to stop ringing and send the incoming call
> to the VM system by sending a 302 response.
>
>  7) Hold/Unhold:
>     This action instructs the UA to hold/unhold a call by sending a
> re-INVITE with the characteristics of the new state of the session.
>     To add a party, the UA sends a REFER request to that party with the
> local focus. The UA can remove a party by sending a BYE request to that
> party.
>
>
>
>

---

From: "Worley, Dale R (Dale)" <[email-masked]>
Date: Fri, 15 Jul 2011 13:03:16 -0400

> From: Shekh-Yusef, Rifaat (Rifaat) [[email-masked]]
> 

There are probably two flavors of Initiate:  One where the INVOKE
specifies a dial string and one where it specifies a URI.

>   3) Join:
>      This action instructs the UA to join an existing dialog by
>      sending an INVITE with Join header and with specific
>      characteristics

I don't think this is a separate operation.
If the intention is to join *at a remote UA*, then this is just an Initiate
where the request-URI is "sip:foo@bar?Join=xyz".
If the intention is to initiate a new dialog, but have it joined *at
this UA* with an existing dialog, it is a form of the Conference
operation.

>      This action instructs the UA to decline an incoming call by

Please use a 4xx response!

See http://tools.ietf.org/id/draft-worley-6xx-considered-harmful-00.txt

>   6) Send to VM:
>      This action instructs the UA to stop ringing and send the
>      incoming call to the VM system by sending a 302 response.

This assumes that the phone knows the proper VM URI.  It also assumes
the user is configured so that the next destination of the call is a
voicemail system.

Aren't "Decline" and "Send to VM" related to the ACH proposals?

Dale

---

From: "Shekh-Yusef, Rifaat (Rifaat)" <[email-masked]>
Date: Sun, 17 Jul 2011 13:44:21 -0400

> From: Peter Musgrave [mailto:[email-masked]]
> Sent: Thursday, July 14, 2011 1:52 PM
> To: Shekh-Yusef, Rifaat (Rifaat)
> Cc: Cullen Jennings; [email-masked]
I would think that this would be a local policy and has nothing to do with the fact that the action was invoked locally or remotely.
For example, one device might force the user to first handle the incoming call before initiating an outgoing call, while another device might allow the user to ignore the incoming call and initiate an outgoing.

> video line for presentation, multiple video lines for continuous presence
Good point.

> Peter
> On Wed, Jul 13, 2011 at 11:12 AM, Shekh-Yusef, Rifaat (Rifaat)
> <[email-masked]> wrote:
> Hi,
> 
>     This action instructs the UA to hold/unhold a call by sending a re-INVITE
> with the characteristics of the new state of the session.
>     To add a party, the UA sends a REFER request to that party with the local
> focus. The UA can remove a party by sending a BYE request to that party.
> 
> 
> 
>

---

From: "Shekh-Yusef, Rifaat (Rifaat)" <[email-masked]>
Date: Sun, 17 Jul 2011 14:14:27 -0400

> From: Worley, Dale R (Dale)
> Sent: Friday, July 15, 2011 1:03 PM
> To: Shekh-Yusef, Rifaat (Rifaat); Cullen Jennings; [email-masked]
> Subject: RE: [splices] INVOKE Actions Scope
> 
> If the intention is to join *at a remote UA*, then this is just an 
> Initiate where the request-URI is "sip:foo@bar?Join=xyz".
What I had in mind for join is described in the following example:
http://www.ietf.org/mail-archive/web/splices/current/msg00049.html

> See 
> http://tools.ietf.org/id/draft-worley-6xx-considered-harmful-00.txt
> 
"A response of this type [6xx] not only rejects the call but also
   requires the termination of all attempts to route the call to
   alternative destinations "

If a telemarketer is calling me and I want to decline his call, then this is exactly what I want.
Why do you think that this is a bad thing to do?

> the user is configured so that the next destination of the call is a 
Yeah, I need to add some parameters here.

> Aren't "Decline" and "Send to VM" related to the ACH proposals?
ACH is to affect the proxy handling of these features, while this is for handling of these features on the phone.
Does this answer your comment?

---

From: "Worley, Dale R (Dale)" <[email-masked]>
Date: Sun, 17 Jul 2011 21:12:40 -0400

________________________________________
From: Shekh-Yusef, Rifaat (Rifaat)

If a telemarketer is calling me and I want to decline his call, then this is exactly what I want.
Why do you think that this is a bad thing to do?
________________________________________

If a telemarketer is calling, what you *really* want is response "1313 Make Caller's Head Explode".

But in the case where what you want to communicate is that *you* don't want
to handle the call.  As there may be forks upstream of your UA and your PBX,
all you can know is that there are no destinations *within your PBX* that should not
take the call.  It is impossible for you to know that there are *no* appropriate destinations
anywhere upstream, as you don't know what all the upstream forks are (absent History-Info).

In practice, the situation is even worse, as many phones have a "Decline Call" button that sends
a 603 response.  But if voicemail is implemented by the sensible means of having the VM system
be a lower-priority fork, the 603 prevents the call from going to voicemail.

Dale

---

From: "Worley, Dale R (Dale)" <[email-masked]>
Date: Sun, 17 Jul 2011 21:17:16 -0400

That makes sense, but I suggest you give it a different name than
just "join" to avoid confusion.

Dale