SIPCORE Working Group A.Klimov Internet-Draft Synterra-Ural Intended status: Informational 26 May 2009 Expires: November 28, 2009 B2BUA with Survivability Feature draft-klimov-sipcore-b2bua-survivability-00 Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and 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 November 27, 2009. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Abstract This draft describes the behavior of Session Initiation Protocol (SIP) [RFC3261] Back-To-Back User-Agent (B2BUA) with survivability feature, we can define it as a survivable SIP proxy (SSP), and how it should process calls in two different modes one is normal (no- failure) mode and the other is survivable (breakdown) mode. Klimov Expires: November 28, 2009 [Page 1] Internet-Draft B2BUA with Survivability Feature 26 May 2009 1. Introduction It is preferable that standalone B2BUA which connects users on one network with SIP server located in other network has possibility to serve calls in case of emergency. Emergency implies that the connection with SIP proxy is lost. Survivability in this meaning should be possibility to accept REGISTER requests alongside with ability to route SIP signalling traffic to another SIP server. The behavior of B2BUA with survivability feature should differ in different modes. 2. Conventions 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 BCP 14, RFC 2119 [RFC2119]. 3. Definitions There are two types of SIP servers in this scenario should be defined. Main SIP server - SIP proxy or registrar to which SIP signalling messages from UAC are redirected in no-failure mode.It MUST be aware for UAC registration. Backup SIP server - SIP proxy to which SIP signalling messages except REGISTER requests from UAC are redirected in breakdown mode. There are two modes of work possible first is no-failure mode when SSP works as a B2BUA and the second is breakdown mode when SSP works as a local registrar within working as B2BUA. 4. B2BUA behavior in normal (no-failure) mode. In no-failure mode SSP MUST redirect SIP signalling messages from UAC to main SIP server until it is reachable. Survivable SIP proxy MUST store registration information in its cache. Reachability state should be checked by means of sending OPTIONS SIP messages to main SIP server. The time period of reachability checking SHOULD be configurable. In this mode the backup SIP server does not participate in work. SSP should accept signalling messages from main SIP proxy and forward them to UAC. 5. B2BUA behavior in survivable (breakdown) mode. In case of main SIP server is unreachable survivable SIP proxy (SSP) SHOULD switch to breakdown mode and MUST use registration information from its cache and terminate registration requests on itself instead of sending them to any SIP server. Survivable SIP proxy (SSP) SHOULD continue check the reachability of Main SIP server by sending OPTIONS Klimov Expires: November 28, 2009 [Page 2] Internet-Draft B2BUA with Survivability Feature 26 May 2009 SIP messages. SSP SHOULD redirect all UAC messages except REGISTER messages to backup SIP server. Incoming calls will go to UAC from backup SIP server so SSP SHOULD be responsible for accepting SIP signalling from backup SIP server. In case of backup SIP server is unreachable survivable SIP proxy (SSP) MUST use registration information from its cache and terminate registration requests on itself instead of sending them to any SIP server. Thus UAC has a valid registration. These registrations should enable calls between UACs registered on SSP. In case main SIP server is reachable survivable SIP proxy (SSP) should switch to normal mode and forward SIP messages from UAC to main SIP Server. 6. Acknowledgments The author would like to acknowledge many people who invent the idea of survivability feature. 7. Security Considerations There are no security considerations. 8. IANA Considerations There are no IANA Considerations. 9. References 9.1. Normative 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", RFC 3261, June 2002. Author's Address Klimov Andrey Synterra-Ural Ltd. Ternopolskaya, 6 Chelyabinsk, Russia, 454091 Phone: + 7 351 2470700 EMail: andrey.klimov@synterra-ural.ru Klimov Expires: November 28, 2009 [Page 3]