Subject: [splices] INVOKE Actions Scope

From: "Shekh-Yusef, Rifaat (Rifaat)" <[email-masked]>
Date: Sat, 18 Jun 2011 09:37:22 -0400

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

---

From: Paul Kyzivat <[email-masked]>
Date: Sat, 18 Jun 2011 13:40:17 -0400

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

> _______________________________________________
> splices mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/splices
>

---

From: Cullen Jennings <[email-masked]>
Date: Wed, 22 Jun 2011 10:11:18 -0700

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. 

> 6. An Action cannot dictate the UI behavior of the target UA.

Cullen Jennings
For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/index.html

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 22 Jun 2011 14:05:07 -0400

Cullen,

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

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.

	Thanks,
	Paul