Re: [splices] INVOKE Actions Scope

Peter Musgrave <musgravepj@gmail.com> Thu, 14 July 2011 17:52 UTC

Return-Path: <musgravepj@gmail.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 9D84F11E80B2 for <splices@ietfa.amsl.com>; Thu, 14 Jul 2011 10:52:14 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.598
X-Spam-Level:
X-Spam-Status: No, score=-3.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, 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 gt4xIDvFOmrw for <splices@ietfa.amsl.com>; Thu, 14 Jul 2011 10:52:13 -0700 (PDT)
Received: from mail-fx0-f54.google.com (mail-fx0-f54.google.com [209.85.161.54]) by ietfa.amsl.com (Postfix) with ESMTP id 0F9A511E80B8 for <splices@ietf.org>; Thu, 14 Jul 2011 10:52:08 -0700 (PDT)
Received: by fxe4 with SMTP id 4so1644521fxe.27 for <splices@ietf.org>; Thu, 14 Jul 2011 10:52:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=+3PEXjN13hCDuOGY2yr0vMvtuaEhWauTTNSgkub00Pk=; b=PKg0CxV15igxgkxMPYr5NOYVJbRk3UAdvqBn1M9/BNoW0mtkekhNW0PmJEprZ16wZ2 CI3otPC9BrXnmC8sLnlP/jKwJG2KklAj+TMWBY5Sr7S2xqdw0RjIsBJ+DAGp4qQsmDz3 9IETj1eNQpM7lWVz/0djCuRNq9xvk9xcK0m+A=
MIME-Version: 1.0
Received: by 10.223.144.140 with SMTP id z12mr3871724fau.147.1310665928118; Thu, 14 Jul 2011 10:52:08 -0700 (PDT)
Received: by 10.223.103.71 with HTTP; Thu, 14 Jul 2011 10:52:07 -0700 (PDT)
In-Reply-To: <6369CB70BFD88942B9705AC1E639A33822CF6DED91@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>
Date: Thu, 14 Jul 2011 13:52:07 -0400
Message-ID: <CAJH01tYUk2mZpTb1EiaTc=B5YZ_=Sc3ggaq3Fubsi+DM3LP3YQ@mail.gmail.com>
From: Peter Musgrave <musgravepj@gmail.com>
To: "Shekh-Yusef, Rifaat (Rifaat)" <rifatyu@avaya.com>
Content-Type: multipart/alternative; boundary="0023545bddec10926904a80b31a4"
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: Thu, 14 Jul 2011 17:52:14 -0000

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