1. call completion services
ETSI TISPAN
call completion services
(draft-poetzl-sipping-call-completion-00)
Roland Jesske
Martin Huelsemann
July 13, 2006
SIPPING WG IETF 66

2. European Telecommunications Standards Institute
E T S I
European Telecommunications Standards Institute
T I S P A N
NGN standardisation group in ETSI
July 13, 2006
SIPPING WG IETF 66

3. Communication Completion on Busy Subscriber (CCBS)
Services in scope:
Communication Completion on Busy Subscriber (CCBS)
Communication Completion on no Reply (CCNR)
July 13, 2006
SIPPING WG IETF 66

4. draft-jesske-sipping-tispan-requirements-03
I-Ds related:
draft-jesske-sipping-tispan-requirements-03
draft-poetzl-sipping-call-completion-00
July 13, 2006
SIPPING WG IETF 66

5. Call completion service on queue basis - uncoordinated call completion services might lead to the situation where the first user activating call completion might be the last user who’s call is completed - a sequential organised (FIFO) call completion service on a busy user can be realised by a network element capable to queue call completion requests - the first user who requests call completion is the first user who is informed that a call completion call is possible now - call completion calls have a higher priority than normal calls
July 13, 2006
SIPPING WG IETF 66

6. General framework: - solutions should be based on existing SIP means (BCP) - solutions should be simple - solutions must be interoperable with existing PSTN call completion services
July 13, 2006
SIPPING WG IETF 66

7. Open issues for call completion services: - Indication that a subscription to a call completion queue is possible - Capability of management of call completion queues - Prioritisation of call completion calls
July 13, 2006
SIPPING WG IETF 66

8. Issue 1 Indication that a UA or application server on the terminating side is able to add requests from the originating side to a call completion queue. Proposed solution: Usage of the Allow-Events header in 486 Busy responses for CCBS and in 180 Ringing responses for CCNR.
July 13, 2006
SIPPING WG IETF 66

9. Issue 2 Management of call completion queues between network elements
Issue 2 Management of call completion queues between network elements. The queuing capability can be implemented in UAs as well as in application servers. After being added a user shall be able to suspend, resume or cancel his position in the call completion queue. Existing SIP means do not fulfil this requirement, e.g. the dialog event package informs about status of a dialog, needed is information about the status of a queue (‘dialog terminated’ unequal ‘ready for recall’) Proposed solution: Usage of SUBSCRIBE/NOTIFY to subscribe to and manage a call completion queue and to receive notifications of changes in the status of the queue. Specification of two new event packages (CCBS and CCNR).
July 13, 2006
SIPPING WG IETF 66

10. Issue 3 Prioritisation of call completion calls
Issue 3 Prioritisation of call completion calls. Call completion calls must be distinguishable from new incoming calls in order to avoid queuing or blocking at the terminating side. Proposed solution: Definition of a private header which can transport a specific call completion indication: P-Service-Indication header
July 13, 2006
SIPPING WG IETF 66

11. July 13, 2006
SIPPING WG IETF 66

12. To do: adding of explanatory text and signalling flows
To do: adding of explanatory text and signalling flows. Needed: reviewing, comments and discussion.
July 13, 2006
SIPPING WG IETF 66

13. Backup
July 13, 2006
SIPPING WG IETF 66

14. July 13, 2006
SIPPING WG IETF 66

15. Call completion event package Defines several event header parameters, amongst others: - queue-operation (add, suspend, resume) - queue-state (request-queued, user-free-for-recall) - cancellation-reason (service-duration [max. time for service activation expired], CCSS-completed) - denial-reason (short-term-denial [e.g. max. number of requests queued], long-term-denial) - caller [uniquely identifies the user who has originated the call completion subscription]
July 13, 2006
SIPPING WG IETF 66

16. P-Service-Indication header - may be used by network elements in certain deployment scenarios to request a special processing of their SIP requests or responses - a UAC may include one or more P-Service-Indication header fields in a request - a UAS receiving a request including a P-Service-Indication header field may inspect it in order to apply service-specific features; a UAS may include one or more P-Service-Indication header fields in a response - a proxy receiving a request including a P-Service-Indication header filed may inspect it in order to process the message accordingly; a proxy may add or remove P-Service-Indication header fields
July 13, 2006
SIPPING WG IETF 66