Re: [splices] INVOKE Actions Scope

Paul Kyzivat <> Wed, 22 June 2011 18:05 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id D80D5228018 for <>; Wed, 22 Jun 2011 11:05:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -110.426
X-Spam-Status: No, score=-110.426 tagged_above=-999 required=5 tests=[AWL=0.173, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id MdHtLcYEIogE for <>; Wed, 22 Jun 2011 11:05:08 -0700 (PDT)
Received: from ( []) by (Postfix) with ESMTP id 651CE21F859C for <>; Wed, 22 Jun 2011 11:05:08 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=2796; q=dns/txt; s=iport; t=1308765908; x=1309975508; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=5Ft06AQ6kFMfPQsBbQ6ro2ueR1UsuF/UxUzOTPpKbbA=; b=LyeqvPjlBvg8d8e7rJikzHBJMD5i+5Obywh4YTYNcPQXh6r35RXmbeSt h2WIvXDBKpyyvqlmoXyNHk823gpSNcgoeWtyzCtXQEMgWaunV3k9U0euz pntr+44RFBbva6NjI53RXYvY7smYKylKPZx/fDBnabAjIafn9l9ejCl3I M=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AvcHAHctAk6rRDoJ/2dsb2JhbABUmDeOWXeIbAehcZ5Ihi0EkWqEZYtD
X-IronPort-AV: E=Sophos;i="4.65,407,1304294400"; d="scan'208";a="383407419"
Received: from ([]) by with ESMTP; 22 Jun 2011 18:05:08 +0000
Received: from [] ( []) by (8.14.3/8.14.3) with ESMTP id p5MI57pg009006 for <>; Wed, 22 Jun 2011 18:05:07 GMT
Message-ID: <>
Date: Wed, 22 Jun 2011 14:05:07 -0400
From: Paul Kyzivat <>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv: Gecko/20110414 Thunderbird/3.1.10
MIME-Version: 1.0
References: <> <>
In-Reply-To: <>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Subject: Re: [splices] INVOKE Actions Scope
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Loosely-coupled SIP Devices \(splices\) working group discussion list" <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 22 Jun 2011 18:05:10 -0000


On 6/22/2011 1:11 PM, Cullen Jennings wrote:
> 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.

The places where I think this wants/needs to go which is *related* to 
dialogs but which fundamentally expands the scope are:

- control of "transducers". Its not rocket science, but its new, and
   its going to require an architectural model of what transducers are
   and how they relate to the existing stuff in sip

- invoking of "features", such as "send the call to voicemail".
   That is at a higher level of abstraction than dialogs. Either
   we have to wave our hands and say "do what I mean", or we need
   to actually define what we mean. I realize Bliss is done and
   gone, but this "smells" like the kind of thing bliss was doing.


> 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
> Cullen Jennings
> For corporate legal information go to:
> _______________________________________________
> splices mailing list