call completion services ETSI TISPAN call completion services (draft-poetzl-sipping-call-completion-00) Roland Jesske r.jesske@t-com.net Martin Huelsemann martin.huelsemann@t-com.net July 13, 2006 SIPPING WG IETF 66

European Telecommunications Standards Institute E T S I European Telecommunications Standards Institute http://portal.etsi.org T I S P A N NGN standardisation group in ETSI http://portal.etsi.org/tispan/TISPAN_ToR.asp July 13, 2006 SIPPING WG IETF 66

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

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

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

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

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

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

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

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

July 13, 2006 SIPPING WG IETF 66

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

Backup July 13, 2006 SIPPING WG IETF 66

July 13, 2006 SIPPING WG IETF 66

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

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