Subject: Re: [RAI] Device control using SIP

From: Hadriel Kaplan <[email-masked]>
Date: Fri, 1 Jul 2011 11:24:30 -0400

I am confused by this example, probably because I'm not a trained mathematician. :)

The example takes a path which would not be possible if we were to define this using a PUBLISH event package, because I would assume the event package would specify that the UAC would not generate a state update until getting acknowledgement from the UAS that the previous state update was processed and acted upon. (for example through a NOTIFY to that effect)  Ergo, you can't PUBLISH state D without first PUBLISHing state B and getting an explicit acknowledgement that such occurred.  Clearly PUBLISH as a SIP method and mechanism does not have such dependency/work-flow restrictions built-in, but as far as I know we can specify such upper-application behaviors in the event packages.

To put this a different way: I'm proposing we NOT keep adding more higher-level application logic into the SIP protocol layer with new SIP method types and SIP protocol machinery, when it isn't necessary.

-hadriel

On Jun 29, 2011, at 10:45 PM, Adam Roach wrote:

On 6/29/11 21:03, Jun 29, Mike Hammer (hmmr) wrote:
Anyway, although I believe in lessons learned, I don’t want to put too much weight in past failures.  Extrapolation is a tricky thing.

I understand.

But in this case, the inherent problem can actually be explained pretty easily for the general case, and it should become clear that specifying states to dictate actions is not a generally solvable problem.

Consider the following FSM:

            +-----+
            |  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
<ATT00001..c>

---

From: Adam Roach <[email-masked]>
Date: Fri, 01 Jul 2011 12:59:26 -0500

The problem is that even calling out a state by itself can be ambiguous. 
Putting more concrete names on some states and transitions, consider the 
following subset of a state machine:

              +---------+
              | Ringing |
              +---------+
                 |   |
   User Forward  |   |  User Reject
   ------------  |   |  -----------
     Send 302    |   |   Send 603
                 V   V
              +---------+
              |  Idle   |
              +---------+

If all you do is tell a terminal in "Ringing" state to assume "Idle," 
the action to take is still ambiguous. You really want an 
action-oriented command set, rather than a state-oriented model with 
implied actions.

/a

On 7/1/11 10:24 AM, Hadriel Kaplan wrote:
> The example takes a path which would not be possible if we were to 
> define this using a PUBLISH event package, because I would assume the 
> event package would specify that the UAC would not generate a state 
> update until getting acknowledgement from the UAS that the previous 
> state update was processed and acted upon. (for example through a 
> NOTIFY to that effect)  Ergo, you can't PUBLISH state D without first 
> PUBLISHing state B and getting an explicit acknowledgement that such 
> occurred.  Clearly PUBLISH as a SIP method and mechanism does not have 
> such dependency/work-flow restrictions built-in, but as far as I know 
> we can specify such upper-application behaviors in the event packages.
>
> To put this a different way: I'm proposing we NOT keep adding more 
> higher-level application logic into the SIP protocol layer with new 
> SIP method types and SIP protocol machinery, when it isn't necessary.
>
> -hadriel
>
>>> Anyway, although I believe in lessons learned, I don’t want to put 
>>> too much weight in past failures.  Extrapolation is a tricky thing.
>>
>> I understand.
>>
>> But in this case, the inherent problem can actually be explained 
>> pretty easily for the general case, and it should become clear that 
>> specifying states to dictate actions is not a generally solvable problem.
>>
>> 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
>> <ATT00001..c>
>

---

From: "Worley, Dale R (Dale)" <[email-masked]>
Date: Fri, 1 Jul 2011 15:46:02 -0400

_______________________________________
From: [email-masked] [[email-masked]] On Behalf Of Mike Hammer (hmmr) [[email-masked]]

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

You don't want your middleboxes to maintain dialog state.  You really don't.

Dale

---

From: "Worley, Dale R (Dale)" <[email-masked]>
Date: Fri, 1 Jul 2011 15:57:06 -0400

________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Adam Roach [[email-masked]]

If all you do is tell a terminal in "Ringing" state to assume "Idle," the action to take is still ambiguous. You really want an action-oriented command set, rather than a state-oriented model with implied actions.
________________________________________

Even worse:  Two states, "Idle" and "On a call".  Both states can transition to the other.

Dale

---

From: "Worley, Dale R (Dale)" <[email-masked]>
Date: Fri, 1 Jul 2011 16:08:37 -0400

> From: [email-masked] [[email-masked]] On Behalf Of Hadriel Kaplan [[email-masked]]
> 
> I would assume the event package would specify that the UAC would not
> generate a state update until getting acknowledgement from the UAS
> that the previous state update was processed and acted upon.

It might not be possible to achieve that as easily as it seems...

Assume that the controller was using a stack that handles the details
of the PUBLISH transaction internally.  The API allows the application
to tell the stack "I have a new state, which is X." and the stack
publishes it to a specified set of UASs by sending PUBLISH to them.
(In our situation, we expect there to be exactly one UAS, but the
stack doesn't know that.)  If the application sets a new state, but
the PUBLISH of that state receives a transient 4xx response, the stack
might not be concerned about resending the state, assuming that a new
state update will be coming along soon.

OK, that last paragraph is a rather flimsy argument.  But this model
is really just a request/response protocol, done at the application
layer, with a PUBLISH client SIP transaction being used to send the
request, and a NOTIFY server SIP transaction from the far end used to
send the response.  With sufficient care at the application layer, we
can make the request/response system robust against quirky
"optimization" behaviors in the SIP stack, etc., but it seems to me
that is reinventing the wheel.

Dale

---

From: "Worley, Dale R (Dale)" <[email-masked]>
Date: Fri, 1 Jul 2011 16:19:48 -0400

> From: Hutton, Andrew [[email-masked]]
> 
> At least some of the approaches I am aware of are loosely based on
> ECMA-TR/87 (CSTA over SIP) and these although they have some
> limitations are not at all lame providing powerful and extensible
> mechanism which is not limited to SIP and don't require any SIP stack
> support.

I've gone back and looked at ECMA TR/87 again, and I am led to propose
(at least as a straw man) that we adopt it as a solution to this
problem.  It has the following advantages:

- Since it incorporates CSTA, it has an expansive model for
  controlling of UAs, so future extensibility is assured.

- CSTA understands that not all devices support all operations, so I
  expect that it has mechanisms for negotiating subsetted and extended
  capabilities.

- TR/87 defines a series of "profiles", including a "minimal" profile:

    Minimal uaCSTA Call Control Profile – provides support for making
    a call, answering an incoming call, deflecting a call, clearing a
    call, transferring a call in a single step, holding a call, and
    retrieving a call.

  This seems to match the set of actions that people have been
  discussing.

- The TR/87 method involves the controller establishing a dialog with
  the controllee using an INVITE with "Content-Disposition: signal",
  and then within that dialog, sending a series of INFO requests.
  This is higher-overhead for systems whose middleboxes maintain
  dialog state, but it allows those same middleboxes to perform
  authorization once for the INVITE rather than separately for each
  remote-control action request.

I have not looked at TR/87 in enough detail to say whether its
overheads are reasonable, nor much of anything other than what I have
written above.

What is your opinion?

Dale

---

From: "Worley, Dale R (Dale)" <[email-masked]>
Date: Fri, 1 Jul 2011 16:44:40 -0400

> From: Hadriel Kaplan [[email-masked]]
> 
> Let me put this all a different way: suppose you're a UA application
> using a third-party SIP stack.  This third-party SIP stack supports
> SUB/NOT/PUB, by exposing an API to the upper application.  The API
> allows the upper application to tell the SIP stack of event-packages
> it can handle, and the two pass the XML bodies back-forth through the
> API, such that the SIP stack is agnostic to the body content details,
> etc.  If the upper application decides tomorrow to implement some new
> package FOO, it can do so through the SIP stack using the API, without
> changing the SIP stack's code.  Do you believe this is possible?  If
> so, do you believe the use-case in this draft cannot work in such a
> model, and that instead we need to make some changes to the SIP stack
> itself for this use-case to work?

The difficulty is that there are behaviors that are allowed heretofore
by SIP stacks which would interfere with the utilization you are
entertaining.  You are actually imposing additional requirements on
the stack beyond RFC 3261/3265.

To explain this, I'm going to have to take the long way around.  Also,
I'm going to use SUBSCRIBE/NOTIFY in the explanation rather than
PUBLISH, both because I understand the grotty details of implementing
it much better and because the semantic model of SIP subscriptions is
much better established.

Let's suppose that "we" are the subscriber for a new event package
FOO.  And let us suppose that our SIP stack is simple, in that it
receives NOTIFY messages and passes their bodies to the application
layer without any post-processing.

Now consider the notifier's SIP application.  It generates a series of
state changes, and tells its SIP stack of them.  Its SIP stack may be
simple, and for each new state, diligently sends NOTIFYs to each
subscriber.

Or maybe the stack is more clever, more optimized, and knows that if a
new state is "full state", it can discard any scheduled NOTIFYs of
previous state changes that it has not already sent.  After all,
SUB/NOT is an event-state mechanism, and only the current state is
relevant!  And given the vagaries of networks, it's possible that some
of the subscribers have been inaccessible for a while, or the
notification process has gotten behind in its work.

Consider that there may be an event state compositor or buffer
in between the notifier and the subscriber, perhaps inserted without
the knowledge of either end.  The compositor might be buffering state
changes, sending 200s to the notifier before sending the NOTIFYs to
the subscribers.  And if the compositor sees a "full state" NOTIFY, it
can throw away any earlier NOTIFYs.  Worse, it could be composing all
the "partial state" NOTIFYs into a cached "full state", and instead of
sending each NOTIFY onward, it only sends the current cached "full
state" onward when it pleases.

Now consider that all of these behaviors could be present in *our*
stack.  Just because the stack handles SUBSCRIBE and NOTIFY it isn't
required pass up the contents of every NOTIFY that is received; it
only needs to ensure that all the rules of SIP are obeyed.

That last probably sounds extreme, but consider this case:  Suppose
the stack is divided into two threads, one which receives (say UDP)
SIP requests and queues them for processing, and one which retrieves
requests from the queues and passes them through the API to the
application.  And suppose the second thread starts getting behind in
its work, perhaps because the application is accepting notifications
slowly.  A clever programmer may have arranged for the first thread,
upon receipt of a full-state NOTIFY within a subscription to delete
from the queues all earlier NOTIFYs -- after all, their state is
subsumed into the full-state NOTIFY!

Of course, all of the above depends on their being identifiable "full
state" NOTIFY bodies, which are guaranteed to include any useful
information from all previous NOTIFY bodies.  But RFC 3265 requires
that there be such NOTIFY bodies, because a re-SUBSCRIBE is required
to receive such a NOTIFY.

Dale

---

From: Alan Johnston <[email-masked]>
Date: Sat, 2 Jul 2011 14:38:50 -0500

Mary,

No, Adam does mean XCON.  Do you recall the work we did on Media
Policy where we tried to allow configuration of the focus by
participants?  It really didn't work.  The current proposal that is
being discussed doesn't do this - it only allows a very small set of
well understood call and media control operations to be requested in a
peer-to-peer manner using SIP.

And I don't think the MEDIACTRL master/slave type is what we need here.

- Alan -

On Wed, Jun 29, 2011 at 2:27 PM, Mary Barnes <[email-masked]> wrote:
> Perhaps XCON is being confused with MEDIACTRL which defined a control
> framework using SIP?
> http://www.rfc-editor.org/rfc/rfc6230.txt
> Mary.
>
> On Wed, Jun 29, 2011 at 1:59 PM, Adam Roach <[email-masked]> wrote:
>>
>> Mike:
>>
>> I don't know which message you think you're responding to, but you've
>> clearly conflated two unrelated points I was making. I'll summarize:
>>
>> The "PUBLISH" method is used for publishing specific states, and is
>> therefore impossible to use for device control. My mail on this point cites
>> XCON as an example of why you can't push states to imply side effects. Note
>> that this point addresses feasibility, not appropriateness. I'm saying it
>> *can't* be done, with no reference to whether it *should*.
>>
>> The use of SIP for device control is inappropriately heavyweight. This
>> point is made without reference to XCON, as it offers no cautionary tales in
>> this area.
>>
>> You seem to be replying to point 2 (based on the message you quoted), but
>> have clearly conflated it with point 1 (given your reference to XCON). On
>> top of that, you seem to imply that I don't think we need inter-device
>> coordination to solve this problem, or that I think you need multiple
>> end-to-end SIP dialogs to have multiple devices on one end of a call
>> (neither of which I've said or implied in this thread).
>>
>> So I can't really ferret out the point you're trying to make, although I
>> gather you disagree with something I said. Which is odd, because I agree
>> with all the statements you make, save for your misrepresentation of my
>> position.
>>
>> Can you clarify?
>>
>> /a
>>
>> On 6/29/11 8:46 AM, Mike Hammer (hmmr) wrote:
>>
>> Adam,
>>
>> 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: [email-masked] [mailto:[email-masked]] On Behalf Of
>> Adam Roach
>> Sent: Tuesday, June 28, 2011 10:11 PM
>> To: Peter Musgrave
>> Cc: [email-masked]
>> 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
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/rai
>>
>>
>> RAI mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/rai
>>
>
>
> RAI mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rai
>
>

---

From: "Worley, Dale R (Dale)" <[email-masked]>
Date: Fri, 8 Jul 2011 15:24:12 -0400

Here is sort of an introduction to ECMA TR-87, although it uses NOTIFY requests rather than INFO requests to carry the CSTA:

http://docs.google.com/viewer?a=v&q=cache:WCifbJd0idcJ:wiki.siemens-enterprise.com/images/9/96/White_Paper_uaCSTA_for_OpenStage_SIP.pdf+http://www.ecma-international.org/standards/ecma-323/csta/ed3+info+user-agent+call-id&hl=en&gl=us&pid=bl&srcid=ADGEESgP6_Csodgai_5fhj2WFQA34iZcVXh7E30aVp-DMfHwIzhYtYMibcDGzS8OCYKxHvZjvqEDJ58dW1p1c6qY8MeoQ4BHqgnQjE8KZJRCN_AnWDB6D9zZPWAhiOyfW6fXCBf2qfvr&sig=AHIEtbTg9bo9YlPd_eDryRCJ0lEQLloSvQ

Dale

---

From: Chris Boulton <[email-masked]>
Date: Mon, 11 Jul 2011 10:18:33 +0100

> And I don't think the MEDIACTRL master/slave type is what we need here.
[Chris] master/slave?  Not quite sure what you mean here.  Sure 
MediaCtrl uses the framework (RFC 6230) in this way for media server 
control but its not restricted to this model.  The Framework was always 
intended to be generic.  As I said in a previous email on this thread - 
the framework is actually very conducive to this type of usage and we 
looked at this some time ago - 
http://tools.ietf.org/html/draft-boulton-sipping-endpoint-control-package-00. 

Chris.

-- 
Chris Boulton
CTO & Co-founder
NS-Technologies <http://www.ns-technologies.com>
m: +44.7876.476681

---

From: Peter Musgrave <[email-masked]>
Date: Tue, 12 Jul 2011 08:48:36 -0400

Thanks Dale.

Useful reference.

This seems to have about the right semantics for what is needed - so I think
it is worth pursuing.

If we can avoid a new mechanism in SIP then I think this work will get done
a lot faster.

I think there needs to be a discussion about in-dialog INFOs versus SUB/NOT
etc. but uaCSTA seems to have covered the cases required for basic device
control.

Peter Musgrave

On Fri, Jul 8, 2011 at 3:24 PM, Worley, Dale R (Dale) <[email-masked]>wrote:

> Here is sort of an introduction to ECMA TR-87, although it uses NOTIFY
> requests rather than INFO requests to carry the CSTA:
>
>

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 12 Jul 2011 11:26:30 -0400

The referenced white paper appears to describe a Siemens-specific 
dialect of ecma-TR/87 (uaCSTA). It has adopted unsolicited NOTIFY as its 
transport for CSTA messages, and has other issues that IMO make it 
entirely unsuitable for an IETF group to embrace.

Actual ecma-TR/87 may be a more viable candidate. I looked at it a long 
time ago, and just now skimmed some of it again. It is a sip mapping 
(using INFO) of a more general mechanism that is not sip-specific. It 
does have a model for the environment that it controls, which I found in 
Section 6 of ecma-269 (CSTA Operational Model) that more or less seems 
to cover the sorts of device capabilities we have been discussing. 
Actual CSTA message body schemas are in ecma-323. (All these docs are 
readily found via google.)

I am not an expert on this, or even a novice. I just took a quick look. 
There is a lot of material there that needs to be reviewed to see it it 
could be suitable as device control for splices.

The mapping of uaCSTA onto INFO of course predates info packages. So if 
we wanted to use it we would either have to bite our tongues and accept 
it as grandfathered, or else create yet another dialect.

	Thanks,
	Paul

On 7/12/11 8:48 AM, Peter Musgrave wrote:
> Thanks Dale.
>
> Useful reference.
>
> This seems to have about the right semantics for what is needed - so I
> think it is worth pursuing.
>
> If we can avoid a new mechanism in SIP then I think this work will get
> done a lot faster.
>
> I think there needs to be a discussion about in-dialog INFOs versus
> SUB/NOT etc. but uaCSTA seems to have covered the cases required for
> basic device control.
>
> Peter Musgrave
>
> On Fri, Jul 8, 2011 at 3:24 PM, Worley, Dale R (Dale) <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     Here is sort of an introduction to ECMA TR-87, although it uses
>     NOTIFY requests rather than INFO requests to carry the CSTA:
>
>     <http://docs.google.com/viewer?a=v&q=cache:WCifbJd0idcJ:wiki.siemens-enterprise.com/images/9/96/White_Paper_uaCSTA_for_OpenStage_SIP.pdf+http://www.ecma-international.org/standards/ecma-323/csta/ed3+info+user-agent+call-id&hl=en&gl=us&pid=bl&srcid=ADGEESgP6_Csodgai_5fhj2WFQA34iZcVXh7E30aVp-DMfHwIzhYtYMibcDGzS8OCYKxHvZjvqEDJ58dW1p1c6qY8MeoQ4BHqgnQjE8KZJRCN_AnWDB6D9zZPWAhiOyfW6fXCBf2qfvr&sig=AHIEtbTg9bo9YlPd_eDryRCJ0lEQLloSvQ>
>
>     Dale

---

From: "Hutton, Andrew" <[email-masked]>
Date: Wed, 13 Jul 2011 11:33:30 +0200

Hi,

I was one of the people behind this Siemens specific dialect and the original ECMA TR/87. I agree that both are unsuitable in their present form to be adopted by the IETF however it is a good architectural solution which has served us well. We never had any intention of bringing this to the IETF but published the interfaces for use by partners.

Architecturally I believe it is right to use SIP only as the transport mechanism and use an XML body to convey the actions and associated parameters therefore not requiring any SIP stack support. 

If there is interest in the IETF for making use of a CSTA based interface transported over SIP then I suspect the ECMA-323 XML would require some modification for example in the use of connection/session identifiers etc. 

Also if there is interest in doing something along these lines in the IETF then I would be able to contribute to this.

Regards
Andy

> Paul Kyzivat
> Sent: 12 July 2011 16:27
> To: [email-masked]
> http://docs.google.com/viewer?a=v&q=cache:WCifbJd0idcJ:wiki.siemens-
> enterprise.com/images/9/96/White_Paper_uaCSTA_for_OpenStage_SIP.pdf+htt
> p://www.ecma-international.org/standards/ecma-323/csta/ed3+info+user-
> agent+call-
> id&hl=en&gl=us&pid=bl&srcid=ADGEESgP6_Csodgai_5fhj2WFQA34iZcVXh7E30aVp-
> DMfHwIzhYtYMibcDGzS8OCYKxHvZjvqEDJ58dW1p1c6qY8MeoQ4BHqgnQjE8KZJRCN_AnWD
> B6D9zZPWAhiOyfW6fXCBf2qfvr&sig=AHIEtbTg9bo9YlPd_eDryRCJ0lEQLloSvQ
> >
> <http://docs.google.com/viewer?a=v&q=cache:WCifbJd0idcJ:wiki.siemens-
> enterprise.com/images/9/96/White_Paper_uaCSTA_for_OpenStage_SIP.pdf+htt
> p://www.ecma-international.org/standards/ecma-323/csta/ed3+info+user-
> agent+call-
> id&hl=en&gl=us&pid=bl&srcid=ADGEESgP6_Csodgai_5fhj2WFQA34iZcVXh7E30aVp-
> DMfHwIzhYtYMibcDGzS8OCYKxHvZjvqEDJ58dW1p1c6qY8MeoQ4BHqgnQjE8KZJRCN_AnWD
> B6D9zZPWAhiOyfW6fXCBf2qfvr&sig=AHIEtbTg9bo9YlPd_eDryRCJ0lEQLloSvQ>
> >
> >     Dale
> 
>

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 13 Jul 2011 09:16:12 -0400

Ah! We have one of the "culprits" in hand! :-)

I'm inclined to first investigate whether the CSTA Operational Model 
encompasses the sort of device control we think we need.
(I think it probably does, but am not certain. For example, its far from 
clear to me whether it encompasses the telepresence devices being 
considered by CLUE, or whether that matters.)

	Thanks,
	Paul

---

From: Dean Willis <[email-masked]>
Date: Fri, 15 Jul 2011 09:43:05 -0500

> Architecturally I believe it is right to use SIP only as the transport mechanism and use an XML body to convey the actions and associated parameters therefore not requiring any SIP stack support. 

I think this is exactly the design rationale that brought us SOAP, which technically works but is a royal pain with typically a tedious toolchain and change management issues.

SOAP, for those of you blessed to not deal with it, uses HTTP to transport XML blobs back and forth. The XML encodes the request identifier, parameters, and return value(s) from the operation.

We have this draft from 2000 that describes one approach for SOAP over SIP:

http://www.softarmor.com/wgdb/docs/draft-deason-sip-soap-00.txt

And yes, you really could do arbitrary device control over SOAP over SIP. One could even envision mapping all of SCCP or MGCP onto SOAP over SIP.

But is this a good idea?

SOAP, as I've mentioned, is a royal pain, and SOAP APIs tend to be brittle.

The alternative methodology is REST, which doesn't necessarily use XML, but instead typically encodes the request identifier into the URL, and encodes parameters as URL parameters or as form elements in a POST.

Which is more robust? Well, GOOGLE scrapped their SOAP API for search a while back ( I discovered this yesterday as I was working through a SOAP tutorial that used the Google API as an example).

This article discusses the rationale:

http://blogoscoped.com/archive/2009-03-03-n84.html

Maybe we need RESTful SIP?

--
Dean

---

From: Adam Roach <[email-masked]>
Date: Fri, 15 Jul 2011 09:46:20 -0500

> Maybe we need RESTful SIP?

HTTP with some rendezvous mechanism?

/a