Internet Engineering Task Dean/Belkind Internet Draft 3Com draft-dean-phonectl-01.txt May 11, 2000 Expires: September, 2000 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 May 11, 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. 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. Although one could handle them separately, and the protocol allows that for a GUI assistant, as presented on the phone we assume this is simply login for both directions. Similar to existing email clients, phones may refuse honor a login's "from" for outbound calls if they cannot register that address of record. 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. Dean/Belkind [Page 2] Internet Draft PHONECTL Protocol May 11, 2000 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" | "list" | "query" | "recent" | "login" Dean/Belkind [Page 3] Internet Draft PHONECTL Protocol May 11, 2000 | "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" 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. 7.5 User This header is used by the login command. It is used to identify a user. Dean/Belkind [Page 4] Internet Draft PHONECTL Protocol May 11, 2000 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 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. Dean/Belkind [Page 5] Internet Draft PHONECTL Protocol May 11, 2000 Master phone far end | Command: Dial | | |----------------->| | | 200 OK | | | Line: foo | | |<-----------------| INVITE | | |-------------------->| | | 401 Unauthorized | | |<--------------------| |Command: list line| | |----------------->| | | 200 OK | | | Line: foo | | | Device: handset | | | Status: 401 Unathorized | | | WWW-Authenticate:| | |<-----------------| | | Command: Dial | | | Line: foo | | | Authorization: | | |----------------->| | | 200 OK | | | Line: foo | | |<-----------------| INVITE | | | Authorization: | | |-------------------->| | | 200 OK | | |<--------------------| | | | 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 Command: Digits 5551212 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. Dean/Belkind [Page 6] Internet Draft PHONECTL Protocol May 11, 2000 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. 1. 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: "Jack" <5551212@sfour.com> From: Rick@3com.com Device: handset Line: lineName2 Status:200 To: "Bill" <7005554141@sfour.com> From: Rick@3com.com Device: hold Line: lineName3 Status:401 Authentication Required To: Rick@3com.com From: "Sarah" <911@sfour.com> Device: hold 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 Dean/Belkind [Page 7] Internet Draft PHONECTL Protocol May 11, 2000 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@fdd.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 parameter=value lines in the body of the message. Just like a tag, spaces around the equal sign are not permitted. Parameter names are case insensitive. 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): PHONECTL myphone.3com.com SIP/2.0 Command: get Content-length: 26 Volume DDD IP-Addr Nonexistent Dean/Belkind [Page 8] Internet Draft PHONECTL Protocol May 11, 2000 The corresponding response (abbreviated): SIP/2.0 200 OK Command: get Content-length: 20 Volume=5 IP-Addr=192.168.1.9 DDD=3com.com 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. 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: joe@sip.provider.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. Dean/Belkind [Page 9] Internet Draft PHONECTL Protocol May 11, 2000 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 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. For example... PHONECTL aphone.3com.com SIP/2.0 Via: SIP/2.0/UDP 192.168.1.5 Command: Login User: rick@sfour.com Authorization: basic af342f422e2d23d32d3,realm=3com Authorization: basic d69d30d3af342f422e2,realm=worldcom Dean/Belkind [Page 10] Internet Draft PHONECTL Protocol May 11, 2000 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 Expire: 3600 Call flow for a password request: Master phone far end | | | | Command: Login | | |--------------------->| | | 200 OK | | | User: rick@x.com | | |<---------------------| REGISTER x.com | | |-------------------->| | | 401 | | |<--------------------| | | REGISTER | | | Authorization: | | |-------------------->| | | 200 OK | | |<--------------------| | Command: list user | | |--------------------->| | | 200 OK | | | User:rick@x.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 Dean/Belkind [Page 11] Internet Draft PHONECTL Protocol May 11, 2000 Line: line1 Cseq: 12321 PHONECTL To: From: 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. 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: Dean/Belkind [Page 12] Internet Draft PHONECTL Protocol May 11, 2000 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 parameter=value, one per line. Just like a tag, spaces around the equal sign are not permitted. Any parameter that is 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 Volume=9999 DDD=3com.com Nonexistent=foo The corresponding response (abbreviated): SIP/2.0 200 OK Command: set Volume=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 Dean/Belkind [Page 13] Internet Draft PHONECTL Protocol May 11, 2000 * 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 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. Dean/Belkind [Page 14] Internet Draft PHONECTL Protocol May 11, 2000 * 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. 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. Dean/Belkind [Page 15] Internet Draft PHONECTL Protocol May 11, 2000 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 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 Dean/Belkind [Page 16] Internet Draft PHONECTL Protocol May 11, 2000 5. Introduction.............................................2 6. Protocol.................................................2 7. Headers..................................................3 7.1 Access .................................................3 7.2 Command ................................................3 7.3 Device .................................................4 7.4 Line ...................................................4 7.5 User ...................................................4 8. Commands.................................................5 8.1 Command: Capablity .....................................5 8.2 Command: Dial ..........................................5 8.3 Command: Digits ........................................6 8.4 Command: List ..........................................6 8.4.1 Command: List lines ...............................6 8.4.2 Command: List users ...............................8 8.5 Command: Get ...........................................8 8.6 Command: Hangup ........................................9 8.7 Command: Password .....................................10 8.8 Command: Query ........................................11 8.9 Command: Recent .......................................12 8.10 Command: Select ......................................12 8.11 Command: Set .........................................13 9. Examples (to be expanded)...............................13 10. Security Considerations.................................15 10.1 Digest without revealing password to phone ...........15 10.2 PGP strong encryption ................................16 11. Infrared................................................16 12. References..............................................16 13. Authors' Addresses......................................16 14. Table Of Contents.......................................16 15. Full Copyright Statement................................17 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. Dean/Belkind [Page 17] Internet Draft PHONECTL Protocol May 11, 2000 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]