Internet Engineering Task Dean/Belkind
Internet Draft 3Com
draft-dean-phonectl-02.txt
September 9, 2000
Expires: January, 2001
PHONECTL Protocol
1. Status of This Memo
This document is an Internet-Draft and is in full conformance with all
provisions of Section 10 of RFC2026.
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.
2. Abstract
The PHONECTL protocol allows remote control of an IP phone as an
alternative to human keying. For example, a Palm sized computer could
provide speed dialing and call screening for an embedded SIP ether-
phone over infrared. PHONECTL is designed to be...
* simple to fit inside a PDA and embedded phone
* intermittent connection capable (i.e. optional for any part of the
call)
* more secure, where plain-text passwords need not be shared with the
phone
3. 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 [1] and
indicate requirement levels for compliant SIP implementations.
Dean/Belkind [Page 1]
Internet Draft PHONECTL Protocol September 6, 2000
4. Definitions
* SIP Message: The generalization of a SIP request or a SIP response.
One could say a SIP datagram, but multiple SIP messages can be
stuffed into a datagram.
* Master: User Agent Client (UAC) The host which issues PHONECTL
requests. For example a personal digital assistant (PDA) or a
Personal Computer (PC).
* Phone: User Agent Server (UAS). The host which receives PHONECTL
requests. For example a SIP EtherPhone.
* Line: A SIP Call Leg End (CLE). Analogous to a line of a multi-line
POTS phone. The line connects the phone to another phone, not the
master.
* Active: a phone line in a non-idle state. For example, ringing or
failure (fast busy).
5. Introduction
The PHONECTL protocol allows remote control of an IP phone as an
alternative to human keying. For example, a Palm sized computer could
provide speed dialing and call screening for an embedded SIP ether-
phone over infrared. PHONECTL is designed to be...
* simple to fit inside a PDA and embedded phone
* intermittent connection capable (i.e. optional for any part of the
call)
* more secure, where plain-text passwords need not be shared with the
phone
With this draft we must assume some future behavior of embedded SIP
phones. Often these phones have a limited interface, and are used by
non-technical people, so they are simplified to perform like existing
phones, both cellular and multi-line POTS. This also allows PHONECTL
to map well to non-SIP phones.
PHONECTL is different than MGCP. The phonectl master does not tell
the phone what ports to send/receive RTP on, and doesn't hear about
the phone's button presses. This protocol is also different than
proxying a SIP call. Proxies are complex and must maintain
connectivity. They must worry about DNS, looping, retransmissions,
etc.
Security for Internet devices is important, but also must be
understandable by the users. The concept of registrations only
affecting inbound calls is confusing. Managing authorities for
outbound calls is also difficult. We have unified these into a login
concept for the user. One could handle inbound and outbound
separately, and the protocol allows for it, but the default is to
unify them as we expect many phone to present them this way.
Dean/Belkind [Page 2]
Internet Draft PHONECTL Protocol September 6, 2000
6. Protocol
The PHONECTL protocol syntax borrows from SIP, and appears as a new
method of SIP. This does not prevent non-SIP phones from using it.
The endpoints of a PHONECTL transaction are called a master and a
phone. Only the master makes requests, and only the phone sends
responses. For reliability over UDP, the master repeats requests
until a response is received. The ACK method of SIP is not used. By
eliminating the triple handshake, session, and bi-directional
operation of SIP, PHONECTL can be minimally simple.
PHONECTL messages SHOULD NOT use RFC822 line folding (i.e. header
lines beginning with space are continuations), but stacks MAY honor
them if they do. PHONECTL datagrams SHOULD NOT include multiple
messages, but stacks MAY honor them if they do.
All PHONECTL messages MUST include the To, From, Via, Cseq, Call-ID,
and Command headers. Additional headers may be required depending on
the value of the Command header.
Some PHONECTL requests require a message body. (Header and body are
separated by the first blank line.) In general, the body contents are
included in or must match the subsequent SIP request issued by the
phone. When specifying a call leg by "to" and "from", the body's "to"
is always the far end name of the SIP call leg, and "from" is the near
end name, even when the PHONECTL causes a SIP response such as answer.
7. Headers
7.1 Access
This header is used with the capabilities and login command to
indicate the access authentication schemes supported by the phone.
7.2 Command
The Command header is a mandatory header for every PHONECTL message.
The command is followed by one or more tokens separated by one space
each, but stacks MAY honor them if they contain multiple spaces. The
command header should be copied to the response.
Command names are case insensitive.
Command = "Command" ":" command-value
command-value = command-type [parameters]
command-type = "dial"
| "hangup"
| "digits"
| "select"
Dean/Belkind [Page 3]
Internet Draft PHONECTL Protocol September 6, 2000
| "list"
| "query"
| "recent"
| "login"
| "get"
| "set"
| "capablity"
parameters = 1*parameter
parameter = (digits | recent-param | capability-param
| list-param)
For example a PHONECTL message could look like:
PONECTL myphone.3com.com SIP/2.0
Via: SIP/2.0/UDP mypc.3com.com
To: "The Phone" <sip:192.168.1.1>
From: mypalm@3com.com
Cseq: 1234124
Call-ID: 4a234ffc4
Command: hangup
Line: line4
7.3 Device
This header is used with select and capability commands. Device names
are discovered using the capability command. With the "select"
command a phone call can be attached to a device. For example, the
following (abbreviated) message moves a call to speakerphone:
Command: select
Line: line3
Device: speakerphone
The device header is optional in a select command.
7.4 Line
The phone presents itself as a multi-line phone. The phone names the
lines. The line names MAY contain spaces. The phone SHOULD name the
lines with something presentable to the user. The phone may choose to
frequently reuse line names, or not. For example:
Line: green
Line: 1
Line: 847-262-1415
Line: rick@siphappens.com
If the phone uses a SIP URI for the line, it is preferable that the
URI is the near-end name of the line.
Dean/Belkind [Page 4]
Internet Draft PHONECTL Protocol September 6, 2000
7.5 User
This header is used by the login command. It is used to identify a
user.
8. Commands
8.1 Command: Capablity
This command is used to discover the features and devices available on
the phone.
Each phone is responsible for its own devices, and should use names
which are human presentable. The first device name MUST correspond to
the hold device.
For example the body of a Capability response could look like:
Devices: hold handset speaker speakerphone
Access: basic digest chap
8.2 Command: Dial
A dial command will place a call or modify an existing call. This is
determined by the presence of "line" header. A dial command with a
line header can only modify an existing call, and a dial command
without a line header can only initiate a new call.
A call-initiating dial command MUST contain a body with at least a
"To" header. It is recommended to also contain a "from" header.
If the body of a call-modifying dial command contains a "To" or "From"
header, these must match the existing call, or the phone SHOULD reject
the PHONECTL request. The phone SHOULD reuse the SIP call leg when a
call-modifying dial command is received. This allows the master to
use digest authentication for failed calls.
For example to initiate a call the master might send a message that
looks like:
PHONECTL aphone.3com.com SIP/2.0
Via: SIP/2.0/UDP
To: sip:myphone.3com.com
From: sip:mypalm.3com.com
Cseq: 234234
Call-ID: 098df3j34
Command: dial
To: sip:sales@3com.com
From: sip: belkind@3com.com
Dean/Belkind [Page 5]
Internet Draft PHONECTL Protocol September 6, 2000
The phone shall return 200 OK if it accepts the PHONECTL. This does
not imply the INVITE was successful. The master should poll with the
list command if it wants to track the progress of the call. This
differentiates between a 401 failure for the PHONECTL and a 401
failure of the INVITE.
Master phone far end
| Command: Dial | |
|----------------->| |
| 200 OK | |
| Line: foo | |
|<-----------------| INVITE |
| |-------------------->|
| | 401 Unauthorized |
| |<--------------------|
|Command: list line| |
|----------------->| |
| 200 OK | |
| Line: foo | |
| Device: handset | |
| Status: 401 Unath| |
| WWW-Authenticate:| |
|<-----------------| |
| Command: Dial | |
| Line: foo | |
| Authorization: | |
|----------------->| |
| 200 OK | |
| Line: foo | |
|<-----------------| INVITE |
| | Authorization: |
| |-------------------->|
| | 200 OK |
| |<--------------------|
| | |
The dial command may have an optional command line parameter. This is
only available when initiating a new call. The command line parameter
specifies the request URI for the phone to use. This is a request-URI
therefore no angle brackets. Normal usage will not need this
parameter, and the "to" header of the body is preferred.
8.3 Command: Digits
This command is used to generate DTMF digits. The digits are the
first token after the word digit. Multiple digits MAY be sent in one
request. An additional token of Ok MAY be appended to indicate the
end of dialing for those phones which support it. A token of
flashhook is also defined
digits 1*(quoted-string | 'ok | 'cancel' | 'back' | 'flashhook')
Dean/Belkind [Page 6]
Internet Draft PHONECTL Protocol September 6, 2000
For example....
Command: Digits "555" "1212" ok
or
Command: Digits flashhook
8.4 Command: List
8.4.1 Command: List lines
The master uses this command to determine the active lines of a phone.
Any non-idle state, such as ringing or call failure (fast busy), is
considered to be active.
The body of the response will contain a sequence of headers beginning
with a Line header, and followed by zero or more additional headers.
Each occurrence of a line header indicates a currently active line.
Successive non-line headers describe the state of the previously
defined line.
Each active line SHOULD return at least the status, to, from, and
device headers. The line name is used to reference the line in other
PHONECTL requests.
For example a List Lines response message might looks like:
SIP/2.0 200 OK
Via:
Cseq: 12321 PHONECTL
Command: list line
To: sip:myphone.3com.com
From: sip:mypalm.3com.com
Line: lineName1
Status:200 connected
To: "Guido Schuster" <5551212@sfour.com>
From: Rick@3com.com
Device: handset
Line: lineName2
Status:200
To: "Ikhlaq Sidhu" <7005554141@sfour.com>
From: Rick@3com.com
Device: hold
Line: lineName3
Status:401 Authentication Required
To: Rick@3com.com
From: "Billy Biggs" <911@sfour.com>
Device: hold
Dean/Belkind [Page 7]
Internet Draft PHONECTL Protocol September 6, 2000
The status header codes are the same status codes defined in RFC2543
Two new (virtual) status codes of are hereby defined...
184 Waiting on DNS
185 Contacting, no response
8.4.2 Command: List Users
The master uses this command to determine the users currently logged
into a phone.
The body of the List Users response contains a sequence of headers
beginning with a User header, and followed by zero or more additional
headers. Each occurrence of a User header indicates a currently
active user. Successive non user headers describe the state of the
previously defined user.
Each active user SHOULD return at least the status header.
The status header codes are the same as the response code to the last
register.
SIP/2.0 200 OK
Via:
Cseq: 12321 PHONECTL
Command: list user
To: sip:myphone.3com.com
From: sip:mypalm.3com.com
User: rick@3com.com
Status: 200 OK
User: ronnen@belkind.net
Status: 401 Authorization Required
8.5 Command: Get
This command is used to get phone specific parameters. The request
body contains a list of parameters, one per line of the body. If none
are provided, the phone SHOULD volunteer some. The parameters names
are not standardized and may change from device to device.
The response to a get request will contain a list of headers
(name:value) in the body of the message. If the Get request included
a parameter that is not supported by the phone, the parameter will not
be listed in the response.
For example (abbreviated):
Dean/Belkind [Page 8]
Internet Draft PHONECTL Protocol September 6, 2000
PHONECTL myphone.3com.com SIP/2.0
Command: get
Content-length: 26
Vol
DDD
Nonexistent
The corresponding response (abbreviated):
SIP/2.0 200 OK
Command: get
Content-length: 20
Vol:5
DDD: 3com.com
Suggested parameters are:
name description range
------------ ---------------------------- ------------
vol volume [1 - 100]
ring-vol ring volume [1 - 100]
op outbound proxy SIP-URI
ddd default dial domain domain name
ddp default dial prefix
sidetone sidetone [on off]
ring-pitch ring-pitch [400 - 4000]
id0 SIP identity of phone SIP-URI
pw0 password for phone's identity (encoded)
desc description for the phone
speed1 first speeddial SIP-URI
speed2 second speeddial SIP-URI
vm voicemail listen address SIP-URI
aa auto answer [on off]
dnd do not disturb [on off]
msg message waiting light [on off]
fwd 302 forwarding of all calls SIP-URI
8.6 Command: Hangup
This command will cause the phone to terminate a call. If the call is
not yet connected, the Master MAY include command line parameters of a
code and status for the final response to the INVITE.
The body of the hangup command MAY contain additional headers to be
included in the INVITE final response or BYE.
If the body contains a "To" or "From" header, these MUST match the
call leg or the hangup command is rejected.
Dean/Belkind [Page 9]
Internet Draft PHONECTL Protocol September 6, 2000
A hangup command could look like:
PHONECTL aphone.3com.com SIP/2.0
Via: SIP/2.0/UDP
To: aphone@3com.com
From: mypalm@3com.com
Cseq: 45632 PHONECTL
Call-ID: a3720f21
Command: hangup
Line: line2
Content-Length: 28
Content-Type: text
Also: billy@sip.sfour.com
Hangup command for a ringing call (abbreviated):
PHONECTL aphone.3com.com SIP/2.0
Command: hangup 600 Busy Everywhere
Line: line2
This method of including derived headers in the body of the message is
very powerful. For example by adding the Also header into the body of
the hangup command, this same command can be used to transfer a call.
8.7 Command: Login
The Login command allows the master to login and provide a phone with
credentials, so the phone has authority to place calls and register.
Revealing passwords is a security concern. It is not necessary for
some modes of operation, but is useful as an alternative to human
keying.
"Login" does not give the master authority to PHONECTL the phone. A
phone can regulate PHONECTL access with a 401 Unauthorized response to
a PHONECTL request. When this happens the master will reattempt the
PHONECTL with an authorization header. Alternatively, "Login" gives
the phone authorization to place SIP requests.
Through use of the expire header in the head and body of the PHONECTL
login request, the master can control whether inbound calls are
directed to the phone (body), and how long outbound calls are
authorized (header). Each login command causes the phone to issue a
REGISTER request for authentication. The headers in the body are
copied to the REGISTER request. If there is no expires header in the
body, the phone SHOULD use the expire header from the head. Expiring
credentials provided with a login command will be kept until
applicable connected calls complete, but stop working for new calls.
A login without an Expire header in the message's headers will be
treated as a non-expiring login. Masters are advised to use an expire
whenever possible due to flash writing considerations of embedded
Dean/Belkind [Page 10]
Internet Draft PHONECTL Protocol September 6, 2000
phones. A login command with an Expire header of 0 in the message's
head will logout a user.
An expire header in the PHONECTL head SHOULD use only the seconds-
from-present format, because simple user agent may not know what time
it is.
The login command will be successful (200 OK) even before a REGISTER
is sent. Masters wishing to track the progress of this resulting
REGISTER message should use the "list users" command. This helps
differentiate between a PHONECTL login failure, and a REGISTER request
failure.
Credentials will be given in a modified basic authorization header.
This format may contain the realm similar to how digest does it. A
master MAY choose to provide additional credentials beyond those
necessary to login. In this case the phone will attempt to use these
credentials before sending a 401 Unauthorized responses to the master.
Authorization headers in the header authenticate the PHONECTL
transaction, whereas Authorization headers in the body may be used to
authenticate the REGISTER.
For example...
PHONECTL aphone.3com.com SIP/2.0
Via: SIP/2.0/UDP 192.168.1.5
Command: Login
User: rick@sfour.com
Expire: 300
Access: digest, chap
To: aphone.3com.com
From: rick@3com.com
Cseq: 1232 PHONECTL
Call-ID: 1f9a8c77e6c3d4eb@192.168.1.5
Content-length: 14
Authorization: basic af342f422e2d23d32d3,realm=3com
Authorization: basic d69d30d3af342f422e2,realm="Columbia U"
Proxy-Authorization: basic d69d30d3af342f422e2,realm="foo baz"
Expire: 3600
Call flow for a password request:
Master phone far end
| | |
| Command: Login | |
|--------------------->| |
| 200 OK | |
| User: rick@3com.com | |
|<---------------------| REGISTER 3com.com |
| |-------------------->|
| | 401 |
| |<--------------------|
Dean/Belkind [Page 11]
Internet Draft PHONECTL Protocol September 6, 2000
| | REGISTER |
| | Authorization: |
| |-------------------->|
| | 200 OK |
| |<--------------------|
| Command: list user | |
|--------------------->| |
| 200 OK | |
| User:rick@3com.com | |
| Status: 200 OK | |
|<---------------------| |
| | |
8.8 Command: Query
The query command is used to retrieve the _to_, and _from_ of a call-
leg and additional stats. The query command MUST include a Line
header indicating the line being queried. The value of this header
MUST match a line name from a "List line" response.
The body of the query response MUST include the near and far names of
a call-leg which correspond to the To and From of a SIP message. The
phone may include additional information.
For example...
SIP/2.0 200 OK
Via:
Command: query
Line: line1
Cseq: 12321 PHONECTL
To: <rick@fdd.com>
From: <ronnen@belkind.net>
To: rick@fdd.com
From: ronnen@belkind.net
Contact: gw5.3com.com
Route: proxy1, proxy2, gw5.3com.com
Call-ID: 12312@myphone.3com.com
8.9 Command: Recent
The recent command allows the master to maybe retrieve a recent SIP
message received for this Call when available. The SIP message is
included in the body of the response. Due to maximum UDP message
restrictions, the SIP message may be incomplete.
Although not all SIP messages are available forever, of particular
nterest are 401 responses and call originating invites.
The recent request MUST include either a Line or User header.
Dean/Belkind [Page 12]
Internet Draft PHONECTL Protocol September 6, 2000
8.10 Command: Select
The select command makes a line off hook. Thus, it will answer a
ringing call.
This command MAY contain a device header (for example hold, handset,
speaker, or speakerphone). If device is omitted then a non-hold
device will be used. Any previously selected lines for that device
are put on hold.
To conference, multiple line headers are listed. A line may have only
one device, but a device may have multiple lines (e.g. when
conferencing). Be aware that the phone may be able to have different
lines selected to handset and speakerphone simultaneously.
For example to place the current handset call _line 1_ on hold, and
select line _line 2_:
PHONECTL aphone.3com.com SIP/2.0
Via: SIP/2.0/UDP
Command: select
Device: handset
Line: line 2
To: phone3@3com.com
From: mypc@3com.com
Content-length: 0
For example to conference line _1_ and _2_ on speakerphone:
PHONECTL aphone.3com.com SIP/2.0
Via: SIP/2.0/UDP
Command: select
Device: speakerphone
Line: 2
Line: 1
To: phone2@3com.com
From: mypc@3com.com
Cseq: 98343 PHONECTL
Call-ID: 34f34a@mypc.com
8.11 Command: Set
This command is used to set a phone specific parameter. The body
contains a list of headers (name:value). Any parameter not supported
is omitted in the body of the response. The response will contain the
modified value of the parameters.
For example (abbreviated):
PHONECTL myphone.3com.com SIP/2.0
Command: set
Dean/Belkind [Page 13]
Internet Draft PHONECTL Protocol September 6, 2000
Vol:9999
DDD:3com.com
Nonexistent: foo
The corresponding response (abbreviated):
SIP/2.0 200 OK
Command: set
Vol: 100
DDD:3com.com
9. Examples (to be expanded)
* Place a call.
PHONECTL aphone.3com.com SIP/2.0
Via: SIP/2.0/UDP
To: sip:myphone.3com.com
From: sip:mypc.3com.com
Cseq: 234234
Call-ID: 098df3j34
Command: dial
To: sip:sales@3com.com
From: sip: belkind@3com.com
* Terminate a call.
PHONECTL phone7.3com.com SIP/2.0
Via: 224.0.1.75 SIP/2.0/UDP
To: sip:phone6.3com.com
From: sip: mypalm.3com.com
Cseq: 823787191
Call-ID 0928f92bd
Command: Hangup
Line: line4
* Answering a call with handset, speakerphone, etc.
PHONECTL phone7.3com.com SIP/2.0
Via: 224.0.1.75 SIP/2.0/UDP
To: sip:phone6.3com.com
From: sip: mypalm.3com.com
Cseq: 823787191
Call-ID 0928f92bd
Command: Select
Line: Line3
Device: handset
PHONECTL phone7.3com.com SIP/2.0
Via: 224.0.1.75 SIP/2.0/UDP
To: sip:phone6.3com.com
From: sip: mypalm.3com.com
Dean/Belkind [Page 14]
Internet Draft PHONECTL Protocol September 6, 2000
Cseq: 823787191
Call-ID 0928f92bd
Command: Select
Line: Line3
Device: speakerphone
* Conferencing.
PHONECTL phone7.3com.com SIP/2.0
Via: 224.0.1.75 SIP/2.0/UDP
To: sip:phone6.3com.com
From: sip: mypalm.3com.com
Cseq: 823787191
Call-ID 0928f92bd
Command: Select
Line: Line3
* Line: Line1
Device: speakerphone
* Mute a call.
??? Do we make this a device ???
* Forward an existing or future call.
??? forward a future call ???
* Set volume control.
* Login/Logout
* Get a list of setta ble parameters.
* Set any or all of the phone parameters.
* Determine the state of the phone. (current calls, call state,
active/logged in users, ect_)
* Digest without sharing plain-text password to phone
* PDA to PDA communication for previously established call.
* Locating a phone via multicast address over infrared.
* Error conditions
10. Security Considerations
Although passing passwords in plaintext is terrible security, there
are many applications where users already memorize and enter a
personal identification number (PIN). This is essentially plaintext.
Changing these PINs frequently, choosing them long, and using unique
ones for each system is good practice but presents a significant
memorization problem. Storing these passwords on a personal digital
assistant (PDA), which delivers them electronically, can improve the
handling. PHONECTL helps to implement this.
It is assumed that most use of the PHONECTL method will be for
physically local devices, as an alternative to human keying. Much of
the communication will be over direct device-to-device channels such
as infrared. Thus, sensitive information such as the list of active
users is not as compromising.
Dean/Belkind [Page 15]
Internet Draft PHONECTL Protocol September 6, 2000
Phones MAY require different PHONECTL passwords based on the command
requested.
10.1 Digest without revealing password to phone
Using PHONECTL it is possible to place a call using digest
authentication without revealing the password to the phone. This does
not use the password command of PHONECTL.
The master would place the call without credentials, which would fail.
The master can learn of the failure by polling with the last command.
Using the recent command the master can learn the nonce. The PDA can
then issue a re-invite with the proper credentials using the dial
command with a line header. Using the line header will keep the same
call-id and thus the nonce valid. The phone SHOULD remember any
authorization headers and repeat them throughout the lifetime of the
call leg for preemptive authorization.
Obviously, if the authorization requiring entity demands new nonces
every message (i.e. with the Authorization Info header), and the
master is unwilling to give the password to the phone, then the master
needs to stay around for the duration of the call. The master should
consider proxying the call if this is the case.
10.2 PGP strong encryption
If a SIP PGP application is available with full time network
connectivity, then it should probably proxy the calls itself. Through
the use of contact, route, and record-route headers, the PGP proxy can
choose to remain or not in the signaling path after the call connects.
Using the PHONECTL method of SIP, the PGP capable proxy can initiate
the phone call from an embedded phone.
11. Infrared
If PHONECTL is used over infrared, it is recommended that the IR
channel use PPP for the layer 2 protocol. The PHONECTL master should
specify the well known SIP multicast address of 224.0.?.? as the
destination.
12. References
Handley, M., Schulzrinne, H., Schooler, E., and Rosenberg, J., _SIP:
Session Initiation Protocol_, RFC2543, March 1999
Franks, J., Hallam-Baker, P., Hostetler, J., Leach, P., Luotonen A.,
Sink, E., and Stewart, L., _An extension to HTTP: Digest Access
Authentication_, RFC2069, January 1997
Dean/Belkind [Page 16]
Internet Draft PHONECTL Protocol September 6, 2000
Crocker, David H., _Standard for the Format of ARPA Internet Text
Messages_, RFC822, August 13, 1982
13. Authors' Addresses
Rick Dean
3Com
3800 Golf Road
Rolling Meadows, IL 60008
Rick_Dean@3com.com
Ronnen Belkind
3Com
3800 Golf Road
Rolling Meadows, IL 60008
Ronnen_Belkind@3com.com
14. Table Of Contents
1. Status of This Memo......................................1
2. Abstract.................................................1
3. Terminology..............................................1
4. Definitions..............................................2
5. Introduction.............................................2
6. Protocol.................................................3
7. Headers..................................................3
7.1 Access .................................................3
7.2 Command ................................................3
7.3 Device .................................................4
7.4 Line ...................................................4
7.5 User ...................................................5
8. Commands.................................................5
8.1 Command: Capablity .....................................5
8.2 Command: Dial ..........................................5
8.3 Command: Digits ........................................6
8.4 Command: List ..........................................7
8.4.1 Command: List lines ...............................7
8.4.2 Command: List Users ...............................8
8.5 Command: Get ...........................................8
8.6 Command: Hangup ........................................9
8.7 Command: Login ........................................10
8.8 Command: Query ........................................12
8.9 Command: Recent .......................................12
8.10 Command: Select ......................................13
8.11 Command: Set .........................................13
9. Examples (to be expanded)...............................14
10. Security Considerations.................................15
10.1 Digest without revealing password to phone ...........16
10.2 PGP strong encryption ................................16
11. Infrared................................................16
12. References..............................................16
Dean/Belkind [Page 17]
Internet Draft PHONECTL Protocol September 6, 2000
13. Authors' Addresses......................................17
14. Table Of Contents.......................................17
15. Full Copyright Statement................................18
15. Full Copyright Statement
Copyright (c) The Internet Society (1999). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published and
distributed, in whole or in part, without restriction of any kind,
provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of developing
Internet standards in which case the procedures for copyrights defined
in the Internet Standards process must be followed, or as required to
translate it into languages other than English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT
NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN
WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Dean/Belkind [Page 18]