idnits 2.17.1 draft-elwell-sipping-service-retargeting-00.txt: -(358): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(361): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(364): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(417): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(420): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(424): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(429): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(433): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(438): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(475): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 17. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 950. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 956. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 970), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 35. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** The document seems to lack an RFC 3978 Section 5.5 (updated by RFC 4748) Disclaimer -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack an RFC 3979 Section 5, para. 1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == There are 18 instances of lines with non-ascii characters in the document. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 35 instances of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. ** 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 304: '... A UAC MAY use service redirection i...' RFC 2119 keyword, line 313: '...or service reasons, a proxy MAY add an...' RFC 2119 keyword, line 317: '...et URI, this too MUST contain the same...' RFC 2119 keyword, line 322: '...service reasons, a redirect MAY add an...' RFC 2119 keyword, line 328: '... A UAS MAY use service redirection i...' (10 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- 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 (October 2005) is 6768 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) == Missing Reference: 'RFCAAAA' is mentioned on line 753, but not defined -- Looks like a reference, but probably isn't: '4' on line 845 -- No information found for draft-ietf-sipping-history-info - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'HIST' ** Downref: Normative reference to an Informational RFC: RFC 3087 (ref. 'SRVCTRL') ** Downref: Normative reference to an Informational RFC: RFC 3325 (ref. 'PASSERT') Summary: 8 errors (**), 0 flaws (~~), 5 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force J. Elwell 3 Internet Draft Siemens 4 F. Audet 5 Nortel 6 draft-elwell-sipping-service-retargeting-00.txt 7 Expires: April 2006 October 2005 9 Indicating Service Retargeting in the Session Initiation Protocol 10 (SIP) 12 Status of this Memo 14 By submitting this Internet-Draft, each author represents that any 15 applicable patent or other IPR claims of which he or she is aware 16 have been or will be disclosed, and any of which he or she becomes 17 aware will be disclosed, in accordance with Section 6 of BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that other 21 groups may also distribute working documents as Internet-Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress. " 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 Copyright Notice 35 Copyright (C) The Internet Society (2005). All Rights Reserved. 37 Abstract 39 This contains motivation, requirements and a proposed solution for 40 indicating service retargeting information in SIP requests and 41 responses. Retargeting of a request can be considered to be service 42 retargeting when it goes beyond "normal" routing and might be of 43 interest to applications at the UAS or UAC. 45 Table of Contents 47 1 Introduction....................................................3 48 2 Requirements....................................................5 49 3 Overview of the solution........................................6 50 4 Behaviour.......................................................7 51 4.1 UAC behaviour.................................................7 52 4.2 Proxy behaviour...............................................7 53 4.3 Redirect behaviour............................................8 54 4.4 UAS behaviour.................................................8 55 5 Syntax..........................................................8 56 6 PSTN Mapping....................................................9 57 7 Examples.......................................................11 58 7.1 Proxy forwards busy to deputy................................11 59 7.2 Endpoint forwards busy to deputy.............................13 60 7.3 Endpoint forwards busy to TDM via a gateway..................14 61 7.4 Endpoint forwards busy to deputy with History Info...........15 62 8 IANA considerations............................................17 63 9 Security Considerations........................................17 64 9.1 Integrity Protection of Forwarding in SIP....................18 65 9.2 Privacy Related Issues on the Second Call Leg................18 66 10 Acknowledgements..............................................19 67 11 Author's Addresses............................................20 68 12 Normative References..........................................20 69 13 Appendix - Rejected Alternatives (temporary � to be removed)..21 70 13.1 Extending the SIP Reason header.............................22 71 13.2 New 3xx response codes......................................22 73 1 Introduction 75 Central to SIP [SIP] is the concept of retargeting a request by a 76 proxy, whereby the Request-URI in the original request is replaced 77 before forwarding the request on the next hop. Retargeting can also 78 occur because of redirection by a redirect server using a SIP 3xx 79 response code and subsequent recursion by the UAC or a proxy. Except 80 where otherwise stated, the term retargeting is used in this document 81 to cover recursion as well as retargeting. A given request from a 82 User Agent Client (UAC) can be retargeted zero or more times before 83 reaching the User Agent Server (UAS). 85 Retargeting is a normal part of routing a request in SIP. For 86 example, an outbound proxy might convert the initial Request-URI from 87 a telephone URI (perhaps in the form of a dial string) to a SIP URI. 88 As another example, the final proxy typically replaces an Address of 89 Record with the URI of a registered contact. 91 However, sometimes a service running at a proxy or redirect server 92 (including a UA acting as a redirect server) can initiate retargeting 93 to a specific service URI. Retargeting of this nature can be called 94 service retargeting, because it is based on special services that 95 operate on incoming requests to a target. An example of service 96 retargeting can be found in [SRVCTRL]. [SRVCTRL] specifies a means 97 for communicating context information to an application, with the 98 expectation that the recipient endpoint or application understands 99 the implications of the context information. Typically the original 100 target user will have made arrangements for service retargeting. 101 Service retargeting can be based on simple or complex rules for 102 handling requests to the original target. 104 For example, a request could be retargeted to a destination that can 105 handle requests that encounter busy or no reply at the original 106 target. As another example, a user could arrange that requests 107 targeted at the user be retargeted to a deputy, perhaps because the 108 original user expects to be absent or does not wish to be disturbed. 109 The fact that a request has been service retargeted is often of 110 interest to the users involved, i.e., the retargeted-to user and the 111 calling user, or to an application. Therefore it would be very useful 112 to provide to the UAS and the UAC details of retargeting in the form 113 of the original target URI, the retargeted-to URI and the reason for 114 retargeting. 116 Service retargeting information is also useful when interworking with 117 PSTN/ISDN. Service retargeting in SIP is similar to diversion in 118 PSTN/ISDN, and therefore service retargeting information in SIP can 119 be mapped to/from diversion information in PSTN/ISDN. For example, 120 for a call that is service retargeted in the SIP network because the 121 original target is busy, if the new target is in PSTN/ISDN the 122 PSTN/ISDN can be told that the call has been diverted on busy. 124 As a further example, service retargeting information can be of use 125 to a voice mail server. When a request is service retargeted to a 126 voice mail server the voice mail server is likely to need to know the 127 identity of the original target in order to access the correct 128 mailbox and the reason for service retargeting in order to behave 129 appropriately, e.g., play an appropriate announcement. 131 In all these examples, information about normal SIP retargeting, as 132 opposed to service retargeting, is not generally of interest. 134 [HIST] specifies a means of providing the UAS and UAC with 135 information about the retargeting of a request. This information 136 includes the initial Request-URI and any retarget-to URIs. This 137 information is placed in the History-Info header, field, which, 138 except where prevented by privacy considerations, is built up as the 139 request progresses and, on reaching the UAS, is returned in certain 140 responses. Within the History-Info header field, each URI, except for 141 the final one, includes as a parameter a Reason Header [REASON] 142 indicating the SIP response code that led to retargeting from that 143 URI to the next URI. This is either the response code received as a 144 result of forwarding the request to that URI or the nearest 145 equivalent if retargeting occurs without having forwarded the 146 request. 148 [HIST], when deployed at relevant SIP entities and not subject to 149 privacy, is intended to provide a comprehensive trace of retargeting 150 for a SIP request, along with the SIP response codes that led to 151 retargeting. [HIST] is captured independently of any service 152 interactions that might have resulted in retargeting. [HIST] 153 captures the information independently of how an endpoint might make 154 use of the information. Thus, it does not fully meet the needs of 155 reporting service retargeting for the following reasons: 157 - [HIST] reports all retargets, not just service retargets. This puts 158 the burden on the UAS or UAC to pick out which retargets are for 159 service reasons and which are for normal SIP routing reasons. 161 - [HIST] reports reasons in the form of SIP response codes, which do 162 not necessarily reflect service reasons for retargeting very well and 163 are not always meaningful to applications. 165 - The SIP response codes captured by [HIST] are dependent upon 166 whether retargeting is as a result of recursion or not. When 167 recursion is used, the SIP response code will always be in the 3xx 168 range, but otherwise, even if the reason for retargeting is 169 identical, the reason will not be in the 3xx range. For example, if 170 retargeting is due to the previous target being busy, the SIP 171 response code used without recursion would normally be 486, but with 172 recursion it would have to be a 3xx response code (e.g., 302). 174 This document defines a mechanism that provides simple but meaningful 175 information to a service retargeted-to user or application to 176 represent the most recent retarget of a request. The mechanism makes 177 use of the solution approach specified in [SRVCTRL], which provides 178 the flexibility to provide service retargeting information in SIP 179 requests. When used in conjunction with [HIST] it provides more 180 comprehensive information to the retargeted-to user or application 181 and also to the calling user or application. Although aimed primarily 182 at INVITE requests, it can in principle apply to other SIP methods. 184 2 Requirements 186 REQ-1. When forwarding a service-retargeted request to a UAS, it must 187 be possible to include information that denotes the service reason 188 for service retargeting and the previous target, in order to assist 189 the user or application in determining how to behave, e.g.: 191 - how to respond to the request; 192 - in the case of an INVITE request that is answered, how to behave 193 during the established session (e.g., greeting to be given). 195 REQ-2. It must be possible to include this information in a service- 196 retargeted request to a UAS also in the case where service 197 retargeting has been followed by retargeting that is not service 198 retargeting. 200 REQ-3. When a request from a UAC has been service-retargeted, it must 201 be possible to include information in a response that denotes the 202 reason for service retargeting and new target, in order to assist the 203 user in determining how to behave, e.g.: 205 - in the case of a failed request, under what circumstances it might 206 be appropriate to re-attempt the request (e.g., if retargeted because 207 of busy but the new target does not answer, it might be appropriate 208 to retry a few minutes later); 209 - in the case of an INVITE request that results in an established 210 session, whether to abandon that session and if so under what 211 circumstances it might be appropriate to re-attempt the request; 212 - in the case of an INVITE request that results in an established 213 session, how to behave during that session (e.g., greeting to be 214 given). 216 REQ-4. It must be possible to indicate that the reason for 217 retargeting is because there are no registered contacts for the URI. 219 REQ-5. It must be possible to indicate that the reason for 220 retargeting is because contacts for the URI are busy. 222 REQ-6. It must be possible to indicate that the reason for 223 retargeting is because the request was not answered during the 224 alerting period. 226 REQ-7. It must be possible to indicate that the reason for 227 retargeting is because the user has arranged for requests to be 228 retargeted irrespective of the state of registered contacts. 230 REQ-8. It must be possible to indicate that the reason for 231 retargeting is because the user declined the request during alerting. 233 REQ-9. It must be possible to indicate that the reason for 234 retargeting is because the user has arranged for requests to be 235 distributed among a number of targets. 237 REQ-10. It must be possible to indicate that the reason for 238 retargeting is because of network conditions. 240 REQ-11. It must be possible to indicate (e.g., by default) that there 241 is no service reason for retargeting. 243 REQ-12. It must be possible to extend the list of service retargeting 244 reasons in the future. 246 REQ-13. It must be possible to suppress information concerning 247 service retargeting in order to reflect network policy or respect the 248 wishes of the retargeted-from user. 250 3 Overview of the solution 252 [SRVCTRL] describes how URI parameters can be used to control a 253 service or application at the UAS by providing appropriate context 254 information. It describes this only in principle, without assigning 255 any new URI parameter names or values. For a given deployment, the 256 principles can be used to achieve control of a service or application 257 by configuring the appropriate URI parameter names and values at the 258 equipment concerned or by using equipment with appropriate 259 capabilities from a single vendor. This requires a lot of 260 coordination for configuring the various pieces of equipment, 261 matching service URIs, mapping service URIs to phone numbers, etc. 262 Further standardisation is required to allow easy deployment of 263 equipment from different vendors and with various level of 264 capabilities. 266 The solution here adopts the principles of [SRVCTRL] and defines 267 parameter names and values for indicating retargeting details to a 268 service or application. This enhancement to SIP, when used alone, is 269 sufficient to satisfy the needs of some applications and can also 270 provide useful information to a retargeted-to user. When used in 271 conjunction with [HIST] it can provide very comprehensive information 272 not only to retargeted-to applications and users but also to source 273 applications and users. 275 When a request is service retargeted (for a reason meaningful to a 276 retargeted-to user or application), two parameters are added to the 277 retargeted-to URI: the old-target parameter contains the previous 278 target URI and the retargeting-reason parameter contains the reason 279 for service retargeting. Provided this is the last retarget, these 280 parameters will reach the UAS and can be provided to the user or 281 application. 283 This provides a simple means of satisfying the needs of certain 284 applications such as voice mail servers that just require information 285 about the most recent retarget in order to trigger appropriate 286 behaviour. 288 When retargeting occurs and a History-Info header field element is 289 added to record the retarget-to URI and the SIP reason that led to 290 retargeting, if the retargeting is service retargeting the old-target 291 and retargeting-reason parameters in the retargeted-to URI will also 292 appear in the History-Info header field element. If History-Info 293 header field elements are forwarded to the UAS, the UAS will be able 294 to see which retargets were service retargets and the service 295 retargeting reasons concerned. Likewise, if the History-Info header 296 field elements are sent back to the UAC, the UAC will be able to see 297 which retargets were service retargets. This information can be 298 presented to the user or application at the UAS or UAC. 300 4 Behaviour 302 4.1 UAC behaviour 304 A UAC MAY use service redirection information in a received History- 305 Info header field to present to the user or application. 307 Note that when a UAC recurses as a result of receiving a 3xx 308 response, any service redirection information in the retargeted-to 309 URI (received in the Contact header field) will automatically be 310 copied into the Request URI. 312 4.2 Proxy behaviour 313 When retargeting a request for service reasons, a proxy MAY add an 314 old-target parameter and a retargeting-reason parameter to the new 315 target URI as placed in the Request-URI of the forwarded request. If 316 a new History-Info header field element is created to contain the new 317 target URI, this too MUST contain the same old-target and 318 retargeting-reason parameters. 320 4.3 Redirect behaviour 322 When redirecting a request for service reasons, a redirect MAY add an 323 old-target parameter and a retargeting-reason parameter to any or all 324 URIs placed in the Contact URI header field in the 3xx response. 326 4.4 UAS behaviour 328 A UAS MAY use service redirection information in a received Request- 329 URI or History-Info header field to present to the user or 330 application. 332 5 Syntax 334 This RFC updates the SIP URI parameters registry as defined in 335 [URIREG]. Two new URI parameters are defined. 337 URI parameter old-target, when present, means that the URI became the 338 target URI for the request (the new Request URI) as a result of 339 service retargeting and the URI parameter value was the Request URI 340 prior to service retargeting. 342 URI parameter retargeting-reason, when present, means that the URI 343 became the target URI for the request (the new Request URI) as a 344 result of service retargeting and the URI parameter value indicates 345 the reason for service retargeting. 347 The following retargeting-reason values are defined in this 348 specification: 350 no-contacts - service retargeting because there are no registered 351 contacts for the URI; 353 busy � service retargeting because contacts for the URI are busy; 355 no-reply � service retargeting because the request was not answered 356 during the alerting period; 358 unconditional � service retargeting because the user has arranged for 359 requests to be retargeted irrespective of the state of registered 360 contacts; 361 declined � service retargeting because the user declined the request 362 during alerting; 364 distribution � service retargeting because the user has arranged for 365 requests to be distributed among a number of targets; 367 network � service retargeting because of network conditions. 369 If a received retargeting-reason value is not recognized it SHOULD be 370 treated as "unconditional". 372 The ABNF definition of these parameters is as follows. 374 uri-parameter = transport-param / user-param / method-param 375 / ttl-param / maddr-param / lr-param 376 / old-target / retargeting-reason / other-param 377 old-target = "old-target=" Request-URI 378 redirecting-reason = "redirecting-reason=" service-reason 379 service-reason = ("no-contacts" / "busy" / "no-reply" 380 / "unconditional" / "declined" / "distribution" 381 / "network" / other-reason) 382 other-reason = token 384 6 PSTN Mapping 386 The mapping to the PSTN/ISDN protocols is important both for gateways 387 that connect the IP network to existing TDM equipment, such as PBXs 388 and voicemail systems, and for gateways that connect the IP network 389 to the PSTN/ISDN network. Both Q.931 and ISUP have signaling for 390 this information that can be treated as roughly equivalent for the 391 purposes here. 393 For a service-retargeted call from SIP to PSTN/ISDN, the user portion 394 of the URI SHOULD be used as the address of the service retargeted-to 395 entity in the PSTN/ISDN, while the old-target SHOULD be mapped to the 396 PSTN/ISDN original redirecting number. 398 If the gateway and Proxy are in the same Trust Domain (defined in RFC 399 3325 [PASSERT]), and the Spec(T) includes compliance with that 400 specification, and the Spec(T) asserts that the Proxy will do 401 screening (whatever that means), then the gateway MAY claim that the 402 original redirecting number is screened; otherwise it SHOULD NOT 403 assert that the original redirecting number is screened. 405 The following SHOULD be used as the mapping from retargeting-reason 406 parameters to ISUP/Q.931/QSIG redirect reason codes: 408 +------------------------------------------------------------------+ 409 | Retargeting reason value | ISUP/Q.931/QSIG redirect 410 | 411 | | reason codes | 412 |----------------------------------------+-------------------------| 413 | no-contacts - service retargeting | Unknown / not available | 414 | because there are no registered | (Unconditional for QSIG)| 415 | contacts for the URI; | | 416 |----------------------------------------+-------------------------| 417 | busy � service retargeting because | User busy | 418 | contacts for the URI are busy; | | 419 |----------------------------------------+-------------------------| 420 | no-reply � service retargeting | No reply | 421 | because the request was not answered | | 422 | during the alerting period; | | 423 |----------------------------------------+-------------------------| 424 | unconditional � service retargeting | Unconditional | 425 | because the user has arranged for | | 426 | requests to be retargeted irrespective | | 427 | of the state of registered contacts; | | 428 |----------------------------------------+-------------------------| 429 | declined � service retargeting because | Deflection during | 430 | the user declined the request during | alerting | 431 | alerting; | (No reply for QSIG) | 432 |----------------------------------------+-------------------------| 433 | distribution � service retargeting | Deflection immediate | 434 | because the user has arranged for | response | 435 | requests to be distributed among a | (Unconditional for QSIG)| 436 | number of targets; | | 437 |----------------------------------------+-------------------------| 438 | network � service retargeting because | Network congestion | 439 | of network conditions. | (Unconditional for QSIG)| 440 +----------------------------------------+-------------------------+ 442 The redirection counters SHOULD be set to one unless additional 443 information is available. 445 For a call from PSTN/ISDN that has been redirected within the 446 PSTN/ISDN, information from the PSTN/ISDN MAY be used to indicate 447 service retargeting in the SIP INVITE request. In this case, the 448 original redirecting number SHOULD be used to derive the old-target 449 URI and the ISUP/Q.931/QSIG redirect reason code should be used to 450 derive the retargeting-reason, in accordance with the table above. 452 More comprehensive mapping to/from PSTN/ISDN may be achieved if the 453 History-Info header field is also taken into account (e.g., by taking 454 into account multiple service retargets and by mapping information 455 sent towards the calling party). This is outside the scope of this 456 document. 458 7 Examples 460 This section provides some example use cases for the solution 461 proposed in this document. The examples are intended to highlight 462 the potential applicability of this solution and are not intended to 463 limit its applicability. The term "deputy" is used to define the 464 role of a recipient UA, after retargeting, in several of the 465 examples. This term is intended to represent a general role of an 466 entity that could be an automata (eg. voicemail server) or another 467 person, such as another member of a work group (e.g. supervisor) or 468 agent in a call center application, etc.. 470 Also the examples show just service retargeting on busy, but can 471 easily be adapted to show other forms of service retargeting. 473 7.1 Proxy forwards busy to deputy 475 In this example, Alice calls Bob. Bob�s proxy determines that Bob is 476 busy, and the proxy forwards the call to Bob's deputy (or voice 477 mail). Alice's phone is at 192.168.0.1 while Bob's phone is at 478 192.168.0.2. The important thing to note is the URI in message F7. 480 Alice Proxy Bob Deputy 481 | | | | 482 | INVITE F1 | | | 483 |--------------->| INVITE F2 | | 484 | |------------->| | 485 |(100 Trying) F3 | | | 486 |<---------------| 486 Busy F4 | | 487 | |<-------------| | 488 | | ACK F5 | | 489 | |------------->| | 490 |(181 Call is Being Forwarded) F6 | 491 |<---------------| | INVITE F7 | 492 | |--------------------------------->| 493 * Rest of flow not shown * 495 F1: INVITE 192.168.0.1 -> proxy.example.com 497 INVITE sip:+15555551002@example.com;user=phone SIP/2.0 498 Via: SIP/2.0/TCP 192.168.0.1:5060;branch=z9hG4bK-74bf9 499 From: Alice ;tag=9fxced76sl 500 To: sip:+15555551002@example.com;user=phone 501 Call-ID: c3x842276298220188511 502 CSeq: 1 INVITE 503 Max-Forwards: 70 504 Contact: 505 Content-Type: application/sdp 506 Content-Length: *Body length goes here* 508 * SDP goes here* 510 F2: INVITE proxy.example.com -> 192.168.0.2 512 INVITE sip:line1@192.168.0.2 SIP/2.0 513 Via: SIP/2.0/TCP 192.168.1.4:5060;branch=z9hG4bK-ik80k7g-1 514 Via: SIP/2.0/TCP 192.168.0.1:5060;branch=z9hG4bK-74bf9 515 From: Alice ;tag=9fxced76sl 516 To: sip:+15555551002@example.com;user=phone 517 Call-ID: c3x842276298220188511 518 CSeq: 1 INVITE 519 Max-Forwards: 70 520 Contact: 521 Content-Type: application/sdp 522 Content-Length: *Body length goes here* 524 * SDP goes here* 526 F4: 486 192.168.0.2 -> proxy.example.com 528 SIP/2.0 486 Busy Here 529 Via: SIP/2.0/TCP 192.168.1.4:5060;branch=z9hG4bK-ik80k7g-1 530 Via: SIP/2.0/TCP 192.168.0.1:5060;branch=z9hG4bK-74bf9 531 From: Alice ;tag=9fxced76sl 532 To: sip:+15555551002@example.com;user=phone;tag=09xde23d80 533 Call-ID: c3x842276298220188511 534 CSeq: 1 INVITE 535 Content-Length: 0 537 F7: INVITE proxy.example.com -> um.example.com 539 INVITE sip:deputy@example.com; \ 540 old-target=sip:+15555551002@example.com;user=phone; \ 541 retargeting-reason=busy SIP/2.0 542 Via: SIP/2.0/TCP 192.168.1.4:5060;branch=z9hG4bK-ik80k7g-2 543 Via: SIP/2.0/TCP 192.168.0.1:5060;branch=z9hG4bK-74bf9 544 From: Alice ;tag=9fxced76sl 545 To: sip:+15555551002@example.com;user=phone 546 Call-ID: c3x842276298220188511 547 CSeq: 1 INVITE 548 Max-Forwards: 70 549 Contact: 550 Content-Type: application/sdp 551 Content-Length: *Body length goes here* 552 * SDP goes here* 554 7.2 Endpoint forwards busy to deputy 556 In this example, Alice calls Bob. Bob is busy, but forwards the 557 session directly to his deputy (or voicemail). Alice's phone is at 558 192.168.0.1 while Bob's phone is at 192.168.0.2. The important thing 559 to note is the URI in the Contact in message F3. 561 Alice Proxy Bob Deputy 562 | | | | 563 | INVITE F1 | | | 564 |--------------->| INVITE F2 | | 565 | |------------->| | 566 | | 302 Moved F3 | | 567 | 302 Moved F4 |<-------------| | 568 |<---------------| | | 569 | ACK F5 | | | 570 |--------------->| ACK F6 | | 571 | |------------->| | 572 | INVITE F7 | 573 |-------------------------------------------------->| 574 * Rest of flow not shown * 576 F1: INVITE 192.168.0.1 -> proxy.example.com 578 INVITE sip:+15555551002@example.com;user=phone SIP/2.0 579 Via: SIP/2.0/TCP 192.168.0.1:5060;branch=z9hG4bK-74bf9 580 From: Alice ;tag=9fxced76sl 581 To: sip:+15555551002@example.com;user=phone 582 Call-ID: c3x842276298220188511 583 CSeq: 1 INVITE 584 Max-Forwards: 70 585 Contact: 586 Content-Type: application/sdp 587 Content-Length: *Body length goes here* 589 * SDP goes here* 591 F2: INVITE proxy.example.com -> 192.168.0.2 593 INVITE sip:line1@192.168.0.2 SIP/2.0 594 Via: SIP/2.0/TCP 192.168.1.4:5060;branch=z9hG4bK-ik80k7g-1 595 Via: SIP/2.0/TCP 192.168.0.1:5060;branch=z9hG4bK-74bf9 596 From: Alice ;tag=9fxced76sl 597 To: sip:+15555551002@example.com;user=phone 598 Call-ID: c3x842276298220188511 599 CSeq: 1 INVITE 600 Max-Forwards: 70 601 Contact: 602 Content-Type: application/sdp 603 Content-Length: *Body length goes here* 605 * SDP goes here* 607 F3: 302 192.168.0.2 -> proxy.example.com 609 SIP/2.0 302 Moved Temporarily 610 Via: SIP/2.0/TCP 192.168.1.4:5060;branch=z9hG4bK-ik80k7g-1 611 Via: SIP/2.0/TCP 192.168.0.1:5060;branch=z9hG4bK-74bf9 612 From: Alice ;tag=9fxced76sl 613 To: sip:+15555551002@example.com;user=phone;tag=09xde23d80 614 Call-ID: c3x842276298220188511 615 CSeq: 1 INVITE 616 Contact: 619 Content-Length: 0 621 F7: INVITE proxy.example.com -> um.example.com 623 INVITE sip: deputy@example.com; \ 624 old-target=sip:+15555551002@example.com;user=phone; \ 625 retargeting-reason=busy SIP/2.0 626 Via: SIP/2.0/TCP 192.168.1.4:5060;branch=z9hG4bK-ik80k7g-2 627 Via: SIP/2.0/TCP 192.168.0.1:5060;branch=z9hG4bK-74bf9 628 From: Alice ;tag=9fxced76sl 629 To: sip:+15555551002@example.com;user=phone 630 Call-ID: c3x842276298220188511 631 CSeq: 1 INVITE 632 Max-Forwards: 70 633 Contact: 634 Content-Type: application/sdp 635 Content-Length: *Body length goes here* 637 * SDP goes here* 639 7.3 Endpoint forwards busy to TDM via a gateway 641 In this example, the deputy (or mailbox) is reached via a gateway to 642 a TDM network. Bob's number is +1 555 555-1002, while deputy's 643 number on the TDM network is +1-555-555-2000. 645 The call flow is the same as in section 7.2 except for the Contact 646 URI in F3 and the Request URI in F7. 648 F3: 302 192.168.0.2 -> proxy.example.com 650 SIP/2.0 302 Moved Temporarily 651 Via: SIP/2.0/TCP 192.168.1.4:5060;branch=z9hG4bK-ik80k7g-1 652 Via: SIP/2.0/TCP 192.168.0.1:5060;branch=z9hG4bK-74bf9 653 From: Alice ;tag=9fxced76sl 654 To: sip:+15555551002@example.com;user=phone;tag=09xde23d80 655 Call-ID: c3x842276298220188511 656 CSeq: 1 INVITE 657 Contact: 659 Content-Length: 0 661 F7: INVITE proxy.example.com -> gw.example.com (for both 7.1 and 7.2) 663 INVITE sip:+15555552000@example.com;user=phone;\ 664 old-target=tel:+15555551002;retargeting-reason=busy \ 665 SIP/2.0 666 Via: SIP/2.0/TCP 192.168.1.4:5060;branch=z9hG4bK-ik80k7g-2 667 Via: SIP/2.0/TCP 192.168.0.1:5060;branch=z9hG4bK-74bf9 668 From: Alice ;tag=9fxced76sl 669 To: sip:+15555551002@example.com;user=phone 670 Call-ID: c3x842276298220188511 671 CSeq: 1 INVITE 672 Max-Forwards: 70 673 Contact: 674 Content-Type: application/sdp 675 Content-Length: *Body length goes here* 677 * SDP goes here* 679 7.4 Endpoint forwards busy to deputy with History Info 681 This example illustrates how History Info [HIST] works in conjunction 682 with service retargeting. The scenario is the same as 7.1. 684 F1: INVITE 192.168.0.1 -> proxy.example.com 686 INVITE sip:+15555551002@example.com;user=phone SIP/2.0 687 Via: SIP/2.0/TCP 192.168.0.1:5060;branch=z9hG4bK-74bf9 688 From: Alice ;tag=9fxced76sl 689 To: sip:+15555551002@example.com;user=phone 690 Call-ID: c3x842276298220188511 691 CSeq: 1 INVITE 692 Max-Forwards: 70 693 Contact: 694 History-Info: ;index=1 695 Content-Type: application/sdp 696 Content-Length: *Body length goes here* 697 * SDP goes here* 699 F2: INVITE proxy.example.com -> 192.168.0.2 701 INVITE sip:line1@192.168.0.2 SIP/2.0 702 Via: SIP/2.0/TCP 192.168.1.4:5060;branch=z9hG4bK-ik80k7g-1 703 Via: SIP/2.0/TCP 192.168.0.1:5060;branch=z9hG4bK-74bf9 704 From: Alice ;tag=9fxced76sl 705 To: sip:+15555551002@example.com;user=phone 706 Call-ID: c3x842276298220188511 707 CSeq: 1 INVITE 708 Max-Forwards: 70 709 Contact: 710 History-Info: ;index=1, 711 ;index=1.1 713 Content-Type: application/sdp 714 Content-Length: *Body length goes here* 716 * SDP goes here* 718 F7: INVITE proxy.example.com -> um.example.com 720 INVITE sip: deputy@example.com; \ 721 old-target=sip:+15555551002@example.com;user=phone; \ 722 retargeting-reason=busy SIP/2.0 723 Via: SIP/2.0/TCP 192.168.1.4:5060;branch=z9hG4bK-ik80k7g-2 724 Via: SIP/2.0/TCP 192.168.0.1:5060;branch=z9hG4bK-74bf9 725 From: Alice ;tag=9fxced76sl 726 To: sip:+15555551002@example.com;user=phone 727 Call-ID: c3x842276298220188511 728 CSeq: 1 INVITE 729 Max-Forwards: 70 730 Contact: 731 History-Info: ;index=1, 732 ;index=1.1 734 ;index=2 737 Contact: 738 Content-Type: application/sdp 739 Content-Length: *Body length goes here* 741 * SDP goes here* 743 8 IANA considerations 745 This specification adds a new value to the IANA registration in the 746 "SIP/SIPS URI Parameters" sub-registry at 747 http://www.iana.org/assignments/sip-parameters as defined in 748 [URIREG]. 750 Parameter Name Predefined Values Reference 752 old-target No [RFCAAAA] 753 retargeting-reason Yes [RFCAAAA] 755 [Note to IANA: Please replace AAAA with the RFC number of this 756 specification. 758 This document requests that IANA create a new registry for 759 retargeting-reason values. Each registry entry must contain the value 760 and the specification in which the value is defined. New values for 761 this registry may be defined only in Standards Track RFCs. This 762 registry is to be populated initially with the following entries 763 defined in section 5: no-contacts; busy; no-reply; unconditional; 764 declined; distribution; network. 766 9 Security Considerations 768 This draft discusses transactions involving at least three parties, 769 which increases the complexity of the privacy issues. In addition, 770 the security considerations of [HIST] apply when the History-Info 771 header field is used. 773 The new URI parameters defined in this draft are generally sent from 774 a Proxy or call control system to a retargeted-to UA (or to a gateway 775 to the PSTN and then to a retargeted-to device). These new 776 parameters tell the retargeted-to UA what service the proxy wishes to 777 have performed. Just as any message sent from the proxy to the 778 retargeted-to UA needs to be integrity protected, these messages need 779 to be integrity protected to stop attackers from, for example, 780 causing speech (e.g., voicemail) meant for a company's CEO to go to 781 an attacker. RFC 3261 provides a TLS mechanism suitable for 782 performing this integrity protection. 784 The signaling from the Proxy to the retargeted-to UA will reveal who 785 is calling whom and possibly some information about a user's presence 786 based on whether the call was answered or retargeted. This 787 information can be protected by encrypting the SIP traffic between 788 the Proxy and the retargeted-to UA. Again, RFC 3261 contains 789 mechanisms for accomplishing this using TLS. 791 The S/MIME based mechanisms in RFC 3261 will generally not be 792 applicable for protecting this information because they are meant for 793 end to end issues and this is primarily a middle to end scenario. 794 Without end-to-end or middle-to-end security, reliance is placed on 795 on hop-by-hop security using TLS and the SIPS URI scheme. This 796 requires that all hops between the Proxy and the retareget-to UR be 797 trusted, which is the case in many deployment scenarios. 799 9.1 Integrity Protection of Forwarding in SIP 801 The forwarding of a call in SIP brings up a very strange trust issue. 802 Consider the normal case when A calls B and the call gets forwarded 803 to C by a network element in B's domain, and then C answers the call. 804 A has called B but ended up talking to C. This scenario may be hard 805 to separate from a man in the middle attack. 807 There are two possible solutions. One is that B sends back 808 information to A saying don't call me, call C and signs it as B. The 809 problem is that this solution involves revealing that B has forwarded 810 to C, which B often may not want to do. For example, B may be a work 811 phone that has been forwarded to a mobile or home phone. The user 812 does not want to reveal their mobile or home phone number but, even 813 more importantly, does not want to reveal that they are not in the 814 office. 816 The other possible solution is that A needs to trust B only to 817 forward to a trusted identity. This requires a hop by hop transitive 818 trust such that each hop will only send to a trusted next hop and 819 each hop will only do things that the user at that hop desired. This 820 solution is enforced in SIP using the SIPS URI and TLS based hop by 821 hop security. It protects from an off axis attack, but if one of the 822 hops is not trustworthy, the call may be diverted to an attacker. 824 Any redirection of a call to an attacker's mailbox is serious. It is 825 trivial for an attacker to make its mailbox seem very much like the 826 real mailbox and forward the messages to the real mailbox so that the 827 fact that the messages have been intercepted or even tampered with 828 escapes detection. 830 9.2 Privacy Related Issues on the Second Call Leg 832 When A calls B and gets redirected to C, occasionally people say 833 there is a requirement for the call leg from B to C to be anonymous. 834 This is not the PSTN and there is no call leg from B to C; instead 835 there is a VoIP session between A and C. If A had put a To header 836 containing B in the initial invite message, unless something special 837 is done about it, C will see that To header. If the person who 838 answers phone C says "I think you dialed the wrong number, who were 839 you trying to reach?" A will probably specify B. 841 If A does not want C to see that the call was to B, A needs a special 842 relationship with the forwarding Proxy to induce it not to reveal 843 that information. The call should go through an anonymizer service 844 that provides session or user level privacy (as described in [PRIV] 845 [4]) service before going to C. It is not hard to figure out how to 846 meet this requirement, but it is unclear why anyone would want this 847 service. 849 The scenario in which B wants to make sure that C does not see that 850 the call was to B is easier to deal with but a bit weird. The usual 851 argument is B wants to forward his phone to C but does not want C to 852 find out his phone number. It is hard to imagine that C would want 853 to accept all B�s calls without knowing how to call B to complain. 854 Several popular web portals will send SMS alert message about things 855 like stock prices and weather to mobile phone users today. Some of 856 these contain no information about the account on the web portal that 857 initiated them, making it nearly impossible for the mobile phone 858 owner to stop them. This anonymous message forwarding has turned out 859 to be a really bad idea even where no malice is present. Clearly 860 some people are fairly dubious about the need for this, but never 861 mind: let's look at how it is solved. 863 In the general case, the proxy needs to route the call through an 864 Anonymization Service and everything will be cleaned up. Any 865 Anonymization service that performs the "Privacy: Header" Service in 866 [PRIV] MUST remove the reason and target URI parameters from the URI. 867 [PRIV] already makes it clear you would need to clean up this sort of 868 information. 870 There is a specialized case of some interest in which the mechanisms 871 in this specification are being used in conjunction with [PRIV], and 872 the retargeted-to UA and the Proxy are both in the trust domain. In 873 this limited case, the problem that B does not want to reveal their 874 address to C can be solved by ensuring that the target parameter URI 875 should never be in a message that is forwarded outside the trust 876 domain. If it is passed to a PSTN device in the trust domain, the 877 appropriate privacy flag needs to be set in the ISUP or ISDN 878 signaling. 880 In several scenarios it is possible that a service retargeted-to user 881 will receive unwanted calls. Arranging for automatic rejection of 882 such calls can alleviate the problem, although it would be preferable 883 to take steps to prevent the service retargeting, e.g., by contacting 884 the retargeting user. Of course, if for privacy reasons service 885 retargeting information is not provided, this will not be possible. 887 10 Acknowledgements 888 Some of the text was taken from Cullen Jennings' draft on voicemail- 889 uri. The following individuals provided valuable comments during the 890 initial formulation of this document: Denis Alexeitsev, Mary Barnes, 891 Martin Dolly, Roland Jesske, Joanne McMillen. 893 11 Author's Addresses 895 John Elwell 896 Siemens Communications 897 Technology Drive 898 Beeston 899 Nottingham, UK, NG9 1LA 900 email: john.elwell@siemens.com 902 Fran�ois Audet 903 Nortel Networks 904 4655 Great America Parkway 905 Santa Clara, CA 95054 906 USA 907 mailto:audet@nortel.com 909 12 Normative References 911 [SIP] J. Rosenberg, H. Schulzrinne, et al., "SIP: Session initiation 912 protocol", RFC 3261. 914 [HIST] M. Barnes, "An Extension to the Session Initiation Protocol 915 for Request History Information", draft-ietf-sipping-history-info-06 916 (work in progress). 918 [REASON] H. Schulzrinne, D. Oran, G. Camarillo, "The Reason Header 919 for the Session Initiation Protocol (SIP)", RFC 3326. 921 [SRVCTRL] B. Campbell, R. Sparks, "Control of Service Context using 922 SIP Request-URI", RFC 3087. 924 [URIREG] G. Camarillo, "The Internet Assigned Number Authority (IANA) 925 Uniform Resource Identifier (URI) Parameter Registry for the Session 926 Initiation Protocol (SIP)", RFC 3969. 928 [PASSERT] Jennings, C., Peterson, J., and M. Watson, "Private 929 Extensions to the Session Initiation Protocol (SIP) for Asserted 930 Identity within Trusted Networks", RFC 3325, November 2002. 932 [PRIV] Peterson, J., "A Privacy Mechanism for the Session Initiation 933 Protocol (SIP)", RFC 3323, November 2002. 935 Intellectual Property Statement 936 The IETF takes no position regarding the validity or scope of any 937 Intellectual Property Rights or other rights that might be claimed to 938 pertain to the implementation or use of the technology described in 939 this document or the extent to which any license under such rights 940 might or might not be available; nor does it represent that it has 941 made any independent effort to identify any such rights. Information 942 on the IETF's procedures with respect to rights in IETF Documents can 943 be found in BCP 78 and BCP 79. 945 Copies of IPR disclosures made to the IETF Secretariat and any 946 assurances of licenses to be made available, or the result of an 947 attempt made to obtain a general license or permission for the use of 948 such proprietary rights by implementers or users of this 949 specification can be obtained from the IETF on-line IPR repository at 950 http://www.ietf.org/ipr. 952 The IETF invites any interested party to bring to its attention any 953 copyrights, patents or patent applications, or other proprietary 954 rights that may cover technology that may be required to implement 955 this standard. Please address the information to the IETF at ietf- 956 ipr@ietf.org. 958 Disclaimer of Validity 960 This document and the information contained herein are provided on an 961 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 962 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 963 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 964 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 965 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 966 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE 968 Copyright Statement 970 Copyright (C) The Internet Society (2005). 972 This document is subject to the rights, licenses and restrictions 973 contained in BCP 78, and except as set forth therein, the authors 974 retain all their rights. 976 Acknowledgement 978 Funding for the RFC Editor function is currently provided by the 979 Internet Society. 981 13 Appendix - Rejected Alternatives (temporary � to be removed) 983 The following alternative solutions were considered and rejected. 985 13.1 Extending the SIP Reason header 987 This alternative involves defining a new "protocol" (namespace) in 988 the SIP Reason header for service retargeting reasons. A service- 989 retargeted request could then convey, as a URI header in the History- 990 Info header field, a Reason header field indicating the service 991 retargeting reason, in addition to the SIP reason for retargeting. In 992 addition, the Reason header field could be used in a 3xx response to 993 indicate a service reason for redirection. This was considered to 994 have the following disadvantages: 996 - It is not backwards compatible with existing UACs or proxies, which 997 would not copy a Reason header from a 3xx response into a History- 998 Info header field when recursing. 1000 - The need for escape characters in URI headers makes this less 1001 readable. 1003 - It does not provide a basic level of support to applications at the 1004 UAS without requiring use of the History-Info header field. 1006 13.2 New 3xx response codes 1008 There are many unused response codes in the 3xx range, and a few of 1009 these could have been used for service retargeting reasons. This was 1010 considered to have the following disadvantages: 1012 - Service reasons for retargeting are in some ways orthogonal to SIP 1013 reasons, and it would be unwise to mix the two in the same namespace. 1015 - There may be advantages in having both a SIP retargeting reason and 1016 a service retargeting reason available. 1018 - It does not provide a basic level of support to applications at the 1019 UAS without requiring use of the History-Info header field.