Internet Engineering Task Force Simon Tsang
Internet Draft Stan Moyer
draft-tsang-sip-appliances-do-00.txt Dave Marples
November, 2000 Telcordia Technologies, Inc
Expires: May, 2001
Henning Schulzrinne
Columbia University
Arjun Roychowdhury
Hughes Software Systems
SIP Extensions for Communicating with Networked Appliances
STATUS OF THIS MEMO
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. Comments should be
submitted to the appliances@research.telcordia.com mailing list.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as work in progress.
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Abstract
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.
1. Introduction
There are numerous technologies for networking and controlling
appliances within a home. Some examples are X.10 [6], OSGi [1], HAVi
[2], VHN [3], and UPnP [4]. However, there is currently no support
for wide-area access communication or control of these Networked
S. Tsang et al [Page 1]
Internet Draft SIP Extensions for NA Control November 2000
Appliances (NAs) 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
[10][11].
The Session Initiation Protocol (SIP) (RFC 2543) [7] is an ideal
protocol for supporting wide-area communication and interworking of
NAs. SIP, as defined in the RFC, meets many of the requirements [11]
for communicating with NAs: security, authentication, reliability,
scalability, universal addressing, support for call setup, and
personal mobility.
This document describes a new SIP method æDOÆ for enabling wide-area
communication between user agents and NAs. The DO method carries
messages or requests for NAs in the body of the DO request, and
delivers it into the home environment where the message or request is
rendered. The method does not result in a session set up, and can be
used within or without an existing session. Examples of DO use
include: sending application requests to NAs, updating NA
information, and querying the status of NAs.
It should be noted that DO can be used in conjunction with other SIP
methods to support wide-area communication between NAs. However,
this draft focuses only on the definition and use of DO.
2. Terminology
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.
3. Definitions
802.11 Wireless LAN networking technology.
Bluetooth Wireless technology for networked devices.
Domain An administrative IP domain.
HAVi 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.
S. Tsang et al [Page 2]
Internet Draft SIP Extensions for NA Control November 2000
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.
4. Overview of Operation
Figure 1 illustrates an example of using the Session Initiation
Protocol to communicate with NAs.
Lamp
|
|
+------+-------+
IP Local Area Network | Appliance |
.......................| Controller |
. | (SIP UA) |
. +--------------+
+-------------+ SIP | .
SIP | Residential |------------------------+ .
User---------| Gateway | .
(SIP UA) | (SIP Proxy) |------------------+ .
+------------++ SIP | .
. | | .
. ++-------+ +-----------+ .
...|Location|.....| Other |....
|Server | | Appliance |
+--------+ | (SIP UA) |
+-----------+
Figure 1: Example architecture using SIP to control NAs
The key components of the architecture are now described.
Residential The RGW provides IP connectivity outside of the home
Gateway (RGW): 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)
S. Tsang et al [Page 3]
Internet Draft SIP Extensions for NA Control November 2000
functions.
Appliance The appliance controller enables non-IP devices
Controller: (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 Other appliances will be connected in the home
Appliance: 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 The location server is a database which provides the
Server: SIP proxy with information on how to route incoming
or outgoing SIP messages.
IP local area The IP local area network in the home network
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 2 shows an example message flow for wide-area NA control.
Appliance
User RGW Controller Lamp
(SIP UA) (SIP Proxy) (SIP UA)
user@example.com example-home.net lamp@ac.example-home.net A0
| | | |
| | | |
| | | |
|------------------>| | |
| DO lamp@example- | | |
| home.net | | |
| on |-------------------->| |
| | DO lamp@ac.example-| |
| | home.net | |
| | on |--------------->|
| | | [ON] |
| | | |
| | | |
| |<--------------------| |
| | 200 OK user@example | |
| | .com | |
|<------------------| | |
|200 OK user@example| | |
| .com | | |
Figure 2: Example message flow for wide-area NA control
S. Tsang et al [Page 4]
Internet Draft SIP Extensions for NA Control November 2000
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.
5. DO Method Definition
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 *
S. Tsang et al [Page 5]
Internet Draft SIP Extensions for NA Control November 2000
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
Table 1. Summary of header fields. (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
S. Tsang et al [Page 6]
Internet Draft SIP Extensions for NA Control November 2000
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.
6. Security Considerations
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.
7. References
[1] OSGi, http://www.osgi.org
[2] HAVi, http://www.havi.org
[3] æVHN Home Network,Æ EIA 851, Version 1, to be released 4Q00,
See http://www.vesa.org for further information.
[4] UPnP, http://www.upnp.org
[5] Jini, http://www.jini.org
[6] X.10, http://www.x10.org
S. Tsang et al [Page 7]
Internet Draft SIP Extensions for NA Control November 2000
[7] 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.
[8] Bluetooth, http://www.bluetooth.com
[9] Salutation, http://www.salutation.org
[10] S. Moyer et al, ôFramework Draft or Networked Appliances using
the Session Initiation Protocolö, Internet Draft, Internet
Engineering Task Force, July 2000. Work in progress.
http://www.argreenhouse.com/iapp/draft-moyer-sip-appliances-
framework-00.txt
[11] S. Tsang et al, ôRequirements for Networked Appliances: Wide-
Area Access, Control, and Interworkingö, Internet Draft,
Internet Engineering Task Force, September 2000. Work in
progress. http://www.argreenhouse.com/iapp/draft-tsang-
appliances-reqs-01.txt
[12] http://www.w3.org/XML/
8. Author's Contacts
Simon Tsang
Telcordia Technologies
445 South Street
MCC 1E 206R
Morristown, NJ 07960, USA.
e-mail: stsang@research.telcordia.com
Stan Moyer
Telcordia Technologies
445 South Street
MCC 1A-238R
Morristown, NJ 07960, USA.
e-mail: stanm@research.telcordia.com
Dave Marples
Telcordia Technologies
445 South Street
MCC 1J-226B
Morristown, NJ 07960, USA.
e-mail: dmarples@research.telcordia.com
Henning Schulzrinne
Department of Computer Science
Columbia University
M/S 0401
1214 Amsterdam Avenue
New York, NY 10027-7003, USA.
e-mail: hgs@cs.columbia.edu
Arjun Roychowdhury
Hughes Software Systems
S. Tsang et al [Page 8]
Internet Draft SIP Extensions for NA Control November 2000
Prestige Opal
146 Infantry Road
Bangalore 560001, India.
e-mail: archow@hss.hns.com
S. Tsang et al [Page 9]