Network Working Group R. Narang Internet-Draft Cisco Systems Inc. Intended status: Standards Track June 2006 Expires: December 3, 2006 Session Initiation Protocol (SIP) Mid-Dialog Status code for network disconnection on one side of B2BUA draft-ranarang-sipping-middialog-sip-status-00.txt Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on December 3, 2006. Copyright Notice Copyright (C) The Internet Society (2006). Narang Expires December 3, 2006 [Page 1] Internet-Draft B2BUA n/w disconn, Mid-dialog Status code June 2006 Abstract This document defines a new SIP status code needed for communicating about the network failure happening in signaling connection on one side of the B2BUA to the other side of B2BUA on an established dialog/session. The network failure condition MAY be detected by session timers [rfc4028] or any other proprietary mechanism. Table of Contents 1. Requirements notation . . . . . . . . . . . . . . . . . . . . 3 2. Introduction and Overview . . . . . . . . . . . . . . . . . . 4 2.1. Simple Handling of the n/w failure . . . . . . . . . . . . 4 2.2. Optimized Handling . . . . . . . . . . . . . . . . . . . . 5 3. B2BUA detecting the network failure behavior . . . . . . . . . 6 3.1. B2BUA wants to remain in partial dialog for CDR . . . . . 6 3.1.1. UA4 is a non-refresher . . . . . . . . . . . . . . . . 6 3.1.2. UA4 is a refresher . . . . . . . . . . . . . . . . . . 6 3.2. B2BUA doesn't want to remain in partial dialog . . . . . . 6 4. B2BUA receiving the 450 status code behavior . . . . . . . . . 7 4.1. UA3 handling . . . . . . . . . . . . . . . . . . . . . . . 7 4.2. UA2 handling . . . . . . . . . . . . . . . . . . . . . . . 7 5. Phone detecting the network failure behavior . . . . . . . . . 8 5.1. Phone2 is a Media Application . . . . . . . . . . . . . . 8 6. Phone receiving the 450 status code behavior . . . . . . . . . 9 6.1. 450 receipt in session refresh . . . . . . . . . . . . . . 9 6.2. 450 receipt in BYE's Reason header . . . . . . . . . . . . 9 7. Proxy's 450 status code behavior . . . . . . . . . . . . . . . 10 7.1. Call Stateful Proxy . . . . . . . . . . . . . . . . . . . 10 7.2. Transaction Stateful Proxy . . . . . . . . . . . . . . . . 10 7.3. Stateless Proxy . . . . . . . . . . . . . . . . . . . . . 10 8. Call Stateful Proxy Session Timeout handling . . . . . . . . . 11 9. IP-PSTN GW receiving the 450 status code behavior . . . . . . 12 10. NAT/ALG's 450 status code behavior . . . . . . . . . . . . . . 13 11. CDR logging of 450 status code . . . . . . . . . . . . . . . . 14 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 12.1. IANA Registration of the 450 (Call in minimal state) Response Code . . . . . . . . . . . . . . . . . . . . . . 15 13. Backward's compatibilty . . . . . . . . . . . . . . . . . . . 16 14. 450 (Call in minimal state) Definition . . . . . . . . . . . . 17 15. Security Considerations . . . . . . . . . . . . . . . . . . . 18 16. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 20 Intellectual Property and Copyright Statements . . . . . . . . . . 21 Narang Expires December 3, 2006 [Page 2] Internet-Draft B2BUA n/w disconn, Mid-dialog Status code June 2006 1. Requirements notation The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. Narang Expires December 3, 2006 [Page 3] Internet-Draft B2BUA n/w disconn, Mid-dialog Status code June 2006 2. Introduction and Overview Consider that a SIP session was established using an INVITE dialog from phone1 to phone2 with B2BUA's in the path as per the following topology:- +----+ +---------+ +---------+ +----+ | +-+| |+-+ +-+| |+-+ +-+| |+-+ | | | || dialog1 || | | || dialog2|| | | || dialog3|| | | | |U||<-------->||U| |U||<------>||U| |U||<------>||U| | | |A|| nw1 ||A| |A|| nw2 ||A| |A|| nw3 ||A| | | |1|| ||2| |3|| ||4| |5|| ||6| | | | || || | | || || | | || || | | | +-+| |+-+ +-+| |+-+ +-+| |+-+ | +----+ +---------+ +---------+ +----+ phone1 B2BUA1 B2BUA2 phone2 Figure 1 There will be an active INVITE dialogs between individual UA's. Consider during session establishment, UA's have negotiated the session timers on the individual INVITE dialogs as per [rfc4028]. The session timers are actively running for monitoring the liveliness of the SIP session. Note:- In the B2BUA configuration as above, the session timers are independently negotiated for each individual dialog between UA's. There is only one media session i.e from phone1 to phone2. The session i.e media path from phone1 to phone2 could have been established using a different network than the call signaling (i.e dialog) path. Consider 'nw3' as per above topology encounters a sudden network failure condition. After session timeout for dialog3, the 'UA5' & 'UA6' will be able to detect this error condition. 2.1. Simple Handling of the n/w failure A simple implementation of UA5 or UA6 would assume this as a critical condition. The UA6 may stop the session (media) and give reorder tone to the user. The UA5 would assume that sip session is also torn down, so it will initiate tearing down the dialog2 towards B2BUA1 by sending a BYE. Narang Expires December 3, 2006 [Page 4] Internet-Draft B2BUA n/w disconn, Mid-dialog Status code June 2006 2.2. Optimized Handling An optimized implementation at UA6 (phone2) would be to not assume this as a critical problem for an active SIP media session between phone1 & phone2. It could try its best to 'not' interrupt the active media connection between phone2 and phone1. The UA6 MAY want to wait for actual physical hang-up from the phone2 user. An optimized implementation at B2BUA2 would be to not tear down an active sip 'dialog2' towards B2BUA1 and instead communicate the status of nw3's "out of order condition" which impacted dialog3. The B2BUA1 on learning about dialog3 disconnection due to n/w failure, could take an appropriate action whether to tear down the 'associated' SIP session towards UA1 or wait for normal hang-up from phone1. As it is described the requirement is to communicate the failure status across the B2BUA about one SIP dialog 'dialog3' onto the another SIP dialog 'dialog2' associated with the same SIP session. Currently in SIP specification there is no appropriate Status code for communicating this kind of failure from one sip dialog to another for an established session. To fulfill this requirement a new SIP Status code 450 "Call in minimal state" is being proposed. Note:- The above optimized handling is also possible when there is only one B2BUA in the configuration. Narang Expires December 3, 2006 [Page 5] Internet-Draft B2BUA n/w disconn, Mid-dialog Status code June 2006 3. B2BUA detecting the network failure behavior This is referring UA5 in Figure 1. The UA5 shall be monitoring the session by using session timers or some other proprietary mechanism. We shall be discussing in the context of session timers throughout this document. During session establishment, it would have been negotiated whether UA5 is a "refresher" or a "non-refresher". The failure of session timer's refresh would not certainly tell whether UA6 crashed or it is due to network connectivity issues. For optimized handling UA5 SHALL make an assumption that session timeout is due to network connectivity issues. The UA5 SHALL internally communicate this condition to the UA4 by passing the 450 status code. Then UA5 MAY terminate itself. The UA4 MAY handle this special condition in two ways depending on whether or not it needs to remain in the partial dialog for the purposes of logging "Call Detail Records" on completion of the SIP session with phone1. 3.1. B2BUA wants to remain in partial dialog for CDR 3.1.1. UA4 is a non-refresher When UA4 is the "non-refresher" for dialog2, then on receiving the next session refresh i.e a re-INVITE or UPDATE, a 450 "Call in minimal state" response MUST be sent. 3.1.2. UA4 is a refresher When UA4 is the "refresher" for dialog2, then an INVITE/UPDATE with Reason header having SIP Status code 450 MUST be sent. Reason: SIP;cause=450;text="Call in minimal state" The session refresh procedure on dialog2 MUST be continued until a BYE is received from remote or session refresh timeout occurs. 3.2. B2BUA doesn't want to remain in partial dialog A BYE with SIP Status code 450 SHOULD be sent and UA4 MUST be terminated on receiving 200 OK (for BYE). Reason: SIP;cause=450;text="Call in minimal state" Narang Expires December 3, 2006 [Page 6] Internet-Draft B2BUA n/w disconn, Mid-dialog Status code June 2006 4. B2BUA receiving the 450 status code behavior This is referring to UA3 in Figure 1. The receipt of SIP Status code="450" by UA3 would indicate that somewhere in the network segment connecting from remote UA or further down, the network is detected as "disconnected". There is no specific information whether the SIP Session/media path between the caller and callee is still active or got disconnected. The received 450 status code MUST be communicated to the other side of B2BUA. 4.1. UA3 handling The UA3 MUST interwork the 450 status code to the UA2 in the same B2BUA. The UA3 handling SHALL be based on whether BYE with 450 in Reason header is received or whether it is the refresher and 450 response to re-INVITE/UPDATE is received or whether it is the non- refresher and re-INVITE/UPDATE with 450 in Reason header is received. The receipt of BYE SHOULD immediately terminate the UA3 and dialog2. Otherwise the session timers mechanism on dialog2 MUST continue until UA2 sends a disconnect (for receipt of BYE on dialog1, or when UA2 needs to tear down the partial dialog by sending a BYE on dialog1). If session timer's timeout occurs on UA3 then also UA3 MUST clear itself. 4.2. UA2 handling The UA2 handling is going to be same as UA4 as it is described above. The UA2 MAY handle this special condition in two ways depending on whether or not it needs to remain in the partial dialog for the purposes of logging "Call Detail Records" on completion of the SIP session with phone1. Preferably immediate B2BUA interacting with the phone UA SHOULD NOT clear the dialog with phone UA until hangup from the phone. The session refresh SHOULD continue until then. If UA2 needs to clear itself, it MUST send an internal disconnect to UA3 and MUST send a BYE with Reason header having a SIP Status code=450 on dialog1. After UA2 receives 200 OK (for BYE) it MUST terminate itself. The internal disconnect to UA3 SHALL result in sending BYE on dialog2, which SHALL clear the dialog with remote UA4. If UA2 needs to remain then it SHOULD continue with the session timers procedure and respond with 450 status code for non-refresher case and MUST send INVITE/UPDATE having 450 in the reason header for refresher case on the session timeout. Narang Expires December 3, 2006 [Page 7] Internet-Draft B2BUA n/w disconn, Mid-dialog Status code June 2006 5. Phone detecting the network failure behavior This is referring UA6 (phone2) in Figure 1. When a phone detects a network failure condition for an established signaling connection via session timers or any other proprietary mechanism it implies a problem in the connectivity for the SIP dialog. The associated SIP media session could have been established through a different network, so sip dialog disconnection due to n/w error doesn't definitely imply that media session is also impacted. Rather than tearing down the media session, best attempt handling would be to just preserve the existing session in a limited mode i.e no other feature capabilities possible. For disconnecting the session, the phone MAY wait for hang-up from the user or MAY depend on media specific monitoring of the session. In this condition the SIP dialog SHALL be terminated immediately, but SIP media session MAY be preserved until hang-up. So phone2 SHALL go into a state where it will just have the media session operational. There SHALL be no 450 status code generation by the phone UA as SIP dialog is already torn down. 5.1. Phone2 is a Media Application It is possible that phone2 is a Media Application i.e. there is no human user e.g IVR or Call Recorder. On session timeout at UA6 (phone2), the SIP dialog with immediate B2BUA SHALL be cleared. So there SHALL be no BYE message received to tear down the media session. If Media application is implementing media session preservation for such scenarios, it MUST be required to additionally kick-off RTP/RTCP monitoring capability on such a condition, so that it is detected when to stop communicating media with the remote and close the RTP/ RTCP channels. Narang Expires December 3, 2006 [Page 8] Internet-Draft B2BUA n/w disconn, Mid-dialog Status code June 2006 6. Phone receiving the 450 status code behavior This is referring UA1 (phone1) in Figure 1. The receipt of 450 status code SHALL intimate to the phone that the network through which the sip dialog was established has detected an error in connectivity. There is no definite information about the status of SIP media session. An optimized action at the UA1 would be to do the best effort handling i.e no interruption to the existing media session. For making sure no features on the SIP dialog are allowed, the softkeys on the phone MUST be disabled. 6.1. 450 receipt in session refresh If UA1 is the refresher, the 450 response SHALL be received in response to INVITE or UPDATE. If UA1 is the non-refresher, the 450 response SHALL be received in the INVITE's Reason header. The session timer's refresh procedure MUST keep on running. For tearing down the session the phone UA MUST wait for hang-up from the user. When user hangs up then a BYE message MUST be sent to the B2BUA. 6.2. 450 receipt in BYE's Reason header This is the scenario when B2BUA's doesn't want to remain in the minimal dialog for CDR purposes. The Phone UA MUST interpret the Reason header in BYE and if 450 is received it would mean to attempt optimized handling as described above. The phone UA MUST send 200 OK for BYE and dialog1 SHALL be terminated. The phone1 will go into a state where it will just have the media session operational. On user hangup the media session i.e RTP/RTCP channels SHOULD be closed. Narang Expires December 3, 2006 [Page 9] Internet-Draft B2BUA n/w disconn, Mid-dialog Status code June 2006 7. Proxy's 450 status code behavior Consider there is a Proxy in the signaling path from phone1 to phone2. 7.1. Call Stateful Proxy Consider that a sip dialog was established from UA through the proxy to a remote UA, the proxy chose to be in the path of all the requests sent in a sip dialog by adding Record-Route header in the requests and responses forwarded through it. For the mid dialog re-INVITE's forwarded through the Proxy, if the client transaction receives a 450 status code from the UAS, the same 450 response MUST be forwarded by the proxy to the server transaction for sending to the UAC. The standard handling as per section 16.7 of per [rfc3261] SHALL be performed with no special handling specific to 450. 7.2. Transaction Stateful Proxy The proxy which is only a transaction stateful will not be in the path of SIP messages after initial INVITE/200 OK exchange. The 450 status code is intended to be useful on an established session/dialog for communicating about sudden network failure in the signaling path in some segment. The 450 status code SHALL be generated by B2BUA and possibly will not be traversing through the proxy, which is transaction stateful only. 7.3. Stateless Proxy If 450 status code response is received by a stateless Proxy, the standard handling as per section 16.11 of [rfc3261] SHALL be performed. Narang Expires December 3, 2006 [Page 10] Internet-Draft B2BUA n/w disconn, Mid-dialog Status code June 2006 8. Call Stateful Proxy Session Timeout handling Assume the configuration having UA endpoints communicating through a call stateful proxy and no B2BUA in the path. During session establishment the session timers were exchanged and actively running for monitoring the session. There will be a session timer running on the stateful proxy. If this timeout occurs on the proxy it would mean either the refresher UA hasn't refreshed or 200 OK from non-refresher isn't received in time. It might be possible that n/w path from proxy to either UA got lost. On encountering this condition, the proxy will remove the call state w/o initiating the BYE from itself as per [rfc4028]. In case later an INVITE/UPDATE/BYE or other response is received from the UA's, it shall be proxied to the other side without using the call stateful proxy logic i.e will be routed by using the Request-URI in the SIP message. The proxy SHALL NOT generate a 450 status code on its own in this condition. At the UA endpoints also, there will be a session timeout condition i.e refresher will not receive 200 OK or non-refresher will not receive the session refresh request. The handling for this condition at the phone UA will be implementation specific or as per section 5 of this draft. As both UA endpoints will autonomously detect this error condition, either side SHALL NOT be generating or handling 450 status code in this situation. Narang Expires December 3, 2006 [Page 11] Internet-Draft B2BUA n/w disconn, Mid-dialog Status code June 2006 9. IP-PSTN GW receiving the 450 status code behavior The receipt of 450 status code SHALL imply that remote UA has probably detected a network disconnection in a sip dialog towards other side of the UA or further down the network towards the destination party, a disconnection caused sending of 450 status code on the sip dialog towards the IP-PSTN GW. The 450 status code could be received in the following ways:- 1. BYE with Reason header having 450 status code. With receipt of BYE the dialog from IP-GW to the remote UA gets terminated. 2. SIP leg on the GW is the refresher and in response to re-INVITE/ UPDATE, a 450 status code is received. The session timers MAY continue until hang-up from the user on the PSTN side or until a failure occurs in session refresh procedure. 3. SIP leg on the GW is the non-refresher and a remote sends a re- INVITE with Reason header having 450 status code. The session timers MAY continue until hang-up from the user on the PSTN side or until a failure occurs in session refresh procedure. For the above cases the IP-PSTN GW MAY maintain a SIP leg/dialog in a minimal state allowing the preservation of the established media session. There MAY NOT be any notification to the PSTN side about this situation. Any features attempted from the PSTN side MUST be rejected with appropriate Q.931 specific error codes. Narang Expires December 3, 2006 [Page 12] Internet-Draft B2BUA n/w disconn, Mid-dialog Status code June 2006 10. NAT/ALG's 450 status code behavior If NAT receives a 450 status code during session refresh, it would imply that network link in the further segment has been detected down. The session refresh between the sip elements will be continuing until a BYE is received, so there SHOULD NOT be transport disconnection on receipt of 450 by NAT/ALG's. Narang Expires December 3, 2006 [Page 13] Internet-Draft B2BUA n/w disconn, Mid-dialog Status code June 2006 11. CDR logging of 450 status code If there has been 450 status code specific handling in a SIP call leg then while CDR's are generated the information about 450 MAY be logged to CDR's. This will indicate that media might have been active longer than the call duration logged in the CDR's due to the specific nature of the 450 status code, allowing media session to be active without the SIP dialog for n/w error conditions. Narang Expires December 3, 2006 [Page 14] Internet-Draft B2BUA n/w disconn, Mid-dialog Status code June 2006 12. IANA Considerations This extension defines a new response code i.e 450. 12.1. IANA Registration of the 450 (Call in minimal state) Response Code The following is the registration for the 450 (Call in minimal state) response code: Response Code: 450 Default Reason Phrase: Call in minimal state RFC Number: Narang Expires December 3, 2006 [Page 15] Internet-Draft B2BUA n/w disconn, Mid-dialog Status code June 2006 13. Backward's compatibilty If a version of intermediate proxy or B2BUA is not implementing 450 response handling then it will result in session timeout on that element, which will result in immediate clearing of the established dialog/media session for the call. Narang Expires December 3, 2006 [Page 16] Internet-Draft B2BUA n/w disconn, Mid-dialog Status code June 2006 14. 450 (Call in minimal state) Definition This response code indicates that the network through which the sip dialog was successfully established has detected an error in connectivity. There is no definite information about the status of SIP session. Its default reason phrase is "Call in minimal state". Narang Expires December 3, 2006 [Page 17] Internet-Draft B2BUA n/w disconn, Mid-dialog Status code June 2006 15. Security Considerations None. Narang Expires December 3, 2006 [Page 18] Internet-Draft B2BUA n/w disconn, Mid-dialog Status code June 2006 16. References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [rfc3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", June 2002. [rfc4028] Donovan, S. and J. Rosenberg, "Session Timers in the Session Initiation Protocol (SIP)", April 2005. Narang Expires December 3, 2006 [Page 19] Internet-Draft B2BUA n/w disconn, Mid-dialog Status code June 2006 Author's Address Rajeev Narang Cisco Systems Inc. 12 Bannerghatta Road Subramanya Arcade Block D Bangalore India Email: ranarang@cisco.com Narang Expires December 3, 2006 [Page 20] Internet-Draft B2BUA n/w disconn, Mid-dialog Status code June 2006 Full Copyright Statement Copyright (C) The Internet Society (2006). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Narang Expires December 3, 2006 [Page 21]