1. July 13, 2006SIPPING WG IETF 66Slide # 1 ETSI TISPAN call completion services (draft-poetzl-sipping-call-completion-00) Roland Jessker.jesske@t-com.net Martin Huelsemannmartin.huelsemann@t-com.net

2. July 13, 2006SIPPING WG IETF 66Slide # 2 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

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

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

5. July 13, 2006SIPPING WG IETF 66Slide # 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

6. July 13, 2006SIPPING WG IETF 66Slide # 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

7. July 13, 2006SIPPING WG IETF 66Slide # 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

8. July 13, 2006SIPPING WG IETF 66Slide # 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.

9. July 13, 2006SIPPING WG IETF 66Slide # 9 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).

10. July 13, 2006SIPPING WG IETF 66Slide # 10 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

11. July 13, 2006SIPPING WG IETF 66Slide # 11

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

13. July 13, 2006SIPPING WG IETF 66Slide # 13 Backup

14. July 13, 2006SIPPING WG IETF 66Slide # 14

15. July 13, 2006SIPPING WG IETF 66Slide # 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]

16. July 13, 2006SIPPING WG IETF 66Slide # 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