SIP Working Group S. Lass Internet Draft WorldCom Expires: January 2002 July 2001 Category: Standards Track Remote Call Setup draft-lass-sip-remote-call-setup-00.txt Status of this Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026 [1]. 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. Please send comments to the author or the working group discussion list. Abstract This document describes a method for 3rd Party call setup using the SIP REFER [2] message. Overview There are cases where a back to back user agent (B2BUA) for call control is necessary. However, there are also cases where a simple mechanism for 3rd party call setup is necessary. Examples include using wireless personal digital assistants and personal computers with address book software to initiate a call from the user's SIP [3] Lass [Page 1] RFC DRAFT Remote Call Setup July 2001 client. Conventions used in this document The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC-2119[4]. Motivation There are many cases where address book and "click to dial" integration is desired. Dialing a SIP URL on a telephone keypad can be tedious. Operation A call setup agent sends a SIP REFER message to initiate a new session. The call setup agent should use the request URI to determine where to send the message. The call setup agent may send the message directly to the UAC, especially for loopback addresses. The UAC can differentiate between a REFER request for call setup and a request to act on an existing session by examining the To: header. A call setup request will not have a tag-param in the To: header. An existing call will have a tag-param in the To: header. The Refer-To and Referred-By headers should be signed. For limited deployment, between a user's UACs and setup agents, a HMAC [5] scheme using a shared secret could be use. For large deployments, a more scalable signature scheme should be used. Once the interaction between the call setup agent and the UAC is completed, the UAC should behave as the initiator of a new session with the destination. HMAC based signature scheme The HMAC signature is calculated with the HMAC text as the concatenation of the Refer-To and Referred-By headers and the HMAC key as a shared secret. signature-scheme = "scheme" "=" "rfc2104" sig-scheme-parms = rfc2104-signature | rfc2104-hash rfc2104-hash = "hash" "=" "md5" Lass [Page 2] RFC DRAFT Remote Call Setup July 2001 rfc2104-signature = "signature" "=" quoted-string Example Message REFER sip:sipclient@domain.com SIP/2.0 Via: SIP/2.0/UDP agent.domain.com To: sip:sipclient@domain.com From: sip:simpleagent@agent.domain.com;tag=6862345324 Call-ID: 6862345324@agent.domain.com CSeq: 6862345324 REFER Refer-To: Referred-By: ; ref=;scheme=rfc2104;hash=md5; signature="the signature" Contact: sip:simpleagent@1.1.1.1:23653 Content-Length: 0 High Level Call Flow Agent Client Other | | | | REFER | | |------------------->| | | 202 Accepted | | |<-------------------| | | | | | | INVITE | | |------------------->| | | | Security Considerations SIP UACs implementing this functionality should not use the same password used to authenticate SIP INVITE messages as the shared secret. A malicious 3rd party could launch a password attack against the client. Since clients typically will not have intrusion detection systems, they should provide alerting for failed setup attempts and temporarily disable support after a specified number of failed attempts. The Referred-By header should contain a date param. The date param Lass [Page 3] RFC DRAFT Remote Call Setup July 2001 should be evaluated by the UAC to reject a replay attack. If the date param is not present, the UAC should request the setup agent to authenticate. For personal computers requiring integration between their call setup agents and UACs, the UACs should be configured to only accept call setup requests from their loopback address. All SIP UACs must require user intervention to proceed with a successful call setup. UACs with handsets could provide visual alerting and require the user to lift the handset to initiate the call. Personal computer based UACs could display a dialog box and require the user to accept the call setup. If the setup agent only initiates new sessions, it is not necessary for the agent to listen on the default SIP port. The agent could be a transient program and specify its listening port via the Contact header. References 1 Bradner, S., "The Internet Standards Process - Revision 3", RFC 2026, October 1996 2 Sparks, R., "SIP Call Control - Transfer", draft-ietf-sip-cc- transfer-04 (work in progress), February 2001. 3 Handley, et. al., "Session Initiation Protocol", RFC 2543, March 1999 4 Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997 5 Krawczyk, et. al., "HMAC: Keyed-Hashing for Message Authentication", RFC 2104, February 1997 Author's Address Steven Lass WorldCom MailStop 41239/041 400 International Parkway Richardbson, TX 75081 Email: steven.lass@wcom.com Lass [Page 4] RFC DRAFT Remote Call Setup July 2001 Full Copyright Statement "Copyright (C) The Internet Society (2001). 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 ENINEERING TASK FORCE DICLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRENTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRENTIES OF MERCAHNTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Lass [Page 5]