SIPPING Working Group Internet-Draft T. Stolz Expires: July 11, 2007 Kapsch Business Com AG M. Alexander Wirtschaftsuniversitaet Wien Centralized Operator Call Control Framework for the Session Initiation Protocol (SIP) draft-stolz-centop-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 July 11, 2007. Copyright Notice Copyright (C) The Internet Society (2007) Abstract This document proposes a call control framework for the Session Initiation Protocol (SIP). The framework is based on the SIP Subscribe/Notify Method and aims to facilitate implementation of a standardized approach in supporting vendor neutral centralized switchboard functionality for PBXs. T.Stolz, M. Alexander Expires July 11, 2007 [Page1] Internet-Draft Centralized Operator Call Control Framework Jan 2007 Table of Contents 1. Terminology ...................................................2 2. Introduction ..................................................2 3. Notify/Subscribe Method .......................................3 3.1. Header Field Support for Notify/Subscribe Method .........4 3.2. Responses to the Notify/Subscribe Method .................4 3.3. Message Body Inclusion ...................................4 3.4. Behaviour of SIP User Agents ...........................4 3.5. Behaviour of the SIP Proxy ...............................4 4. NOTIFY Message Bodies .........................................4 5. Example .......................................................5 5.1. Example Call Flow ........................................5 5.2. Example Call Flow using Gateways and a Proxy Server ......5 5.3. Example Message Body with XML Content ....................6 6. References ....................................................7 7. Authors’ Address ..............................................7 1. Terminology 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 RFC 2119 [1]. 2. Introduction Up to now different vendors have implemented centralized PBX switchboard functionality using proprietary user-user signalling in ISDN and the H.323 protocol. There have not been efforts to set a standard yet. Due to the more open architecture of the SIP protocol, we believe PBX vendors will tend to implement the centralized switchboard services in SDP or will use CTI services. A standard-confirming application of the SIP notify/subscription mechanism described in RFC 2543 [2] will be used for defining this vendor neutral centralized switchboard functionality. T.Stolz, M. Alexander Expires July 11, 2007 [Page2] Internet-Draft Centralized Operator Call Control Framework Jan 2007 PBX A PBX B +------+ +------+ PSTN - | |- EXT A | |- PSTN | | | | SB A - | |-------- WAN ------------ | |- SB B +------+ +------+ PSTN ... public switched telephony network PBX ... private branch exchange WAN ... wide area network SB ... switchboard SB B in PBX B should get all switchboard calls from PBX A if SB A is off-line. PBX A has to be informed about availability of SB B. Without the state information for PBX B no call should be routed to switchboard in PBX B. This means that PBX A has to be notified about the status of the switchboard in PBX B. Additionally, all important information for network rerouting should be delivered. This may be done in both directions. 2.1 Example Uses The following are examples for use cases: - Carrying all information needed for outsourcing switchboard services to a centrex of public switch provider.[4],[5] - Carrying PBX Vendor information for network monitoring purposes and statistics done via proxy server. - Carrying additional information about different customer settings and different rerouting paths within same exchange. - Possibility for full integration into IMS networks [4],[5] 3. Notify/Subscribe Method The notification about the actual switchboard state can be done using either in a one-or two step approach, depending on complexity and network size. In a mandatory first step, the presence of any operator present is sent. This means that the serving PBX informs the served PBX if it is possible to handle calls for it.[3] T.Stolz, M. Alexander Expires July 11, 2007 [Page3] Internet-Draft Centralized Operator Call Control Framework Jan 2007 A second optional step can be used to send/receive information about each individual switchboard status of the serving PBX. This information can be used by the served PBX for routing target decision. Both steps could be included in same notify message. 3.1. Header Field Support for Notify/Subscribe Method Handling Header Field is outside of scope of this document and has to comply with rules defined in [2]. 3.2. Responses to the Notify/Subscribe Method A 200 OK response shall be sent if the Subscribe and Notify method was successfully received and rerouting will be done. Other response codes are: Request Failure (4xx), Server Failure (5xx) and Global Failure (6xx) responses may also be received and will be treated by the sending PBX as "no rerouting will be done". 3.3. Message Body Inclusion The Notify Method has to contain a message body. Additional information, such as specific customer data or more detailed information may be included in the message body e.g. using XML. 3.4. Behaviour of SIP User Agents[2] Unless stated otherwise, the protocol rules for the notify/subscribe request governing the usage of tags, Route and Record-Route, retransmission and reliability, CSeq incrementing and message formatting follow those specified in [2]. The Subscribe/Notify Method MUST NOT change the state of a SIP call or any sessions initiated by SIP [2],[3]. 3.5. Behaviour of the SIP Proxy Handling of the SIP Proxy Server should be done according to [2],[3] 4. NOTIFY Message Bodies The following information MUST be included in the Notify message body to provide mandatory information to the subscriber: T.Stolz, M. Alexander Expires July 11, 2007 [Page4] Internet-Draft Centralized Operator Call Control Framework Jan 2007 OwnExchangeID: NotifiedExchangeID: OwnSwitchBoardID: OwnSwitchBoardStatus: OpenForReroutedCalls: OpenForRecalledCalls: The following information SHOULD be included in Notify message to provide information about the vendor and type of cooperating exchange: Vendor: Type1: Type2: The following information MAY be included in the Notify message body to provide additional information to the subscriber: Customer: MinimumWaitingTime: MaximumWaitingTime: AverageWaitingTime: 5. Examples 5.1. Example Call Flow [3] Subscriber Notifier |-----SUBSCRIBE---->| Request state subscription |<-------200--------| Acknowledge subscription |<------NOTIFY----- | Return current state information |--------200------->| |<------NOTIFY----- | Return current state information |--------200------->| 5.2. Example Call Flow using Gateways and a Proxy Server PBX A (GW1) Proxy Server (GW 2) PBX B |--------->|------------>|------------>|----------->| | SUBSCRIBE | SUBSCRIBE | | | | | | |<---------|<------------|<------------|<-----------| | 200 OK | 200 OK | T.Stolz, M. Alexander Expires July 11, 2007 [Page5] Internet-Draft Centralized Operator Call Control Framework Jan 2007 | | | | | |<-------- |<------------|<------------|<-----------| | NOTIFY | NOTIFY | | | | | | |--------->|------------>|------------>|----------->| | 200 OK | 200 OK | | | | | | |<---------|<------------|<------------|<-----------| | NOTIFY | NOTIFY | | | | | | |--------->|------------>|------------>|----------->| | 200 OK | 200 OK | 5.3. Example Message Body with XML Content T.Stolz, M. Alexander Expires July 11, 2007 [Page6] Internet-Draft Centralized Operator Call Control Framework Jan 2007 6. References [1] Bradner, S.,”Key words for use in RFCs to Indicate Requirement Levels”, RFC 2119, March 1997 [2] Handley, M., Schulzrinne, H., Schooler, E. and J. Rosenberg, "SIP: Session Initiation Protocol", RFC 2543, March 1999. [3] Roach A.B. “Session Initiation Protocol (SIP)-Specific Event Notification", RFC 3265, June 2002 [4] 3GPP, "Presence Service; Architecture and functional description; Stage 2", 3GPP TS 23.141, June 2005 [5] 3GPP, "IP Multimedia Subsystem (IMS); Stage 2" 3GPP TS 23.228, June 2005 7. Authors’ Address Thomas Stolz Kapsch Business Com AG Wienerbergstrasse 53 1120 Vienna Austria Email: thomas.stolz@kapsch.net Michael Alexander Wirtschaftsuniversität Wien Augasse 2-6 1090 Vienna Austria Email: malexander@wu-wien.ac.at Intellectual Property Statement The IETF takes no position regarding the validity or scope of any T.Stolz, M. Alexander Expires July 11, 2007 [Page7] Internet-Draft Centralized Operator Call Control Framework J an 2007 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. Disclaimer of Validity 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. Copyright Statement Copyright (C) The Internet Society (2007). 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. Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society. T.Stolz, M. Alexander Expires July 11, 2007 [Page8]