Re: [splices] INVOKE Actions Scope

Paul Kyzivat <pkyzivat@cisco.com> Sat, 18 June 2011 17:40 UTC

Return-Path: <pkyzivat@cisco.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 90DC011E80AB for <splices@ietfa.amsl.com>; Sat, 18 Jun 2011 10:40:45 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.599
X-Spam-Level:
X-Spam-Status: No, score=-110.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
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 oHVNz1HrHsU9 for <splices@ietfa.amsl.com>; Sat, 18 Jun 2011 10:40:44 -0700 (PDT)
Received: from sj-iport-2.cisco.com (sj-iport-2.cisco.com [171.71.176.71]) by ietfa.amsl.com (Postfix) with ESMTP id 1D00B21F856D for <splices@ietf.org>; Sat, 18 Jun 2011 10:40:20 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=pkyzivat@cisco.com; l=2432; q=dns/txt; s=iport; t=1308418820; x=1309628420; h=message-id:date:from:mime-version:to:subject:references: in-reply-to:content-transfer-encoding; bh=YWz+QfVeLNbI8HeWJ10GKu/90LjSJTBffzo0vLjp/H4=; b=Fhl16Wq9yqdrousRdIk1XJmveFOArZtwlxiFv7u2zCk9bKW4WotJmT3k B3+nfLr/9LUmHkvpt08m0wiCDkEBsmjYK/p9ZY57tA1brnlE+d9bDIVhl lBVMjAzzxNX2NSZwVDip1oaJK1vrq9RDIqlfHgk5yTW5KjQtEZQuG0S/t E=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AmkHAMbi/E2tJXG9/2dsb2JhbABEDpgWjkl3iGwHn12dJ4Mdgw0EkV6EYIs9
X-IronPort-AV: E=Sophos;i="4.65,386,1304294400"; d="scan'208";a="379922529"
Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by sj-iport-2.cisco.com with ESMTP; 18 Jun 2011 17:40:19 +0000
Received: from [10.86.247.114] ([10.86.247.114]) by rcdn-core2-2.cisco.com (8.14.3/8.14.3) with ESMTP id p5IHeIKk026076 for <splices@ietf.org>; Sat, 18 Jun 2011 17:40:18 GMT
Message-ID: <4DFCE301.10700@cisco.com>
Date: Sat, 18 Jun 2011 13:40:17 -0400
From: Paul Kyzivat <pkyzivat@cisco.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.17) Gecko/20110414 Thunderbird/3.1.10
MIME-Version: 1.0
To: splices@ietf.org
References: <4CA2C4386DB56F4589D436E1C3C86F752230509C3B@DC-US1MBEX4.global.avaya.com>
In-Reply-To: <4CA2C4386DB56F4589D436E1C3C86F752230509C3B@DC-US1MBEX4.global.avaya.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
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: Sat, 18 Jun 2011 17:40:45 -0000

On 6/18/2011 9:37 AM, 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.

"Manipulate" is a fuzzy word.

You can look in 3261 and *start* to identify the state of a dialog.
Then you can look at 5057 for more on dialog usages.

If we were to consider any manipulation of any dialog or dialog usage 
state, we would need to support complex arguments - SDP, maybe event 
payloads, etc.

IMO we need to scope down more. E.g. only invite-dialog-usages, and the 
kinds of manipulation can't involve getting into fine details. We need 
to find a way to abstract away the details. Either we create our own 
abstraction, or else we adopt some existing abstraction. Unfortunately, 
I fear the existing abstractions may not cover multimedia sufficiently 
for our needs.

> 3. An Action can manipulate the state of a physical "feature" of a device, e.g. transducer.

"Transducer" seems like it might be a useful abstraction here.
But again, we need to understand it a little better to be able to 
understand what sort of "manipulation" is possible.

ISTM that "transducers" are the sources and sinks of media streams.
The class of manipulations we care about is perhaps just the 
attachment/detachment of transducers to media streams. Does that seem right?

> 4. An Action can invoke a well-defined telephony "feature" on the UA, e.g.hold.

I'm not so certain how "well-defined" these are, especially in the sip 
context.

E.g., does "hold" apply only to audio? Or does it apply in parallel to 
all media streams? Or can you hold individual streams? Is it 
music/video/etc on hold, or simply stopping the media?

IMO even "well known features" need to be individually defined.
This starts to feel like what bliss was doing.

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