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

[Rohan Mahy]

At 03:50 PM 8/3/00 , Stan Moyer wrote:
>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.
>
>At 01:43 PM 8/2/2000 -0500, Ben Campbell wrote:
>>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.
>
>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

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.

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

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

thanks,
-rohan

>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
>>me.
>
>I hope I answered your question(s), if not please let me know and I will 
>provide additional info/detail.
>
>-Stan Moyer
>
>
>
>_______________________________________________
>SIP mailing list
>SIP@lists.bell-labs.com
>http://lists.bell-labs.com/mailman/listinfo/sip
>