White Paper Mapping of Signalling Protocols ISUP To/From SIP, SIP-I

White Paper Mapping of Signalling Protocols ISUP To/From SIP, SIP-I

INTERNATIONAL INTERCONNECTION FORUM FOR SERVICES OVER IP (i3 FORUM) Workstream “Technical Aspects” White Paper Mapping of Signalling Protocols ISUP to/from SIP, SIP-I (Release 3) May 2011 “White Paper – Mapping of signalling protocols: from ISUP to SIP, SIP-I” Release 3, May 2011 1 i3 Forum Proprietary Document Executive Summary Mapping between ISUP and SIP, or ISUP and SIP-I, is a complex area with regard to disconnect cause values and this needs to be considered to ensure optimum behaviour for session control. The most straightforward case is ISUP to SIP-I in accordance with specification ITU Q1912.5, Annex C Profile C. Since the ISUP message is encapsulated within the SIP message, correct conveyance of the ISUP information is guaranteed in most circumstances. However, when ISUP has to be mapped into SIP there are a number of standards that differ and this has led to different vendor implementations. A further level of complication exists when multiple conversions (i.e. signalling protocol interworking) take place in the International Carrier domain. The level of end-to-end signalling transparency achieved depends on the compatibility of the two (or more) mapping activities. The more divergent these are the less signalling transparency occurs. In addition, these mapping inconsistencies can also adversely affect the quality KPIs that are generated in the Carrier and/or Service Provider network, leading to differences in values reported by the parties involved in transporting the call. This can in turn result in difficulties in identifying the root cause of an issue and, potentially worse, applying incorrect call routing management. This behaviour can affect whether SLAs have been met or not by a particular party. The objective of this document is twofold. On the one hand, it aims to outline to the carrier industry that inconsistencies do exist under some conditions and may lead to undesired network behaviour. On the other hand, on the basis of the joint activity carried out by 3GPP and i3 Forum in late 2010 / early 2011, it identifies actions Carriers need to take to limit these complexities and ambiguities when implementing new SIP or SIP-I interconnections. Specifically, it is advised to implement the new mapping specified by 3GPP TS29.163 Release 7.22.0 [5], or any other Release distributed after March 2011 that incorporates this new mapping. “White Paper – Mapping of signalling protocols: from ISUP to SIP, SIP-I” Release 3, May 2011 2 i3 Forum Proprietary Document Table of Contents Executive Summary .......................................................................................................................................................2 1 Scope and Objective ..................................................................................................................................4 2 Acronyms....................................................................................................................................................4 3 References .................................................................................................................................................4 4 Reference Configuration.............................................................................................................................6 5 Applicable International standards .............................................................................................................6 6 Interworking between ISUP-SIP and between ISUP- SIP-I........................................................................7 7 Message mappings between ISUP – SIP and between ISUP –SIP-I.........................................................8 8 Parameter Mappings between ISUP-SIP and between ISUP- SIP-I ..........................................................8 8.1 Considerations on ISUP, SIP interworking.............................................................................. 8 8.2 Considerations on ISUP, SIP-I interworking ........................................................................... 8 9 Disconnect Cause Value Mappings between ISUP-SIP and between ISUP- SIP-I ...................................9 9.1 Desired Behaviours in a Disconnect Cause Value to Response Code Mapping.................... 9 9.1.1 Mapping Granularity ............................................................................................................. 9 9.1.2 Mapping Stability .................................................................................................................. 9 9.1.3 Symmetric Mappings ............................................................................................................ 9 9.1.4 Quality KPI preservation....................................................................................................... 9 9.2 ISUP – SIP Interworking Issues .............................................................................................. 9 9.2.1 Inconsistencies within a given Standard Mapping................................................................ 9 9.2.2 Inconsistencies across different Standard Mappings ........................................................... 10 9.2.3 Disadvantages of the Current Mapping Schemes ................................................................ 10 9.3 ISUP – SIP Interworking with Reason Header Support .......................................................... 11 9.3.1 Optional Inclusion or Interpretation of the Reason Header .................................................. 11 9.3.2 Loss of Location Information ................................................................................................ 11 9.3.3 IETF Draft regarding Reason in Responses......................................................................... 12 9.4 ISUP – SIP-I Interworking ....................................................................................................... 12 10 Resolving Disconnect Cause Value Inconsistencies..................................................................................12 11 Recommendations to involved parties........................................................................................................13 12 ANNEX A - Mapping from ISUP messages to SIP messages....................................................................14 13 ANNEX B - Mapping from SIP Response Codes to ISUP Disconnect Cause Values................................15 14 ANNEX C - Mapping from ISUP Disconnect Cause Values to SIP Response Codes ...............................17 15 ANNEX D - Mapping delta between ITU-T Q1912.5 and 3GPP TS.29.163 and subsidiary documents. ...20 16 ANNEX E – Examples of issues with ISUP – SIP-I interworking................................................................21 “White Paper – Mapping of signalling protocols: from ISUP to SIP, SIP-I” Release 3, May 2011 3 i3 Forum Proprietary Document 1 Scope and Objective This document addresses signalling interworking issues when converting from TDM to IP. These issues exist when inter-operating between legacy ISUP networks and next-generation VoIP networks using SIP-based protocols. Mapping between ISUP and SIP, or ISUP and SIP-I, is a complex area with regard to disconnect cause values and this needs to be considered to ensure optimum behaviour for session control and quality KPI reporting. The objective of this document is twofold. On the one hand, it aims to outline to the carrier industry that inconsistencies do exist under some conditions and may lead to undesired network behaviour. On the other hand, on the basis of the joint activity carried out by 3GPP and i3 Forum in late 2010 / early 2011, it identifies actions that carriers need to take to limit these complexities and ambiguities when implementing new SIP or SIP-I interconnections. Specifically, it is advised to implement the new mapping specified by 3GPP TS29.163 Release 7.22.0 [5], or any other Release distributed after March 2011 that incorporates this new mapping. The content of this white paper complements the i3 Forum document “Technical Interconnection model for International Voice Services”, [1]. 2 Acronyms 3GPP: 3rd Generation Partnership Program ABR Answer to Bid Ratio ASR Answer Seizure Ratio CDR Call Detail Record IETF Internet Engineering Task Force ISDN Integrated Services Digital Network ISUP ISDN User Part ITU International Telecommunication Union KPI Key Performance Indicator NER Network Effictiveness Ratio NNI Network to Network Interface RFC Request for Comments SIP Session Initiation Protocol SIP-I SIP with encapsulated ISUP TDM Time Division Multiplexing 3 References [1] i3 Forum, “Technical Interconnection Model for International Voice Services”, Release 4.0, May 2011 [2] IETF RFC 3261 “SIP: Session Initiation Protocol”, June 2002 [3] ITU-T Recommendation Q1912.5 “Interworking between Session Initiation Protocol and Bearer Independent Call Control or ISDN User Part”, 2004 [4] IETF RFC 3398 – “ISUP to SIP Mapping”, December 2002 [5] 3GPP TS 29.163 “Interworking between IP multimedia network and circuit switched networks” Release 7.22.0, Kansas City, March 2011 [6] 3GPP TS 29.163 “Interworking between IP multimedia network and circuit switched networks” Release 7.21.0, and all versions prior to March 2011. [7] ITU-T Recommendation Q.850 “Usage of codes and location in the digital subscriber Signalling System No. 1 and the Signalling System No. 7 ISDN User Part”, May 1998; [8] IETF RFC 3326 “The Reason Header Field for the Session Initiation Protocol (SIP)”,

View Full Text

Details

  • File Type
    pdf
  • Upload Time
    -
  • Content Languages
    English
  • Upload User
    Anonymous/Not logged-in
  • File Pages
    22 Page
  • File Size
    -

Download

Channel Download Status
Express Download Enable

Copyright

We respect the copyrights and intellectual property rights of all users. All uploaded documents are either original works of the uploader or authorized works of the rightful owners.

  • Not to be reproduced or distributed without explicit permission.
  • Not used for commercial purposes outside of approved use cases.
  • Not used to infringe on the rights of the original creators.
  • If you believe any content infringes your copyright, please contact us immediately.

Support

For help with questions, suggestions, or problems, please contact us