* Your assessment is very important for improving the workof artificial intelligence, which forms the content of this project
Download V1.0.0 vom 15.10.2014
Survey
Document related concepts
Extensible Authentication Protocol wikipedia , lookup
Deep packet inspection wikipedia , lookup
Piggybacking (Internet access) wikipedia , lookup
Computer network wikipedia , lookup
Airborne Networking wikipedia , lookup
Cracking of wireless networks wikipedia , lookup
Internet protocol suite wikipedia , lookup
Recursive InterNetwork Architecture (RINA) wikipedia , lookup
Serial digital interface wikipedia , lookup
List of wireless community networks by region wikipedia , lookup
Zero-configuration networking wikipedia , lookup
SIP extensions for the IP Multimedia Subsystem wikipedia , lookup
Transcript
Unterarbeitskreis Signalisierung Specification of the NGN-Interconnection Interface Ausgabestand: V1.0.0 vom 15.10.2014 Verabschiedet in der 150. Tagung des AKNN am 14.10.2014 Herausgegeben vom Arbeitskreis für technische und betriebliche Fragen der Nummerierung und Netzzusammenschaltung (AKNN) Erarbeitet vom Unterarbeitskreis Signalisierung (UAK-S) Editor: Stefan Krämer DB Netz AG UAK-S: NGN Ic Interface Ausgabestand: V1.0.0 vom 15.10.2014 E-Mail: [email protected] Seite 1 von 98 Spec_UAKS_NGN_Ic_Interface_V1_0_0.docx 0 Content 0 Content ..................................................................................................................................... 2 1 History ....................................................................................................................................... 6 2 Foreword ................................................................................................................................... 7 3 Scope........................................................................................................................................ 7 4 References ............................................................................................................................... 8 4.1 References (normative) ...................................................................................................................... 8 4.1.1 Basic References ....................................................................................................................... 8 4.1.1.1 Architecture ....................................................................................................................... 8 4.1.1.2 Protocols ........................................................................................................................... 8 4.1.1.3 Numbering and Addressing .............................................................................................. 9 4.1.1.4 Simulation Services........................................................................................................... 9 4.1.1.5 Emulation Services ......................................................................................................... 10 4.1.1.6 Emergency Calls ............................................................................................................. 11 4.2 References (informative) .................................................................................................................. 11 4.2.1 Architecture .............................................................................................................................. 12 4.3 National References ......................................................................................................................... 12 5 Definitions and Abbreviations ................................................................................................. 13 5.1 Definitions..................................................................................................................................... 13 5.1.1 Nature of SIP ........................................................................................................................... 13 5.1.1.1 SIP................................................................................................................................... 13 5.1.1.2 IC-SIP(m) ........................................................................................................................ 13 5.1.1.3 IC-SIP(o) ......................................................................................................................... 13 5.1.1.4 SIP(n/a) ........................................................................................................................... 14 5.1.2 Reference Points of Interfaces ................................................................................................ 14 5.1.3 Trust Domain and Topology Hiding ......................................................................................... 14 5.1.4 P-Asserted-Identity .................................................................................................................. 14 5.2 Abbreviations ............................................................................................................................... 14 6 Architecture............................................................................................................................. 14 6.1 6.2 7 Ic-Interface ................................................................................................................................... 15 Iz-Interface ................................................................................................................................... 15 Numbering and Addressing at the Ic-Interface ....................................................................... 16 7.1 Format of SIP URIs .......................................................................................................................... 16 7.1.1 Global Number Format ............................................................................................................ 16 7.1.2 SIP Request URI ..................................................................................................................... 16 7.1.2.1 Number Portability ...................................................................................................... 16 7.1.2.2 Emergency Calls (Notruf) ........................................................................................... 17 7.1.2.2.1 PSAP in PSTN Technology ....................................................................................... 17 7.1.2.2.2 PSAP in NGN Technology ......................................................................................... 17 7.1.2.3 Harmonised Numbers for Harmonised Services of Social Value (Harmonisierte Dienste von sozialem Wert) ......................................................................................................... 18 7.1.2.4 Authority Bureau Call (Einheitlicher Behördenruf) ...................................................... 18 7.1.2.5 Directory Enquiries (Auskunft) .................................................................................... 19 7.1.2.6 Tollfree Callback Service for Directory Enquiries (Entgeltfreie Rückrufnummer für Vermittlungsdienste) .................................................................................................................... 19 7.1.2.7 International Freephone Services ............................................................................... 19 7.1.2.8 International Service Numbers ................................................................................... 19 7.1.2.9 Test numbers for Carrier Selection Calls.................................................................... 20 7.1.3 P-Asserted-Identity Header Field............................................................................................. 20 7.1.4 From Header Field ................................................................................................................... 20 7.1.5 To Header Field ....................................................................................................................... 20 7.1.6 History-Info Header Field ......................................................................................................... 20 7.2 Routing of SIP Requests .................................................................................................................. 20 7.2.1 Scenario 1: Termination........................................................................................................... 21 7.2.2 Scenario 2a: Determination of the Destination Network is not possible in the A-Domain ....... 22 UAK-S: NGN Ic Interface Ausgabestand: V1.0.0 vom 15.10.2014 Seite 2 von 98 Spec_UAKS_NGN_Ic_Interface_V1_0_0.docx 7.2.3 Scenario 2b: Determination of the Destination Network is possible in the A-Domain, but there is no Traffic Relation to the Destination Domain ................................................................................... 23 7.3 Charged / Non Charged Telephone Traffic ...................................................................................... 24 7.4 Mobile Service Prefix (Mobilfunkservicevorwahl) ............................................................................. 24 7.4.1 Introduction .............................................................................................................................. 24 7.4.2 Definition .................................................................................................................................. 24 7.4.3 Transmission............................................................................................................................ 24 7.5 Service Calls handed over from International Carriers .................................................................... 25 8 Ic-Profile Endorsement for ETSI TISPAN TS 124 503 ........................................................... 26 8.1 8.2 8.3 8.4 8.4.1 8.4.2 8.4.3 8.4.4 9 Global Modifications ..................................................................................................................... 26 Modifications ETSI TS 124 503 V8.3.0 ........................................................................................ 26 Modifications to 3GPP TS 24.229 ................................................................................................ 29 Profiling of ETSI TS 124 503 / 3GPP TS 24.229 ANNEX A ........................................................ 41 Supported Methods on the Ic-Interface ................................................................................... 41 Supported Status-Codes on the Ic-Interface ........................................................................... 42 Support of SIP Header on the Ic-Interface .............................................................................. 45 Supported SDP Types ............................................................................................................. 48 Simulation Services Supported for NGN-Voice-Interconnection ............................................ 51 9.1 Supported Services on the Interconnection Interface ...................................................................... 51 9.2 Description of Services ..................................................................................................................... 52 9.2.1 CDIV ........................................................................................................................................ 52 9.2.2 OIP/OIR ................................................................................................................................... 52 9.2.3 TIP/TIR..................................................................................................................................... 52 9.2.4 HOLD ....................................................................................................................................... 52 9.2.5 ACR&CB .................................................................................................................................. 52 9.2.6 ECT .......................................................................................................................................... 52 9.2.7 CONF ....................................................................................................................................... 52 9.2.8 CUG ......................................................................................................................................... 52 9.2.9 MWI.......................................................................................................................................... 52 9.2.10 MCID ........................................................................................................................................ 52 9.2.11 Call Completion........................................................................................................................ 52 9.2.12 CW ........................................................................................................................................... 53 9.2.13 UUS ......................................................................................................................................... 53 9.2.14 Emergency Calls (Notruf) ........................................................................................................ 53 10 Bearer Aspects .................................................................................................................. 54 10.1 Bearer Services ............................................................................................................................ 54 10.2 Bearer Control .............................................................................................................................. 54 10.2.1 Through Connection of the Media Path (speech/data transmission) ...................................... 54 10.2.1.1 General Remarks ........................................................................................................ 54 10.2.1.2 Scenarios described ................................................................................................... 55 10.2.1.2.1 Remarks and Symbols used .................................................................................... 55 10.2.1.2.2 Scenario 1: Connection Set-up to User Equipment B, which is Not Trusted concerning Early Media................................................................................................................ 56 10.2.1.2.3 Scenario 2: Connection Set-up to User Equipment B, which is Trusted concerning Early Media ................................................................................................................................. 57 10.2.1.2.4 Scenario 3: Connection Set-up with Tones/Announcements from the Transit-/ Destination Network ..................................................................................................................... 58 10.2.1.2.5 Scenario 4: Originator has an Early Media Dialogue with an IVR in the Transit-/ Destination Network ..................................................................................................................... 59 10.2.1.3 Description of the Procedures .................................................................................... 59 10.2.1.3.1 Actions required at the Origination Network ............................................................ 60 10.2.1.3.2 Actions required at an Intermediate National Network (Transit) .............................. 61 10.2.1.3.3 Actions required at the Termination Network........................................................... 63 10.2.1.3.4 Overview of the Media Handling in the Relevant Network Types ............................ 65 10.2.2 MIME Type Handling ............................................................................................................... 66 10.3 Tones and Announcements ......................................................................................................... 67 10.3.1 Actions required at the Origination Network ............................................................................ 67 10.3.2 Actions required at an Intermediate National Network (Transit).............................................. 67 10.3.3 Actions required at the Terminating Network .......................................................................... 67 UAK-S: NGN Ic Interface Ausgabestand: V1.0.0 vom 15.10.2014 Seite 3 von 98 Spec_UAKS_NGN_Ic_Interface_V1_0_0.docx 10.3.4 Media Clipping ......................................................................................................................... 67 10.4 Codecs ......................................................................................................................................... 67 10.5 IP Version, IP Header Interworking and Fragmentation .............................................................. 67 11 Forward Address Signalling............................................................................................... 68 11.1 11.2 11.3 12 Variant 1: En Bloc Forward Address Signalling only ................................................................... 68 Variant 2: Multiple Invite Method in Combination with En Bloc Forward Address Signalling ...... 68 Remarks about the Usage of both Variants in Interconnection Scenarios .................................. 68 Charging Aspects .............................................................................................................. 70 12.1 12.2 12.3 Begin of Charging ........................................................................................................................ 70 End of Charging ........................................................................................................................... 70 SIP Support of Charging .............................................................................................................. 70 13 Roaming ............................................................................................................................ 70 14 Emergency Calls ............................................................................................................... 70 14.1 Requirements for Emergency Calls ............................................................................................. 70 14.2 Number Format ............................................................................................................................ 71 14.3 Transmission of Additional Information ........................................................................................ 71 14.3.1 SIP UUI Header Field .............................................................................................................. 71 14.3.1.1 General ....................................................................................................................... 72 14.3.1.2 Civic Location ............................................................................................................. 72 14.3.1.3 Geographic Location................................................................................................... 73 14.3.2 SIP Geolocation Header Field ................................................................................................. 73 14.3.2.1 General ....................................................................................................................... 73 14.3.2.2 Civic Location ............................................................................................................. 74 14.3.2.3 Geographic Location................................................................................................... 75 14.3.2.3.1 Point ......................................................................................................................... 75 14.3.2.3.2 Ellipse ....................................................................................................................... 76 14.3.2.3.3 Polygon .................................................................................................................... 77 14.3.2.3.4 Arc Band .................................................................................................................. 78 14.3.2.3.5 Description of radio cell ............................................................................................ 80 14.3.2.3.6 Mobile Radio Cell identification ................................................................................ 80 14.3.2.3.7 Confidence ............................................................................................................... 81 14.4 Exemplary Encoding ................................................................................................................ 81 14.4.1 Civic Location........................................................................................................................... 81 14.4.2 Ellipsoid Arc/Arc Band ............................................................................................................. 83 14.5 Emergency Calls for Voice Service Provider ........................................................................... 85 Annex A A.1 A.2 Address Formats (informative) .................................................................................. 86 Number Portability........................................................................................................................ 86 Emergency Calls .......................................................................................................................... 86 Annex B SIP/SDP MIME Type Signalling on the Ic-Interface (informative) .............................. 87 Annex C Forward Address Signalling (informative) .................................................................. 90 C.1 General......................................................................................................................................... 90 C.2 Overlap Signalling Methods ......................................................................................................... 90 C.2.1 In-dialogue Method .................................................................................................................. 90 C.2.2 Multiple-INVITE Method........................................................................................................... 90 C.2.2.1 General ........................................................................................................................... 90 C.3 Routing Impacts ........................................................................................................................... 90 C.3.1 General .................................................................................................................................... 90 C.3.2 Deterministic Routing ............................................................................................................... 90 C.3.3 Digit Collection ......................................................................................................................... 90 Annex D Calling Party’s Category (normative) ......................................................................... 92 Annex E Nationally Ported International Service Numbers (informative) ................................. 94 Annex F Abbreviations and Terms ........................................................................................... 95 F.1 F.2 Abbreviations .................................................................................................................................... 95 Terms................................................................................................................................................ 97 UAK-S: NGN Ic Interface Ausgabestand: V1.0.0 vom 15.10.2014 Seite 4 von 98 Spec_UAKS_NGN_Ic_Interface_V1_0_0.docx Annex G Das Mandat des UAK Signalisierung (informative).................................................... 98 UAK-S: NGN Ic Interface Ausgabestand: V1.0.0 vom 15.10.2014 Seite 5 von 98 Spec_UAKS_NGN_Ic_Interface_V1_0_0.docx 1 History Version 0.0.1 Date 10.03.2008 0.0.1 0.0.1 16.04.2008 19.05.2008 0.0.2 0.0.3 05.06.2008 04.08.2008 0.0.4 0.0.5 0.0.6 16.09.2008 21.10.2008 16.03.2009 0.0.7 0.0.8 0.0.9 24.08.2009 09.12.2009 26.03.2010 0.0.10 0.0.11 20.04.2010 19.08.2010 0.0.12 10.01.2011 0.0.13 22.02.2011 0.0.14 06.09.2011 0.0.15 20.10.2011 0.0.16 20.02.2012 0.0.17 0.0.18 22.03.2012 15.05.2012 0.0.19 16.08.2012 0.1.0 31.12.2012 0.1.1 05.02.2014 0.1.2 26.02.2014 0.1.3 0.1.4 0.2.0 1.0.0 07.05.2014 26.08.2014 27.08.2014 15.10.2014 Comments First version based on the T-Com (TE33) Technische Richtlinie 163TR 25 (Draft), Version 1.0.2 / 10th September 2007 89. UAK-S: Mandatory SDP lines marked yellow in chapter 8.2.5 Results of the 90. UAK-S worked in: - working document WD-90-1 added as informative annex B - changes in chapter 4 resulting from WD-90-2 added AKNN mandate added in chapter 3 First UAK-S internal distributed version Document changed during 91. UAK-S meeting on 20th May 2008 Chapter 2, 3 and 5.1.1 modified during 92. UAK-S meeting added to the document Document changed during 94. UAK-S meeting on 16th September 2008 Document changed during 95. UAK-S meeting on 21th October 2008 Document changed during 99. UAK-S meeting on 12th February 2009 and during editorial meeting on 11th March 2009 Changed during editorial meeting on 24th August 2009 Contributions of the UAK-S meetings 103. – 107. added Telekom proposals for references (document 109.2) and MIME bodies (chapter Annex B) added Telekom´s proposal completed, editorial changes Changes of 110th and 111th meeting added, chapter 8.4 deleted, three options for different formats added Changes of 112th meeting added, results of editor meeting on 20th December 2010 and of 114. UAK-S added Results of editor meeting on 14th February 2011 and of 115. UAK-S added; tables 8-1, 8-4, 8-5, 8-6, 8-7, 8-8 updated according to document UAKS_115_8_Telekom, number format of option 1 completed (UAKS_115_21_Telekom) Results of 130. AKNN and of UAK-S editor sessions on 11th March and 29th August 2011 added, (simulation services, references and new address option 4 added) Agreed review results of 120. UAK-S and results of editor session on 19th October added, (e.g. address option 3 deleted, In-dialog Overlap Signalling method deleted) Agreed review results of 121. and 122. UAK-S added, proposal for chapter 10.2.1 and 10.3 added Received review comments discussed in 123. UAK-S and added Results of 124. and 125. UAK-S added, options concerning encryption of history info header added. Results of 136. AKNN meeting added in chapter 8.4.1 (reference [66] changed to “draft-ietf-sipcore-rfc4244bis-08.txt” and Note added). Agreed version of 128. UAK-S meeting on 20th December 2012 in Nürnberg. Identical in content to previous version. Results of editor meeting on 16th December 2013 and of 134. UAK-S on 17th December 2013 added. Changes of version 0.1.1 accepted. Agreed contributions of 135th UAK-S on 18th February 2014 in Berlin added and marked. Results of 136th UAK-S meeting added. Results of 137th UAK-S meeting added. Agreed version of 137th UAK-S meeting on 26th August 2014 in Hannover Agreed version of 150th AKNN meeting on 14th October 2014 in Hannover UAK-S: NGN Ic Interface Ausgabestand: V1.0.0 vom 15.10.2014 Seite 6 von 98 Spec_UAKS_NGN_Ic_Interface_V1_0_0.docx 2 Foreword This technical specification defines the Interconnection Interface between NGN Service Providers for the service Voice over NGN (VoNGN) and has been produced by subworkinggroup UAK-S of AKNN. The present document may refer to technical specifications or reports of 3GPP identities, UMTS identities, GSM identities, ETSI identities, ITU-T identities or IETF identities. These should be interpreted as being references to the corresponding deliverables. 3 Scope This document provides the specification for Network-Network-Interfaces (NNI) between Next Generation Networks (NGN) of NGN Service Providers. For the services defined in the AKNN document “Konzept für die Zusammenschaltung von Next Generation Networks” [[52]] this specification provides in detail the requirements for the service layer interface (Ic-Interface) and as far as needed, requirements for the transport layer interface (Iz-Interface). IP Multimedia Subsystem (IMS) architecture, as described in [[2]], is basically used for this specification. The NNI (Ic) reference point for this document is described as profile definition of TISPAN, 3GPP and IETF standards. UAK-S: NGN Ic Interface Ausgabestand: V1.0.0 vom 15.10.2014 Seite 7 von 98 Spec_UAKS_NGN_Ic_Interface_V1_0_0.docx 4 References The present document is based on TISPAN Release 2 specifications for NGN (see: [[1]]). If features of higher releases or other standardization bodies are needed, this will be mentioned explicitly. [[1]] Draft ETSI WI 00005 V0.4.8 (2010-04): Telecommunications and Internet converged Services and Protocols for Advanced Networking (TISPAN); Release 2 Definition (not yet published) download: ftp://docbox.etsi.org/TISPAN/Open/NGN_LATEST_DRAFTS/RELEASE2/ Editorial note: The internal references in this specification are noted in double brackets [[x]]. The format of imported reference lists in chapter 8 are not changed and noted in single brackets [y]. 4.1 References (normative) The following references apply in case bilateral agreements exist to support the corresponding functionalities. 4.1.1 Basic References 4.1.1.1 Architecture [[2]] ETSI TS 123 517 V8.0.0 (2007-12): Digital cellular telecommunication system (Phase 2+); Universal Mobile Telecommunication System (UMTS); Telecommunications and Internet converged Services and Protocols for Advanced Networking (TISPAN); IP Multimedia Subsystem (IMS); Functional Architecture (3GPP TS 23.517 version 8.0.0 Release 8) 4.1.1.2 Protocols Within the framework of interconnection between NGNs, the specification ETSI ES 283 003 is applicable as Call Control Protocol for the NGN service VoNGN: [[3]] ETSI TS 124 503 V8.3.0 (2009-01): Digital cellular telecommunication system (Phase 2+); Universal Mobile Telecommunication System (UMTS); LTE;TISPAN; IP Multimedia Call Control Protocol based on Session Initiation Protocol (SIP) and Session Description Protocol (SDP) Stage 3 [3GPP TS 24.229 (Release 7), modified] (3GPP TS 24.503 version 8.3.0 Release 8) For handling of overlap signalling in IBCF Annex N and related Chapter 4.9.2 of [[4]] are applicable. For handling of the rn-Parameter chapters 5.3.2.1, 5.4.3.2, 5.5.1 and 5.6.2 of [[4]] are applicable. [[4]] 3GPP TS 24.229 (V9.6.0) (2010-12): "3rd Generation Partnership Project; Technical Specification Group Core Network and Terminals; IP multimedia call control protocol based on Session Initiation Protocol (SIP) and Session Description Protocol (SDP); Stage 3 (Release 9)" [[5]] IETF RFC 791 (September 1981): Internet Protocol [[6]] IETF RFC 2460 (December 1998): Internet Protocol, Version 6 (IPv6) Specification [[7]] IETF RFC 4040 (April 2005): RTP Payload Format for a 64 kbit/s Transparent Call UAK-S: NGN Ic Interface Ausgabestand: V1.0.0 vom 15.10.2014 Seite 8 von 98 Spec_UAKS_NGN_Ic_Interface_V1_0_0.docx [[8]] IETF RFC 4694 (October 2006): Number Portability Parameters for the "tel" URI [[9]] IETF RFC 5009 (September 2007): Private header (P-Header) extension to the Session Initiation Protocol (SIP) for authorization of Early Media [[10]] ITU-T Recommendation V.152 (November 2004): Procedures for supporting Voice-Band Data over IP Networks [[11]] ITU-T Recommendation T.38 (September 2010, pre-published): Group 3 facsimile communication over IP networks Procedures for real-time Further references for profiling: see chapter 8 4.1.1.3 Numbering and Addressing [[12]] ETSI TR 184 003 V3.1.1 (2010-06): Portability of telephone numbers between operators for Next Generation Networks (NGN) [[13]] ETSI TS 184 011 V3.1.1 (2011-02): Requirements and usage of E.164 numbers in NGN and NGCN 4.1.1.4 Simulation Services The following Simulation Services are applicable on the interconnection Interface: [[14]] ETSI TS 183 008 V2.8.0 (2008-06): Telecommunications and Internet converged Services and Protocols for Advanced Networking (TISPAN); PSTN/ISDN simulation services; Terminating Identification Presentation (TIP) and Terminating Identification Restriction (TIR); Protocol specification [[15]] ETSI TS 183 007 V2.0.0 (2008-06): Telecommunications and Internet converged Services and Protocols for Advanced Networking (TISPAN); PSTN/ISDN simulation services; Originating Identification Presentation (OIP) and Originating Identification Restriction (OIR); Protocol specification [[16]] ETSI TS 183 004 V2.5.0 (2008-06): Telecommunications and Internet converged Services and Protocols for Advanced Networking (TISPAN); PSTN/ISDN simulation services: Communication Diversion (CDIV); Protocol specification [[17]] ETSI TS 183 011 V 2.0.0 (2008-06): Telecommunications and Internet converged Services and Protocols for Advanced Networking (TISPAN); PSTN/ISDN simulation services: Anonymous Communication Rejection (ACR) and Communication Barring (CB); Protocol specification NGN [[18]] ETSI TS 183 010 V2.0.0 (2008-06): Telecommunications and Internet converged Services and Protocols for Advanced Networking (TISPAN);NGN Signalling Control Protocol; Communication HOLD (HOLD) PSTN/ISDN simulation services; Protocol specification [[19]] ETSI TS 183 005 V2.6.0 (2008-06): Telecommunications and Internet converged Services and Protocols for Advanced Networking (TISPAN); PSTN/ISDN simulation services: Conference (CONF); Protocol specification [[20]] ETSI TS 183 054 V2.2.0 (2008-06): Telecommunications and Internet converged Services and Protocols for Advanced Networking (TISPAN); PSTN/ISDN simulation services; Protocol specification Closed User Group (CUG) UAK-S: NGN Ic Interface Ausgabestand: V1.0.0 vom 15.10.2014 Seite 9 von 98 Spec_UAKS_NGN_Ic_Interface_V1_0_0.docx [[21]] ETSI TS 183 042 V2.1.1 (2009-01): Telecommunications and Internet converged Services and Protocols for Advanced Networking (TISPAN);PSTN/ISDN Simulation Services; Completion of Communications to Busy Subscriber (CCBS), Completion of Communications by No Reply (CCNR);Protocol Specification [[22]] ETSI TS 183 058 V2.1.0 (2008-06): Telecommunications and Internet Converged Services and Protocols for Advanced Networking (TISPAN);SIP Transfer of IP Multimedia Service Tariff Information; Protocol specification (“SIP-Charging") [[23]] ETSI TS 183 015 V2.1.1 (2009-04): Telecommunications and Internet converged Services and Protocols for Advanced Networking (TISPAN);NGN Signalling Control Protocol; Communication Waiting (CW) PSTN/ISDN simulation services [[24]] ETSI TS 183 029 V2.6.0 (2008-06): Telecommunications and Internet converged Services and Protocols for Advanced Networking (TISPAN); PSTN/ISDN simulation services: Explicit Communication Transfer (ECT); Protocol specification [[25]] ETSI TS 183 016 V2.6.0 (2008-06): Telecommunications and Internet converged Services and Protocols for Advanced Networking (TISPAN); PSTN/ISDN simulation services; Malicious Communication Identification (MCID); Protocol specification [[26]] ETSI TS 183 006 V2.0.0 (2008-06): Telecommunications and Internet converged Services and Protocols for Advanced Networking (TISPAN);PSTN/ISDN simulation services; Message Waiting Indication (MWI); Protocol specification [[27]] ETSI TS 124 628 V8.2.0 (2009-01): Digital cellular telecommunications system (Phase 2+); Universal Mobile Telecommunications System (UMTS); LTE; Common Basic Communication procedures using IP Multimedia (IM) Core Network (CN) subsystem; Protocol specification (3GPP TS 24.628 version 8.2.0 Release 8) Note: [[28]] Note: Currently there exists no separate specification for UUS. ETSI TS 124 642 V10.3.0 (2011-06): Digital cellular telecommunications system (Phase 2+); Universal Mobile Telecommunications System (UMTS); LTE; Completion of Communications to Busy Subscriber (CCBS) and Completion of Communications by No Reply (CCNR) using IP Multimedia (IM)Core Network (CN) subsystem; Protocol Specification (3GPP TS 24.642 version 10.3.0 Release 10) [[28]] is only applicable for the handling of CCNL. 4.1.1.5 Emulation Services The support of the emulation services will be achieved by the support of the related content types in the MIME-bodies (see Annex B). [[29]] IETF RFC 3204 (December 2001): MIME media types for ISUP and QSIG Objects UAK-S: NGN Ic Interface Ausgabestand: V1.0.0 vom 15.10.2014 Seite 10 von 98 Spec_UAKS_NGN_Ic_Interface_V1_0_0.docx [[30]] ETSI TS 183 043 V2.3.1 (2009-03): Telecommunications and Internet converged Services and Protocols for Advanced Networking (TISPAN); IMS - based PSTN/ISDN Emulation; Stage 3 specification [[31]] IETF draft-ietf-bliss-call-completion-10 (May 2011): Call Completion for Session Initiation Protocol (SIP) [[32]] IETF RFC 3863 (August 2004): Presence Information Data Format (PIDF) 4.1.1.6 Emergency Calls [[33]] IETF Draft draft-ietf-ecrit-additional-data-11: “Additional Data related to an Emergency Call” – July 2013 [[34]] ITU-T Recommendation Q.763: “Signalling System No. 7 – ISDN user part formats and codes” – December 1999 [[35]] ITU-T Recommendation Q.931: “Digital subscriber Signalling System No. 1 – Network layer” – May 1998 [[36]] IETF RFC 5139: “Revised Civic Location Format for Presence Information Data Format Location Object (PIDF-LO)” – February 2008 [[37]] IETF RFC 5491: “GEOPRIV Presence Information Data Format Location Object (PIDF-LO) Usage Clarification, Considerations, and Recommendations” – March 2009 [[38]] 3GPP TS 23.032 V11.0.0 (2012-09): “3rd Generation Partnership Project; Technical Specification Group Services and System Aspects; Universal Geographical Area Description (GAD) (Release 11)” [[39]] 3GPP TS 23.003 V11.5.0 (2013-03): “3rd Generation Partnership Project; Technical Specification Group Core Network and Terminals; Numbering, addressing and identification (Release 11)” [[40]] OGC 06-142r1 V1.0 (2007-04-10): “Open Geospatial Consortium Inc; GML 3.1.1 PIDF-LO Shape Application Schema for use by the Internet Engineering Task Force (IETF)” [[41]] IETF Draft draft-thomson-geopriv-confidence-03: “Expressing Confidence in a Location Object” – October 2010 [[42]] IETF Draft draft-thomson-geopriv-uncertainty-07: “Representation of Uncertainty and Confidence in PIDF-LO” – March 2012 4.2 References (informative) References mentioned in this document (informative): [[43]] 3GPP TS 24.229 V7.9.0 (2007-09): 3rd Generation Partnership Project; Technical Specification Group Core Network and Terminals; IP multimedia call control protocol based on Session Initiation Protocol (SIP) and Session Description Protocol (SDP); Stage 3 (Release 7) [[44]] 3GPP TS 24.229 V9.6.0 (2010-12): 3rd Generation Partnership Project; Technical Specification Group Core Network and Terminals; IP multimedia call control protocol based on Session Initiation Protocol (SIP) and Session Description Protocol (SDP); Stage 3 (Release 9) UAK-S: NGN Ic Interface Ausgabestand: V1.0.0 vom 15.10.2014 Seite 11 von 98 Spec_UAKS_NGN_Ic_Interface_V1_0_0.docx [[45]] 3GPP TS 29.165 V9.6.0 (2011-03): 3rd Generation Partnership Project; Technical Specification Group Core Network and Terminals; Inter-IMS Network to Network Interface; (Release 9) [[46]] 3GPP TS 29.162 V8.4.0 (2010-09): 3rd Generation Partnership Project; Technical Specification Group Core Network and Terminals; Interworking between the IM CN subsystem and IP networks (Release 8) [[47]] 3GPP TS 29.163 V8.24.0 (2013-12): 3rd Generation Partnership Project; Technical Specification Group Core Network and Terminals; Interworking between the IP Multimedia (IM) Core Network (CN) subsystem and Circuit Switched (CS) networks (Release 8) [[48]] ETSI TS 183 047 V2.2.0 (2008-06): Telecommunications and Internet converged Services and Protocols for Advanced Networking (TISPAN); PSTN/ISDN simulation services; Protocol specification AoC (“UNI-Interface”) [[49]] ETSI TS 129 527 V8.3.0 (2009-04): Digital cellular telecommunication system (Phase 2+); Universal Mobile Telecommunication System (UMTS); TISPAN; [Endorsement of the SIP-ISUP interworking between the IP Multimedia (IM) Core Network (CN) subsystem and Circuit Switched (CS) networks [3GPP TS 29.163 (Release 7), modified ] (3GPP TS 29.527 version 8.3.0 Release 8) Note: This reference is used for identifying the PSTN MIME-body. 4.2.1 Architecture [[50]] ETSI ES 282 001 V2.0.0 (2008-03): Telecommunications and Internet converged Services and Protocols for Advanced Networking (TISPAN); NGN Functional Architecture [[51]] ETSI ES 282 010 V2.0.6 (2008-04): Telecommunications and Internet converged Services and Protocols for Advanced Networking (TISPAN); Charging management [Endorsement of 3GPP TS 32.240 Release 7, 3GPP TS 32.260 Release 7, 3GPP TS 32.297 Release 7, 3GPP TS 32.298 Release 7 and 3GPP TS 32.299 Release 7 modified] 4.3 National References [[52]] AKNN UAK-NGN: Konzept für die Zusammenschaltung von Next Generation Networks, V2.0.0, 31.03.2009 [[53]] Bundesnetzagentur(BNetzA): Technische Richtlinie Notruf (TR-Notruf), Version 1.0 – June 2011 [[54]] Vfg Nr. 14/2013 der Bundesnetzagentur: § 108 Telekommunikationsgesetz (TKG) in Verbindung mit § 7 Absatz 7 Verordnung über Notrufverbindungen (NotrufV); hier: Erweiterung der Standortbeschreibungsformen in der Technische Richtlinie Notrufverbindungen (TR Notruf) – April 2013 UAK-S: NGN Ic Interface Ausgabestand: V1.0.0 vom 15.10.2014 Seite 12 von 98 Spec_UAKS_NGN_Ic_Interface_V1_0_0.docx 5 Definitions and Abbreviations 5.1 Definitions 5.1.1 Nature of SIP SIP is basically used to exchange signalling information on the UNI and NNI and among them. This document considers only SIP Signalling Information that is exchanged on the NNI. Please refer to following Figure 5-1. The NNI is the Ic-Interface per ETSI TISPAN ES 282 001 as outlined in section 6 of this document. NGN network A ETSI TISPAN NGN Rel. 2 SIP SIP (n/a) SIP (n/a) IC-SIP (o) IC-SIP (o) IC-SIP IC-SIP (m) IC-SIP (m) NGN network B ETSI TISPAN NGN Rel. 2 SIP NGN-InterconnectionInterface (Ic, NNI) n/a not applicable o optional m mandatory . Figure 5-1: SIP at the NNI between NGN providers 5.1.1.1 SIP See reference [[3]] For the purpose of this specification standard SIP is divided up in SIP that is relevant for interconnection (IC- SIP (m) /IC-SIP (o)) between NGN operators / service providers and SIP that is (currently) not used on the Ic-Interface (SIP (n/a)). 5.1.1.2 IC-SIP(m) IC-SIP(m) := Interconnection-SIP (mandatory) This is the basic set of methods, status codes and headers that must be supported by every NGN operator on the Ic-Interface. The mandatory methods can be found in Table 8-5, the mandatory status codes are listed in Table 8-6 and the mandatory headers are detailed in Table 8-7. 5.1.1.3 IC-SIP(o) IC-SIP(o) := Interconnection-SIP (optional) These are methods, status codes and headers that may additionally be supported on the Ic-Interface by NGN operators on basis of mutual agreements. The optional methods can be found in Table 8-5, the optional status codes are listed in Table 8-6 and the optional headers are detailed in Table 8-7. UAK-S: NGN Ic Interface Ausgabestand: V1.0.0 vom 15.10.2014 Seite 13 von 98 Spec_UAKS_NGN_Ic_Interface_V1_0_0.docx 5.1.1.4 SIP(n/a) SIP(n/a) := SIP (not applicable) These are methods, status codes and headers that are currently not supported on the Ic-Interface by NGN operators. They may however be used inside the NGN of an NGN service provider/operator. The not applicable methods can be found in Table 8-5, the not used status codes are listed in Table 8-6 and the not applicable headers are detailed in Table 8-7. 5.1.2 Reference Points of Interfaces For the purposes of the present document the following reference points apply: Ic Reference Point between IBCF of different NGN domains Iz Reference Point between I-BGF of different NGN domains 5.1.3 Trust Domain and Topology Hiding The interconnected networks as described in this document are seen as “Trust domain” as described in [[3]], chapter 4.4. Therefore based on bilateral contracts it shall be possible to exchange sensitive headers (P-Headers) between interconnection partners. In a destination network it shall be guaranteed by the operator that terms and conditions of privacy values shall be followed in correspondence to [33] and [34]. The use of Topology Hiding (THIG) is optional and is dependent on network policies. However THIG and Trust Domain are independent features. 5.1.4 P-Asserted-Identity The transmission of a trusted identity in form of a calling party number in the SIP header field P-AssertedIdentity among interconnection partners is mandatory. The originating network shall ensure that the subscriber’s information in the P-Asserted Identity (user part and host portion) are verified, screened and hence can uniquely be assigned to a certain subscriber. The P-Asserted-Identity Header shall be set up by the originating network operator and shall be transmitted transparently through the networks. For calls originating from a circuit switched network, the P-Asserted-Identity Header is set up in general from the interworking network. Note: For calls originating from Circuit Switched Networks carrying no or an incomplete CLI (see [[47]], Table 12 ) or for international calls, a P-Asserted-Identity SIP Header Field needs not necessarily be present. For the format of a P-Asserted-Identity Header, please refer to sub-clause 7.1.3. Note: In the future case of a roaming mobile customer, the domain of the P-Asserted-Identity Header needs not necessarily match the domain of the originating network operator (VPLMN). 5.2 Abbreviations see: [[3]] resp. [[4]], subclause 3.2 6 Architecture For the service VoNGN it is assumed that the interconnection carriers are using the IP Multimedia Subsystem (IMS) as Control Subsystem as described in [[50]], chapter 7.2.2 figure 7. UAK-S: NGN Ic Interface Ausgabestand: V1.0.0 vom 15.10.2014 Seite 14 von 98 Spec_UAKS_NGN_Ic_Interface_V1_0_0.docx Iw Ib Service Cont rol Subsyst ems IWF IBCF IBCF Ic Service Layer To/From ot her IP net works Transport Layer Transport cont rol Transport processing I-BGF Iz Figure 6-1: NGN Interconnection, see [[50]], chapter 7.2.2, figure 7 The Iw-Interface and the IWF are not part of this specification. 6.1 Ic-Interface The Ic-Interface shall be used for interconnection with other VoNGN operators at the service layer level. 6.2 Iz-Interface The Iz-Interface shall be used for interconnection with other VoNGN operators at the transport layer level. UAK-S: NGN Ic Interface Ausgabestand: V1.0.0 vom 15.10.2014 Seite 15 von 98 Spec_UAKS_NGN_Ic_Interface_V1_0_0.docx 7 Numbering and Addressing at the Ic-Interface 7.1 Format of SIP URIs For the purpose of interconnection the URI format of a SIP URI shall be used. The userpart is formatted as specified within RFC 3966 (reference [22]). The SIP URI is marked with "user = phone". The "alias format" for SIP URI is not allowed at the NNI (Ic). Notes: 1) 2) 3) 4) Currently the "alias format" for a SIP-URI is not supported The following formats can occur in combination (e.g. ported international service number) The set up of telephone numbers shall be done in accordance with regulatory requirements. DNS forward lookups for the SIP URI’s <hostportion> (e.g. operator.de) do not have to be supported by the domain owner (e.g. operator.de). Editorial remark: In the following examples blanks are included due to a better readability. 7.1.1 Global Number Format The global-number format as specified in chapter 5.1.4 of RFC 3966 [22] for a SIP URI using E.164-numbers is defined as follows: sip: +<CC> <NDC> <SN> @ <hostportion>; user=phone with: CC: NDC: SN: Country Code National Destination Code Subscriber Number Example: sip: +49 30 12345678 @ operator.de; user=phone 7.1.2 SIP Request URI For a SIP Request URI, the global number format according to clause 7.1.1 shall be used. However, for certain call scenarios as described in the following sub-clauses the transmission of additional routing information is necessary. To route calls including additional information like hexadecimal digits (e.g. calls to PSAPs or ported destinations) the use of the rn-Parameter [[8]] is mandatory, since the use of hexadecimal digits in the Request-URI using the Global Number Format is not allowed. Being a TEL-URI parameter the rn-parameter shall be used before the "@" in the user part of a Request-URI (see also Annex A of this specification). If an rn-Parameter is available in a SIP Request URI, its evaluation shall take precedence in the user part. 7.1.2.1 Number Portability For a call with a ported destination (“Export Fall”), the following form shall be used: sip: +<CC> <NDC> <SN> [;npdi] ;rn = +<CC> D<xyz> <NDC> <SN> @ <hostportion>; user = phone The parameter npdi denotes that a check of the porting in the LNP database has already been done. The porting identifier (Portierungskennung) D<xyz> denotes the target network operator. The set up of the npdi parameter is optional but if received it shall be analysed. UAK-S: NGN Ic Interface Ausgabestand: V1.0.0 vom 15.10.2014 Seite 16 von 98 Spec_UAKS_NGN_Ic_Interface_V1_0_0.docx The +<CC>, <NDC>, <SN> in the Request-URI and in the rn TEL-URI parameter are of equal value. Example: sip: +49 6151 1234567 [;npdi] ;rn = +49 D123 6151 1234567 @ operator.de; user = phone 7.1.2.2 Emergency Calls (Notruf) This chapter describes the number format of an emergency call (Notruf) dependent on the technology (NGN and PSTN, respectively) of the Public Safety Answering Point (Notrufabfragestelle, PSAP) and gives an example in each case. For the transmission of information accompanying the emergency call, please refer to clause 14. 7.1.2.2.1 PSAP in PSTN Technology On the NNI the following format is required for emergency calls to a PSTN PSAP: sip: +<CC> <VLN> <NDC> <x(y)>; rn = + <CC> <NDC> CC<x(y)> @ <host portion>; user=phone For the so called directory number (the part of the Request-URI before the (rn-)Parameter(s)), the normalized PSAP encoding into global number format with stripped hex-CC and added routing number (“Verkehrslenkungsnummer”, VLN) (0)1982 between CC and NDC shall be used. Please note also the difference between the abbreviation <CC> denoting the country code and the hexdigits CC in the encoding of the PSAP. The use of the rn-Parameter is necessary, since the encoding of the PSAP contains hexadecimal digits. An exemplary SIP Request URI is shown below: sip: +49 1982 911 21; rn = +49 911 CC21 @ telekom.de; user=phone Please note that the VLN (0)1982 has not yet been assigned by the BNetzA. As an interim solution until the VLN has finally been allocated, the <VLN> in the directory number could also be omitted. 7.1.2.2.2 PSAP in NGN Technology On the NNI the following format is required for emergency calls to an NGN PSAP: sip: +<CC> <VLN> <NCbnetza> @ <host portion>; user=phone The number NCbnetza will be assigned by BNetzA in conjunction with the coding of the destination PSAP access line. Also, due to limitations in the existing PSTN technology, the length of such a PSAP number (VLN and NCbnetza) may be 12 digits (including the leading “0”) at the most. This is to ensure that an NGN PSAP can also be reached from PSTN customers. For the time being the length of NCbnetza is thus limited to 7 digits. Note: After the last ISDN switch has been shut down, the length restriction of twelve digits does not apply anymore and the format of an NGN PSAP routing number could be revised. The routing number (“Verkehrslenkungsnummer”, VLN) (0)1982 shall be used between Country Code and NCbetza. Please note that the VLN (0)1982 has not yet been assigned by the BNetzA. Note: Details will be provided in TR Notruf (section covering the “Notrufanschlüsse in IP Technik”) An exemplary SIP Request URI is shown below: sip: +49 1982 4711815 @ telekom.de; user=phone UAK-S: NGN Ic Interface Ausgabestand: V1.0.0 vom 15.10.2014 Seite 17 von 98 Spec_UAKS_NGN_Ic_Interface_V1_0_0.docx 7.1.2.3 Harmonised Numbers for Harmonised Services of Social Value (Harmonisierte Dienste von sozialem Wert) The so called Harmonised Services of Social Value (HDSW) are called party numbers of the format 116xyz. On the interconnection interface the part xyz of the called number 116xyz has to be preceded by the routing prefix (0)1987. sip: +<CC> 1987 <xyz> @ <hostportion>; user = phone Example: For a call to a service to get a lost bank or credit card locked (dialled number 116116) the interconnection format looks like: sip: +49 1987 116 @ operator.de; user = phone 7.1.2.4 Authority Bureau Call (Einheitlicher Behördenruf) The so called authority bureau call (Einheitlicher Behördenruf) 115 is a nationwide established service number where the citizen’s questions with civic topics are answered. According to BNetzA directive 38/2010, the authority bureau call was changed to a geographic destination. Hence the global number format according to chapter 7.1.1 with 115 as subscriber number shall be used. sip: +<CC> <NDC> 115 @ <hostportion>; user = phone Example: sip: +49 911 115 @ operator.de; user = phone However, for calls originating from mobile networks, a different format including location information can also be used. For this location information, three alternatives are suggested: NDC (ONKZ) coding, “Allgemeiner Gemeindeschlüssel” (AGS) coding or emergency coding. These alternatives are distinguished by a special indicator digit. For these cases the following formats shall be used: NDC or AGS coding: sip: +<CC> 1986 115 <y> <xxxxxxx> @ <hostportion>; user = phone with: y: xxxxxxx: Indicator Digit (0 or 1: AGS coding, 2: NDC Coding) AGS or 3 digit NDC Example: sip: +49 1986 115 0 9564000 @ operator.de; user = phone Emergency Coding: sip: +<CC> 1986 115; rn = +<CC> 1986 115 <y> <xxxxxxx> @ <hostportion>; user = phone with: y: xxxxxxx: Note: Indicator Digit (3: Emergency Coding) Emergency Coding including Hexadecimal Digits The additional rn-Parameter is necessary since the emergency coding contains hexadecimal digits. Example: sip: +49 1986 115; rn = +49 1986 115 3 911CC21 @ operator.de; user = phone UAK-S: NGN Ic Interface Ausgabestand: V1.0.0 vom 15.10.2014 Seite 18 von 98 Spec_UAKS_NGN_Ic_Interface_V1_0_0.docx 7.1.2.5 Directory Enquiries (Auskunft) The Directory Enquiries (“Auskunft”) is designed as follows: 118(0)xy. The part <(0)xy> of the called number has to be preceded by the routing prefix (0)1989. The following format shall be used: sip: +<CC> 1989 (0)<xy> @ <hostportion>; user = phone Example: sip: +49 1989 33 @ operator.de; user = phone 7.1.2.6 Tollfree Callback Service for Directory Enquiries (Entgeltfreie Rückrufnummer für Vermittlungsdienste) The Tollfree Callback Service for Directory Enquiries (“Entgeltfreie Rückrufnummer für Vermittlungsdienste”) is designed as follows: 0118(0)xy According to BNetzA directive 53/2011, the Tollfree Callback Service for Directory Enquiries is introduced to the national networks. From the view of originating network operators it shall be handled in same manner as the freephone services are handled. sip: +49 118 (0) xy @ <hostportion>; user = phone Example: sip: +49 118 10 @ operator.de; user = phone For this procedure the CDIV service according to [[16]] shall be used. Additionally the `From´ header can be set to the number of the toll free callback service. 7.1.2.7 International Freephone Services For the International Freephone Service (IFS) the following format shall be used: sip: +<CC> 1988 <xy>[*z] @ <hostportion>; user = phone Please note that additional digits *z will follow the carrier code <xy> based on bilateral agreements. Example: sip: +49 1988 23 54321 @ operator.de; user = phone 7.1.2.8 International Service Numbers International service numbers (e.g. +800, +808) shall be transmitted in the following format: sip: + <International Service Number> @ <host portion>; user = phone This format is required in order to distinguish between International service numbers and National service numbers. An exemplary SIP Request URI is shown below: sip: +800 12345678 @ operator.de; user=phone UAK-S: NGN Ic Interface Ausgabestand: V1.0.0 vom 15.10.2014 Seite 19 von 98 Spec_UAKS_NGN_Ic_Interface_V1_0_0.docx 7.1.2.9 Test numbers for Carrier Selection Calls The test numbers to identify the selected carrier are allocated as follows: (0)310: Test of Carrier Selection for long distant calls and (0)311: Test of Carrier Selection for short distant calls These numbers shall be transmitted in the following format: sip: +<CC> <Carrier Selection Test number> @ tariff.<host portion>; user=phone including the special tariff subdomain according to sub-clause 7.3. An exemplary SIP Request URI is shown below: sip: +49 310 @ tariff.operator.de; user=phone 7.1.3 P-Asserted-Identity Header Field Only Domain Names shall be used for the host portion of the P-Asserted-Identity Header Field. The user part of the P-Asserted-Identity Header Field shall be set up as a Global Number Format as defined in clause 7.1.1. Optionally, a display name can also be set into the P-Asserted-Identity Header Field. An exemplary P-Asserted-Identity Header Field is shown below: P-Asserted-Identity: “Hans Mustermann” <sip:+49 911 1234567 @ operator.de; user=phone> 7.1.4 From Header Field In general, the From Header Field is screened by the originating party’s network operator and hence carries a Global Number Format as defined in clause 7.1.1. If the special “no screening” arrangement is used, the originating party’s network operator forwards the From Header Field as originally set up by the end customer. Thus, the From Header Field needs not necessarily carry a Global Number Format in this case. However, the end customer may only set up a number he has been allocated. In this case, a trusted number set up by the originating network operator in the P-Asserted-Identity Header Field according to clause 7.1.3 shall be transmitted alongside the From Header Field. 7.1.5 To Header Field No requirements are made regarding the format of the To-Header Field. 7.1.6 History-Info Header Field For the SIP History-Info Header Field, a Global Number Format as defined in clause 7.1.1 shall be used. 7.2 Routing of SIP Requests The domain name of the target network shall in any case be set up correctly according to RFC 3261 and ETSI TR 184 003. The use of host portion dependent routing is based on bilateral agreements. In any case the transit is based on bilateral agreements. Note: The following call scenarios only depict exemplary codings. UAK-S: NGN Ic Interface Ausgabestand: V1.0.0 vom 15.10.2014 Seite 20 von 98 Spec_UAKS_NGN_Ic_Interface_V1_0_0.docx 7.2.1 Scenario 1: Termination Subscriber A is sending a call attempt to Home Network A. During the NP database dip in Home Network A for the number dialled by Subscriber A the B-Domain was determined as Home Network of Subscriber B. A direct interconnect between A-Domain and B-Domain exists in this scenario. B-Domain A-Domain Home network B sub Home network A-sub +498948124812@b-domain +493047114711@a-domain DB DB B-sub A-sub Request-Line: Invite sip:+498948124812@b-domain; user=phone From: “Name“<sip: +493047114711@a-domain; user=phone> P-Asserted-Identity: “+493047114711“ <sip:+493047114711@a-domain; user=phone> To: < sip:+498948124812@a-domain; user=phone > Remark: Only the Request URI will be used for the routing. Figure 7-1: Scenario 1: Termination UAK-S: NGN Ic Interface Ausgabestand: V1.0.0 vom 15.10.2014 Seite 21 von 98 Spec_UAKS_NGN_Ic_Interface_V1_0_0.docx 7.2.2 Scenario 2a: Determination of the Destination Network is not possible in the A-Domain In case of transit situations, where based on bilateral agreements the transiting network will perform a number portability query to determine the FQDN of the destination, the originating network will use the domain name of this transit network to set up the request (scenario 2a). A-Domain B-Domain Home Network A-sub +493047114711@a-domain Home Network B-sub P-Domain *1 DB +498948124812@b-domain DB DB B-sub A-sub Request-Line: Request-Line: Invite sip:+498948124812@p-domain; user=phone Invite sip:+498948124812@b-domain; user=phone From: “Name“<sip: +493047114711@a-domain; user=phone> From: “Name“<sip: +493047114711@a-domain; user=phone P-Asserted-Identity: “+493047114711 “ P-Asserted-Identity: “+493047114711 “ <sip:+493047114711@a-domain; user=phone> To: < sip:+498948124812@a-domain; user=phone > <sip:+493047114711@a-domain; user=phone> To: < sip:+498948124812@a-domain; user=phone > Remark: Only the Request URI will be used for the routing. *1 The P-Domain determines the home network of the B-Subscriber with a database query. There exist bi-/trilaterale agreements beween A-, P- and B-domain concerning the transfer of these connections. Figure 7-2: Scenario 2a: Determination of the Destination Network is not possible in the A-Domain UAK-S: NGN Ic Interface Ausgabestand: V1.0.0 vom 15.10.2014 Seite 22 von 98 Spec_UAKS_NGN_Ic_Interface_V1_0_0.docx 7.2.3 Scenario 2b: Determination of the Destination Network is possible in the A-Domain, but there is no Traffic Relation to the Destination Domain P-Domain is receiving a call attempt from A-Domain directed to B-Domain in order to transmit this request based on Hostportion Dependent Routing. During the NP database dip in Home Network A for the Number dialled by Subscriber A the B-Domain was determined as Home Network of Subscriber B. A direct interconnect between A-Domain and B-Domain does not exist in this transit scenario. Based on bilateral agreements A-Domain is using P-Domain as transit in order to reach B-Domain. A-Domain *1 Home Network A-sub +493047114711@a-domain B-Domain Home Network B-sub P-Domain *1 DB +498948124812@b-domain DB DB B-sub A-sub Request-Line: Request-Line: Invite sip:+498948124812@b-domain; user=phone Invite sip:+498948124812@b-domain; user=phone From: “Name“<sip: +493047114711@a-domain; user=phone> From: “Name“<sip: +493047114711@a-domain; user=phone P-Asserted-Identity: “+493047114711 “ P-Asserted-Identity: “+493047114711 “ <sip:+493047114711@a-domain; user=phone> To: < sip:+498948124812@a-domain; user=phone > <sip:+493047114711@a-domain; user=phone> To: < sip:+498948124812@a-domain; user=phone > *1 The P-Domain determines the home network of the B-Subscriber with a database query. There exist bi-/trilateral agreements beween A-, P- and B-Domain concerning the transfer of these connections. Figure 7-3: Scenario 2b: Determination of the Destination Network is possible in the A-Domain, but there is no Traffic Relation to the Destination Domain UAK-S: NGN Ic Interface Ausgabestand: V1.0.0 vom 15.10.2014 Seite 23 von 98 Spec_UAKS_NGN_Ic_Interface_V1_0_0.docx 7.3 Charged / Non Charged Telephone Traffic There is a need to distinguish between charged and non charged traffic. Charged traffic means that a connection is charged by the originating network carrier (TNB). Non charged traffic means that a connection has to be charged by the selected carrier (VNB). For non charged traffic, an additional marking “tariff.” in the beginning of the host portion of the SIP Request URI shall be used. An exemplary SIP Request URI is shown below: sip: + 49 911 1234567 @ tariff.operator.de; user = phone For charged traffic, no marking shall be used, e.g. sip: +49 911 1234567 @ operator.de; user=phone This additional marking shall only be used for carrier selection traffic. Value added services will not be marked, since they can be distinguished by the number range. 7.4 Mobile Service Prefix (Mobilfunkservicevorwahl) This chapter describes the handling of the Mobile Service Prefix (Mobilfunkservicevorwahl) using a P-Germany-Tariff header. 7.4.1 Introduction When a number of the prefix range 0900 is dialled from a mobile network, additional tariff information is forwarded to the VNB/SP in the PSTN. This tariff information is realised using the Mobile service prefix and begins with the prefix C1C and is followed by two digits (tt), which include the current tariff information. Hence such a number is of the structure: (0) C1C tt 900 xxxxxx This information shall also be kept for calls transported via an NGN. Therefore, a P-Germany-Tariff header as defined in chapter 7.4.2 shall be used to transmit this information as part of an INVITE method. 7.4.2 Definition Syntax Notation in accordance to ABNF: P-Germany-Tariff = "P-Germany-Tariff" HCOLON tariff tariff = tariff-tag „=“ tariff-value tariff-tag = „tariff“ tariff-value = 2*2 DIGIT An exemplary SIP INVITE Request is shown below: INVITE SIP: +49 900 [email protected]; user=phone SIP/2.0 … P-Germany-Tariff: tariff=23 … 7.4.3 Transmission When received in a SIP INVITE request, the P-Germany-Tariff header shall be transmitted transparently through the networks and shall not be discarded. UAK-S: NGN Ic Interface Ausgabestand: V1.0.0 vom 15.10.2014 Seite 24 von 98 Spec_UAKS_NGN_Ic_Interface_V1_0_0.docx 7.5 Service Calls handed over from International Carriers To indicate that calls to certain service numbers were originally handed over at an international gateway, the P-Germany-Tariff header field as defined in sub-clause 7.4.2 may be used. In this case the tariff-value (“tariff cluster”) shall be set to 99. Note: The tariff cluster 99 is not used for the Mobile Service Prefix. An exemplary SIP INVITE Request is shown below: INVITE SIP: +49 180 [email protected]; user=phone SIP/2.0 … P-Germany-Tariff: tariff=99 … UAK-S: NGN Ic Interface Ausgabestand: V1.0.0 vom 15.10.2014 Seite 25 von 98 Spec_UAKS_NGN_Ic_Interface_V1_0_0.docx 8 Ic-Profile Endorsement for ETSI TISPAN TS 124 503 This section provides the endorsement of ETSI TISPAN TS 124 503 [[3]]. This chapter describes modifications to reflect the supported functionalities and e.g. methods and headers applicable for the Ic interface. As long as no modification of the base specification 3GPP TS 24.229 [[43]] was carried out by the ETSI endorsement TS 124 503 [[3]], the base specification [[43]] is valid with the modifications described in chapter 8.3 of this specification. The conditions e.g. A.x of the following tables can also be found in [[43]]. 8.1 Global Modifications The meaning of indication of the following tables is shown in Table 8-1. Table 8-1: Meaning of Indication in the last column Indication Meaning n/a not applicable; not supported m mandatory; supported by sending and receiving o optional; may be supported based on bilateral agreements x prohibited/excluded; it is not allowed to use the capability i irrelevant; outside the scope of this specification c<integer> conditional; the requirement on the capability depends on the support of other items. <integer> is the identifier of the conditional expression. p<integer> prerequisite In general the base specifications defined in clause 4 are valid. An “m” in the last column of Table 8-2 to Table 8-4 does not necessarily mean that the entire reference is valid. 8.2 Modifications ETSI TS 124 503 V8.3.0 Table 8-2: Modified Table 1 in chapter 2.1 of ETSI TS 124 503 [[3]] References in 3GPP TS 24.229 Replaced references by ETSI TS 124 503 [2] 3GPP TS 23.002: "Network architecture". Relevant for UAK-S NGN Ic Interface ETSI ES 282 007: "Telecommunications and Internet converged Services and Protocols for Advanced Networking (TISPAN); IP Multimedia Subsystem (IMS); Functional architecture" (note 1) m ETSI ES 282 001: "Telecommunications and Internet converged Services and Protocols for Advanced Networking (TISPAN); NGN Functional Architecture Release 2" (note 1) m [4A] 3GPP TS 23.107: "Quality of (note 2) Service (QoS) concept and architecture". n/a [4B] 3GPP TS 23.167: "IP Multimedia Subsystem (IMS) emergency session; Stage 2". ETSI TS 182 009: 'Telecommunications and Internet converged Services and Protocols for Advanced Networking (TISPAN); NGN Architecture to support emergency communication from citizen to authority' (note 1) (note 2) n/a [5] 3GPP TS 23.218: "IP Multimedia (IM) Session Handling; IM call model". (note 2) n/a [6] 3GPP TS 23.221: "Architectural requirements". (note 2) n/a [4C] 3GPP TS 23.122: "Non-AccessStratum (NAS) functions related to Mobile Station (MS) in idle mode". UAK-S: NGN Ic Interface Ausgabestand: V1.0.0 vom 15.10.2014 n/a Seite 26 von 98 Spec_UAKS_NGN_Ic_Interface_V1_0_0.docx References in 3GPP TS 24.229 Replaced references by ETSI TS 124 503 Relevant for UAK-S NGN Ic Interface [7] 3GPP TS 23.228: "IP multimedia subsystem; Stage 2". ETSI TS 182 006: "Telecommunications and Internet converged Services and Protocols for Advanced Networking (TISPAN); IP Multimedia Subsystem (IMS); Stage 2 description" m [8] 3GPP TS 24.141: "Presence service using the IP Multimedia (IM) Core Network (CN) subsystem; Stage 3". ETSI ES 283 030: "Telecommunications and Internet converged Services and Protocols for Advanced Networking (TISPAN); Presence Service Capability; Protocol Specification [3GPP TS 24.141 V7.0.0, modified and OMA-TSPresence_SIMPLE-V1_0, modified]" (note 1) n/a [10] 3GPP TS 26.235: "Packet switched conversational multimedia applications; Default codecs". ETSI TS 181 005: "Telecommunications and Internet converged Services and Protocols for Advanced Networking (TISPAN); Services and Capabilities Requirements' (note 1) n/a [10A] 3GPP TS 27.060: "Mobile Station (note 2) (MS) supporting Packet Switched Services". n/a [11A] 3GPP TS 29.162: "Interworking between the IM CN subsystem and IP networks". ETSI TS 183 021: "Telecommunications and Internet converged Services and Protocols for Advanced Networking (TISPAN); NGN Release 1; Endorsement of 3GPP TS 29.162 Interworking between IM CN Sub-system and IP networks" (note 1) c1 ETSI ES 283 027: 'Telecommunications and Internet converged Services and Protocols for Advanced Networking (TISPAN); Endorsement of the SIP-ISUP Interworking between the IP Multimedia (IM) Core Network (CN) subsystem and Circuit Switched (CS) networks [3GPP TS 29.163 (Release 7), modified]' (note 1) [14] 3GPP TS 29.228: "IP Multimedia ETSI TS 183 033: "Telecommunications and (IM) Subsystem Cx and Dx Interfaces; Internet converged Services and Protocols for Signalling flows and message contents". Advanced Networking (TISPAN); IP Multimedia; Diameter based protocol for the interfaces between the Call Session Control Function and the User Profile Server Function/Subscription Locator Function; Signalling flows and protocol details [3GPP TS 29.228 V6.8.0 and 3GPP TS 29.229 V6.6.0, modified]" (note 1) [15] 3GPP TS 29.229: "Cx and Dx ETSI TS 183 033: "Telecommunications and Interfaces based on the Diameter Internet converged Services and Protocols for protocol, Protocol details". Advanced Networking (TISPAN); IP Multimedia; Diameter based protocol for the interfaces between the Call Session Control Function and the User Profile Server Function/Subscription Locator Function; Signalling flows and protocol details [3GPP TS 29.228 V6.8.0 and 3GPP TS 29.229 V6.6.0, modified]" (note 1) [16] 3GPP TS 32.240: ETSI ES 282 010: "Telecommunications and "Telecommunication management; Internet Converged Services and Protocols for Charging management; Charging Advanced Networking (TISPAN); Charging architecture and principles". (Endorsement of 3GPP TS 32.240 Release 7, 3GPP TS 32.260 Release 7, 3GPP TS 32.297 Release 7, 3GPP TS 32.298 Release 7 and 3GPP TS 32.299 Release 7 modified)" (note 1) m [11B] 3GPP TS 29.163: "Interworking between the IP Multimedia (IM) Core Network (CN) subsystem and Circuit Switched (CS) networks". UAK-S: NGN Ic Interface Ausgabestand: V1.0.0 vom 15.10.2014 n/a n/a n/a Seite 27 von 98 Spec_UAKS_NGN_Ic_Interface_V1_0_0.docx Replaced references by ETSI TS 124 503 Relevant for UAK-S NGN Ic Interface [17] 3GPP TS 32.260: "Telecommunication management; Charging management; IP Multimedia Subsystem (IMS) charging". ETSI ES 282 010: "Telecommunications and Internet Converged Services and Protocols for Advanced Networking (TISPAN); Charging [Endorsement of 3GPP TS 32.240 Release 7, 3GPP TS 32.260 Release 7, 3GPP TS 32.297 Release 7, 3GPP TS 32.298 Release 7 and 3GPP TS 32.299 Release 7modified]" (note 1) n/a [19] 3GPP TS 33.203: "Access security for IP based services". (note 2) n/a References in 3GPP TS 24.229 [67] draft-rosenberg-sipping-acr-code-00 IETF RFC 5079 (December 2007): "Rejecting (November 2005): "Rejecting Anonymous Requests in the Session Initiation Anonymous Requests in the Session Protocol (SIP)". Initiation Protocol (SIP)". o [68] draft-jennings-sip-voicemail-uri-05 (November 2005): "Session Initiation Protocol (SIP) URIs for Applications such as Voicemail and Interactive Voice Response (IVR)". [69] draft-ietf-ecrit-service-urn-06 (March 2007): "A Uniform Resource Name (URN) for Services". [79] draft-ietf-rohc-sigcomp-sip-07 (July 2007): "Applying Signaling Compression (SigComp) to the Session Initiation Protocol (SIP)". o IETF RFC 4458: "Session Initiation Protocol (SIP) URIs for Applications such as Voicemail and Interactive Voice Response (IVR)" (note 1) RFC 5031 (January 2008): "A Uniform Resource Name (URN) for Services". n/a RFC 5049 (December 2007): "Applying Signaling Compression (SigComp) to the Session Initiation Protocol (SIP)". n/a [85] 3GPP2 C.S0005-D (March 2004): "Upper Layer (Layer 3) Signalling Standard for cdma2000 Standards for Spread Spectrum Systems". (note 2) n/a [86] 3GPP2 C.S0024-A v1.0 (April 2004): "cdma2000 High Rate Packet Data Air Interface Standard". (note 2) n/a [87] ITU-T Recommendation J.112, "Transmission Systems for Interactive Cable Television Services" (note 2) n/a [88] PacketCable Release 2 Technical Report, PacketCable™ Architecture Framework Technical Report, PKT-TRARCH-FRM. (note 2) n/a [89] draft-ietf-sip-location-conveyance08 (July 2007): "Session Initiation Protocol Location Conveyance". draft-ietf-sip-location-conveyance-10 (February 2008): "Location Conveyance for the Session Initiation Protocol". c2 [91] draft-ietf-ecrit-requirements-13 (March 2007): "Requirements for Emergency Context Resolution with Internet Technologies". RFC 5012 (January 2008): "Requirements for Emergency Context Resolution with Internet Technologies". n/a [119] draft-garcia-simple-presencedictionary-06 (August 2007): "The Presence-Specific Static Dictionary for Signaling Compression (Sigcomp)". RFC 5112 (January 2008): "The Presence-Specific Static Dictionary for Signaling Compression (Sigcomp)". n/a UAK-S: NGN Ic Interface Ausgabestand: V1.0.0 vom 15.10.2014 Seite 28 von 98 Spec_UAKS_NGN_Ic_Interface_V1_0_0.docx References in 3GPP TS 24.229 note 1: note 2: c1: c2: Replaced references by ETSI TS 124 503 Relevant for UAK-S NGN Ic Interface The reference in the first column is replaced by the document listed on the right column. This replacement is applicable to all occurrences of the reference throughout the present endorsement. The reference in the first column contains 3GPP or 3GPP2 or cable specific requirements and is not generally applicable to the present endorsement. See chapter 10.5 See Table 8-4 8.3 Modifications to 3GPP TS 24.229 Table 8-3: Modified Chapter 2 References of 3GPP TS 24.229 [[43]] Relevant for UAK-S NGN Ic Interface Reference Reference Document umber 3GPP TR 21.905: "Vocabulary for 3GPP Specifications". n/a 3GPP TS 22.101: "Service aspects; Service principles". n/a [2] 3GPP TS 23.002: "Network architecture". c1 [3] 3GPP TS 23.003: "Numbering, addressing and identification". o [4] 3GPP TS 23.060: "General Packet Radio Service (GPRS); Service description; Stage 2". n/a [4A] 3GPP TS 23.107: "Quality of Service (QoS) concept and architecture". c1 [4B] 3GPP TS 23.167: "IP Multimedia Subsystem (IMS) emergency sessions". c1 [4C] 3GPP TS 23.122: "Non-Access-Stratum (NAS) functions related to Mobile Station (MS) in idle mode". c1 [5] 3GPP TS 23.218: "IP Multimedia (IM) Session Handling; IM call model". c1 [6] 3GPP TS 23.221: "Architectural requirements". c1 [7] 3GPP TS 23.228: "IP multimedia subsystem; Stage 2". c1 3GPP TS 23.234: "3GPP system to Wireless Local Area Network (WLAN) interworking; System description". n/a 3GPP TS 24.008: "Mobile radio interface layer 3 specification; Core Network protocols; Stage 3". n/a [8A] 3GPP TS 24.141: "Presence service using the IP Multimedia (IM) Core Network (CN) subsystem; Stage 3". c1 [8B] 3GPP TS 24.147: "Conferencing using the IP Multimedia (IM) Core Network (CN) subsystem; Stage 3". n/a [1] [1A] [7A] [8] UAK-S: NGN Ic Interface Ausgabestand: V1.0.0 vom 15.10.2014 Seite 29 von 98 Spec_UAKS_NGN_Ic_Interface_V1_0_0.docx Relevant for UAK-S NGN Ic Interface Reference Reference Document umber n/a [8C] 3GPP TS 24.234: "3GPP System to Wireless Local Area Network (WLAN) interworking; User Equipment (UE) to network protocols; Stage 3". [8D] Void. [8E] 3GPP TS 24.279: "Combining Circuit Switched (CS) and IP Multimedia Subsystem (IMS) services, stage 3, Release 7". n/a [8F] 3GPP TS 24.247: "Messaging service using the IP Multimedia (IM) Core Network (CN) subsystem; Stage 3". n/a [8G] 3GPP TS 24.167: "3GPP IMS Management Object (MO); Stage 3". n/a 3GPP TS 25.304: "UE Procedures in Idle Mode and Procedures for Cell Reselection in Connected Mode". n/a [9A] 3GPP TS 25.331: "Radio Resource Control (RRC); Protocol Specification". n/a [10] 3GPP TS 26.235: "Packet switched conversational multimedia applications; Default codecs". c1 [10A] 3GPP TS 27.060: "Mobile Station (MS) supporting Packet Switched Services". c1 [11] 3GPP TS 29.061: "Interworking between the Public Land Mobile Network (PLMN) supporting Packet Based Services and Packet Data Networks (PDN)". n/a [11A] 3GPP TS 29.162: "Interworking between the IM CN subsystem and IP networks". c1 [11B] 3GPP TS 29.163: "Interworking between the IP Multimedia (IM) Core Network (CN) subsystem and Circuit Switched (CS) networks". c1 [11C] 3GPP TS 29.161: "Interworking between the Public Land Mobile Network (PLMN) supporting Packet Based Services with Wireless Local Access and Packet Data Networks (PDN)" n/a [12] 3GPP TS 29.207 Release 6: "Policy control over Go interface". n/a [13] Void. [9] [13A] 3GPP TS 29.209 Release 6: "Policy control over Gq interface". n/a [13B] 3GPP TS 29.212: "Policy and Charging Control over Gx reference point". n/a [13C] 3GPP TS 29.213: "Policy and charging control signalling flows and Quality of Service (QoS) parameter mapping". n/a [13D] 3GPP TS 29.214: "Policy and Charging Control over Rx reference point". n/a [14] 3GPP TS 29.228: "IP Multimedia (IM) Subsystem Cx and Dx Interfaces; Signalling flows and message contents". c1 UAK-S: NGN Ic Interface Ausgabestand: V1.0.0 vom 15.10.2014 Seite 30 von 98 Spec_UAKS_NGN_Ic_Interface_V1_0_0.docx Relevant for UAK-S NGN Ic Interface Reference Reference Document umber [15] 3GPP TS 29.229: "Cx and Dx Interfaces based on the Diameter protocol, Protocol details". c1 [16] 3GPP TS 32.240: "Telecommunication management; Charging management; Charging architecture and principles". c1 [17] 3GPP TS 32.260: "Telecommunication management; Charging management; IP Multimedia Subsystem (IMS) charging". c1 [18] 3GPP TS 33.102: "3G Security; Security architecture". n/a [19] 3GPP TS 33.203: "Access security for IP based services". c1 3GPP TS 33.210: "IP Network Layer Security". n/a [20] 3GPP TS 44.018: "Mobile radio interface layer 3 specification, Radio Resource Control Protocol". n/a [20A] RFC 2401 (November 1998): "Security Architecture for the Internet Protocol". n/a [20B] RFC 1594 (March 1994): "FYI on Questions and Answers to Commonly asked "New Internet User" Questions". n/a [20C] Void. [20D] Void. [20E] RFC 2462 (November 1998): "IPv6 Address Autoconfiguration". n/a [20F] RFC 2132 (March 1997): "DHCP Options and BOOTP Vendor Extensions". n/a [21] RFC 2617 (June 1999): "HTTP Authentication: Basic and Digest Access Authentication". n/a [22] RFC 3966 (December 2004): "The tel URI for Telephone Numbers". c2 [23] RFC 2833 (May 2000): "RTP Payload for DTMF Digits, Telephony Tones and Telephony Signals". m [24] RFC 3761 (April 2004): "The E.164 to Uniform Resource Identifiers (URI) Dynamic Delegation Discovery System (DDDS) Application (ENUM)". n/a [25] RFC 2976 (October 2000): "The SIP INFO method". c3 RFC 3041 (January 2001): "Privacy Extensions for Stateless Address Autoconfiguration in IPv6". n/a [26] RFC 3261 (June 2002): "SIP: Session Initiation Protocol". m [27] RFC 3262 (June 2002): "Reliability of provisional responses in Session Initiation Protocol (SIP)". o [19A] [25A] UAK-S: NGN Ic Interface Ausgabestand: V1.0.0 vom 15.10.2014 Seite 31 von 98 Spec_UAKS_NGN_Ic_Interface_V1_0_0.docx Relevant for UAK-S NGN Ic Interface Reference Reference Document umber [27A] RFC 3263 (June 2002): " Session Initiation Protocol (SIP): Locating SIP Servers". n/a [27B] RFC 3264 (June 2002): "An Offer/Answer Model with Session Description Protocol (SDP)". m [28] RFC 3265 (June 2002): "Session Initiation Protocol (SIP) Specific Event Notification". n/a [28A] RFC 3267 (June 2002): "Real-Time Transport Protocol (RTP) Payload Format and File Storage Format for the Adaptive Multi-Rate (AMR) and Adaptive Multi-Rate Wideband (AMR-WB) Audio Codecs". o [29] RFC 3311 (September 2002): "The Session Initiation Protocol (SIP) UPDATE method". m [30] RFC 3312 (October 2002): "Integration of resource management and Session Initiation Protocol (SIP)". o [31] RFC 3313 (January 2003): "Private Session Initiation Protocol (SIP) Extensions for Media Authorization". n/a [32] RFC 3320 (March 2002): "Signaling Compression (SigComp)". n/a [33] RFC 3323 (November 2002): "A Privacy Mechanism for the Session Initiation Protocol (SIP)". m [34] RFC 3325 (November 2002): "Private Extensions to the Session Initiation Protocol (SIP) for Network Asserted Identity within Trusted Networks". m RFC 3326 (December 2002): "The Reason Header Field for the Session Initiation Protocol (SIP)". m RFC 3327 (December 2002): "Session Initiation Protocol Extension Header Field for Registering Non-Adjacent Contacts". n/a [35A] RFC 3361 (August 2002): "Dynamic Host Configuration Protocol (DHCP-for-IPv4) Option for Session Initiation Protocol (SIP) Servers". n/a [36] RFC 3515 (April 2003): "The Session Initiation Protocol (SIP) REFER method". n/a [37] RFC 3420 (November 2002): "Internet Media Type message/sipfrag". n/a [38] RFC 3608 (October 2003): "Session Initiation Protocol (SIP) Extension Header Field for Service Route Discovery During Registration". n/a [39] RFC 4566 (June 2006): "SDP: Session Description Protocol". m [40] RFC 3315 (July 2003): "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)". n/a RFC 2131 (March 1997): "Dynamic host configuration protocol". n/a RFC 3319 (July 2003): "Dynamic Host Configuration Protocol (DHCPv6) n/a [34A] [35] [40A] [41] UAK-S: NGN Ic Interface Ausgabestand: V1.0.0 vom 15.10.2014 Seite 32 von 98 Spec_UAKS_NGN_Ic_Interface_V1_0_0.docx Relevant for UAK-S NGN Ic Interface Reference Reference Document umber Options for Session Initiation Protocol (SIP) Servers". [42] RFC 3485 (February 2003): "The Session Initiation Protocol (SIP) and Session Description Protocol (SDP) static dictionary for Signaling Compression (SigComp)". n/a [43] RFC 3680 (March 2004): "A Session Initiation Protocol (SIP) Event Package for Registrations". n/a [44] Void. [45] Void. [46] Void. [47] Void. [48] RFC 3329 (January 2003): "Security Mechanism Agreement for the Session Initiation Protocol (SIP)". n/a [49] RFC 3310 (September 2002): "Hypertext Transfer Protocol (HTTP) Digest Authentication Using Authentication and Key Agreement (AKA)". n/a [50] RFC 3428 (December 2002): "Session Initiation Protocol (SIP) Extension for Instant Messaging". n/a [51] Void. [52] draft-drage-sipping-rfc3455bis-13 (January 2014): "Private Header (PHeader) Extensions to the Session Initiation Protocol (SIP) for the 3rdGeneration Partnership Project (3GPP)". [53] RFC 3388 (December 2002): "Grouping of Media Lines in Session Description Protocol". n/a [54] RFC 3524 (April 2003): "Mapping of Media Streams to Resource Reservation Flows". n/a [55] RFC 3486 (February 2003): "Compressing the Session Initiation Protocol (SIP)". n/a [56] RFC 3556 (July 2003): "Session Description Protocol (SDP) Bandwidth Modifiers for RTP Control Protocol (RTCP) Bandwidth". o o n/a [56A] RFC 3581 (August 2003): "An Extension to the Session Initiation Protocol (SIP) for Symmetric Response Routing". [56B] RFC 3841 (August 2004): "Caller Preferences for the Session Initiation Protocol (SIP)". o [56C] RFC 3646 (December 2003): "DNS Configuration options for Dynamic Host Configuration Protocol for IPv6 (DHCPv6)". n/a ITU-T Recommendation E.164: "The international public telecommunication numbering plan". m [57] UAK-S: NGN Ic Interface Ausgabestand: V1.0.0 vom 15.10.2014 Seite 33 von 98 Spec_UAKS_NGN_Ic_Interface_V1_0_0.docx Relevant for UAK-S NGN Ic Interface Reference Reference Document umber o [58] RFC 4028 (April 2005): "Session Timers in the Session Initiation Protocol (SIP)". [59] RFC 3892 (September 2004): "The Session Initiation Protocol (SIP) Referred-By Mechanism". n/a [60] RFC 3891 (September 2004): "The Session Inititation Protocol (SIP) "Replaces" Header". n/a [61] RFC 3911 (October 2004): "The Session Inititation Protocol (SIP) "Join" Header". n/a [62] RFC 3840 (August 2004): "Indicating User Agent Capabilities in the Session Initiation Protocol (SIP)" n/a [63] RFC 3861 (August 2004): "Address Resolution for Instant Messaging and Presence". n/a RFC 3948 (January 2005): "UDP Encapsulation of IPsec ESP Packets". n/a [64] RFC 4032 (March 2005): "Update to the Session Initiation Protocol (SIP) Preconditions Framework". n/a [65] RFC 3842 (August 2004) "A Message Summary and Message Waiting Indication Event Package for the Session Initiation Protocol (SIP)" o [65A] RFC 4077 (May 2005): "A Negative Acknowledgement Mechanism for Signaling Compression". n/a [66] RFC 7044 (February 2014): "An Extension to the Session Initiation Protocol (SIP) for Request History Information". Note 1: The history information header shall not be discarded. Note 2: This reference shall only be used for CDIV; all other features are ffs. m [67] draft-ietf-sip-acr-code-05 (July 2007): "Rejecting Anonymous Requests in the Session Initiation Protocol (SIP)".Editor's note: The above document cannot be formally referenced until it is published as an RFC. c1 [68] RFC 4458 (January 2006): "Session Initiation Protocol (SIP) URIs for Applications such as Voicemail and Interactive Voice Response (IVR)". c1 [69] draft-ietf-ecrit-service-urn-06 (March 2007): "A Uniform Resource Name (URN) for Services".Editor's note: The above document cannot be formally referenced until it is published as an RFC. c1 [70] RFC 3903 (October 2004): "An Event State Publication Extension to the Session Initiation Protocol (SIP)". o [71] Void. [72] RFC 3857 (August 2004): "A Watcher Information Event Template Package for the Session Initiation Protocol (SIP)". [63A] UAK-S: NGN Ic Interface Ausgabestand: V1.0.0 vom 15.10.2014 n/a Seite 34 von 98 Spec_UAKS_NGN_Ic_Interface_V1_0_0.docx Relevant for UAK-S NGN Ic Interface Reference Reference Document umber [73] [74] RFC 3856 (August 2004): "A Presence Event Package for the Session Initiation Protocol (SIP)". o [74A] RFC 3603 (October 2003): "Private Session Initiation Protocol (SIP) Proxy-to-Proxy Extensions for Supporting the PacketCable Distributed Call Signaling Architecture". n/a RFC 4662 (August 2006): "A Session Initiation Protocol (SIP) Event Notification Extension for Resource Lists". n/a [77] draft-ietf-sipping-config-framework-12 (May 2007): "A Framework for Session Initiation Protocol User Agent Profile Delivery". Editor's note: The above document cannot be formally referenced until it is published as an RFC. n/a [78] RFC 4575 (August 2006): "A Session Initiation Protocol (SIP) Event Package for Conference State". c5 [79] draft-ietf-rohc-sigcomp-sip-07 (July 2007): "Applying Signaling Compression (SigComp) to the Session Initiation Protocol (SIP)".Editor's note: The above document cannot be formally referenced until it is published as an RFC. c1 [80] RFC 3825 (July 2004): "Dynamic Host Configuration Protocol Option for Coordinate-based Location Configuration Information". n/a [81] Void. [82] RFC 4457 (April 2006): "The Session Initiation Protocol (SIP) P-UserDatabase Private-Header (P-header)". n/a [83] RFC 4145 (September 2005): "TCP-Based Media Transport in the Session Description Protocol (SDP)". n/a [84] RFC 4320 (January 2006): "Actions Addressing Identified Issues with the Session Initiation Protocol's (SIP) Non-INVITE Transaction". n/a [85] 3GPP2 C.S0005-D (March 2004): "Upper Layer (Layer 3) Signaling Standard for cdma2000 Standards for Spread Spectrum Systems". c1 [86] 3GPP2 C.S0024-A v1.0 (April 2004): "cdma2000 High Rate Packet Data Air Interface Standard". c1 [87] ITU-T Recommendation J.112, "Transmission Systems for Interactive Cable Television Services" c1 [88] PacketCable Release 2 Technical Report, PacketCable™ Architecture Framework Technical Report, PKT-TR-ARCH-FRM. c1 [89] draft-ietf-sip-location-conveyance-08 (July 2007): "Session Initiation Protocol Location Conveyance".Editor's note: The above document c1 [75] [76] UAK-S: NGN Ic Interface Ausgabestand: V1.0.0 vom 15.10.2014 Seite 35 von 98 Spec_UAKS_NGN_Ic_Interface_V1_0_0.docx Relevant for UAK-S NGN Ic Interface Reference Reference Document umber cannot be formally referenced until it is published as an RFC. [90] RFC 4119 (December 2005) "A Presence-based GEOPRIV Location Object Format". m [91] draft-ietf-ecrit-requirements-13 (March 2007): "Requirements for Emergency Context Resolution with Internet Technologies".Editor's note: The above document cannot be formally referenced until it is published as an RFC. c1 [92] draft-ietf-sip-outbound-10 (July 2007): "Managing Client Initiated Connections in the Session Initiation Protocol (SIP)".Editor's note: The above document cannot be formally referenced until it is published as an RFC. c3 [93] draft-ietf-sip-gruu-14 (June 2007): "Obtaining and Using Globally Routable User Agent (UA) URIs (GRUU) in the Session Initiation Protocol (SIP)". Editor's note: The above document cannot be formally referenced until it is published as an RFC. n/a [94] draft-ietf-sipping-gruu-reg-event-08 (October 2006): "Reg Event Package Extension for GRUUs". Editor's note: The above document cannot be formally referenced until it is published as an RFC. n/a [95] draft-mahy-iptel-cpc-04 (August 2006): "CPC tel URI". Editor's note: The above document cannot be formally referenced until it is published as an RFC. c3 [96] RFC 4168 (October 2005): "The Stream Control Transmission Protocol (SCTP) as a Transport for the Session Initiation Protocol (SIP)". n/a [97] draft-camarillo-sipping-profile-key-02 (June 2007): "The Session Initiation Protocol (SIP) P-Profile-Key Private Header (P-Header)". [98] ETSI ES 283 035: "Telecommunications and Internet Converged Services and Protocols for Advanced Networks (TISPAN); Network Attachment Sub-System (NASS); e2 interface based on the DIAMETER protocol". n/a [99] draft-ietf-mmusic-ice-17 (July 2007): "Interactive Connectivity Establishment (ICE): A Protocol for Network Address Translator (NAT) Traversal for Offer/Answer Protocols". Editor's note: The above document cannot be formally referenced until it is published as an RFC. n/a [100] draft-ietf-behave-rfc3489bis-09 (August 2007): "Session Traversal Utilities for (NAT) (STUN)". Editor's note: The above document cannot be formally referenced until it is published as an RFC. o [101] draft-ietf-behave-turn-04 (July 2007): "Traversal Using Relays around NAT (TURN): Relay Extensions to Session Traversal Utilities for NAT (STUN)". Editor's note: The above document cannot be formally referenced until it n/a UAK-S: NGN Ic Interface Ausgabestand: V1.0.0 vom 15.10.2014 o Seite 36 von 98 Spec_UAKS_NGN_Ic_Interface_V1_0_0.docx Relevant for UAK-S NGN Ic Interface Reference Reference Document umber is published as an RFC. [102] draft-ietf-sip-ice-option-tag-02 (June 2007): "Indicating Support for Interactive Connectivity Establishment (ICE) in the Session Initiation Protocol (SIP)". Editor's note: The above document cannot be formally referenced until it is published as an RFC. n/a [103] RFC 4967 (July 2007): "Dial String Parameter for the Session Initiation Protocol Uniform Resource Identifier". n/a [104] draft-ietf-sip-uri-list-message-01: "Multiple-Recipient MESSAGE Requests in the Session Initiation Protocol (SIP)". Editor's note: The above document cannot be formally referenced until it is published as an RFC. o [105] draft-ietf-sip-multiple-refer-01: "Referring to Multiple Resources in the Session Initiation Protocol (SIP)". Editor's note: The above document cannot be formally referenced until it is published as an RFC. n/a [106] draft-ietf-sip-uri-list-conferencing-01: "Conference Establishment Using Request-Contained Lists in the Session Initiation Protocol (SIP)". Editor's note: The above document cannot be formally referenced until it is published as an RFC. n/a [107] draft-ietf-sip-uri-list-subscribe-01: "Subscriptions to Request-Contained Resource Lists in the Session Initiation Protocol (SIP)". Editor's note: The above document cannot be formally referenced until it is published as an RFC. n/a [108] RFC 4583 (November 2006): "Session Description Protocol (SDP) Format for Binary Floor Control Protocol (BFCP) Streams". n/a [109] draft-ejzak-sipping-p-em-auth-04 (June 2007): "Private Header (PHeader) Extension to the Session Initiation Protocol (SIP) for Authorization of Early Media". Editor's note: The above document cannot be formally referenced until it is published as an RFC. c3 [110] RFC 4354 (January 2006): "A Session Initiation Protocol (SIP) Event Package and Data Format for Various Settings in Support for the Push-toTalk over Cellular (PoC) Service". n/a [111] draft-allen-sipping-poc-p-answer-state-header-05 (March 2007): "The PAnswer-State Header Extension to the Session Initiation Protocol for the Open Mobile Alliance Push to talk over Cellular". Editor's note: The above document cannot be formally referenced until it is published as an RFC. n/a [112] Void c3 [113] Void. [114] Void. UAK-S: NGN Ic Interface Ausgabestand: V1.0.0 vom 15.10.2014 Seite 37 von 98 Spec_UAKS_NGN_Ic_Interface_V1_0_0.docx Relevant for UAK-S NGN Ic Interface Reference Reference Document umber [115] Void. [116] Void c3 [117] draft-ietf-sip-fork-loop-fix-05 (March 2007): "Addressing an Amplification Vulnerability in Session Initiation Protocol (SIP) Forking Proxies c3 [118] RFC 4896 (June 2007): "Signaling Compression (SigComp) Corrections and Clarifications". n/a [119] draft-garcia-simple-presence-dictionary-06 (August 2007): "The Presence-Specific Static Dictionary for Signaling Compression (Sigcomp)".Editor's note: The above document cannot be formally referenced until it is published as an RFC. c1 [120] draft-rosenberg-sip-app-media-tag-01 (July 2007): "A Session Initiation Protocol (SIP) Media Feature Tag for MIME Application Sub-Types". Editor's note: The above document cannot be formally referenced until it is published as an RFC. m [121] draft-drage-sipping-service-identification-01 (July 2007): "A Session Initiation Protocol (SIP) Extension for the Identification of Services". Editor's note: The above document cannot be formally referenced until it is published as an RFC. o c1: c2: c3: c4: c5: see Table 8-2 The rules defined in chapter 7 are valid. see Table 8-4 IF Table 8-5/24 OR Table 8-5/12 THEN o ELSE n/a (SUBSCRIBE, NOTIFY Request) IF Table 9-1/5 THEN m ELSE o (CONF) UAK-S: NGN Ic Interface Ausgabestand: V1.0.0 vom 15.10.2014 Seite 38 von 98 Spec_UAKS_NGN_Ic_Interface_V1_0_0.docx Additionally, the following References of 3GPP TS 24.229 [[44]] (Release 9) are required: Table 8-4: Parts of modified Chapter 2 References of 3GPP TS 24.229 [[43]](Release 9) Relevant for UAK-S NGN Ic Interface Reference Reference Document umber [25] RFC 6086 (January 2011): " Session Initiation Protocol (SIP) INFO Method and Package Framework". o [89] RFC 6442 (December 2011): "Location Conveyance for the Session Initiation Protocol" m [92] RFC 5626 (October 2009): "Managing Client Initiated Connections in the Session Initiation Protocol (SIP)". n/a [95] draft-patel-dispatch-cpc-oli-parameter-03 (June 2010): "Uniform Resource Identifier (URI) Parameters for indicating the Calling Party's Category and Originating Line Information". Editor's note: The above document cannot be formally referenced until it is published as an RFC. (Note 1) m [109] RFC 5009 (September 2009): “Private Header (P-Header) Extension to the Session Initiation Protocol (SIP) for Authorization of Early Media“ (Note 2) o [112] RFC 4694 (October 2006): "Number Portability Parameters for the 'tel' URI", see reference list in document [[4]] c1 [116] RFC 4412 (February 2006): "Communications Resource Priority for the Session Initiation Protocol (SIP)". o [117] RFC 5393 (December 2008): "Addressing an Amplification Vulnerability in Session Initiation Protocol (SIP) Forking Proxies". m [125] RFC 5360 (October 2008): "A Framework for Consent-Based Communications in the Session Initiation Protocol (SIP)". n/a [126] draft-ietf-cuss-sip-uui-10 (April 2013): "A Mechanism for Transporting User to User Call Control Information in SIP". m [126A] draft-ietf-cuss-sip-uui-isdn-04 (May 2012): “Interworking ISDN Call Control User Information with SIP” m [133] RFC 5502 (April 2009): "The SIP P-Served-User Private-Header (PHeader) for the 3GPP IP Multimedia (IM) Core Network (CN) Subsystem". n/a [134] draft-vanelburg-sipping-private-network-indication-02 (July 2008): "The Session Initiation Protocol (SIP) P-Private-Network-Indication PrivateHeader (P-Header)". Editor's note: The above document cannot be formally referenced until it is published as an RFC. n/a [140] draft-dawes-sipping-debug-02 (February 2010): "Private Extension to the Session Initiation Protocol (SIP) for Debugging". Editor's note: The above document cannot be formally referenced until it is published as an RFC. n/a UAK-S: NGN Ic Interface Ausgabestand: V1.0.0 vom 15.10.2014 Seite 39 von 98 Spec_UAKS_NGN_Ic_Interface_V1_0_0.docx Relevant for UAK-S NGN Ic Interface Reference Reference Document umber [158] RFC 5373 (November 2008): "Requesting Answering Modes for the Session Initiation Protocol (SIP)". n/a [162] draft-kaplan-dispatch-session-id-00 (December 2009): "A Session Identifier for the Session Initiation Protocol (SIP)". Editor's note: The above document cannot be formally referenced until it is published as an RFC. n/a [173] RFC 4488 (May 2006): "Suppression of Session Initiation Protocol (SIP) REFER Method Implicit Subscription". n/a c1: only rn as global-rn and npdi parameters according to chapter 7 shall be used. Note 1: See also Annex D. Note 2: Usage according to clause 10.2. UAK-S: NGN Ic Interface Ausgabestand: V1.0.0 vom 15.10.2014 Seite 40 von 98 Spec_UAKS_NGN_Ic_Interface_V1_0_0.docx 8.4 Profiling of ETSI TS 124 503 / 3GPP TS 24.229 ANNEX A The IBCF is used as B2BUA and therefore for the profiling of TS 124 503 [[3]] / TS 24.229 [[43]] only the role of a UA as shown in [[4]], Table A.2 is valid. 8.4.1 Supported Methods on the Ic-Interface A Method Request (e.g. INVITE request) is the Method itself. A Method Response is the Response (e.g. 1xx) sent as a result of a Request. The following SIP Methods shall be supported on the NNI: The following table is an endorsement of [[43]], Table A.5 in chapter A.2.1.3 Table 8-5: Supported Methods Item 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 c1: c2: PDU Reference in [[43]] Sending ACK request [26] 13 m BYE request [26] 15.1 m BYE response [26] 15.1 m CANCEL request [26] 9 m CANCEL response [26] 9 m INFO request [26] 13 c2 INFO response [26] 13 c2 INVITE request [26] 13 m INVITE response [26] 13 m MESSAGE request [50] 4 n/a MESSAGE response [50] 4 n/a NOTIFY request [28] 7.1.2 c1 NOTIFY response [28] 7.1.2 c1 OPTIONS request [26] 11 o OPTIONS response [26] 11 o PRACK request [27] 6 o PRACK response [27] 6 o PUBLISH request [70] 6 c1 PUBLISH response [70] 5 c1 REFER request [36] 2 n/a REFER response [36] 2 n/a REGISTER request [26] 10 n/a REGISTER response [26] 10 n/a SUBSCRIBE request [28] 7.1.1 c1 SUBSCRIBE response [28] 7.1.1 c1 UPDATE request [29] 5 m UPDATE response [29] 5 m other requests n/a other response o IF Table 9-1/3 OR Table 9-1/5 OR Table 9-1/8 OR Table 9-1/11 THEN m, ELSE n/a (CCBS & CCNR, CONF, ECT, MWI) IF Table 9-1/13 THEN m, ELSE n/a (SIP support of charging) UAK-S: NGN Ic Interface Ausgabestand: V1.0.0 vom 15.10.2014 NNI Receiving m m m m m c2 c2 m m n/a n/a c1 c1 o o o o c1 c1 n/a n/a n/a n/a c1 c1 m m n/a o Seite 41 von 98 Spec_UAKS_NGN_Ic_Interface_V1_0_0.docx 8.4.2 Supported Status-Codes on the Ic-Interface The following status-codes shall be supported on the NNI: This table is based on [[43]], Table A.6 Table 8-6: Supported Status-Codes Item 101 1 2 3 4 5 102 6 7 103 8 9 10 11 12 104 13 14 15 16 17 18 19 20 21 22 22A 23 24 25 26 27 Status-Code 1xx response 100 (Trying) 180 (Ringing) 181 (Call Is Being Forwarded) 182 (Queued) 183 (Session Progress) 2xx response 200 (OK) 202 (Accepted) 3xx response 300 (Multiple Choices) 301 (Moved Permanently) 302 (Moved Temporarily) 305 (Use Proxy) 380 (Alternative Service) 4xx response 400 (Bad Request) 401 (Unauthorized) 402 (Payment Required) 403 (Forbidden) 404 (Not Found) 405 (Method Not Allowed) 406 (Not Acceptable) 407 (Proxy Authentication Required) 408 (Request Timeout) 410 (Gone) 412 (Conditional Request Failed) 413 (Request Entity Too Large) 414 (Request-URI Too Large) 415 (Unsupported Media Type) 416 (Unsupported URI Scheme) 420 (Bad Extension) UAK-S: NGN Ic Interface Ausgabestand: V1.0.0 vom 15.10.2014 [26] 21.1 [26] 21.1.1 [26] 21.1.2 [26] 21.1.3 Sending – Status RFC Profile NNI p21 p21 c21 m c2 m c2 m Receiving – Status RFC Profile NNI p21 p21 c11 m c1 m c1 m [26] 21.1.4 [26] 21.1.5 [26] 21.2 [26] 21.2.1 [28] 7.3.1 [26] 21.3 [26] 21.3.1 [26] 21.3.2 c2 c1 p22 m c3 p23 m m m m p22 m n/a p23 n/a n/a c1 c1 p22 m c3 p23 m m m m p22 m n/a p23 c22 c22 [26] 21.3.3 m n/a m c22 [26] 21.3.4 [26] 21.3.5 [26] 21.4 [26] 21.4.1 [26] 21.4.2 [26] 21.4.3 [26] 21.4.4 [26] 21.4.5 [26] 21.4.6 m m p24 m o n/a m m m n/a n/a p24 m n/a n/a m m m m m p24 m m n/a m m m c22 c22 p24 m m (Note 2) c23 (Note 1) m m m [26] 21.4.7 [26] 21.4.8 m o m n/a m m m c23 (Note 2) [26] 21.4.9 [26] 21.4.10 [70] 11.2.1 c2 m c20 m m o m m c20 m m o [26] 21.4.11 m m m m [26] 21.4.12 m m m m [26] 21.4.13 m m m m [26] 21.4.14 m m m m [26] 21.4.15 m m m m Ref. in [[43]] Seite 42 von 98 Spec_UAKS_NGN_Ic_Interface_V1_0_0.docx Item 28 28A 29 29A 29B 30 31 32 33 34 35 36 37 38 39 40 41 41A 105 42 43 44 45 46 47 48 49 106 50 51 52 53 Status-Code 421 (Extension Required) 422 (Session Interval Too Small) 423 (Interval Too Brief) 429 (Provide Referrer Identity) 433 (Anonymity Disallowed) 480 (Temporarily Unavailable) 481 (Call/Transaction Does Not Exist) 482 (Loop Detected) 483 (Too Many Hops) 484 (Address Incomplete) 485 (Ambiguous) 486 (Busy Here) 487 (Request Terminated) 488 (Not Acceptable Here) 489 (Bad Event) 491 (Request Pending) 493 (Undecipherable) 494 (Security Agreement Required) 5xx response 500 (Internal Server Error) 501 (Not Implemented) 502 (Bad Gateway) 503 (Service Unavailable) 504 (Server Time-out) 505 (Version not supported) 513 (Message Too Large) 580 (Precondition Failure) 6xx response 600 (Busy Everywhere) 603 (Decline) 604 (Does Not Exist Anywhere) 606 (Not Acceptable) UAK-S: NGN Ic Interface Ausgabestand: V1.0.0 vom 15.10.2014 [26] 21.4.16 Sending – Status RFC Profile NNI o o Receiving – Status RFC Profile NNI i i [58] 6 c7 o c7 o [26] 21.4.17 [59] 5 c4 c8 m n/a m c9 m n/a [67] 5 c14 o c14 o [26] 21.4.18 m m m m [26] 21.4.19 m m m m [26] 21.4.20 [26] 21.4.21 [26] 21.4.22 m m o m m m m m m m m m [26] 21.4.23 [26] 21.4.24 [26] 21.4.25 o m m m m m m m m m m m [26] 21.4.26 m m m m [28] 7.3.2 [26] 21.4.27 [26] 21.4.28 [48] 2 c3 m m c5 n/a m m n/a c3 m m c6 n/a m m n/a [26] 21.5 [26] 21.5.1 p25 m p25 m p25 m p25 m [26] 21.5.2 [26] 21.5.3 [26] 21.5.4 m o m m m m m m m m m m [26] 21.5.5 [26] 21.5.6 m m m m m m m m [26] 21.5.7 m m m m [30] 8 o o o o [26] 21.6 [26] 21.6.1 [26] 21.6.2 [26] 21.6.3 p26 m c10 m p26 m m m p26 m m m p26 m m m [26] 21.6.4 m m m m Ref. in [[43]] Seite 43 von 98 Spec_UAKS_NGN_Ic_Interface_V1_0_0.docx Item c1: c2: c3: c4: c5: c6: c7: c8: c9: c10: c11: c12: c13: c14: c20: c21: c22: c23: p21: p22: p23: p24: p25: p26: Sending – Status Receiving – Status RFC Profile NNI RFC Profile NNI IF A.5/9 THEN m ELSE n/a - - INVITE response. IF A.5/9 THEN o ELSE n/a - - INVITE response. IF A.4/20 THEN m ELSE n/a - - SIP specific event notification extension. IF A.5/19 OR A.5/21 THEN m ELSE n/a - - REGISTER response or SUBSCRIBE response. IF A.4/37 AND A.4/2 THEN m ELSE n/a - - security mechanism agreement for the session initiation protocol and registrar. IF A.4/37 THEN m ELSE n/a - - security mechanism agreement for the session initiation protocol. IF A.4/42 AND (A.5/9 OR A.5/23) THEN m ELSE n/a - - the SIP session timer AND (INVITE response OR UPDATE response). IF A.4/43 AND A.5/17 THEN o ELSE n/a - - the SIP Referred-By mechanism and REFER response. IF A.4/43 AND A.5/17 THEN m ELSE n/a - - the SIP Referred-By mechanism and REFER response. IF A.4/44 THEN m ELSE o - - the Session Inititation Protocol (SIP) "Replaces" header. IF A.5/9 THE m ELSE n/a - - INVITE response. IF A.3/4 THEN m ELSE o - - S-CSCF. IF A.3/1 OR A.3/2 OR A.3/4 THEN m ELSE o - - UE, P-CSCF, S-CSCF. IF ACR THEN m ELSE o - - rejecting anonymous requests in the session initiation protocol. IF A.4/41 THEN m ELSE n/a - - an event state publication extension to the session initiation protocol. IF A.5/9 OR A.5/9B or A.5/13 OR A.5/15B OR A.5/17 OR A.5/19 OR A.5/21 THEN o ELSE n/a - - INVITE response or MESSAGE response or OPTIONS response or PUBLISH response or REFER response or REGISTER response or SUBSCRIBE response. IF received then sent 480 at the outgoing interface IF received then sent 403 at the outgoing interface Status-Code Ref. in [[43]] A.6/2 OR A.6/3 OR A.6/4 OR A.6/5 - - 1xx response. A.6/6 OR A.6/7 - - 2xx response. A.6/8 OR A.6/9 OR A.6/10 OR A.6/11 OR A.6/12 OR A.6/13 - - 3xx response. A.6/14 OR A.6/15 OR A.6/16 OR A.6/17 OR A.6/18 OR A.6/19 OR A.6/20 OR A.6/21 OR A.6/22 OR A.6/22A OR A.6/23 OR A.6/24 OR A.6/25 OR A.6/26 OR A.6/27 OR A.6/28 OR A.6/28A OR A.6/29 OR A.6/29A OR A.6/29B OR A.6/30 OR A.6/31 OR A.6/32 OR A.6/33 OR A.6/34 OR A.6/35 OR A.6/36 OR A.6/436 OR A.6/38 OR A.6/39 OR A.6/40 OR A.6/41 OR A.6/41A. - 4xx response. A.6/42 OR A.6/43 OR A.6/44 OR A.6/45 OR A.6/46 OR A.6/47 OR A.6/48 OR A.6/49 - 5xx response A.6/50 OR A.6/51 OR A.6/52 OR A.6/53 - - 6xx response. Conditions c1-c21 and p21-p26 taken from ES 283 003 Note 1: Note 2: This Response is within SIP for future use defined. These Responses are sent in cases for Registration. Registration in another domain than the home domain is not allowed. Therefore a re INVITE can not be expected. UAK-S: NGN Ic Interface Ausgabestand: V1.0.0 vom 15.10.2014 Seite 44 von 98 Spec_UAKS_NGN_Ic_Interface_V1_0_0.docx 8.4.3 Support of SIP Header on the Ic-Interface The following SIP Headers shall be supported on the NNI. This table is based on [[44]], Table A.1. Table 8-7: Supported Headers Item 1 2 3 4 4a 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 22a 23 23a 23b 23c 24 24a 25 26 26a 27 28 29 30 31 32 32a Header Accept Accept-Contact Accept-Encoding Accept-Language Accept-Resource-Priority Alert-Info Allow Allow-Events Authentication-Info Authorization Call-ID Call-Info Contact Content-Disposition Content-Encoding Content-Language Content-Length Content-Type CSeq Date Error-Info Event Expires Flow-Timer From Geolocation Geolocation-Error Geolocation-Routing History-Info Info-Package In-Reply-To Join Max-Breadth Max-Forwards MIME-Version Min-Expires Min-SE Organization P-Access-Network-Info P-Answer-state UAK-S: NGN Ic Interface Ausgabestand: V1.0.0 vom 15.10.2014 NNI Reference [26] 20.1 [56B] 9.2 [26] 20.2 [26] 20.3 [116] 3.2 [26] 20.4 [26] 20.5, 5.1 [28] 7.2.2 [26] 20.6 [26] 20.7 [26] 20.8 [26] 20.9 [26] 20.10 [26] 20.11 [26] 20.12 [26] 20.13 [26] 20.14 [26] 20.15 [26] 20.16 [26] 20.17 [26] 20.18 [28] 7.2.1 [26] 20.19 [92] 10 [26] 20.20 [89] 4.1 [89] 4.4 [89] 4.2 [66] 4.1 [25] 4 [26] 20.21 [61] 7.1 [117] 5.8 [26] 20.22 [26] 20.24 [26] 20.23 [58] 5 [26] 20.25 [52] 4.4 [111] 7.1 Sending o n/a n/a n/a o c1 m n/a n/a n/a m c2 m c7 n/a n/a m m m n/a n/a c6 o n/a m m n/a n/a m o n/a n/a n/a m o n/a o n/a n/a n/a Receiving o n/a n/a n/a o c1 m n/a n/a n/a m c2 m c7 n/a n/a m m m n/a n/a c6 o n/a m m n/a n/a m o n/a n/a n/a m o n/a o o n/a n/a Seite 45 von 98 Spec_UAKS_NGN_Ic_Interface_V1_0_0.docx Item 33 33a 33b 34 35 36 36a 37 37z 38 39 39a 39b 39c 39d 39e 40 40a 40b 41 41a 42 43 44 45 46 47 48 48a 49 49a 49b 50 51 52 53 54 55 55a 56 57 58 58a 59 60 Header Reference P-Asserted-Identity P-Asserted-Service P-Associated-URI P-Called-Party-ID P-Charging-Function-Addresses P-Charging-Vector P-Debug-Id P-Early-Media P-Germany-Tariff P-Media-Authorization P-Preferred-Identity P-Preferred-Service P-Private-Network-Indication P-Profile-Key P-Served-User P-User-Database P-Visited-Network-ID Path Permission-Missing Priority Priv-Answer-Mode Privacy Proxy-Authenticate Proxy-Authorization Proxy-Require RAck Reason Record-Route Recv-Info Referred-By Refer-Sub Refer-To Reject-Contact Replaces Reply-To Request-Disposition Require Retry-After Resource-Priority Route RSeq Security-Client Security-Server Security-Verify Server [34] 9.1 [121] 4.1 [52] 4.1 [52] 4.2 [52] 4.5 [52] 4.6 [140] 13.1 [109] 9 see chapter 7.4 [31] 5.1 [34] 9.2 [121] 4.2 [134] 8 [97] 5 [133] 6 [82] 4 [52] 4.3 [35] 4 [125] 5.9.3 [26] 20.26 [158] 2 [33] 4.2 [26] 20.27 [26] 20.28 [26] 20.29 [27] 7.2 [34A] 2 [26] 20.30 [25] 5 [59] 3 [173] 4 [36] 2.1 [56B] 9.2 [60] 6.1 [26] 20.31 [56B] 9.1 [26] 20.32 [26] 20.33 [116] 3.1 [26] 20.34 [27] 7.1 [48] 2.2 [48] 2.2 [48] 2.2 [26] 20.35 UAK-S: NGN Ic Interface Ausgabestand: V1.0.0 vom 15.10.2014 NNI Sending m n/a n/a n/a n/a o(Note 2) n/a o (Note 1) o n/a n/a o n/a n/a n/a n/a n/a n/a n/a n/a n/a m n/a n/a n/a o m o o c3 n/a n/a n/a c4 n/a n/a o o o o o n/a n/a n/a n/a Receiving m n/a n/a n/a n/a o(Note 2) n/a o(Note 1) o n/a n/a o n/a n/a n/a n/a n/a n/a n/a n/a n/a m n/a n/a n/a o m o o c3 n/a n/a n/a c4 n/a n/a o o o o o n/a n/a n/a n/a Seite 46 von 98 Spec_UAKS_NGN_Ic_Interface_V1_0_0.docx Item Header Reference NNI Sending Receiving 60a Service-Route [38] 5 n/a n/a 60b Session-ID [162] 6.2 n/a n/a 61 Session-Expires [58] 4 o o 62 SIP-Etag [70] 11.3.1 n/a n/a 63 SIP-If-Match [70] 11.3.2 n/a n/a 64 Subject [26] 20.36 n/a n/a 65 Subscription-State [28] 7.2.3 c5 c5 66 Supported [26] 20.37 o o 67 Timestamp [26] 20.38 o o 68 To [26] 20.39 m m 68a Trigger-Consent [125] 5.11.2 n/a n/a 69 Unsupported [26] 20.40 o o 70 User-Agent [26] 20.41 o o 70a User-to-User [126] 4.1 m m 71 Via [26] 20.42 m m 72 Warning [26] 20.43 o o 73 WWW-Authenticate [26] 20.44 n/a n/a c1: IF Table 9-1/7 THEN m ELSE o (CW) c2: IF Table 9-1/3 THEN m ELSE n/a (CCxx) c3: IF Table 9-1/5 OR Table 9-1/8 THEN m ELSE n/a (CONF, ECT) c4: IF Table 9-1/8 THEN m ELSE n/a (ECT) c5: IF Table 8-4/12 THEN m ELSE n/a (NOTIFY request) c6: IF Table 9-1/5 THEN m ELSE n/a (CONF) c7: IF Table 10-1/4 OR Table 10-1/5 OR Table 10-1/6 THEN m ELSE IF Table 10-1/2 OR Table 10-1/3 THEN o ELSE n/a (MIME Types) Note 1: see chapter 10.2: A transit network shall forward a P-Early-Media header as received. Note 2: The usage of this parameter requires multilateral agreeements. This will be clarified in a later version of this specification. UAK-S: NGN Ic Interface Ausgabestand: V1.0.0 vom 15.10.2014 Seite 47 von 98 Spec_UAKS_NGN_Ic_Interface_V1_0_0.docx 8.4.4 Supported SDP Types Table 8-8 and Table 8-9 are based on [[43]], table A.318 and A.319, respectively. The modifications reflect the support of SDP types at the Ic– Interface as described within this document. Table 8-8: SDP Types Item Type 1 2 Sending - Status RFC Profile NNI Session level description [39] 5.1 m m [39] 5.2 m m Ref. in [[43]] Receiving – Status RFC Profile NNI v= (protocol version) m m o= (owner/creator and m m session identifier) 3 s= (session name) [39] 5.3 m m m m 4 i= (session information) [39] 5.4 o o m o 5 u= (URI of description) [39] 5.5 o n/a o n/a 6 e= (email address) [39] 5.6 o n/a o n/a 7 p= (phone number) [39] 5.6 o n/a o n/a 8 c= (connection [39] 5.7 c5 o m m information) 9 b= (bandwidth [39] 5.8 o o (NOTE 1) m m information) Time description (one or more per description) 10 t= (time the session is [39] 5.9 m m (NOTE 2) m m active) 11 r= (zero or more repeat [39] 5.10 o n/a o n/a times) Session level description (continued) 12 z= (time zone [39] 5.11 o n/a o n/a adjustments) 13 k= (encryption key) [39] 5.12 x n/a n/a n/a 14 a= (zero or more [39] 5.13 o o m m session attribute lines) Media description (zero or more per description) 15 m= (media name and [39] 5.14 o o m m transport address) 16 i= (media title) [39] 5.4 o n/a o n/a 17 c= (connection [39] 5.7 c1 c1 c1 c1 information) 18 b= (bandwidth [39] 5.8 o o (NOTE 1) o o information) 19 k= (encryption key) [39] 5.12 x n/a n/a n/a 20 a= (zero or more media [39] 5.13 o o m m attribute lines) c1: IF A.318/15 THEN m ELSE n/a. c5: IF A.318/17 THEN o ELSE m - - "c=" contained in all media description. NOTE 1: For "video" and "audio" media types that utilise RTP/RTCP, it shall be specified. For other media types, it may be specified. NOTE 2: Shall be set to 00. IF CONF is used than other values can appear but this is out of scope of this specification. UAK-S: NGN Ic Interface Ausgabestand: V1.0.0 vom 15.10.2014 Seite 48 von 98 Spec_UAKS_NGN_Ic_Interface_V1_0_0.docx Prerequisite table line Table 8-8/14 OR table line Table 8-8/20 - - a= (if at least one “a=” attribute exists ) Table 8-9: Media Attribute Lines (a=) Item Type 1 2 3 category (a=cat) keywords (a=keywds) name and version of tool (a=tool) packet time (a=ptime) maximum packet time (a=maxptime) receive-only mode (a=recvonly) send and receive mode (a=sendrecv) send-only mode (a=sendonly) Inactive mode (a=inactive) whiteboard orientation (a=orient) conference type (a=type) character set (a=charset) language tag (a=sdplang) language tag (a=lang) frame rate (a=framerate) quality (a=quality) format specific parameters (a=fmtp) rtpmap attribute (a=rtpmap) current-status attribute (a=curr) desired-status attribute (a=des) confirm-status attribute (a=conf) media stream identification attribute (a=mid) group attribute (a=group) setup attribute (a=setup) connection attribute (a=connection) 4 5 6 7 8 8A 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 UAK-S: NGN Ic Interface Ausgabestand: V1.0.0 vom 15.10.2014 Ref. in [[43]] Sending - Status Receiving - Status RFC c8 c8 c8 Profile NNI c8 c8 c8 c9 c9 c9 Profile NNI c9 c9 c9 [39] 6 [39] 6, [28A] 8 [39] 6 c10 c10 c10 c10 c11 c11 c11 c11 o o m m [39] 6 o o m m [39] 6 o o m m [39] 6 o o m m [39] 6 c10 c10 c11 c11 [39] 6 c8 c8 c9 c9 [39] 6 c8 c8 c9 c9 [39] 6 o o m m [39] 6 [39] 6 o c10 o c10 m c11 m c11 [39] 6 [39] 6 c10 c10 c10 c10 c11 c11 c11 c11 [39] 6 c10 c10 c11 c11 [30] 4 c1 n/a c2 c2 [30] 4 c1 n/a c2 c2 [30] 4 c1 n/a c2 c2 [53] 3 c3 n/a c4 n/a [53] 4 c5 n/a c6 n/a [83] 4 c7 n/a c7 n/a [83] 5 c7 n/a c7 n/a [39] 6 [39] 6 [39] 6 RFC Seite 49 von 98 Spec_UAKS_NGN_Ic_Interface_V1_0_0.docx c1: c2: c3: c4: c5: c6: c7: c8: c9: c10: c11: IF A.317/22 AND A.318/20 THEN o ELSE n/a - - integration of resource management and SIP, media level attribute name "a=". IF A.317/22 AND A.318/20 THEN m ELSE n/a - - integration of resource management and SIP, media level attribute name "a=". IF A.317/23 AND A.318/20 THEN o ELSE n/a - - integration of resource management and SIP, media level attribute name "a=". IF A.317/23 AND A.318/20 THEN m ELSE n/a - - integration of resource management and SIP, media level attribute name "a=". IF A.317/24 AND A.318/20 THEN o ELSE n/a - - integration of resource management and SIP, media level attribute name "a=". IF A.317/24 AND A.318/20 THEN m ELSE n/a - - integration of resource management and SIP, media level attribute name "a=". IF A.317/26 AND A.318/20 THEN m ELSE n/a - - integration of resource management and SIP, media level attribute name "a=". IF A.318/14 THEN o ELSE x - - session level attribute name "a=". IF A.318/14 THEN m ELSE n/a - - session level attribute name "a=". IF A.318/20 THEN o ELSE x - - media level attribute name "a=". IF A.318/20 THEN m ELSE n/a - - media level attribute name "a=". UAK-S: NGN Ic Interface Ausgabestand: V1.0.0 vom 15.10.2014 Seite 50 von 98 Spec_UAKS_NGN_Ic_Interface_V1_0_0.docx 9 Simulation Services Supported for NGN-VoiceInterconnection 9.1 Supported Services on the Interconnection Interface Support of Simulation Services on the NNI means that the related signalling information is transported transparently via the Ic interface. This is done for the simulation services listed in the table below. Table 9-1: Simulation Services Item Simulation Services Support at NNI 1 ACR & CB Anonymous Communication Rejection & Communication Barring 2 AoC Advice of Charge (Note) 3 CCBS & CCNR Completion of Communications to Busy Subscriber & Completion of Communications by No Reply o 4 CDIV Communication Diversion o 5 CONF Conference o 6 CUG Closed User Group o 7 CW Communication Waiting o 8 ECT Explicit Communication Transfer o 9 HOLD Communication Hold o 10 MCID Malicious Communication Identification 11 MWI Message Waiting Indication o 12 OIP & OIR Originating Identification Presentation & Originating Identification Restriction m 13 SIPCharging SIP Transfer of IP Multimedia Service Tariff Information c1 14 TIP & TIR Terminating Identification Presentation & Originating Identification Restriction o Note: c1: o n/a n/a AoC (2) is only applicable at the UNI. To transmit charging information on the NNI, the support of SIP-Charging (13) is necessary. see chapter 12.3 UAK-S: NGN Ic Interface Ausgabestand: V1.0.0 vom 15.10.2014 Seite 51 von 98 Spec_UAKS_NGN_Ic_Interface_V1_0_0.docx 9.2 Description of Services For the Simulation Services the references in chapter 4.1.1.4 apply. 9.2.1 CDIV The maximum of 5 diversions is allowed. Indication of an originating user is optional. The elements caused by the CDIVN service are not supported on the NNI. The “Diversion” header shall not be used. 9.2.2 OIP/OIR No special requirements beyond that defined within chapter 8 on the NNI needed. 9.2.3 TIP/TIR No special requirements beyond that defined within clause 8 on the NNI needed. 9.2.4 HOLD No special requirements beyond that defined within chapter 8 on the NNI needed. 9.2.5 ACR&CB No special requirements beyond that defined within chapter 8 on the NNI needed. 9.2.6 ECT The Interworking of the REFER Request to an INVITE shall be done by the serving network operator. See chapter 4.7.2.9.7 of ETSI TS 124 628 [[27]] for details. 9.2.7 CONF The Interworking of the REFER Request to an INVITE shall be done by the serving network operator. See chapter 4.7.2.9.7 of ETSI TS 124 628 [[27]] for details. The event package “conference” and the Event header shall be supported 9.2.8 CUG No special requirements beyond that defined within chapter 8 and 10.2.2 on the NNI needed. 9.2.9 MWI The event package name "message-summary" in the SUBSCRIBE and NOTIFY request shall be supported. 9.2.10 MCID MCID is not applicable on the Ic interface (see also chapter 5.1.4). 9.2.11 Call Completion The event package name "call-completion" and the Call-Info header field with a purpose parameter set to 'call-completion' and the m parameter set to "BS" or “NR” or “NL” shall be supported. UAK-S: NGN Ic Interface Ausgabestand: V1.0.0 vom 15.10.2014 Seite 52 von 98 Spec_UAKS_NGN_Ic_Interface_V1_0_0.docx Note: Since Call Completion on Not Logged-In (CCNL) is a 3GPP Release 10 feature, the support of [[28]] is mandatory for using CCNL. 9.2.12 CW No special requirements beyond that defined within clause 8 on the NNI needed. 9.2.13 UUS UUS is not a simulation service. The standardisation work is still ongoing. 9.2.14 Emergency Calls (Notruf) The transmission of information accompanying the emergency call (e.g. emergency caller location, supplier recognition) is for further study. UAK-S: NGN Ic Interface Ausgabestand: V1.0.0 vom 15.10.2014 Seite 53 von 98 Spec_UAKS_NGN_Ic_Interface_V1_0_0.docx 10 Bearer Aspects 10.1 Bearer Services Fax and Modem transmission via G.711a shall be supported as default setting. Two optional alternatives are proposed: (i) T.38: MIME Type: image (RFC 3362) using UDPTL (only for Fax) (ii) V.152 in transparent mode 10.2 Bearer Control 10.2.1 Through Connection of the Media Path (speech/data transmission) 10.2.1.1 General Remarks The following chapters describe the establishment of the transmission path with respect to the offer/answer procedure and the early-media handling. The usage of the P-Early-Media header is an option. All statements made regarding P-Early-Media header are conform to [[9]]. Although the through connection is done based on local policies it is described for the purpose of clarifying the relation between charging and establishing the transmission path. Please consider that the originating and terminating network discard the P-Early-Media header received from the not trusted user equipment. If the destination network sends an SDP information with 18x this network or a trusted UE connected to it is responsible to play appropriate tones or announcements. UAK-S: NGN Ic Interface Ausgabestand: V1.0.0 vom 15.10.2014 Seite 54 von 98 Spec_UAKS_NGN_Ic_Interface_V1_0_0.docx 10.2.1.2 Scenarios described 10.2.1.2.1 Remarks and Symbols used The B-subscriber is trusted concerning early media := the early media in backward direction is already available in the early dialogue in the destination network. The B-subscriber is not trusted concerning early media := the early media in backward direction is not available in the early dialogue in the destination network. Scenario 4 is only successful if the P-Early-Media header is supported across all involved networks. Scenario 4 (bidirectional media channel before 200 OK available in the originating network) applies only if this was explicitly covered by a contract which was approved by the originating operator. Figure 10-1: Symbols used UAK-S: NGN Ic Interface Ausgabestand: V1.0.0 vom 15.10.2014 Seite 55 von 98 Spec_UAKS_NGN_Ic_Interface_V1_0_0.docx 10.2.1.2.2 Scenario 1: Connection Set-up to User Equipment B, which is Not Trusted concerning Early Media Figure 10-2: Scenario 1: Connection set-up to user equipment B, which is not trusted concerning early media UAK-S: NGN Ic Interface Ausgabestand: V1.0.0 vom 15.10.2014 Seite 56 von 98 Spec_UAKS_NGN_Ic_Interface_V1_0_0.docx 10.2.1.2.3 Scenario 2: Connection Set-up to User Equipment B, which is Trusted concerning Early Media Figure 10-3: Scenario 2: Connection set-up to user equipment B, which is trusted concerning early media UAK-S: NGN Ic Interface Ausgabestand: V1.0.0 vom 15.10.2014 Seite 57 von 98 Spec_UAKS_NGN_Ic_Interface_V1_0_0.docx 10.2.1.2.4 Scenario 3: Connection Set-up with Tones/Announcements from the Transit-/ Destination Network Figure 10-4: Scenario 3: Connection set-up with tones/announcements from the transit-/destination network UAK-S: NGN Ic Interface Ausgabestand: V1.0.0 vom 15.10.2014 Seite 58 von 98 Spec_UAKS_NGN_Ic_Interface_V1_0_0.docx 10.2.1.2.5 Scenario 4: Originator has an Early Media Dialogue with an IVR in the Transit-/ Destination Network User Equipment A Originating Node (P-CSCF/C-BGF, A-BGF) Transit Node (IBCF/I-BGF) Transit-/TerminatingNode IVR INVITE: user B SIP/2.0 SDP TRYING INVITE: user B SIP/2.0 P-Early-Media: supported SDP INVITE: user B SIP/2.0 P-Early-Media: supported SDP INVITE: user B SIP/2.0 P-Early-Media: supported SDP 18x yyyyy P-Early-Media: sendrecv SDP 18x yyyyy P-Early-Media: sendrecv SDP 18x yyyyy P-Early-Media: sendrecv SDP 18x yyyyy P-Early-Media: sendrecv SDP Optional 200 OK 200 OK 200 OK 200 OK The blue marked signalling events are optional informations Figure 10-5: Scenario 4: Originator has an early media dialogue with an IVR in the transit-/destination network 10.2.1.3 Description of the Procedures Early media is a speech/data transmission in the early dialogue. It is not desirable that unauthorized early media is gated to the user equipments. The user equipment in the originating and terminating network is responsible for the “offer/answer exchange” and therefore for the establishment of the media path. Consequently the user equipment establishes the media path by offer/answer exchange. Independent of the offer/answer exchange the network(s) controls this media path and connects through the media path as recommended in this clause below. UAK-S: NGN Ic Interface Ausgabestand: V1.0.0 vom 15.10.2014 Seite 59 von 98 Spec_UAKS_NGN_Ic_Interface_V1_0_0.docx 10.2.1.3.1 Actions required at the Origination Network Three scenarios in the originating network are possible according to the standards: • The offer is available in the initial INVITE; the answer is available in a provisional response. • The offer is available in the initial INVITE; the answer is available in the 200 OK final response. • The offer is available in the 200 OK final response; the answer is available in the ACK. Within the scope of this specification, the third bullet item is not desired. That means that the SDP answer should be available at least in the 200 OK INVITE. As a basic requirement the through-connection of the media path shall be completed in backward and forward direction between the networks as soon as an SDP answer is available based on the information delivered, the originating network has no knowledge whether early media is authorized or not (see Figure 10-6 case A). The transmission path is completed in the forward and backward direction between the user equipment in the originating and destination network on receipt of a 200 OK to the INVITE request from the destination network (see Figure 10-6 case E). If media are modified with subsequent SDP offer-answer exchanges during the call establishment or while the call is confirmed, any updates of the transmission path required to support the adjusted media should be performed when the new SDP offer-answer exchange is completed. If the originating network supports the early media authorization according to the requirements in RFC 5009: • A P-Early-Media header is present in the initial INVITE request set to ‘supported’ • When a P-Early-Media header is received in a provisional response, the early media is authorized according to the value of the received P-Early-Media header towards the user equipment (see Figure 10-6 case B, C and D).The through connection in forward direction shall be completed based on bilateral agreements If early media authorization according to the requirements in RFC 5009 is not supported, the originating network has to trust the early media handling in the terminating network and the transmission path is controlled only with the information received in the SDP towards the user equipment (see Figure 10-6 case A and case E). UAK-S: NGN Ic Interface Ausgabestand: V1.0.0 vom 15.10.2014 Seite 60 von 98 Spec_UAKS_NGN_Ic_Interface_V1_0_0.docx Figure 10-6: Signalling events and media handling in the originating network. 10.2.1.3.2 Actions required at an Intermediate National Network (Transit) The establishment of the transmission path in forward and backward direction is completed via the transit network as soon as an SDP answer is available. If the intermediate national network supports the procedures of RFC 5009 it can selectively open or close the media gate(s) corresponding to an authorized early media as indicated in the P-Early-Media header. The intermediate national network sends a P-Early-Media header as received. If media are modified with subsequent SDP offer-answer exchanges during the call establishment or while the call is ongoing, any updates of the transmission path required to support the adjusted media should be performed when the new SDP offer-answer exchange is completed If Tones and Announcements are applicable the MRF sends an SDP that contains an ‘a’ attribute set to ‘sendonly’ and UAK-S: NGN Ic Interface Ausgabestand: V1.0.0 vom 15.10.2014 Seite 61 von 98 Spec_UAKS_NGN_Ic_Interface_V1_0_0.docx if the destination network receives a P-Early-Media header set to ‘supported’ in the initial INVITE request and if the early media authorization according to the requirements in RFC 5009 is supported, a P-Early-Media header is present in the 18x provisional response set to ‘sendonly’ (see Figure 10-7 case B). Media path enabled IBCF I-BGF INVITE: user B SIP/2.0 P-Early-Media: supported SDP 18x yyyyyy P-Early-Media: xxx SDP IBCF I-BGF INVITE: user B SIP/2.0 P-Early-Media: supported SDP 18x yyyyyy P-Early-Media: xxx SDP Media path disabled INVITE: user B SIP/2.0 P-Early-Media: supported SDP 18x yyyyyy P-Early-Media: xxx SDP Media in forward direction Media in forward direction Media in forward direction Media in backward direction Media in backward direction Media in backward direction CASE A Announ. 18x yyyyyy P-Early-Media: sendonly SDP 18x yyyyyy P-Early-Media: sendonly SDP Media in forward direction Media in forward direction Media in backward direction Media in backward direction CASE B IVR 18x yyyyyy P-Early-Media: sendrecv SDP 18x yyyyyy P-Early-Media: sendrecv SDP Media in forward direction Media in forward direction Media in backward direction Media in backward direction CASE C The blue marked events are applicable if RFC 5009 is supported in the originating or terminating network Figure 10-7: Signalling events and media handling in the intermediate national network UAK-S: NGN Ic Interface Ausgabestand: V1.0.0 vom 15.10.2014 Seite 62 von 98 Spec_UAKS_NGN_Ic_Interface_V1_0_0.docx 10.2.1.3.3 Actions required at the Termination Network Since the terminating network has the knowledge based on local policies whether early media in forward or backward direction is authorized it is responsible whether the media stream in the early dialogue is allowed and is gated from/to the terminating user equipment. The scenarios for the “offer/answer exchange” as described in clause 10.2.1.3.1 are also applicable in this section. The establishment of the transmission path in the early dialogue is suppressed towards the called party. Based on local policies if the destination user is trusted regarding early media, the through-connection of the media path will be completed in the backward direction as soon as an SDP answer from the SIP user equipment at the called party’s side is available. If the destination network receives a P-Early-Media header set to ‘supported’ in the initial INVITE request and if the early media authorization according to the requirements in RFC 5009 is supported, a P-EarlyMedia header is present in the 18x provisional response set to ‘sendonly’ (see Figure 10-8 case B). Based on local policies if the destination user is not trusted regarding early media, the through-connection of the media path is suppressed towards the calling party user equipment (see Figure 10-8 case A). If the destination network receives a P-Early-Media header set to ‘supported’ in the initial INVITE request and if the early media authorization according to the requirements in RFC 5009 is supported, a P-EarlyMedia header is present in the 18x provisional response set to ‘inactive’. When the called party answers with a 200 OK INVITE, the destination network shall connect through the transmission path to the terminating user in forward and backward direction and the ringing tone is removed if applicable. A 200 OK to the preceding exchange is sent (see Figure 10-7 case A and case B). If media are modified with subsequent SDP offer-answer exchanges during the call establishment or while the call is ongoing, any updates of the transmission path required to support the adjusted media should be performed when the new SDP offer-answer exchange is completed. If Tones and Announcements are applicable the MRF sends an SDP that contains an ‘a’ attribute set to ‘sendonly’ and if the destination network receives a P-Early-Media header in the initial INVITE request set to ‘supported’ and if the early media authorization according to the requirements in RFC 5009 is supported, a P-Early-Media header is present in the 18x provisional response set to ‘sendonly’ (see Figure 10-8 case C). UAK-S: NGN Ic Interface Ausgabestand: V1.0.0 vom 15.10.2014 Seite 63 von 98 Spec_UAKS_NGN_Ic_Interface_V1_0_0.docx IBCF P-CSCF I-BGF INVITE: user B SIP/2.0 P-Early-Media:supported SDP 18x yyyyy P-Early-Media: inactive SDP Media in forward direction Media in backward direction 200 OK INVITE Media in forward direction Media in backward direction UE-B Non trusted C-BGF A-BGF INVITE: user B SIP/2.0 P-Early-Media:supported SDP INVITE: user B SIP/2.0 SDP 18x yyyyy SDP 18x yyyyy P-Early-Media: inactive SDP CASE A Media in forward direction Media in backward direction 200 OK INVITE 200 OK INVITE Media in forward direction Media in backward direction UE-B trusted 18x yyyyy P-Early-Media: sendonly SDP Media in forward direction Media in backward direction 200 OK INVITE Media in forward direction Media in backward direction 18x yyyyy SDP 18x yyyyy P-Early-Media: sendonly SDP CASE B Media in forward direction Media in backward direction 200 OK INVITE 200 OK INVITE Media in forward direction Media in backward direction Announ. 18x yyyyy P-Early-Media: sendonly SDP Media in forward direction Media in backward direction 18x yyyyy P-Early-Media: sendonly SDP CASE C Media in forward direction Media in backward direction Media path enabled Media path disabled IVR 18x yyyyy 18x yyyyy P-Early-Media: sendrecv SDP Media in forward direction Media in backward direction CASE D P-Early-Media: sendrecv SDP Media in forward direction Media in backward direction The blue marked events are applicable if RFC 5009 is supported in the originating or terminating network Figure 10-8: Signalling events and media handling in the terminating network UAK-S: NGN Ic Interface Ausgabestand: V1.0.0 vom 15.10.2014 Seite 64 von 98 Spec_UAKS_NGN_Ic_Interface_V1_0_0.docx 10.2.1.3.4 Overview of the Media Handling in the Relevant Network Types The figure below gives an overview of the media handling in the originating, transit and terminating network. Figure 10-9: Signalling events and media handling in the originating, transit and terminating network UAK-S: NGN Ic Interface Ausgabestand: V1.0.0 vom 15.10.2014 Seite 65 von 98 Spec_UAKS_NGN_Ic_Interface_V1_0_0.docx 10.2.2 MIME Type Handling For the Ic interface it is necessary to define the various SIP message bodies amongst SIP functionalities (e.g. methods, header, parameter, numbering formats) in order to reach a minimum interoperability at the Ic-interface between two IBCF or B2BUA. The IBCF shall support following content types in SIP: Table 10-1: MIME Type Handling Item Content Type Ref. Usage 1 application/SDP [39] SDP m 2 application/ISUP [[29]] Encapsulating of ISUP in MIME bodies o 3 multipart/mixed [[29]] Transport of multiple, different MIME types in a MIME body m 4 application/vnd.etsi.pstn+xml [[44]] Transport of PSTN/ISDN information o 5 application/x-session-info [[30]] Digit for Overlap o 6 application/vnd.etsi.sci+xml [[22]] SIP support of charging information c1 7 application/simple-messagesummary+xml [65] Transport of MWI information c2 8 message/sipfrag [37] SUBCRIBE/NOTIFY mechanism c3 9 application/vnd.etsi.cug+xml [[20]] Transport of CUG information c4 10 application/call-completion [[31]] Transport of CCBS and CCNR information c5 11 application/pidf+xml [[32]] Transport of CCBS and CCNR information m 12 application/conferenceinfo+xml [78] Transport of CONF information c6 13 application/emergencyCall.Pr oviderInfo+xml [[33]] Transport of additional data for emergency calls m c1: c2: c3: c4: c5: c6: Support at NNI IF Table 9-1/13 THEN m ELSE o (SIP-Charging) IF Table 9-1/11 THEN m ELSE o (MWI) IF Table 8-5/24 OR Table 8-5/12 THEN o ELSE n/a (SUBSCRIBE, NOTIFY Request) IF Table 9-1/6 THEN m ELSE o (CUG) IF Table 9-1/3 THEN m ELSE o (CCxx) IF Table 9-1/5 THEN m ELSE o (CONF) According to [[43]], chapter 5.10.6.3 the IBCF can screen the SIP message body and handle it according to network policies. UAK-S: NGN Ic Interface Ausgabestand: V1.0.0 vom 15.10.2014 Seite 66 von 98 Spec_UAKS_NGN_Ic_Interface_V1_0_0.docx 10.3 Tones and Announcements 10.3.1 Actions required at the Origination Network If the originating network receives an 18x with SDP then it has to connect the backward path. However, if the originating network receives a P-Early-Media-header indicating that inband information is available and the early media authorization according the requirements in RFC 5009 is supported, it shall rather throughconnect the bearer in backward direction. 10.3.2 Actions required at an Intermediate National Network (Transit) The intermediate network shall pass tones and announcements in backward and forward direction once the bearer is through-connected. Please refer also to clause 10.2.1.3.2. 10.3.3 Actions required at the Terminating Network If the terminating network sends an 18x with SDP then it has to send a ring back tone or early media to the originating network. The terminating network may insert tones and announcements in backward or forward direction as applicable once the early media is authorized. If it inserts tones and announcements, it may provide a P-Early-Media-header indicating that inband information is available in SIP signalling towards the originating network and if the early media authorization according to the requirements in RFC 5009 is supported. Please refer to clause 10.2.1.3.3. 10.3.4 Media Clipping Media Clipping can occur in certain scenarios. However, no feasible solution has been standardised yet. 10.4 Codecs A successful setup to all targets is guaranteed only in that case, when at least the G.711a-Codec with a packet-size of 20 ms is included in the SDP-offer. This does not necessarily apply for ISDN data services, where the negotiation of clearmode channel according to RFC 4040 [[7]] is sufficient and precondition for a successful connection. 10.5 IP Version, IP Header Interworking and Fragmentation Version 4 or 6 of the internet protocol is used for NGN interconnection according to AKNN concept paper [[52]]. The interworking shall be done according to [[46]]. Fragmentation of VoIP (RTP) packets is not supported on the NNI. UAK-S: NGN Ic Interface Ausgabestand: V1.0.0 vom 15.10.2014 Seite 67 von 98 Spec_UAKS_NGN_Ic_Interface_V1_0_0.docx 11 Forward Address Signalling There is no consensus about a single dialling procedure to be used in Germany. Amongst the Forward Address Signalling methods, the following two variants are preferred: The en bloc forward signalling (see chapter 11.1) and the Multiple Invite Overlap Signalling method in combination with en bloc forward address signalling (see chapter 11.2). The choice of using one of these procedures over the Icinterface will be basis for bilateral agreements. 11.1 Variant 1: En Bloc Forward Address Signalling only En bloc procedure shall be used. 11.2 Variant 2: Multiple Invite Method in Combination with En Bloc Forward Address Signalling As long as subscribers are using overlap signalling, there is a need for a solution to deal with this scenario within SIP networks. If all addressable numbers would have a length known by the originating network, overlap-to-en-bloc conversion would solve this scenario. With respect to e.g. private branch exchanges (PBX) with extended dial-in range, the overlap-to-en-bloc conversion would lead to a post dial delay, because the originating network does not know the end of dialling until the last interdigit timer interval timed out. The Multiple Invite method according to annex C.2.2 shall be used. Please note that this procedure also includes the en bloc procedure. 11.3 Remarks about the Usage of both Variants in Interconnection Scenarios In case that a transit network allows as a receiving entity to use the Multiple Invite method and has to terminate such call attempts towards a network allowing the en bloc forward signalling only this transit network has to perform an overlap-to-en bloc conversion function as described in [[4]] chapter 4.9.3 ff and annex N.3. Please be aware that this also applies to possible cases of several transit networks. The conversion shall be applied by the last network in the chain supporting the Multiple Invite method. Also, in case of a direct interconnection between two operators using different dialling procedures, the overlap-to-en bloc conversion shall be performed by the network supporting the Multiple Invite method, i.e. the originating network. The basic problem to be solved by this procedure is the determination of the end of dialling. Two possibilities are described by 3GPP: First based on the knowledge of the dialling plan and second based on a timer supervision. To use the knowledge of the dialling plan only the (last) transit network operator or (depending on the exact interconnection scenario) the originating network operator needs to have full information about the length of all valid subscriber numbers to be received including PBX numbers. In case the timer solution is selected to determine the end of dialling the preconditions described in [[4]] have to be met. UAK-S: NGN Ic Interface Ausgabestand: V1.0.0 vom 15.10.2014 Seite 68 von 98 Spec_UAKS_NGN_Ic_Interface_V1_0_0.docx This includes the following scenario: Figure 11-1: Example: Conversion from Multiple Invite method to En Bloc method Please be aware that the network performing the overlap-to-en bloc conversion has to be capable of receiving several parallel INVITE methods with the same Call-ID and From header but different CSeq IDs for the same call attempt. Also the routing of these parallel INVITE methods has to be ensured via the same network entities (Case: message 3 and 4)! UAK-S: NGN Ic Interface Ausgabestand: V1.0.0 vom 15.10.2014 Seite 69 von 98 Spec_UAKS_NGN_Ic_Interface_V1_0_0.docx 12 Charging Aspects 12.1 Begin of Charging When the originating network receives a 200 OK indicating the requested session establishment has been completed, the transmission path shall be connected through in both directions. If the originating network is the network controlling charging, charging shall begin if applicable. The ACK method shall not be used for the determination of the begin of charging. 12.2 End of Charging When the originating network receives a BYE indicating that the established session has to be released, the transmission path shall be released in both directions. If the originating network is the network controlling charging, charging shall be terminated, if applicable. 12.3 SIP Support of Charging See [[51]] To support Advice of Charge for destinations in offline charging the SIP Transfer of IP Multimedia Service Tariff Information [[22]] shall be supported to convey tariff information provided by a Charge Determination Point via network boundaries. 13 Roaming Currently Roaming of SIP-subscribers in fixed public networks is not supported. 14 Emergency Calls The TR-Notruf [[53]] has been published in June 2011. For mobile networks, an extended location description [[54]] was released from BNetzA in April 2013. These documents contain several new requirements for emergency calls, which are briefly summarized in sub-clause 14.1. Depending on the respective technology (PSTN or NGN) of the Public Safety Answering Point (PSAP), a different encoding for the number format as well as for the additional information is used. The respective number format is clause 14.2; the transmission of the additional information is described in clause 14.3. Exemplary encodings can be found in clause 14.4. Finally, emergency calls for Voice Service Providers (VSP) are described in clause 14.5. Please note that the specification process has to be finished until the first PSAP will be migrated to NGN technology. 14.1 Requirements for Emergency Calls Emergency calls shall be routed to the corresponding PSAP which is dependent on the origin of the emergency call. This origin is a geographical area which is identified by the official municipal identifier for emergency calls (“Amtlicher Gemeindeschlüssel Notruf“, AGS_N). Furthermore, additional information has to be transmitted to the PSAP for an emergency call. This additional information contains the actual location of the emergency caller, which can either be transmitted as civic location, as geographic location or, for mobile networks, as a geographic area where the caller actually camps respectively and a Service Provider ID. Until a separate Service Provider ID has been allocated, the porting identifier (Dxyz) has to be used instead. UAK-S: NGN Ic Interface Ausgabestand: V1.0.0 vom 15.10.2014 Seite 70 von 98 Spec_UAKS_NGN_Ic_Interface_V1_0_0.docx 14.2 Number Format For emergency calls to a PSTN PSAP, the format is described in sub-clause 7.1.2.2.1. For emergency calls to an NGN PSAP, the format is described in sub-clause 7.1.2.2.2. 14.3 Transmission of Additional Information The originating network operator shall set up the additional information and transit network operator shall transmit the additional information transparently. The additional information can be transported in a SIP Geolocation Header Field PIDF-LO xml body as described in sub-clause 14.3.2 and/or in a SIP User-to-User Header described in sub-clause 14.3.1 using the same address format (e.g. civic location) SIP User-to-User Header field as for the network provided SIP Geolocation Header Field PIDF-LO. including Field as for the including Possible scenarios how the additional information can be transmitted from an originating network operator (oTNB) to the PSAP dependent on the respective technologies of both the oTNB and the PSAP (i.e. PSTN or NGN, respectively) are described in the following Table 14-1. Table 14-1: Scenarios for the transmission of additional information (informative) PSAP PSTN NGN PSTN UUI parameter (Note1) UUI header (Note1) NGN (Note2) Geolocation including PIDF-LO UUI header Geolocation including PIDF-LO UUI header oTNB Note1: According to clause 8.1.3.3 of TR-Notruf [[53]], for circuit switched telephone lines connected via ISDN switching equipment, no location information needs to be set up until the end of its operating time. Note2: It is allowed to transmit only the PIDF format in case that a service provider takes care of providing the necessary information in the appropriate format to the PSAP. The additional information in the (network provided) SIP Geolocation Header Field including PIDF-LO xml body is seen as master information. Exemplary encodings for a civic and a geographic location are both shown in sub-clause 14.4. 14.3.1 SIP UUI Header Field The necessary UUI encoding is specified by Annex N3 of TR-Notruf [[53]] and is extended for mobile networks in [[54]]. Even though the UUI SIP Header Field could carry more characters, the maximum number of characters defined by Annex N3 of TR-Notruf [[53]] shall not be exceeded, even if a truncation of an address might be necessary. In order to transport this information in SIP, the respective bits shall be concatenated in hexadecimal encoding and set into the User-to-User SIP Header Field. According to clause 9 of draft-ietf-cuss-sip-uui-isdn-04 [126A], the protocol discriminator is used as the first octet of the User-to-User 1 SIP Header field. Both the parameter name and the length indicator will subsequently be added by the MGC into the ISUP UUI container (see clause 7.4.21.1.2 of 3GPP TS 29.163). The “encoding”-Parameter can optionally be set to “hex”. Even though this parameter is not present, the encoding must be assumed 1 Number of octets to follow the length indicator (not counting the length indicator itself) UAK-S: NGN Ic Interface Ausgabestand: V1.0.0 vom 15.10.2014 Seite 71 von 98 Spec_UAKS_NGN_Ic_Interface_V1_0_0.docx as the default for this package (see draft-ietf-cuss-sip-uui-isdn-04 [126A]), which is “hex”. The same holds for the “purpose”-Parameter, where interworking with the ISDN UUI Service must be assumed if missing, i.e. purpose=isdn-uui is the default value. 14.3.1.1 General The actual location information can either be transmitted as civic (see sub-clause 14.3.1.2) or geographic location (see sub-clause 0). A differentiation between these two formats is achieved by a descriptor in Octet 6. The following parameters according to Table 14-2 information for both a geographic and a civic location. have to be transmitted alongside the location Table 14-2: General UUI Information Elements Content Data-Type Value Range Octets Sub-clause in [[53]] N3-A.1 User-user information Binary 0010 0000 1 element identifier (Note 1) Length of user-user contents Binary 6-32 2 N3-A.2 Protocol discriminator Binary 3 N3-A.3 Provider ID Hexadecimal 4 characters 4 to 5 N3-A.4 Description of location Hexadecimal 2 characters 6 N3-A.5 information Note 1: In ISUP, the ‘parameter name’ is coded with H’20, i.e. binary 0010 0000 according to Table 5 of ITU-T Q.763 [[34]]. On a DSS1 interface, the encoding of this parameter is H’7E, i.e. binary 0111 1110 according to Figure 4-36 of ITU-T Q.931 [[35]]. Please note that according to sub-clause 3.6.1 of ITU-T Recommendation Q.763 [[34]] only the body of the User-to-User information parameter (i.e. protocol discriminator and user-information field) are coded identically to ITU Recommendation Q.931 [[35]]. For further details, please refer to the respective sub-clauses of Annex N3 of TR-Notruf [[53]] as indicated in the last column. 14.3.1.2 Civic Location A civic location contains a street name (at most the first 21 characters), a house number and the postcode. Optionally, a house number suffix can also be transmitted. The encoding is described in Table 14-3. Table 14-3: UUI Encoding of a Civic Location Sub-clause in [[53]] N3-A.6.2.3 Content Data-Type Value Range Octets Street name ASCII House number Decimal 13 to 33 (max.) 10 to 11 N3-A.6.2.2 House number suffix Postcode ASCII Decimal up to 21 characters 4 digits 0–9 1 character 5 digits 0–9 12 7 to 9 N3-A.6.2.1 The 7 bit ASCII character shall be mapped into bits 1 to 7 of the octet. Bit 8 of the octet (MSB) shall be set to “0”. For further details, please refer to the respective sub-clauses of Annex N3 of TR-Notruf [[53]] as indicated in the last column. UAK-S: NGN Ic Interface Ausgabestand: V1.0.0 vom 15.10.2014 Seite 72 von 98 Spec_UAKS_NGN_Ic_Interface_V1_0_0.docx 14.3.1.3 Geographic Location Different geographic location formats are defined in Table 14-4. Table 14-4: UUI Encoding of a Geographic Location Geographic Location Format Ellipsoid Point Ellipsoid Point with Uncertainty Ellipse Polygon Ellipsoid Arc Reference coordinates Coverage area and Description of radio cell Octets Sub-clause in 7 to 12 7 to 16 7 to 31 7 to 18 7 to 12 7 to 18 [[53]] N3-A.6.1.1 [[53]] N3-A.6.1.2 [[53]] N3-A.6.1.3 [[53]] N3-A.6.1.4 [[54]] N3-A.6.4.2 [[54]] N3-A.6.4.1 For further details, please refer to the respective sub-clauses of Annex N3 of TR-Notruf [[53]] or Vfg Nr. 14/2013 [[54]] as indicated in the last column. For information on how to code the respective location elements to transmit them in the respective SIP UUI Header Field (or, later on, in the ISUP UUI container), please refer to clause 6 of 3GPP TS 23.032 [[38]]. 14.3.2 SIP Geolocation Header Field The SIP Geolocation Header field is defined in RFC 6442 [89]. RFC 4119 [90] defines so called Presence Information Data Format – Location Objects (PIDF-LO) which are used by RFC 6442 [89]. Further PIDF-LO types are defined by RFC 5139 [[36]]. General information on how to constrain, represent and interpret locations in a PIDF-LO are described in RFC 5491 [[37]]. Multiple location objects shall be supported. 14.3.2.1 General The actual location information can either be transmitted as civic (see sub-clause 14.3.2.2) or geographic location (see sub-clause 0). The service provider ID according to Table 14-5 shall be transmitted alongside the location information for both a geographic and a civic location. Table 14-5: Service Provider ID Content Service Provider ID Data-Type Hexadecimal Value Range 4 characters Reference [[53]] The IETF Draft draft-ietf-ecrit-additional-data-11 [[33]] shall be used to transmit the service provider ID. Table 14-6: Additional Data Parameters Parameter Anbieterkennung/Portierungskennung Data Provider (=”BNetzA”) UAK-S: NGN Ic Interface Ausgabestand: V1.0.0 vom 15.10.2014 SIP (Additional Data) ProviderID DataProviderString ProviderIDSeries TypeOfProviderID ContactURI Seite 73 von 98 Spec_UAKS_NGN_Ic_Interface_V1_0_0.docx The PIDF-LO types “tuple”, “device” und “person” shall be used according to Table 14-7. Table 14-7: Usage of PIDF-LO types PIDF-LO type Description tuple used for location information determined and sent by the network device used for location information determined and sent by the end device person used for location information entered by the user and sent by the end device c1: IF location information is sent from end device THEN m ELSE n/a Support m c1 c1 If the PIDF-LO types “device” or “person” are present in a SIP message, they shall also be forwarded transparently. 14.3.2.2 Civic Location A civic location transmitted in the SIP Geolocation Header can contain more information as defined for the User-to-User container in ISUP (see sub-clause 14.3.1). For the emergency call originating network provider, the only mandatory location information elements for a civic location are Country, A1 (State) and A3 (Town Name). However, any further location information needed to fully describe the civic location shall also be transmitted in the corresponding PIDF-LO Element. The encoding is described in Table 14-8 and is based on RFC 4119 [90] and RFC 5139 [[36]]. Table 14-8: PIDF-LO Encoding of a Civic Location PIDF-LO Content Example Element Land nach ISO 3166 DE Country Bundesland HE A1 Landkreisname Darmstadt A2 Gemeindename Darmstadt A3 Ortsteilname A4 Amtlicher Gemeindeschlüssel Notruf 06 4 11 000a A5 (AGS N) Straßenname ohne HeinrichA6 Zusatz HertzZusatz zu Straßenname Str. STS Data-Type UTF-8 string UTF-8 string UTF-8 string UTF-8 string UTF-8 string c1 UTF-8 string c1 UTF-8 string Hausnummer 3 Integer HNS Hausnummer Zusatz -7 UTF-8 string FLR UNIT ROOM BLD LMK LOC c1: Postleitzahl 64295 Parametertype m m c1 m c1 UTF-8 string HNO PC Value Range “DE” Integer c1 4 digits 0–9 c1 c1 5 digits 0–9 c1 Stockwerk 4 UTF-8 string c1 Einheit D1 UTF-8 string c1 Raumnummer 4.D1.14 UTF-8 string c1 Gebäude UTF-8 string c1 Name des Deutsche UTF-8 string c1 Unternehmens Telekom Zusätzliche TZ RheinUTF-8 string c1 Informationen Main IF appropriate data for the respective PIDF-LO Element is needed to fully describe the civic location, THEN m, ELSE n/a UAK-S: NGN Ic Interface Ausgabestand: V1.0.0 vom 15.10.2014 Seite 74 von 98 Spec_UAKS_NGN_Ic_Interface_V1_0_0.docx 14.3.2.3 Geographic Location The SIP Geolocation Header Field can also be used to transmit a geographic location. Therefore, the Geography Markup Language (GML), which is an application of XML, is used. According to Annex I4 of TR-Notruf [[53]], the following different geographic location formats as defined in Table 14-9 may be used. Table 14-9: Encoding of a Geographic Location Geographic Location Format Reference clause / annex in RFC 5491 [[37]] TR-Notruf [[53]] RFC 5491 [[37]] This document Point Geographische Koordinate 5.2.1 14.3.2.3.1 Ellipse Geographische Koordinate mit Unsicherheitsellipse 5.2.4 14.3.2.3.2 Polygon Polygon 5.2.2 14.3.2.3.3 Arc Band Gebiet mittels Kreisringsegment 5.2.5 14.3.2.3.4 n/a Beschreibung der Funkzelle n/a 14.3.2.3.5 A description and an encoding example for each of these different formats are given in the following subclauses. Requirements on how to transmit a Mobile Radio Cell Identification and a Confidence value (which can both be used independently of the actual geographic location format) can be found in sub-clauses 14.3.2.3.6 and 14.3.2.3.7. Please note that these descriptions and examples are in accordance with 3GPP TS 23.032 [[39]] and OGC 06-142r1 [[40]]. 14.3.2.3.1 Point 14.3.2.3.1.1 Description The description of a point is that of a point on the surface of the ellipsoid, and consists of a latitude and a longitude. In practice, such a description can be used to refer to a point on the Earth’s surface, or close to the Earth’s surface, with the same longitude and latitude. In order to transmit the height of a point, the altitude may additionally be given as description. Figure 14-1 illustrates a point on the surface of the ellipsoid and its coordinates. Figure 14-1: Description of a point as two coordinates The latitude is the angle between the equatorial plane and the perpendicular to the plane tangent to the ellipsoid surface at the point. Positive latitudes correspond to the North hemisphere. The longitude is the angle between the half-plane determined by the Greenwich meridian and the half-plane defined by the point and the polar axis, measured eastward. UAK-S: NGN Ic Interface Ausgabestand: V1.0.0 vom 15.10.2014 Seite 75 von 98 Spec_UAKS_NGN_Ic_Interface_V1_0_0.docx 14.3.2.3.1.2 Exemplary Encoding A point may be specified using either ETRS89 (latitude, longitude) or ETRS89 (latitude, longitude, altitude). This is shown in the following examples: <gml:Point srsName="urn:ogc:def:crs:EPSG::4258" xmlns:gml="http://www.opengis.net/gml"> <gml:pos>-34.407 150.883</gml:pos> </gml:Point> <gml:Point srsName="urn:ogc:def:crs:EPSG::4937" xmlns:gml="http://www.opengis.net/gml"> <gml:pos>-34.407 150.883 24.8</gml:pos> </gml:Point> 14.3.2.3.2 Ellipse 14.3.2.3.2.2 Description The ellipse is characterised by the coordinates of a point (the origin), distances r1 and r2 and an angle of orientation A. It describes formally the set of points on the ellipsoid which fall within or on the boundary of an ellipse with semi-major axis of length r1 oriented at angle A (0 to 180°) measure clockwise from north and semi-minor axis of length r2, the distances being the geodesic distance over the ellipsoid, i.e., the minimum length of a path staying on the ellipsoid and joining the two points, as shown in Figure 14-2. As for the point, this can be used to indicate points on the Earth’s surface, or near the Earth’s surface, of same latitude and longitude. The confidence level with which the position of a target entity is included within this set of points is also included with this shape. The typical use of this shape is to indicate a point when its position is known only with a limited accuracy, but the geometrical contributions to uncertainty can be quantified. North angle, A semi-major axis, r1 semi-minor axis, r2 Figure 14-2: Description of an Ellipse UAK-S: NGN Ic Interface Ausgabestand: V1.0.0 vom 15.10.2014 Seite 76 von 98 Spec_UAKS_NGN_Ic_Interface_V1_0_0.docx 14.3.2.3.2.2 Exemplary Encoding The following example shows an ellipse. <gs:Ellipse srsName="urn:ogc:def:crs:EPSG::4937" xmlns:gs="http://www.opengis.net/pidflo/1.0" xmlns:gml="http://www.opengis.net/gml"> <gml:pos> 42.5463 -73.2512 26.3 </gml:pos> <gs:semiMajorAxis uom="urn:ogc:def:uom:EPSG::9001"> 7.7156 </gs:semiMajorAxis> <gs:semiMinorAxis uom="urn:ogc:def:uom:EPSG::9001"> 3.31 </gs:semiMinorAxis> <gs:orientation uom="urn:ogc:def:uom:EPSG::9102"> 142 </gs:orientation> </gs:Ellipse> 14.3.2.3.3 Polygon 14.3.2.3.3.1 Description A polygon is an arbitrary shape described by an ordered series of points (in the example pictured in Figure 14-3, A to E). The minimum number of points allowed is 3, and the maximum number of points allowed is 15. The points shall be connected in the order that they are given. A connecting line is defined as the line over the ellipsoid joining the two points and of minimum distance (geodesic). The last point is connected to the first. The list of points shall respect a number of conditions: • a connecting line shall not cross another connecting line; • two successive points must not be diametrically opposed on the ellipsoid. The described area is situated to the right of the lines with the downward direction being toward the Earth’s centre and the forward direction being from a point to the next. C B E A D Figure 14-3: Description of a Polygon Note: This definition does not permit connecting lines greater than roughly 20 000 km. If such a need arises, the polygon can be described by adding an intermediate point. UAK-S: NGN Ic Interface Ausgabestand: V1.0.0 vom 15.10.2014 Seite 77 von 98 Spec_UAKS_NGN_Ic_Interface_V1_0_0.docx 14.3.2.3.3.2 Exemplary Encoding The following example shows a polygon that is specified using EPSG 4258 and the gml:pos element. No altitude is included in this example, indicating that altitude is unknown. <gml:Polygon srsName="urn:ogc:def:crs:EPSG::4258" xmlns:gml="http://www.opengis.net/gml"> <gml:exterior> <gml:LinearRing> <gml:pos>42.556844 -73.248157</gml:pos> <gml:pos>42.549631 -73.237283</gml:pos> <gml:pos>42.539087 -73.240328</gml:pos> <gml:pos>42.535756 -73.254242</gml:pos> <gml:pos>42.542969 -73.265115</gml:pos> <gml:pos>42.553513 -73.262075</gml:pos> <gml:pos>42.556844 -73.248157</gml:pos> </gml:LinearRing> </gml:exterior> </gml:Polygon> The following alternative example shows the same polygon with a constant altitude included that is specified using EPSG 4937 and the gml:posList element. <gml:Polygon srsName="urn:ogc:def:crs:EPSG::4937" xmlns:gml="http://www.opengis.net/gml"> <gml:exterior> <gml:LinearRing> <gml:posList> 42.556844 -73.248157 36.6 42.549631 -73.237283 36.6 42.539087 -73.240328 36.6 42.535756 -73.254242 36.6 42.542969 -73.265115 36.6 42.553513 -73.262075 36.6 42.556844 -73.248157 36.6 </gml:posList> </gml:LinearRing> </gml:exterior> </gml:Polygon> The gml:posList element is interpreted as a list with the dimension of the CRS indicating how many values are required for each point. 14.3.2.3.4 Arc Band 14.3.2.3.4.1 Description An arc band is a shape characterised by the coordinates of a point o (the origin), inner radius r1 2 (gs:innerRadius), uncertainty radius r2 (gs:outerRadius), both radii being geodesic distances over the surface of the ellipsoid, the offset angle θ (gs:startAngle) between the first defining radius of the arc band and North, and the included angle β (gs:openingAngle) being the angle between the first and second defining radii. The offset angle is within the range of 0° to 359,999b° while the included angle is within the range from 0,000b1° to 360°. This is to be able to describe a full circle, 0° to 360°. 2 Thus the outer radius is r1+r2. UAK-S: NGN Ic Interface Ausgabestand: V1.0.0 vom 15.10.2014 Seite 78 von 98 Spec_UAKS_NGN_Ic_Interface_V1_0_0.docx North Point (o) θ β r1 r2 Figure 14-4: Description of an Arc Band This shape definition can also be used to describe a sector (inner radius equal to zero), a circle (included angle equal to 360°) and other circular shaped areas. 14.3.2.3.4.2 Exemplary Encoding The following example includes an arc band shape. This Arc Band starts at 266 degrees and has a 120 degree opening; therefore, the end of the Arc Band is at a 26 degree bearing. <gs:ArcBand srsName="urn:ogc:def:crs:EPSG::4258" xmlns:gs="http://www.opengis.net/pidflo/1.0" xmlns:gml="http://www.opengis.net/gml"> <gml:pos> 42.5463 -73.2512 </gml:pos> <gs:innerRadius uom="urn:ogc:def:uom:EPSG::9001"> 1661.55 </gs:innerRadius> <gs:outerRadius uom="urn:ogc:def:uom:EPSG::9001"> 2215.4 </gs:outerRadius> <gs:startAngle uom="urn:ogc:def:uom:EPSG::9102"> 266 </gs:startAngle> <gs:openingAngle uom="urn:ogc:def:uom:EPSG::9102"> 120 </gs:openingAngle> </gs:ArcBand> UAK-S: NGN Ic Interface Ausgabestand: V1.0.0 vom 15.10.2014 Seite 79 von 98 Spec_UAKS_NGN_Ic_Interface_V1_0_0.docx 14.3.2.3.5 Description of radio cell A radio cell can either be geographically described as: • balance point of the area of the radio cell (see sub-clause 14.3.2.3.5.1) or as • unique description of the radio cell (see clause 14.3.2.3.6). 14.3.2.3.5.1 Balance Point of the Area of the Radio Cell The balance point of the area of the radio cell can be described using the latitude and longitude of the geographic coordinates of the balance point of the coverage area. The description of the dimension of the radio cell can be realized using an ellipse referring to the balance point of the radio cell according to clause 14.3.2.3.2. 14.3.2.3.6 Mobile Radio Cell identification The following statements are in accordance with 3GPP TS 23.003 [[39]]. The Location Area Identification (LAI) is composed of the following elements: • A Mobile Country Code (MCC) identifies the country in which the PLMN is located. The value of the MCC is the same as the three digit MCC contained in international mobile subscriber identity (IMSI); • a Mobile Network Code (MNC) is a code identifying the PLMN in that country. The MNC takes the same value as the two or three digit MNC contained in IMSI; Note: In Germany, the MNC is only a two digit code. According to Annex N3-A6.3.3.1 of TR-Notruf [[53]], the third digit is hard coded as hexadecimal F and • a Location Area Code (LAC) is a fixed length code (of 2 octets) identifying a location area within a PLMN. This part of the location area identification can be coded using a full hexadecimal representation except for the following reserved hexadecimal values 0000 and FFFE. The BSS and cell within the BSS are identified within a location area or routeing area by adding a Cell Identity (CI) to the location area identification, as shown in the following Figure 14-5. The CI is of fixed length with 2 octets and it can be coded using a full hexadecimal representation. The Cell Global Identification (CGI) is the concatenation of the LAI and the CI. The Cell Identity shall be unique within a location area. MCC MNC CI LAC Location Area Identification Cell Global Identification (CGI) Figure 14-5: Cell Global Identification The CGI is transmitted in a hexadecimal representation as Additional Code (ADDCODE) as a civicAddress in the PIDF-LO alongside a(n) (additional) Location Element (LOC) set to "Mobilfunkzelle" as shown in the following example: <cl:civicAddress xml:lang="de"> <cl:LOC>Mobilfunkzelle</cl:LOC> <cl:ADDCODE>26201F1080939A</cl:ADDCODE> </cl:civicAddress> The Location Element (LOC) indicates that this PIDF-LO is the identifier of a mobile radio cell. UAK-S: NGN Ic Interface Ausgabestand: V1.0.0 vom 15.10.2014 Seite 80 von 98 Spec_UAKS_NGN_Ic_Interface_V1_0_0.docx 14.3.2.3.7 Confidence According to draft-thomson-geopriv-confidence-03 [[41]], the confidence is transmitted as separate element within the location-info of the PIDF-LO. The confidence element expresses the confidence in the associated location information as a percentage and optionally includes an attribute that indicates the shape of the probability density function (PDF) of the associated region of uncertainty. Three values are possible for the shape of this PDF: unknown, normal and rectangular. Further details on how to obtain or ascertain uncertainty and confidence can be found in draft-thomsongeopriv-uncertainty-07 [[42]]. An exemplary encoding for a confidence of 75% which follows a normal distribution is shown below for a circular shape: <gp:location-info> <gs:Circle srsName="urn:ogc:def:crs:EPSG::4258"> <gml:pos>42.5463 -73.2512</gml:pos> <gs:radius uom="urn:ogc:def:uom:EPSG::9001"> 850.24 </gs:radius> </gs:Circle> <con:confidence pdf="normal">75</con:confidence> </gp:location-info> 14.4 Exemplary Encoding 14.4.1 Civic Location This sub-clause contains an exemplary encoding of excerpts of a SIP Message including SDP with location information for the civic location • Bundesland: Hessen • Landkreis: Darmstadt • Gemeinde: Darmstadt • Amtlicher Gemeindeschlüssel Notruf: 06411000a • Straße: Heinrich-Hertz-Str. • Hausnummer: 3-7 • Postleitzahl: 64295 • Stockwerk: 4 • Einheit: E2 • Raum: 4.E2.04 • Name des Unternehmens: Deutsche Telekom • Zusätzliche Informationen: TZ Rhein-Main for the transmission in the both the SIP UUI Header Field and the SIP Geolocation Header Field including the PIDF-LO format and the Service Provider ID • Service Provider ID: D150 for the transmission as additional-data, respectively. INVITE sip:[email protected]; user=phone SIP/2.0 Via: SIP/2.0/TCP 1.2.3.4:5060;branch=z9hG4bKfe07342047384 Max-Forwards: 65 To: <sip:[email protected]:5060;user=phone> From: <sip:[email protected];user=phone>;tag=a3096f28 Call-ID: [email protected] Call-Info: <cid:[email protected]>;purpose=emergencyCallData Geolocation: <cid:[email protected]> P-Asserted-Identity: <sip:[email protected];user=phone> UAK-S: NGN Ic Interface Ausgabestand: V1.0.0 vom 15.10.2014 Seite 81 von 98 Spec_UAKS_NGN_Ic_Interface_V1_0_0.docx Content-Type: multipart/mixed; boundary=boundary1 User-to-User: 001D05304692F5F3FFFF4865696E726963682D486572747A2D5374722E; encoding=hex; purpose=isdn-uui --boundary1 Content-Type: application/sdp m=audio 35564 RTP/AVP 9 8 101 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 a=ptime:20 a=sendrecv --boundary1 Content-Type: application/pidf+xml Content-ID: <[email protected]> <?xml version="1.0" encoding="UTF-8"?> <presence xmlns="urn:ietf:params:xml:ns:pidf" xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10" xmlns:cl="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr" entity="pres:[email protected]"> <tuple id="abcd123456"> <status> <gp:geopriv> <gp:location-info> <cl:civicAddress xml:lang="de"> <cl:country>DE</cl:country> <cl:A1>HE</cl:A1> <cl:A2>Darmstadt</cl:A2> <cl:A3>Darmstadt</cl:A3> <cl:A5>06411000a</cl:A5> <cl:A6>Heinrich-Hertz-</cl:A6> <cl:STS>Str.</cl:STS> <cl:HNO>3</cl:HNO> <cl:HNS>-7</cl:HNS> <cl:PC>64295</cl:PC> <cl:FLR>4</cl:FLR> <cl:UNIT>E2</cl:UNIT> <cl:ROOM>4.E2.04</cl:ROOM> <cl:LMK>Deutsche Telekom</cl:LMK> <cl:LOC>TZ Rhein-Main</cl:LOC> </cl:civicAddress> </gp:location-info> <gp:usage-rules> <gp:retransmission-allowed>yes</gp:retransmission-allowed> <gp:retention-expiry>2013-08-31T12:00:00Z</gp:retention-expiry> </gp:usage-rules> </gp:geopriv> </status> <timestamp>2013-08-01T12:00:00Z</timestamp> </tuple> </presence> --boundary1 Content-Type: application/emergencyCall.ProviderInfo+xml Content-ID: <[email protected]> <?xml version="1.0" encoding="UTF-8"?> UAK-S: NGN Ic Interface Ausgabestand: V1.0.0 vom 15.10.2014 Seite 82 von 98 Spec_UAKS_NGN_Ic_Interface_V1_0_0.docx <emergencyCall.ProviderInfo xmlns="urn:ietf:params:xml:ns:emergencyCall.ProviderInfo"> <DataProviderString>Telekom</DataProviderString> <ProviderID>D150</ProviderID> <contactURI>sip:[email protected];user=phone</contactURI> <ProviderIDSeries>BNetzA</ProviderIDSeries> </emergencyCall.ProviderInfo> --boundary1-Note 1: The two parameters “encoding” and “purpose” in the SIP UUI Header Field are optional and need not necessarily be present (see sub-clause 14.3.1.1 as well as [126] and [126A]). Both the parameter name and the length indicator (which would be 201D for the example above) are not transmitted in the SIP User-to-User Header Field and will subsequently be added by the MGC into the ISUP UUI container. 14.4.2 Ellipsoid Arc/Arc Band This sub-clause contains an exemplary encoding of excerpts of a SIP Message including SDP with location information as a geographic location as an Ellipsoid Arc for the radio tower Darmstadt-Weiterstadt • Description of Location Information: 75 (Ellipsoid arc) • Latitude: 49° 53’ 48’’ • Longitude: 08° 37’ 22’’ 3 • Inner radius: r1=0m (N = 0) • Uncertainty radius: r2=2005m (K = 56 (Hexadecimal 0x38))3 • Offset angle: θ = 328° (N=164 (Hexadecimal 0xA4); 328° ≤ θ ≤ 330°)3 • Included angle: β = 64° (N=32 (Hexadecimal 0x20); 64° ≤ β ≤ 66°)3 • Confidence: 100% requested (Hexadecimal 0x64) 3 • Mobile Country Code (MCC): 262 (Germany) • Mobile Network Code (MNC): 01F (Telekom Deutschland) • Location Area Code (LAC): 4224 (Hexadecimal 0x1080) • Cell Identity (CI): 37786 (Hexadecimal 0x939A) for the transmission in the both the SIP UUI Header Field and the SIP Geolocation Header Field including PIDF-LO format and the Service Provider ID • Service Provider ID: D124 for the transmission as additional-data, respectively. INVITE sip:[email protected]; user=phone SIP/2.0 Via: SIP/2.0/TCP 1.2.3.4:5060;branch=z9hG4bKfe07342047384 Max-Forwards: 65 To: <sip:[email protected]:5060;user=phone> From: <sip:[email protected];user=phone>;tag=a3096f28 Call-ID: [email protected] Call-Info: <cid:[email protected]>;purpose=emergencyCallData Geolocation: <cid:[email protected]> P-Asserted-Identity: <sip:[email protected];user=phone> Content-Type: multipart/mixed; boundary=boundary1 User-to-User: 001D4275943584807322000038A420640062F210010839A9; encoding=hex; purpose=isdn-uui --boundary1 Content-Type: application/sdp m=audio 49120 RTP/AVP 97 8 101 3 For information on how to convert the actual location values into the values in brackets and v.v., please refer to clause 6 of 3GPP TS 23.032. UAK-S: NGN Ic Interface Ausgabestand: V1.0.0 vom 15.10.2014 Seite 83 von 98 Spec_UAKS_NGN_Ic_Interface_V1_0_0.docx a=rtpmap:97 AMR/8000/1 a=fmtp:97 mode-change-capability=2 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15 a=ptime:20 a=sendrecv --boundary1 Content-Type: application/pidf+xml Content-ID: <[email protected]> <?xml version="1.0" encoding="UTF-8"?> <presence xmlns="urn:ietf:params:xml:ns:pidf" xmlns:gp="urn:ietf:params:xml:ns:pidf:geopriv10" xmlns:gml="http://www.opengis.net/gml" xmlns:gs="http://www.opengis.net/pidflo/1.0" xmlns:cl="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr" entity="pres:[email protected]"> <tuple id="arcband"> <status> <gp:geopriv> <gp:location-info> <gml:location> <gs:ArcBand srsName="urn:ogc:def:crs:EPSG::4326" xmlns:gs="http://www.opengis.net/pidflo/1.0" xmlns:gml="http://www.opengis.net/gml"> <gml:pos> 49.8967 8.6228 </gml:pos> <gs:innerRadius uom="urn:ogc:def:uom:EPSG::9001"> 0 </gs:innerRadius> <gs:outerRadius uom="urn:ogc:def:uom:EPSG::9001"> 2005 </gs:outerRadius> <gs:startAngle uom="urn:ogc:def:uom:EPSG::9102"> 328 </gs:startAngle> <gs:openingAngle uom="urn:ogc:def:uom:EPSG::9102"> 64 </gs:openingAngle> </gs:ArcBand> </gml:location> <con:confidence>100</con:confidence> <cl:civicAddress xml:lang="de"> <cl:LOC>Mobilfunkzelle</cl:LOC> <cl:ADDCODE>26201F1080939A</cl:ADDCODE> </cl:civicAddress> </gp:location-info> <gp:usage-rules> <gp:retransmission-allowed>yes</gp:retransmission-allowed> <gp:retention-expiry>2013-08-31T12:00:00Z</gp:retention-expiry> </gp:usage-rules> </gp:geopriv> </status> <timestamp>2013-08-01T12:00:00Z</timestamp> </tuple> </presence> UAK-S: NGN Ic Interface Ausgabestand: V1.0.0 vom 15.10.2014 Seite 84 von 98 Spec_UAKS_NGN_Ic_Interface_V1_0_0.docx --boundary1 Content-Type: application/emergencyCall.ProviderInfo+xml Content-ID: <[email protected]> <?xml version="1.0" encoding="UTF-8"?> <emergencyCall.ProviderInfo xmlns="urn:ietf:params:xml:ns:emergencyCall.ProviderInfo"> <DataProviderString>Telekom Deutschland</DataProviderString> <ProviderID>D124</ProviderID> <contactURI>sip:[email protected];user=phone</contactURI> <ProviderIDSeries>BNetzA</ProviderIDSeries> </emergencyCall.ProviderInfo> --boundary1-Note 1: The two parameters “encoding” and “purpose” in the SIP UUI Header Field are optional and need not necessarily be present (see sub-clause 14.3.1.1 as well as [126] and [126A]). Both the parameter name and the length indicator (which would be 2018 for the example above) are not transmitted in the SIP Userto-User Header Field and will subsequently be added by the MGC into the ISUP UUI container. 14.5 Emergency Calls for Voice Service Provider This topic is ffs. UAK-S: NGN Ic Interface Ausgabestand: V1.0.0 vom 15.10.2014 Seite 85 von 98 Spec_UAKS_NGN_Ic_Interface_V1_0_0.docx Annex A Address Formats (informative) A.1 Number Portability Settings: B: 0911 7654321 Ported to Provider B with Porting Identifier D987 A: 06151 1234567 Provider A DB INVITE sip: +49 911 7654321; npdi; rn = +49 D987 911 7654321 7654321 @ provider_b.de; user = phone From: <sip: +49 6151 1234567 @ provider_a.de; user = phone> To: <sip: +49 911 7654321 @ provider_a.de; user = phone> P-Asserted-Identity: <sip: +49 6151 1234567 @ provider_a.de; provider_a.de; user = phone> … Provider B DB A B Figure A-1: Number Portability with Routing Number A.2 Emergency Calls Settings: PSAP 06151CC23 A: 06151 1234567 Provider A DB INVITE sip: +49 1984 6151 23; rn = +49 6151 CC23 @ provider_b.de; user = phone From: <sip: +49 6151 1234567 @ provider_a.de; user = phone> To: <sip: 110 @ provider_a.de; user = phone> P-Asserted-Identity: <sip: +49 6151 1234567 @ provider_a.de; user = phone> … A Provider B DB B Figure A-2: Emergency Call with Routing Number UAK-S: NGN Ic Interface Ausgabestand: V1.0.0 vom 15.10.2014 Seite 86 von 98 Spec_UAKS_NGN_Ic_Interface_V1_0_0.docx Annex B SIP/SDP MIME Type Signalling on the Ic-Interface (informative) Scope: This chapter depicts some exemplary coding regarding SIP/SDP MIME Type Signalling at the Ic-Interface. For VoIP applications the following top level media types and subtypes are used 1.) Content-Type application/SDP is used according to [[51]] for SDP. Example: Content-Type: application/sdp Content-Length: 154 v=0 o=alice 2890844526 2890844526 IN IP4 client.a.example.com s=c=IN IP4 client.a.example.com t=0 0 m=audio 49172 RTP/AVP 0 a=rtpmap:0 PCMU/8000 2. ) Content-Type application/ISUP is used according to [[29]] for encapsulation of ISUP in MIME bodies. Example: Content-Type: application/ISUP; version=nxv3; base=etsi121 Content-Disposition: signal; handling=optional 01 00 49 00 00 03 02 00 07 04 10 00 33 63 21 43 00 00 03 06 0d 03 80 90 a2 07 03 10 03 63 53 00 10 0a 07 03 10 27 80 88 03 00 00 89 8b 0e 95 1e 1e 1e 06 26 05 0d f5 01 06 10 04 00 3.) Content-Type multipart/mixed is used according to [[29]] for the transport of multiple different MIME bodies in a SIP message. Example: Content-Type: multipart/mixed; boundary=unique-boundary-1 MIME-Version: 1.0 --unique-boundary-1 Content-Type: application/SDP; charset=ISO-10646 v=0 o=jpeterson 2890844526 2890842807 IN IP4 126.16.64.4 s=SDP seminar c=IN IP4 MG122.level3.com t= 2873397496 2873404696 m=audio 9092 RTP/AVP 0 3 4 --unique-boundary-1 Content-Type: application/ISUP; version=nxv3; base=etsi121 Content-Disposition: signal; handling=optional UAK-S: NGN Ic Interface Ausgabestand: V1.0.0 vom 15.10.2014 Seite 87 von 98 Spec_UAKS_NGN_Ic_Interface_V1_0_0.docx 01 00 49 00 00 03 02 00 07 04 10 00 33 63 21 43 00 00 03 06 0d 03 80 90 a2 07 03 10 03 63 53 00 10 0a 07 03 10 27 80 88 03 00 00 89 8b 0e 95 1e 1e 1e 06 26 05 0d f5 01 06 10 04 00 --unique-boundary-1— 4.) Content-Type application/vnd.etsi.pstn+xml is used according to [[44]] for the transport of PSTN/ISDN information. Example: Content-type: application/vnd.etsi.pstn+xml Content-Disposition: signal; handling=optional <?xml version="1.0" encoding="utf-8"?> <tns:PSTN xmlns:tns="http://uri.etsi.org/ngn/params/xml/simservs/pstn" xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance <tns:BearerCapability> <tns:BCoctet3> <tns:CodingStandard>00</tns:CodingStandard> <tns:InformationTransferCabability> 00000 </tns:InformationTransferCabability> </tns:BCoctet3> <tns:BCoctet4> <tns:TransferMode>00</tns:TransferMode> <tns:InformationTransferRate>10000</tns:InformationTransferRate> </tns:BCoctet4> <tns:BCoctet5> <tns:Layer1Identification>01</tns:Layer1Identification> <tns:UserInfoLayer1Protocol>10000</tns:UserInfoLayer1Protocol> </tns:BCoctet5> </tns:BearerCapability> </tns:PSTN> 5.) Content-Type application/vnd.etsi.sci+xml is used according to [[22]] in a 183 Session Progress or INFO Request to transmit tariff information on the Ic-Interface Example: Content-type: application/vnd.etsi.sci+xml <?xml version="1.0" encoding="utf-8"?> <tns:messageType xmlns:tns="http://uri.etsi.org/ngn/params/xml/simservs/sci" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"> <tns:crgt> <tns:chargingControlIndicators> <tns:immediateChangeOfActuallyAppliedTariff> 1 </tns:immediateChangeOfActuallyAppliedTariff> </tns:chargingControlIndicators> <tns:chargingTariff> <tns:tariffCurrency> <tns:currentTariffCurrency> <tns:communicationChargeSequenceCurrency> <tns:currencyFactorScale> <tns:currencyFactor>27</tns:currencyFactor> <tns:currencyScale>-7</tns:currencyScale> </tns:currencyFactorScale> UAK-S: NGN Ic Interface Ausgabestand: V1.0.0 vom 15.10.2014 Seite 88 von 98 Spec_UAKS_NGN_Ic_Interface_V1_0_0.docx <tns:tariffDuration>0</tns:tariffDuration> <tns:subTariffControl>1</tns:subTariffControl> <tns:tariffControlIndicators> 0 </tns:tariffControlIndicators> </tns:communicationChargeSequenceCurrency> </tns:currentTariffCurrency> </tns:tariffCurrency> </tns:chargingTariff> <tns:originationIdentification> <tns:networkIdentification>028207021F7F</tns:networkIdentification> <tns:referenceID>4711</tns:referenceID> </tns:originationIdentification> <tns:currency>EUR</tns:currency> </tns:crgt> </tns:messageType> 6.) Content-Type application/vnd.etsi.cug+xml is used according to [[20]] in an initial INVITE to exchange CUG data Example Content-type: application/vnd.etsi.cug+xml <?xml version="1.0" encoding="utf-8"?> <simservs xmlns= http://uri.etsi.org/ngn/params/xml/simservs/xcapu xmlns:cp="urn:ietf:params:xml:ns:common-policy" xmlns:ocp="urn:oma:xml:xdm:common-policy"> <cug> <networkIndicator>0940</networkIndicator> <cugInterlockBinaryCode>4711</cugInterlockBinaryCode> <cugCommunicationIndicator>11</cugCommunicationIndicator> </cug> </simservs> According to [[43]], chapter 5.10.6.3 the IBCF can screen the SIP message body and modify it appropriately. UAK-S: NGN Ic Interface Ausgabestand: V1.0.0 vom 15.10.2014 Seite 89 von 98 Spec_UAKS_NGN_Ic_Interface_V1_0_0.docx Annex C Forward Address Signalling (informative) C.1 General This subclause explains the overlap signalling impacts on the core entities of the IM CN subsystem. The support of overlap signalling and each of the overlap signalling method within the IM CN subsystem are optional and is dependent on the network policy. Only one overlap signalling method shall be used within one IM CN subsystem. C.2 Overlap Signalling Methods C.2.1 In-dialogue Method not applicable C.2.2 Multiple-INVITE Method C.2.2.1 General The multiple-INVITE method uses INVITE requests with the same Call ID and From header in order to transport digits (as specified in 3GPP TS 29.163 [11B]). C.3 Routing Impacts C.3.1 General If overlap signalling is supported, the IM CN subsystem needs to be configured in such a manner that erroneous routing of INVITE requests with incomplete numbers towards others entities than the corresponding INVITE requests with full numbers is avoided, for instance towards a default destination for unknown numbers such as a PSTN. Possibly impacted nodes include the S-CSCF for the UE-originated case, the transit routing function, the I-CSCF, and application servers. A misrouting can be avoided by configuring the entity sending overlap signalling in such a manner that it will send the first INVITE request with a sufficient number of digits to find a suitable entry in the translation database. If ENUM is used, the ENUM database in a typical deployment contains sufficient information about the first digits, as required to identify the destination IP domain. Therefore, ENUM is able to handle incomplete numbers in such deployments. As another alternative, the routing entity can reject calls with unknown numbers with a 404 (Not Found) response, using entries in the routing database to identify calls towards the PSTN. The S-CSCF for the UE-originated case could also forward calls with unknown numbers to the BGCF, if the BGCF is configured to reject calls to unknown destinations with a 404 (Not Found) response. C.3.2 Deterministic Routing If the multiple-INVITE method is used for overlap signalling, if an entity receives an INVITE request outside an existing dialogue with the same Call ID and From header as a previous INVITE request during a certain period of time, the entity shall route the new INVITE request to the same next hop as the previous INVITE request. Note: INVITE requests with the same Call ID and From header fields received in sequence during a certain period of time belong to the same call. The routing towards the same next hop could be achieved by an appropriately configured database or by the entity comparing the Call ID and From header fields of each INVITE request outside an existing dialogue with Call IDs and tag From header field parameters of previous INVITE requests. If the entity compares the Call ID and From header, it stores the information about received Call ID and From headers at least for a time in the order of call setup times. If paths have been established at registration time, deterministic routing will be automatic for entities on these paths. C.3.3 Digit Collection Entities performing routing decisions may require additional digits for a decision where to route an INVITE request. These entities may interact with a routing database to reach this decision. UAK-S: NGN Ic Interface Ausgabestand: V1.0.0 vom 15.10.2014 Seite 90 von 98 Spec_UAKS_NGN_Ic_Interface_V1_0_0.docx If no suitable entry in a database is found for the digits received in an INVITE request, an entity can reject the INVITE request with a 404 (Not Found) or 484 (Address Incomplete) response. This method of digit collection can be performed by a SIP proxy and is suitable both for the in-dialogue and multiple-INVITE overlap signalling methods. Replying with a 404 (Not Found) response avoids the need to keep apart incomplete and unknown numbers. The 484 (Address Incomplete) response requires the recognition of incomplete numbers. Note: An HSS does not support the recognition of incomplete numbers. A routing database being queried by ENUM also does not support the recognition of incomplete numbers. As an alternative for the in-dialogue method, the digit collection function described in annex N.2 may be invoked. It shall be performed by an entity acting as a B2BUA. The digit collection function requires the ability to recognise incomplete number. Only the clause 4.9 and ANNEX N of [[4]] is applicable for the current specification. UAK-S: NGN Ic Interface Ausgabestand: V1.0.0 vom 15.10.2014 Seite 91 von 98 Spec_UAKS_NGN_Ic_Interface_V1_0_0.docx Annex D Calling Party’s Category (normative) This annex describes the “cpc” URI parameter for use in SIP requests and is based on [95]. D.1 Introduction In ISUP, a cpc parameter is defined which characterizes the station at which a call was originated and carries other information which can describe the originating party. For example if a call is originated from a payphone a call can be handled in a specific way. When telephone numbers are contained in URIs, e.g. in tel URI or equivalent SIP URI it may be necessary to transmit any cpc associated to that telephone number. Such a method is described in this annex (see the IETF Draft given above for further details). It is an option to set up the CPC parameter. D.2 Definition The Calling Party’s Category is represented as URI parameter for the tel URI scheme and SIP URI representation of telephone numbers. The ABNF syntax is as follows and extends the formal syntax for the tel URI as specified in RFC 3966: par cpc cpc-tag cpc-value genvalue =/ cpc = cpc-tag “=” cpc-value = “cpc” = “ordinary” / “test” / “operator” / “payphone” / “unknown” / “mobile-hplmn” / “mobile-vplmn” / genvalue = 1*(alphanum / “-” / “.”) The semantics of these Calling Party’s Category values are described below: ordinary: The caller has been identified, and has no special features. test: This is a test call that has been originated as part of a maintenance procedure. operator: The call was generated by an operator position. payphone: The calling station is a payphone. unknown: The CPC could not be ascertained. mobile-hplmn: The call was generated by a mobile device in its home PLMN. mobile-vplmn: The call was generated by a mobile device in a visited PLMN. The detection of a public phone as A-party can only be done using the cpc parameter in the P-Asserted-Identity Header of an Invite-message. D.3 Transmission When received in a SIP request, the cpc parameter shall be transmitted transparently through the network and shall not be discarded. D.4 Interworking The SIP/ISUP interworking of the cpc parameter shall be done as described in 3GPP TS 29.163, Annex C. UAK-S: NGN Ic Interface Ausgabestand: V1.0.0 vom 15.10.2014 Seite 92 von 98 Spec_UAKS_NGN_Ic_Interface_V1_0_0.docx D.5 Example One example for the use of the cpc parameter is the following: Public phone (booth) NGN Service Provider Figure D-1: Example for the use of the cpc parameter Invite sip: +49 800 1234567 @ operator.de; user=phone P-Asserted-Identity: <sip:+493087654321; cpc=payphone@a-domain; user=phone> To: < sip: +49 800 1234567@a-domain; user=phone> From: “Name“<sip: +493087654321@a-domain; user=phone> …. Consider that the A-party calls a freephone number (0800 or 00800) from a payphone. It is possible to charge an additional fee (the payphone access charge, PAC) besides the delivery fee, which has to be paid by the service provider (B-party), if the call originated from a payphone. This PAC is charged as an additional fee per minute and is booked to the split second. UAK-S: NGN Ic Interface Ausgabestand: V1.0.0 vom 15.10.2014 Seite 93 von 98 Spec_UAKS_NGN_Ic_Interface_V1_0_0.docx Annex E Nationally Ported International Service Numbers (informative) To distinguish ported International Service Numbers (see chapter 7.1.2.8) from ported National Service Numbers, the following format sip: +<International Service Number> [;npdi] ;rn=+49 D<xyz> 0 <International Service Number> @ <host portion>; user=phone including an additional “0” in the rn-Parameter between Porting Identifier D<xyz> and International Service Number shall be used for ported International Service Numbers. An exemplary SIP Request URI is shown below: sip:+80012345678;npdi;[email protected];user=phone UAK-S: NGN Ic Interface Ausgabestand: V1.0.0 vom 15.10.2014 Seite 94 von 98 Spec_UAKS_NGN_Ic_Interface_V1_0_0.docx Annex F Abbreviations and Terms F.1 Abbreviations Abbreviation Explanation A-BGF Access-Border Gateway Function, definition: see C-BGF: ABNF Augmented Backus–Naur Form ACR Anonymous Communication Rejection AGS Allgemeiner Gemeindeschlüssel B2BUA Back to Back User Agent BNetzA Bundesnetzagentur BSS Base Station Subsystem C-BGF Core-Border Gateway Function CAT Customised Alerting Tone CB Communication Barring CCNL Call Completion on Not Logged-In CDIV Call Diversion Service CGI Cell Global Identification CI Cell Identity CRS Customised Ringing Tone CSCF Call Session Control Function CUG Closed User Group ECT Explicit Communication Transfer ENUM E.164 Number Mapping ffs for further study GML Geographic Markup Language HDSW Harmonised Services of Social Value (z.B. Sperrnotruf) HSS Home Subscriber Service I-BGF Interconnect Border Gateway Function IBCF Interconnect Border Control Function IC Interconnection Ic Reference Point between IBCF of two networks (Referenzpunkt zwischen IBCF zweier Netze) IMSI International Mobile Subscriber Identity Iz Reference Point between I-BGF of two networks (Referenzpunkt zwischen I-BGF zweier Netze) IVR Interactive Voice Response System Iw Reference Point between Interworking function and other networks (Referenzpunkt zwischen Interworkingfunktion und anderen IP-Netzen) UAK-S: NGN Ic Interface Ausgabestand: V1.0.0 vom 15.10.1014 Source [[3]] [[2]] [[2]] Seite 95 von 98 Spec_UAKS_NGN_Ic_Interface_V1_0_0.docx LAC Location Area Code LAI Location Area Identification MCC Mobile Country Code MGC Media Gateway Controller MNC Mobile Network Code MCID Malicious Communication Identification MIME Multipurpose Internet Mail Extensions MRF Multimedia Resource Function MSB Most Significant Bit MSV Mobilfunk Service Vorwahl MWI Message Waiting Indication NDC National Destination Code NGCN Next Generation Corporate Networks NGN Next Generation Networks NNI Network Network Interface OIP Originating Identification Presentation OIR Originating Identification Restriction ONKZ Ortsnetzkennzahl (NDC) oTNB originating Network Provider (Ursprungsteilnehmernetzbetreiber) P-CSCF Proxy CSCF PAC Payphone Access Charge PSAP Public Safety Answering Point (Notrufabfragestelle) RTCP RealTime Control Protocol SDP Session Description Protocol SIP Session Initiation Protocol THIG Topology Hiding Inter-network Gateway TIP Terminating Identification Presentation TIR Originating Identification Restriction UA User Agent URI Uniform Resource Identifier UUS User to User Signalling VLN Verkehrslenkungsnummer (routing prefix) VoNGN Voice over Next Generation Networks VPLMN Visited PLMN VSP Voice Service Provider UAK-S: NGN Ic Interface Ausgabestand: V1.0.0 vom 15.10.2014 TS 23.228 Seite 96 von 98 Spec_UAKS_NGN_Ic_Interface_V1_0_0.docx F.2 Terms Term Definition UAK-S: NGN Ic Interface Ausgabestand: V1.0.0 vom 15.10.2014 Source Seite 97 von 98 Spec_UAKS_NGN_Ic_Interface_V1_0_0.docx Annex G Das Mandat des UAK Signalisierung (informative) UAK-S: S: NGN Ic Interface Ausgabestand: V V1.0.0 vom 15.10.2014 .2014 Seite 98 von 98 Spec_UAKS_NGN_Ic_Interface_V1_0_0.docx