Re: [splices] INVOKE Actions Scope

"Shekh-Yusef, Rifaat (Rifaat)" <rifatyu@avaya.com> Sun, 17 July 2011 17:44 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 7304D21F85E1 for <splices@ietfa.amsl.com>; Sun, 17 Jul 2011 10:44:28 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.321
X-Spam-Level:
X-Spam-Status: No, score=-3.321 tagged_above=-999 required=5 tests=[AWL=0.278, 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 DbEsq8w3XZiM for <splices@ietfa.amsl.com>; Sun, 17 Jul 2011 10:44:27 -0700 (PDT)
Received: from co300216-co-outbound.net.avaya.com (co300216-co-outbound.net.avaya.com [198.152.13.100]) by ietfa.amsl.com (Postfix) with ESMTP id 5BFBD21F85B5 for <splices@ietf.org>; Sun, 17 Jul 2011 10:44:26 -0700 (PDT)
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AikBAD8fI07GmAcF/2dsb2JhbABSmC6DWYtrd4h8pn4Cmj+FXV8EhyWQX4RChxE
X-IronPort-AV: E=Sophos;i="4.67,218,1309752000"; d="scan'208";a="291213196"
Received: from unknown (HELO co300216-co-erhwest.avaya.com) ([198.152.7.5]) by co300216-co-outbound.net.avaya.com with ESMTP; 17 Jul 2011 13:44:24 -0400
Received: from dc-us1hcex1.us1.avaya.com (HELO DC-US1HCEX1.global.avaya.com) ([135.11.52.20]) by co300216-co-erhwest-out.avaya.com with ESMTP; 17 Jul 2011 13:42:34 -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; Sun, 17 Jul 2011 13:44:23 -0400
From: "Shekh-Yusef, Rifaat (Rifaat)" <rifatyu@avaya.com>
To: Peter Musgrave <musgravepj@gmail.com>
Date: Sun, 17 Jul 2011 13:44:21 -0400
Thread-Topic: [splices] INVOKE Actions Scope
Thread-Index: AcxCTsIZNX7Z9Z1aQ4OkJd/Vfv87sQCWPe/g
Message-ID: <6369CB70BFD88942B9705AC1E639A33822CF878BA3@DC-US1MBEX4.global.avaya.com>
References: <4CA2C4386DB56F4589D436E1C3C86F752230509C3B@DC-US1MBEX4.global.avaya.com> <AD0C7C55-811C-4932-AAAE-4F8780D30BE4@cisco.com> <6369CB70BFD88942B9705AC1E639A33822CF6DED91@DC-US1MBEX4.global.avaya.com> <CAJH01tYUk2mZpTb1EiaTc=B5YZ_=Sc3ggaq3Fubsi+DM3LP3YQ@mail.gmail.com>
In-Reply-To: <CAJH01tYUk2mZpTb1EiaTc=B5YZ_=Sc3ggaq3Fubsi+DM3LP3YQ@mail.gmail.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="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "splices@ietf.org" <splices@ietf.org>
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: Sun, 17 Jul 2011 17:44:28 -0000

> -----Original Message-----
> From: Peter Musgrave [mailto:musgravepj@gmail.com]
> Sent: Thursday, July 14, 2011 1:52 PM
> To: Shekh-Yusef, Rifaat (Rifaat)
> Cc: Cullen Jennings; splices@ietf.org
> Subject: Re: [splices] INVOKE Actions Scope
> 
> 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.
> 
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.


> 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. )
> 
Good point.

> Peter
> On Wed, Jul 13, 2011 at 11:12 AM, Shekh-Yusef, Rifaat (Rifaat)
> <rifatyu@avaya.com> wrote:
> 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
> >
> 
> _______________________________________________
> splices mailing list
> splices@ietf.org
> https://www.ietf.org/mailman/listinfo/splices