Instytut Telekomunikacji PW NGN architektura SIP-T, SIP-I Materiały wykładowe do uŝytku wewnętrznego SIP-T/SIP-I 1
Zakres zastosowań SS7 (ITU) PSTN SIP-T IP PSTN SIP-T(IETF) ISUP/BICC SIP-I IP ISUP/BICC SIP-T/SIP-I 2
SIP-T/SIP-I (SIP- for Telephony/-with encapsulated ISUP) Podstawowy cel NGN: zapewnienie moŝliwości współpracy sieciom budowanym w róŝnych technikach W odniesieniu do techniki SIP oznacza to SIP-T: wykorzystanie sygnalizacji SIP dla lepszego zharmonizowania współpracy domeny PSTN z domeną pakietową (SIP) ISUP-ISUP oraz PSTN-terminaleSIP istnieją dwa przypadki: PSTN-SIP/SIP-PSTN konwersja protokołów PSTN-SIP-PSTN ( tranzyt PSTN przez domenę pakietową) SIP-I: ISUP-ISUP + BICC-BICC dodatkowo dochodzi więc BICC-BICC, popularny w rdzeniu GSM/UMTS na bazie sieci pakietowej Czyli środowisko współpracy jest dość bogate cd. SIP-T/SIP-I 3
Środowisko wielu sieci Architektura Domena IMS Domena GSM/UMTS Domena PSTN CSCF/ BGCF 3GPP SIP MGCF BICC SIP-I ISUP MSC Serwer Styk Nc BICC SIP-I SIP-T ISUP MSC Serwer SIP-I SIP-T ISUP Softswitch Styk Mc Border Gtwy IM-MGW VoIP TDM MGW Styk Nb VoIP TDM MGW VoIP TDM MGW CSCF Call Session Control F. BGCF Border Gateway Control F. IM-MGW - IP Multimedia Media Gateway F. MGW Media Gateway który schemat współpracy preferować - SIP czy BICC? SIP-T/SIP-I 4
Kontekst 3GPP Rel. 7 SIP-T/SIP-I 5
Oczekiwania funkcjonalne dlaczego SIP? Oczekiwania (względem zasad współpracy) i przesłanki (za SIP) oczekiwania zapewnienie przezroczystości usługowej domeny pakietowej dla usług tranzytowych (podobnie jak w przypadku BICC), ale - o ile moŝna - zapewnienie dostępu do informacji poziomu ISUP w domenie pakietowej przesłanki potencjalna moŝliwość budowy dodatkowych usług na bazie funkcjonalności serwerów SIP (elastyczność rutingowa, w tym forking, szeroki wachlarz sposobów wprowadzania usług (por. 2 wykład, slajd 14), BICC pod tym względem jest bardziej hermetyczny (niepopularny w sensie API) być moŝe sposób na ograniczenie zbioru platform usługowych eliminacja dedykowanych platform IN, jednorodność sygnalizacji zgłoszeniowej (SIP)? ale to nie takie proste SIP-T/SIP-I 6
Oczekiwania funkcjonalne jak? Informacja poziomu ISUP gdzie moŝe zostać wykorzystywana? tylko przez domenę PSTN przez domenę PSTN i domenę pakietową (poziom SIP) (por. oczekiwania) do czego? - głównie ruting, moŝe teŝ inne usługi, ale... problem: sposób przekazywania informacji ISUP wewnątrz wiadomości SIP wykorzystanie przez SIP wymaga transferu informacji w nagłówkach (header) SIP PSTN DSS1/SS7 dla celów wyłącznie PSTN wystarczy transfer w ciele wiadomości SIP (enkapsulacja), ale co z mid-call signaling (np. uderzenie w widełki podczas trwania połączenia)? chcemy Info ISUP ISUP/BICC SIP IP/SIP ruting+ usługi via SIP usługi PSTN... header msg body PSTN DSS1/SS7 translacja wybranych parametrów ISUP do pól nagłówka transfer wiadomości ISUP w body SIP Ostatecznie: SIP-T (IETF): ISUP-ISUP, ISUP-SIP SIP-I (ITU): ISUP-ISUP, BICC-BICC Ogólne zasady podobne w obu wersjach RóŜnice w detalach (ITU -Typ1/2: tylko nagłówki SIP Typ3/4: + enkapsulacja ISUP==SIP-I) SIP-I: CLIP, CLIR, 7
Składniki architektury i ich rola (przykład SIP-T) Inicjator sygnalizacji SIP-T (np. MGC, specjalizowany SIP UAC, np. SIP phone) podstawowe funkcje: enkapsulacja ISUP, translacja ISUP->SIP (poziom wiadomości, poziom parametrów) Końcowy odbiorca sygnalizacji SIP-T (MGC, SIP UAS ) podstawowe funkcje: standardowe przetwarzanie sygnalizacji SIP, interpretacja enkapsulowanych informacji ISUP (MGC, UAS), translacja SIP->ISUP (MGC) Serwer Proxy podstawowe funkcje: kierowanie wiadomości na podstawie informacji rutingowej (zasadniczo tej zawartej w polach nagłówka) SIP-T/SIP-I 8
Standaryzacja i wymagania - podsumowanie SIP-T: definicja uŝycia SIP dla współpracy ISUP z: ISUP i z terminalami_sip, rok ~2002 (RFC 3372 def + RFC 3398 odwzorowanie, RFC 3578, RFC 3204), SIP-I: definicja uŝycia SIP dla współpracy ISUP-ISUP oraz BICC-BICC, rok ~2004 (ITU-T Q.1912.5) (w istocie SIP-I to tzw. Profil C w Q.1912.5) (a więc zasadniczo nie są to nowe protokoły, choć mają róŝny zakres) Wymagania na współpracę i wynikowe funkcje SIP-I/T - podsumowanie Wymagania na współpracę SIP-I/T-ISUP Funkcje SIP-I/T dla realizacji wymagań Przezroczystość dla sygnalizacji ISUP ZagnieŜdŜenie wiadomości ISUP w ciele wiadomości SIP [RFC 3204] Ruting wiadomości SIP zaleŝny od informacji poziomu ISUP Odwzorowanie (translacja) ISUP do SIP (RFC3398) - poziom wiadomości jako takiej [IAM->INVITE...] - poziom parametrów wiadomości (CPN->To, RequestURI, kody przyczyny) Transfer wiadomości ISUP typu mid-call Wykorzystanie metody SIP INFO SIP-T/SIP-I 9
Przykład na bazie SIP-T Podstawowy scenariusz PSTN/MGC/SIP numeracja (RFC 3398) Translacja numerów np. wg: reguły RFC 3398 (np. tel:cpn, sip:+cpn@tele.pw.edu.pl,...) Q.1912.5 (tel: +48-22-2347794; user = phone) DNS/ENUM query (CPN/CIN => odpowiednie URI) SIP MGC/MG PSTN <-----------IAM---------- 1 [CPN,CIN] ==========Audio==========> <---INVITE[SIP-URI + ] 2 <--------INVITE--------- [SIP-URI + ISUP body] -----------100-----------> 3 -----------18x-----------> ==========Audio==========> =========================> ------------ACM---------> 4 5 -----------18x-----------> OK [ SIP-URI + ANM body] ------------CPG---------> 6 7 -----------200-----------> <=========Audio==========> ------------ANM---------> 8 <=========Audio==========> 9 <----------ACK------------ Kierowanie zgłoszenia CalledPartyNumber, CallIngPartyNumber => Request URI, To, From => ruting SIP SIP-T/SIP-I 10
Przykład cd. Podstawowy scenariusz SIP/MGC/PSTN numeracja (RFC 3398) Translacja numerów np. wg: reguły RFC 3398 Q.1912.5 DNS/ENUM SIP [SIP-URI + ISUP body] MGC/MG PSTN 1 ---------INVITE----------> <----------100------------ ------------IAM----------> 2 [CPN,CIN] <=========Audio=========== <-----------ACM----------- 3 4 <----------18x------------ <=========Audio=========== <-----------CPG----------- 5 6 <----------18x------------ <-----------ANM----------- 7 OK[SIP-URI + ANM body] <=========Audio==========> 8 <----------200------------ <=========Audio==========> 9 -----------ACK-----------> Kierowanie zgłoszenia Request URI, To, From + ISUPBody => CalledPartyNumber, CallingPartyNumber SIP-T/SIP-I 11
Podsumowanie SIP-T / SIP-I co lepsze? Domena IMS Domena GSM/UMTS Domena PSTN CSCF/ BGCF 3GPP SIP MGCF BICC SIP-I ISUP MSC Serwer Styk Nc BICC SIP-I SIP-T ISUP Styk Mc MSC Serwer SIP-I SIP-T ISUP Softswitch Border Gtwy IM-MGW VoIP TDM MGW Styk Nb VoIP TDM MGW VoIP TDM MGW oba są rozwinięciem SIP (elastyczność usługowa), ale: w SIP-I wykorzystano szereg dodatkowych RFC, co go wzbogaca SIP-T obejmuje jedynie scenariusz podstawowego zgłoszenia, a SIP-I równieŝ usługi dodatkowe (CLIP, CLIR, ) w SIP-I jawnie uwzględniono współpracę z transportem (np. RFC 3312) SIP-I dziedziczy klarowność dokumentów ITU SIP-T/SIP-I 12
Dodatek słowo o ENUM ENUM - wyciąg z ITU - Telecommunication Standardization Sector, Information Document 10-E STUDY GROUP 2, February 2002 The Domain Name System is a distributed hierarchical lookup service. It is primarily used on the Internet to translate between domain names and Internet Protocol ( IP ) addresses. The ENUM protocol, published in the standards-track document RFC 2916, proposes mapping ITU-T Recommendation E.164 telephone numbers into the DNS. An overview of how the DNS works in given in Annex C, starting on page 15. The ENUM protocol involves associating telephone numbers with network resources or services in the DNS. For example, a specific E.164 number can be coupled with, inter alia, other E.164 numbers, such as fax and mobile numbers, voice mail systems, an IP telephony address, an email address, a web site or any other resources or services that can be identified through a widely-used Internet addressing scheme called Uniform Resource Identifiers ( URIs )[1]. A description how the E.164 numbering plan would appear in the DNS using the ENUM protocol is in Annex E, starting on page 23. ENUM An Enabler of IP Telephony? One of the technical challenges raised by the ever-closer integration between circuit-switched and packet-switched networks is how to address calls that pass from one network service to another. Generally, it is assumed to be desirable that an integrated global subscriber access plan exists. For example, the same ITU-T E.164 telephone number would reach a subscriber regardless of whether IP-based or PSTN network technologies are used. It is now widely possible to originate calls from IP address-based networks to other networks, but it is uncommon to terminate calls from other networks to IP address-based networks. Rather, calls are generally terminated on the PSTN, so the called party can only use a terminal device connected to those networks. In order to access a subscriber on an IP address-based network from the PSTN, some sort of global numbering/addressing scheme across both PSTN and IP address-based networks needs to be developed and implemented. SIP-T/SIP-I 13
cd. ENUM ANNEX E - What is ENUM? ENUM is a protocol which is the result of work of the IETF's Telephone Number Mapping working group[2]. The charter of the ENUM working group was to define a DNS-based architecture and protocol for mapping an ITU-T Recommendation E.164 telephone number to what are known as Uniform Resource Identifiers ( URIs )[3]. A relatively stable standardstrack version of the ENUM protocol has been published as RFC 2916[4]. URIs are strings of characters that identify resources such as documents, images, files, databases, email addresses or other resources or services in a common structured format. The most commonly known types of URIs are Uniform Resource Locators ( URLs ) which are used to locate resources using the World Wide Web. For example, http://www.itu.int/infocom/enum/ is the URL for the ITU web site providing an overview of ITU ENUM activities. The ENUM protocol uses what are called Naming Authority Pointer ( NAPTR ) DNS resource records as defined in RFC 2915[5] in order to identify the available methods or services for contacting a specific node identified through a Recommendation E.164 number. The ENUM protocol defines and uses a specific type of NAPTR service with the mnemonic E2U (E.164 to URI resolution). The result of an ENUM query can be one or more URIs with their order of processing and preference indicated by values in the NAPTR records. These URIs are then used to reference resources or services associated with the Recommendation E.164 number. Possible examples of resources or services include, inter alia, fax number, mobile number, email address, GPS coordinates, phone redirection services, unified messaging services, voice mail and public key for asymmetric encryption applications. How are E.164 Numbers Mapped into the DNS? The ENUM protocol requires that related services be looked up through a convention of one-to-one reverse mapping of digits[6] in an ITU-T Recommendation E.164 number into separate DNS zones which are then concatenated with another domain. The Internet Architecture Board ( IAB ), has proposed that this domain be e164.arpa. As of September 1, 2001, there is not yet consensus by ITU Member States on the usage of the e164.arpa domain or of any particular operator of that domain but with that caveat, it is used below for the sake of discussion. SIP-T/SIP-I 14
cd. ENUM As an example, lets construct the related DNS domain to look up NAPTR resource records associated with the number +33 1 40 20 51 51 which corresponds to the information desk at the Louvre Museum in Paris, France: Write the E.164 number in its full form, including the country code, then remove all non-digit characters with the exception of the leading +. Example: +33140205151 Remove all characters with the exception of the digits and put dots (. ) between each digit. Example: 3.3.1.4.0.2.0.5.1.5.1 Reverse the order of the digits and append the ENUM Tier-0 zone to the end. Example: 1.5.1.5.0.2.0.4.1.3.3.e164.arpa If the Louvre Museum had chosen to provision its number in the DNS for ENUM services, the client application could now perform a lookup on this name and, for example, retrieve the NAPTR records for a corresponding fax number, email address or any other URI for the E.164 number +33 1 40 20 51 51. [1] http://www.ietf.org/rfc/rfc2396.txt. [2] http://www.ietf.org/html.charters/enum-charter.html. [3] See http://www.ietf.org/rfc/rfc2396.txt. The Internet Assigned Numbers Authority ( IANA ), part of the Internet Corporation for Assigned Names and Numbers ( ICANN ), maintains a list of standardized URI prefix schemes such as http, ftp, and mailto at http://www.isi.edu/in-notes/iana/assignments/url-schemes. [4] http://www.ietf.org/rfc/rfc2916.txt. [5] http://www.ietf.org/rfc/rfc2915.txt. SIP-T/SIP-I 15