Re: [splices] INVOKE Actions Scope

"Shekh-Yusef, Rifaat (Rifaat)" <rifatyu@avaya.com> Wed, 13 July 2011 15:13 UTC

Return-Path: <rifatyu@avaya.com>
X-Original-To: splices@ietfa.amsl.com
Delivered-To: splices@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2AC9E21F876F for <splices@ietfa.amsl.com>; Wed, 13 Jul 2011 08:13:16 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.229
X-Spam-Level:
X-Spam-Status: No, score=-3.229 tagged_above=-999 required=5 tests=[AWL=0.370, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id EziSUbFLU9id for <splices@ietfa.amsl.com>; Wed, 13 Jul 2011 08:13:11 -0700 (PDT)
Received: from de307622-de-outbound.net.avaya.com (de307622-de-outbound.net.avaya.com [198.152.71.100]) by ietfa.amsl.com (Postfix) with ESMTP id A40D311E80F8 for <splices@ietf.org>; Wed, 13 Jul 2011 08:13:07 -0700 (PDT)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AvEAAH21HU6HCzI1/2dsb2JhbABTl36PPnexHQKbVoVbXwSXfYtM
X-IronPort-AV: E=Sophos;i="4.65,525,1304308800"; d="scan'208";a="256387340"
Received: from unknown (HELO p-us1-erheast.us1.avaya.com) ([135.11.50.53]) by de307622-de-outbound.net.avaya.com with ESMTP; 13 Jul 2011 11:12:46 -0400
Received: from dc-us1hcex1.us1.avaya.com (HELO DC-US1HCEX1.global.avaya.com) ([135.11.52.20]) by p-us1-erheast-out.us1.avaya.com with ESMTP; 13 Jul 2011 11:05:43 -0400
Received: from DC-US1MBEX4.global.avaya.com ([169.254.2.172]) by DC-US1HCEX1.global.avaya.com ([2002:870b:3414::870b:3414]) with mapi; Wed, 13 Jul 2011 11:12:45 -0400
From: "Shekh-Yusef, Rifaat (Rifaat)" <rifatyu@avaya.com>
To: Cullen Jennings <fluffy@cisco.com>, "splices@ietf.org" <splices@ietf.org>
Date: Wed, 13 Jul 2011 11:12:43 -0400
Thread-Topic: [splices] INVOKE Actions Scope
Thread-Index: Acww/2lIInU16D1MQoqzcynyzVKFbgQbxviA
Message-ID: <6369CB70BFD88942B9705AC1E639A33822CF6DED91@DC-US1MBEX4.global.avaya.com>
References: <4CA2C4386DB56F4589D436E1C3C86F752230509C3B@DC-US1MBEX4.global.avaya.com> <AD0C7C55-811C-4932-AAAE-4F8780D30BE4@cisco.com>
In-Reply-To: <AD0C7C55-811C-4932-AAAE-4F8780D30BE4@cisco.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: en-US
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: Re: [splices] INVOKE Actions Scope
X-BeenThere: splices@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Loosely-coupled SIP Devices \(splices\) working group discussion list" <splices.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/splices>, <mailto:splices-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/splices>
List-Post: <mailto:splices@ietf.org>
List-Help: <mailto:splices-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/splices>, <mailto:splices-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 13 Jul 2011 15:13:16 -0000

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:fluffy@cisco.com]
> Sent: Wednesday, June 22, 2011 1:11 PM
> To: splices@ietf.org
> 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
> > splices@ietf.org
> > 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
>