Technical Paper. Call Completion (CCBS/CCNR) On Issue 1.0

Transcription

1 Technical Paper Call Completion (CCBS/CCNR) On Issue 1.0 Siemens Enterprise Communications GmbH & Co KG Munich, 09/06/2010 Germany Siemens Enterprise Communications

2 Executive Summary Call completion is a telephony feature which takes action on a failure to complete a call. It allows for notifying the calling user when the called user is available again. This document covers two conditions for call completion: CCBS (Call Completion Busy Subscriber): The called party is busy. CCNR (Call Completion No Reply): The called party does not respond. Call completion features can be implemented on a PBX, a dedicated server (e.g. a voic server) or directly on the client device (e.g. messaging applications). There are several commercial companies which provide call completion features, as well as IETF documents specifying call completion features for open standards, such as SIP. The RFC 5359 gives a best practice example for call completion. However, the SEN OSCAR group has evaluated this RFC with the result that it is not useful for a B2BUA architecture. The IETF BLISS working group currently provides a draft paper ( on how call completion can be implemented. However, no RFC is available for this topic yet. Although no standard has been released until now, OpenStage phones already support server based call completion. An implementation according to the IETF BLISS draft is planned, but currently not available. This document provides best practice guidance on how call completion for Siemens OpenStage SIP phones can be implemented on any 3 rd party SIP based server presently on the market. Open Communications Principles and Best Practices 01/25/1010 I 2

3 Contents Executive Summary 2 Contents 3 Call Completion on OpenStage 4 CCBS/CCNR for the User 4 CCNR (Call Completion No Reply) 4 Server based Call Completion 5 CCBS (Call Back Busy Subscriber) 5 Server based Call Completion 6 Delete all Callbacks 6 CCBS/CCNR for the Administrator 7 Phone Configuration 7 Message Flows 8 CCNR (Call Completion No Reply) 8 CCBS (Call Completion Busy Subscriber) 9 Server based Call Completion 9 Delete all Callbacks 10 Beautifying the feature 10 Call Server Requirements 12 Open Communications Principles and Best Practices 01/25/1010 I 3

4 Call Completion on OpenStage CCBS/CCNR for the User This is an overview about a possible implementation of server based call completion. OpenStage phones support this feature out of the box. The server must be configured appropriately and provide the additional features (see Call Server Requirements). CCNR (Call Completion No Reply) User scenario CCNR 1. User invokes a call to user B (200). 2. Phone initiates the call. 3. B party (200) is ringing. Callback option is displayed to user A. 4. B party does not pick up the call, user A invokes callback feature. 5. Calls server plays announcement, informing user A that the callback feature has been activated. 6. Phone returns to idle status. Open Communications Principles and Best Practices 01/25/1010 I 4

5 Server Based Call Completion As soon as user B is available again, the server will initiate a call to user A. If user A accepts the callback, a call to user B is initiated automatically. CCBS (Completion of Calls to Busy Subscriber) User Scenario CCBS 1. User A invokes a call to user B (200). 2. Phone A initiates the call. 3. B party (200) is busy. Callback option is displayed to user A. 4. User A invokes callback feature. 5. Call server plays announcement, informing user A that the callback feature has been activated. 6. Phone A returns to idle status. Open Communications Principles and Best Practices 01/25/1010 I 5

6 Server Based Call Completion As soon as user B is available again, the server will initiate a call to user A. If user A accepts the callback, a call to user B is initiated automatically. Delete all Callbacks There are two possibilities to delete all callbacks: 1) Context menu in idle screen 2) Configure a Free Programmable Key (FPK) Open Communications Principles and Best Practices 01/25/1010 I 6

7 Remark: To add extra convenience, the OpenStage Server key feature can be used. This feature enables the server to control the LED associated with a key. By this means, the server can switch on the LED to indicate that callbacks are in the queue, or switch it off if there are none. CCBS/CCNR for the Administrator Phone Configuration For sending the appropriate feature code for a callback, the phone needs to be configured accordingly. The configuration page can be found at: Administrator Pages > System -> Features -> Services The relevant parameters are: a) Code for call back busy: Feature code to be sent when the called party is busy. b) Code for callback no reply: Feature code to be sent when the called party is not answering. The code can be identical to that in a). c) Code for callback cancel all: Feature code to be sent when the user wants to cancel all callbacks. Administration page with call back parameters Open Communications Principles and Best Practices 01/25/1010 I 7

8 Message Flows CCNR (Call Completion No Reply) No. from Scenario 2 Phone <-Message-> Server INVITE Message Request: INVITE sip:200@ : Ringing Status: 180 Ringing 4 CANCEL Request: CANCEL sip:200@ : Request Terminated Status: 487 Request Terminated ACK Request: ACK:sip:200@ :5060 INVITE Request: INVITE sip:*2@ : Session Progress 183 Session Progress 487 Request Terminated Status: 487 Request Terminated 6 ACK Request: ACK sip:*2@ : User invokes a call to user B (200). 2. Phone initiates the call. The phone starts a basic call to the server (INVITE). 3. B party is ringing. Callback option is displayed. Phone receives the ringing code (180). Callback function can be invoked at any time during the ringing phase. 4. B party does not pick up the call, user invokes callback function. The phone cancels the basic call (CANCEL/487/ACK) and sends the feature code to the server (INVITE). This INVITE request has no information about the unsuccessful call which should be used for the callback. Therefore, the server has to check its call history to find out which user must be monitored. 5. Call server plays announcement stating that the callback is initiated. To play the announcement, the server uses the early media mechanism (183). The user is informed whether his callback attempt was successful or not. 6. Phone returns to idle status. The server terminates the call after the announcement has been played (487/ACK), and the phone is returning to idle status. Open Communications Principles and Best Practices 01/25/1010 I 8

9 CCBS (Call Completion Busy Subscriber) No. from Scenario 2 Phone <-Message-> Server INVITE Server Request: INVITE sip:200@ : Busy Here Status: 486 Busy Here ACK Request: ACK:sip:200@ : INVITE Request: INVITE sip:*1@ : Session Progress 183 Session Progress 487 Request Terminated Status: 487 Request Terminated 6 ACK Request: ACK sip:*1@ : User invokes a call to user B (200). 2. Phone initiates the call. The phone starts a basic call to the server (INVITE). 3. B party (200) is busy. Callback option is displayed. 4. Phone receives the busy code (486). Callback function can be invoked at any time while the busy tone is played. 5. User invokes callback function. The phone sends the feature code to the server (INVITE). This INVITE request has no information about the call which should be used for the callback. Therefore, the server has to check its call history to find out which user must be monitored. 6. Call server plays announcement stating that the callback is initiated. To play the announcement, the server uses the early media mechanism (183). The user is informed whether his callback attempt was successful or not. 7. Phone returns to idle status. The server terminates the call after the announcement has been played (487/ACK) and the phone is returning to idle status. Server based Call Completion The server will initiate a call to the user when it has determined that the wanted party is available,. The SIP server is responsible for establishing the session between the devices and may use SIP 3PCC procedures to establish the session. Open Communications Principles and Best Practices 01/25/1010 I 9

10 Delete all Callbacks Phone <-Message-> Server INVITE Server Request: INVITE 183 Session Progress 183 Session Progress 487 Request Terminated Status: 487 Request Terminated ACK Request: ACK The phone sends the appropriate feature code to the server (INVITE). This code tells the server that all callbacks for this specific user must be cancelled. The server can play an announcement to the user to inform him about the success of the action. Remark: OpenStage phones do not make use of the reason phrase in the 487 response. A message included in the response will not be displayed on the OpenStage screen. Beautifying the feature There are several possibilities to add convenience to the feature. Two suggestions are described in the following. Delete all Callbacks with LED Control The administrator can use a server key for the delete all call backs feature. The LED could be used to show whether there are queued callback requests or not. With OpenStage 60/80 phones, the voice dial key could be used (firmware version V2R1 required). Add Information in the Voic Overview The voice message system could be used to show detailed information about outstanding callback requests to the user. If the urgent messages type is not used yet, the associated label can be renamed to display the number of outstanding callback requests. OpenStage SIP phones support unsolicited NOTIFY requests for voic updates. The server can send such NOTIFY requests at any time. Open Communications Principles and Best Practices 01/25/1010 I 10

11 Open Communications Principles and Best Practices 01/25/1010 I 11

12 Call Server Requirements The current OpenStage CCBS/CCNR support is server based. The phone does not support client based information management for call completion. Therefore the server must accomplish the following tasks: Recognize feature codes for the functions CCBS, CCNR and deletion of callback requests Play announcements about the status of the triggered features Monitor a user line to complete an open call via 3 rd party call control Trigger the LED for callback request deletion via dialog event package (optional) Open Communications Principles and Best Practices 01/25/1010 I 12

13 About Siemens Enterprise Communications: Siemens Enterprise Communications is a premier provider of end-to-end enterprise communications solutions that use open, standards-based architectures to unify communications and business applications for a seamless collaboration experience. This award-winning "Open Communications" approach enables organizations to improve productivity and reduce costs through easy-to-deploy solutions that work within existing IT environments, delivering operational efficiencies. It is the foundation for the company's OpenPath commitment that enables customers to mitigate risk and cost-effectively adopt unified communications. This promise is underwritten through our OpenScale service portfolio, which includes international, managed and outsource capability. Siemens Enterprise Communications is owned by a joint venture of The Gores Group and Siemens AG. The joint venture also encompasses Enterasys Networks, which provides network infrastructure and security systems, delivering a perfect basis for joint communications solutions. For more information about Siemens Enterprise Communications or Enterasys, please visit or Communication for the open minded Siemens Siemens Enterprise Enterprise Communications Communications Siemens Enterprise Communications GmbH & Co. KG Siemens Enterprise Communications GmbH & Co. KG is a Trademark Licensee of Siemens AG Hofmannstr Munich, Germany Status 04/2010 The information provided in this brochure contains merely general descriptions or characteristics of performance which in case of actual use do not always apply as described or which may change as a result of further development of the products. An obligation to provide the respective characteristics shall only exist if expressly agreed in the terms of contract. Availability and technical specifications are subject to change without notice. OpenScape, OpenStage and HiPath are registered trademarks of Siemens Enterprise Communications GmbH & Co. KG. All other company, brand, product and service names are trademarks or registered trademarks of their respective holders. Printed in Germany.