oder Der Weg zu All-IP und seine Tücken Markus Geller Copyright 2015 ComConsult Research GmbH, Aachen

Transkript

1 Quo vadis PSTN oder Der Weg zu All-IP und seine Tücken Markus Geller Copyright 2015 ComConsult Research GmbH, Aachen

2 Stirbt das alte PSTN wirklich? Nicht so ganz. All IP Zugang Provider A ISDN All IP Backbone Carrier A ISDN All IP Backbone Carrier B ISDN All IP Zugang Provider B

3 Warum nicht Ende zu Ende IP? Es gibt 6 konkurrierende Guidelines mit dem Ziel All IP global umzusetzen IETF/SPEERMINT i3 Forum GSMA ITU-T 3GPP IMS ATIS & SIP Forum: IP-NNI für Nord Amerika Plus einen Best Practice Provideransatz (Verizon)

4 IETF/SPEERMINT Zweck / Umfang: Lösung von SIP/SDP Problemen zwischen VoIP basierten Netzen Fokussierung auf Basic VoIP Dienste Bereitstellung einer ausreichenden Detailtiefe um Mehrdeutigkeiten zu vermeiden Beschreibung des eigentlichen SIP Signalisierungsprozesses für das NNI Spezifiziert die Anforderungen des SSP Netzwerkes als Ganzes und nicht den des eigentlichen Übergabepunktes

5 i3 Forum International Interconnect Forum for Services over IP Zweck / Umfang: Beschreibung eines Übergangs zwischen Internationalen Carrier und nationalen TDM / IP Service Provider Transport, Signalisierung, Media Unterstützung, Sicherheit, QoS, Accounting & Billing Orientiert sich am SIP RFC 3261, plus einiger weniger Erweiterungen Das aktuelle White Paper ist stark auf ISUP (ISDN User Part / SS7) fokussiert

6 GSMA Global System for Mobile Communications Alliance Service Provider Network A IPX Provider-X IPX Proxy Inter-Operator IP Backbone DNS/ ENUM IPX Provider-Y IPX Proxy Service Provider Network B Service Provider Network C Bildquelle: SIP Interconnect Guidelines, Hancock/Malas

7 ITU-T Study Group 11 Zweck / Umfang Definiert SIP/SDP Anforderungen für das NNI im Rahmen von Basis Diensten zur Sprachübertragung Dabei weniger detailliert als SPEERMINT Orientiert sich wie der i3 Vorschlag am RFC 3261, plus einiger weniger SIP/SDP Erweiterungen Liefert keine Beschreibung für Basis nahe Funktionen wie: Early Media Call-fwd Loop detection Halten, Transfer, Konferenz, usw.

8 3GPP IMS 3rd Generation Partnership Project IP Multimedia System Zweck / Umfang Identifizierung der notwendigen Voraussetzungen zum Peering von Multimedia-Anwendungen Definition von NNI Profilen, so sie benötigt werden Angestrebte Funktionen: Basis Voice, plus ca. 20 weitere Multimedia-Dienste Billing, Security, IPv4/6

9 Seit Januar 2014: ATIS & SIP Forum: IP-NNI für Nord Amerika Auszug aus der Presseerklärung der ATIS: By enabling ubiquitous IP-based interconnection, the new Task Force will support wide-scale availability of IP-based voice services, and lay the groundwork for ubiquitous advanced real-time communications such as high-definition voice, point-to-point video calling, and multimedia text across wireless, wireline and cable providers ATIS - Alliance for Telecommunications Industry Solutions

10 Aber einigen Providern dauert der Findungsprozess zu lange: Beispiel Verizon: Quelle:FierceTelecom

11 Zusätzliche Herausforderung: Es fehlen Standards die die öffentliche Sicherheit betreffen Die vorhandenen Verfahren basieren oft auf den klassische PSTN Strukturen Die ATIS hat auch hier erst im Sommer 2014 eine entsprechende Task Force eingerichtet: PSRA-TF - Public Safety Related Applications Task Force Zu den Aufgabenstellungen zählen: Feuerwehr & Polizei Notruf Pager Systeme usw. ATIS - Alliance for Telecommunications Industry Solutions

12 BNA - Technische Richtlinie Notrufverbindungen Die TR Notruf legt unabhängig von den in Ursprungs- und Transitnetzen verwendeten Übertragungs- und Vermittlungstechniken die technischen Einzelheiten von Notrufverbindungen zu den im Einsatz befindlichen Notrufabfragestellen fest Notrufabfragestellen sind zurzeit ausschließlich mit Netzzugängen in ISDN- Technik ausgestattet Die TR Notruf legt die technischen Eigenschaften dieser Notrufanschlüsse fest Sie gibt das Verfahren und die verschiedenen Formate zur Übertragung der Standortangabe als Anschrift oder in der Form einer Beschreibung mit geografischen Koordinaten vor Die Standortangaben sind seit 23. Dezember 2012 zu übertragen

13 TR Notruf 1.0 (aktuelle Fassung: Juni 2011)!! 6.3 Technologiespezifische Anforderungen an Notrufverbindungen Notrufverbindungen im ISDN Anforderungen an Notrufverbindungen im ISDN sind im Anhang N3 beschrieben Notrufverbindungen in IP-Netzen Die Festlegung der Anforderungen erfolgt in einer künftigen Ausgabe der TR Notruf. Information: Anhang N -> Normativer Charakter Anhang I -> Informativer Charakter

14 8.2 Aufgaben der Betreiber von Telekommunikationsnetzen Mitwirkung bei der Ermittlung des Standortes des Notrufenden Auf Anforderung des Telefondienste Anbieters des Notrufenden ist der Erbringer von Vorleistungen verpflichtet, an der Ermittlung des Standortes mitzuwirken. Nutzt der verpflichtete Vorleistungserbringer seinerseits Vorleistungen, so muss er beim Erbringer dieser Vorleistung die Standortdaten anfordern Der Erbringer der Vorleistung ist verpflichtet, die Standortdaten in Abhängigkeit vom Netzzugang, d.h. entweder Festnetzanschluss oder Mobilfunkanschluss, von dem die Notrufverbindung eingeleitet wurde, unverzüglich an den Anfragenden zu übermitteln. Nach Empfang der Anfrage sind die Standortdaten innerhalb von 1 Sekunde an die anfragende Stellezu übermitteln. Die technische Schnittstelle zur Anforderung der Daten über den aktuellen Standort des Notrufenden ist beispielhaft in Anhang I4 beschrieben.

15 e164 vs. SIP URI DMZ Firma Y DMZ Dienste: DNS NAPTR Record SRV Record A/AAAA Record SBC / SIP Proxy / ALG Internet Verzeichnis ENUM Internet DMZ Firma X DMZ Firma Z

16 NAPTR Record: $ORIGIN e164.arpa. IN NAPTR "U" "E2U+sip" IN NAPTR "U" "E2U+ " SRV Record: $ORIGIN example.com _sip._tcp.example.com IN SRV bigbox.example.com. _sip._tcp.example.com IN SRV smallbox1.example.com. A/AAAA Record $ORIGIN bigbox.example.com. AAAA 2001:db8::1

17 Einschränkungen: erfordert eine SIP Infrastruktur die DNS nach RFC 3263 unterstützt SRV NAPTR A, AAAA nicht jeder DNS Dienst kann das leisten MS ab Windows Server 2008 R2 DNS BIND ab es wird ein gemeinsames Directory benötigt z.b. ENUM keine Zusicherung von SLAs oder QoS keine SIP Normalisierung kein Übergang ins PSTN

18 Und was ist mit SIP Connect? Dies ist und bleibt eine Lösung zwischen Enterprise und Provider zur Ablösung von ISDN Wichtig hier die Unterscheidung zwischen SIP Connect und SIP Trunking

19 Fraglich ist jedoch ob SIP Connect sich durchsetzen kann Zertifizierung war bisher aufwendig und kostenintensiv Daher bisher geringes Interesse bei Providern wie TK/SBC Herstellern Viele Provider haben schon jahrelange Erfahrung mit VoIP Peerings und verzichten auf Standards Die Einrichtung von SIP Trunks ist heute unkomplizierter geworden

20 Fazit SIP wird ISDN als Zugangstechnologie bis 2018 ablösen Die Zukunft von SIP Connect ist ungewiss E.164 Rufnummern werden weiter benötigt da der Provider Interconnect bis auf weiteres auf PSTN Technik beruht Es fehlen auf SIP Basis Mechanismen für Notruf & Co Die Standardisierung des Provider Interconnect ist zäh und von vielen Interessengruppen geprägt Bsp.: Die Arbeitspapiere der ITU T Study Group 11 stammen aus 2007 Es ist damit zu rechnen das große Provider de facto Standards entwickeln