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

From: "Ben Campbell" <[email-masked]>
Date: Wed, 2 Aug 2000 13:43:48 -0500

I have a general comment on the "Networked Appliances" draft.

It seems to me that SIP is not an appropriate protocol for this purpose. It
falls into the category of using SIP for an RPC mechanism. It is not clear
to me how the primary features that distinguish SIP from something like HTTP
(finding location, mobility, etc) are needed for a networked appliance
protocol.

It is entirely possible I am missing something here. If so, please enlighten
me.

Thanks!

Ben Campbell
dynamicsoft

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

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 02 Aug 2000 15:08:50 -0400

I don't see this as RPC in the classical sense. There are two aspects:

- action (MESSAGE) to affect lightbulb state;'

- events to obtain lightbulb state.

Thus, this is very similar to sending text (chat) messages and
subscribing to user status changes (events). Particularly in the event
case, the usual SIP advantages apply, including that the watcher may be
mobile (Speaking from personal plumbing accident experience, I want to
be notified when the home temperature drops below threshold regardless
of my location).

There are some nice secondary benefits to this: existing SIP message and
notification tools can be trivially extended to handle this. I can put
my washer in my address book and be notified when the wash is ready.

Also, existing tools such as sip-cgi and CPL are quite useful for this
space.

Since this doesn't require any SIP extensions, it seems (hopefully)
harmless.

---

From: "Ben Campbell" <[email-masked]>
Date: Wed, 2 Aug 2000 14:50:29 -0500

> From: Henning Schulzrinne [mailto:[email-masked]]
>

It seems that this and other discussions of subscribe/notify and message, we
are moving towards a general event mechanism, i.e. application to
application communication, not necessarily human to human communication. I
am agnostic on whether this is a good or bad thing, but I am surprised it
does not generate more controversy. Perhaps this should come up at the event
mechanism BOF tonight.

> Since this doesn't require any SIP extensions, it seems (hopefully)

Not to be pedantic, but while it may not _introduce_ any new extensions, it
certainly does require a them. Again, perhaps we need to clarify the
intended purpose of the presence and messaging extension proposals.

---

From: "Srinath A" <[email-masked]>
Date: Thu, 3 Aug 2000 09:50:31 +0530

Hi,

    I would like to add in this context that once the instant messaging is in place, can it be used
for sending static images in SIP?  This pertains to the earlier issue on sending a variable bitrate,
low frame rate video in parallel with the existing session. Whenever an entity wants to send a frame
to the other end it merely sends a notification message with the body containing the jpeg image.

    I have a doubt regarding whether RPC mechanism can be used for the same purpose as controlling
networked appliances from a wide area network. Do existing RPC mechanisms have User location
facilities? What about authentication? My personal opinion is that RPC could be used within the home
domain and not outside it. Comments?

Srinath A
Silicon Automation Systems Ltd
Bangalore
India.
Ph: +91-80-5276100/108 Ext 4220.
Company: www.sasi.com
Home: www.geocities.com/srinath_tvpm

---

From: Stan Moyer <[email-masked]>
Date: Thu, 03 Aug 2000 09:50:59 -0400

This is a good question and one that we thought a lot about, so I'd be 
happy to share some of our thoughts on this subject with you.

>(finding location, mobility, etc) are needed for a networked appliance

First, I do not think that we are really using SIP as an RPC mechanism. 
Though an argument could be made for the case when we want to query the 
status of a device (e.g., "what's the temperature"). However, we believe 
that there is a need to communicate with networked devices in several 
different fashions:
1. Send a command to a device (e.g., "Turn on the light"). This is very 
similar to Instant Messaging except that it is to a device instead of to a 
human user (or application). So we propose to use the MESSAGE method in the 
impp drafts.
2. Query a device (as mentioned above). While it could be viewed as similar 
to an RPC, it could also be an Instant Message with an acknowledgement
3. Establish a "session" with a device (e.g., "view the baby-cam", or "send 
audio stream to stereo"). For this you would use a SIP INVITE with an SDP 
payload.
4. Asynchronous events (e.g., "notify me when the security alarm goes 
off"). This requires an event mechanism and the impp drafts describe 
SUBSCRIBE and NOTIFY messages that could be used for this.

We were not able to find one protocol out there that could easily support 
all these communications paradigms. While it is true that several different 
protocols could be used, we believe that there is great value in using one 
protocol to support all these mechanisms for networked device 
communications. To only require one common infrastructure to be deployed, 
maintained, and managed is a big plus (IMO) for any architecture. There are 
maybe only a few devices (like a camera that establishes a session to 
transmit a video stream, and also accepts commands, e.g., via MESSAGE, to 
control -- e.g., pan, zoom, etc.) that may have convergence of these 
communications paradigms, but there will be many home domains that require 
this convergence.

In addition to supporting the previously mentioned communications 
mechanism, networked devices also have other requirements. For example,
- a general purpose addressing scheme
- support for mobility/forwarding
- security (privacy and authentication/authorization)
In our opinion, SIP was the only protocol we found that met all of the 
combined requirements.

Perhaps the framework draft does not do a good enough job of outlining 
these (and other) requirements and we would be better off with a separate 
requirements draft.

We know that SIP was not originally intended for this purpose, but we think 
that using SIP for networked appliances does not put any additional 
burden/requirements on SIP (assuming the impp drafts are incorporated) and 
only adds to the overall attractiveness of SIP.

>It is entirely possible I am missing something here. If so, please enlighten

I hope I answered your question(s), if not please let me know and I will 
provide additional info/detail.

-Stan Moyer

---

From: Henry Sinnreich <[email-masked]>
Date: Thu, 03 Aug 2000 09:03:12 -0500

>great value in using one
>maintained, and managed is a big plus (IMO) for any
>architecture.

I believe many service providers would fully agree, given the
cost of OSS and skill sets required for every protocol in the
network.

Henry

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

>-----Original Message-----
>From: [email-masked]
>[mailto:[email-masked]]On Behalf Of Stan Moyer
>Sent: Thursday, August 03, 2000 8:51 AM
>To: Ben Campbell; [email-masked]
>Cc: [email-masked];
>[email-masked]
>Subject: [SIP] Re: Comment on
>draft-moyer-sip-appliances-framework-00.txt
>
>

---

From: Henning Schulzrinne <[email-masked]>
Date: Thu, 03 Aug 2000 10:29:25 -0400

> to the other end it merely sends a notification message with the body containing the jpeg image.

Nobody can keep you from doing this if you insist (as long as you don't
want to turn it into an Internet standard), but you'll find that there
are more appropriate mechanisms, as discussed on this list a few weeks
ago. RTP works just fine for JPEG, regardless of whether you send a
frame a second or a frame a week.

> domain and not outside it. Comments?

Some of the Corba facilities use directory-based mechanisms to locate
(effectively) servers, but interdomain use does seem to be rare at this
point.

---

From: Rohan Mahy <[email-masked]>
Date: Thu, 03 Aug 2000 11:07:16 +0200

Hi,

I think this is reasonable, but for higher bit-rate messages, I think a
starting a specific application from the SDP would be appropriate (per
Christian's proposal). The transport could be RTP, TCP, BXXP, whatever.  I
would draw the line at MESSAGE requests fitting in a single datagram.  

thanks,
-rohan

---

From: Rohan Mahy <[email-masked]>
Date: Thu, 03 Aug 2000 11:37:38 +0200

>to an RPC, it could also be an Instant Message with an acknowledgement

while the message flow and size would be appropriate for message, we need
to decide if we agree with this usage or instead with Jonathan's guidelines
doc .  The guidlines doc says not to overload INFO to do device control,
etc, etc, ; and that a method name should convey the verb associated with
the method.

which do we want? 

	a) CONTROL and QUERY methods?
	b) use MESSAGE  and SUBSCRIBE (for a fetch)
	c) use another app setup with SIP INVITE
	d) use a completely separate protocol

This is not a decision limited to "wierd" applications like refrigerator
temperature, light bulbs and coffe pots (no offense intended). 

One feature that really could take advantage of a CONTROL method is Far-end
camera control for video sessions.  You could also use such a method for
conference moderation/control.  Jonathan specifically said conference
control is out of scope.

>SUBSCRIBE and NOTIFY messages that could be used for this.

I agree that both 3 and 4 are completely apropos for SIP.

thanks,
-rohan