idnits 2.17.1 draft-sinha-dispatch-sip-continuation-option-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (April 2, 2012) is 4404 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Informational ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: 'Continue' on line 821 == Unused Reference: '7' is defined on line 1035, but no explicit reference was found in the text Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 DISPATCH Working Group Amardeep Sinha 2 Internet Draft Subhrajyoti De 3 Intended Status: Informational Sunil Kumar Sinha 4 Expires: October 1, 2012 Manjunath Hanchinal 5 April 2, 2012 7 The Continue Header Field for the Session Initiation Protocol (SIP) 8 draft-sinha-dispatch-sip-continuation-option-03.txt 10 Abstract 12 Before placing a call, it is quite often useful for the Caller to 13 know whether a Callee is in favorable state to receive a call or 14 not. This document defines an optional tag "continue" and a header 15 "Continue" to address the purpose. The "Continue" header field is 16 to confirm the session continuity with the Callee from the Caller 17 after an option for session continuity is placed by the Callee based 18 on the unfavorable state of the Callee. This functionality is needed 19 to resolve the unwillingness of the Callee to receive any call. An 20 option is given to the Callee by the Service Provider or by the 21 Handset Manufacturer or by the Carrier to establish this requirement. 23 Status of this Memo 25 This Internet-Draft is submitted in full conformance with the 26 provisions of BCP 78 and BCP 79. Internet-Drafts are working 27 documents of the Internet Engineering Task Force (IETF). Note that 28 other groups may also distribute working documents as 29 Internet-Drafts. The list of current Internet-Drafts is at 30 http://datatracker.ietf.org/drafts/current. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at 34 any time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on October 1, 2012. 39 Copyright Notice 41 Copyright (c) 2011 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with 49 respect to this document. 51 Table of Contents 52 1. Introduction.................................................02 53 1.1 Terminology.............................................04 54 2. Overall Operation............................................04 55 3. UAS Behavior.................................................05 56 4. UAC Behavior.................................................06 57 5. The Continue Header Definition...............................06 58 6. Backwards Compatibility......................................08 59 7. Examples and Use cases.......................................08 60 7.1 Call is Finally Placed by Calling Party..................08 61 7.2 Call is Finally Not Placed by Calling Party..............10 62 7.3 Caller Hungs Up..........................................12 63 7.4 Caller does not have Call Continuation Option feature....12 64 7.5 Callee does not support NDDND feature....................13 65 7.6 SIP-ISDN Interworking with Call Continuation feature.....13 66 7.7 SIP-FXS Interworking with Call Continuation feature......17 67 8. Implementation Recommendation................................20 68 9. IANA Considerations..........................................21 69 9.1 IANA Registration of Continue SIP Header field..........21 70 9.2 IANA Registration of continue SIP Option-tag............21 71 10. Security Considerations......................................21 72 11. Acknowledgements.............................................21 73 12. References...................................................22 74 12.1 Normative References...................................22 75 12.2 Informative References.................................22 76 13. Authors' Address.............................................22 78 1. Introduction 80 Session Initiation Protocol (SIP) allows Caller to establish sessions 81 with Callee without knowing whether Callee is in a position to accept 82 session request or not. There is no way by which Caller can know 83 the favorable state of Callee. There are several reasons why the 84 Caller wants to know the favorable state of Callee before finally 85 placing the call, because Callee may be in a different time zone, 86 Callee may be in a meeting, theatre, having lunch with family/friends 87 ,etc. Callee may not want to be disturbed but may like to receive 88 calls which is urgent and of good interest to him. Another example 89 Bob may not like office calls on weekends or at his personal/family 90 time, but a project which requires his consent to progress or 91 business gets affected can be treated as urgent and he would like to 92 hear them. Same in case he's in a business meeting and doesnot want 93 to receive call from family or his team but anything which requires 94 his urgent attention, it would be important for him to accept. The 95 nearest approach or solutions to such problem available till date is 96 described below along with the appropriate cause why this document is 97 not considering this for implementation. These approaches are not 98 sufficient enough to address all concerns and not giving the control 99 on the call to the Caller for urgent call irrespective of Callee's 100 priority. 102 (a) By OPTION Method - It is used to determine the capabilities of 103 SIP User Agent (UA). This OPTION method allows a SIP User Agent 104 Client (UAC) to discover information about the supported method, 105 content types, extensions, codec, etc for a client which is 106 registered with the Server. OPTION method is given by the Caller 107 to know either Server Capabilities or Client Capabilities and not 108 to its callee's state. 110 (b) By Priority Header - Priority Header can be used to override a 111 ongoing call, DND option or any voice feature based on the 112 Priority of the call as set by the Caller and as agreed with the 113 Operator. If Called Party supports the feature and Caller does 114 not support Priority, then this feature will be just DND. 116 (c) By Do Not Disturb (DND) - When user enable DND on the phone, this 117 parameter allows user to specify how the DND features handle 118 incoming calls: 120 (c.1) Call Reject - This option specifies that no incoming call 121 information gets presented to the user. Depending on how user 122 configure the DND Incoming Call Alert parameter, the phone may 123 play a beep or display a flash notification of the call. 125 (c.2) Ringer Off - This option turns off the ringer, but incoming 126 call information gets presented to the device, so that the user 127 can accept the call. 129 DND feature doesnot serve the requirement of Caller to make a call 130 in diverted to voicemail. 132 (d) By Presence[1] Feature - The use of PRESENCE with UAC clients 133 restricted to higher end-mobile devices. It is also not necessary 134 that caller and callee both are in each-other's buddy's list or 135 connected to same social-networks as it is not necessary that 136 call is between two known persons. 138 Therefore the purpose of this document to give the control to the 139 Caller. It also describes a mechanism for a Callee to 140 convey the information to a Caller to place a call only when call is 141 urgent by introducing "Call Continuation Option" and "Non-Dedicated 142 Dot Not Disturb (NDDND)" as two new features in TELECOMMUNICATION. 144 Definition 146 o Non-Dedicated Do Not Disturb (NDDND)- is a state of Callee which 147 portrays that the Callee is in a non-dedicated or slight DND mode 148 with willingness to receive calls only if it is urgent. However 149 the decision is driven by the Caller whether to finally place a 150 call or not. By setting this option at the Callee UE or at voice 151 services of Callee on the operator side, it ensures that the 152 Caller gets a notification after placing a call that Callee is 153 in a unfavorable state to receive call at this moment but in a 154 position to accept any call if caller thinks its urgent. 156 o Call Continuation Option - is a feature where an option is given 157 to the Caller after Caller dials the Callee number to confirm the 158 application whether to finally place the call or not based on 159 certain configuration at the Callee User Equipment (UE) or at the 160 Voice Feature Service of Callee. 162 1.1 Terminology 164 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 165 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 166 this document are to be interpreted as described in RFC 2119[5]. 168 2. Overall Operation 170 Callee is willing to receive only urgent call by enabling NDDND. This 171 will convey the information to Caller that Callee is not in a 172 favorable state to receive calls and option will be given to the 173 Caller to place a call only if it is urgent. This can be achieved by 174 adding an optional tag "continue" in the Require header of 182 175 (Queued) provisional response from Callee. If Callee does not enable 176 this feature, operation will be as per RFC 3261[2]. 178 Caller is keen to know whether the Callee is free or not to take a 179 call. So Caller sends INVITE with option tag "continue" in the 180 Supported header. The Callee interprets the Caller up-to-date and 181 inline capabilities and responds with 182(Queued)response with 182 Require header value as "continue" if the feature NDDND is set at the 183 Callee. This SIP response is interpreted at the Caller with a message 184 popup or some in call information (device implementation) telling the 185 unfavorable state of Callee to receive calls but tells its 186 availability state also with an "Y" or "N" which can also be 187 simulated by Call-Place GREEN Button or Call-Cancel RED Button 188 as per Caller wishes to perform the needful action. This is described 189 in details in the mentioned use cases in Section 7. Accordingly PRACK 190 [3] or UPDATE [4] with "Continue" header value as "Yes" (if 'Y' 191 option is selected or GREEN button is pressed)or "No" (if 'N' option 192 is selected) to be sent to Callee or the CANCEL request from Caller 193 will be initiated if Hard RED Button is pressed. 195 The Caller will have following 3 options to the control session. 197 (i) Continue: Yes 199 Caller MUST inject "Continue" header with field value as "yes" or 200 "YES" in the PRACK or UPDATE to support the Require header of 201 provisional response. 203 (ii) Continue: No 205 Caller MUST inject "Continue" header with field value as "no" 206 or "NO" in the PRACK or UPDATE to support the Require header of 207 provisional response. 209 (iii) Caller Hungs Up 211 CANCEL request is sent by Caller and call gets terminated as per 212 described in RFC 3261. 214 Note-If the Caller does not act on received 182 (Queued) provisional 215 responses, retransmission timer implemented as per RFC 3261. 217 ^ 218 / \ 219 / \ 220 / \ +-------------+ 221 / \ | | 222 No / PLACE A \ Yes | PLACE CALL | 223 +<-------------------< Call >-------------->| TO CALLEE | 224 | CALLER PRESS \ / CALLER PRESS | | 225 | RED BUTTON \ / GREEN BUTTON +-------------+ 226 | \ / 227 | \ / 228 | \ / 229 | v 230 | | 231 | | CALLER HUNG UP 232 | | 233 | V 234 | +----------------+ 235 | | | 236 | | Terminate Call | 237 | | | 238 | +----------------+ 239 | ^ 240 V | 241 +---------------------------->+ 243 Figure 1: Algorithm for Call Continuation Option feature 245 3. UAS Behavior 247 A UAS MAY send 182 (Queued) provisional (by adding Require header 248 field with the option tag "continue") response if the initial INVITE 249 request contains a Supported header field with the option tag 250 "continue". If the UAS is unwilling to do so, it MUST ignore the 251 option tag "continue" and proceed as per guidelines described in RFC 252 3261. 254 A UAS MUST send 182 (Queued) provisional (by adding Require header 255 field with the option tag "continue") response if the initial INVITE 256 request contained a Require header field with the option tag 257 "continue". If the UAS is unwilling to do so, UAS responds with 180 258 (Ringing) provisional response. 260 A UAS MUST NOT send 182 (Queued) provisional (by adding Require 261 header field with the option tag "continue") response if the initial 262 INVITE request did not include either a Supported or Require header 263 field indicating this feature. 265 A UAS MUST NOT send 182 (Queued) provisional (by adding Require 266 header field with the option tag "continue") response if the initial 267 INVITE request include Priority header with high value. 269 If more than one "Continue" header field is present in PRACK or 270 UPDATE with two different field values, the UAS MUST reject the 271 request with a 400 (Bad Request) response. 273 If a "Continue" header field is present in a request other than PRACK 274 or UPDATE, the UAS MUST reject the request with a 400 (Bad Request) 275 response. 277 4. UAC Behavior 279 When the UAC creates a new request, it can insist for Call 280 Continuation Option in the provisional response for the request. To 281 do that, it inserts a Require header with the value "continue" as 282 option tag in the request. A Require header with the value "continue" 283 MUST NOT be present in any requests except INVITE. 285 If the UAC does not wish to insist on usage of Call Continuation 286 Option in the provisional response, a Supported header MUST be 287 include in the request with the option tag "continue". The UAC SHOULD 288 include this in all INVITE requests. 290 If a provisional response is received for an initial request and that 291 response contains a Require header field containing the option tag 292 "continue", the response is send in field value of "Continue" header 293 in PRACK or UPDATE request. 295 If a provisional response is received for an initial request and that 296 response contains a Require header field containing the option tag 297 "continue" and UAC is unwilling to establish a session, it MUST 298 reject with CANCEL request. 300 5. The "Continue" Header Definition 301 The Call Continuation Option feature makes use of "Continue" header 302 which provides control to Caller on establishing the session. It MAY 303 appear as an option extension header in PRACK or UPDATE request of 304 the Call Continuation Option feature. 306 The syntax of "Continue" header field follows the standard SIP 307 parameter syntax. 309 Continue = "Continue" HCOLON continue_value 310 continue_value = "YES" / "yes" / "NO" / "no" 312 For example, the used "Continue" header in SIP PRACK or UPDATE 313 request would look like 315 Continue: "YES" 316 Continue: "yes" 317 Continue: "NO" 318 Continue: "no" 320 The information about "Continue" header field in this document in 321 relation to method and proxy is summarized in Table 1. 323 The "where" column, in the Table 1, describes the request and 324 response types in which the header field may be used. The header may 325 not appear in other types of SIP messages. Values in the where 326 column is: 328 R: header field may only appear in requests. 330 The proxy column and last fourteen columns relate to the presence of 331 a "Continue" header field in a method: 333 o: the header field is optional. 334 -: the header field is not applicable. 336 Header field where proxy ACK BYE CAN INV OPT REG PRACK REFER SUB NOT 337 ---------------------------------------------------------------------- 338 Continue R - - - - - - - o - - - 340 Header field where INF UPD MSG PUB 341 --------------------------------------------------------------------- 342 Continue R - o - - 344 Table 1: Additional Table Entries for the "Continue" Header 346 6. Backwards Compatibility 348 This feature or SIP implementation does not have any impact on 349 existing Network designs and Handsets. This draft proposes the use of 350 additional header called SIP "Continue" header in order to 351 incorporate this feature of NDDND. 353 Handsets or Network who do not understand this feature shall not 354 handle and normal SIP behavior follows as per RFC 3261. 356 There are 2 use cases for backward compatibility: 358 o Caller Not Updated, Callee Updated 360 o Caller Updated, Callee Not Updated 362 Handling of SIP messages for the above two mentioned scenarios are 363 clearly mentioned in Section 7.4 and Section 7.5 respectively. 365 7. Examples and Use cases 367 This section contains a number of examples and use cases that 368 illustrate the use of the "Continue" header field. For simplicity, 369 header fields are usually shown in the same order. Usually only the 370 minimum required header field set is shown. Also, message body 371 content lengths are often not calculated, but instead shown as "..." 372 where the actual octet count would be. 374 Messages are identified in the figures as F1, F2, F3, etc. This 375 references the message details in the table that follows the figure. 377 Comments in the message details are shown in the following form: 378 /* Comments. */ 380 7.1 Call is Finally Placed by Calling Party 382 In this scenario, Alice has enabled NDDND feature in her profile. Bob 383 sends initial INVITE with option tag "continue" in Support header. 384 Alice asks for confirmation of urgent call before ringing by 182 385 (Queued) provisional response with option tag "continue" in Require 386 header. Bob confirmed as urgent call by providing yes as "Continue" 387 header field value. Alice's phone rings finally. 389 Bob Proxy Alice 390 | INVITE F1 | | 391 |---------------------->| | 392 | 100 Trying F2 | | 393 |<----------------------| INVITE F3 | 394 | |----------------------->| 395 | | | 396 | | 182 Queued F4 | 397 | 182 Queued F5 |<-----------------------| 398 |<----------------------| | 399 | | | 400 | PRACK F6 | | 401 |---------------------->| PRACK F7 | 402 | |----------------------->| 403 | | | 404 | | 200 OK F8 | 405 | 200 OK F9 |<-----------------------| 406 |<----------------------| | 407 | | | 408 | | 180 Ringing F10 | 409 | 180 Ringing F11 |<-----------------------| 410 |<----------------------| | 411 | | | 412 * Rest of flow not shown * 414 Figure 2: Call is Finally Placed by Calling Party 416 Message Details 418 /* The initial INVITE request has option tag "continue" in Support 419 header. */ 421 F1 Message Bob->Proxy 423 INVITE sip:alice@proxy.com SIP/2.0 424 Via: SIP/2.0/UDP client.biloxi.example.com;branch=z9hG4bKnashds8 425 Max-Forwards: 70 426 To: Alice 427 From: Bob ;tag=67890 428 Call-ID: a84b4c76e66710 429 CSeq: 1 INVITE 430 Supported:100rel,continue 431 Contact: 432 Content-Type: application/sdp 433 Content-Length: ... 435 (Bob's SDP not shown) 437 /* Alice supporting the new header extension "Continue", initially 438 her phone does not ring upon receiving initial INVITE request. It 439 will include option tag "continue" in Require header while sending 440 182 (Queued) provisional response to Bob. The response, F5, 441 received at Bob, might look like this. */ 443 F5 Message Proxy ->Bob 445 SIP/2.0 182 Queued 446 Via: SIP/2.0/UDP client.biloxi.example.com;branch=z9hG4bKnashds8 447 To: Alice ;tag=12345 448 From: Bob ;tag=67890 449 Contact: 450 Require: 100rel,continue 451 Call-ID: a84b4c76e66710 452 CSeq: 1 INVITE 453 Content-Type: application/sdp 454 Content-Length: ... 456 (Alice's SDP not shown) 458 /* Thus Bob comes to know that Alice is not willing to accept call 459 if the call is not very important. So Bob has control on the call 460 and can take a decision on his call. Assume Bob finally place the 461 call include "yes" or "YES" as the field value of "Continue" 462 header in PRACK method (F6).*/ 464 F6 Message Bob -> Proxy 466 PRACK sip: sip:alice@proxy.com SIP/2.0 467 Via: SIP/2.0/UDP client.biloxi.example.com:5060; 468 branch=z9hG4bKnash009 469 Max-Forward: 70 470 From: Bob ;tag=67890 471 To: Alice ;tag=12345 472 Call-ID: a84b4c76e66710 473 Require: 100rel,continue 474 CSeq: 2 PRACK 475 RAck: 1 1 INVITE 476 Continue: YES 477 Content-Length: 0 479 Alice's phone rings as it got the confirmation. The guidelines of 480 rest of messages flow is described in RFC 3261. 482 7.2 Call is Finally Not Placed by Calling Party 483 In this scenario, Bob finally decided not placed the call to Alice 484 as his call is not very urgent and Alice is willing to receive only 485 urgent call at this moment. The Alice's phone does not ring and 486 call is forward to preset destination if any. 488 Bob Proxy Alice 489 | INVITE F1 | | 490 |---------------------->| | 491 | 100 Trying F2 | | 492 |<----------------------| INVITE F3 | 493 | |----------------------->| 494 | | | 495 | | 182 Queued F4 | 496 | 182 Queued F5 |<-----------------------| 497 |<----------------------| | 498 | | | 499 | PRACK F6 | | 500 |---------------------->| PRACK F7 | 501 | |----------------------->| 502 | | | 503 | | 200 OK F8 | 504 | 200 OK F9 |<-----------------------| 505 |<----------------------| | 506 | | | 507 | | | 508 | | 486 Busy Here F10 | 509 | |<-----------------------| 510 | | | 511 * Rest of flow not shown * 513 Figure 3: Call is Finally Not Placed by Calling Party 515 /* Assume Bob finally wish not to place the call with Alice as his 516 call is not very important. So he injects "no" or "NO" as the 517 field value of "Continue" header in PRACK method (F6)*/ 519 F6 Message Bob -> Proxy 521 PRACK sip: sip:bob@biloxi.example.com SIP/2.0 522 Via: SIP/2.0/TCP client.biloxi.example.com:5060;branch=z9hG4bK124 523 Max-Forward: 70 524 From: Bob sip:bob@biloxi.example.com;tag=67890 525 To: Alice ;tag=12345 526 Call-ID: 12ka4@ biloxi.example.com 527 CSeq: 2 PRACK 528 Continue: NO 529 Content-Length: 0 531 Alice's phone does not ring as it got confirmation as no. PRACK is 532 responded by 200 (OK) followed by 486 (Busy Here) as per RFC 3261 534 7.3 Caller Hungs Up 536 In this example, Bob hangs up the call with Alice when he comes to 537 know that Alice need confirmation about importance of call before 538 ringing, which is shown in Figure 3. 540 Bob Proxy Alice 541 | INVITE F1 | | 542 |---------------------->| | 543 | 100 Trying F2 | | 544 |<----------------------| INVITE F3 | 545 | |----------------------->| 546 | | | 547 | | 182 Queued F4 | 548 | 182 Queued F5 |<-----------------------| 549 |<----------------------| | 550 | | | 551 | CANCEL F6 | | 552 |---------------------->| CANCEL F7 | 553 | |----------------------->| 554 * Rest of flow not shown * 556 Figure 4: Caller Hungs Up 558 /* Bob disconnects by initiating a Cancel (F6) request and the call 559 is handled as per RFC 3261*/ 561 F6 Message Bob -> Proxy 563 CANCEL sip: sip:bob@biloxi.example.com SIP/2.0 564 Via: SIP/2.0/UDP client.biloxi.example.com:5060;branch=z9hG4bK123 565 Max-Forward: 70 566 From: Bob ;tag=67890 567 To: Alice ;tag=12345 568 Call-ID: 12ka4@biloxi.example.com 569 CSeq: 1 INVITE 570 Content-Length: 0 572 The guidelines of rest of messages flow is described in RFC 3261. 574 7.4 Caller does not have Call Continuation Option feature 576 There might be cases when Bob doesnot support "Continue" header 577 but Alice has enabled NDDND feature. In such a case Bob wouldnot be 578 facilitated with continue advantages. Bob sends initial INVITE 579 without option tag "continue" in Support or Require header and will 580 receive 480 (Temporarily Unavailable) responses. Alice phone will 581 not ring. 583 Bob Proxy Alice (NDDND enabled) 584 | INVITE F1 | | 585 |---------------------->| | 586 | 100 Trying F2 | | 587 |<----------------------| INVITE F3 | 588 | |----------------------->| 589 | | | 590 | | 480 Temporarily | 591 | | Unavailable F5 | 592 | |<-----------------------| 593 | | | 594 * Rest of flow not shown * 596 Figure 5: Caller does not has Call Continuation Option feature 598 NDDND feature will be overwritten and Alice phone ring if the initial 599 INVITE request include Priority header with high value. Basic 600 intention of Alice is not to block urgent or emergency call but to 601 avoid unimportant call as busy. 603 7.5 Callee does not support NDDND feature 605 Alice phone rings which even though option tag "continue" present in 606 Support header of initial INVITE send by Bob. 608 Bob Proxy Alice (NDDND disabled) 609 | INVITE F1 | | 610 |---------------------->| | 611 | 100 Trying F2 | | 612 |<----------------------| INVITE F3 | 613 | |----------------------->| 614 | | | 615 | | 180 Ringing F4 | 616 | |<-----------------------| 617 * Rest of flow not shown * 619 Figure 6: Callee does not support NDDND feature 621 7.6 SIP-ISDN Interworking with Call Continuation feature 623 In this scenario, ISDN terminal(Intelligent mode) has enabled 624 NDDND feature in his/her profile. SIP UAC sends initial INVITE 625 with option tag "continue" in Support header. ISDN terminal asks 626 for confirmation of urgent call before ringing by sending Q 931 627 Information Element (IE) in ISDN Facility message. SIP UAC 628 confirmed as urgent call by providing yes as "Continue" header 629 field value. ISDN terminal phone rings finally. 631 SIP UAC (Bob) SIP Gateway ISDN Terminal (Alice) 632 | INVITE F1 | | 633 |---------------------->| | 634 | 100 Trying F2 | | 635 |<----------------------| Q 931 SETUP F3 | 636 | |----------------------->| 637 | | | 638 | | Call Proceeding F4 | 639 | 182 Queued F5 |<-----------------------| 640 |<----------------------| | 641 | | | 642 | PRACK F6 | | 643 |---------------------->| INFO [Continue] F7 | 644 | |----------------------->| 645 | | | 646 | | | 647 | 200 OK F8 | | 648 |<----------------------| | 649 | | | 650 | | Alerting F9 | 651 | 180 Ringing F10 |<-----------------------| 652 |<----------------------| | 653 | | | 654 * Rest of flow not shown * 656 Figure 7: Interworking Call is Finally Placed by Calling Party 657 Message Details 659 /* The initial INVITE request has option tag "continue" in Support 660 header. */ 662 F1 Message Bob->Proxy 664 INVITE sip:alice@proxy.com SIP/2.0 665 Via: SIP/2.0/UDP client.biloxi.example.com;branch=z9hG4bKnashds8 666 Max-Forwards: 70 667 To: Alice 668 From: Bob ;tag=67890 669 Call-ID: a84b4c76e66710 670 CSeq: 1 INVITE 671 Supported:100rel,continue 672 Contact: 673 Content-Type: application/sdp 674 Content-Length: ... 676 (Bob's SDP not shown) 678 /* Alice supporting the new header extension "Continue", initially 679 her phone does not ring upon receiving initial INVITE request. It 680 will include option tag "continue" in Require header while sending 681 182 (Queued) provisional response to Bob. The response, F5, 682 received at Bob, might look like this. */ 684 F5 Message Proxy ->Bob 686 SIP/2.0 182 Queued 687 Via: SIP/2.0/UDP client.biloxi.example.com;branch=z9hG4bKnashds8 688 To: Alice ;tag=12345 689 From: Bob ;tag=67890 690 Contact: 691 Require: 100rel,continue 692 Call-ID: a84b4c76e66710 693 CSeq: 1 INVITE 694 Content-Type: application/sdp 695 Content-Length: ... 697 (Alice's SDP not shown) 699 /* Thus Bob comes to know that Alice is not willing to accept call 700 if the call is not very important. So Bob has control on the call 701 and can take a decision on his call. Assume Bob finally place the 702 call include "yes" or "YES" as the field value of "Continue" 703 header in PRACK method (F6).*/ 705 F6 Message Bob -> Proxy 707 PRACK sip: sip:alice@proxy.com SIP/2.0 708 Via: SIP/2.0/UDP client.biloxi.example.com:5060; 709 branch=z9hG4bKnash009 710 Max-Forward: 70 711 From: Bob ;tag=67890 712 To: Alice ;tag=12345 713 Call-ID: a84b4c76e66710 714 Require: 100rel,continue 715 CSeq: 2 PRACK 716 RAck: 1 1 INVITE 717 Continue: YES 718 Content-Length: 0 720 F3 Q931 Signaling message (IE) SIP Gateway -> ISDN Terminal 722 03:29:41.816 line:5/0 L3 rx SETUP callref:5. 723 03:29:41.817 hex01: 08 01 05 05 04 03 80 90 a3 6c 06 01 81 33 30 30 724 03:29:41.817 hex02: 31 70 05 81 33 30 30 32 a1 725 03:29:41.817 Called Number : 3002 726 03:29:41.817 Calling Number : 3001 727 03:29:41.819 line:5/0 L1 frame sent. 728 03:29:41.819 line:5/0 L2 tx RR P/F=0 NR=13 C/R=0 TEI=0. 729 03:29:41.819 hex: 00 01 01 1a 731 F4 Q.931 Signaling message (IE) SIP Gateway <- ISDN Terminal 733 03:29:41.859 line:5/0 L1 frame sent. 734 03:29:41.860 line:5/0 L2 tx INFO P=0 NR=13 NS=12 C/R=1 TEI=0. 735 03:29:41.860 hex: 02 01 18 1a 736 03:29:41.860 line:5/0 L3 tx CALL PROCEEDING callref:5. 737 03:29:41.861 hex01: 08 01 85 02 18 01 89 738 03:29:41.861 line:5/7 L1 frame sent. 739 03:29:41.862 line:5/7 L2 tx INFO P=0 NR=4 NS=4 C/R=1 TEI=0. 740 03:29:41.862 hex: 02 01 08 08 742 F7 Q931 Facility message (IE) SIP Gateway -> ISDN Terminal 744 03:29:41.965 line:5/7 L1 frame received. 745 03:29:41.965 line:5/7 L2 rx INFO P=0 NR=5 NS=6 C/R=0 TEI=0. 746 03:29:41.965 hex: 00 01 0c 0a 748 Fac(1c): 08 01 6e 05 1c 31 9f aa 0b 80 01 01 a1 03 80 01 30 82 01 749 00 8b 01 00 a1 1e 02 01 01 02 01 23 30 16 30 14 a1 0f 81 04 45 55 750 52 4f a2 07 81 02 0f 99 82 01 06 82 01 00 752 08|00001000 Protocol discriminator: DSS1 753 01|00000001 Length of callReference: 1 754 6e|0------- Call reference flag: Origination Side 755 |-1101110 Call reference: 110 756 05|00000101 Message type: SETUP 757 1c|00011100 I-Element: Facility information element identifier 758 31|00110001 Length = 49 759 9f|10011111 Protocol Profile: 760 aa|10101010 Tag/Class/Form: aa/Context specific/Constructed () 761 0b|00001011 Length (small) = 11 762 80|10000000 Not decoded 763 01|00000001 Not decoded 764 01|00000001 Not decoded 765 a1|10100001 Not decoded 766 03|00000011 Not decoded 767 80|10000000 Not decoded 768 01|00000001 Not decoded 769 30|00110000 Not decoded 770 82|10000010 Not decoded 771 01|00000001 Not decoded 772 00|00000000 Not decoded 773 8b|10001011 Tag/Class/Form: 8b/Context specific/Primitive () 774 01|00000001 Length (small) = 1 775 00|00000000 Not decoded 776 a1|10100001 Tag/Class/Form: a1/Context specific/Constructed 777 (Invoke) 778 1e|00011110 Length (small) = 30 779 02|00000010 Tag/Class/Form: 02/Universal/Primitive (integer) 780 (Invoke ID) 781 01|00000001 Length (small) = 1 782 01|00000001 Invoke ID: 1 783 02|00000010 Tag/Class/Form: 02/Universal/Primitive (integer) 784 (Operation value) 785 01|00000001 Length (small) = 1 786 23|00100011 Operation value: 35, Continue 787 30|00110000 Tag/Class/Form: 30/Universal/Constructed 788 (sequence) 789 16|00010110 Length (small) = 22 790 30|00110000 Tag/Class/Form: 30/Universal/Constructed 791 (sequence) 793 The guidelines of rest of messages flow is described in RFC 3261 794 and ETSI TS 183 036 V3.4.1 document. 796 7.7 SIP-FXS Interworking with Call Continuation feature 798 In this scenario, FXS phone (Intelligent mode) has enabled NDDDND 799 NDDND feature in his/her analog-user-profile with dial-peer 800 configured for SIP-FXS call with route provisioned in Voice 801 Gateway. SIP UAC sends initial INVITE with option tag "continue" 802 in Support header. FXS phone asks for confirmation of urgent call 803 call before ringing by sending FXS event-triggered Continue 804 message. SIP UAC confirmed as urgent call by providing yes as 805 "Continue" header field value. FXS phone rings finally. 807 SIP UAC (Bob) Voice Gateway Intelligent FXS(Alice) 808 | | | 809 | INVITE F1 | | 810 |---------------------->| | 811 | 100 Trying F2 | | 812 |<----------------------| F3 event incoming call | 813 | |----------------------->| 814 | | on local port 5/1 recvd| 815 | 182 Queued F4 | 816 |<----------------------| | 817 | | | 818 | PRACK F5 | | 819 |---------------------->| event-trigger F6 | 820 | |----------------------->| 821 | | [Continue] received | 822 | | | 823 | 200 OK F7 | | 824 |<----------------------| | 825 | | | 826 | | event FXS port 5/1 | 827 | 180 Ringing F9 |<-----------------------| 828 |<----------------------| status: ringing F8 | 829 | | | 830 * Rest of flow not shown * 832 Figure 8: Interworking Call is Finally Placed by Calling Party 834 Message Details 836 F1 Message Bob->Voice Gateway 838 INVITE sip:6666@20.20.2.71:5060 SIP/2.0 839 Via: SIP/2.0/UDP <20.20.2.10:5062>;branch= 840 z9hG4bKa34888322e87a14e8.b688156c7e0985838 841 Max-Forwards: 70 842 From: "1004" ;tag=6e8892955e 843 To: "6666" 844 Call-ID: 5d2e26590f35cc8b 845 CSeq: 18826 INVITE 846 Allow: INVITE, ACK, CANCEL, BYE, NOTIFY, REFER, OPTIONS, UPDATE, 847 PRACK,SUBSCRIBE, INFO 848 Require:100rel,continue 849 Allow-Events: talk, hold, conference, LocalModeStatus 850 Contact: sip:1004@20.20.2.10:5062 851 Content-Type: application/sdp 852 Content-Length: .... 854 F2 Message Voice Gateway -> Bob 855 SIP/2.0 100 Trying 856 Allow:PRACK,ACK,CANCEL,BYE,SUBSCRIBE,NOTIFY,INVITE,REFER, 857 OPTIONS,INFO,UPDATE, REGISTER 858 Call-ID: 5d2e26590f35cc8b 859 CSeq: 18826 INVITE 860 From: "1004" ;tag=6e8892955e 861 To: "6666" 862 Via: SIP/2.0/UDP <20.20.2.10:5062>;received=20.20.2.10; 863 branch=z9hG4bKa34888322e87a14e8.b688156c7e0985838 865 F3 Voice Gateway -> FXS Phone 867 event "Incoming call on local port: 5/1, calling:1004 , called: 868 6004, call- id: 8" received 869 event "UAC <20.20.2.71:5060> <- UAS <20.20.2.10:5062> INVITE" 870 received 872 F4 Message Voice Gateway -> Bob 874 SIP/2.0 183 Session Progress 875 Allow-Events: hold,talk 876 Call-ID: 5d2e26590f35cc8b 877 Require: 100rel,continue 878 CSeq: 18826 INVITE 879 From: "1004" ;tag=6e8892955e 880 To: "6666" ;tag=2704 881 Via: SIP/2.0/UDP <20.20.2.10:5062>;received=20.20.2.10;branch= 882 z9hG4bKa34888322e87a14e8.b688156c7e0985838 884 F5 Message Bob -> Voice Gateway 886 PRACK sip: sip:alice@proxy.com SIP/2.0 887 Via: SIP/2.0/UDP client.biloxi.example.com:5060; 888 branch=z9hG4bKnash009 889 Max-Forward: 70 890 From: Bob ;tag=67890 891 To: Alice ;tag=12345 892 Call-ID: a84b4c76e66710 893 Require: 100rel,continue 894 CSeq: 2 PRACK 895 RAck: 1 1 INVITE 896 Continue: YES 897 Content-Length: 0 899 F6 Message Voice-Gateway -> FXS Phone (Intelligent) 901 Event Continue is received on local port: 5/1 903 F7 Message Voice Gateway -> Bob 904 SIP/2.0 180 Ringing 905 Allow-Events: hold,talk 906 Call-ID: 5d2e26590f35cc8b 907 CSeq: 18826 INVITE 908 From: "1004" ;tag=6e8892955e 909 To: "6666" ;tag=2704 910 Via: SIP/2.0/UDP <20.20.2.10:5062>;received=20.20.2.10; 911 branch=z9hG4bKa34888322e87a14e8.b688156c7e0985838 913 F8 Message FXS Phone -> Voice Gateway 915 FXS port 5/1 status: ringing on 917 8. Implementation Recommendation 919 "Session Continuation Option" feature in SIP is a new call control 920 feature proposed in this document applicable in favour of Callee 921 that gives option to Caller requesting for a confirmation to place 922 a call to Callee based on the following new applications at the 923 Callee. 925 o Callee unfavorable Time to Receive Call (usually when the 926 Callee is sleeping or travelling, based on Callee time zone 927 which is based on his location that needs to be updated by 928 Callee in case of VoIP subscriber, and manually or 929 automatically done by Mobile Service Provider based on 930 Daylight Savings for 3G/4G subscriber). 932 o Callee has set a Non-Dedicated Do-Not-Disturb (NDDND) that is 933 DND with lower priority when the Callee is in a theatre, 934 meeting, driving, lunch/dinner, etc. - Callee is willing to 935 receive the call only when it is very urgent. 937 This application is totally based on SIP Call Session 938 Establishment principles (Offer-Answer Model) with minor 939 deviation in call flows and is implementation specific and 940 driven based on configuration at. 942 o SIP UA or Voice Over Internet Protocol (VoIP) End Device, 943 3G/4G Handsets (Device Driven) - Device plays more important 944 role in Call Handling. 946 o SIP Back-To-Back User Agent (B2BUA) server as a part of Voice 947 Feature Services given by the Service Provider (Service 948 Provider Driven) - Network plays more important role in Call 949 Handling instead of SIP Terminals or 3G/4G Handsets. 951 This Call Feature Application handling behaviour and subsequent 952 actions at the Calling and Callee and SIP AS is clearly defined 953 later using State Diagrams based on the call confirmation options 954 handled by Calling Party and relevant configurations / services 955 provided by the Network Service Provider. 957 This feature can be implemented using SIP with minor changes at 958 protocol level by introducing "Continue" header in SIP PRACK 959 Request and slight changes in the basic Offer-Answer Model 960 implementation in both UAs and SIP AS based on implementation, 961 calls of which are discussed in detail later on. There will be an 962 additional need of changes in UA Application and also at SIP AS in 963 case this feature is driven by a SIP AS instead of Callee. 965 This feature is fully backward compatible and doesnot have any 966 impact on existing Subscribers, Devices, Network Setup and 967 Operation. The Service Provider may need to upgrade their SIP 968 Application server in case they wish to give this new voice 969 feature as a new service to their subscribers. Similarly Device 970 Manufacturer needs to upgrade the application of their handsets or 971 introduce as a new application feature in their new Handsets or 972 Devices. 974 9. IANA Considerations 976 This document registers a new header field name with a compact 977 form and one new option tag. 979 9.1 IANA Registration of "Continue" SIP Header field 981 Name of Header: Continue 982 Compact Form: g 984 9.2 IANA Registration of "continue" SIP Option-tag 986 Name of option: continue 987 Description: Support for the SIP Continue header. 989 10. Security Considerations 991 The Continue header in this document does not in itself have 992 security considerations. However, as mentioned in RFC 3427[6], an 993 important reason for the IETF to manage the extensions of SIP is to 994 ensure that all extensions and parameters are able to provide secure 995 usage. 997 11. Acknowledgements 999 Thanks to Paul Kyzivat, Worley, Dale R (Dale), John Elwell and Ram 1000 Mohan R who provided helpful comments, feedback and suggestions. 1002 Also the authors would like to thank Mayur Saxena, Jay Prakash 1003 Dubey, Lakshmi P Vijay Badithe, Prasad Kulkarni, Rajesh Batagurki, 1004 Vineet Hada, Ayan Ghosh, Reetesh Gupta, Nishesh Shukla, Dipankar 1005 Goswami, Gagandeep Singh and Gauri Kshirsagar for their input. 1007 12. References 1009 12.1 Normative References 1011 [1] Rosenberg, J., "A Presence Event Package for the Session 1012 Initiation Protocol (SIP)", RFC 3856, August 2004. 1014 [2] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 1015 Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: 1016 Session Initiation Protocol", RFC 3261, June 2002. 1018 [3] Rosenberg, J. and H. Schulzrinne, "Reliability of Provisional 1019 Responses in the Session Initiation Protocol (SIP)", RFC 3262, 1020 June 2002. 1022 [4] Rosenberg, J., "The Session Initiation Protocol (SIP)UPDATE 1023 Method", RFC 3311, October 2002. 1025 12.2 Informative References 1027 [5] Bradner, S., "Key words for use in RFCs to indicate requirement 1028 levels," BCP 14, RFC 2119, March 1997. 1030 [6] Peterson, J., Jennings, C., and R. Sparks, "Change Process for 1031 the Session Initiation Protocol (SIP) and the Real-time 1032 Applications and Infrastructure Area", BCP 67,RFC 5727, 1033 March 2010. 1035 [7] Q.931 : ISDN user-network interface layer 3 specification for 1036 basic call control 1038 13. Authors' Addresses 1040 Amardeep Sinha 1041 FF02, First Floor, 1042 Rainbow Residency, 1043 Green-Glen-Layout, 1044 Bellandur, Outer-Ring-Road 1045 Bangalore (Karnataka) 1046 India -560103 1048 EMail: sinha.amardeep@gmail.com 1049 Subhrajyoti De 1050 F.E. 91 SECTOR 3 1051 SALT LAKE CITY 1052 KOLKATA - 700 106. 1053 WEST BENGAL. INDIA. 1055 EMail: de_subhrajyoti@yahoo.co.uk 1057 Sunil Kumar Sinha 1058 FF01, First Floor, 1059 Rainbow Residency, 1060 Green-Glen-Layout, 1061 Bellandur, Outer-Ring-Road 1062 Bangalore (Karnataka) 1063 India -560103 1065 EMail: sunilkumarsinha9@gmail.com 1067 MANJUNATH Hanchinal 1068 64, C-101, GAGAN DARSHAN APARTMENTS, 1069 10TH A CROSS KANAKA NAGAR, 1070 R.T. NAGAR, 1071 Bangalore (Karnataka) 1072 India -560032 1074 EMail: manjugd@gmail.com