1. August 2, 2005SIPPING WG IETF 63 ETSI TISPAN ISDN simulation services Roland Jesske r.jesske@t-com.net Denis Alexeitsev d.alexeitsev@t-com.net Miguel Garcia-Martin miguel.an.garcia@nokia.com

2. August 2, 2005SIPPING WG IETF 63 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 I S D N Integrated Services Digital Network

3. August 2, 2005SIPPING WG IETF 63 Services in scope: Anonymous Communication Rejection (ACR) Terminating Indication Presentation (TIP) Advice of Charge (AoC) Communication Completion on Busy Subscriber (CCBS) Communication Completion on no Reply (CCNR) Malicious Communication Identification (MCID) Communication Diversion (CDIV)

4. August 2, 2005SIPPING WG IETF 63 I-Ds in scope: draft-jesske-sipping-tispan-requirements-01 draft-jesske-sipping-tispan-analysis-00 draft-jesske-sipping-etsi-ngn-reason-00 Relevant I-Ds: draft-garcia-sipping-etsi-ngn-p-headers-00 draft-elwell-sipping-redirection-reason-02

5. August 2, 2005SIPPING WG IETF 63 Anonymous Communication Rejection (ACR) Issue 1 Transfer of service specific session or transaction termination reasons. Possible solutions: a) allow Reason: header in unsuccessful responses - draft-jesske-sipping-etsi-ngn-reason-00.txt b) extend warn-codes in the Warning: header with additional application specific termination reasons.

6. August 2, 2005SIPPING WG IETF 63 Anonymous Communication Rejection (ACR) Issue 2 Override of user restrictions: Various authorities (police, security agencies, … ) require service providers to ignore restrictions on anonymous call acceptance for their calls. Possible solution: a) use of specific P-Header inside of the trusted domain to explicitly request the override of the users restrictions on the acceptance of anonymous calls. b) use the some sort of source information (URI, …) to automatically assume a request to override restrictions. Such assumption may not always be correct.

7. August 2, 2005SIPPING WG IETF 63 Terminating Indication Presentation (TIP) Issue 1 Called party needs to provide any given identity to the calling party Current situation: Forward direction: From:Calling party given identity P-Asserted-Id Network asserted calling party identity Backward direction: ??? P-Asserted-Id Network asserted called party identity Possible solution: a) Reply-To header. Can only be used in requests. b) Call-Info header with a new value for the purpose parameter

8. August 2, 2005SIPPING WG IETF 63 Advice of Charge (AoC) Issue 1 Request for AoC information inside of the INVITE dialog. AoC service is invoked during an active session. Possible solutions: a) use of new P-AoC header as described in draft-garcia-sipping-etsi-ngn- p-headers-00 Issue 2 Transfer of the AoC Information Possible solutions: a) new MIME body with AoC Information

9. August 2, 2005SIPPING WG IETF 63 Communication Completion on Busy Subscriber (CCBS)/(CCNR) Issue 1 Indication of the support for dialog event package from the target to the origin in responses (486 Busy, 180 Ringing, …). Possible solution: a) extend the event notification framework to include Allow-Events: header in 486 response.

10. August 2, 2005SIPPING WG IETF 63 Communication Completion on Busy Subscriber (CCBS) Issue 2 Sequential notification of dialog event package state changes. Think about it as something like reverse sequential forking Notifications about a change in a dialog state to multiple subscribers are needed to be performed in sequence. Earlier subscription will get the notification first - FIFO Possible Solutions a) any protocol impact ???

11. August 2, 2005SIPPING WG IETF 63 Communication Completion on Busy Subscriber (CCBS) Issue 3 Management of the notification queue for sequential notifications. A subscriber should be able to suspend and resume his position in queue. While in the suspend state a subscriber will not get a notification about a change in the dialog event package state, but the next subscriber in the queue. Possible Solutions a) Add a new parameter to the dialog event package in the SUBSCRIBE request. Example: Event: dialog;queue=suspend Event: dialog;queue=resume

12. August 2, 2005SIPPING WG IETF 63 Communication Completion on Busy Subscriber (CCBS) Issue 4 Indication about sequential notification policy to allow queue management from the subscribers. Possible Solutions a) Add a new parameter to the dialog event package in the NOTIFY request Example: Event: dialog;queue=true

13. August 2, 2005SIPPING WG IETF 63 Malicious Communication Identification (MCID) Issue 1 How to provide an indication of the malicious sessions from the UA to the network. The logging of the call information is independent of the origin presentation restrictions. The logged information will not be provided to the callee, but to the legal authorities. Possible solutions: a) Define a new event package to trigger the logging. The event package subscription will be performed as a fetch operation.

14. August 2, 2005SIPPING WG IETF 63 Malicious Communication Identification (MCID) Issue 2 Request origin identity from the previous domain if not available at the time of the MCID indication receipt. Possible solutions: a) define a new or extend an existing event package to transport: a1) dialog id information in the SUBSCRIBE request a2) origin identity in the NOTIFY request

15. August 2, 2005SIPPING WG IETF 63 Communication Diversion (CDIV) Issue Transfer of the session origin information to the target after diversions, including diversion reasons. Possible solutions: a) use of draft-ietf-sip-history-info-06 with draft-elwell-sipping-redirection- reason-02 b) use of draft-ietf-sip-history-info-06 with reasons from draft-jennings-sip- voicemail-uri-04. Alignment is needed to express correct redirection reasons and to cover all scenarios described within draft-elwell-sipping-redirection-reason-02

16. August 2, 2005SIPPING WG IETF 63 Calling Party Category Issue Group users to different categories. Service providers need to identify different subscriber groups to provide specific regulatory services (prison, police, …) or business services (payphone, hotel, …). The services can include specific call routing, preemption, restriction/override procedures, … Possible solutions: a) use of draft-mahy-iptel-cpc-02.txt tel URI cpc parameter in P-Asserted- Id header b) new P-Caller-Category header c) use of SAML framework