A variety of technologies are available to network appliances
and provide home automation and control. However, these
do not support wide-area access control and interworking
of these Networked Appliances (NA). This document describes
a new SIP method, DO, that allows a SIP UA to communicate
with NAs.
The next wave of the Internet is widely predicted to be the
Networked Appliance (NA) - the refrigerator that can keep
an inventory of your groceries and re-order when necessary
or perhaps the alarm clock that can co-ordinate your agenda,
check the weather and the road conditions to determine the
correct time to wake you up. It is clear that these appliances
will need to communicate amongst themselves. For example,
an alarm clock may be configured to switch on the bedroom
lights at 7am as a wake-up indication to the user.
The term Networked Appliance (NA) is difficult to define as
it can cover a very large range of devices. However, for the
purposes of this document, a Networked Appliance is defined
as being a dedicated function consumer devices containing
at least one networked processor. Examples of NAs include:
lamps, refrigerators, toasters, and TVs.
There are numerous networking technologies which allow the
scenarios outlined above to be realized within a single home
or administrative domain. Some examples are X.10 [6], HAVi
[2], VHN [3], and UPnP [4].
However, there is currently no support for wide-area access
control of these networked appliances from the Internet, or
for interworking the various home networking technologies.
The ability to provide such support will radically enhance
the ability to provide exciting new services.
For example, before leaving the office, a user could contact
his (or her) home and ask it to pre-heat the oven, record
the news on TV, and set the house temperature to 70 degrees
F. While on a business trip, a plumber comes to the house
to fix a leaky sink. The user is notified when the plumber
rings the doorbell and a camera at the door transmits an image
of the plumber to the user's laptop PC. The plumber's ID card
has an electronic signature which is also transmitted
with the image and verified by the user's client software.
The user remotely unlocks the door and allows the plumber
in, all the while viewing and conversing with the plumber
via micro-cameras and microphones in the home.
This document outlines a set of requirements for providing
Networked Appliance wide-area accessibility and interworking.
Required capabilities include: control of NAs, event subscription
and notification, and remote sensor reading.
In this document, the key words ‘MUST’, ‘MUST NOT’, ‘REQUIRED’, ‘SHALL’,
‘SHALL NOT’, ‘SHOULD’, ‘SHOULD NOT’, ‘RECOMMENDED’, ‘MAY’, and
‘OPTIONAL’ are to be interpreted as described in RFC 2119
and indicate requirement levels for the protocol.
Home Audio Video Interoperability:
A consortium of audio-visual electronics manufacturers
who have developed a common, openly-licensable specification
for networking digital home entertainment products.
OSGi
Open Services Gateway initiative:
An industry group working to define and promote an open
standard for connecting smart consumer and small business
appliances with commercial internet services.
Jini
Java based device connectivity
and discovery framework.
NA
Networked Appliance: A dedicated
function consumer devices containing at least one networked
processor.
NAT
Network Address Translator.
RGW
Residential Gateway: Point
of networking and control access to/from a home environment.
The RGW may contain additional functions, such as firewalls
and NATs.
Salutation
An open service discovery
and session management protocol developed by the Salutation
Consortium.
SIP
UAC
SIP User Agent Client
SIP
UAS
SIP User Agent Server
UPnP
Universal Plug and Play:
An open architecture for connectivity of PCs of all form
factors, intelligent appliances, and wireless devices.
VHN
Video Electronics Standards
Association (VESA) Home Networking: Networking and control
for video appliances developed by the VESA consortium.
X.10
Early power line based home
networking technology.
Figure 1 illustrates an example of using the Session Initiation Protocol
to communicate with NAs.
Figure 1: Example architecture using SIP to control NAs
The key components of the architecture are now described.
Residential
Gateway (RGW):
The RGW provides IP connectivity
outside of the home environment. All external access to
the home will be made through the RGW. The RGW will provide
a SIP proxy for handling SIP requests and responses to/from
the home. Additionally, the RGW may provide firewall and
network address translator (NAT) functions.
Appliance
Controller:
The appliance controller
enables non-IP devices (e.g., X.10) to be controlled from
an IP network. It provides interworking between the IP
local area network and the non-IP devices. The Appliance
Controller comprises a SIP UA and a device controller,
and performs SIP to device protocol interworking.
Lamp:
The lamp is an example of
a non-IP appliance. It is controlled by the user on an
IP network through the Appliance Controller.
Other
Appliance:
Other appliances will be
connected in the home environment. This one uses a SIP
UA to allow users to control it from the wide-area IP
network.
User:
A user controls NAs in the
home environment over a wide-area IP network via a SIP
UA.
Location
Server:
The location server is a
database which provides the SIP proxy with information
on how to route incoming or outgoing SIP messages.
IP
local area network:
The IP local area network
in the home network environment connects together the
RGW, IP appliances and Appliance Controllers. A variety
of networking technologies may be employed. Examples are:
802.3, 802.11, and Bluetooth [8].
Figure shows an example message flow for wide-area NA control.
Example message flow for
wide-area NA control
In this scenario, a user (SIP UA address user@example.com)
remotely turns on a lamp in the home with domain name
example-home.net. The Appliance Controller has a SIP
UA with SIP address lamp@ac.example-home.net.
The body of the DO message sent by the user contains XML describing the
action to be performed by the NA. When the Appliance Controller receives
the DO message, it must interpret the action specified in the
DO body and send the appropriate command to the lamp (e.g., “ON”).
The Appliance Controller will then respond with 200 OK to
the user to indicate that the action has been performed.
This specification defines a new SIP method, DO. The
purpose of DO is to enable messages or requests to be sent
to NAs without setting up a new session. However, DO can
be used within the context of an existing session, and
will share the same Call ID as the existing session. The
message or request will be carried in the body of the DO
message. The BNF for this method is:
Do = "DO"
5.1. Header Field Support for DO Method
The following table is an extension of tables 4 and 5 in
the SIP specification. Refer to the SIP Specification
for a description of the content of the table.
Header
Where
enc.
e-e
DO
Accept
R
e
o
Accept
415
e
o
Accept-Encoding
R
e
o
Accept-Encoding
415
e
o
Accept-Language
R
e
o
Accept-Language
415
e
o
Allow
200
e
o
Allow
405
e
m
Authorization
R
e
o
Authorization
r
e
o
Call-ID
gc
n
e
m
Contact
R
e
m
Contact
2xx
e
o
Contact
3xx
e
o
Contact
486
e
o
Content-Encoding
e
e
o
Content-Length
e
e
m
Content-Type
e
e
*
Cseq
gc
n
e
m
Date
g
e
o
Encryption
g
n
e
o
Expires
g
e
o
From
gc
n
e
m
Hide
R
n
h
o
Max-Forwards
R
n
e
o
Organization
g
c
h
o
Priority
R
c
e
o
Proxy-Authenticate
407
n
h
o
Proxy-Authorization
R
n
h
o
Proxy-Require
R
n
h
o
Record-Route
R
h
o
Record-Route
2xx,401,484
h
o
Require
R
e
o
Retry-After
R
c
e
-
Retry-After
404,413,480
c
e
o
486
500,503
c
e
o
600, 603
c
e
o
Response-Key
R
c
e
o
Route
R
h
o
Server
r
c
e
o
Subject
R
c
e
o
Timestamp
g
e
o
To
gc(1)
n
e
m
Unsupported
420
e
o
User-Agent
G
c
e
o
Via
gc(2)
n
e
m
Warning
r
e
o
WWW-Authenticate
R
c
e
o
WWW-Authenticate
401
c
e
o
(1) copied with possible addition of tags
(2) UAS removes first Via header field.
5.2. Responses to DO Requests
A 200 OK response is sent if the DO request was successful.
The message body MAY include additional information to
reflect the result of the successful DO request, such
as current device status.
Request Failure (4xx), Server Failure (5xx) and Global Failure
(6xx) responses can also be sent for the DO Request.
5.3. Message Body Inclusion
DO requests SHOULD contain a message body, which contains
information on the action to be performed by the NA.
This document does not specify the format for the DO
message body, which may depend on the application domain.
For Networked Appliances, there is an investigation underway
to define a Device Messaging Protocol (DMP) MIME type
that can be used as a DO message body. 5.4. Behaviour of SIP User Agents
The protocol processing rules applied by the SIP User Agent
(UA) are similar to those for non-INVITE requests. DO
requests do not set up sessions and do not require session
state to be maintained. Each DO request MAY have a distinct
Call-ID or several DO requests MAY share the same Call-ID.
In the latter case, the receiving UA MUST enforce ordering.
DO requests MAY be part of an INVITE-initiated session. (For
example, a video camera could use DO requests, using a suitable message
body, to control its pan, tilt and zoom operations.)
5.5. Behaviour of SIP Proxy and Redirect Servers
5.5.1 Proxy Server
The protocol rules applied by the SIP Proxy Server shall be
similar to those applied used for any other SIP request.
Forking Proxy Server
The protocol rules applied by the SIP Forking Proxy Server
are the
same as for other non-INVITE requests.
5.5.2 Redirect Server
The protocol rules applied by the SIP Redirect Server shall
be similar to those applied used for the INVITE request.
The key difference is that the DO message shall not change
the state of the session.
Unauthorized use of networked appliances may cause injury
or property damage. Thus, implementations SHOULD use
authentication to ensure that only authorized entities
control network appliances and that the message body
cannot be altered without detection, as described in Section
13 of RFC 2543.
M. Handley, H. Schulzrinne, E. Schooler, and J. Rosenberg, "SIP:
session initiation protocol," Request for Comments (Proposed
Standard) 2543, Internet Engineering Task Force, March
1999.
