idnits 2.17.1 draft-biggs-sip-replaces-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 249 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The abstract seems to contain references ([2]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 109: '... Replaces header MUST be ignored. The...' RFC 2119 keyword, line 115: '... MAY use the Referred-By header if p...' RFC 2119 keyword, line 120: '... agent SHOULD silently accept the ne...' RFC 2119 keyword, line 121: '... The user agent SHOULD also shut down...' Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (May 2001) is 8381 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 2543 (ref. '2') (Obsoleted by RFC 3261, RFC 3262, RFC 3263, RFC 3264, RFC 3265) -- No information found for draft-ietf-sip-cc - is the name correct? -- Possible downref: Normative reference to a draft: ref. '3' == Outdated reference: A later version (-05) exists of draft-ietf-sip-cc-transfer-02 -- Possible downref: Normative reference to a draft: ref. '4' Summary: 7 errors (**), 0 flaws (~~), 3 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Engineering Task Force Biggs/Dean 2 Internet Draft 3Com 3 draft-biggs-sip-replaces-00.txt 4 November 2000 5 Expires May 2001 7 The SIP Replaces Header 9 Status of this Memo 11 This document is an Internet-Draft and is in full conformance with 12 all provisions of Section 10 of RFC2026 [1]. 14 Internet-Drafts are working documents of the Internet Engineering 15 Task Force (IETF), its areas, and its working groups. Note that other 16 groups may also distribute working documents as Internet-Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six months 19 and may be updated, replaced, or obsoleted by other documents at any 20 time. It is inappropriate to use Internet-Drafts as reference 21 material or to cite them other than as work in progress. 23 The list of current Internet-Drafts can be accessed at 24 http://www.ietf.org/ietf/1id-abstracts.txt 26 The list of Internet-Draft Shadow Directories can be accessed at 27 http://www.ietf.org/shadow.html 29 This document is an individual submission to the IETF. Comments 30 should be directed to the authors. 32 Abstract 34 This document describes an extension to the Session Initiation 35 Protocol (SIP) [2]. The purpose of this extension is to provide a 36 method for allowing an active call-leg to be replaced by a new 37 incoming call-leg for the purposes of call handoff. 39 1 Overview 41 This document defines a SIP [2] extension to help provide attended 42 transfer or call handoff capabilities. This header has its roots in 43 [3], however both the syntax and semantics are changed. 45 Call handoff occurs when a SIP user agent which is involved in a 46 3-way call conference wishes to silently leave the call by requesting 47 the two remote parties to establish a direct signalling relationship. 48 While the transfer functionality provided by REFER [4] allows the 49 conference initiator to connect the two remote parties, there is no 50 standard way for the target of the transfer to associate the incoming 51 call with the active one. 53 The header defined here is intended to provide a simple and backwards 54 compatible method to allow this association to occur. We also define 55 a signature scheme which allows the replacement request to be 56 authenticated by the target user agent. 58 2 Rationale 60 1. Using a Replaces header in the request makes the intent obvious. 62 2. A unique call-id may be given to the replacement call, which helps 63 call leg matching. 65 3. No adverse effects if the header is unsupported. 67 3 The Replaces Header 69 The Replaces header is used to indicate that the call leg identified 70 in the header is to be shut down and logically replaced by the 71 incoming INVITE in which it is contained. It is a request header 72 only, and defined here only for INVITEs. The syntax is: 74 Replaces = "Replaces" ":" 1#replaces-values 75 replaces-values = callid *( ";" replaces-param ) 76 callid = token [ "@" token ] 77 replaces-param = to-tag | from-tag | rep-signature 78 | extension-param 79 to-tag = "to-tag=" UUID 80 from-tag = "from-tag=" UUID 81 rep-signature = signature-scheme *( ";" sig-scheme-params ) 82 signature-scheme = "scheme" "=" token 83 sig-scheme-parms = token "=" ( token | quoted-string ) 85 3.1 Examples 87 Replaces: 98732@sip.billybiggs.com 89 Replaces: 12345@149.112.118.3;to-tag=12345;from-tag=54321 91 3.2 A PGP based signature-scheme 93 One signature-scheme for Replaces headers uses PGP as follows: 95 signature-scheme = "scheme" "=" "pgp" 96 sig-scheme-parms = pgp-version | signed-by | pgp-signature 98 pgp-version, signed-by and pgp-signature are defined in section 15.1 99 of RFC2543, with the modification that the signature is computed 100 across the concatenation of the callid, to-tag, and from-tag in that 101 order. 103 4 Behavior of SIP User Agents 105 The Replaces header contains matching information for a call-leg, 106 identified by the call-id and related tags. Upon receiving an INVITE 107 with a Replaces header, the user agent will attempt to match the 108 information with any active call legs. If no match is found, the 109 Replaces header MUST be ignored. The to tag and from tag should be 110 matched as if they were present in an incoming request, that is, the 111 to tag should match the local tag for the call leg, and the from tag 112 should match the remote tag. 114 If the replaces header matches more than one call-leg, the user agent 115 MAY use the Referred-By header if present to attempt to match the 116 call with an appropriate call-leg, but should otherwise ignore the 117 header. 119 If a matching call-leg is found and the signature checked, the user 120 agent SHOULD silently accept the new call, replacing the old call in 121 the user interface. The user agent SHOULD also shut down the 122 replaced call leg by sending a BYE. 124 5 Attended Call Transfer to a Supporting Target 126 In these examples, the names of the actors are taken from [4]. 128 In this scenario, the transferor is in a 3-way call with both the 129 transferee and the transfer target and wishes to leave the call. The 130 transferor REFERs the transferee to the transfer target, using the 131 Replaces header to signify to the target that the incoming call 132 should replace its current call to the transferor. The replaces 133 header is placed as a header parameter in the SIP URI used in the 134 Refer-To header. 136 After accepting the call, the target's BYE is received by the 137 transferor before it has a chance to send its own BYE. 139 Transferor Transferee Transfer 140 | | Target 141 | | | 142 Call-ID:1 | INVITE/200 OK/ACK | | 143 |<----------------------->| | 144 | | | 145 Call-ID:2 | INVITE/200 OK/ACK | | 146 |<--------------------------------------------->| 147 | | | 148 | REFER target?Replaces=1 | | 149 |------------------------>| | 150 | 100 Trying | | 151 |<------------------------| | 152 | | INVITE Replaces:1 | 153 | |-------------------->| Immediate 154 | | 200 OK/ACK | Acceptance 155 | |<------------------->| 156 | | BYE/200 OK | 157 |<--------------------------------------------->| 158 | 200 OK (to the REFER) | | 159 |<------------------------| | 160 | BYE/200 OK | | 161 |<----------------------->| | 162 | | | 164 6 Attended Call Transfer to an Unsupporting Target 166 In this scenario, the transfer target ignores the Replaces header. 167 In this case, the transferor sends a BYE to confirm shutdown of the 168 replaced call. 170 Transferor Transferee Transfer 171 | | Target 172 | | | 173 Call-ID:1 | INVITE/200 OK/ACK | | 174 |<----------------------->| | 175 | | | 176 Call-ID:2 | INVITE/200 OK/ACK | | 177 |<--------------------------------------------->| 178 | | | 179 | REFER target?Replaces=1 | | 180 |------------------------>| | 181 | 100 Trying | | 182 |<------------------------| | 183 | | INVITE Replaces:1 | 184 | |-------------------->| User 185 | | 200 OK/ACK | Accepts 186 | |<------------------->| Call 187 | 200 OK (to the REFER) | | 188 |<------------------------| | 189 | BYE/200 OK | | 190 |<--------------------------------------------->| 191 | BYE/200 OK | | 192 |<----------------------->| | 193 | | | 195 7 Author's Addresses 197 Billy Biggs 198 3Com 199 3800 Golf Rd 200 Rolling Meadows, IL 201 USA 203 Phone: sip:Billy_Biggs@sip.3com.com 204 Email: Billy_Biggs@3com.com 206 Rick Dean 207 3Com 208 3800 Golf Rd 209 Rolling Meadows, IL 210 USA 212 Phone: sip:Rick_Dean@sip.3com.com 213 Email: Rick_Dean@3com.com 215 8 References 217 [1] S. Bradner, "The Internet Standards Process -- Revision 3", 218 BCP9, RFC2026, October 1996. 220 [2] M. Handley, H. Schulzrinne, E. Schooler, and J. Rosenberg, 221 "SIP:Session Initiation Protocol", RFC 2543, March 1999. 223 [3] H. Schulzrinne, J. Rosenberg, "SIP Call Control Services", 224 Internet Draft draft-ietf-sip-cc-01, Internet Engineering Task 225 Force, June 17, 1999 Work in Progress (expired). 227 [4] R. Sparks, "SIP Call Control: Transfer", Internet Draft 228 draft-ietf-sip-cc-transfer-02.txt, Internet Engineering Task 229 Force, November 2000, Work in Progress.