So if there was some reasonable way to perform CTI within SIP, it would make
life easier for many real-world systems.

Adam,

The problem with the device control approach is that you need to have
multiple dialogs running through the network and all the boxes there
that maintain state.  When you have more complex call flows, trying to
get all N dialogs in sync will be problematic.  The network might be
able to authenticate and authorize the SIP device, but maybe not the
conference room screen you just commandeered.  When you treat a SIP
device with some ancillary devices as components of that SIP device, the
call control can be managed much more simply when it is a single dialog
with multiple media.

Maybe XCON had issues, but Telepresence with multiple devices under the
control of a single endpoint does not.  So, I'm not so sure the XCON
experience can be extrapolated to what may be proposed here.  Also, the
issue was not about "target state" but about "current state".  It should
not be too difficult for a device to report what it is doing now and
notifying whenever it changes.  That is not really much different than
when you are dealing with a component in an integrated system.  The
controller takes action based on current status.

Mike

-----Original Message-----
From: rai-bounces@ietf.org [mailto:rai-bounces@ietf.org] On Behalf Of
Adam Roach
Sent: Tuesday, June 28, 2011 10:11 PM
To: Peter Musgrave
Cc: rai@ietf.org
Subject: Re: [RAI] Device control using SIP

On 6/28/11 17:29, Jun 28, Peter Musgrave wrote:

Could we define a set of actions which would apply to the reference 
dialog state machine and define what each state would do for each 
remote action?

Sure. That's exactly what I was saying would make sense when I spoke of 
an "action-based approach." It's actually pretty easy -- similar to a 
terminal stimulus protocol.

The question, though, is why on earth would we want to use SIP for this?

SIP is great at setting up and tearing down sessions, and performing 
operations that operate on those sessions at a semantic level. But 
that's not what this is.

This is a set of device control primitives. The best you could hope for 
is to use the incongruously heavyweight machinery of SIP transactions 
for each of these primitives. But that makes no more or less sense than 
using extensions to HTTP, SMTP, IMAP, FTP, MSRP, XMPP, BXXP, or <name 
your favorite protocol here> to do the same thing. None of it makes any 
sense. At all.

What would make far more *sense* would be using SIP to set up sessions 
of some simple, extensible device-control protocol (call it DCP for for 
lack of a better term), and then using that DCP to perform device
control.

/a
_______________________________________________
RAI mailing list
RAI@ietf.org
https://www.ietf.org/mailman/listinfo/rai

Adam,

The problem with the device control approach is that you need to have
multiple dialogs running through the network and all the boxes there
that maintain state.  When you have more complex call flows, trying to
get all N dialogs in sync will be problematic.  The network might be
able to authenticate and authorize the SIP device, but maybe not the
conference room screen you just commandeered.  When you treat a SIP
device with some ancillary devices as components of that SIP device, the
call control can be managed much more simply when it is a single dialog
with multiple media.

Maybe XCON had issues, but Telepresence with multiple devices under the
control of a single endpoint does not.  So, I'm not so sure the XCON
experience can be extrapolated to what may be proposed here.  Also, the
issue was not about "target state" but about "current state&=
quot;.  It should
not be too difficult for a device to report what it is doing now and
notifying whenever it changes.  That is not really much different than
when you are dealing with a component in an integrated system.  The
controller takes action based on current status.

Mike

-----Original Message-----
From: rai-bounces=
@ietf.org [ma=
ilto:rai-bounces@ietf.org] On Behalf Of
Adam Roach
Sent: Tuesday, June 28, 2011 10:11 PM
To: Peter Musgrave
Cc: rai@ietf.org
Subject: Re: [RAI] Device control using SIP

On 6/28/11 17:29, Jun 28, Peter Musgrave wrote:

Could we define a set of actions which would apply to the refe=
rence=20
dialog state machine and define what each state would do for each=20
remote action?

Sure. That's exactly what I was saying would make sense when=
 I spoke of=20
an "action-based approach." It's actually pretty easy -- simi=
lar to a=20
terminal stimulus protocol.

The question, though, is why on earth would we want to use SIP for this?

SIP is great at setting up and tearing down sessions, and performing=20
operations that operate on those sessions at a semantic level. But=20
that's not what this is.

This is a set of device control primitives. The best you could hope for=20
is to use the incongruously heavyweight machinery of SIP transactions=20
for each of these primitives. But that makes no more or less sense than=20
using extensions to HTTP, SMTP, IMAP, FTP, MSRP, XMPP, BXXP, or <name=20
your favorite protocol here> to do the same thing. None of it makes any=
=20
sense. At all.

What would make far more *sense* would be using SIP to set up sessions=20
of some simple, extensible device-control protocol (call it DCP for for=20
lack of a better term), and then using that DCP to perform device
control.

/a
_______________________________________________
RAI mailing list
RAI@ietf.org
htt=
ps://www.ietf.org/mailman/listinfo/rai

Adam,

multiple dialogs running through the network =
and all the boxes there
that maintain state.  =
When you have more complex call flows, trying =
to
get all N dialogs in sync will be =
problematic.  The network might be
able to =
authenticate and authorize the SIP device, but maybe not =
the
conference room screen you just =
commandeered.  When you treat a SIP
device =
with some ancillary devices as components of that SIP device, =
the
call control can be managed much more simply =
when it is a single dialog
with multiple =
media.

Maybe XCON had =
issues, but Telepresence with multiple devices under =
the
control of a single endpoint does not.  =
So, I'm not so sure the XCON
experience can be =
extrapolated to what may be proposed here.  Also, =
the
issue was not about "target state" =
but about "current state".  It =
should
not be too difficult for a device to report =
what it is doing now and
notifying whenever it =
changes.  That is not really much different =
than
when you are dealing with a component in an =
integrated system.  The
controller takes =
action based on current =
status.

Mike<=
/pre> 

-----Or=
iginal Message-----
From: rai-bounces@ietf.org [mailto:rai-bounces@ietf.org] On =
Behalf Of
Adam Roach
Sent: =
Tuesday, June 28, 2011 10:11 PM
To: Peter =
Musgrave
Cc: rai@ietf.org
Subjec=
t: Re: [RAI] Device control using =
SIP

On 6/28/11 17:29, =
Jun 28, Peter Musgrave wrote:
Could we define a =
set of actions which would apply to the reference =
dialog state machine and define what each state =
would do for each 
remote =
action?

Sur=
e. That's exactly what I was saying would make sense when I spoke of =
an "action-based approach." It's =
actually pretty easy -- similar to a 
terminal =
stimulus protocol.

The =
question, though, is why on earth would we want to use SIP for =
this?

SIP is great at =
setting up and tearing down sessions, and performing =
operations that operate on those sessions at a =
semantic level. But 
that's not what this =
is.

This is a set of =
device control primitives. The best you could hope for =
is to use the incongruously heavyweight machinery =
of SIP transactions 
for each of these primitives. =
But that makes no more or less sense than 
using =
extensions to HTTP, SMTP, IMAP, FTP, MSRP, XMPP, BXXP, or <name =
your favorite protocol here> to do the same =
thing. None of it makes any 
sense. At =
all.

What would make =
far more *sense* would be using SIP to set up sessions =
of some simple, extensible device-control protocol =
(call it DCP for for 
lack of a better term), and =
then using that DCP to perform =
device
control.

/a
____________________________________=
___________
RAI mailing =
list
RAI@ietf.org
https://www.ietf.org/m=
ailman/listinfo/rai

            +-----+

                  |  A  |

                  +-----+

      event 1      /    \    event 2

      --------    /      \   --------

      action 1   /        \  action 2

                V          V

             +-----+   +-----+

             |  B  |   |  C  |

             +-----+   +-----+

      event 3   |     /   |  event 5

      --------  |    /    |  --------

      action 3  |   /     |  action 5

                V  V      V

             +-----+   +-----+

             |  D  |   |  E  |

             +-----+   +-----+

      Now, if the system is in state A, and you tell it to assume state
      D, it is ambiguous whether it is to perform "action 1" and "action
      3" (inferring that event 1 and event 3 are to occur), or whether
      it is to perform "action 2" and (unlabeled) "action 4" (the
      transition from C to D). The system could, of course, *pick* one
      arbitrarily, but that lacks precision and may lead to unwanted
      actions.

      In fact, it's not particularly easy to programmatically figure out
      how to even traverse an unambiguous path from A to E in a
      sufficiently complex graph.

      And, of course, it can be computationally expensive (given
      real-world state machines) to figure out that a request to assume
      state "E" when the system is in state "B" is actually impossible.

      This is all made much, much easier if you simply design a system
      that explicitly calls out events rather than resultant states.

      /a

       &nbs=
p;    +-----+
          =
;  |  A  =
|
          =
;  +-----+
event 1      =
/    \    event =
2
--------    /      =
\   --------
action 1   =
/        \  action =
2
          =
V          =
V
       +-----+   =
+-----+
       |  B  =
|   |  C  =
|
       +-----+   =
+-----+
event 3   |     =
/   |  event 5
--------  =
|    /    |  =
--------
action 3  |   =
/     |  action =
5
          =
V  V      =
V
       +-----+   =
+-----+
       |  D  =
|   |  E  =
|
       +-----+   =
+-----+
       =

Now, if the system is in state A, and you tell it to =
assume state D, it is ambiguous whether it is to perform "action =
1" and "action 3" (inferring that event 1 and event 3 are =
to occur), or whether it is to perform "action 2" and =
(unlabeled) "action 4" (the transition from C to D). The =
system could, of course, *pick* one arbitrarily, but that lacks =
precision and may lead to unwanted actions.
In fact, =
it's not particularly easy to programmatically figure out how to even =
traverse an unambiguous path from A to E in a sufficiently complex =
graph.
And, of course, it can be computationally =
expensive (given real-world state machines) to figure out that a request =
to assume state "E" when the system is in state "B" =
is actually impossible.
This is all made much, much =
easier if you simply design a system that explicitly calls out events =
rather than resultant =
states.
/a