|
|
|
Note that this is a heavily overloaded term, but our working definition is
A dedicated function consumer device containing a
networked processor
But more generally it is any non-general purpose device (i.e., not a PC,
Palm Pilot, PDA, etc.) that has a network connection.
The short answer is that SIP meets all the requirements for accessing devices from the wide area and this enables re-use of the infrastructure that has been constructed for SIP in a whole new domain!
The long answer is that we developed several main requirements for the accessing of devices from the wide area and SIP was the only protocol that we found that could meet all of the requirements (yes, there are protocols, such as http, that can meet many of the requirements, but not all of them). Some of these requirements are:
 |
Support abstract addressing/naming. Devices behind the residential gateway/firewall/NAT may not be directly addressable -- their addresses may not be known, they may be private IP addresses, or even non-IP addresses. |
|
Provide security -- both authentication/authorization and privacy. There is a need to check access on a per operation per device basis when accessing devices in the home from the wide area. In addition, the contents of the messages, must be kept private so that eavesdroppers cannot learn about what is in people's homes. |
|
Support four different communications
mechanisms for devices:
|
|
Provide a flexible payload capability. For example, the ability to carry different MIME types. |
|
Interwork with different in-home networking technologies (e.g., HAVi, UPnP, Jini, Salutation, etc.) |
|
Provide support for the mobility of networked appliances either within the home domain, within the Service Provider's domain, or across Service Provider domains. |
Additionally, using SIP for Networked Appliances enables the re-use of an existing SIP infrastructure (e.g., for Voice over IP, Instant Messaging, etc.) for a whole new set of services.
Almost definitely not. SIP is good for finding an endpoint (device), and it carries an arbitrary payload. In itself it does not define what that payload is. At the very least there is going to need to be some protocol to define that. Also, SIP is a little heavyweight for communication between two local devices, which don't need many of the advantages that SIP brings to wide area communication. There is lots of work going on by other groups in the definition and standardization of these protocols and we expect SIP for Networked Appliances to leverage these existing and emerging standards.
Pretty much anything you can do via local access to a device from another. For example, using the SUBSCRIBE and NOTIFY extensions you can get asynchronous notification of changes in the status of devices (e.g. a doorbell ringing), using INVITE you can open up media streams (e.g. to collect video from a remote camera) and using DO you can perform arbitrary actions on remote devices (e.g. opening the door). Combine these three and you've just implemented a remote door service. We believe that using these services in combination allows the realization of almost all services remotely, in a secure and reliable fashion.
The only modification to SIP (as specified in draft-ietf-sip-rfc2543bis-01.pdf) that we are proposing is the creation of a new message type, DO (see draft-tsang-sip-appliances-do-00.txt) though we also require the extensions specified in the SUBSCRIBE/NOTIFY drafts (draft-roach-sip-subscribe-notify-03.txt)-- specifically the new methods, SUBSCRIBE and NOTIFY.
We also need a different addressing scheme, though this can be captured in a SIP URL. We propose to encode a structured device naming scheme (e.g., similar to an SLP URL) to the left of the “@” sign in the To: field. Then encrypt the encoded address to ensure privacy. For example: [d=lamp,r=bedroom,u=stsang]@simon.home.net where the information in the square brackets would be BASE-64 encoded and (optionally) encrypted. However, standard SIP addressing will work too -- e.g., bedroomlamp@simon.home.net.
In addition, a new payload type, specific for devices is required. We propose to specify a new MIME type that we are calling the Device Messaging Protocol (DMP) to carry the information required to excite NAs and which can carry responses back to the originator. Of course there is no reason that other payloads (e.g., SOAP) could be be carried too (either as another MIME type or as part of the DMP). See draft-khurana-dmp-appliances-00.txt for more details on DMP.
Why do you propose to base 64 encode (and encrypt) the device addressing information (e.g., an SLP URL) in the username portion of the SIP URL? Why not just use a generic URI with an SLP or LDAP URL?
The reason for this is that we want the ability to encrypt this information for privacy reasons. Since the slp url, e.g., slp:/d=lamp,r=bedroom,u=stanm, carries information about what devices you have in your home and where they are, we believe this information should be kept private (or at least have the ability to keep it private). So, if we were to use, for example, an LDAP url as the uri for addressing, we would not be able to encrypt the field since it has be able to be read by intermediate SIP Proxies that may not be able to "decrypt" the field. By placing this information in the username portion of a sip url, we enable the "sensitive" information to be encrypted (e.g. using PGP) while still retaining the routing capability of the SIP Proxies. Of course the base 64 encoding would not be required if you encrypt the field and all the characters are RFC compliant (e.g., [slp:/d=lamp,r=bedroom,u=stanm]@stanm.home.net ==> 5n3PwPFV793Bd6EmgO@stanm.home.net).
For device communications/querying, why not use the MESSAGE method proposed in the SIP for IM internet draft, why not use a new message type/method?
There was some discussion about this on the SIP WG mailing list and the appliances mailing list. The main point of the discussion was whether it made sense to "overload" MESSAGE to communicate with appliances or if it was better to use a new method specifically for networked appliances. For now, we have proposed a new method type, DO, to control/query networked appliances. This should not require any changes to SIP Proxies.
SIP is used for locating devices within a given logical environment (called a REALM), which may well consist of disparate physical networks, with widely different characteristics and underlying protocol systems (e.g, any of the above-mentioned protocols). SIP for Networked Appliances is intended to give a uniform means of access to appliances in a realm without being tied to any particular one of them.
SIP for Networked Appliances is as secure as SIP, we do not believe that new security holes are opened by using SIP in this way, although the number of things it's possible to do with SIP for Networked Appliances means that the consequences of a compromise may be more severe.
We believe that SIP for NA's fits neatly into OSGi -- there is no need to make a choice between them, you can have both. Having said this, SIP-NA does not mandate OSGi. Our view is that you should be able to use SIP with or without an OSGi framework underneath. We don't see a problem with doing this provided that SIP-NA is specified at the protocol level and are not 'tempted up' to APIs. The APIs will be specified in OSGi.
Don't misinterpret the above as our not supporting OSGi, on the contrary we think it's great work and are contributing heavily to it -- Dave Marples is the Chair of the OSGi Architecture Expert Group, for example. We simply want SIP to be as widely applied as possible, and this needs to include environments that are not OSGi compliant.
SIP for Networked Appliances was presented by Dave Famolari at the OSGi meeting in Rome 20-22 September 2000, please see the OSGi website (www.osgi.org) for the latest information.
| Home | Back | Top of Page | Feedback | www.telcordia.com |
| © 1999 - 2005 Telcordia Technologies, Inc. |