ETSI TISPAN ISDN simulation services
Download
1 / 16

ETSI TISPAN ISDN simulation services Roland Jesske [email protected] - PowerPoint PPT Presentation


  • 78 Views
  • Uploaded on

ETSI TISPAN ISDN simulation services Roland Jesske [email protected] Denis Alexeitsev [email protected] Miguel Garcia-Martin [email protected] E T S I European Telecommunications Standards Institute http://portal.etsi.org T I S P A N

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about ' ETSI TISPAN ISDN simulation services Roland Jesske [email protected]' - tess


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript

ETSI TISPAN ISDN simulation services

Roland Jesske [email protected]

Denis Alexeitsev [email protected]

Miguel Garcia-Martin [email protected]

SIPPING 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

SIPPING 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)

SIPPING 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

SIPPING WG IETF 63


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


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


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


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


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


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


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


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


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


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


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


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


ad