ETSI TISPAN ISDN simulation services Roland Jesske r.jesske@t-com

1. 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 SIPPING WG IETF 63

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

3. 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) SIPPING WG IETF 63

4. 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 SIPPING WG IETF 63

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

6. 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 user’s 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. SIPPING WG IETF 63

7. Terminating Indication Presentation (TIP)Issue 1 Called party needs to provide any given identity to the calling partyCurrent situation:Forward direction: From: Calling party given identity P-Asserted-Id Network asserted calling party identityBackward 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 SIPPING WG IETF 63

8. Advice of Charge (AoC)Issue 1Request 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-00Issue 2 Transfer of the AoC InformationPossible solutions:a) new MIME body with AoC Information SIPPING WG IETF 63

9. Communication Completion on Busy Subscriber (CCBS)/(CCNR)Issue 1Indication 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. SIPPING WG IETF 63

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

11. Communication Completion on Busy Subscriber (CCBS)Issue 3Management 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 Solutionsa) Add a new parameter to the “dialog” event packagein the SUBSCRIBE request.Example: Event: dialog;queue=suspendEvent: dialog;queue=resume SIPPING WG IETF 63

12. Communication Completion on Busy Subscriber (CCBS) Issue 4Indication about sequential notification policy to allow queue management from the subscribers.Possible Solutionsa) Add a new parameter to the “dialog” event package in the NOTIFY requestExample:Event: dialog;queue=true SIPPING WG IETF 63

13. Malicious Communication Identification (MCID) Issue 1How 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. SIPPING WG IETF 63

14. Malicious Communication Identification (MCID) Issue 2Request 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 SIPPING WG IETF 63

15. Communication Diversion (CDIV)IssueTransfer 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-02b) 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 SIPPING WG IETF 63

16. Calling Party CategoryIssueGroup 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 inP-Asserted-Id headerb) new P-Caller-Category headerc) use of SAML framework SIPPING WG IETF 63