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

E T S I

European Telecommunications Standards Institute http://portal.etsi.org

T I S P A N

NGN standardisation group in ETSIhttp://portal.etsi.org/tispan/TISPAN_ToR.asp

I S D N

Integrated Services Digital Network

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)

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

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.

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.

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 identityP-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

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

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.

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 ???

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 packagein the SUBSCRIBE request.

Example: Event: dialog;queue=suspendEvent: dialog;queue=resume

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

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.

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 requesta2) origin identity in the NOTIFY request

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

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 headerc) use of SAML framework