Subject: [RAI] Device control using SIP

From: Gonzalo Camarillo <[email-masked]>
Date: Tue, 21 Jun 2011 11:27:57 +0300

Hi,

the SPLICES WG is chartered to work on a framework for disaggregated
media in SIP.

https://datatracker.ietf.org/wg/splices/charter/

As part of the SPLICES framework, the WG has been discussing a SIP-based
mechanism to control devices.

https://datatracker.ietf.org/doc/draft-yusef-splices-invoke/

As you can see, this is an individual submission and the SPLICES WG
still has not decided whether or not this will be needed. However, this
draft has attracted a significant amount of attention on the SPLICES
mailing list.

The reason for this "heads up" is that this issue has been discussed at
length by the RAI community in the past. You may remember the "explode
my phone" discussions where a user agent sent such a command to another
one :o)

I would like to see an explicit discussion on whether or not this type
of application (i.e., device control) should fall within the scope of SIP.

Thanks,

Gonzalo

---

From: "Mike Hammer (hmmr)" <[email-masked]>
Date: Tue, 21 Jun 2011 10:29:22 -0500

Gonzalo,

Are you referring to a specific working group, or just referencing the
technology?

I think it should fall within the technical scope of SIP, else you get
the god-box mentality that 3GPP came up with for IUT.  While the
approach of this draft seems to make one SIP user a puppet-master for
another entity and does not require the network to know that 2 SIP
sessions might be related, there are other approaches possible.  Such as
having the master subscribe to gain the right to use the subordinate's
IP address and capabilities to send traffic to it.  That would lead to
fewer sessions handled through the core, and less reliance on VCC type
mechanisms.  I am not sure if that is what you meant by the exploded
device discussion, since I wasn't there to hear it.

But, the bottom line is that there are SIP-related existing message
types that could be used without inventing new ones that could get the
job done without resorting to things like Megaco.  So, I would say it
falls within the technical scope of SIP.  You are still setting up
sessions, right?

Mike

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Gonzalo Camarillo
Sent: Tuesday, June 21, 2011 4:28 AM
To: [email-masked]
Subject: [RAI] Device control using SIP

Hi,

I would like to see an explicit discussion on whether or not this type
of application (i.e., device control) should fall within the scope of
SIP.

Thanks,

Gonzalo

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

---

From: "Worley, Dale R (Dale)" <[email-masked]>
Date: Tue, 21 Jun 2011 12:18:05 -0400

________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Gonzalo Camarillo [[email-masked]]

As part of the SPLICES framework, the WG has been discussing a SIP-based
mechanism to control devices.[that is, SIP UAs]

I think that constructing a good way to remotely control a UA via SIP is desirable.  The reason is
that people are already building CTI ("computer-telephone integration") systems, but using other
protocols.  (E.g., HTTP is always popular.)  But in a SIP-based system, all of the network reachability
problems have already been solved for SIP; there is extra work to solve them again for HTTP or
another protocol.  So if there was some reasonable way to perform CTI within SIP, it would make
life easier for many real-world systems.

Dale

---

From: Chris Boulton <[email-masked]>
Date: Wed, 22 Jun 2011 14:00:28 +0100

On 21/06/2011 17:18, Worley, Dale R (Dale) wrote:
> So if there was some reasonable way to perform CTI within SIP, it would make
[Chris] Agreed.  I am not convinced that using a new SIP method is 
really the way we want to go with this - it feels dirty :-).  We looked 
at using the Media Channel Control Framework 
(http://tools.ietf.org/html/rfc6230) for this very task 
(http://tools.ietf.org/html/draft-boulton-sipping-endpoint-control-package-00) 
a couple of years ago which a) uses Session Initiation Protocol as 
intended - to negotiate and manage sessions (the hint is in the name) 
and b) use the control channel for control.

Chris.

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

---

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

I don't think SIP is a particular good protocol for device control and have generally been an advocated other protocols for that.

 However, I do not think the draft-yusef-splices-invoke draft is about device control. It is about using SIP to do call control - something that I think SIP is good for. Right now  many of the operation you would like to do on a SIP dialog can be signaled in SIP, however, some can not and some of these are needed for widely implement and used features in todays systems. This draft just tries to fill some of theses gaps in manipulating SIP dialog state. 

My largest concern about this draft is it is likely 5 years too late and so most vendors just have proprietary extensions to accomplish this which limits the interoperability between phones and PBXs. Based on IETF feedback, we have switched this drat to, use a URN, no use XML, no use a new method, no SIP should not do this, no this should be in BLISS, no we are closing BLISS so it can't go there, this is realated to SPLICES so please take it there, no this is not in the scope of SPLICES. 

The bottom line is it will be the same people discussing it no matter where in RAI we discuss it and if the bits a arranged in angle brackets, the method part of SIP message, or some other part of the sip message makes pretty very little difference to any practical use of this.

> of application (i.e., device control) should fall within the scope of SIP.

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

---

From: "Worley, Dale R (Dale)" <[email-masked]>
Date: Wed, 22 Jun 2011 15:37:12 -0400

________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Cullen Jennings [[email-masked]]

My largest concern about this draft is it is likely 5 years too late and so most vendors just have proprietary extensions to accomplish this which limits the interoperability between phones and PBXs.
_______________________________________________

One would expect that, but oddly, I haven't seen it.  Most systems that do call control do it by running all calls through a central B2BUA, and manipulating the calls within the B2BUA, leaving the phones as SIP-ified dumb phones.

Dale

---

From: "Elwell, John" <[email-masked]>
Date: Thu, 23 Jun 2011 08:47:30 +0200

> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Cullen Jennings
> Sent: 22 June 2011 18:11
> To: [email-masked]
> Subject: Re: [RAI] Device control using SIP
> 
> 
> I don't think SIP is a particular good protocol for device 
> control and have generally been an advocated other protocols for that.
> 
>  However, I do not think the draft-yusef-splices-invoke draft 
> is about device control. It is about using SIP to do call 
> control - something that I think SIP is good for. Right now  
> many of the operation you would like to do on a SIP dialog 
> can be signaled in SIP, however, some can not and some of 
> these are needed for widely implement and used features in 
> todays systems. This draft just tries to fill some of theses 
> gaps in manipulating SIP dialog state. 
> 
> My largest concern about this draft is it is likely 5 years 
> too late and so most vendors just have proprietary extensions 
> to accomplish this which limits the interoperability between 
> phones and PBXs. Based on IETF feedback, we have switched 
> this drat to, use a URN, no use XML, no use a new method, no 
> SIP should not do this, no this should be in BLISS, no we are 
> closing BLISS so it can't go there, this is realated to 
> SPLICES so please take it there, no this is not in the scope 
> of SPLICES. 
[JRE] I agree it is too late. Those who need it have found other ways of doing it, e.g., CSTA. We had a discussion 5 or 6 years ago on this general topic, with several proposals, including the possibility of transporting CSTA over SIP. The IETF did nothing and Ecma produced Technical Report TR/087 covering transport of CSTA XML syntax over SIP. This can be treated as a standard although I don't think it is implemented much in quite that form (and that is perhaps why it never became and Ecma Standard). Anyway, we would need to be very clear on the motivation for opening this up again now when it wasn't seen as appropriate at the time.

> 
> The bottom line is it will be the same people discussing it 
> no matter where in RAI we discuss it and if the bits a 
> arranged in angle brackets, the method part of SIP message, 
> or some other part of the sip message makes pretty very 
> little difference to any practical use of this.
[JRE] RAI has a process, which is to discuss new work in DISPATCH. I don't think we want SPLICES to turn into a sort of SIPPING. This topic was originally dispatched to SPLICES because there seemed to be some synergy with the SPLICES problem. That has turned out not to be the case (there may be some commonality, but the Yusef draft is much broader). So a mistake was made, and the proper thing to do would be to bring it back to DISPATCH, draft a charter, hold a mini-BoF, etc.. This is clearly too big and controversial just to let some WG creep its scope and pick it up. Perhaps the DISPATCH chairs can step in here? Oh - I see Cullen is a DISPATCH chair.

John

---

From: Gonzalo Camarillo <[email-masked]>
Date: Thu, 23 Jun 2011 12:57:41 +0300

Hi Mike,

> Are you referring to a specific working group, or just referencing the

I am talking about the technology. If we decide we want to work on this,
deciding in which WG to do it should be trivial.

>  So, I would say it

As the examples in the draft show, a UA can tell another UA to answer a
call. So, it somewhat relates to both call and device control.

Cheers,

Gonzalo

---

From: Gonzalo Camarillo <[email-masked]>
Date: Thu, 23 Jun 2011 13:07:08 +0300

Hi Cullen,

as I also said in a previous email, I would like the community to decide
whether or not we want to do this with SIP. If we decide we indeed want
to do this, choosing which WG does it would be easy... and deciding how
to do it would be business as usual within the WG.

I want to focus on doing the right thing. Once we have consensus on what
to do, we can take care of the process.

One timing-related question on your response below. Considering your
concern about this mechanism being a few years late, do you think it is
still worthwhile standardizing it at this point? Are those vendors with
proprietary solutions likely to switch to a standard solution?

Thanks,

Gonzalo

---

From: Simon Pietro Romano <[email-masked]>
Date: Thu, 23 Jun 2011 12:07:11 +0200

I personally agree with Cullen. I do believe the things in the draft are 
worth discussing (finally!) and the venue where we discuss them is a 
minor concern for me.

Simon

-- 
                             _\\|//_
                             ( O-O )
    ~~~~~~~~~~~~~~~~~~~~~~o00~~(_)~~00o~~~~~~~~~~~~~~~~~~~~~~~~
                     Simon Pietro Romano
               Universita' di Napoli Federico II
                  Computer Science Department
         Phone: +39 081 7683823 -- Fax: +39 081 7684219
                 e-mail: [email-masked]
           http://www.comics.unina.it/simonpietro.romano

     <<Molti mi dicono che lo scoraggiamento è l'alibi degli
    idioti. Ci rifletto un istante; e mi scoraggio>>. Magritte.
                          oooO
    ~~~~~~~~~~~~~~~~~~~~~~(   )~~ Oooo~~~~~~~~~~~~~~~~~~~~~~~~~
                           \ (    (   )
                            \_)    ) /
                                  (_/

---

From: Christer Holmberg <[email-masked]>
Date: Thu, 23 Jun 2011 12:31:59 +0200

Hi,

Cullen said that SIP is good for call control and dialog state manipulation. However, what we are talking about here is using SIP to control/manipulate ANOTHER SIP dialog.

So, how much should the SIP dialog I am using to do that control be affected?

For example, if we would use the INVOKE method, my SIP stack would have to support that method, and understand the semantics of it.

But, if we would see the call control more as an application, and SIP as a mechanism to transport that call control information, something like INFO would be more appropriate. Of course, my SIP stack would have to support the INFO method, but it wouldn't have to understand the semantics of the application date carried in the INFO.

Regards,

Christer

> Behalf Of Gonzalo Camarillo
> Sent: 23. kesäkuuta 2011 13:07
> To: Cullen Jennings
> Cc: [email-masked]
> as I also said in a previous email, I would like the 
> community to decide whether or not we want to do this with 
> SIP. If we decide we indeed want to do this, choosing which 
> WG does it would be easy... and deciding how to do it would 
> be business as usual within the WG.
> 
> I want to focus on doing the right thing. Once we have 
> consensus on what to do, we can take care of the process.
> 
> One timing-related question on your response below. 
> Considering your concern about this mechanism being a few 
> years late, do you think it is still worthwhile standardizing 
> it at this point? Are those vendors with proprietary 
> solutions likely to switch to a standard solution?
> 
> Thanks,
> 
> Gonzalo
> 
> 
> >  However, I do not think the draft-yusef-splices-invoke 
> draft is about device control. It is about using SIP to do 
> call control - something that I think SIP is good for. Right 
> now  many of the operation you would like to do on a SIP 
> dialog can be signaled in SIP, however, some can not and some 
> of these are needed for widely implement and used features in 
> >> As part of the SPLICES framework, the WG has been discussing a 
> >> SIP-based mechanism to control devices.
> >>
> >> still has not decided whether or not this will be needed. However, 
> >> this draft has attracted a significant amount of attention on the 
> >> SPLICES mailing list.
> >>
> >> The reason for this "heads up" is that this issue has been 
> discussed 
> >> at length by the RAI community in the past. You may remember the 
> >> "explode my phone" discussions where a user agent sent 
> such a command 
> >> to another one :o)
> >>
> >> I would like to see an explicit discussion on whether or not this 
> >> type of application (i.e., device control) should fall 
> within the scope of SIP.
> >>
> >> Thanks,
> >>
> >> Gonzalo
> >>

---

From: Gonzalo Camarillo <[email-masked]>
Date: Thu, 23 Jun 2011 14:39:36 +0300

Hi John,

> [JRE] RAI has a process, which is to discuss new work in DISPATCH. I
> don't think we want SPLICES to turn into a sort of SIPPING. This
> topic was originally dispatched to SPLICES because there seemed to be
> some synergy with the SPLICES problem. That has turned out not to be
> the case (there may be some commonality, but the Yusef draft is much
> broader). So a mistake was made, and the proper thing to do would be
> to bring it back to DISPATCH, draft a charter, hold a mini-BoF, etc..
> This is clearly too big and controversial just to let some WG creep
> its scope and pick it up. Perhaps the DISPATCH chairs can step in
> here? Oh - I see Cullen is a DISPATCH chair.

Yes, the history of this work is that this draft was dispatched to the
SPLICES WG. There are people in the SPLICES WG who believe they need
this functionality. Given that this issue (call and device control in
SIP) has been discussed previously and that such functionality may be
used beyond SPLICES-related scenarios, we need input from the community
at large.

I think the RAI list is a good place to ask this question because it is
a technically-related question about the scope of SIP. Depending on what
the community thinks about this scope issue, we will decide what process
we need to apply to get the job done.

Thanks,

Gonzalo

---

From: "Mike Hammer (hmmr)" <[email-masked]>
Date: Thu, 23 Jun 2011 08:21:19 -0500

Christer,

I would not look at it as device control.
The way I am envisioning the question is this:

Can multiple device components be aggregated into one endpoint with 
a single SIP session control managing media to those device components?

Look at how our Telepresence rooms operate.  The difference here is that 
the devices being aggregated should be able to join the endpoint (I am 
tempted to call it the borg now) in ad-hoc fashion.

I am envisioning in my head walking into a conference room, 
discovering the identity of a flat screen on the wall (manual or NFC), 
asking and getting permission to assume control of it (SUBSCRIBE/NOTIFY?), 
then sending re-INVITE so video feed goes to that screen rather than my smartphone.

Is it too late?  
Yeah, right up until someone like Apple does it and all go gaga over it.

Mike

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Christer Holmberg
Sent: Thursday, June 23, 2011 6:32 AM
To: Gonzalo Camarillo; Cullen Jennings (fluffy)
Cc: [email-masked]
Subject: Re: [RAI] Device control using SIP

Hi,

Regards,

Christer

---

From: "Hutton, Andrew" <[email-masked]>
Date: Thu, 23 Jun 2011 17:03:05 +0200

Hi,

I completely agree with Christer's statement below about this all been application level stuff that should not impact a SIP implementation/stack other than the generic mechanism for extracting a body and passing it to an application. 

Whatever protocol is used for conveying these actions to the device I think that SIP is just one of a number of possible transports so it would be a mistake to use SIP itself and therefore prevent other transports being used.

Regards
Andy

> Christer Holmberg
> Sent: 23 June 2011 11:32
> To: Gonzalo Camarillo; Cullen Jennings
> Cc: [email-masked]
> Cullen said that SIP is good for call control and dialog state
> manipulation. However, what we are talking about here is using SIP to
> control/manipulate ANOTHER SIP dialog.
> 
> For example, if we would use the INVOKE method, my SIP stack would have
> to support that method, and understand the semantics of it.
> 
> But, if we would see the call control more as an application, and SIP
> as a mechanism to transport that call control information, something
> like INFO would be more appropriate. Of course, my SIP stack would have
> to support the INFO method, but it wouldn't have to understand the
> semantics of the application date carried in the INFO.
> 
> Regards,
> 
> Christer
> 
> 
>

---

From: Cullen Jennings <[email-masked]>
Date: Thu, 23 Jun 2011 08:45:25 -0700

> My largest concern about this draft is it is likely 5 years too late and so most vendors just have proprietary extensions to accomplish this which limits the interoperability between phones and PBX…

Fair enough - we have stuffed some XML in the SIP between the B2BUA based PBX and the phones but I imagine other vendors have done other things. The CSTA approach did not cut it.

---

From: Cullen Jennings <[email-masked]>
Date: Thu, 23 Jun 2011 09:13:22 -0700

> [JRE] RAI has a process, which is to discuss new work in DISPATCH. I don't think we want SPLICES to turn into a sort of SIPPING. This topic was originally dispatched to SPLICES because there seemed…

(not with my dispatch chair hat on here )

So in general, I like that IETF process allows us to make mistakes, and then go fix them. Any time we make a mistake, I am sad with the delay it introduces but I think it important to go fix them. I think that is what Gonzalo is driving here is just lets go sort out the right thing to do then figure out where to do it.

---

From: Cullen Jennings <[email-masked]>
Date: Thu, 23 Jun 2011 09:14:02 -0700

> Cullen said that SIP is good for call control and dialog state manipulation. However, what we are talking about here is using SIP to control/manipulate ANOTHER SIP dialog.

Right, just like REFER. I think in the past that was why some of the authors argued refer was about the right semantics for this. I'm not really fixated on how we do this, I would just like to see it solved.

---

From: Hadriel Kaplan <[email-masked]>
Date: Thu, 23 Jun 2011 16:26:24 -0400

> of application (i.e., device control) should fall within the scope of SIP.

I read the draft and I don't see the big deal.  The "application" in question is to be able to tell another UA to change its state (dialog state, media state, conference state, whatever).  Presumably in order to do the things described, the controlling UAC needs to actually know what state the controlled UAS is in before "commanding" it to do something new.  We have a means to do that: SUBSCRIBE/NOTIFY, for things like the dialog event-package.  We also have things to push state: PUBLISH.  So just go define a new Event-Package similar to but broader than dialog event-package, have the Controller SUBSCRIBE to it to learn the current state and any future changes, and have it send PUBLISHes within the same dialog to change the state on the controlled party.

I don't see a need for a new method or headers.
Do we need a new WG to define an Event-Package?

-hadriel

---

From: Paul Kyzivat <[email-masked]>
Date: Thu, 23 Jun 2011 17:41:26 -0400

> I read the draft and I don't see the big deal.  The "application" in question is to be able to tell another UA to change its state (dialog state, media state, conference state, whatever).  Presumab…

That could work! I think I like it.

> Do we need a new WG to define an Event-Package?

Maybe. We have had a lot of trouble getting good definitions of event 
packages. The state model seems difficult for people to understand.

If one of the goals is to control the mapping of calls to "transducers" 
(speakers, microphones, etc.) then the state model for the event package 
should encompass these things. While it doesn't seem like rocket 
science, I suspect it will take work to get people to a common 
understanding.

I'm not suggesting that we shouldn't do it, but I don't think we should 
assume it will be quick and easy to do either.

	Thanks,
	Paul

---

From: "Shekh-Yusef, Rifaat (Rifaat)" <[email-masked]>
Date: Thu, 23 Jun 2011 22:50:59 -0400

Hadriel,

The Controller can learn the state of the Controlled device using other means.
For example, a proxy application that is in the signaling path is aware of the state of the Controlled device, so it does not need to subscribe to anything.

Also, I thought that PUBLISH is used to publish state changes, not manipulate the state of a dialog.
Your proposal seems to overload and change the meaning of the PUBLISH request.

Regards,
 Rifaat

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Hadriel
> Kaplan
> Sent: Thursday, June 23, 2011 4:26 PM
> To: Gonzalo Camarillo
> Cc: [email-masked]
> I read the draft and I don't see the big deal.  The "application" in question
> is to be able to tell another UA to change its state (dialog state, media
> state, conference state, whatever).  Presumably in order to do the things
> described, the controlling UAC needs to actually know what state the
> controlled UAS is in before "commanding" it to do something new.  We have a
> means to do that: SUBSCRIBE/NOTIFY, for things like the dialog event-package.
> We also have things to push state: PUBLISH.  So just go define a new Event-
> Package similar to but broader than dialog event-package, have the Controller
> SUBSCRIBE to it to learn the current state and any future changes, and have it
> send PUBLISHes within the same dialog to change the state on the controlled
> party.
>

---

From: Salvatore Loreto <[email-masked]>
Date: Fri, 24 Jun 2011 11:16:09 +0300

I have a lot of doubts that overloading the PUBLISH method is the right 
way to solve this issue;
especially if the idea is to change the meaning of a 'plain' PUBLISH 
request
one that does not carry any new header specifically designed for the aim

/Sal

---

From: "Mike Hammer (hmmr)" <[email-masked]>
Date: Fri, 24 Jun 2011 08:36:45 -0500

Is device state something that can be published?

Or is there some hidden restriction on what type of info can be
published?

Mike

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Salvatore Loreto
Sent: Friday, June 24, 2011 4:16 AM
To: [email-masked]
Subject: Re: [RAI] Device control using SIP

/Sal

On 6/24/11 5:50 AM, Shekh-Yusef, Rifaat (Rifaat) wrote:
> For example, a proxy application that is in the signaling path is
aware of the state of the Controlled device, so it does not need to
subscribe to anything.
>> From: [email-masked] [mailto:[email-masked]] On Behalf Of
Hadriel
>>> I would like to see an explicit discussion on whether or not this
type

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 24 Jun 2011 09:52:31 -0400

> one that does not carry any new header specifically designed for the aim

It might be reasonable, or not, depending on how structured.
For it to make sense, there needs to be an event type with a suitable 
state model, so that updates to the state via PUBLISH make sense.
Its not entirely clear to me how feasible it is to come up with a 
suitable state model to accommodate that, but it could be investigated. 
At this point its just a concept.

I'd have to go back and study the dialog event package to see if that 
could be made to work.

I guess the most questionable part is if publishing a state change to a 
device that has direct knowledge of the state can be interpreted as a 
request to "make it so". That is perhaps a bit of a stretch, though the 
device receiving the publish is free to do as it wishes.

I think Hadriel was suggesting some new event type and state model, 
crafted with this in mind. That might make things better, maybe not.

Either way, it wouldn't hurt to explore what the state model should be. 
(E.g. that it contains state of "transducers".)

	Thanks,
	Paul

---

From: Alan Johnston <[email-masked]>
Date: Fri, 24 Jun 2011 09:08:34 -0500

Gonzalo,

I believe that this work is definitely within the realm of SIP.  I
disagree that this is about device control, it is about a peer-to-peer
approach for third party call and session control.  We already have an
ability to do most of these things using 3PCC, but this is a state
heavy approach that requires B2BUAs that break many of the
peer-to-peer capabilities of SIP.

As for the scope, I think the scope should be exactly that is
specified in the draft:  a limited set of actions that are relevant to
SIP User Agent for call control and session control.  Any extensions
to the mechanism should be limited to this general area and require a
standards track specification which will ensure that it will be
extended to become general device control, unless there is IETF
consensus to do so.

This work is needed for the SPLICES working group, and we at Avaya
plan to implement it for other applications as well.  The fact that
there are proprietary and non-SIP approaches to this should not
prevent us from doing so in SIP.

And finally, we have shown that there is a community who is interested
in developing and deploying this from discussions in DISPATCH and in
SPLICES.  This approach has also been discussed over many years in
SIPPING and BLISS.  Lets just get on with the work and see what the
working group can come up with!

- Alan -

---

From: Alan Johnston <[email-masked]>
Date: Fri, 24 Jun 2011 09:55:39 -0500

Cullen,

I don't think it is too late to standardize this.  I agree that there
are a number of proprietary implementations out there, and some of
those happened because earlier attempts to standardize in the IETF
this were summarily blocked.

There is still lots of new SIP development going on.  And some
existing players, such as Avaya, have new development planned that
will utilize this.

Also, I don't think any of the proprietary approaches will be good
enough for SPLICES, at least the ones that I've seen - they are all an
ugly mess, which is what happens when specs are written without the
benefit of IETF feedback and consensus.

It is late - very late, but not too late.

- Alan -

---

From: Cullen Jennings <[email-masked]>
Date: Fri, 24 Jun 2011 09:29:53 -0600

I agree. There are some projects at Cisco that will use this is we can agree on something. The amount of work going on around using devices with better user interfaces for input, such as tablets, to work in conjunction with devices with better audio / video user interfaces makes this very relevant.

---

From: Hadriel Kaplan <[email-masked]>
Date: Fri, 24 Jun 2011 11:47:50 -0400

> For example, a proxy application that is in the signaling path is aware of the state of the Controlled device, so it does not need to subscribe to anything.

I was only pointing out one can use SUB/NOT to learn it if one needs to learn it.  If you don't need to learn anything before issuing a command, that's fine. (personally I wouldn't rely on a Proxy to know the state of a UA by the messages that Proxy happens to forward, but to each his own)

> Your proposal seems to overload and change the meaning of the PUBLISH request.

No it doesn't overload it.  It uses it for an application no one has used it for before, maybe, but SIP methods are not one-method-per-use-case.  

I think one could argue it either way.  If you *want* to define a new method and headers and such, then you could argue PUBLISH is wrong... but if you want to not have to change SIP just to do this thing then I think it's not too hard to describe how PUBLISH is right.  This is all just legal academic posturing anyway; I think it's pretty clear there's nothing actually broken with using a PUBLISH to do this in practice. (ie, it won't screw up SIP the protocol, UAs, proxies, b2buas, deployments, etc.)

-hadriel

---

From: "Shekh-Yusef, Rifaat (Rifaat)" <[email-masked]>
Date: Fri, 24 Jun 2011 12:27:27 -0400

> If you *want* to define a new method and headers and such, then you could argue PUBLISH is wrong...

:)
Just as a reminder, take a look at the following link:
https://datatracker.ietf.org/doc/draft-yusef-dispatch-action-ref/
This was our first proposal, to use REFER; we introduced INVOKE after the discussion in SPLICES meeting and the concerns around overloading the REFER method, which is already heavily overloaded.

No one of the authors of these two draft really "*want* to define a new method".
What we really want is to define a proper mechanism for invoking actions on a UA.

Regards,
 Rifaat

> From: Hadriel Kaplan [mailto:[email-masked]]
> Sent: Friday, June 24, 2011 11:48 AM
> To: Shekh-Yusef, Rifaat (Rifaat)
> Cc: Gonzalo Camarillo; [email-masked]
> > For example, a proxy application that is in the signaling path is aware of
> the state of the Controlled device, so it does not need to subscribe to
> anything.
> 
> I was only pointing out one can use SUB/NOT to learn it if one needs to learn
> it.  If you don't need to learn anything before issuing a command, that's
> fine. (personally I wouldn't rely on a Proxy to know the state of a UA by the
> messages that Proxy happens to forward, but to each his own)
> 
> 
> No it doesn't overload it.  It uses it for an application no one has used it
> for before, maybe, but SIP methods are not one-method-per-use-case.
> 
> I think one could argue it either way.  If you *want* to define a new method
> and headers and such, then you could argue PUBLISH is wrong... but if you want
> to not have to change SIP just to do this thing then I think it's not too hard
> to describe how PUBLISH is right.  This is all just legal academic posturing
> anyway; I think it's pretty clear there's nothing actually broken with using a
> PUBLISH to do this in practice. (ie, it won't screw up SIP the protocol, UAs,
> proxies, b2buas, deployments, etc.)
> 
> -hadriel

---

From: Hadriel Kaplan <[email-masked]>
Date: Fri, 24 Jun 2011 12:40:12 -0400

It's not overloading or changing the meaning of a "plain" PUBLISH.  PUBLISH is basically just SIP's version of HTTP's POST request.  It's purposefully generic to begin with, with the event-type defining its specific use.  It's only "meaning" is that the request is for pushing event state on the server its targeted at for the event-type its for.  This use-case does not change that meaning of a PUBLISH method.

It especially does NOT need a new header.  The only time SUB/NOT/PUB need new SIP headers is when the SIP protocol behavior is actually changed, or maybe if it's a change that applies to all event types.  Using a PUBLISH to push commands in no way changes the underlying behavior or semantics of the SIP protocol layer for the PUBLISH message itself.

Here's one way of describing it to be legal: when you "command" another UA to do something, you are in effect pushing state/event changes of your internal representation of a virtual UA.  In other words, when Alice-UA tells Bob-UA to terminate a call, Alice-UA has an internal representation of another UA named "Bob" which Alice is changing the state of to 'terminated'.  Alice-UA then pushes that state change to a server using a PUBLISH.  The fact that the server happens to be Bob-UA and uses the pushed state to modify its own internal state/behavior doesn't change the method type that Alice-UA can use to push the state.

-hadriel "sneaky defense lawyer" kaplan

---

From: Adam Roach <[email-masked]>
Date: Fri, 24 Jun 2011 12:34:22 -0500

On 6/24/11 11:40 AM, Hadriel Kaplan wrote:
> It's not overloading or changing the meaning of a "plain" PUBLISH.  PUBLISH is basically just SIP's version of HTTP's POST request.

That's a pretty bad analogy -- POST is used for arbitrary 
application-specified data.

PUBLISH is used to update a specific kind of information in a specific 
way with well-defined semantics. It can't be used for conveying 
arbitrary information. Perhaps you've confused it with INFO?

Due to this behavior (PUBLISH updates a specific set of subscribable 
state), PUBLISH is far more like HTTP's "PUT" than it is "POST."

/a

---

From: Alan Johnston <[email-masked]>
Date: Fri, 24 Jun 2011 12:58:34 -0500

I agree with Adam - overloading/changing PUBLISH this way wouldn't be good.

I think the closest SIP primitive would be REFER.  In fact, if you
read RFC 3515, it shows a UA receiving a REFER then doing "whatever",
which is pretty close to this!  ;-)

However, these days REFER is really only used for call transfer, and
that is quite different from what we are proposing here.  That is why
we define a new SIP method to avoid overloading REFER.

- Alan -

On Fri, Jun 24, 2011 at 12:34 PM, Adam Roach <[email-masked]> wrote:
>> It's not overloading or changing the meaning of a "plain" PUBLISH.
>>  PUBLISH is basically just SIP's version of HTTP's POST request.
>
> PUBLISH is used to update a specific kind of information in a specific way
> with well-defined semantics. It can't be used for conveying arbitrary
> information. Perhaps you've confused it with INFO?
>
> Due to this behavior (PUBLISH updates a specific set of subscribable state),
> PUBLISH is far more like HTTP's "PUT" than it is "POST."
>
> /a

---

From: "Worley, Dale R (Dale)" <[email-masked]>
Date: Fri, 24 Jun 2011 14:30:07 -0400

> From: Hadriel Kaplan [[email-masked]]
> 
> If you *want* to define a new method and headers and such, then you
> could argue PUBLISH is wrong... but if you want to not have to change
> SIP just to do this thing then I think it's not too hard to describe
> how PUBLISH is right.

How is it that adding a new method is somehow "changing SIP" but
overloading an existing method with a new purpose is not "changing
SIP"?

In either case, the application code that implements the new
functionality will have to be written.  And border elements will have
to be configured to discern and filter the requests that invoke the
new functionality.

The only real difference is that when we overload two functions onto
one method, we risk that elements won't be able to reliably
distinguish which functionality is intended, causing operational
failures and security problems.

Dale

---

From: Dan York <[email-masked]>
Date: Fri, 24 Jun 2011 14:41:05 -0400

Definitely agree here... let's try to make SIP *simpler* instead of adding more complexity.  Adding another primitive is, to me, far simpler than overloading an existing primitive. 

With a new primitive, a SIP endpoint either supports it or it doesn't.  
With an existing primitive, we get into "well, the endpoint supports the FOO primitive, but not the use case of FOO as a xxxxxxx".   And that gets way too messy.

My 2 cents,
Dan

P.S. And please, please, please forget Alan even mentioned REFER here... it's hard enough getting people to support REFER with its current definition... we don't need more definitions!  :-)

-- 
Dan York, CISSP, Director of Conversations
Voxeo Corporation   http://www.voxeo.com  [email-masked]
Phone: +1-407-455-5859  skype: danyork  sip:[email-masked]

Join the Voxeo conversation:
Blogs: http://blogs.voxeo.com
Twitter: http://twitter.com/voxeo  http://twitter.com/danyork
Facebook: http://www.facebook.com/voxeo

---

From: "Worley, Dale R (Dale)" <[email-masked]>
Date: Fri, 24 Jun 2011 14:50:54 -0400

> From: Shekh-Yusef, Rifaat (Rifaat) [[email-masked]]
> 

*If* the proxy is dialog-stateful, which makes it difficult for
several proxies to load-balance each other on a request-by-request
basis.

> manipulate the state of a dialog.

Using PUBLISH would be incorrect in two ways:

One problem is that PUBLISH is intended for the UAC to publish *its*
state.  The recipient then consumes this state, possibly for
redistribution to other recipients.

The other problem is that PUBLISH is for publishing *state*, where --
by definition -- what is important is the *current* state value, not
the transitions by which the state value got to the current value.
One particular consequence of this is that if the UAC sends several
successive PUBLISHes to a recipient that fail, then if it sends *one*
successful PUBLISH (containing "full state"), *that suffices* to put
the recipient into the proper state.

In contrast, most people model CTI mechanisms as RPCs, in which each
request/response cycle has unlimited consequences.  And as such, a
"catch up" operation can only be done by re-executing, in sequence,
every failed operation.

Now it is possible to design a CTI mechanism that is truly a set of
state variables, but few designers understand the need or would get it
right.  In particular, the case of "Initiate two separate calls to +1
800 555 1212 that overlap in time" has a 90%+ chance of failing when
attempted using the mechanism of any -01 draft.  (After all, we got in
wrong in RFC 2543.)

Dale

---

From: "Mike Hammer (hmmr)" <[email-masked]>
Date: Fri, 24 Jun 2011 14:26:18 -0500

Alan,

Your statement is correct if you are still wanting N !=1 SIP UAs in the picture.

If you go for a single UA solution that binds multiple devices into one endpoint, then it is a different story.

This sounds like a 4 blind men and one elephant discussion, since multiple models might exist.

Mike

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Alan Johnston
Sent: Friday, June 24, 2011 1:59 PM
To: Adam Roach
Cc: [email-masked]
Subject: Re: [RAI] Device control using SIP

- Alan -

---

From: Hadriel Kaplan <[email-masked]>
Date: Fri, 24 Jun 2011 15:33:15 -0400

> state), PUBLISH is far more like HTTP's "PUT" than it is "POST."

Well I didn't mean it as an exact analogy, but in the sense that it's pushing application-specific data... just with the application specifics being defined by the event package (which is different than POST obviously).

Afaik, PUT is similar to POST but for the resource of the request-uri. (or so RFC 2616 says)

Yes, PUBLISH creates subscribe-able state, but that's quite reasonable for this use-case.

-hadriel

---

From: Hadriel Kaplan <[email-masked]>
Date: Fri, 24 Jun 2011 15:38:07 -0400

> overloading an existing method with a new purpose is not "changing

If you don't think creating a new method is a bigger change than using an existing one for an arguably similar purpose, then we'll just have to disagree on that. :)
We can argue about whether PUBLISH is legit or not, but doing a new method is a big deal these days, in my opinion.

> failures and security problems.

If you describe it as "overloading two functions onto one method", then of course it sounds bad.  I'm arguing we're not doing that.  The "function" defined for a PUBLISH method is semantically appropriate if you carefully define how this use-case works.

-hadriel

---

From: Hadriel Kaplan <[email-masked]>
Date: Fri, 24 Jun 2011 15:43:00 -0400

> With an existing primitive, we get into "well, the endpoint supports the FOO primitive, but not the use case of FOO as a xxxxxxx".   And that gets way too messy.

I concur... who wouldn't concur with make it simpler. :)
Luckily, what I'm proposing is not to overload a primitive.  The primitive for PUBLISH stays the same.  I'm proposing this use-case define a new event package.
As for the ability to indicate support, luckily event packages have that with the Allow-Events header.

-hadriel

---

From: "Worley, Dale R (Dale)" <[email-masked]>
Date: Fri, 24 Jun 2011 15:43:29 -0400

> If you don't think creating a new method is a bigger change than using
> an existing one for an arguably similar purpose, then we'll just have
> to disagree on that. :)  We can argue about whether PUBLISH is legit
> or not, but doing a new method is a big deal these days, in my
> opinion.

It may be true that adding a method is much harder in practice, but that's
a different matter than what you stated, which was to imply that as long as
a new method or header wasn't added, that it wasn't "changing SIP".

Indeed, if there are reasons of practical implementation why one should be
preferred over the other, it would be valuable if you would explicate them.

But let us not confuse practical difficulties with architectural uncleanness.

Dale

---

From: "Worley, Dale R (Dale)" <[email-masked]>
Date: Fri, 24 Jun 2011 15:49:29 -0400

________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Hadriel Kaplan [[email-masked]]

Do you believe that you can define such an event package that would work properly?  That is, it has a proper state-variable model, and yet can handle the operations we desire?

Not to mention the fact that the UAC of the PUBLISH would not be publishing *its* state, but what it wants the UAS's state *to be*.

Dale

---

From: "Mike Hammer (hmmr)" <[email-masked]>
Date: Fri, 24 Jun 2011 15:01:26 -0500

Ummm...

Subscribe: to media info
Notify: of media capabilities and IP address to use

Subscribe: to device control: seize
Notify:  Under your command (locked to one at a time)

Subscriber UA does SIP session control using IP and media capabilities
learned from device.

Notify: media state: receiving media (or vice versa sending if a camera
instead of HD screen)

Notify: media state: not receiving media

Subscribe: to device control: release
Notify:  Device publicly available now

Who needs refer or CTI or a second UA in this picture?

Mike

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Worley, Dale R (Dale)
Sent: Friday, June 24, 2011 3:49 PM
To: Hadriel Kaplan; Dan York
Cc: [email-masked]
Subject: Re: [RAI] Device control using SIP

________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Hadriel
Kaplan [[email-masked]]

Luckily, what I'm proposing is not to overload a primitive.  The
primitive for PUBLISH stays the same.  I'm proposing this use-case
define a new event package.
_______________________________________________

Do you believe that you can define such an event package that would work
properly?  That is, it has a proper state-variable model, and yet can
handle the operations we desire?

Not to mention the fact that the UAC of the PUBLISH would not be
publishing *its* state, but what it wants the UAS's state *to be*.

Dale

---

From: "Kevin P. Fleming" <[email-masked]>
Date: Fri, 24 Jun 2011 15:04:27 -0500

> the recipient into the proper state.

The term for this is 'idempotent'. A PUBLISH request including 'full 
state' for the associated event-package is idempotent (as is a NOTIFY 
containing 'full state'). As you stated in the rest of your reply, what 
is being proposed here is far from that.

Thus ends this Friday's random vocabulary lesson.

-- 
Kevin P. Fleming
Digium, Inc. | Director of Software Technologies
Jabber: [email-masked] | SIP: [email-masked] | Skype: kpfleming
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
Check us out at www.digium.com & www.asterisk.org

---

From: Hadriel Kaplan <[email-masked]>
Date: Fri, 24 Jun 2011 16:04:39 -0400

> redistribution to other recipients.

See my message on one way to describe this:
http://www.ietf.org/mail-archive/web/rai/current/msg01085.html

> attempted using the mechanism of any -01 draft.  (After all, we got in

That issue is true regardless of the method or means by which we do this.  Whether it's two INVOKE requests to initiate two separate calls, or two "<dialog state='calling'>" elements in an XML body of a PUBLISH... both the spec and developers need to account for it.

-hadriel

---

From: "Worley, Dale R (Dale)" <[email-masked]>
Date: Fri, 24 Jun 2011 16:13:05 -0400

> http://www.ietf.org/mail-archive/web/rai/current/msg01085.html

Eh?  The one where you say that PUBLISH is equivalent to HTTP POST?
But it's not -- POST allows arbitrary semantics in the server; in
particular, if a second POST is done, the resulting state in the
server is not necessarily independent of the first POST.

> That issue is true regardless of the method or means by which we do
> this.  Whether it's two INVOKE requests to initiate two separate
> calls, or two "<dialog state='calling'>" elements in an XML body of a
> PUBLISH... both the spec and developers need to account for it.

The issue is true, but the chances of the spec being wrong are
increased by a factor of 100 or so.

Dale

---

From: "Worley, Dale R (Dale)" <[email-masked]>
Date: Fri, 24 Jun 2011 16:16:50 -0400

________________________________________
From: [email-masked] [[email-masked]] On Behalf Of Kevin P. Fleming [[email-masked]]

Actually, it's stronger than idempotent -- a full-state PUBLISH leaves the
recipient in one particular state, independently of *any* preceding PUBLISHes.

Dale

---

From: Hadriel Kaplan <[email-masked]>
Date: Fri, 24 Jun 2011 16:56:28 -0400

> server is not necessarily independent of the first POST.

No, you know that's not the part of the message I was referring to.  Are you just being belligerent? 

> increased by a factor of 100 or so.

A factor of 100 or so?  I'm amazed by your ability to determine the actual probability value of these things.  Is there an app for that? ;)

-hadriel

---

From: Hadriel Kaplan <[email-masked]>
Date: Fri, 24 Jun 2011 16:59:08 -0400

> Do you believe that you can define such an event package that would work properly?  That is, it has a proper state-variable model, and yet can handle the operations we desire?

Heck no - this isn't *my* draft or use-case.  I don't even really care about this use-case.  I just don't think we need to go create more methods and headers to handle it.

-hadriel

---

From: Hadriel Kaplan <[email-masked]>
Date: Fri, 24 Jun 2011 16:59:44 -0400

> a new method or header wasn't added, that it wasn't "changing SIP".

Where did I say that??
I said: "The only time SUB/NOT/PUB need new SIP headers is when the SIP protocol behavior is actually changed, or maybe if it's a change that applies to all event types."

I implied this use-case did not need to change the SIP protocol.  Are you implying it does?

> But let us not confuse practical difficulties with architectural uncleanness.

On the contrary - I would argue having to create a new SIP Header or Method for every new use-case is architecturally unclean.

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?

-hadriel

---

From: Adam Roach <[email-masked]>
Date: Fri, 24 Jun 2011 16:53:46 -0500

> Yes, PUBLISH creates subscribe-able state, but that's quite reasonable for this use-case.

The problem is that the only mechanism for doing this within the model 
that PUBLISH provides is to use PUBLISH to say "Here's the state that I 
would like the call to assume. Now, you figure out how to manipulate the 
call until it resembles that state."

The first foray into a solution for XCON tried to take this approach. We 
had to scrap it and start over once people tried -- and utterly failed 
-- to actually implement it. The problem is that this approach just 
can't be made to work. Ignoring the fact that you can't always get from 
the current state to the "new" state suggested by the client, it is a 
computationally intractable problem to figure out what actual 
manipulations need to take place to get from an arbitrary call state A 
to an arbitrary call state B.

What you really *want* is some kind of action-based approach, rather 
than a state-based approach. And you can't use PUBLISH for that without 
changing its fundamental semantics.

/a

---

From: "Worley, Dale R (Dale)" <[email-masked]>
Date: Mon, 27 Jun 2011 16:15:11 -0400

> A factor of 100 or so?  I'm amazed by your ability to determine the
> actual probability value of these things.

Yes, I *am* being belligerent.

But I have an actual point, too.

I'm trained as a mathematician.  Due to that, I've got a very sharp
sense for formal models, and how particular problems or algorithms can
be be fitted into models, and especially, to detect when someone's
attempt to do such a fitting fails.

I have noticed over the years that software people are rather bad at
fitting problems into models, and when they attempt to fit a problem
into a model that is not highly flexible, they fail almost 100% of the
time.

(Which is where the "factor of 100 or so" comes from:  Any decent
programmer can specify an RPC mechanism -- the success rate is nearly
100%.  State-variable models have a failure rate of nearly 100%.)

An example in SIP is the deep irregularity of the use of Supported and
Require, which in many cases are not just carrying information about
which UAs support which features (which is what is claimed by RFC
3261), but trigger specific normatively-required processing of
requests.

Another example is the dialog event package, which is not strictly
state information (since terminated dialogs are supposed to be
notified as "terminated" before they disappear from the state).  But
that situation is rescued by a cheat:  We don't really care if the
subscriber is told overtly of the termination of a dialog or only
implicitly by its vanishing from the state.

Or the comparison of SIP PUBLISH with HTTP methods:  PUBLISH has some
semantic similarity with PUT, but not with POST.  (RFC 2616 sections
9.5 and 9.6 say that two PUTs in a row should leave only the effect of
the second PUT, whereas two POSTs in a row will leave the effect of
both (indeed, that two POSTs are nearly commutative).)

Or as Adam Roach mentioned, XCON attempted to implement call
manipulation in a state-change model, and failed -- if not in theory,
then implementers failed to implement it successfully.

Now we *do* have a practical problem on our hands, and it needs a
solution.  One proposal to solve the problem is to do device control
using PUBLISH.  This requires that the system of state information we
device must fit within the model permitted to PUBLISH.

Based on history, I predict that this effort has a high likelihood of
failing, in the sense of "A solution will be adopted, but it will not
be within the PUBLISH model.  Few software people will notice this.
Many difficulties in practice will result from this."

Or, to be a bit egotistical, I predict that if I am not involved in
the effort, it has a high likelihood of failing, but if I am deeply
involved in creating the model, there is some chance of success.  (It
still could fail because the desired behavior is inherently
un-expressible within the model we choose, and there's no way I can
get around that.)

This runs up against two requirements that I have:
    1. The solution should work correctly within the rules of SIP.
    2. I don't do the work of getting the solution right.

I *am* being snarky.  But the "challenge" I am throwing at you
rhetorically is actually a correct description of the *human* problem
to be solved:  If you (or someone) is prepared to do the work to
*properly* fit the device control semantics into a state-variable
model, then you've proven that we can define the use of PUBLISH to
solve the problem.

That is, I'm trying to goad you into saying, "You say it can't be
done, huh?  I'll show you!  I'll do it exactly right, and you'll have
to admit that I did it right!" -- rather than discussing the use of
PUBLISH in the abstract, and leaving it implicit that somebody out
there can and will get it right (which they won't).

Which would solve the problem.

> Is there an app for that?

Yes -- study mathematics for >= 8 years, then watch the IETF for >= 5
years, cringing at the sloppiness with which *everything* is defined
and analyzed.

Dale

---

From: Peter Musgrave <[email-masked]>
Date: Tue, 28 Jun 2011 18:29:47 -0400

Hey y'all,

Let me see if I can interpret this in a way my theoretical physics type
brain can handle (never had the patience for all that rigor!).

XCON taught us target states are bad.

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? In
normal circumstances you would send the action, the UA would be in the state
you were told by a dialog-event and life is good. If it has moved on, then
the action is an event into whatever state it is in when the event arrives
(or I suppose you could say apply event only if you really are in the state
you told me you were in). I can still see some flaws in this approach but is
it a workable paradigm? (Physicists love paradigms).

Cheers,

Peter

---

From: Adam Roach <[email-masked]>
Date: Tue, 28 Jun 2011 21:10:40 -0500

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

---

From: Alan Johnston <[email-masked]>
Date: Tue, 28 Jun 2011 21:57:18 -0500

I don't see what the big fuss is about.  Yes, there are lots of ways
you could do this, and you could tunnel it over any protocol.  No one
is forced to use this - if it doesn't work for your environment, then
don't use it.

But there are environments where this does make sense - there is an
existence proof of about 4 other proprietary approaches that use SIP.
And, they are all pretty lame, having had no IETF or working group
review.

We would like to standardize a peer-to-peer, lightly coupled remote
call control extension for SIP.  We could even do this today just
using REFER without any extensions at all, but it wouldn't really be
interoperable, and wouldn't be as good.

I look forward to getting back to the work of solving the problem
SPLICES was chartered to do, and to do it we will need this type of
remote call control capability.

- Alan -

On Tue, Jun 28, 2011 at 9:10 PM, Adam Roach <[email-masked]> wrote:
>> 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

---

From: "Mike Hammer (hmmr)" <[email-masked]>
Date: Wed, 29 Jun 2011 08:46:57 -0500

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

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

---

From: Cullen Jennings <[email-masked]>
Date: Wed, 29 Jun 2011 11:23:55 -0600

> call. So, it somewhat relates to both call and device control.

SIP refer allows one device to tell another to make a phone call. So if we take this point of view then there is already IETF consensus that SIP is used for device control.

---

From: Adam Roach <[email-masked]>
Date: Wed, 29 Jun 2011 13:59:30 -0500

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:

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

 2. 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:
> using extensions to HTTP, SMTP, IMAP, FTP, MSRP, XMPP, BXXP, or<name

---

From: Mary Barnes <[email-masked]>
Date: Wed, 29 Jun 2011 14:27:40 -0500

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:

>    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*.
>
>    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).
>
> From: [email-masked] [mailto:[email-masked] <[email-masked]>] On Behalf Of
> Adam Roach
> RAI mailing [email-masked]://www.ietf.org/mailman/listinfo/rai
>
>
>

---

From: "Hutton, Andrew" <[email-masked]>
Date: Wed, 29 Jun 2011 21:41:54 +0200

See below

> Alan Johnston
> Sent: 29 June 2011 03:57

[AndyH] - Getting the right architectural solution is important we don't want multiple competing IETF solutions for the same thing which is what happens if we get it wrong. This causes confusion and wasted time and money hence the fuss.

> And, they are all pretty lame, having had no IETF or working group

[AndyH] - I am aware of a number of approaches but apart from the REFER based mechanism non of them use SIP except as a transport for an XML body. 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. 

What existing SIP based mechanism are you referring to other than REFER?

> remote call control capability.

It might be a minor point but the SPLICES explicitly states that the WG will not create new mechanism and this is what we got consensus for so it does need to be re-chartered.

I am not against doing some standardisation in this area but do think we need to better understand the scope of the requirements and solution architecture.

> dialog

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 29 Jun 2011 15:51:11 -0400

I'm picking a random message in this thread to reply to.

ISTM we have gotten way too far into the weeds on this.
I think we can and should scope out better what we mean my device 
control before we get too involved in *how* to signal the device control.

The dialog event package has a state model for devices that encompasses 
the possibility that a device might be involved in multiple dialogs.

*Some* of the actions being discussed fit with just that state:
e.g. rejecting an incoming call.

*Most* of the actions imply additional state, such as various 
transducers (e.g. handset, headset, "speakerphone" mic and speaker, 
local display, mixers, maybe some lights and buttons), perhaps an 
implied URL for a music on hold server, etc. The actions then depend 
upon and manipulate this state. E.g.

- answering a call implies not only sip signaling to complete an
   early dialog, but also associating streams in that dialog with
   particular transducers, or with streams in some other dialog
   with a subordinate device.

- putting call on hold may involve dissociating some transducers
   from streams in a dialog, and then maybe acting as a b2bua to
   link those streams to another dialog with a music on hold url.

Carrying out these actions implies transitions in this expanded state 
model. I don't see how we can meaningfully define the actions without this.

(I'm not saying that the above sketch of an expanded state model is 
*correct*. Its just an example. It may be that we can find a simpler one 
that is sufficient for our purposes.)

If we can define a suitable state model, and actions based on 
transitions in this state model, *then* we will have a good foundation 
for deciding on a mechanism for signaling those actions.

The state model then also bounds the scope of actions that can 
meaningfully defined.

	Thanks,
	Paul

---

From: Adam Roach <[email-masked]>
Date: Wed, 29 Jun 2011 17:10:34 -0500

> And, they are all pretty lame, having had no IETF or working group

Certainly you recognize the irony of justifying an architecture by 
saying that certain people have already done it,and then pointing out 
that these same people got it wrong.

I would argue that the lack of IETF input is precisely *why* they chose 
to squirrel this information away inside SIP messages. This misuse of 
SIP is quite integral to the list of reasons that the approaches are, as 
you put it, "lame."

/a

---

From: "Mike Hammer (hmmr)" <[email-masked]>
Date: Wed, 29 Jun 2011 21:03:00 -0500

Adam,

I try to read through all comments on a thread before commenting and
responding to the latest message in some cases.  If so, I may have
mis-attributed a view to you.  So, if you have not disagreement with my
statement, then perhaps we are more in sync than dissonant.

My main concern was the implication in some of the comments that the
only approach involves "device control" that leads to multiple SIP
sessions from a multiplicity of devices, where I am suggesting that a
single SIP session (dialog) can manage multiple media paths which seem
to be serving one end-user.

Anyway, although I believe in lessons learned, I don't want to put too
much weight in past failures.  Extrapolation is a tricky thing.

Mike

From: Adam Roach [mailto:[email-masked]] 
Sent: Wednesday, June 29, 2011 3:00 PM
To: Mike Hammer (hmmr)
Cc: Peter Musgrave; [email-masked]
Subject: Re: [RAI] Device control using SIP

Mike:

1.	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*.
2.	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.

Can you clarify?

/a

Adam,

 
Mike

-----Original Message-----

	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?

 

 
/a

---

From: Adam Roach <[email-masked]>
Date: Wed, 29 Jun 2011 21:45:10 -0500

> 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

---

From: Alan Johnston <[email-masked]>
Date: Thu, 30 Jun 2011 10:03:41 -0500

On Wed, Jun 29, 2011 at 5:10 PM, Adam Roach <[email-masked]> wrote:
> Certainly you recognize the irony of justifying an architecture by saying
> that certain people have already done it,and then pointing out that these
> same people got it wrong.
>
> I would argue that the lack of IETF input is precisely *why* they chose to
> squirrel this information away inside SIP messages. This misuse of SIP is
> quite integral to the list of reasons that the approaches are, as you put
> it, "lame."

The other approaches aren't lame because they use SIP.  They are lame
because of the coverage, usage model, notifications, etc.

Given that we have already standardized REFER, I can't see how this is
a misuse of SIP, unless you believe REFER is a misuse.    Many of
things in this draft can already be done with REFER, and are in
certain deployments, but we need to fully specify it.  The other parts
do require standardization, and for them REFER isn't exactly the right
semantic.  I think this approach with a new method is an excellent
start to this work, and we should let SPLICES get on with it.

- Alan -

---

From: Adam Roach <[email-masked]>
Date: Thu, 30 Jun 2011 10:58:09 -0500

On 6/30/11 10:03 AM, Alan Johnston wrote:
> a misuse of SIP, unless you believe REFER is a misuse.

This is a different model altogether than REFER, and it has vastly 
different security properties. REFER is a for *me* to suggest an action 
to *your* device. And there are very few things that make sense for me 
to suggest to your device.

The scope being proposed here entails a far broader set of actions, most 
of which are nonsensical going from one user to another. It would, for 
example, be ridiculous for me to suggest to your device that it reject a 
call, put a call on hold, unmute the microphone, or activate a "do not 
disturb" mode. Those really are things that only make sense for *you* to 
tell your phone to do (hence requiring a different security model).

REFER goes between devices under the control of different users to 
communicate a small, limited set of operations. It was not designed to 
carry a wide variety of device-control primitives between devices under 
the control of the same user.

/a

---

From: Alan Johnston <[email-masked]>
Date: Thu, 30 Jun 2011 11:03:56 -0500

Adam,

This might be your interpretation of REFER, but I doubt you can find
normative language in RFC 3515 that supports your statements below.

However, the current proposal does use a different method, as it is
different from the common usages of REFER, so this discussion is
fairly academic.  Having a different method allows for different
policies and security models.

- Alan -

On Thu, Jun 30, 2011 at 10:58 AM, Adam Roach <[email-masked]> wrote:
>> Given that we have already standardized REFER, I can't see how this is a
>> misuse of SIP, unless you believe REFER is a misuse.
>
> This is a different model altogether than REFER, and it has vastly different
> security properties. REFER is a for *me* to suggest an action to *your*
> device. And there are very few things that make sense for me to suggest to
> your device.
>
> The scope being proposed here entails a far broader set of actions, most of
> which are nonsensical going from one user to another. It would, for example,
> be ridiculous for me to suggest to your device that it reject a call, put a
> call on hold, unmute the microphone, or activate a "do not disturb" mode.
> Those really are things that only make sense for *you* to tell your phone to
> do (hence requiring a different security model).
>
> communicate a small, limited set of operations. It was not designed to carry
> a wide variety of device-control primitives between devices under the
> control of the same user.
>
> /a
>

---

From: "Mike Hammer (hmmr)" <[email-masked]>
Date: Thu, 30 Jun 2011 11:40:48 -0500

Understand your logic, but I don't think that matches what I was
thinking was needed.

It is more like two separate state machines (controller and controllee
devices), 

with one able to take actions that affect the other, 

and the controllee reporting its *current* state to the controlling
entity.

And, no hidden states.

So, some differences there.  Also realize that one could argue that the
combination 

of the two is a state machine, but that is where system design (system
being the network 

and not a box) works to avoid such deadlocks.  If that was not possible,

then the PSTN would have never worked. J

Anyway, don't want to drill down in this thread on a solution.

And do recognize we talk around different ideas, so not really in
conflict.

Mike

From: Adam Roach [mailto:[email-masked]] 
Sent: Wednesday, June 29, 2011 10:45 PM
To: Mike Hammer (hmmr)
Cc: Peter Musgrave; [email-masked]
Subject: Re: [RAI] Device control using SIP

I understand.

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

/a

---

From: "Shekh-Yusef, Rifaat (Rifaat)" <[email-masked]>
Date: Thu, 30 Jun 2011 13:50:01 -0400

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Adam Roach
> It would, for example, be ridiculous for me to suggest to your device that it reject a
> call, put a call on hold, unmute the microphone, or activate a "do not disturb" mode.

Why would it be ok for your device to ask my device to terminate a call, but it would be ridiculous for your device to ask my device to reject a call?

Regards,
 Rifaat