Subject: RE: [SIP] Comment on draft-moyer-sip-appliances-framework-00.txt

From: Stan Moyer <[email-masked]>
Date: Thu, 03 Aug 2000 11:53:05 -0400

At 02:38 PM 8/2/2000 -0700, Fox, Mike wrote:
>The temptation to extend or use the "message" capability of SIP may become a
>problem for all SIP devices to represent the message to the user. I would
>think it far more compatible to start a SIP session and initiate a RTP audio
>stream to deliver the audio message "FYI the house is too cold, the windows
>are open, and it is snowing inside." when you are contacted via a SIP PSTN
>gateway at your hotel in sunny Jamaica. And to deliver the message as text
>to your pager, if instead you were hiking in the Rockies.

I agree this is desirable and is easily supported if the device only needs 
to support SIP (plus RTP) to send either type of message. If a different 
protocol is required to send a text page that is an additional requirement 
on the device. While it's not difficult to have a PC (or even a PDA) 
support multiple protocols, we're looking at low-cost consumer devices 
where very extra bit of RAM is going to increase the cost to the consumer.

>  It seems that with
>SDP this is already worked out by the session UAs, where as the message
>scheme requires the destination UA to provide "message translation" so that
>the message can be presented to the user by the interface device.

The message translation is only for devices that don't communicate with SIP 
(or one of the media protocols that SIP would initiate a session for, e.g. 
RTP). The translation is "mandatory" because that is the only way to 
communicate with a device.

>  I think
>the logic of session initiation consistently extends to initiating device
>control and RPC protocols with SIP, rather than putting these into SIP.

In many cases we only desire to send a simple command to a device (e.g., 
"Turn off the coffee pot") and in that case, setting up a session with SIP 
to send an RPC is a lot of overhead (plus requires two protocols -- SIP and 
the RPC).

-Stan

>My $0000.02
>
>Mike Fox
>
>
>_______________________________________________
>SIP mailing list
>[email-masked]
>http://lists.bell-labs.com/mailman/listinfo/sip

_______________________________________________
SIP mailing list
[email-masked]
http://lists.bell-labs.com/mailman/listinfo/sip

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 03 Aug 2000 14:23:52 -0400

> where very extra bit of RAM is going to increase the cost to the consumer.

I think that MESSAGE is definitely not appropriate for what you are
trying to do. It is along the same lines of the continued abuse of INFO,
whereby totally different semantics are defined through the inclusion of
different bodies. MESSAGE means one thing and one thing only - "please
render this content for display to someone, and it represents a message
which may be responded to and is part of a conversation thread". Any
other usage is inappropriate. 

SIP is primarily appropriate when you wish to be involved in
communications with some entity which is moving around; where you have
only an abstract identifier that names this object (user@domain), and
based on that you need to rapidly contact that object at one of the many
places an instance of that object might be available. "involved in
communications" might mean initiating a session, asking for
notifications about changes in that objects communications states,
sending it an instant message. 

I am yet to be convinced that this application fits into that category.
Will my lightbulb be moving around? Will it be reachable at multiple
places? Doesn't seem like it. What, for example, is wrong with using
http for this? I can have a mini-web server that presents an interface
that I can use to control the lightbulb. The same architecture with
proxies and authentication and interworking units operates just fine
there.

-Jonathan R.

-- 
Jonathan D. Rosenberg                       72 Eagle Rock Ave.
Chief Scientist                             First Floor
dynamicsoft                                 East Hanover, NJ 07936
[email-masked]                     FAX:   (973) 952-5050
http://www.cs.columbia.edu/~jdrosen         PHONE: (732) 741-7244
http://www.dynamicsoft.com

---

From: "Simon Tsang (Telcordia Technologies)" <[email-masked]>
Date: Thu, 3 Aug 2000 16:42:19 -0400

Jonathan,

Please see my comments inserted into your message below:

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]On Behalf Of Jonathan Rosenberg
> Sent: Thursday, August 03, 2000 2:24 PM
> To: Stan Moyer
> Cc: Fox, Mike; [email-masked]; [email-masked];
> [email-masked]
> Subject: Re: [SIP] Comment ondraft-moyer-sip-appliances-framework-00.txt
>
OK.  I think there may have been a misunderstanding of what we're proposing
here.  What we are proposing is to use MESSAGE *only* to carry the
command/query/whatever between the communicating endpoints.  When MESSAGE
finally reaches the destination SIP UA, the body is extracted and passed to
the controlling application.  The SIP UA *is not involved* after MESSAGE is
received.  The architecture of this is illustrated by the following stacks:

 +-------+           +----------------------+
 |  GUI  |           | Appliance Controller |
 +-------+           +----------------------+
 +-------+           +-------+   +----------+         +----+
 | SIP UA+-----------+ SIP UA|   | X.10 unit+---------+Lamp|
 +-------+           +-------+   +----------+         +----+
         SIP message                         Control messages
        over IP (layer 3)                    over X.10 (layer 1)

SIP is used only to carry information on what to do with the lamp to the SIP
UA in the Appliance Controller.  It is then the Appl. Controller's job to
extract the control information and do something with it.  (In the example
above, it controls the lamp via an X.10 interface.)  I would say that this
does not affect the semantics of MESSAGE.  The receiving SIP UA treats the
incoming MESSAGE as if it were an instant message.  Once the MESSAGE is
received, the receiving UA extracts the message from the body and passes it
up to the controlling application (in this case, the Appliance Controller).
In fact, it may even be possible to demo the above scenario using a SIP
based IM system, and treat the Appliance controller as an IM user.

> places an instance of that object might be available. "involved in
Firstly, it is likely that Appliances will be moving around alot.  They'll
be going from home to hotel, home to home, home to conference venue, home to
car, home to bus etc.  OK, you're unlikely to move your refrigerator around
that much, but it's very likely that appliances such as the Internet Alarm
clock will be moved around (especially on business trips!).  So there will
be a great need to address them as they move between locations and domains.
Henning has already mentioned the possibility of 'naming' your appliances,
so that my kitchen stove could be [email-masked].  This reference can
then be added to your 'favourites' address book.    Using HTTP to do this
will require explicit addressing (like the SLP URL Stan showed in the
presentation yesterday) for every single request, and cannot support the
more friendly object@domain representation.

>What, for example, is wrong with using
For sure, we could set up a mini-web server in the home to control
appliances which stay in the home, but IMHO I don't think it's a viable (or
scalable approach) for appliances which are moving around alot.

Please feel free to shoot me down in flames if you think I'm way off the
mark here.

Cheers,
Simon

--
Simon Tsang (Ph.D)
Research Scientist
Telcordia Technologies (http://www.telcordia.com)

E-mail: [email-masked]
Phone: +1.973.829.4511   Fax: +1.973.829.5889

---

From: Stan Moyer <[email-masked]>
Date: Thu, 03 Aug 2000 17:27:00 -0400

Simon,

Good points -- I would also add the following comments (see below) to yours.

>received.  The architecture of this is illustrated by the following stacks:

Yes, and this is why we're proposing to use a new MIME type (DMP == Device 
Messaging Protocol) for the payload so that if an IM-based system got a 
message destined for a device, it wouldn't just try and render the content 
(since it would be an incompatible/unknown MIME type).

We discussed using a different message (instead of MESSAGE), but we decided 
that another message type with (what we thought were) very similar if not 
identical semantics would be too/more confusing.

>more friendly object@domain representation.

Actually, I'm not sure if I agree that most appliances will be moving 
around a lot, but we do have to allow for that possibility. We definitely 
need to use an abstract identifier because we can't assume that the details 
of device name/addresses in a home domain are known to entities in the wide 
area (outside the home domain). This is one of the reasons that http won't 
work.

>scalable approach) for appliances which are moving around alot.

In addition to the addressing problem mentioned above, for 
devices/appliances that don't need an intermediate appliance controller 
it's probably overkill to have a mini web-server. Plus that would only work 
for control, what mechanism would you use for events and steaming media 
(especially to the device)? We believe a common (SIP) infrastructure for 
all these communications paradigms is best.

-Stan

---

From: Jonathan Rosenberg <[email-masked]>
Date: Thu, 03 Aug 2000 23:36:14 -0400

"Simon Tsang (Telcordia Technologies)" wrote:
> does not affect the semantics of MESSAGE. 

Of course it does. You are not displaying them to a user for the purpose
of messaging and communications. If you are including content that has
semantic meaning to some upper layer system, its not a MESSAGE. Its
something else. MESSAGE does not just mean "deliver this to higher layer
protocol stack". It means a very specific thing - render this content to
the user, where this rendering is some kind of communication which might
be responded to. 

There is no shortage of method names. 

Another way to look at it is this; if you message were misrouted, and
sent to some other SIP UA, would the "right" thing happen? No, it would
not. With MESSAGE, the client will redner the content. 

> (since it would be an incompatible/unknown MIME type).

Thats really bad. Come one. If you use xml, its going to be
text/xml+dmp, in which case the IM client will likely render the xml.
You want to bank on the right thing happening by hoping the guys
messaging client is really strict and won't try to render your content?

There are no shortage of methods. There is no surcharge per letter or
anything. I promise.

> clock will be moved around (especially on business trips!). 

Most likely I'm the one moving it around. Why would I need wide area
access to my own alarm clocks? Seems like the devices I need wide area
access to are the ones I don't have with me to move around, i.e., the
ones pretty stable in my house (alarms, oven, fridge, lights, etc.).

I don't dispute that they might possibly in some cases move around, but
it doesn't seem like the typical case. Choosing a protocol just for
support of an unlikely case doesn't seem like the right thing to do.

 So there will
> more friendly object@domain representation.

Why isn't the addressing http://simon.home.net/stove? I can't add this
to my bookmarks? The addressing is just as explicit as in the SIP case.

-Jonathan R.

---

From: Stan Moyer <[email-masked]>
Date: Fri, 04 Aug 2000 10:50:46 -0400

>to my bookmarks? The addressing is just as explicit as in the SIP case.

How do you know that's the address? Why isn't it 
http://simon.home.net/cooker? or http://simon.home.net/grill? Or maybe you 
know the name, but how do others know? We need a standard way to "search" 
for the correct service in the home -- access to devices/appliances in the 
home will not always be done by people, it could also be done by 
network-based services (I can give examples if you want). The SIP Proxy 
mechanism provides a convenient way to route the message to the correct 
(home) domain, where the more abstract address can then be resolved.

Also what's the address for subscribing for the event that the timer has 
gone off and my meal is done -- you probably can't (or at least shouldn't) 
use http for that?

So, I guess the answer is that, yes you could use http for some of the 
things you need to do with appliances, but it's not optimal for the whole 
problem space.

I would argue that the reasons you are arguing for convergence in the 
thread, "Re: [SIP] a proposal for a way to compromise? (really, not a 
joke)" , e.g.,

>...Let us not bypass the benefits afforded to users of the system. I think
>it is fair to say users will want to have services that integrate
>presence with voice, video, and other communications. Thats happening
>today. By using the same infrastructure for the two, some neat services
>become possible ...

are many of the same reasons you would want to use SIP for networked 
appliances/devices.

-Stan

Stan Moyer
Director, Internet Services Infrastructure Research
<[email-masked]>; Telcordia Technologies,
MCC-1A238R, 445 South Street, Morristown, NJ 07960-6438
voice: +1 973 829 4923; fax: +1 973 829 5889
http://www.argreenhouse.com/bios/stanm/

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 04 Aug 2000 11:26:08 -0400

> the user, where this rendering is some kind of communication which might

While I'm no fan of overloading names, I don't think it's quite as clear
cut as we'd like. Some considerations:

- It's bad if the same type of device (or the same name) gets two types
of messages with very different meaning. This doesn't seem likely in
this case.

- We already have different content for INVITE, distinguished by
Content-Disposition. It's a bit a matter of taste whether to use a
different Content-Disposition or a different message.  Thus, you
definitely need a different Content-Disposition, other than render.

- Having the same message makes sense if filtering, for example, would
likely be the same for both.

One could argue that a message being displayed to a user is just
electrons on phosphor. A message to a lightbulb is just a one-bit
phosphor. (After all, sending a MESSAGE to the Times Square news ticker
is nothing but turning on *lots* of lightbulbs... It's also likely to be
one-way.)

In this case, it's a matter of abstraction whether MESSAGE is taken as
only stuff that's text displayed to human users or more general.
Reasonable people can disagree, I believe. Do we need to apply a Turing
test to the recipient?

In summary, I think either a new message type or MESSAGE can be made to
work as long as the type of content is labeled clearly, not just in
terms of syntax but also semantics. If lots of people think it's
different enough and can describe the difference in some generic term
("MESSAGE is for messages for human consumption and is not expected to
have other consequences; generally two way", "CONTROL is for messages
for machine consumption that may trigger things, generally one-way"),
it's easier to just use another method name and be done with the
discussion.

> support of an unlikely case doesn't seem like the right thing to do.

I still don't understand the harm to SIP even if mobility is rare right
now (with suitable authentication, devices in cars may be quite usefully
be accessed remotely, e.g., for maintenance and diagnostic purposes).
Web clients are very hard to automate and script, so I don't see this as
a viable alternative in all cases.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 04 Aug 2000 17:09:22 -0400

Stan Moyer wrote:
> How do you know that's the address? 

How did you know the address was [email-masked]? The URL above is
merely a syntactic translation. Web servers act as fronts for data
stored, in fact, elsewhere. Same case here.

> gone off and my meal is done -- you probably can't (or at least shouldn't)

No, probably not. This debate is going on in another thread on the
sip-events list.

> are many of the same reasons you would want to use SIP for networked

I don't see the analogy. Presence, voice, video are all forms of
communications. Its reasonable to want to screen an IM from someone and
their phone calls at the same time. In what ways would I want services
which integrate me talking to my refrigerator and me controlling it?

-Jonathan R.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 04 Aug 2000 17:16:10 -0400

> of messages with very different meaning. This doesn't seem likely in

What about a TV which acts as a message center? When a MESSAGE arrives,
is it a message to be displayed to the person watching, or a control for
the device itself?

> definitely need a different Content-Disposition, other than render.

True, but in no case does the content of the message alter the
underlying semantics of the method or response code. It always provides
additional information that qualifies it. Here, its fundamentally
altering what happens to it.

> likely be the same for both.

These things serve much different functions. I think its likely you
would have very different policies for filtering them.

> terms of syntax but also semantics.

This introduces yet another place an implementation needs to look at to
figure out what the purpose of the message is. Method is for that
purpose. 

-Jonathan R.

---

From: "Simon Tsang (Telcordia Technologies)" <[email-masked]>
Date: Fri, 4 Aug 2000 21:00:11 -0400

Jonathan,

Please see my comments inserted below:

> From: Jonathan Rosenberg [mailto:[email-masked]]
> Sent: Friday, August 04, 2000 5:16 PM
> To: Henning Schulzrinne
> Cc: Simon Tsang (Telcordia Technologies); Stan Moyer; Fox, Mike;
> [email-masked]; [email-masked]
[some paragraphs snipped to save bytes]

> is it a message to be displayed to the person watching, or a control for
This scenario will never happen.  The users of the message centre will have
their own addresses to identify them (e.g. [email-masked]
or more generally, [email-masked]) while the TV as an appliance
to be controlled will have its own address (e.g.
[email-masked]).  The users 'TV-controls' and
'jdrosen@messages' (or 'messages') will have their own SIP UAs.  There
should be no confusion at all about how MESSAGE gets rendered.

> altering what happens to it.
I still can't agree with you here.  I think Henning is right.  Surely
Content-Disposition: does just what you argue against?  The
Content-Disposition header describes what should be done with the body when
it's received at the UA.  With the current parameter values, the UA can
either set up the session using the body (which is assumed to be SDP) or the
UA displays/renders the body to the user.  Hence it is fundamentally
altering what the UA does when the SIP message is received.  Am I
misunderstanding the purpose of the header?

> figure out what the purpose of the message is. Method is for that
This has been an interesting discussion and I'm grateful for all the
comments.  If other people on the list also feel so strongly about it, then
we could introduce a separate method from MESSAGE.  But I'd rather use
MESSAGE with a new Content-Disposition value defined.

Have a nice weekend.

Thanks,
Simon

--
Simon Tsang (Ph.D)
Research Scientist - Internet Service Management Research
Telcordia Technologies (http://www.telcordia.com)

---

From: Stan Moyer <[email-masked]>
Date: Sat, 05 Aug 2000 21:02:37 -0400

Jonathan,

Would you still object to using SIP for networked devices/appliances if we used
another message name? For the longest time we were ready to propose a new
method that we had been calling KICK for the purpose of sending a message to a
networked appliance/device. Then when we ready your impp drafts that proposed
the method MESSAGE, we thought there would be a benefit to using the same
method/message since the semantics seemed very similar (or at least we thought
so). The main benefit is that a SIP Proxy and/or SIP UA stack that supported
Instant Messaging and Presence would also support networked appliance/device
messaging -- new Proxies and UA stacks would not be required. This would be
very advantageous in terms of compatibility and interworking.

But, if you believe that the negatives outweigh the benefits in this case, we
could be persuaded to create a new method/message (but at this point in time I
am not convinced).

-Stan

Stan Moyer

---

From: Stan Moyer <[email-masked]>
Date: Sat, 05 Aug 2000 21:02:47 -0400

>stored, in fact, elsewhere. Same case here.

I don't think arguing a different solution (i.e. protocol) for each of the
requirements (e.g., how to address control messages) for supporting
networked devices/appliances is fruitful. Yes, an alternate solution (from
SIP) is possible for each of the requirements, but when you combine most or
all of the requirements, then SIP does appear to be the best solution.
Since there are many requirements and considerations for supporting
networked device/appliances, maybe it would be best if we meet face-to-face
to discuss these in detail (it would take awhile to cover in this mailing
list). We'd be happy to host a meeting or visit you (and anyone else
interested would also be welcome to attend).

>which integrate me talking to my refrigerator and me controlling it?

The only difference is communications between people and communication
between devices. They are just different types of entities, but still have
a need to exchange information (e.g., communicate) via audio, video, and
data. For example, what if your refrigerator had a built-in video-screen
for communications (I know that sounds far-fetched, but I have seen a
concept video from Intel with just that scenario). And even if you don't
talk with your refrigerator, you probably would (at the very least) have a
phone in the kitchen and wouldn't it be nice if the same infrastructure in
the residential gateway (for the home) and the service provider could
support both services?

-Stan Moyer

---

From: "Ben Campbell" <[email-masked]>
Date: Sat, 5 Aug 2000 20:32:29 -0500

> [mailto:[email-masked]]On Behalf Of Henning Schulzrinne

[snip]

> a viable alternative in all cases.
Hi Henning,

I am not sure what you mean by the last sentence. You assert that web
clients are not always the best solution because they can be hard to
automate. Do you intend imply that SIP clients are somehow easier to
automate, and therefore a better solution in those cases? I'm not sure I
understand your point.

Thanks!

Ben.

---

From: Henning Schulzrinne <[email-masked]>
Date: Sat, 05 Aug 2000 22:14:10 -0400

[Trimming the cc list since I suspect that everyone is on the sip
mailing list]

> automate, and therefore a better solution in those cases? I'm not sure I

Web interaction relies on forms input, either as PUT or GET (? query).
Web forms are generally designed as HTML forms. Only GET can generally
be bookmarked, with a very limited expressiveness and kludgey syntax.
(And GET is not supposed to change the state of the resource, while that
is clearly what you want to do for a control mechanism. Also, see the
dislike for SOAP expressed elsewhere...) 

Appliance control, in my view, will be a combination of automated agents
and human interaction. I would even guess that many larger appliances
will have both a web server and a more message-based mechanism. For
small appliances, having a UDP-only mechanism has distinct complexity
advantages.

In addition, in a kind of strange reversal of roles, while HTTP could
conceivably be used for retrieval of state and (mostly human)
configuration, it offers no notification mechanism. Thus, since
notification is an inherent feature of devices, it is convenient to have
the same protocol to both directions.

It might also be relevant to note that technologies such as the web were
originally designed for human interaction, although now many wish that
we had more labeling (as in XML and the efforts for standardizing
ecommerce field names, inter alia) making it more suitable for
machine-to-machine interaction. I suspect that even SIP notification and
messaging will see a similar evolution from mostly human-to-human to
various mixtures.

Also, there currently is no equivalent technology to sip-cgi and CPL for
HTTP. (There's obviously cgi, but that's in the server itself and not
really where you want it.)

I have to admit that I continue to be somewhat perplexed by this
discussion. We have dozens of SIP extensions that truly do change and
complicate SIP to provide the feel of 19th century telephony (well, or
1970s user interaction), and here we have one that adds nothing (beyond
a method, depending on taste) and works by adding a different content
type. To me, that indicates a strength of the underlying
SIP-for-presence model, not some errant digression.

Henning

---

From: Henry Sinnreich <[email-masked]>
Date: Sun, 06 Aug 2000 07:32:31 -0500

It appears from this mail trail that the reticence for using SIP
for appliances are due not from the merit of this use, but
rather from philosophical/principles considerations of
overloading the use of SIP and "world domination". IMHO let's
stick with merit and specifics: There is a solid case as stated
by Stan Moyer and others to use SIP for appliances.

This discussion has BTW omitted the most common appliance:
Phones!  :->)

Thanks, Henry

Henry Sinnreich
MCI WorldCom
400 International Parkway
Richardson, Texas 75081
USA

>[mailto:[email-masked]]On Behalf Of Stan Moyer
>Sent: Saturday, August 05, 2000 8:03 PM
>To: Jonathan Rosenberg; Henning Schulzrinne
>Cc: Simon Tsang (Telcordia Technologies);
>[email-masked];
>Subject: Re: [SIP] Comment on
>draft-moyer-sip-appliances-framework-00.txt
>
>
>Jonathan,
>

---

From: "Ben Campbell" <[email-masked]>
Date: Sun, 6 Aug 2000 20:07:06 -0500

Hi Henning,

Thanks for the clarification.

In my mind, the controversy over the appliances draft, is that it proposes
to use SIP and the event extensions as a general purpose process to process
message passing and event protocol. Or if not general purpose, then at least
for the fairly broad category of device control. Do you see this as true?

I have difficulty deciding whether this is a good or bad thing. Past
attempts of the IETF to work on general purpose event mechanisms has gone
nowhere, with the general reason (excuse?) that the requirements for event
mechanisms are too varied for one protocol to support them. Now that we
propose to add event extensions to SIP, I expect to see a wave of
application proposals to use SIP as the general purpose approach.

I for one believe we _do_ need one or more general purpose event protocols,
and am willing to _consider_ using SIP for that purpose. I am not so
concerned that such use would actually harm SIP; I just wonder if it is the
best for the job.

The questions I would like to see considered are the following:

1. Is SIP (with event and message extensions) an appropriate platform for
general event and message applications, particularly in a device to device
or human to device model.

2. For a given application of said extensions, how do we decide whether it
is a good fit? For example, what if instead of refrigerators and lamps, we
proposed to control and monitor medical equipment or industrial processes?

> Sent: Saturday, August 05, 2000 9:14 PM
> To: Ben Campbell
> Cc: [email-masked]

---

From: Henning Schulzrinne <[email-masked]>
Date: Sun, 06 Aug 2000 21:28:35 -0400

> for the fairly broad category of device control. Do you see this as true?

Yes. However, it's not the only such extension. We've already seen two
others, namely the PINT version and the use of SUBSCRIBE/NOTIFY for
mailbox notification.

> or human to device model.

For this, it would help to see where the differences are, in general,
between h2h and h2d etc. modes, beyond that the description of the state
is different.

Note also that this question has two types of answers:

(1) What would be an ideal protocol mechanism, within the constraint of
being physically achievable or a given network infrastructure?

(2) What is the best protocol framework with existing tools?

For example, the cost and availability of anycast and multicast may well
change the answer.

> proposed to control and monitor medical equipment or industrial processes?

This is similar to the question as to whether SIP is a good way to call
911, i.e., are Internet protocols such as SIP sufficiently reliable and
robust for applications where failure of communications has significant
negative consequences. Since SIP is targeted for first-line telephony,
among other applications, the answer better be yes, otherwise, we have
far more serious problems than lightbulbs.

---

From: "Ben Campbell" <[email-masked]>
Date: Mon, 7 Aug 2000 08:02:07 -0500

> others, namely the PINT version and the use of SUBSCRIBE/NOTIFY for

Well, at least philosophically, these fit more closely into the realm of
"normal" SIP applications. However, since I am down to only objections of
philosopy rather than objections of fact, I will concede the argument. As
you said earlier, the appliance draft does not propose any new extensions
for device control, and therefore it doesn't really add complication to SIP.

I withdraw my objections.

Thanks!

Ben.