WJ NP_VoIP_wersja_30_dla_operatorow

Zakład Sieci (Z-2)
Identyfikacja problemów w przenośności numerów
telefonicznych dla usług świadczonych w technologii VoIP
Warszawa - Miedzeszyn
Wrzesień 2010 r.
1
SPIS TREŚCI
1.
WSTĘP ............................................................................................................ 5
1.1.
1.2.
1.3.
1.4.
1.5.
2.
CELE PODSTAWOWE ................................................................................................ 5
PRZEZNACZENIE WYNIKÓW .................................................................................... 5
PODSTAWA REALIZACJI PRACY ............................................................................... 5
SPOSÓB REALIZACJI PRACY ..................................................................................... 5
WPROWADZENIE ...................................................................................................... 7
ZAKRES
OBOWIĄZKÓW
DOSTAWCÓW
USŁUG
DOTYCZĄCYCH
PRZENOSZENIA NUMERÓW W TECHNOLOGII VOIP WYNIKAJĄCY Z PRAWA
TELEKOMUNIKACYJNEGO I DYREKTYW UNIJNYCH ..................................... 8
2.1. OBOWIĄZKI DLA PRZEDSIĘBIORCÓW TELEKOMUNIKACYJNYCH WYNIKAJĄCE Z
USTAWY PRAWO TELEKOMUNIKACYJNE ................................................................ 8
2.2. UWAGI ODNOŚNIE ZAPISÓW PRAWA TELEKOMUNIKACYJNEGO .......................... 11
2.3. OBOWIĄZKI W ZAKRESIE PRZENOSZENIA NUMERU WYNIKAJĄCE Z DYREKTYW
UNIJNYCH............................................................................................................... 12
2.4. WNIOSKI Z ZAPISÓW DYREKTYWY 2009/136/WE............................................... 13
3.
ANALIZA
STANU AKTUALNEGO PRZENOSZENIA NUMERÓW DLA USŁUG W
TECHNOLOGII VOIP REALIZOWANYCH PRZEZ KRAJOWYCH DOSTAWCÓW
USŁUG ........................................................................................................... 14
3.1. PUBLICZNE USŁUGI TELEFONICZNIE ŚWIADCZONE W TECHNOLOGII VOIP........ 14
3.2. AKTUALNY
STAN
PRZENOSZENIA
NUMERÓW
TELEFONICZNYCH
Z
UWZGLĘDNIENIEM USŁUG W TECHNOLOGII VOIP ............................................... 15
3.3. WARIANTY STOSOWANYCH ROZWIĄZAŃ SIECIOWYCH PLATFORM VOIP Z
UWZGLĘDNIENIEM WSPÓŁPRACY MIĘDZYSIECIOWEJ POD KĄTEM PRZENOSZENIA
NUMERÓW .............................................................................................................. 16
3.4. UśYWANY ZAKRES I SPOSÓB KORZYSTANIA Z NUMERACJI .................................. 17
4.
REALIZACJA TECHNICZNA PRZENOSZENIA NUMERÓW .............................. 18
4.1. METODY REALIZACJI PRZENOSZENIA NUMERÓW ................................................ 18
4.2. AKTUALNIE STOSOWANA METODA PRZENOSZENIA NUMERÓW W SIECI KRAJOWEJ
DLA USŁUG TELEFONICZNYCH REALIZOWANYCH W TECHNOLOGII VOIP .......... 19
5.
PROBLEMY
WYNIKAJĄCE ZE SCENARIUSZY PRZENOSZENIA NUMERÓW W
SIECI KRAJOWEJ DLA USŁUG REALIZOWANYCH W TECHNOLOGII VOIP ... 25
6.
ZASTOSOWANIA
METODY QOR W SIECI IP W PRZYPADKU PRZENOSZENIA
NUMERU POMIĘDZY SIECIAMI PSTN .......................................................... 26
7.
MOśLIWOŚCI
ZASTOSOWANIA ENUM DLA POTRZEB PRZENOSZENIA
NUMERÓW USŁUG REALIZOWANYCH W TECHNOLOGII VOIP .................... 27
8.
PRZENOSZENIE NUMERÓW MIĘDZY RÓśNYMI RODZAJAMI SIECI .............. 29
ZWIĄZANE Z BAZĄ DANYCH NPDB PRZY PRZENOSZENIU NUMERÓW
MIĘDZY RÓśNYMI RODZAJAMI SIECI ..................................................................... 31
8.1. PROBLEMY
2
8.2. PROBLEMY
ZWIĄZANE Z SYGNALIZACJĄ PRZY PRZENOSZENIU NUMERÓW
MIĘDZY RÓśNYMI RODZAJAMI SIECI ..................................................................... 31
8.3. WYKORZYSTANIE
USŁUGI ENUM W PRZENOŚNOŚCI NUMERÓW PRZY
WSPÓŁPRACY SIECI VOIP/IMS ............................................................................. 32
9.
8.3.1. NUMER TELEFONICZNY NIE JEST PRZENOSZONY MIĘDZY SIECIAMI ............................32
8.3.2. NUMER TELEFONICZNY JEST PRZENOSZONY MIĘDZY SIECIAMI PSTN........................33
8.3.3. NUMER TELEFONICZNY JEST PRZENOSZONY MIĘDZY SIECIĄ PSTN I IP .....................34
8.3.4. NUMER TELEFONICZNY JEST PRZENOSZONY MIĘDZY SIECIAMI IP..............................35
8.3.5. PODSUMOWANIE ...........................................................................................................36
WNIOSKI ...................................................................................................... 38
9.1. WNIOSKI Z KONSULTACJI Z DOSTAWCAMI USŁUG W TECHNOLOGII VOIP ......... 38
9.2. PROPONOWANE KIERUNKI DZIAŁAŃ ..................................................................... 39
10. ZAŁĄCZNIK NR 1. PRZEGLĄD DOKUMENTÓW MIĘDZYNARODOWYCH ...... 42
10.1. PRZEGLĄD DOKUMENTÓW ORGANIZACJI REGULACYJNYCH ............................... 42
10.1.1. REKOMENDACJE CEPT ................................................................................................42
10.1.2. OŚWIADCZENIE ERG....................................................................................................42
10.2. INICJATYWY PODJĘTE PRZEZ OFCOM W ZWIĄZKU Z PRZENOŚNOŚCIĄ NUMERU 42
10.2.1. ZMIANA POLITYKI WZGLĘDEM DOSTAWCÓW USŁUG VOIP W ZAKRESIE PRAWA DO
PRZENOŚNOŚCI NUMERU...............................................................................................43
10.2.2. PROPOZYCJA MODYFIKACJI DEFINICJI USŁUGI PATS POD KĄTEM PRZENOŚNOŚCI
NUMERU ........................................................................................................................43
10.3. KOMENTARZ OPERATORA WIND HELLAD TELECOMMUNICATIONS S.A. DO
RAPORTU ERG (07) 56 REV 1............................................................................... 45
10.4. DECYZJA FCC W SPRAWIE ROZSZERZENIA LOKALNEJ PRZENOŚNOŚCI NUMERU
NA USŁUGI VOIP .................................................................................................... 46
10.5. ASPEKTY STANDARYZACYJNE W DOKUMENTACH RFC DOTYCZĄCYCH
PRZENOŚNOŚCI NUMERÓW..................................................................................... 46
10.5.1.
10.5.2.
10.5.3.
10.5.4.
10.5.5.
10.5.6.
10.5.7.
10.5.8.
10.5.9.
WYKORZYSTANIE WSKAŹNIKA „TEL” URI W PRZENOŚNOŚCI NUMERÓW ..................46
SKŁADNIA WSKAŹNIKA „TEL”URI...............................................................................47
NUMERY TELEFONICZNE WE WSKAŹNIKU URI ...........................................................48
SEPARATORY W NUMERACH TELEFONICZNYCH ..........................................................48
ZNAKI ALFABETYCZNE ODPOWIADAJĄCE CYFROM .....................................................48
ZNAKI ALFANUMERYCZNE „*” I „#” ORAZ ZNAKI SŁUśĄCE JAKO IDENTYFIKATORY.49
NUMERY GLOBALNE .....................................................................................................49
NUMERY LOKALNE .......................................................................................................49
PARAMETRY ZWIĄZANE Z PRZENOŚNOŚCIĄ NUMERÓW WYKORZYSTANE WE
WSKAŹNIKU „TEL”URI.................................................................................................49
10.5.10. SPECYFIKACJA SKŁADNI POLA „PARAMETR” WSKAŹNIKA „TEL” URI........................50
10.5.11. OGÓLNE ZASADY OBSŁUGI WSKAŹNIKA „TEL” URI....................................................51
10.5.12. OBSŁUGA WSKAŹNIKA „TEL” URI Z JEDNYM LUB Z WIELOMA PARAMETRAMI .........52
10.5.13. DODAWANIE PARAMETRU LUB PARAMETRÓW DO WSKAŹNIKA „TEL” URI ...............53
10.5.14. DODAWANIE INFORMACJI O LOKALIZACJI ABONENTA WYWOŁUJĄCEGO ...................54
10.5.15. DODAWANIE PARAMETRU LUB PARAMETRÓW NP Z POWODU KONWERSJI
PROTOKOŁÓW ...............................................................................................................54
10.5.16. KWESTIE ZWIĄZANE Z BEZPIECZEŃSTWEM..................................................................55
10.5.17. MAPOWANIE ADRESÓW E.164 NA WSKAŹNIKI URI DLA „INFRASTRUKTURALNEGO
ENUM” PRZY ZASTOSOWANIU APLIKACJI DDDS.......................................................56
10.5.18. WYMAGANIA NA ENUM INFRASTRUKTURALNY ........................................................57
10.6. PRZENOŚNOŚĆ NUMERU W SIECI GSTN................................................................ 59
3
10.6.1.
10.6.2.
10.6.3.
10.6.4.
INFORMACJE OGÓLNE ...................................................................................................59
PROCEDURY STOSOWANE W PRZYPADKU PRZENOŚNOŚCI USŁUGOWEJ ......................60
PORÓWNANIE PROCEDUR PRZENOŚNOŚCI USŁUGOWEJ ...............................................63
INTERFEJSY UśYWANE MIĘDZY SWITCH’EM I BAZĄ NPDB.........................................64
10.7. REPREZENTOWANIE „GRUPY ŁĄCZY” WE WSKAŹNIKU TEL/SIP URI .................. 65
10.7.1. INFORMACJE OGÓLNE ...................................................................................................65
10.7.2. WYMAGANIA ZWIĄZANE Z PRZEKAZYWANIEM INFORMACJI O GRUPIE ŁĄCZY ..........66
10.7.3. PRZYKŁADOWA ARCHITEKTURA ODNIESIENIA I PRZEPŁYW WIADOMOŚCI .................66
10.8. WYKORZYSTYWANIE
SYSTEMU ENUM DLA EFEKTYWNEGO ROZWOJU USŁUG
ŚWIADCZONYCH PRZY JEGO WSPARCIU ................................................................ 67
10.8.1. INFORMACJE OGÓLNE ...................................................................................................67
10.8.2. OGÓLNA ZASADA DZIAŁANIE SYSTEMU ENUM..........................................................68
10.8.3. DZIAŁANIE SYSTEMU ENUM W POŁĄCZENIU MIĘDZY DWOMA ABONENTAMI
SYSTEMU IMS...............................................................................................................68
10.8.4. DZIAŁANIE SYSTEMU ENUM W POŁĄCZENIU MIĘDZY ABONENTEM SYSTEMU IMS I
SIECI PSTN ...................................................................................................................70
10.8.5. ARCHITEKTURA SYSTEMU ENUM DNS ZAPEWNIAJĄCA „PEERING” USŁUG VOIP
POMIĘDZY SIECIAMI IP .................................................................................................70
DOKUMENTY ZWIĄZANE ........................................................................... 72
UśYWANE SKRÓTY .............................................................................................. 75
4
1. Wstęp
1.1. Cele podstawowe
Celem pracy jest przeprowadzenie identyfikacji problemów w przenośności numerów
telefonicznych dla usług świadczonych w technologii VoIP w kraju.
1.2. Przeznaczenie wyników
Wyniki pracy zostaną wykorzystane w procesie ustalania kierunków działań regulatora w
przenośności numerów telefonicznych dla usług realizowanych w technologii VoIP.
1.3. Podstawa realizacji pracy
Podstawą realizacji pracy była potrzeba wykonania analizy identyfikacji problemów w
przenośności numerów telefonicznych dla usług świadczonych w technologii VoIP w kraju.
1.4. Sposób realizacji pracy
W opracowaniu przeanalizowano następującą problematykę:
1. Zakres obowiązków operatorów sieci i dostawców usług związany z przenoszeniem
numerów w technologii VoIP, który wynika z aktualnych regulacji prawych, w tym z
ustawy Prawo telekomunikacyjne [1] i dwu rozporządzeń [2] i [5] oraz aktualnych
wytycznych wynikających ze zmiany Dyrektyw Komisji Europejskiej z listopada 2009
roku.
2. Aktualny stan przenoszenia numerów dla usług w technologii VoIP realizowanych
przez krajowych dostawców usług wykonany na podstawie konsultacji z dostawcami
usług w technologii VoIP:
- rodzaj świadczonych usług telefonicznych w technologii VoIP,
- aktualny stan przenoszenia numerów telefonicznych dla usług w technologii
VoIP,
- warianty stosowanych rozwiązań sieciowych platform VoIP z uwzględnieniem
współpracy międzysieciowej pod kątem przenoszenia numerów,
- uŜywany zakres i sposób korzystania z numeracji oraz współpraca operatorów
w tym zakresie,
- metody przenoszenia numerów stosowane w sieci krajowej dla usług
telefonicznych realizowanych w technologii VoIP.
3. MoŜliwości zastosowania metody QoR dla usług w technologii VoIP.
4. MoŜliwości zastosowania ENUM dla potrzeb przenoszenia numerów usług
realizowanych w technologii VoIP.
5. Przenoszenie numerów między róŜnymi rodzajami sieci:
- problemy związane z bazą danych NPDB przy przenoszeniu numerów między
róŜnymi rodzajami sieci,
- problemy związane z sygnalizacją przy przenoszeniu numerów między
róŜnymi rodzajami sieci.
5
6. MoŜliwości wykorzystania ENUM w przenośności numerów przy współpracy sieci
PSTN z siecią VoIP/IMS dla róŜnych scenariuszy, gdzie numer telefoniczny:
- nie jest przenoszony między sieciami,
- jest przenoszony między sieciami PSTN,
- jest przenoszony między siecią PSTN i IP,
- jest przenoszony między sieciami IP.
7. Problemy związane z przenoszeniem numerów w sieci krajowej dla usług
realizowanych w technologii VoIP.
8. Wnioski
- wnioski zgłaszane przez dostawców usług w technologii VoIP,
- wnioski z konsultacji z dostawcami usług w technologii VoIP,
- propozycje dalszych działań.
W załączniku nr 1 zamieszczono wyniki przeglądu dokumentów międzynarodowych w
zakresie przenośności numerów:
1. Dokumentów organizacji regulacyjnych, w szczególności:
- rekomendacje CEPT,
- oświadczenie ERG,
- raport opisujący inicjatywy podjęte przez OFCOM w związku z przenośnością
numeru,
- decyzja FCC w sprawie rozszerzenia lokalnej przenośności numeru na usługi
VoIP.
2. Dokumentów RFC.
6
1.5. Wprowadzenie
Obecnie mamy do czynienia z rozpowszechnianiem róŜnych usług głosowych (w tym
telefonii IP i telefonii internetowej) realizowanych w dojrzałej juŜ technologii VoIP,
zastępujących tradycyjne usługi telefoniczne. W wyniku pojawiają się nowi dostawcy usług
przejmujący część rynku usług telefonicznych. Usługi VoIP są oferowane w wielu
odmianach, niektóre z nich są traktowane jako substytut klasycznych usług głosowych
świadczonych w sieciach stacjonarnych (PSTN) i ruchomych (np. GSM) przy wykorzystaniu
numeracji telefonicznej.
Dostawcy tych usług powinni mieć dostęp do takich samych zakresów numerów, jaki mają
operatorzy klasycznych usług telefonicznych.
Substytucja telefonii stacjonarnej przez usługi telefonii VoIP stwarza potrzebę zapewnienia
przenoszenia numerów telefonicznych dla abonentów korzystających z tych usług.
Przenośność numeru NP (Number Portability) jest uprawnieniem abonenta do zachowania
posiadanego numeru telefonicznego przy zmianie dostawcy usługi, miejsca korzystania z
usługi lub rodzaju usługi.
Wprowadzenie przenośności numeru nie tylko likwiduje utrudnienia i uciąŜliwości
wynikające ze zmiany numeru telefonu przy zmianie przedsiębiorcy telekomunikacyjnego,
ale równieŜ stanowi jeden z waŜniejszych elementów sprzyjających rozwojowi konkurencji
na rynku telekomunikacyjnym.
Przenośność numeru jest jednym z podstawowych instrumentów konkurencji
międzyoperatorskiej. Dlatego teŜ powszechnie przenośność numeru jest postrzegana jako
narzędzie w rękach regulatora słuŜące do zmniejszania barier w działalności usługowej
dostawców zamiast stosowania działań restrykcyjnych w stosunku do podmiotów nie
przestrzegających obowiązujących regulacji.
Zgodnie z suplementem 2 zalecenia ITU-T E.164: „Number portability”, wyróŜnia trzy
podstawowe rodzaje przenośności:
a) przenośność dostawcy usług SPP (Service Provider Portability),
b) przenośność lokalizacyjna LNP (Location Number Portability),
c) przenośność usługowa SP (Service Portability).
W odniesieniu do usług realizowanych w technologii VoIP, które mają charakter
nomadyczny, zastosowanie mają: przenośność przy zmianie dostawcy usługi i przenośność
usługowa (polegającą na zmianie formy świadczenia usługi telefonicznej np. w sieci PSTN
lub realizowanej za pośrednictwem sieci Internet).
Aktualnie prawo telekomunikacyjne określa obowiązek przenoszenia numerów dla
abonentów dla sieci telefonicznych stacjonarnych i ruchomych.
Potrzeby klientów powodują, Ŝe dostawcy usług w technologii VoIP realizują usługi
przenoszenia numerów w miarę moŜliwości technicznych i na postawie decyzji biznesowych.
Brak realizacji NP powoduje tworzenie barier i przez to ograniczanie rozwoju rynku połączeń
głosowych oraz ograniczenia praw abonentów do numeru.
Powoduje to dezorientację abonentów, którzy zamawiając usługę z przydzielonym nowym
numerem lub przenosząc numer od innego operatora sieci stacjonarnej będą mogli w
przyszłości przenieść numer do innego operatora świadczącego usługę w sieci stacjonarnej,
czy teŜ w technologii VoIP.
7
Obowiązki w zakresie przenoszenia numerów są określone przez ustawę Prawo
Telekomunikacyjne z dnia 16 lipca 2004 r. z późn. zmianami [1] oraz wytyczne w
Dyrektywach Parlamentu Europejskiego. (Do listopada 2009 obowiązek przenoszenia
numerów wynikał z dyrektywy o usłudze powszechnej (dyrektywy 2002/22/WE) [7], a od
listopada obowiązują zmiany zapisów tej dyrektywy określone przez dyrektywę nowelizującą
2009/136/WE [6]);
Istnieje teŜ Dyrektywa Parlamentu Europejskiego i Rady 2009/136/WE z dnia 25 listopada
2009 r. zmieniająca dyrektywę 2002/22/WE w sprawie usługi powszechnej i związanych z
sieciami i usługami łączności elektronicznej praw uŜytkowników, dyrektywa 2002/58/WE
dotycząca przetwarzania danych osobowych i ochrony prywatności w sektorze łączności
elektronicznej oraz rozporządzenie (WE) nr 2006/2004 w sprawie współpracy między
organami krajowymi odpowiedzialnymi za egzekwowanie przepisów prawa w zakresie
ochrony konsumentów - LP9 002.21.81 Dziennik Urzędowy Unii Europejskiej 18.12.2009 r.
Wprowadzone ww. dokumentami zmiany w zakresie przenośności numeru mają na celu
wpływ z jednej strony na rozwój konkurencji, a z drugiej osiąganie korzyści przez abonentów
oraz zabezpieczenie ich interesów przed moŜliwością wystąpienia ograniczeń czy
nieprawidłowości. Jak określono w preambule (p.47) ,,Istotne jest zapewnienie, aby
moŜliwości tej nie ograniczały przeszkody prawne, techniczne ani praktyczne, w tym warunki
umów, procedury, opłaty itd.
Nowelizacja dyrektywy o usłudze powszechnej:
- przyspiesza całą procedurę przenoszenia numeru – numer ma być aktywowany w
ciągu jednego dnia roboczego,
- kładzie większy nacisk na egzekwowanie przez regulatora wywiązywania się przez
dostawców usług z tego obowiązku,
- ogranicza czas umów - umowy o świadczenie usług nie powinny przekraczać 24
miesięcy, a ponadto powinny być dostępne równieŜ 12 miesięczne okresy
zobowiązania,
- zaleca, aby warunki i procedury rozwiązywania umów nie zniechęcały do zmiany
dostawców usług,
- uprawnia regulatorów do podejmowania w razie potrzeby środków zapewniających
ochronę abonentów w trakcie przenoszenia numeru (bez zmniejszania dla nich
atrakcyjności tego procesu), a nawet do nakładania odpowiednich kar na
przedsiębiorców, które są niezbędne do zminimalizowania mogących wystąpić
nieprawidłowości.
2. Zakres obowiązków dostawców usług dotyczących przenoszenia
numerów w technologii VoIP wynikający z Prawa telekomunikacyjnego i
Dyrektyw Unijnych
2.1. Obowiązki dla przedsiębiorców telekomunikacyjnych wynikające z ustawy Prawo
telekomunikacyjne
Z zapisów obowiązującej ustawy Prawo Telekomunikacyjne z dnia 16 lipca 2004 r. z późn.
zm., wynika dla dostawców usług obowiązek zapewnienia abonentowi przeniesienia numeru
w przypadku zmiany miejsca zamieszkania, siedziby lub miejsca wykonywania działalności
w sieci tego samego operatora (art. 70) oraz obowiązek zachowania numeru w przypadku
zmiany dostawcy usług (art. 71). Realizacja obowiązku przenośności numeru jest określona
8
na podstawie art. 73 i 74 w wydanych w oparciu o zapisy ww. ustawy Pt dwu
rozporządzeniach:
-
Rozporządzeniu Ministra Infrastruktury z dnia 17 czerwca 2009 r. w sprawie
warunków korzystania z uprawnień w publicznych sieciach telefonicznych, (Dz.
U. Nr 97 poz. 810, 2009 r.) [5],
-
Rozporządzeniu Ministra Infrastruktury z dnia 9 stycznia 2008 r. w sprawie
szczegółowych wymagań dotyczących zasad adresowania dla właściwego
kierowania połączeń (Dz. U. z dnia 29 stycznia 2008 r.) [2].
Zapisy ustawy są zgodne z zasadami neutralności technologicznej. Z rozporządzenia [5]
wynika, Ŝe obowiązek przenoszenia numerów telefonicznych dotyczy publicznej telefonicznej
sieci stacjonarnej (z określoną lokalizacją zakończenia łącza) i telefonicznej sieci ruchomej.
Regulacją nie jest objęte przenoszenie numerów dla usług telefonicznych realizowanych w
technologii VoIP w sposób nomadyczny.
W zakresie przenośności numeru zapisy ustawy określają uprawnienia dla abonenta i
obowiązki dla dostawcy usługi zapewniającego przyłączenie do publicznej sieci telefonicznej.
1. Art. 71 ust 1. ustawy Prawo telekomunikacyjnego określa uprawnienia abonenta
publicznej sieci telefonicznej, którymi mogą być usługi realizowane w technologii
VoIP, do przenoszenia numerów z tym, Ŝe nie określa zasięgu obszaru geograficznego
dla numerów geograficznych, co nie stanowi ograniczenia w przypadku usług w
technologii VoIP:
„Art. 71.
1. Abonent będący stroną umowy z dostawcą usług zapewniającym
przyłączenie do publicznej sieci telefonicznej moŜe Ŝądać przy zmianie
dostawcy usług przeniesienia przydzielonego numeru do istniejącej sieci
operatora na:
1) obszarze geograficznym – w przypadku numerów geograficznych;
2) terenie całego kraju – w przypadku numerów niegeograficznych.”
2. Art. 74 ust 1. ustawy Prawo telekomunikacyjnego określa obowiązek dostawcy usługi
zapewniającego przyłączenie do publicznej sieci telefonicznej zapewnienia
moŜliwości realizacji uprawnień abonenta do przenoszenia numeru, w tym stworzenia
warunków technicznych:
,,Art. 74
1. Dostawca usług zapewniający przyłączenie do publicznej sieci
telefonicznej i operator, do którego sieci został przyłączony abonent
będący stroną umowy z dostawcą usług zapewniającym przyłączenie
do publicznej sieci telefonicznej, są obowiązani zapewnić moŜliwości
do realizacji uprawnień abonenta, o których mowa w art. 69–72,
polegające na stworzeniu odpowiednich warunków technicznych lub
zawarciu umowy, o której mowa w art. 31 albo art. 128, a jeŜeli
moŜliwości takie istnieją – zapewnić ich realizację.”
3. Art. 74 ust 2. ustawy Prawo telekomunikacyjnego określa moŜliwość ograniczenia
uprawnień abonentów na wniosek dostawcy usług ze względu na moŜliwości
techniczne sieci, co moŜe być wykorzystane w etapie przejściowym wdraŜania
przenośności numerów przez dostawców usług w technologii VoIP:
9
,,Art. 74
2. Na wniosek dostawcy albo operatora, o których mowa w ust. 1,
Prezes UKE moŜe, w drodze decyzji, na czas określony, zawiesić
realizację lub ograniczyć zakres realizacji określonego uprawnienia, o
którym mowa w art. 69–72, jeŜeli techniczne moŜliwości sieci
wnioskodawcy nie pozwalają na realizację uprawnienia w całości lub
części, określając harmonogram przystosowania tej sieci do
realizacji uprawnienia objętego wnioskiem.”
4. Prawo telekomunikacyjne w artykule Art. 2 punkt 28 – z zapisu wynika, Ŝe usługi
VoIP dostępne publicznie są publiczną usługą telekomunikacyjną:
28) Publiczna sieć telefoniczna – publiczną sieć telekomunikacyjną
wykorzystywaną do świadczenia publicznie dostępnych usług telefonicznych,
zapewniającą łączność głosową między zakończeniami sieci, a takŜe inne
formy łączności, w szczególności przesyłanie faksów i danych.”
5. Art. 2 punkt 22 ustawy Pt definiuje numer geograficzny. Usługi w technologii VoIP
mogą być uŜywane w róŜnych lokalizacjach, nie ma stałej lokalizacji zakończenia
sieci i tu występuje niespójność:
„22) numer geograficzny – numer ustalony w planie numeracji krajowej, w
którym część ciągu cyfr zawiera wskaźnik obszaru geograficznego,
wykorzystywany do kierowania połączeń do stałej lokalizacji zakończenia
sieci.”
6. Art. 2 punkt 23 ustawy Pt definiuje numer niegeograficzny. Usługi w technologii
VoIP zgodnie z planem numeracji krajowej PNK-TF mają przypisany zakres
WST=39:
„23) numer niegeograficzny – numer ustalony w planie numeracji krajowej,
który nie zawiera ciągu cyfr określającego wskaźnik obszaru geograficznego,
w szczególności numer zakończenia ruchomej publicznej sieci telefonicznej,
numer do którego połączenia są bezpłatne albo o podwyŜszonej opłacie.”
7. Rozporządzenie Ministra Infrastruktury z dnia 9 stycznia 2008 r. w sprawie
szczegółowych wymagań dotyczących zasad adresowania dla właściwego kierowania
połączeń (Dz. U. z dnia 29 stycznia 2008 r.) ustala zasady adresowania dla
właściwego kierowania połączeń w zakresie numeracji słuŜącej realizacji uprawnień
abonenta i uŜytkownika z wykorzystaniem systemu sygnalizacji SS7 do przenoszenia
przydzielonego numeru pomiędzy operatorami oraz numer rutingowy NR NP (5 cyfr)
= "C hex"+ XYZT. Rozporządzenie powyŜsze nie uwzględnia sygnalizacji
stosowanych w technologii VoIP.
8. Rozporządzenie Ministra Infrastruktury z dnia 17 czerwca 2009 r. w sprawie
warunków korzystania z uprawnień w publicznych sieciach telefonicznych ogranicza
obowiązek przenoszenia numerów w sieciach stacjonarnych dla określanej lokalizacji,
tym samym wyklucza obowiązek zapewnienia przenośności numeru w przypadku
usługi realizowanej w sposób nomadyczny, gdzie wykorzystanie numeru jest
niezaleŜne od lokalizacji, czyli usług realizowanych w technologii VoIP. (Zapisy
ujmujące tą kwestie zostały niezmienione w projekcie do zmian rozporządzenia z
sierpnia 2010 r.):
§ 6 ust 1.:
10
„§ 6. 1. Abonent będący stroną umowy z dostawcą usług zapewniającym
przyłączenie do stacjonarnej lub ruchomej publicznej sieci telefonicznej, w
celu realizacji uprawnienia, o którym mowa w art. 71 ust. 1 ustawy, występuje
z wnioskiem w formie pisemnej do nowego dostawcy usług o przeniesienie
przydzielonego numeru do tego dostawcy, zwanego dalej "nowym dostawcą”
oraz
§ 6 ust 1ust 2 punkt 4:
,, 4) adres, pod który zostanie przeniesiony numer - w przypadku abonentów
będących stroną umowy z dostawcą usług zapewniającym przyłączenie do
stacjonarnej publicznej sieci telefonicznej;”.
9. Art. 2 punkty 38 i 52 ustawy Pt określają stacjonarną publiczną sieć telefoniczną, ale
skoro usługa VoIP moŜe być świadczona w dowolnej lokalizacji nieprzypisanej do jej
konkretnego adresu, tym samym potwierdzają, Ŝe nie ma obowiązku przenoszenia
numerów dla usług nomadycznych świadczonych w technologii VoIP:
„38) stacjonarna publiczna sieć telefoniczna – publiczną sieć telefoniczną, w
której zakończenia sieci mają stałą lokalizację;”,
„52) zakończenie sieci – fizyczny punkt, w którym abonent otrzymuje dostęp
do publicznej sieci telekomunikacyjnej; w przypadku sieci stosujących
komutację lub przekierowywanie, zakończenie sieci identyfikuje się za pomocą
konkretnego adresu sieciowego, który moŜe być przypisany do numeru lub
nazwy abonenta;”.
10. Art. 56, ust.4 ustawy Prawo telekomunikacyjnego zawiera zapis o konieczności
podania w umowie oprócz numeru przydzielonego abonentowi takŜe adresu
zakończenia sieci tylko w przypadku przyłączenia do publicznej stacjonarnej sieci
telefonicznej sieci i nie dotyczy usług nomadycznych w technologii VoIP:
Art. 56, ust.4
,,4. Umowa o zapewnienie przyłączenia do publicznej sieci
telekomunikacyjnej poza elementami, o których mowa w ust. 3, powinna
określać numer przydzielony abonentowi, a w przypadku przyłączenia do
publicznej stacjonarnej sieci telefonicznej takŜe adres zakończenia sieci”.
Usługa stacjonarnej sieci telefonicznej określana jako POTS, która dostarcza styk analogowy
a/b, w określonej stałej lokalizacji z wykorzystaniem geograficznego numeru telefonicznego
mimo, Ŝe wewnątrz sieci realizowana jest w technologii VoIP ma obowiązek przenoszenia
numerów. Dostawca usługi telefonicznej jest jednocześnie dostawcą zakończenia łącza.
Uprawnienia abonentów dla usług nomadycznych realizowanych w technologii VoIP w
zakresie przenoszenia numerów nie są objęte regulacją, poniewaŜ zakończenie sieci nie
identyfikuje się za pomocą konkretnego adresu sieciowego, który moŜe być przypisany do
numeru lub nazwy abonenta.
2.2. Uwagi odnośnie zapisów Prawa telekomunikacyjnego
Aktualne Pt nie zawiera zapisu zgodnego z zapisami Dyrektywy 2009/136/WE o
,,zapewnieniu wszystkim abonentom, którzy posiadają numery naleŜące do krajowego planu
numeracji” moŜliwości jego zachowania w przypadku zmiany przedsiębiorcy świadczącego
usługę’’ natomiast w Pt jest zapis o uprawnieniu dla abonenta będącego stroną umowy z
dostawcą usług zapewniającym przyłączenie do publicznej sieci telefonicznej. Wymagana jest
11
zmiana w tym zakresie zapisów ustawy Pt w art. 71. odpowiednio do zapisów ww.
Dyrektywy.
2.3. Obowiązki w zakresie przenoszenia numeru wynikające z Dyrektyw Unijnych
Podstawy prawne dla funkcjonowania przenośności numeru w państwach członkowskich UE
wynikają aktualnie z art. 30: ,Ułatwienia przy zmianie dostawcy usług” Dyrektywy
2009/136/WE z dnia 25 listopada 2009r zmieniającej zapisy art. 30: ,,Przenośność numeru”
dyrektywy o usłudze powszechnej tj. Dyrektywy 2002/19/WE.
Art.30 aktualnej dyrektywy (2009/136/WE) zawiera w porównaniu do zapisów art.30
dyrektywy 2002/19/WE zmiany i rozszerzenia. Został zmieniony zapis w punkcie 1,
nieznacznie przeredagowany i uściślony punkt 2, a ponadto zostały rozszerzone zapisy przez
dodanie punktów 4,5,6, wprowadzono równieŜ zapis do Załącznika I (część C).
1. Punkt 1 – wprowadza zapis o obowiązku państw członkowskich zapewnienia
wszystkim abonentom posiadającym numery z planu numeracji telefonicznej
moŜliwości zachowania dotychczasowego (-ych) numeru (-ów) niezaleŜnie od
przedsiębiorstwa świadczącego usługę. Wyeliminowany został zapis ,,wszyscy, którzy
sobie tego Ŝyczą abonenci publicznie dostępnych usług telefonicznych ” występujący
w art. 30 dyrektywy o usłudze powszechnej z 2002r, a ponadto zapis dotyczący
wprowadzenia w Ŝycie przepisów o przenoszeniu numerów, o których mowa w
punkcie 1, art. 30 tejŜe dyrektywy został przeniesiony do części C załącznika I do
dyrektywy 2009/136/WE i określa zakres zastosowania przenośności:
-
dla numerów geograficznych – w określonym miejscu,
-
dla numerów niegeograficznych – w dowolnym miejscu
oraz wskazuje, Ŝe zapisów części C załącznika I nie stosuje się do przenoszenia
numerów między sieciami świadczącymi usługi stacjonarne, a sieciami telefonii
komórkowej.
,,1. Państwa członkowskie zapewniają, aby wszyscy abonenci posiadający
numery naleŜące do krajowego planu numeracji telefonicznej mogli na swój
wniosek zachować dotychczasowy numer lub dotychczasowe numery
niezaleŜnie od tego, które przedsiębiorstwo świadczy usługę, zgodnie z
przepisami części C załącznika I.”
2. Punkt 4– rozszerza zapisy art. 30 dyrektywy o usłudze powszechnej z 2002r i obliguje
do przeprowadzania procesu przenoszenia numeru i jego ponownej aktywacji w jak
najkrótszym czasie oraz wyznacza czas aktywacji u nowego przedsiębiorstwa w ciągu
jednego dnia roboczego. Ponadto wprowadza zapisy dotyczące ochrony abonentów w
trakcie przenoszenia numeru, umoŜliwiające właściwym organom krajowym
zastosowanie środków zabezpieczających abonentów przed naduŜyciami, w tym przez
nakładanie na przedsiębiorstwa odpowiednich kar i obowiązek wypłaty abonentom
rekompensaty.
,,4. Przenoszenie numerów, a następnie ich aktywacja przeprowadzane są w
jak najkrótszym czasie. W kaŜdym przypadku abonenci, którzy zawarli umowę
w sprawie przeniesienia numeru do nowego przedsiębiorstwa, mają
aktywowany numer w ciągu jednego dnia roboczego.
Bez uszczerbku dla akapitu pierwszego właściwe organy krajowe mogą
ustanowić ogólne zasady procesu przenoszenia numerów, uwzględniając
krajowe przepisy o umowach, moŜliwości techniczne oraz potrzebę
12
zachowania ciągłości usług świadczonych abonentowi. W kaŜdym przypadku
brak usługi w trakcie procesu przenoszenia nie przekracza jednego dnia
roboczego. Właściwe organy krajowe uwzględniają takŜe w razie potrzeby
środki zapewniające ochronę abonentów w trakcie przenoszenia numeru oraz
zapewniają, aby ich numery nie były przenoszone do innego dostawcy usług
wbrew ich woli.
Państwa członkowskie zapewniają, aby przewidziane zostało nakładanie na
przedsiębiorstwa odpowiednich kar, w tym obowiązek wypłaty abonentom
rekompensaty w przypadku opóźnień w przenoszeniu numerów lub naduŜyć w
tym zakresie, spowodowanych przez te przedsiębiorstwa lub w ich imieniu.”
3. Punkt 2 – zapis punktu nieznacznie zmieniony pod względem redakcyjnym i uściślony
w porównaniu do zapisu punktu 2 w art. 30 dyrektywy o usłudze powszechnej z
2002r.
,,2. Krajowe organy regulacyjne zapewniają, aby ceny ustalane przez
operatorów lub dostawców usług związane z przenoszeniem numerów były
zorientowane na koszty oraz aby bezpośrednie obciąŜenia abonentów, jeśli
takie są, nie zniechęcały abonentów do zmiany.”
4. Punkt 3 – pozostał niezmieniony i dotyczy działań organów regulacyjnych w zakresie
taryf i zachowania przy tym warunków konkurencji.
„3. Krajowe organy regulacyjne nie narzucają taryf detalicznych za
przenoszenie numerów w sposób, który zakłócałby konkurencję, na przykład
przez ustanawianie szczególnych lub wspólnych taryf detalicznych. ”
5. Punkt 5 – rozszerzenie zapisów w porównaniu do art. 30 dyrektywy o usłudze
powszechnej z 2002r. - wprowadzony nowy punkt, którego zapis ma na celu ochronę
interesu konsumenta w zakresie podpisywania umów z przedsiębiorcami i okresu
świadczenia usług.
,,5. Państwa członkowskie zapewniają, aby umowy zawierane między
konsumentami a przedsiębiorstwami świadczącymi usługi łączności
elektronicznej nie wprowadzały początkowego okresu zobowiązania
przekraczającego 24 miesiące. Państwa członkowskie zapewniają równieŜ, aby
przedsiębiorstwa oferowały uŜytkownikom moŜliwość podpisania umowy na
okres nieprzekraczający 12 miesięcy”
6. Punkt 6 - rozszerzenie zapisów w porównaniu do art. 30 dyrektywy o usłudze
powszechnej z 2002r. - wprowadzony nowy punkt, którego zapis ma na celu, aby
sposób rozwiązywania umów z przedsiębiorcami nie wpływał niekorzystnie na
moŜliwość zmiany przez abonenta dostawcy usług.
,,6. Bez uszczerbku dla jakiegokolwiek minimalnego okresu obowiązywania
umowy państwa członkowskie zapewniają, aby warunki i procedury
rozwiązania umowy nie zniechęcały do zmiany dostawców usług.”
2.4. Wnioski z zapisów Dyrektywy 2009/136/WE
1. Dyrektywa 2009/136/WE, zgodnie z zasadą neutralności technologicznej, nie
wskazuje technologii sieci, której dotyczy obowiązek zapewnienia przenośności
numeru, nie odnosi się do Ŝadnej technologii, w tym równieŜ technologii VoIP.
13
2. Dyrektywa 2009/136/WE nie wyróŜnia rodzaju sieci (np. stacjonarna, ruchoma).
Natomiast w załączniku I wskazano, Ŝe obowiązek nie dotyczy przenoszenia numerów
pomiędzy sieciami stacjonarnymi i telefonii komórkowej.
3. Dyrektywa 2009/136/WE obliguje państwa członkowskie do zapewnienia wszystkim
abonentom, którzy posiadają numery naleŜące do krajowego planu numeracji dla
publicznych sieci telefonicznych moŜliwości jego zachowania w przypadku zmiany
przedsiębiorcy świadczącego usługę.
4. Skoro tekst Dyrektywy 2009/136/WE nie wyróŜnia technologii sieci, a wskazuje
jedynie na fakt posiadania przez abonenta numeru z planu numeracji krajowej to z
tego wynika, Ŝe obowiązek realizacji przenośności numeru dotyczy kaŜdej
technologii, w jakiej dostarczana jest usługa, a więc i technologii VoIP.
5. W konsekwencji, moŜna wnioskować, Ŝe obowiązek zapewnienia przenośności
numerów przydzielonych abonentom z krajowego planu numeracji mają wszyscy
dostawcy usług, w tym w dostawcy usług technologii VoIP.
6. Dyrektywa dotyczy wszystkich abonentów, bez wprowadzania rozgraniczeń (np. na
abonentów indywidualnych i abonentów biznesowych.
7. Obowiązek ten dotyczy wszystkich abonentów, a więc i wszystkich abonentów
korzystających z technologii VoIP.
8. Dyrektywa nie posługuje się pojęciem ,,przyłączenia do publicznej sieci telefonicznej”
stosowanym w Pt oraz w Rozporządzeniu z dnia 17 czerwca 2009 r. w sprawie
warunków korzystania z uprawnień w publicznych sieciach telefonicznych.
9. W świetle zmienionej dyrektywy wymagana jest zmiana Pt w sprawie realizacji
uprawnień abonentów.
3. Analiza stanu aktualnego przenoszenia numerów dla usług w
technologii VoIP realizowanych przez krajowych dostawców usług
3.1. Publiczne usługi telefonicznie świadczone w technologii VoIP
Usługi w technologii VoIP realizowane są głównie z wykorzystaniem protokołu SIP.
Stosowane są takŜe protokoły IAX2, H.323 lub firmowe, przy czym obserwowana jest
tendencja do przechodzenia na protokół SIP.
Przez większość dostawców usług w technologii VoIP oferowana jest telefonia internetowa
(nomadyczna), która moŜe być uŜywana w dowolnej sieci oferującej dostęp do Internetu
(takŜe w sieci ruchomej) w kraju i zagranicą. Dostawcy nie stosują Ŝadnych ograniczeń
realizacji usług w zaleŜności od adresu IP, co powoduje, Ŝe dany numer moŜe być
wykorzystywany w dowolnej sieci i lokalizacji na świecie. KaŜdy uŜytkownik ma przyznany
jeden numer telefoniczny. W większości przypadków usługa w technologii VoIP i sieci
dostępowe dostarczane są przez róŜne podmioty. Wyjątkiem jest telefonia VoIP świadczona
w sieci operatora z wykorzystaniem urządzenia pośredniczącego zarządzanego przez
operatora. Klient moŜe przenieść urządzenie do innej lokalizacji tylko w sieci operatora
świadczącego usługę. Numer telefoniczny związany jest z danym urządzeniem dostępowym.
Usługa stacjonarnej sieci telefonicznej określana jako POTS, która dostarcza styk analogowy
a/b, w określonej stałej lokalizacji z wykorzystaniem geograficznego numeru telefonicznego
mimo, Ŝe wewnątrz sieci realizowana jest w technologii VoIP nazywana telefonią stacjonarną
IP ma obowiązek przenoszenia numerów. Została tu wymieniona z uwagi na uwarunkowania
14
związane ze współpracą międzyoperatorską właściwą do dostawców usług w technologii
VoIP oraz postępujący rozwój w zakresie rozwiązań NGN / IMS.
Jako urządzenia końcowe mogą być wykorzystywane:
- oprogramowanie typu softphone,
- bezprzewodowe telefony VoIP,
- przewodowe telefony VoIP,
- bramki VoIP ze stykiem a/b umoŜliwiającym dołączenie aparatu telefonicznego,
- urządzenia wielofunkcyjne - łączące funkcje modemu (opcjonalnie) xDSL,
rutera z wbudowanym punktem dostępowym sieci bezprzewodowej,
- telefony komórkowe - obsługujące sieć bezprzewodową WiFi umoŜliwiające
zarejestrowanie konta VoIP i korzystanie bez dodatkowych urządzeń.
Dla klientów biznesowych jest świadczona jest usługa pod nazwą handlową SIP trunking,
umoŜliwiająca dołączenie do sieci central abonenckich IP-PABX-ów jako alternatywa dla
tradycyjnych dołączeń PBX-ów w technologii komutacji łączy. Usługa jest realizowana
głównie za pośrednictwem sieci Internet oraz takŜe sieci IP VPN, co umoŜliwia zapewnienie
jakości usług. W usłudze mogą być wykorzystywane blok numeracji i (dodatkowo bez
ograniczeń liczby) pojedyncze numery telefoniczne, które mogą być takŜe numerami
przeniesionymi.
3.2. Aktualny stan przenoszenia numerów telefonicznych z uwzględnieniem usług w
technologii VoIP
Aktualnie większość z dostawców publicznych usług telefonicznych realizowanych w
technologii VoIP stosuje przenoszenie numerów (z ograniczeniami). Głównie realizowane
jest przenoszenie numerów z sieci PSTN do usług w technologii VoIP, a nie odwrotnie.
Pozostali konsultowani dostawcy usług VoIP rozwaŜają wprowadzenie przenoszenia
numerów, ale tego nie realizują ze względu na:
-
brak moŜliwości technicznych ze względu na metodę OR,
-
korzyści biznesowe,
-
małe zapotrzebowanie klientów,
-
kosztów wdroŜenia i obsługi,
-
moŜliwości aktualnie uŜywanej platformy VoIP.
Przenoszenie numerów realizowane jest w zakresie numeracji geograficznej we wszystkich
49 strefach numeracyjnych.
Dla WST= 39 z zakresu numeracji przeznaczonej dla usług w technologii VoIP przenoszenie
numerów nie jest realizowane przez dostawców usług.
Przenoszenie ww. numerów jest realizowane w następujących wariantach np.
-
bez ograniczeń jako Dawca i jako Biorca, jeśli obaj przedsiębiorcy dysponują punktem
styku w sygnalizacji SS7 – dotyczy to usług realizowanych w sieci PSTN i w
technologii VoIP,
-
z ograniczeniami - przenośność numerów realizowana jest w ramach danej grupy
dostawców usług VoIP korzystających ze wparcia w zakresie obsługi numeracji przez
danego operatora,
15
-
z ograniczeniami - jednostronnie z wybranych sieci PSTN do usług realizowanych
przez dostawcę w technologii VoIP.
Ograniczenia wynikają z opisanych wcześniej uwarunkowań technicznych oraz zakresu
podpisanych umów międzyoperatorskich.
Jeśli przenoszenie jest realizowane, dostawcy usług w technologii VoIP zamieszczają
informację na stronie WWW.
W przypadku, gdy zakres numeracji danego dostawcy usługi obsługiwany jest przez operatora
zewnętrznego wymagany jest proces weryfikacji i potwierdzenie przez tego operatora
moŜliwości przeniesienia numeru.
Operatorzy zewnętrzni realizują przenoszenie numerów dla dostawców usługi w technologii
VoIP, którym udostępniają swój zakres numeracji.
Problemy dla róŜnych scenariuszy przenoszenia numerów opisano w punkcie 5.
3.3. Warianty stosowanych rozwiązań sieciowych platform VoIP z uwzględnieniem
współpracy międzysieciowej pod kątem przenoszenia numerów
Rozwiązania sieciowe VoIP występujące u operatorów są róŜnorodne i uzaleŜnione są od
następujących czynników:
- rodzaju świadczonej usługi w zaleŜności od rodzaju klienta: indywidualnego,
biznesowego, hurtowego,
- świadczenia stacjonarnej usługi telefonicznej i posiadania infrastruktury z
komutacją łączy,
- sposobu świadczenia usług w technologii VoIP,
- sygnalizacji stosowanej na łączach międzyoperatorskich,
- rodzaju współpracy z innymi operatorami w procesie realizacji usług.
ZauwaŜalny jest trend wykorzystywania łączy międzyoperatorskich z sygnalizacją SIP.
WyróŜniono następujące warianty modeli rozwiązań sieciowych:
1. Platforma VoIP wykorzystująca dla połączeń międzyoperatorskich tylko styk z
protokołem IP w sygnalizacji SIP. Dla realizacji przenoszenia numerów w obecnie
stosowanej metodzie wykorzystywane są z usług operatorów zewnętrznych
posiadających styk w sygnalizacji SS7, którzy realizują rozgłaszanie numeracji.
Operatorzy zewnętrzni mogą takŜe wykonywać funkcje dodatkowe np. taryfikację
połączeń, kierowanie połączeń na numery alarmowe. Stosowane jest oprogramowanie
platform VoIP komercyjne i typu open-source. Współpraca poprzez łącza w
sygnalizacji SIP umoŜliwia wymianę ruchu telefonicznego w technologii VoIP bez
pośrednictwa sieci PSTN/ISDN i poprzez to stworzenie warunków konkurencyjności
co prowadzi do obniŜenia kosztów połączeń między operatorskich.
2. Dwie platformy (komutacji łączy i VoIP), które ze sobą współpracują. Łącza
międzyoperatorskie realizowane są z wykorzystaniem protokołów SS7 i SIP.
Platforma VoIP pozwala na świadczenie usług bezpośrednio dla klientów, innych
dostawców usług oraz resellerów. Stosowane są platformy NGN (np. NGN
Broadworks firmy Broadsoft, Huawai Softswitch, firmy Alcatel-Lucent) W tym
rozwiązaniu operatorzy za pomocą łączy w sygnalizacji SS7 mogą realizować
przenoszenie numerów dla ruchu telefonicznego kierowanego za pośrednictwem sieci
PSTN/ISDN dla swoich abonentów. W przypadku tranzytowania ruchu innych
16
operatorów w sygnalizacji w protokole SIP do sieci PSTN/IDSN jest takŜe wspierana
przenośność numerów, jeśli zakres numeracji tych operatorów będzie obsługiwany i
rozgłaszany przez ww. platformy.
3. Platforma VoIP obsługująca tylko abonentów danego operatora współpracująca z
operatorami zewnętrznymi tylko poprzez łącze w sygnalizacji SS7 i wymiana ruchu
telefonicznego realizowana jest tylko za pośrednictwem sieci PSTN/ISDN – np.
operator sieci telewizji kablowej. W porównaniu funkcjonalnym biorąc pod uwagę
współpracę między sieciową jest to rozwiązanie podobne do sieci PSTN/ISDN.
Przykładowo współpraca platform VoIP i komutacji łączy zastosowanej u jednego z
dostawców usług w technologii VoIP odbywa się następująco:
-
połączenie przychodzące z sieci własnej (oraz z sieci innych operatorów dla zakresu
numeracji uŜywanego przez usługę VoIP) są kierowana na MediaGateway, który
rozdziela ruch na platformę z komutacją łączy lub VoIP,
-
jeśli platforma VoIP stwierdzi, Ŝe numer został przeniesiony to połączenie jest
przekierowane. Zwracany jest do MediaGateway numer poprzedzony kodem
rutingowym NR NP.
Z przeprowadzonych analiz rozwiązań sieciowych wynika występowanie następujących
tendencji:
-
szerokiego stosowania połączeń międzyoperatorskich z zastosowaniem sygnalizacji
SIP, jako bardziej funkcjonalnych i korzystnych ekonomicznie, zamiast w sygnalizacji
SS7 (w sygnalizacji SIP nie jest stosowana metoda przenoszenia numerów OR),
-
wdraŜanie platform NGN z funkcjami współpracy ENUM, które to funkcje będą
mogły być wykorzystane do realizacji przenoszenia numerów.
3.4. UŜywany zakres i sposób korzystania z numeracji
Dostawcy usług w technologii VoIP wykorzystają przewaŜnie bloki numerów geograficznych
w róŜnych strefach numeracyjnych stacjonarnej publicznej sieci telefonicznej.
Dostawcy usług w technologii VoIP uŜywają takŜe innych form adresacji. Dodatkowo
uŜytkownicy mogą mieć przyznany numer telefoniczny, i wtedy usługa nosi znamiona
publicznej usługi telefonicznej i moŜe realizować uprawnienia w zakresie przenoszenia
numerów.
Wykorzystanie numeracji geograficznej wynika m.in. z faktu, Ŝe usługi VoIP zostały
wcześniej uruchomione, przed wyodrębnieniem w PNK-TF numeracji dla usług
wykorzystujących technologię IP.
Dostawcy usług w technologii VoIP mimo, Ŝe mają przyznane numery z zakresu numeracji
WST=39 przeznaczonego dla technologii VoIP, nie wykorzystują ich.
Wśród zgłaszanych problemów są trudności ze współpracą międzyoperatorską wynikające z
konieczności podpisania dodatkowych umów na wymianę ruchu.
Dodatkowy problem to konieczność dołączenia do punktów styków w kraju. Ma to istotny
wpływ na dołączenie sieci mniejszych operatorów, którzy będą musieli zestawić łącze do
jednego z punktów styku.
W przypadku wykorzystywania sygnalizacji SIP przez dostawcę usług w technologii VoIP
obsługa zakresu numeracji realizowana jest przez operatora zewnętrznego, który realizuje
tranzyt ruchu do sieci PSTN/ISDN.
17
Stosowane są dwa warianty obsługi bloków numeracji przy współpracy z operatorami
realizującymi połączenia międzysieciowe w sygnalizacji SIP:
- dostawca usług w technologii VoIP korzysta z bloku numeracji zgodnie z
umową o udostępnieniu numeracji,
- dostawca usług w technologii VoIP przekazuje do obsługi przyznany przez
UKE blok numeracji do obsługi przez operatora zewnętrznego.
Przenośność numerów oprócz rozwiązań technicznych sieci to takŜe realizacja procedur
przenoszenia numerów wymagająca obsługi przez systemy informatyczne.
WdroŜenie i eksploatacja przenoszenia numerów jest duŜym obciąŜeniem dla małych
operatorów i wymaga współpracy z operatorami zewnętrznymi, którzy obsługują dany zakres
numeracji. Wymaga takŜe podpisania umów z operatorami, co dla małych operatorów z
uwagi na małą skalę jest nieopłacalne biznesowo. Mali operatorzy z uwagi na złoŜoność i
wysokie koszty obsługi procesów muszą korzystać ze wsparcia operatorów zewnętrznych.
Dostawcy usług w technologii VoIP korzystają zgodnie z umową o udostępnienie numeracji z
zakresu przydzielonego dla kilku operatorów. W tym przypadku numerację kreuje i rozgłasza
jeden z operatorów.
Konieczność korzystania z numeracji na podstawie umowy o uŜyczenie numeracji ogranicza
swobodę działania dostawców usług w technologii VoIP, gdyŜ przeniesienie numeru jest
uzaleŜnione od operatora uŜyczającego numerację i wymaga jego zgody oraz wymaga
kierowania ruchu przez sieć tego operatora.
W chwili obecnej, ze względu na powszechność umów o uŜyczenie numeracji, praktycznie
niemoŜliwe jest ustalenie właściciela numeracji w kontekście odpowiedzialności w procesie
jej przenoszenia.
Dostawcy usług w technologii VoIP planują przejąć bloki numeracji od innych operatorów, z
których korzystają zgodnie z umową udostępnienia. Wymaga to uwolnienia bloku numeracji i
wystąpienia o przydział numeracji przez dostawców usług w technologii VoIP do Urzędu
Komunikacji Elektronicznej.
Biorąc pod uwagę realizowaną centralną bazy numerów przeniesionych i wykorzystanie jest
przez dostawców usług w technologii VoIP zostanie oddzielony proces zarządzania i obsługi
przenoszenia numerów od tranzytowania ruchu telefonicznego.
4. Realizacja techniczna przenoszenia numerów
4.1. Metody realizacji przenoszenia numerów
Realizacja przenośności numerów w sieciach telefonicznych jest moŜliwa przy zastosowaniu
następujących metod technicznych:
-
przekierowania połączenia OR (Onward Routing),
-
połączenia zwróconego CDB (Call Drop Back),
-
zapytania przy braku połączenia QoR (Query on Release),
-
zapytania dla wszystkich połączeń ACQ (All Call Query).
Metoda OR polega na kierowaniu połączenia od abonenta inicjującego połączenie do numeru
przeniesionego za pośrednictwem sieci operatora Macierzystego. Na poziomie centrali, w
której przed przeniesieniem był przyłączony abonent numeru przeniesionego zostaje dodany
do numeru przydzielonego numer rutingowy, umoŜliwiający kierowanie połączenia na numer
18
przeniesiony do sieci biorcy. Przez cały czas trwania połączenia wykorzystywane są zasoby
sieci Dawcy.
W metodzie CDB centrala abonenta wywołującego kieruje połączenie sygnalizacyjne do sieci
Dawcy. Centrala dawcy stwierdza, Ŝe wybrany numer został przeniesiony i centrala ta zwraca
do centrali inicjującej połączenie informację o przeniesieniu numeru wraz z identyfikatorem
centrali Biorcy. Na tej podstawie centrala inicjująca zestawia połączenie do sieci biorcy (bez
dalszego angaŜowania sieci Dawcy). Dawca prowadzi bazę danych zawierającą
aktualizowane informacje o sieci, do której przenieśli numery jego pierwotni abonenci.
Dawcą jest przedsiębiorca telekomunikacyjny, świadczący usługi w publicznej sieci
telefonicznej, którego abonent wykorzystywał numer przydzielony przed dokonaniem
przeniesienia tego numeru przydzielonego do innego przedsiębiorcy telekomunikacyjnego
świadczącego usługi w publicznej stacjonarnej sieci telefonicznej. Biorcą jest przedsiębiorca
telekomunikacyjny świadczący usługi w publicznej sieci telefonicznej, do którego abonent
zamierza przenieść lub przeniósł numer przydzielony.
Metoda QoR polega na tym, Ŝe połączenie jest początkowo kierowane do sieci dawcy. JeŜeli
centrala dawcy stwierdzi, Ŝe numer został przeniesiony, to zwraca informację o braku
moŜliwości zastawienia połączenia. Wówczas centrala inicjująca (lub tranzytowa) wysyła
zapytanie do centralnej bazy danych numerów przeniesionych i na podstawie otrzymanej
odpowiedzi zestawia połączenie do sieci biorcy. Siecią Dawcy jest publiczna sieć telefoniczna
przedsiębiorcy telekomunikacyjnego, którego abonent wykorzystywał numer przydzielony
przed dokonaniem przeniesienia tego numeru przydzielonego do sieci innego przedsiębiorcy
świadczącego
usługi
w
publicznej
stacjonarnej
sieci
telekomunikacyjnego
telekomunikacyjnej. Siecią Biorcy jest publiczna sieć telefoniczna przedsiębiorcy
telekomunikacyjnego, do którego abonent zamierza przenieść lub przeniósł swój numer
przydzielony.
W metodzie ACQ centrala inicjująca przed kaŜdym zestawieniem połączenia przesyła
zapytanie do bazy danych (centralnej lub lokalnie replikowanej). Jeśli numer został
przeniesiony otrzymuje ona numer rutingowy dla potrzeb kierowania do centrali docelowej
obsługującej wywoływanego abonenta. Metoda ACQ wymaga centralnej bazy danych, która
zwykle jest zarządzane przez wydzielony podmiot.
Przy realizacji metody OR obowiązki spadają na Operatora Macierzystego a dla metody ACQ
na kaŜdą stronę inicjującą połączenie a takŜe na podmiot organizujący CBD NP.
W połączeniach krajowych metoda OR stosowana jest w sieciach stacjonarnych i metoda
ACQ w sieciach ruchomych. Planuje się, Ŝe w krajowej publicznej sieci stacjonarnej po
wdroŜeniu platformy PLI CBD będzie wykorzystywana w połączeniach krajowych metoda
ACQ.
4.2. Aktualnie stosowana metoda przenoszenia numerów w sieci krajowej dla usług
telefonicznych realizowanych w technologii VoIP
Aktualnie stosowaną metodą przenoszenia numerów w sieci stacjonarnej jest metoda OR
(Onward Routing).
Metoda OR polega na kierowaniu połączeń w tradycyjny sposób na podstawie początkowych
cyfr numeru telefonicznego. W przypadku, gdy numer został przeniesiony do innego
operatora (lub sieci), połączenie kierowane jest najpierw do sieci Macierzystej. Sieć ta
dysponuje informacją, do której centrali innego operatora przeniesiony jest numer i kieruje
połączenie dalej z wykorzystaniem numeru rutingowego RN NP. (Routing Number). Numer
RN jest kodem unikalnym, jednoznacznie identyfikującym docelową sieć i centralę.
19
Tak więc sieć Macierzysta bezpośrednio uczestniczy w kaŜdym połączeniu zestawionym na
przeniesiony numer.
Metoda OR jest stosowana w początkowych fazach wdraŜania przenośności numerów, kiedy
liczba numerów przeniesionych jest jeszcze relatywnie niewielka.
Połączenie moŜe być zestawiane bezpośrednio z sieci Macierzystej do Sieci Biorcy, o ile
istnieje połączenie międzyoperatorskie między siecią Dawcy i Biorcy, a w przeciwnym
przypadku przez innego operatora zapewniającego tranzyt ruchu.
Metoda ta nie pozwala na określenie sieci, która jest uŜytkownikiem danego numeru i w
związku z tym nie pozwala na określenie wysokości ponoszonych kosztów za terminowanie
połączenia.
Platformy VoIP nie są dostosowane do uŜywania metody ACQ (All Call Query) ani QoR
(Query on Release) i będą wymagać dodatkowych nakładów na dostosowanie. Przy
niewielkiej skali realizowanych przenośności dostosowanie ich do realizacji metod ACQ lub
QoR moŜe być nieuzasadnione ekonomicznie.
Potencjalnie platformy VoIP u części dostawców stosowane w sieci krajowej dostosowane są
do współpracy z ENUM. Jednak wdroŜenie funkcjonalności będzie wymagało nakładów
inwestycyjnych.
Wynika z tego, Ŝe optymalnym docelowych rozwiązaniem byłoby wykorzystanie usługi
ENUM dla potrzeb przenoszenia numerów dla usług realizowanych w technologii VoIP, a
numer rutingowy NR NP byłby tworzony zgodnie z rozporządzeniem [2].
Zasady adresowania dla właściwego kierowania połączeń w zakresie numeracji słuŜącej
realizacji uprawnień abonenta i uŜytkownika do przenoszenia przydzielonego numeru
pomiędzy operatorami oraz format numeru rutingowego (NR NP) określa Rozporządzenie
Ministra Infrastruktury z dnia 9 stycznia 2008 r. w sprawie szczegółowych wymagań
dotyczących zasad adresowania dla właściwego kierowania połączeń (Dz. U. z dnia 29
stycznia 2008 r.).
1. Zasady adresowania dla właściwego kierowania połączeń w zakresie numeracji
słuŜącej realizacji uprawnień abonenta i uŜytkownika do przenoszenia przydzielonego
numeru pomiędzy operatorami ustalają:
-
numer rutingowy (NR NP) zamieszcza się w parametrze Called Party Number
wiadomości IAM (Initial Address Message) przed numerem abonenta B (tryb
połączony "concatenated"),
-
parametr NoA (Nature of Address) przyjmuje wartość 3,
-
adresowanie metodą "en-bloc",
-
numer rutingowy (NR NP) dołącza się po odpytaniu bazy dla numerów
przeniesionych; dopuszcza się dołączenie numeru rutingowego (NR NP) po
odpytaniu bazy dla numerów nie przeniesionych.
gdzie:
parametr Called Party Number - parametr stosowany w Systemie
Sygnalizacji ITU-T nr 7 (SS7), zawarty w wiadomości IAM,
zawierający w szczególności zakodowany numer abonenta
wywoływanego,
20
wiadomość IAM (Initial Address Message) - wiadomość zawarta w
protokole ISUP (ISDN User Part), przesyłana w procesie zestawiania
połączenia,
parametr NoA (Nature of Address) - wskaźnik określający typ adresu.
adresowanie metodą "en-bloc" - sposób adresowania polegający na
równoczesnym przekazywaniu wszystkich cyfr numeru abonenta, przez
umieszczenie ich w jednym bloku wiadomości przesyłanych w procesie
zestawiania połączenia,
„C” hex - zapis liczby za pomocą systemu szesnastkowego,
ZT - po dojściu ZT do wartości 99 ustala się inny wolny AB dla danej
SN,
HOST (HOST - ID) - numer centrali telefonicznej obsługującej nową
lokalizację abonenta z przeniesionym numerem.
2. Format numeru rutingowego (NR NP) określa się dla numerów geograficznych i
niegeograficznych następujący:
-
NR NP (5 cyfr) = "C hex" + XYZT,
gdzie:
XY = AB = wskaźnik strefy numeracyjnej (X=1-9),
ZT6) = numer HOST (HOST - ID) w danej SN (dla danego AB)
lub
XYZT - numer operatora (X=0).
Dla numerów geograficznych numery rutingowe określone są dla kaŜdej strefy numeracyjnej.
Tabela 4-1 przestawia przykład kodów rutingowych NP
Tabela 4-1 Przykładowy fragment tablicy Zagospodarowania Numeracji - Numery Rutingowe (NR NP)
Tablica Zagospodarowania Numeracji - Numery Rutingowe (NR NP)
(stan na dzień 11 sierpnia 2010 r.)
Numer
rutingow
y (NR
NP)
Lp.
Strefa
numeracyjna
WSN /
AB
698
WARSZAWA
22
WARSZAWA/AX0
Telekomunikacja Polska S.A.
C2244
699
WARSZAWA
22
WARSZAWA/NGN-1
Netia S.A.
C2245
700
WARSZAWA
22
WARSZAWA
Aster Sp. z o.o.
C2246
701
WARSZAWA
22
TARNOWSKIE GÓRY
GALTIM Katarzyna Rakowska
C2247
702
WARSZAWA
22
WARSZAWA
JMDI Jacek Maleszko
C2248
703
WARSZAWA
22
KUTNO II
Multimedia Polska S.A.
C2249
704
WARSZAWA
22
WARSZAWA
Crowley Data Poland Sp. z o.o.
C2250
705
WARSZAWA
22
WARSZAWA
Netia S.A.
C2251
706
WARSZAWA
22
ŁÓDŹ
FORWEB S.C.
C2252
707
WARSZAWA
22
KUTNO
Multimedia Polska S.A.
C2253
Lokalizacja centrali
21
Przedsiębiorca telekomunikacyjny
708
WARSZAWA
22
WARSZAWA
MediaTel S.A.
C2254
709
WARSZAWA
22
PIASECZNO
FONE Sp. z o.o.
C2255
710
WARSZAWA
22
WARSZAWA
Easyconnect Sp. z o.o.
C2256
711
WARSZAWA
22
WARSZAWA
BT Poland Sp. z o.o.
C2257
712
WARSZAWA
22
PIASECZNO/NC4
GTS Energis Sp. z o.o.
C2258
713
WARSZAWA
22
WARSZAWA/CK MORY3
Exatel S.A.
C2259
714
WARSZAWA
22
OLSZTYN
VECTRA S.A.
C2260
721
WARSZAWA
22
WARSZAWA
Polska Telefonia Cyfrowa Sp. z o.o.
C2267
722
WARSZAWA
22
WARSZAWA
Netia S.A.
C2268
723
WARSZAWA
22
WARSZAWA
Spray S.A.
C2269
724
WARSZAWA
22
WARSZAWA
Długie Rozmowy S.A.
C2270
725
WARSZAWA
22
WARSZAWA/NF1
E-Telko Sp. z o.o.
C2271
726
WARSZAWA
22
WARSZAWA/ND2
Netia S.A.
C2272
727
WARSZAWA
22
PIASECZNO/NC3
GTS Energis Sp. z o.o.
C2273
728
WARSZAWA
22
WARSZAWA
Nettel Systems Sp. z o.o.
C2274
729
WARSZAWA
22
WARSZAWA
Intelligent Technologies S.A.
C2275
730
WARSZAWA
22
WARSZAWA
Intelligent Technologies S.A.
C2276
731
WARSZAWA
22
WARSZAWA
GTS Polska Sp. z o.o.
C2277
732
WARSZAWA
22
WARSZAWA
UPC Polska Sp. z o.o.
C2278
734
WARSZAWA
22
WARSZAWA CTG
Telekomunikacja Kolejowa Sp. z o.o.
C2280
735
WARSZAWA
22
WARSZAWA/NC1
GTS Energis Sp. z o.o.
C2281
C2282
736
WARSZAWA
22
WARSZAWA
UPC Polska Sp. z o.o.
737
WARSZAWA
22
WARSZAWA
MNI S.A.
C2283
738
WARSZAWA
22
ŁÓDŹ
Telefonia Dialog S.A.
C2284
739
WARSZAWA
22
WARSZAWA/CK MYSIA
Exatel S.A.
C2285
740
WARSZAWA
22
WARSZAWA/CK MORY1
Exatel S.A.
C2286
741
WARSZAWA
22
PIASECZNO
GTS Energis Sp. z o.o.
C2287
742
WARSZAWA
22
PIASECZNO
GTS Energis Sp. z o.o.
C2288
743
WARSZAWA
22
WARSZAWA/MS1700XX
Polkomtel S.A.
C2289
747
WARSZAWA
22
WARSZAWA
Netia S.A.
C2293
754
CIECHANÓW
23
CIECHANOW/DC1
Telekomunikacja Polska S.A.
C2301
755
CIECHANÓW
23
CIECHANOW/CZ1
Telekomunikacja Polska S.A.
C2302
756
CIECHANÓW
23
MLAWA/CD1
Telekomunikacja Polska S.A.
C2303
W tabeli numerów NR NP widać, Ŝe umieszczone są m.in. numery operatorów biorących
udział jako „Dawcy” w procesie przenoszenia numerów dla usług w technologii VoIP.
W ww. rozporządzeniu są określone wymagania dla numeru rutingowego (NR NP),
zamieszczanego w parametrze Called Party Number w wiadomości IAM (Initial Address
Message) w sygnalizacji SS7, przed numerem abonenta B. Nie ma wymagań w zakresie
innych rodzajów sygnalizacji, co tym samym wskazuje konieczność stosowania sygnalizacji
SS7 w połączeniach międzyoperatorskich dla połączeń głosowych równieŜ w technologii
VoIP dla realizacji uprawnienia przenoszenia numerów.
Aktualnie we współpracy sieci przy wykorzystaniu sygnalizacji SIP wykorzystuje się
podobne mechanizmy i formaty kodów rutingowych jak w przypadku wiązek SS7. Istotnym
jest, aby platformy VoIP partnerów wspierały takŜe cyfry z zakresu poza dziesiętnego
wykorzystywane w kodach rutingowych.
Proponuje się następujący format adresowania w sygnalizacji SIP, który juŜ jest stosowany
przez dostawców usług:
tel:”+48” + ”C” + XYZT+ KNA
22
gdzie NR NP (5 cyfr) = "C" + XYZT
Przykład numeru dla numeru przeniesionego do sieci PSTN/ISDN TP S.A. będzie
następujący.
tel: +4822C2213223250643
Proponuje się zachowanie zgodności z formatem numeru kierowania alarmowego NKA:
tel: „48” + WSNd (2 cyfry) + ”C” + IDL (3 cyfry)+ AUS = XYZ (3 cyfry)
Przykład numeru kierowania alarmowego dla numeru 112 będzie następujący:
tel: +4822C104112
Stosowany format adresowania dla kierowania połączeń w zakresie numeracji słuŜącej
realizacji uprawnień abonenta i uŜytkownika do przenoszenia przydzielonego numeru
pomiędzy operatorami w sygnalizacji SIP róŜni się od formatu określonego w załączniku w
„§ 3 w punkcie 1) d) w rozporządzeniu Ministra Infrastruktury z dnia 9 stycznia 2008 r. w
sprawie szczegółowych wymagań dotyczących zasad adresowania dla właściwego kierowania
połączeń, poniewaŜ stosowany jest format numeru międzynarodowego z prefiksem znak „+”,
zamiast w formacie numeru krajowego.
Stosowanie formatu numeru międzynarodowego spowodowane jest brakiem wskaźnika
określającego typ adresu, który stosowany jest w sygnalizacji SS7.
W protokole SIP kodowanie numeru telefonicznego odbywa się w formie tekstowej z zgodnie
RFC 3261 (SIP: Session Initiation Protocol). Kodowanie znaków w systemie szesnastkowym
(w tym znaku „C”) jest zgodne RFC 3966 (The tel URI for Telephone Numbers) punkt 5.1.3.
Rozwiązania techniczne w zakresie współpracy sieci z sygnalizacją SIP a siecią PSTN/ISDN
dla realizacji usług głosowych są zestandaryzowane.
Rozszerzenia wprowadzone do protokołu SIP, mają na celu zapewnienie kompatybilnego
współdziałania obu rodzajów sieci w sygnalizacji SS7 i SIP. Rozszerzenia te, to
zaimplementowane w sygnalizacji SIP mechanizmy umoŜliwiające przenoszenie bez strat
informacji i parametrów specyficznych dla sygnalizacji ISUP. Są to mechanizmy określane
jako:
- SIP – T - opracowany przez IETF, opisany w dokumentach RFC 3372 1, RFC
33982 , RFC 35783 i RFC 32044 ,
- SIP – I - opracowany przez ITU-T, przedstawiony w dokumencie Q.1912.55.
Mechanizmy te pozwalają na konwersję informacji pomiędzy sygnalizacjami ISUP i SIP oraz
transparentne przenoszenie ich (w tym wiadomości, parametrów, kodów przyczyn i innych)
1
RFC 3372 - Session Initiation Protocol for Telephones (SIP-T) Context and Architectures, 2002
2
RFC 3398 - Integrated Services Digital Network (ISDN) User Part (ISUP) to Session Initiation Protocol (SIP)
Mapping, 2002
3
RFC 3578 - Mapping of Integrated Services Digital Network (ISDN) User Part (ISUP) Overlap Signalling to
the Session Initiation Protocol (SIP), 2003
4
RFC 3204 - MIME media types for ISUP and QSIG Objects, 2001
5
ITU-T- Q.1912.5 - Interworking between Session Initiation Protocol (SIP) and Bearer Independent Call
Control protocol or ISDN User Part (03/2004)
23
przez sieci przy wykorzystaniu m.in. mapowania wiadomości sygnalizacyjnych oraz
enkapsulacji.
PoniŜej w ramach przykładu przytoczono z dokumentu RFC 3372 diagram ilustrujący
przebieg (i mapowanie) sygnalizacji SIP na ISUP w przypadku zestawiania połączenia z sieci
IP do sieci PSTN.
Rysunek 4-1 Wymiana informacji między w przypadku zestawiania z sieci IP do sieci PSTN (RFC 3372)
Przykłady współpracy pomiędzy dwoma protokołami sygnalizacji - SIP i ISUP oraz
mapowanie sygnalizacji w róŜnych fazach zestawiania połączenia szczegółowo
przedstawione zostały równieŜ w dokumencie ITU-T- Q.1912.5, skąd zaczerpnięto niŜej
podany przykład (Rysunek 4-2).
Rysunek 4-2 Wymiana informacji w fazie zestawiania połączenia i mapowanie sygnalizacji SIP na ISUP w
przypadku połączenia zakańczanego w sieci ISDN (Q.1912.5)
24
5. Problemy wynikające ze scenariuszy przenoszenia numerów w sieci
krajowej dla usług realizowanych w technologii VoIP
W niniejszym rozdziale poddano analizie wybrane scenariusze przenoszenia numerów, w
których jedną ze stron jest usługa realizowana w technologii VoIP:
- PSTN →VoIP,
- VoIP → PSTN,
- PSTN→ VoIP → PSTN,
- VoIP → VoIP.
Zwrócono uwagę na następujące aspekty:
- rodzaj uŜywanego zakresu numeracji – numer geograficzny i niegeograficzny,
- wpływ rodzaju metody przenoszenia numerów, z uwzględnieniem OR,
- rodzaj usługi – usługi PSTN i realizowane w technologii VoIP.
1. Scenariusz PSTN → VoIP
- numer geograficzny – nie ma ograniczeń wynikających z zakresu numeracji,
- PSTN jako sieć „Macierzysta” zapewnia mechanizm obsługi przenoszenia
numerów metodą OR, ruch musi być wymieniany przez punkt styku z siecią
PSTN, aktualnie problemy techniczne nie występują.
2. Scenariusz VoIP → PSTN
- numer geograficzny – przenośność numeru będzie realizowana jeśli wskaźnik
strefy numeracyjnej będzie zgodny ze strefą numeracyjną do której przenoszony
jest numer,
- numer niegeograficzny WST = 39 dla usług realizowanych w technologii VoIP
– nie ma obowiązku przenoszenia, wystąpią problemy techniczne obsługi
numeru przez centrale z komutacją łączy,
- w przypadku zastosowania metody OR rolę sieć Macierzysta jest po stronie
platformy VoIP wymagane połączenie sieciowe z siecią telefoniczną w
sygnalizacji SS7 lub korzystanie przy wymianie ruchu za pośrednictwem
trzeciego operatora, który realizuje tranzyt ruchu i rozgłaszanie numeracji.
3. Scenariusz PSTN → VoIP → PSTN
- numer geograficzny – przenośność numeru będzie realizowana, jeśli wskaźnik
strefy numeracyjnej będzie zgodny ze strefą numeracyjną sieci PSTN, do której
przenoszony jest numer,
- jest to dalsza kontynuacja scenariusza nr 1. Przeniesienie numeru będzie
wymagało zmian ustawień w sieci PSTN, która jako sieć „Macierzysta”
zapewnia mechanizm obsługi przenoszenia numerów metodą OR, ruch musi być
wymieniany przez punkt styku z siecią PSTN - aktualnie problemy techniczne
nie występują. Przenoszenie numeru będzie odbywało się z wykorzystaniem
mechanizmów sieci PSTN.
4. Scenariusz VoIP → VoIP
- numer geograficzny – nie ma ograniczeń wynikających z właściwości numeru,
25
- numer niegeograficzny WST = 39 dla usług realizowanych w technologii VoIP nie ma ograniczeń,
- nie ma moŜliwości wsparcia przenoszenia numerów z wykorzystaniem metody
OR bez pośrednictwa sieci PSTN,
- przenoszenie numerów z wykorzystaniem metody OR moŜe być realizowane
jeśli numery będą numer będzie przenoszony w ramach operatora zewnętrznego,
który będzie rozgłaszał numerację i zapewniał tranzyt do sieci PSTN z
wykorzystaniem punktu styku w sygnalizacji SS7,
- korzystanie z pośrednictwa sieci PSTN spowoduje pogorszenie jakości usługi w
wyniku dodatkowej konwersji sygnału głosowego,
- naleŜy rozwaŜyć zastosowanie metody, która zapewnia korzystanie z centralnej
bazy numerów przeniesionych bez pośrednictwa sieci PSTN.
6. Zastosowania metody QoR w sieci IP w przypadku przenoszenia
numeru pomiędzy sieciami PSTN
Zgodnie z zaleceniem [22], w przypadku zastosowania metody QoR centrala inicjująca
kieruje połączenie do centrali Dawcy z opcjonalnym wskaźnikiem informującym, Ŝe ta
metoda jest moŜliwa do uŜycia. Jeśli centrala Dawcy nie będzie obsługiwać połączenia, to jest
ono rozłączane z podaniem właściwej przyczyny. W odpowiedzi na odebrany wskaźnik
rozłączenia, centrala inicjująca określa informację rutingową w drodze wysłania zapytania do
zewnętrznej bazy danych. Baza danych odpowiada na to zapytanie przesyłając wiadomość
zawierającą numer rutingowy RN (Routing Number).
MoŜliwość zastosowania metody QoR, z udziałem sieci IP działającej na bazie softswitcha
TSS (telephone softswitch), w przypadku przeniesienia numeru między sieciami PSTN
przedstawia podany niŜej scenariusz [30].
1. Inicjująca sieć PSTN odbiera wywołanie od abonenta wywołującego i kieruje je do
urządzenia softswitch, wysyłając wiadomość IAM zawierającą numer abonenta
Ŝądanego w parametrze CdPN (Called Party Numer).
2. W oparciu o analizę cyfr numeru CdPN softswitch określa sieć PSTN, do której
kierowane jest wywołanie zakładając, Ŝe aktualnie rezyduje w niej Ŝądany abonent. W
związku z tym wysyła w kierunku tej sieci wiadomość IAM, zawierającą numer
abonenta Ŝądanego w parametrze CdPN.
3. Po otrzymaniu wiadomości IAM centrala w sieci odbierającej sprawdza, czy numer
CdPN został rzeczywiście przeniesiony do innej sieci oraz opcjonalnie, czy jest to
numer „obsadzony” (czy nie jest wolny). Po rozpoznaniu (w oparciu o odebraną
informację sygnalizacyjną), Ŝe jedna z poprzedzających sieci realizuje funkcję QoR,
centrala odbierająca w sieci PSTN nadaje zwrotnie do softswitcha wiadomość REL z
odpowiednim wskaźnikiem (lub bez), Ŝe numer CdPN został przeniesiony. Z punktu
widzenia przenośności numeru ta sieć jest traktowana jako sieć Dawcy.
4. Softswitch odbiera wiadomość REL i stwierdza, Ŝe poprzednia sieć nie realizuje
metody QoR. W tym scenariuszu softswitch ma dostęp do bazy NPDB zawierającej
kompletny adres sieci odbiorcy (recipient network) przeniesionych numerów. Bazując
na odebranym wskaźniku przyczyny rozłączenia, softswitch generuje zapytanie do
centralnie administrowanej bazy NPDB posługując się w tym zapytaniu numerem
CdPN. Z punktu widzenia przenośności, numer CdPN jest traktowany jako numer
katalogowy.
26
5. Baza danych NPDB odsyła numer rutingowy (RN) stowarzyszony z numerem DDN.
Numer RN wskazuje abonenta przeniesionego do centrali odbiorcy (centrala Biorcy).
6. Softswitch wykorzystuje odebrany numer RN do przekierowania połączenia w stronę
sieci Biorcy, w której on aktualnie rezyduje, umieszczając w wiadomości IAM
wysyłanej tej do sieci kompletną informację adresową tzn. informację zawierającą
zarówno numer DDN, jak i RN.
7. Ostatecznie, kiedy centrala końcowa w sieci PSTN odbiorcy określi swoją własną
informację rutingową, analizują otrzymany numer RN, wykorzystuje numeru DDN do
zestawienia końcowego odcinka połączenia do abonenta Ŝądanego.
Rysunek 6-1 przedstawia postać graficzną tego scenariusza.
Rysunek 6-1 Scenariusz obsługi połączenia do numeru przeniesionego między sieciami PSTN przy
wykorzystaniu metody QoR
7. MoŜliwości zastosowania ENUM dla potrzeb przenoszenia numerów
usług realizowanych w technologii VoIP
MoŜliwości wykorzystania ENUM w przypadku przenośności numerów między róŜnymi
rodzajami sieci zostały opisane w dokumencie „ENUM based Numer Portability in VoIP and
IMS networks” [30]. W tym dokumencie zostały teŜ opisane aspekty dotyczące
przekazywania informacji sygnalizacyjnej z tym związanej, kwestie związane z korzystaniem
z zewnętrznych baz danych numerów przeniesionych oraz ruting w sieci na bazie adresów
„zmapowanych” przy pomocy usługi ENUM.
Usługa ENUM wzbogacona o nową funkcję „pstn enumservice” jest traktowane jako
potencjalne narzędzie rozwiązania problemów związanych z przenośnością numerów w
połączeniach zestawianych poprzez róŜne rodzaje sieci, w tym m.in. z przenośnością
numerów pomiędzy sieciami PSTN i IP oraz rutingiem połączeń w środowisku sieci IP, gdy
informacja o przenośności jest przekazywana za pośrednictwem protokołu SIP.
27
Realizacja przenośności numeru wiąŜe się z realizacją funkcji sygnalizacyjnych i
rutingowych. Ten związek wynika m.in. z potrzeby przekazania w sieci PSTN informacji
związanych z przenośnością w protokołach sygnalizacyjnych (takich jak: ISUP), po
wykonaniu odpowiednich działań w bazie danych NPDB (Number Portability Data Base). W
sieci IP funkcje sygnalizacyjne przejmuje serwer sygnalizacji, który wykorzystuje informacje
związane z przenośnością, odebrane w wiadomościach protokołu ISUP, do określenia trasy
rutingu.
Numer rutingowy jest powiązany z numerem telefonicznym, który został przeniesiony z sieci
Dawcy do sieci obsługującej połączenie (serving network). Sieć Dawcy jest z punktu
widzenia przenośności siecią Początkową (initial network), w której numer telefoniczny jest
przypisany do abonenta zanim jeszcze zostanie przeniesiony do innej sieci. Sieć Obsługująca
(serving network) jest siecią, która w aktualnie realizowanym połączeniu obsługuje
przeniesiony numer. Z numerem telefonicznym, który nie jest przenoszony, nie jest
stowarzyszony Ŝaden numer rutingowy, poniewaŜ „N’ pierwszych cyfr tego numeru moŜe
być wykorzystane do celu rutingu.
Przez sieci IP rozumie się sieci nowej generacji NGN (Next Generation Network), które
charakteryzują się separacją warstwy aplikacyjnej (application layer) i warstwy sterowania
mediami (media control layer).
Podstawowe bloki funkcjonalne sieci NGN tworzą urządzenia takie jak: softswitch, brama
medialna (gateway), brama sygnalizacyjna (signalling gateway) i platforma zarządzania
usługami (service management platform).
Softswitch jest urządzeniem telefonicznym o funkcjonalności tradycyjnej centrali
telefonicznej, zbudowanym na bazie platformy komputerowej z oprogramowaniem o
otwartych standardach. Zapewnia integrację usług głosowych, transmisji danych i wideo oraz
wykonuje translację wiadomości protokołów stosowanych w sieciaci PSTN i IP.
Brama medialna zapewnia komunikację między róŜnymi sieciami (np. sieciami
telefonicznymi i sieciami transmisji danych), przekształcając sygnały uŜytkowe (np z IP na
PCM)
Brama sygnalizacyjna dokonuje translacji wiadomości sygnalizacyjnych do postaci
umoŜliwiającej ich przesłanie w sieci pakietowej.
Platforma zarządzania usługami integruje róŜne systemy zarządzania usługami, w tym
usługami sieci inteligentnej, PSTN, IP itp.
Aby zestawić połączenie do terminala w sieci IP musi być znany adres IP miejsca
przeznaczenia (destination IP address). Alternatywnie, terminal moŜe zostać zidentyfikowany
na podstawie nazwy hosta, która jest przetwarzana na adres IP przez system DNS. W
przypadku, gdy terminale są opatrzone numeracją E.164, usługa DNS moŜe być
wykorzystana do mapowania numerów telefonicznych na adresy sieci IP. MoŜna tego
dokonać tworząc nazwę domenową z numeru E.164 i wykonując przeszukanie rekordów
DNS NAPTR (DNS Naming Authority Pointer), w wyniku którego otrzymuje się wskaźnik
URI, zawierający m.in. nazwę hosta (patrz dok. [19]).
ENUM wykorzystuje do mapowania domeny „e164.arpa”. Numery telefoniczne są
konwertowane na nazwy domen przy uŜyciu procedury opisanej w dokumencie RFC 2916
[17]. Numer E.164 musi być pełnym numerem telefonicznym, zawierającym w szczególności
kod kraju. Wszystkie znaki i symbole są usuwane, pozostawiane są tylko cyfry, pomiędzy
które wstawiane są kropki. Odwracana jest kolejność cyfr i na końcu sekwencji dodawany jest
skrót „e164.arpa”. Przy pomocy takiej procedury moŜna „zmapować” dowolny numer np.
numer +385-1-1234567 na nazwę hosta „7.6.5.4.3.2.1.1.5.8.3.e164.arpa”.
28
W systemie DNS jest gromadzona informacja w postaci róŜnych typów rekordów. Opisany w
standardzie RFC 2915 [18] rekord NAPTR jest wykorzystywany do identyfikacji dostępnych
dróg kontaktu z węzłem o danej nazwie. MoŜe być takŜe uŜyty do identyfikacji usług w
domenie o określonej nazwie.
ENUM definiuje nową usługę E2U (E.164 to URI), która mapuje (odwzorowuje) jeden numer
E.164 na listę wskaźników URI. ENUM moŜe być wykorzystane z powiązaniu z niektórymi
protokołami (np. SIP, SMTP) i moŜe mapować np. numery telefoniczne na adresy poczty
elektronicznej (e-mail).
8. Przenoszenie numerów między róŜnymi rodzajami sieci
Wcześniej nie były stosowane Ŝadne rozwiązania dla przenośności numeru dla usługi
telefonicznej między róŜnymi rodzajami sieci. Obecnie numer, który został przeniesiony do
sieci IP moŜe być obsługiwany w sieci PSTN przy wykorzystaniu procedury przenośności
numeru. W takim przypadku zachodzi potrzeba uŜycia zasobów bazy danych numerów
przeniesionych, przechowującej aktualny numer rutingowy, za pomocą którego połączenie do
numeru przeniesionego jest kierowane do bramy medialnej (gateway).
W procesie zestawiania połączenia telefonicznego między róŜnymi sieciami podstawowym
zadaniem jest określenie rodzaju sieci Docelowej (destination network), poniewaŜ na tej
podstawie odbywa się potem mapowanie nazwy E.164 na adres innego rodzaju sieci.
W przypadku sieci hybrydowej, złoŜonej z wielu sieci PSTN i IP, moŜna wyróŜnić cztery
scenariusze ich współpracy: PSTN-PSTN, PSTN-IP, IP-PSTN i IP-IP.
W przypadku zestawiania połączenia z terminala sieci IP do abonenta sieci PSTN, którego
numer został przeniesiony do innej sieci IP i jest wykorzystywana metoda QoR, współpraca
między zaangaŜowanymi sieci (za pośrednictwem sieci IP opartej na softswitch’u) przebiega
wg podanego niŜej scenariusza.
1. Softswitch odbiera w protokole SIP z sieci IMS wiadomość INVITE z Ŝądaniem
„Request-URI” identyfikacji abonenta Ŝądanego, który jest opisany przez wskaźnik
„tel URI” zawierający numer CdPN.
2. Analiza numeru (adresu) w softswitch’u polega na tym, Ŝe dla kaŜdego połączenia jest
przeszukiwana zewnętrzna baza danych rekordów NAPTR w celu identyfikacji
dostępnych usług powiązanych z odebranym numerem E.164.
3. W oparciu o dostarczony numer CdPN tworzona jest nazwa domeny, która zostaje
wykorzystana w zapytaniu skierowanym do zewnętrznego systemu DNS.
4. W odebranej z DNS odpowiedzi sofstwitch dokonuje selekcji rekordów, wybierając te
rekordy NAPTR, które wspierają działanie usługi E2U tzn. takie, które wskazują
numer telefoniczny preferencyjnie powiązany za pomocą wskaźnika „tel URI”.
5. Odebrany z DNS wskaźnik „tel” URI zawiera numer taki sam jak oryginalny numer
CdPN. W oparciu o analizę numeru CdPN softswitch określa, Ŝe połączenie powinno
zostać skierowane do końcowej sieci PSTN (terminating PSTN network), w której
zakłada, Ŝe obecnie rezyduje abonent Ŝądany. Na tej podstawie w kierunku końcowej
sieci PSTN wysyła wiadomość IAM z numerem CdPN.
6. Po odebraniu wiadomości IAM, centrala w sieci odbierającej (receiving PSTN
network) sprawdza, Ŝe numer CdPN został przeniesiony do innej sieci i nadaje
zwrotnie do softswitcha wiadomość REL z odpowiednim wskaźnikiem informującym
o tym fakcie. Z punktu widzenia przenośności numeru ta sieć jest traktowana jako sieć
Dawcy (donor network).
29
7. Softswitch przejmuje wiadomość REL i bazując na wskaźniku przyczyny rozłączenia,
generuje zapytanie do centralnie administrowanej bazy NPDB umieszczając w
zapytaniu numer CdPN. Z punktu widzenia przenośności numeru, numer CdPN jest
traktowany jako numer katalogowy.
8. Baza danych NPDB odsyła numer rutingowy (RN) stowarzyszony z numerem DDN.
9. Softswitch wykorzystuje odebrany numer RN do wybrania właściwej bramy medialnej
dla ponownego rutingu połączenia w kierunku sieci odbiorcy VoIP/IMS (receipient
VoIP/IMS network), umieszczając w wiadomości IAM (wysyłanej do sieci odbiorcy)
kompletną informację adresową tzn. informację zawierającą zarówno numer DDN, jak
i RN.
Rysunek 8-1 przedstawia postać graficzną scenariusza obsługi połączenia, gdy numer
telefoniczny został przeniesiony między róŜnymi rodzajami sieci.
Rysunek 8-1 Scenariusz obsługi połączenia do numeru przeniesionego z sieci PSTN do sieci IP przy
wykorzystaniu metody QoR
Z przedstawionego wyŜej scenariusza wynika, Ŝe wymagane są dwa zapytania do
zewnętrznych baz danych - pod kątem NAPR w bazie systemu DNS i pod kątem NP w bazie
NPDB, w porównaniu z jednym zapytaniem dotyczącym NP w przypadku przenośności
numeru między sieciami PSTN. Takie podwójne odpytywanie zabiera czas i zajmuje zasoby
sieci.
30
Skoro przenośność numeru umoŜliwia abonentom przenoszenie uŜywanych numerów z sieci
jednego dostawcy do sieci innego, to jeśli numer (wzięty z bloku numerów naleŜących do
operatora sieci PSTN) zostanie przeniesiony do sieci IP (jak to opisano wyŜej), wówczas
połączenia inicjowane przez abonentów IP nie muszą być rutowane przez sieć PSTN.
Połączenia mogą być przenoszone poprzez róŜne rodzaje sieci. Za kaŜdym razem połączenie
przechodzące z jednej sieci do drugiej musi przejść przez bramę medialną, która konwertuje
przekazywany strumień danych. Konwersja powoduje opóźnienia transmisji i wprowadza
jitter, które degradują jakość obsługi ruchu. Dlatego teŜ naleŜy unikać niepotrzebnych
konwersji danych w sieci.
Generalnie z punktu widzenia przenośności numeru występują problemy dotyczące dwóch
aspektów: bazy danych numerów przeniesionych (NP databese) oraz sygnalizacji/rutingu w
sieci.
8.1. Problemy związane z bazą danych NPDB przy przenoszeniu numerów między
róŜnymi rodzajami sieci
W standardzie RFC 3482 [15] znajdują się dwie propozycje rozwiązań dotyczących interfejsu
bazy danych numerów przeniesionych.
Pierwszym z nich jest zastosowanie w sieciach IP dla potrzeb przenośności numerów
rozwiązania o funkcjonalności centrali międzynarodowej, która jest uŜywana w sieci PSTN
do zapewnienia współpracy róŜnych krajowych wersji protokołu ISUP. Takie rozwiązanie
powinno spowodować, Ŝe informacja sygnalizacyjna będzie kierowana do tych jednostek sieci
IP, które realizują funkcje przenośności numeru (NP).
Drugim rozwiązaniem jest propozycja zdefiniowania „wspólnego” interfejsu dla wszystkich
baz NPDB, poprzez który jednostki sieci IP będą przekazywały zapytania do wszystkich baz
danych numerów przeniesionych. JuŜ istniejące bazy NPDB powinny być przystosowane tak,
aby mogły wykorzystywać ten dodatkowy interfejs, natomiast nowe bazy NPDB zawierające
takie same informacje powinny być rozwijane od początku pod kątem współpracy poprzez ten
interfejs. Usługa ENUM posiada zdolności do obsługi obu tych rozwiązań. Pod tym kątem w
dokumencie RFC 4769 [20] została opisana nowa usługa „enumservice pstn”, która wskazuje
dane rutingowe PSTN obejmujące dane dotyczące przenośności numeru i dane dotyczące
numeru nieprzeniesionego. Ta usługa powinna umoŜliwić dostawcom usług umiejscowienie
przenoszonych numerów lub bloków numerów oraz dostarczenie powiązanych z nimi danych
kontaktowych, ułatwiających dostępność do bazy danych DNS (ENUM). W ten sposób
wszystkie przeglądania numerów telefonicznych zostaną skonsolidowane w postaci jednego
przeglądania DNS NAPTR, co uprości ruting i działanie sieci.
8.2. Problemy związane z sygnalizacją przy przenoszeniu numerów między róŜnymi
rodzajami sieci
Protokół SIP, transportując informacje sygnalizacyjne, wykorzystuje informacje przesyłane w
protokole ISUP, nawet wtedy, gdy ISUP jest tunelowany w SIP. Jest to konieczne w tym celu,
aby sieci IP mogły obsługiwać „domowe” połączenia (domestic calls) zestawiane między
dwoma sieciami PSTN i aby inicjująca sieć PSTN mogła przekazać zapytanie do bazy danych
NPDB. W przypadku, gdy sieci IP obsługują takie zapytania, informacje dotyczące
przenośności numeru są przekazywane w protokole SIP do docelowej sieci PSTN. WyróŜnia
się trzy rodzaje informacji związane z przenośnością numeru, które są przekazywane w
protokole SIP:
a) wybrany numer, na podstawie którego w sieci końcowej następuje zakańczanie
połączenia,
31
b) numer rutingowy (RN) wykorzystywany do kierowania wywołań do końcowej
sieci PSTN (terminating PSTN network),
c) wskaźnik „npdi” (NPDB dip indicator), który wykorzystuje końcowa sieć
PSTN.
Wybrany numer jest umieszczany we wskaźniku URI, natomiast numer rutingowy, zgodnie
ze standardem RFC 4694 [16], stanowi rozszerzenie wskaźnika „tel URI”. To rozszerzenie
jest obsługiwane przez SIP, poniewaŜ moŜe być ono przeniesione jako parametr opcjonalny
części uŜytkownika SIP URI.
8.3. Wykorzystanie usługi ENUM w przenośności numerów przy współpracy sieci
VoIP/IMS
Usługa ENUM posiada wszystkie moŜliwości, aby stać się powszechną metodą mapowania
adresów w sieciach VoIP/IMS. Z punktu widzenia przenośności numeru moŜna wyróŜnić
cztery scenariusze związane z ENUM, dotyczące następujących sytuacji:
a) gdy numer nie jest przenoszony,
b) gdy numer jest przenoszony między sieciami PSTN,
c) gdy numer jest przenoszony między sieciami PSTN i IP,
d) gdy numer jest przenoszony między sieciami IP.
8.3.1.
Numer telefoniczny nie jest przenoszony między sieciami
Scenariusz obsługi połączeń telefonicznych, inicjowanych z IMS do abonenta sieci PSTN,
którego numer nie został przeniesiony przebiega w podany niŜej sposób.
1. Softswitch odbiera z sieci IMS wiadomość SIP INVITE z Ŝądaniem „Request-URI”
identyfikacji abonenta Ŝądanego, który jest opisany przez wskaźnik „tel URI”
zawierający numer CdPN.
2. W oparciu o dostarczony numer zostaje utworzona nazwa domeny i wykorzystana w
zapytaniu NAPTR skierowanym do zewnętrznej bazy danych DNS.
3. Po otrzymaniu odpowiedzi z DNS, softswitch dokonuje wyboru tych rekordów
NAPTR, które wspierają realizację usługi E2U (np. wybiera rekord NAPTR dla
numeru nieprzeniesionego uŜywając wskaźnika „tel URI”).
4. Brak obecności numeru rutingowego „rn” we wskaźniku „tel URI” oznacza, Ŝe numer
nie został przeniesiony. Pole „npdi” jest dołączane po to, Ŝeby nie były generowane
niepotrzebnie następne zapytania do bazy danych PSTN.
5. Na podstawie analizy numeru CdPN, softswitch stwierdza, Ŝe połączenie będzie
rutowane do końcowej sieci PSTN, w której rezyduje abonent Ŝądany (w kierunku tej
sieci zostaje wysłana wiadomość IAM z numerem CdPN).
W przypadku, gdy sieć PSTN inicjuje połączenie powinny być podjęte takie same działania,
jak opisano powyŜej w punktach 2, 3 i 4.
Rysunek 8-2 przedstawia postać graficzną scenariusza działania usługi ENUM w przypadku,
gdy numer telefoniczny nie został przeniesiony do innej sieci.
32
Rysunek 8-2 Działanie usługi ENUM w przypadku, gdy numer nie został przeniesiony
8.3.2.
Numer telefoniczny jest przenoszony między sieciami PSTN
Scenariusz obsługi połączeń telefonicznych, inicjowanych z IMS do abonenta sieci PSTN,
którego numer został przeniesiony do innej sieci PSTN, w przypadku, gdy te połączenia są
obsługiwane przez ten sam softswitch, przebiega w podany niŜej sposób.
1. Softswitch odbiera z sieci IMS wiadomość SIP INVITE z Ŝądaniem „Request-URI”
identyfikacji abonenta Ŝądanego, który jest opisany przez wskaźnik „tel” URI
zawierający numer CdPN.
2. W oparciu o dostarczony numer zostaje utworzona nazwa domeny i wykorzystana w
zapytaniu NAPTR skierowanym do zewnętrznej bazy danych DNS.
3. Po otrzymaniu odpowiedzi z DNS, softswitch dokonuje wyboru tych rekordów
NAPTR, które wspierają realizację usługi E2U (np. wybiera rekord NAPTR dla
numeru przeniesionego uŜywając wskaźnika „tel URI”).
4. Obecność numeru rutingowego „rn” we wskaźniku „tel URI” oznacza, Ŝe abonent jest
traktowany jako przeniesiony. Pole „npdi” jest dołączane w celu ochrony, Ŝeby nie
były generowane kolejne niepotrzebnie zapytania w bazach danych PSTN.
5. Softswitch wykorzystuje odebrany numer rutingowy „rn” do rerutowania połączenia w
kierunku sieci odbiorcy (recipient network). W kierunku tej sieci zostaje wysłana
wiadomość IAM zawierająca zarówno numer rutingowy RN (zmapowany z numeru
„rn”), jak i numer CdPN.
33
6. Ostatecznie, kiedy centrala końcowa w sieci odbiorcy odnajdzie swoją własną
informację rutingową (w wyniku analizy dostarczonego numeru RN), wykorzystuje
odebrany numer CdPN do zakończenia połączenia.
W przypadku, gdy sieć PSTN inicjuje połączenie powinny być podjęte takie same działania,
jak opisano powyŜej w punktach 2, 3, 4 i 5.
Rysunek 8-3 przedstawia schemat scenariusza działania usługi ENUM, gdy numer
telefoniczny został przeniesiony z sieci PSTN do innej takiej sieci.
Rysunek 8-3 Działanie usługi ENUM, gdy numer telefoniczny został przeniesiony między sieciami PSTN
8.3.3.
Numer telefoniczny jest przenoszony między siecią PSTN i IP
Scenariusz obsługi połączeń telefonicznych, inicjowanych z IMS do abonenta sieci PSTN,
którego numer został przeniesiony z sieci PSTN do sieci IP, przebiega w podany niŜej sposób.
1. Softswitch odbiera z sieci IMS wiadomość SIP INVITE z Ŝądaniem „Request-URI”
identyfikacji abonenta Ŝądanego, który jest opisany przez wskaźnik „tel URI”
zawierający numer CdPN.
2. W oparciu o dostarczony numer zostaje utworzona nazwa domeny i wykorzystana w
zapytaniu NAPTR skierowanym do zewnętrznej bazy danych DNS.
3. Po otrzymaniu odpowiedzi z DNS, softswitch dokonuje wyboru tych rekordów
NAPTR, które wspierają realizację usługi E2U (np. wybiera rekord NAPTR dla
numeru przeniesionego uŜywając wskaźnika „SIP URI”).
34
4. Obecność numeru rutingowego „rn” we wskaźniku „SIP URI” oznacza, Ŝe abonent
jest traktowany jako przeniesiony. Pole „npdi” jest dołączane w celu ochrony, Ŝeby
nie były generowane kolejne niepotrzebnie zapytania w bazach danych PSTN.
5. Metoda konwersji numeru z „tel URI” na „SIP URI” została podana w dokumentach
RFC 3261 [16] i RFC 4694 [18].
6. Softswitch zestawia połączenie SIP pod adres domeny IP, wysyłając w tym celu
wiadomość INVITE z otrzymanym numerem „rn” i wskaźnikiem „npdi”.
W przypadku, gdy sieć PSTN inicjuje połączenie powinny być podjęte takie same działania,
jak opisano powyŜej w punktach 2, 3 i 4.
Rysunek 8-4 przestawia postać graficzną działanie usługi ENUM, gdy numer telefoniczny
został przeniesiony z sieci PSTN do IP.
Rysunek 8-4 Działanie usługi ENUM, gdy numer telefoniczny został przeniesiony z sieci PSTN do IP
8.3.4.
Numer telefoniczny jest przenoszony między sieciami IP
Scenariusz obsługi połączeń telefonicznych, inicjowanych z IMS do abonenta sieci IP,
którego numer został przeniesiony do innej sieci IP, przebiega w podany niŜej sposób.
1. Softswitch odbiera z sieci IMS wiadomość SIP INVITE z Ŝądaniem „Request-URI”
identyfikacji abonenta Ŝądanego, który jest opisany przez wskaźnik „tel URI”
zawierający numer CdPN. Wskaźnik „tel” URI, który jest przenoszony jako parametr
opcjonalny w części uŜytkownika wskaźnika „SIP URI” zawiera numer abonenta
Ŝądanego CdPN.
35
2. W oparciu o dostarczony numer zostaje utworzona nazwa domeny i wykorzystana w
zapytaniu NAPTR skierowanym do zewnętrznej bazy danych DNS.
3. Po otrzymaniu odpowiedzi z DNS, softswitch dokonuje wyboru tych rekordów
NAPTR, które wspierają realizację usługi E2U (np. wybiera rekord NAPTR dla
numeru przeniesionego uŜywając wskaźnika „SIP URI”).
4. Obecność numeru rutingowego „rn” we wskaźniku „SIP URI” oznacza, Ŝe abonent
jest traktowany jako przeniesiony. Pole „npdi” jest dołączane w celu ochrony, Ŝeby
nie były generowane kolejne niepotrzebnie zapytania w bazach danych PSTN.
5. Softswitch zestawia połączenie SIP pod adres domeny IP, wysyłając w tym celu
wiadomość INVITE z otrzymanym numerem „rn” i wskaźnikiem „npdi”.
W przypadku, gdy sieć PSTN inicjuje połączenie powinny być podjęte takie same działania,
jak opisano powyŜej w punktach 2, 3 i 4.
Rysunek 8-5 przedstawia postać graficzną scenariusza działanie usługi ENUM, gdy numer
telefoniczny został przeniesiony między sieciami IP.
Rysunek 8-5 Działanie usługi ENUM, gdy numer telefoniczny został przeniesiony między sieciami IP
8.3.5.
Podsumowanie
Przenośność numeru pozwala abonentowi sieci telefonicznej zatrzymać dotychczasowy
numer:
- przy zmianie dostawcy usługi (przenośność dostawcy usługi),
- przy przejściu do nowej lokalizacji (przenośność lokalizacyjna),
- zmianie abonowanej usługi (przenośność usługowa).
36
Sposób implementacji NP jest róŜny w poszczególnych krajach. Wspólne dla wszystkich
stosowanych dzisiaj rozwiązań jest tylko to, Ŝe wybrany numer abonenta Ŝądanego (numer
katalogowy) jest mapowany na prefiks lub numer rutingowy. Numer rutingowy, będący
zhierarchizowanym adresem rutingu, moŜe być analizowany (cyfra po cyfrze) w celu
określenia właściwego kraju, operatora sieci, końcowej centrali i abonenta końcowego. Z
prefiksu rutingowego moŜe być utworzony numer rutingowy poprzez dodanie kilku cyfr
poprzedzających numer katalogowy. Prefiks wraz z numerem katalogowym jest
przekazywany w parametrze CdPN (Called Party Number) wiadomości IAM protokołu ISUP.
Taki model rutingu jest stosowany w większości krajów europejskich (np. w Austrii, Belgii,
Finlandii, Francji, Niemczech, Włoszech, Norwegii, Hiszpanii, Szwecji, Szwajcarii i Wielkiej
Brytanii. W rozwiązaniach, w których do przenośności numeru uŜywa funkcji sieci
inteligentnej, bazy danych dla celów mapowania jest zorganizowana w elementach sieci
zwanych SDF (Service Data Function).
Wraz z rozwojem sieci IP pojawiły się potrzeby związane z przenoszeniem numerów między
sieciami PSTN i IP i nowy rodzaj przenośności – przenośność między róŜnymi rodzajami
sieci. Początkowo nie było rozwiązań dla przenośności numerów pomiędzy sieciami IP i
PSTN, potem okazało się, Ŝe numer, który został przeniesiony do sieci IP moŜe być
obsłuŜony w tej sieci w zwykły sposób, przy wykorzystaniu rozwiązań stosowanych do
przenośności numeru w sieci PSTN. W sieci IP świadczącej usługę VoIP, przenośność
numeru moŜe być w ograniczonym zakresie implementowana, przy wykorzystaniu funkcji
„redirect” oraz serwera Proxy, który kieruje połączenia do bramy medialnej (Gateway) w
oparciu o numer rutingowy. Wywołania do przeniesionych numerów są kierowane do nowego
miejsca przeznaczenia przy wykorzystaniu wcześniej funkcji serwera sygnalizacji. Dlatego
taka realizacja bardziej odpowiada funkcji przekierowania połączenia (call forwarding) niŜ
funkcji przenośności numeru (numer portability). Kierowaniem mogą być objęte zarówno
połączenia inicjowane do terminali IP, jak i połączenia inicjowane do terminali sieci PSTN.
Bazy danych numerów przeniesionych mogą być uaktualnione za pomocą numerów
rutingowych, które słuŜą do kierowania połączeń do bram medialnych.
W sieciach świadczących usługę VoIP na bazie systemu IMS przenośność numeru moŜe być
realizowana przy wykorzystaniu funkcjonalności ENUM, zapewniającej mapowanie adresów
E.164. ENUM umoŜliwia współpracę systemów działających w oparciu o numery
telefoniczne z systemami wykorzystującymi w rutingu wskaźnik URI. ENUM, wzbogacona o
nową funkcję „pstn enumservice” jest traktowana jako usługa o potencjalnych moŜliwościach,
przy pomocy której zostaną rozwiązane problemy związane z przenośnością numerów usług
VoIP, przy wykorzystaniu systemu sygnalizacji SIP. Podstawowe specyfikacje usługi ENUM
dla tego rodzaju zastosowań zostały opublikowane w standardach RFC i działają juŜ
komercyjne jej implementacje oparte na tych standardach. Jednak te przypadki nie dotyczą
przenośności numerów poprzez róŜne rodzaje sieci. Ostatnie działania prowadzone przez
grupę roboczą „IETF enum working group” zmierzają w takim kierunku, aŜeby usługa
ENUM mogła być stosowana jako baza danych mapowania numerów wspólna dla całej sieci,
która zapewnia pełne wsparcie w zakresie przenośności numeru wszystkim jednostkom w
sieci. Prace, które będą prowadzone w przyszłości w tym obszarze powinny być związane z
upowszechnieniem informacji w bazie danych ENUM, które muszą być uaktualniane dla
uniknięcia błędnego lub nieefektywnego kierowania wywołań w sieci. Obecnie uaktualnianie
baz danych odbywa się w sposób ręczny i ten proces nie jest koordynowany między
dostawcami usług. Staje się to uciąŜliwe, szczególnie, gdy wzrasta częstość modyfikacji bazy
w związku z przenoszeniem numerów w sieci. Ponadto, przy takim podejściu wzrasta ryzyko
wprowadzenia błędnej lub niekompatybilnej informacji. Dlatego potrzebna jest procedura
zautomatyzowanego aktualizowania baz danych w celu zsynchronizowania informacji między
dostawcami usług.
37
9. Wnioski
9.1. Wnioski z konsultacji z dostawcami usług w technologii VoIP
1. Aktualnie większość dostawców usług w technologii VoIP, mimo braku obowiązku,
realizuje przenoszenie numerów, ale w sposób ograniczony.
2. Z uwagi na brak uregulowań i wytycznych dla usług realizowanych w technologii VoIP
dostawcy usług w technologii VoIP mają trudności w zakresie określenia właściwości
usług, przenośności numerów oraz współpracy międzyoperatorskiej.
3. Dostawcy usług w technologii VoIP mają niewystarczającą wiedzę dotyczącą metod
przenośności numerów, moŜliwości dostosowania ich platform VoIP oraz realizowanej
bazy numerów przeniesionych CBD.
4. Aktualnie stosowana metoda OR wywodząca się z technologii sieci z komutacją łączy nie
spełnia wymagań dostawców usług w technologii VoIP poniewaŜ:
- wymaga stosowania styku w sygnalizacji SS7 i wyposaŜenia w nie platform
VoIP, zestawiania kanałów cyfrowych, przeprowadzania testów
akceptacyjnych oraz ponoszenia kosztów eksploatacji łączy.
- wymaga wymiany ruchu w technologii VoIP za pośrednictwem sieci PSTN,
co uniemoŜliwia bezpośrednią wymianę ruchu z wykorzystaniem
sygnalizacji SIP między dostawcami usług w technologii VoIP, ogranicza
warunki konkurencyjności oraz takŜe pogarsza jakość połączeń poprzez
wielokrotne konwersje sygnałów głosowych,
- powoduje to generowanie dodatkowego ruchu i zajmowanie zasobów
operatora macierzystego w związku z kierowaniem połączeń, co w
przypadku zwiększenia ruchu generowanego na numery przeniesione wiąŜe
się z koniecznością rozbudowy punktów styku.
5. Obecnie stosowana metoda przenośności OR powoduje, Ŝe operator macierzysty (Dawca)
ponosi koszty kierowania połączenia otrzymując jednocześnie przychód za zakończenie
połączenia.
6. Wprowadzenie i obsługa procesu przenoszenia numerów wiąŜe się z kosztami wdroŜenia
systemów informatycznych oraz podpisania umów z operatorami i jest nieopłacalna
biznesowo dla małych dostawców usług w technologii VoIP obsługujących np. rzędu
kilkuset abonentów.
7. Koszty punktu styku w sygnalizacji SS7 są zbyt wysokie dla dostawców usług w
technologii VoIP obsługujących małą liczbę abonentów, co powoduje konieczność
współpracy z operatorami zewnętrznymi w zakresie obsługi i rozgłaszania numeracji.
8. Konieczność zlecenia obsługi numeracji w przypadku braku punktu styku w sygnalizacji
SS7 powoduje, Ŝe operatorzy rozgłaszający numerację zachowują większą część stawki za
ruch przychodzący. Skutkiem tego jest bardzo niewielki udział w przychodach dostawców
usług VoIP z tytułu zakańczania połączeń na numerację swoich klientów.
9. Z uwagi na zapewnienie warunków konkurencyjności dostawca usług w technologii VoIP
powinien mieć moŜliwość wyboru rodzaju technologii punktu styku (z sygnalizacją SIP
czy SS7), przez który chce kierować ruch oraz czy w wymianie ruchu z siecią PSTN chce
korzystać z sieci innego operatora, który zapewni mu konwersję sygnalizacji SIP na SS7.
38
10. Aktualnie większość operatorów sieci PSTN/ISDN posiada styki międzyoperatorskie z
protokołem IP z sygnalizacją SIP.
11. Dostawcy usług w technologii VoIP obecnie wykorzystują podobne formaty kodów
rutingowych w sygnalizacji SIP jak w przypadku sygnalizacji SS7. Stosowany jest format
międzynarodowy numeru np. tel:”+48” + ”C” + XYZT+ KN”. Liczba „C” w systemie
szesnastkowym kodowana jest tekstowo jako litera C. Podobny sposób kodowania
stosowany jest dla przesyłania numeru kierowania alarmowego NKA. Proponuje się
wprowadzenie tego rozwiązania do stosowania w całym kraju. Będzie ono wymagać
zmiany rozporządzenia w sprawie szczegółowych wymagań dotyczących zasad
adresowania dla właściwego kierowania połączeń.
12. Dostawcy usług VoIP, w szczególności działający w małej skali i uŜywający numeracji ze
wszystkich stref numeracyjnych zwykle korzystają z umów o uŜyczenie numeracji. Jako,
Ŝe nie są właścicielem numeracji proces przenoszenia numeru muszą realizować za
pośrednictwem operatora trzeciego. Powoduje to, Ŝe na podstawie numeru niemoŜliwe
jest ustalenie przedsiębiorcy telekomunikacyjnego uŜytkującego numer. Art. 127 Pt
dopuszcza udostępnianie przydzielonej numeracji innym współpracującym podmiotom
dostarczającym usługi telekomunikacyjne jednak nie moŜe to utrudniać albo ograniczać
wykonywania działalności. Natomiast Rozporządzenie w sprawie szczegółowych
wymagań dotyczących gospodarowania numeracją w publicznych sieciach telefonicznych
nie odnosi się do udostępniania numeracji. W związku z powyŜszym proponuje się
rozwaŜenie rejestracji umów w UKE oraz zmniejszenie przydzielanego bloku numeracji
do 100 NN, co wymaga zmiany ww. rozporządzania.
9.2. Proponowane kierunki działań
1. Wprowadzenie obowiązku NP dla usług realizowanych w technologii VoIP, biorąc pod
uwagę zasadę neutralności technologicznej, powinno uwzględniać równe warunki dla
wszystkich dostawców usług w technologii VoIP.
2. Wskazane jest, aby w zakresie przenośności numerów abonenci usług w technologii VoIP
mieli takie same uprawnienia do korzystania z numeracji jak abonenci sieci
stacjonarnych,.
3. Wprowadzenie przenośności numerów dla usług w technologii VoIP powinno być
poprzedzone okresem przygotowawczym i okresem przejściowym. Najpierw powinny
powstać jednolite zasady przenośności numerów w oparciu o platformę CBD, w kolejnym
etapie naleŜałoby przygotować rozszerzoną funkcjonalność CBD dla potrzeb przenośności
numerów dla usług w technologii VoIP i następnie wprowadzić obowiązek przenośności
numerów dla usług realizowanymi w technologii VoIP.
4. Powinna być moŜliwa koegzystencja róŜnych metod przenoszenia numerów w zaleŜności
od warunków technicznych, w szczególności w okresie przejściowym.
5. Wskazane jest wcześniejsze uprzedzenie dostawców usług w technologii VoIP o
wprowadzeniu obowiązku przenoszenia numeru dla usług realizowanych w technologii
VoIP w celu podjęcia przygotowań.
6. Wskazane jest przygotowanie wstępnej propozycji i rozpoczęcie uzgodnień z dostawcami
usług w technologii VoIP, których celem będzie wypracowanie szczegółowego
rozwiązania technicznego, które ma zostać zaimplementowane łącznie z procesami
niezbędnymi do jego obsługi.
39
7. Na podstawie wytycznych w zakresie rozwiązań technicznych dostawcy usług w
technologii VoIP będą mogli ocenić zakres przygotowań, harmonogram i koszty oraz
wykonać wyboru optymalnego rozwiązania. Aktualnie dostawcy usług VoIP nie posiadają
wiedzy w tym zakresie.
8. Informacja o planowanym obowiązku wprowadzenia przenośności numerów oraz
wymaganych rozwiązań technicznych jest takŜe istotna dla przedsiębiorców
telekomunikacyjnych w przypadku zakupu platform komunikacyjnych VoIP. W
przeciwnym razie zakupione platformy komunikacyjne VoIP mogą nie realizować funkcji
przenośności numerów i narazić operatorów na poniesienie dodatkowych kosztów
rozbudowy.
9. Proponowane rozwiązania techniczne nie powinny wymuszać zmiany technologii
platform VoIP w kierunku technologii sieci PSTN z komutacją łączy (tj. stosowania
punktów styku w sygnalizacji SS7), z uwagi na aktualne trendy rozwojowe w kierunku
sieci NGN i konwergencję w oparciu o protokół IP. Aktualnie wzrasta liczba punktów
styków do współpracy międzyoperatorskiej w protokole IP z sygnalizacją SIP. TakŜe
stacjonarne sieci PSTN są rozbudowywane w oparciu o infrastrukturę wykorzystującą
protokół IP. Aktualnie sieci PSTN/ISDN z komutacją kanałów nie są przedmiotem ofert
producentów i przedsiębiorcy nie inwestują w ich rozwój.
10. Proponuje się wprowadzenie formatów kodów rutingowych w sygnalizacji SIP
odpowiadających stosowanym w sygnalizacji SS7. Wymagać to będzie jednolitej obsługi
cyfr z zakresu poza dziesiętnego wykorzystywanych w kodach rutingowych przez
platformy VoIP współpracujących dostawców usług.
11. Preferowanym rozwiązaniem, które moŜe być zastosowane do realizacji przenoszenia
numerów dla usług w technologii VoIP jest carrier ENUM, jako zestandaryzowane,
zgodne z kierunkiem rozwoju sieci NGN.
12. Proponuje się, aby rozwaŜyć rozbudowę platformy PLI CBD o Carrier ENUM i
zintegrowanie jej z bazą numerów przeniesionych. Przed implementacją Carrier ENUM
naleŜałoby
przeprowadzić
szczegółową
analizę
aktualnych
dokumentów
standaryzacyjnych w tym zakresie oraz rozwiązań stosowanych w innych krajach.
13. Nowe platformy VoIP instalowane w sieci krajowej u dostawców usług w technologii
VoIP (np. NGN Broadworks firmy Broadsoft, Huawai Softswitch, firmy Alcatel-Lucent)
mają moŜliwość realizacji przenośności numerów z wykorzystaniem usługi ENUM.
14. Wprowadzenie przenośności numerów dla usług realizowanych w technologii VoIP jest
procesem długotrwałym, poniewaŜ oprócz rozszerzenia funkcjonalności platformy
komunikacyjnej VoIP będzie wymagane wprowadzenie obsługi procedur przenoszenia
numerów i zmiany w systemach informatycznych obsługi klienta.
15. Biorąc pod uwagę złoŜoność działań proponuje się etapowe wdraŜanie obowiązku
przenoszenia numerów dla usług w technologii VoIP:
- Etap I – jednostronnie z PSTN do usług w technologii VoIP – realizowane jak
dotychczas przy wykorzystaniu metody OR, niewymagające dodatkowych prac,
- Etap II – dwustronnie między dostawcami usług w technologii VoIP – uzaleŜnione
od realizacji CBD i jeśli podjęta zostanie decyzja od uruchomienia usługi ENUM,
proponuje się rozwaŜyć zastosowania innej metody,
- Etap III – dwustronnie między PSTN i usługami w technologii VoIP.
40
16. W okresie wdraŜania NP proponuje się przeprowadzenie konsultacji z dostawcami usług
w technologii VoIP w celu identyfikacji problemów i podjęcia środków zaradczych.
17. Wprowadzenie przenośności numerów dla usług w technologii VoIP wskazuje na
potrzebę zmian w:
- ustawie Prawo telekomunikacyjne polegających na zrównania uprawnień
abonentów i dostosowaniu do aktualnych zapisów Dyrektyw Unijnych – przy
uwzględnieniu specyfiki technologiczni VoIP i równocześnie zachowaniu
neutralności technologicznej,
- rozporządzeniu w sprawie warunków korzystania z uprawnień w publicznych
sieciach telefonicznych w zakresie usunięcia ograniczenia obowiązku przenoszenia
numerów w sieciach stacjonarnych tylko dla określanej lokalizacji,
- rozporządzeniu w sprawie szczegółowych wymagań dotyczących zasad
adresowania dla właściwego kierowania połączeń, w zakresie formatów dla
numerów rutingowych NR NP i numeru kierowania alarmowego NKA dla
sygnalizacji SIP stosowanej w technologii VoIP.
41
10. Załącznik Nr 1. Przegląd dokumentów międzynarodowych
10.1. Przegląd dokumentów organizacji regulacyjnych
10.1.1. Rekomendacje CEPT
Istotę stanowiska europejskiego, co do przeznaczania numeracji na cele związane z usługami
VoIP o charakterze nomadycznym najlepiej oddaje rekomendacja komitetu ECC CEPT
(05/03) z maja 2005 r6. Podkreśla ona znaczenie nomadycznej realizacji usług VoIP dla
rozwoju konkurencji i kluczową cechę tych usług polegającą na zerwaniu związku ze stałą
lokalizacją. Zaleca podejmowanie decyzji dotyczących nomadyczności w ramach generalnych
zasad neutralności technologicznej, niedyskryminacji, zachowania walorów transparentności
taryfowej i przenośności numeru. Jednocześnie potwierdza, Ŝe dotychczasowe plany
numeracji nie uwzględniały zjawiska nomadyczności, które powinno znaleźć
odzwierciedlenie w nowych ustaleniach. Rekomendowanie jednolitych ustaleń jest
niemoŜliwe na skutek wielu zaszłości. Dlatego władze krajowe przy podejmowaniu decyzji
powinny rozwaŜyć dwie opcje, odpowiednio wywaŜając interesy uŜytkowników, dostawców
usług i interes publiczny. Po pierwsze, opcję polegającą na przeznaczeniu numerów
geograficznych na cele świadczenia usług nomadycznych. Po drugie, opcję przeznaczenia na
ten cel nowego zakresu numeracji. Uzupełniająco naleŜy rozwaŜyć moŜliwość połączenia
obydwu podejść. Kluczowym elementem rekomendacji jest podjęcie rozstrzygnięcia w tej
sprawie, aby brak decyzji nie wstrzymywał rozwoju tej kategorii usług.
10.1.2. Oświadczenie ERG
Stanowisko Grupy Regulatorów Europejskich (ERG) w sprawie numeracji i przenośności
numeru zostało przedstawione w raporcie ERG (05) 12: ERG Common Statement for VoIP
Regulatory Approaches. Zdaniem ERG plany numeracji powinny być neutralne
technologicznie i takie same zakresy numeracji powinny być udostępniane zarówno dla
tradycyjnych usług głosowych, jak i usług VoIP. Takie podejście przyczyni się do wspierania
nowych usług oraz promowania przenośności numeru i będzie wyrazem popierania
konkurencji na rynku usług telefonicznych.
Przenośność numeru, dająca uŜytkownikowi końcowemu moŜliwość pozostawienia numeru
przy zmianie dostawcy usługi, jest waŜna zarówno z punktu widzenia konsumenta, jak i
dostawcy usługi i jest jednym z głównych atrybutów konkurencji.
W ramach planu numeracji krajowej powinny być jednakowe warunki związane z
przenośnością numeru dla podobnych kategorii usług głosowych.
10.2. Inicjatywy podjęte przez Ofcom w związku z przenośnością numeru
Inicjatywy, które podjął regulator brytyjski (Ofcom) w kwestii przenośności numeru dotyczą
głównie dostawców usług VoIP. Ich celem jest zapewnienie takich warunków, Ŝeby z
przenośności numeru mogli rzeczywiście korzystać dostawcy tych usług oraz Ŝeby
przenośność przyczyniała się do wzrostu konkurencyjności i innowacyjności. Do tych
inicjatyw zalicza się:
a)
zmianę polityki względem dostawców usług VoIP w zakresie prawa do
przenośności numeru,
b)
modyfikację definicji usługi PATS pod kątem przenośności numeru.
6
ECC Recommendation (05)03 "Numbering for nomadic "Voice over IP" Services, 10 maja 2005 r.
42
10.2.1. Zmiana polityki względem dostawców usług VoIP w zakresie prawa do
przenośności numeru
Celem prowadzonej przez Ofcom polityki w okresie przejściowym było ograniczenie liczby
dostawców usług NVS (New Voice Service) kwalifikujących się do realizacji usługi
przenośności wyłącznie do takich, których obejmują zobowiązania wynikające ze
świadczenia usług PATS, określone w dokumencie zawierającym ogólne warunki
świadczenia usług w sieci brytyjskiej GC (General Conditions). Ofcom ogłosił swoją politykę
w zakresie kwalifikowalności dostawców usług NVS do realizacji przenośności numeru w
grudniu 2004 r. i dostarczył stosowny przewodnik. Regulator pozostawił tych dostawców
komunikacji, którzy powinni zostać poddani przeglądowi realizacji jego polityki dotyczącej
przenośności w okresie przejściowym.
Jednym z elementów tej polityki były konsultacje przeprowadzone w 2004 r. oraz
rozpoznanie, jaki oddźwięk w okresie przejściowym będą miały przydzielone dostawcom
usług NVS prawa dotyczące przenośności numerów.
Ofcom postanowił, Ŝe nie naleŜy oczekiwać dostarczania przenośności dostawcom usługi
PATS przez dostawców komunikacji (communications provider), jeśli świadczone przez nich
usługi nie spełniają warunków usługi PATS. Z drugiej strony dał do zrozumienia, Ŝe nie
będzie dłuŜej pobłaŜał, lecz będzie kategorycznie domagał się wykonywania zobowiązań od
dostawców usług NVS (włączając w to dostawców usług VoIP), którzy dostarczają usługi
PATS.
Regulator podjął takŜe decyzję o zmianie działań regulacyjnych w odniesieniu do
przenośności numeru. Dał temu wyraz w oświadczeniu opublikowanym w sierpniu 2006,
stanowiącym podsumowanie wyników wcześniejszych konsultacji. Zgodnie z zawartymi tam
postanowieniami, Ofcom oczekuje, Ŝe dostawcy komunikacji, kierując się podejściem
zdroworozsądkowym, będą dostarczać przenośność numeru:
- tak szybko, jak to tylko będzie moŜliwe, z uwzględnieniem zobowiązań
określonych w GC 18.1 (dotyczą one zarówno dostawców usług VoIP, jak i
innych usług telefonicznych (non-VoIP services), którzy świadczą usługi
PATS),
- w następstwie Ŝądań pochodzących od innych dostawców komunikacji,
zgodnie z definicją podaną w GC 18 i zobowiązaniami określonymi w GC
18.1, a niezaleŜnie od tego takŜe innym dostawcom komunikacji zgodnie z
odpowiednimi warunkami ogólnymi GC innymi niŜ GC 18,
- zgodnie z zobowiązaniami określonymi w GC 18.2 bez Ŝądania od innych
dostawców pisemnego potwierdzenia, Ŝe aktualnie świadczą usługi PATS.
10.2.2. Propozycja modyfikacji definicji usługi PATS pod kątem przenośności
numeru
W aneksie 9 z konsultacji przeprowadzonych w 2004 r. Ofcom zwrócił uwagę, Ŝe Generalna
Dyrekcja Telekomunikacji wprowadziła do GC 18 definicję usług PATS róŜniącą się od
definicji przyjętych w innych dokumentach GC. Było to spowodowane tym, Ŝe definicja
usług PATS, wprowadzona w dyrektywie o usłudze powszechnej (USD), nie obejmowała
przenośności dla numerów niegeograficznych związanych z realizacją wyłącznie połączeń
przyjściowych, np. takich jak połączenie bezpłatne. W oparciu o przyjęte kryteria takie
połączenie nie powinno być klasyfikowane jako usługa PATS, poniewaŜ nie jest połączeniem
wychodzącym i nie zapewnia dostępu do numerów alarmowych. Dyrekcja Generalna
zapewniała, Ŝe intencją wprowadzonego w dyrektywie USD zapisu, nie było wykluczenie
takich usług z przenośności numeru. Zwracała uwagę, Ŝe artykuł 30(1)(b) dyrektywy USD
43
zapewnia prawa abonentów do przenośności numerów niegeograficznych, do których zgodnie
z definicją podaną w artykule 2(f) USD zalicza się numery sieci komórkowych oraz numery
usług bezpłatnych i numery usług z podziałem opłaty (premium rate numbers). Ofcom
uzgodnił, Ŝe pod kaŜdym innym względem ogólne warunki GC 18 będą stanowiły odbicie
artykułu 30 USD, szczególnie w odniesieniu do praw abonentów związanych z realizacją
usługi PATS, która jako usługa sieci publicznej umoŜliwia inicjowanie i odbieranie połączeń
zarówno w ruchu krajowym, jak i międzynarodowym oraz zapewnia dostęp do numerów
alarmowych krajowych i międzynarodowych. Te działania stanowiły waŜny element polityki
regulatora w zakresie przenośności numerów.
Ofcom podjął dalsze kroki, które pozwoliłyby rozwiązywać problemy związane z
przenośnością numeru, w oparciu o definicję usług PATS rozszerzoną o przenośność
numerów niegeograficznych. W tym celu zaproponował zmodyfikowanie definicji usług
PATS podanej w GC 18.5, według której PATS oznacza usługę sieci publicznej
umoŜliwiającą inicjowanie i odbieranie połączeń telefonicznych lub tylko odbieranie takich
połączeń w ruchu krajowym i międzynarodowym za pomocą numeru lub numerów objętych
krajowym lub międzynarodowym planem numeracji. Zgodnie z nową propozycją regulatora,
termin PATS:
a) w odniesieniu do usługi, która z przydzielonym numerem telefonicznym
będzie wykorzystywana do odbierania połączeń na warunkach określonych
umową zawartą między uŜytkownikiem i dostawcą, oznacza usługę
komunikacji elektronicznej słuŜącą wyłącznie do odbieranie takich połączeń w
ruchu krajowym i międzynarodowym za pomocą numeru lub numerów
objętych krajowym lub międzynarodowym planem numeracji,
b) w odniesieniu do usługi, która z przydzielonym numerem telefonicznym
będzie wykorzystywana do inicjowania i odbierania połączeń oraz będzie
zapewniała dostęp do słuŜb alarmowych na warunkach określonych umową
zawartą między uŜytkownikiem i dostawcą, ma znaczenie przypisane jej w
paragrafie 1 części 1 dokumentu [29].
Ta propozycja oznacza w rzeczywistości to, Ŝe abonenci, którzy tylko odbierają połączenia z
wykorzystaniem numerów geograficznych i niegeograficznych będą mieli zapewnione prawo
do przenośności numeru niezaleŜnie od tego, czy jest oferowany dostęp do numerów
alarmowych oraz czy dostawca spełnia wymagania GC inne niŜ podane w GC 18.
Przyjęcie tej propozycji będzie skutkowało uchwaleniem przepisów prawnych realizacji usług
uŜywających numerów geograficznych spełniających warunki usługi PATS. Oznacza to, Ŝe
tak sformalizowana definicja usług PATS będzie mała odbicie w aktualnej polityce, tak
poŜądanej w odniesieniu do przenośności numeru oraz do usług zapewniających dostęp do
słuŜb alarmowych, a w konsekwencji takŜe w odniesieniu do dostawców komunikacji w
sensie wymagania na dostarczanie przenośności numerów innym dostawcom. W rezultacie ta
inicjatywa powinna zwiększyć szansę dostępności do numerów alarmowych na bazie usług
VoIP.
Jeśli usługa dostępna publicznie nie zapewnia dostępu do numerów alarmowych, to nie
powinna być kojarzona z usługami PATS, które uŜywają numerów geograficznych i spełniają
warunki dla nowej definicji usługi PATS, określone w GC 18. Do takiej usługi nie powinien
mieć zastosowania przepis podany w GC 18 i nie powinny być respektowane Ŝadne prawa ani
obowiązki w zakresie przenośności numeru.
W świetle przedstawionych wyŜej problemów, związanych z przedefiniowaniem usługi PATS
pod kątem przenośności numerów, Ofcom rozwaŜa dwa podejścia do ich rozwiązania.
44
Pierwsze polega na nie podejmowaniu Ŝadnych działań w kwestii zmiany tej definicji, czyli
na pozostawieniu jej w dotychczasowym sensie. Drugie na dokonaniu jej zmiany dla potrzeb
GC 18 zgodnie z przedstawioną wyŜej propozycją, które traktuje jako działanie preferowane.
Ofcom uwaŜa, Ŝe pozostawienie tej definicji w obecnym brzmieniu pociąga za sobą ryzyko,
Ŝe niekonsekwencja i brak pełnej logiczności w treści tej definicji będzie kontynuowana i
moŜe wywołać wśród dostawców usług (PSTN i VoIP) niepoŜądaną niepewność, jakim
prawom i obowiązkom podlegają z racji istniejących regulacji. W związku z drugim
podejściem, Ofcom uwaŜa, Ŝe zmiana definicji nie pociągnie Ŝadnych kosztów materialnych
dla dostawców usług, włączając w to dostawców usług VoIP, a jedynie koszty
administracyjne obciąŜające samego regulatora.
10.3. Komentarz operatora WIND Hellad Telecommunications S.A. do raportu
ERG (07) 56 Rev 1
Zdaniem europejskiej grupy regulatorów ERG (European Regulator’s Group) administracje
krajów członkowskich powinny czynić starania, aby zapobiegać zjawiskom dyskryminacji
dostawców usług z punktu widzenia stosowanych w sieciach zakresów numeracyjnych.
Według WIND Hellad Telecommunications S.A. [31], jednego z największych operatorów
sieci stacjonarnych, komórkowych i internetowych w Grecji, to zalecenie powinno mieć
zastosowanie wyłącznie do dostawców świadczących usługi równowaŜne usługom
świadczonym w tradycyjnej sieci telefonicznej.
W tym kontekście operator grecki zwraca uwagę na niewyraźną konkluzję zawartą w pkt
4.4.2 ww. raportu ERG, która jak mu się wydaje, nie wprowadza wyraźnego rozróŜnienia
między dostawcami usług PATS i ETS.
Ten sam komentarz dotyczy stwierdzenia podanego w parag. 5.1, w którym ERG wyraŜa
opinię, Ŝe „wydaje się właściwym podejściem nakładanie na dostawców usług VoIP
obowiązków związanych z przenośnością numeru oraz zezwolenie na przenoszenie numerów
pomiędzy tradycyjnymi usługami telefonicznymi i usługami VoIP. Zdaniem WIND Hellad
Telecommunications S.A. takie stwierdzenie nie jest jasne bez dokonania kategoryzacji usług
głosowych.
W raporcie ERG (05)12 [26] znajduje się stwierdzenie, Ŝe „dla potrzeb przenośności numeru,
w obrębie określonego zakresu numerów krajowego planu numeracji, powinny być
zapewnione jednakowe warunki dla podobnych usług, aby ułatwić konsumentom wybór
operatora oraz zapewnić warunki promocji efektywnej konkurencji”. Zdaniem WIND Hellad
Telecommunications S.A trudno jest zrozumieć, jak zaproponowaną miarę „równego”
traktowania stosować do róŜnych typów usług VoIP, niezaleŜnie od ich kategorii. W tym
podejściu ERG znacząco odchodzi od wcześniejszej uzgodnionego stanowiska. Grecki
operator wyraŜa nadzieję, Ŝe przenośność powinna być stosowana między usługami
równowaŜnymi, poniewaŜ w przeciwnym razie zostanie zatracona kontrola, a konsument
będzie zawiedziony.
Operator WIND Hellad Telecommunications S.A potwierdza, Ŝe zgadza się ze stanowiskiem
ERG zawartym w parag. 5.1, iŜ mechanizm przenośności powinien pozostać do decyzji
poszczególnych krajów członkowskich. Według tego operatora, dostawcy powinni zachować
ostroŜność w podejmowaniu ryzyka we wprowadzaniu nowych uciąŜliwych mechanizmów,
które będą satysfakcjonować pod względem przenośności „nowych graczy” wchodzących na
rynek telekomunikacyjny.
45
10.4. Decyzja FCC w sprawie rozszerzenia lokalnej przenośności numeru na
usługi VoIP
Zapowiedź podjęcia decyzji w sprawie rozszerzenia lokalnej przenośności numeru na usługi
VoIP przez Federalną Komisję Komunikacji (FCC) Stanów Zjednoczonych została ogłoszona
31 października 2007 r. (patrz dok. [32]). To działanie było po części odpowiedzią na skargi
zgłaszane przez konsumentów, dotyczące braku moŜliwości przenoszenia numeru do lub z
sieci dostawców usług VoIP.
W oświadczeniu FCC (Federal Communications Commission) złoŜonym w tej sprawie mówi
się, Ŝe prawo konsumenta do zatrzymania uŜywanego numeru telefonicznego, (który jest
dobrze znany w kręgu znajomych), przy przełączeniu na nową technologię zostało
rozszerzone na mocy zarządzenia, które zapewni konsumentom moŜliwość wyboru dostawcy
usługi telefonicznej biorąc pod uwagę jakość, cenę i usługę.
Komisja FCC wyjaśnia, Ŝe obowiązek dostarczania usługi przenośności numeru zostaje
rozszerzony na dostawców usług VoIP oraz operatorów sieci, którym zostały przydzielone
zakresy numerów do realizacji świadczonych usług. FCC w swoim zarządzeniu wyjaśnia, Ŝe
towarzystwa telekomunikacyjne nie mogą przeszkadzać lub opóźniać przenoszenie numerów
piętrząc trudności przed dostawcami nowych usług (np. Ŝądając dostarczenia nadmiernie
rozbudowanej informacji). Wnioskuje, Ŝeby ocena LNP (Location Numer Portability) dla
pojedynczego numeru portu opierała się na nie więcej niŜ czterech polach: (1) 10- cyfrowym
numerze telefonicznym, (2) numerze „customer account number”, (3) 5-cyfrowym kodzie zip
i (4) kodzie przejścia (jeśli jest stosowany). Ponadto wnioskuje, Ŝeby z technicznego punktu
widzenia procedura przenośności pojedynczego numeru portu była przeprowadzona w ciągu
48 godzin.
FCC w swoim zarządzeniu zapewnia, Ŝe uŜytkownicy i operatorzy małych sieci
bezprzewodowych mogą przenosić swoje numery telefoniczne do sieci operatorów duŜych
sieci radiowych. Ta decyzja koresponduje z postanowieniem Komisji zawartym w
zarządzeniu „Intermodal Numer Portability Order”, Ŝądającym Ŝeby FCC analizowało wpływ
wydanych w tym zakresie wymagań na małe podmioty w warunkach działania elastycznych
regulacji.
10.5. Aspekty standaryzacyjne w dokumentach RFC dotyczących przenośności
numerów
10.5.1. Wykorzystanie wskaźnika „tel” URI w przenośności numerów
Wskaźnik „tel” URI dotyczy zasobów sieciowych identyfikowanych za pomocą numeru
telefonicznego i stanowi unikalny, globalny identyfikator zwany teŜ „nazwą” („name”). „Tel”
URI odnosi się do samego numeru telefonicznego, a nie do konkretnych urządzeń fizycznych.
Numer telefoniczny, stanowiący ciąg cyfr dziesiętnych wskazujących unikalny punkt
zakończenia sieci, zawiera takŜe informację niezbędną do celów kierowania wywołania w
sieci do punktu przeznaczenia. Numer telefoniczny powszechnie rozumiany jest jako:
„address–of-record” oraz „dial string”.
W przypadku „address–of-record” numer telefoniczny jest rozumiany jako kanoniczny adres
rekordu lub identyfikator punktu zakończenia sieciowego wewnątrz określonej sieci. W
sieciach publicznych taki numer ma postać zgodną z publicznym planem numeracji E.164, a
w sieciach prywatnych jest tworzony zgodnie z własnymi zasadami przyjętymi w danej sieci.
Za pomocą takich numerów mogą być osiągani abonenci Ŝądani niezaleŜnie od lokalizacji
abonenta wywołującego, chociaŜ wiadomo, Ŝe nie wszystkie numery mogą być osiągane z
46
dowolnego miejsca, zarówno z przyczyn technicznych jak i polityki lokalnej. Jeden punkt
zakończenia sieci moŜe mieć przydzielonych kilka róŜnych identyfikatorów.
W przypadku „dial string”, numer telefoniczny jest rozumiany jako ciąg znaków
wybierczych, zawierających (wprowadzone przez uŜytkownika) cyfry, symbole i pauzy, które
słuŜą są do generowania adresu rekordu lub identyfikatora (rozumianych zgodnie z podaną
wyŜej definicją) wykorzystywanego do celów rutingu.
Numery rozumiane zarówno jako „address–of-record”, jak i „dial string” mogą być wyraŜone
jako wskaźniki URI. W Ŝądaniach przesyłanych w protokole SIP oraz w innych protokołach
sygnalizacji telefonicznej, do ich przekazania mogą być uŜyte wskaźniki „tel” URI. NaleŜy
jednak pamiętać, Ŝe „tel” URI nie określają rodzaju połączenia (głos, fax, dane), ani nie
dostarczają parametrów komunikacji, uŜywanych do negocjowania warunków połączenia.
Punkt zakończenia sieci wskazywany w numerze telefonicznym wskaźnika „tel” URI nie ma
ograniczeń w tym sensie, Ŝe moŜe się znajdować zarówno w publicznej jak i w prywatnej
sieci telefonicznej oraz w sieci Internet, która moŜe być zarówno siecią stacjonarną, jak i
ruchomą obsługującą terminale stacjonarne, ruchome i nomadyczne. Adresowany w ten
sposób terminal moŜe być wykorzystywany w realizacji usługi komunikacji elektronicznej
ECS (Electronic Communication Service) słuŜącej do przesyłania głosu, danych i faksu.
10.5.2. Składnia wskaźnika „tel”URI
Wskaźnik URI został zdefiniowany przy wykorzystaniu formy ABFN (Augmented BackusNaur Form) opisanej w dokumencie RFC 2234 [46] i uŜywa elementy określone z załączniku
A do tego standardu. Podana w dokumencie RFC 2396 [19]definicja składni wskaźnika URI
określa aktualne znaki, które mogą być zawarte w tym parametrze. JeŜeli zostaną
zarezerwowane do uŜycia we wskaźnikach „tel” URI znaki, takie jak: „ + ”, „ ; ”, „ = ” oraz „
? „ jako separatory między komponentami „tel” URI, to nie mogą być one kodowane.
Natomiast, jeśli występują jako wartości parametrów URI to muszą zostać zakodowane.
Według dokumentu RFC 3966 [9] wskaźnik „tel” URI powinien posiadać składnię
przedstawioną na rysunku 10-1.
47
Rysunek 10-1 Składnia wskaźnik „tel” URI według standardu RFC 3966
Pola takie jak nazwa parametru „pname”, subadres ISDN („isdn-subaddress”), rozszerzenie
(„extension”) i kontekst {„contex”) mogą się pojawiać tylko jeden raz. Jeśli we wskaźniku
„tel” URI są obecnie pola „isdn-subaddress” i „extension” to powinny się pojawić jako
pierwsze, przed polem „contex” oraz innymi polami pokazanymi na powyŜszym rysunku.
10.5.3. Numery telefoniczne we wskaźniku URI
Numer telefoniczny znajduje się w części „telephone-subscriber” wskaźnika URI i moŜe być
przedstawiany jako globalny (global number) lub lokalny (local number) numer E.164.
Zasadniczo wszystkie numery telefoniczne muszą uŜywać formy globalnej, chyba Ŝe nie
mogą być reprezentowane w tej postaci. Numery tworzone wg prywatnych planów numeracji
oraz numery alarmowe i kody niektóre innych usług nie mogą przybierać formy globalnych
numerów E.164 i mogą być reprezentowane w postaci numerów lokalnych z odpowiednim
kontekstem.
10.5.4. Separatory w numerach telefonicznych
Numery telefoniczne mogą zawierać wizualne separatory („visual-separator”) poprawiające
głównie czytelność sekwencji. Tego rodzaju znaki stanowią jednak komplikację w procesie
porównywania wskaźników URI. Dlatego w zaleceniu ITU-T E.123 [47] rekomenduje się
uŜywanie spacji tylko jako wizualnych separatorów na wydrukach numerów telefonicznych, a
nie we wskaźnikach „tel” URI.
10.5.5. Znaki alfabetyczne odpowiadające cyfrom
W niektórych krajach numery telefoniczne są pisane z uŜyciem liter alfabetu
odpowiadających pewnym cyfrom znajdującym się na klawiaturze aparatu telefonicznego.
Format wskaźnika URI nie obejmuje jednak takiej notacji, poniewaŜ mapowanie znaków
alfabetu na cyfry w wydaniu międzynarodowym nie zostało dotąd ujednolicone.
48
10.5.6. Znaki alfanumeryczne „*” i „#” oraz znaki słuŜące jako identyfikatory
Jeśli w protokole ISUP numery terminali abonenta wywołującego i Ŝądanego TNs (Terminal
Numbers) są przesyłane w kodzie BCD, to jedną cyfra moŜe być zakodowana za pomocą
sześciu dodatkowych wartości, czasami reprezentowanych jako znaki heksadecymalne od
„A” do „F”. Podobnie w przypadku stosowania kodu DTMF mogą być uŜywane znaki „*”,
„#” oraz litery od „A” do „D”. JednakŜe zgodnie z E.164 tego typu znaki nie mogą wchodzić
w skład globalnych numerów telefonicznych.
10.5.7. Numery globalne
Zgodnie ze specyfikacją podaną w zaleceniach ITU-T E.123 i E.164, numer globalny jest
identyfikowany za pomocą znaku „+” poprzedzającego sekwencję cyfr i musi się składać z
kodu kraju CC (Country Code) oraz krajowego numeru katalogowego abonenta NSN
(National Subscriber Number). Numer globalny jest unikalnym numerem międzynarodowym.
10.5.8. Numery lokalne
Numer lokalny jest numerem unikalnym wyłącznie w obrębie określonego obszaru
geograficznego (np. kraju, stanu, prowincji) lub w obrębie pewnej części sieci telefonicznej
(np. lokalnej centrali telefonicznej, sieci prywatnej). Wskaźniki URI z numerami lokalnymi
mogą być uŜywane tylko w środowiskach sieci, w których lokalne jednostki mogą skutecznie
zestawiać połączenia w oparciu o takie numery. Numery lokalne muszą mieć parametr
„phone-contex” wskazujący zakres ich waŜności.
10.5.9. Parametry związane z przenośnością numerów wykorzystane we
wskaźniku „tel”URI
Standard RFC 4694 [16] definiuje pięć parametrów wskaźnika URI (Uniform Resorce
Identifier (URI) słuŜących do przenoszenia informacji związanych z przenośnością numeru
NP. (Numer Portability). Te parametry mogą być przekazywane do kolejnych węzłów sieci
znajdujących się w łańcuchu połączeniowym wtedy, gdy w bazie danych przenoszonych
numerów zostanie utworzony wskaźnik „npdi”.
10.5.9.1 Informacje ogólne
Usługa przenośności numerów pozwala abonentom telefonicznym zachować swoje numery
[9]w sytuacji, kiedy zmieniają oni dostawcę usługi (przenośność dostawcy usługi),
przechodzą do nowej lokalizacji (przenośność lokalizacyjna) lub zmieniają abonowaną usługę
(przenośność usługi). Numerami telefonicznymi mogą być numery geograficzne, komórkowe,
bezpłatne oraz inne numery niegeograficzne.
Przenośność numeru ma wpływ na sygnalizację i kierowanie połączeń w sieci. Bierze się to
po pierwsze, z potrzeby przekazania informacji o przenośności we wskaźniku „tel” URI [9] w
protokołach takich jak: SIP [RFC 3261] i H.323 [H.323], po przetworzeniu wskaźnika „NP
Database dip” w bazie danych numerów przeniesionych. Po drugie, z potrzeby
wykorzystywania informacji o przenośności przez serwer usługi VoIP do określenia drogi
rutingu.
Numer rutingowy jest powiązany z numerem geograficznym lub komórkowym
przeniesionym z sieci operatora zwanego „Dawcą” („donor carrier”) do operatora innej sieci,
gdzie przez „Dawcę” („donor carrier”) rozumie się pierwotnego operatora sieci, w której
został przydzielony numer geograficzny zanim jeszcze został przeniesiony. Numery
geograficzne, które nie są przenoszone oraz numery komórkowe nie mają numerów
rutingowych, poniewaŜ „N” pierwszych cyfr numeru geograficznego i komórkowego moŜe
być uŜytych do celów rutingu. Numer rutingowy moŜe być uŜyty takŜe do wskazania switch’a
49
lub węzła inicjującego połączenie lub usługę podobną do realizowanej w systemie
sygnalizacji SS7/ISUP (Signalling System Number 7/Integrated Services Digital Network
User Part), umoŜliwiającej przesyłanie parametru JIP (Jurisdication Information Parametr).
Parametr „rn” przenosi informację o numerze rutingowym. Parametr „rn-contex” opisuje jak
powinna być interpretowana wartość parametru „rn”, jeśli nie ma ona postaci ‘global-rn”.
Wskaźnik „NP Database dip” słuŜy do informowania serwerów lub switch’y niŜszej warstwy
sieci w czasie w zestawianiu połączenia, Ŝe dla danego numeru geograficznego nie istnieje
potrzeba tworzenia ponownie tego wskaźnika. Taki wskaźnik jest przenoszony w parametrze
„npdi”.
Kod identyfikacji operatora CIC (Carrier Identification Code) określa właściwego dla
dowolnego numeru bezpłatnego dostawcę usługi połączeń bezpłatnych (freephone service
provider). Tego rodzaju informacja jest przenoszona w parametrze „cic”. W parametrze „ciccontex” jest przekazywana informacja, która opisuje jak powinna być interpretowana wartość
parametru „cic”, jeśli nie ma ona postaci ‘global-rn”. Ten parametr moŜe być takŜe
wykorzystywany do przenoszenia informacji wprowadzonych na etapie abonowania usługi.
10.5.10. Specyfikacja składni pola „parametr” wskaźnika „tel” URI
Podana niŜej składnia wykorzystuje formę ABFN (Augmented Backus-Naur Form) opisaną w
dokumencie [35] i zawiera pięć parametrów, takich jak: „rn”, „npdi”, „cic”, „rn-contex”i „ciccontex” powstałych z rozszerzenia pola „parametr” wskaźnika „tel URI zdefiniowanego w
standardzie [9].
Rysunek 10-2 Składnia pola „parametr” wskaźnika „tel” URI
Parametry „rn”, „npdi”i „cic” mogą się pojawić tylko raz w polu wskaźnika „tel” URI.
Pierwsza wartość „hex-phonedigit” w polu „local-rn” lub „local-cic” musi być cyfrą
heksadecymalną.
Informacja o numerze rutingowym umieszczona po znaku “+” w polu „global-rn” musi
rozpoczynać się od kodu kraju zgodnego z E.164. W tym polu cyfra heksadecymalna jest
dozwolona dopiero po tym kodzie.
Informacja o numerze rutingowym przekazywana w parametrze „rn” pola „local-rn” musi być
interpretowana zgodnie z opisem podanym w polu „rn-contex” tzn. w przypadku, gdy
50
parametr „rn” ma format „global-hex-digits” i jeśli w tym parametrze znajduje się krajowy
numer rutingowy to „rn-contex” musi zawierać aktualny kod kraju zgodny z E.164
poprzedzony znakiem „+”. W polu „local-rn” są dozwolone cyfry heksadecymalne.
Informacja „cic” umieszczona po znaku “+” w polu „global-cic” musi rozpoczynać się od
kodu kraju zgodnego z E.164.
Wartość „cic” w parametrze „cic” pola „local-cic” musi być interpretowana zgodnie z opisem
podanym w polu „cic-contex” tzn. w przypadku, gdy parametr „cic” ma format „global-hexdigits” i jeśli w tym parametrze znajduje się wartość „cic” operatora krajowego to „ciccontex” musi zawierać aktualny kod kraju zgodny z E.164 poprzedzony znakiem „+”.
Włączenie wizualnych separatorów w pola „rn”, „npdi”i „cic” jest opcjonalne.
10.5.11. Ogólne zasady obsługi wskaźnika „tel” URI
WyróŜnia się dwa sposoby wykorzystania wskaźnika „tel” URI. W pierwszym z nich „tel”
URI pojawia się w stałej zawartości (static content), tzn. Ŝe moŜe się on pojawić na stronie
HTML (HyperText Markup Language). W drugim przypadku ten wskaźnik pojawia się w
protokole sygnalizacji telefonicznej, takim jak SIP lub H.323, który zostanie uŜyty do
wymiany wiadomości dla zestawienia połączenia. Omawiane tu rozszerzenia funkcjonalne
„tel” URI odnoszą się do takich właśnie protokołów sygnalizacyjnych. W przypadku, gdy
„tel” URI jest ulokowany w stałej zawartości to zdefiniowane wcześniej parametry nie
powinny być prezentowane, a jednostka odbierająca powinna je usunąć zanim rozpocznie
analizę odebranej wiadomości.
Przekazywane w protokołach sygnalizacyjnych parametry URI mają znaczenie wtedy, gdy są
stosowane między jednostkami sygnalizacyjnymi i węzłami sieci Ŝądanej, które mają do
siebie zaufanie, poniewaŜ parametry wstawione przez węzeł jednej sieci mogą wpływać na
ruting, za który jest odpowiedzialny inny węzeł sieci. Jeśli jakiś węzeł sieci odbierze
wiadomość sygnalizacyjną od jednostki, co do której nie ma całkowitej pewności, to
powinien zignorować odebrane parametry.
Kwestia, w jaki sposób węzeł sieci obsługuje odebrane wskaźniki „tel” URI zawierające jeden
lub kilka takich parametrów, gdy ma udostępnioną bazę danych numerów przeniesionych dla
numerów bezpłatnych (NP Database for freephone numbers) lub numerów geograficznych
(NP Database for geographical telephone numbers) i potrzebuje wstawić niektóre z nich w
pole wskaźnika „tel” URI, jest omówiona w pkt. 10.5.12 niniejszego raportu.
NaleŜy zauwaŜyć, Ŝe zwykle są podejmowane dwie próby dostępu do baz danych numerów
bezpłatnych (freephone Databases) dla potrzeb do kierowania połączeń do takich numerów.
Pierwsza próba jest wykonywana przez sieć inicjującą połączenie, kiedy zwraca się do bazy
danych z zapytaniem w sprawie pozyskania informacji „cic” po to, Ŝeby połączenie mogło
zostać skierowane do właściwego dostawcy obsługi numerów bezpłatnych (serving freephone
provider) obsługującego Ŝądany numer. Kiedy juŜ połączenie osiągnie takiego właśnie
dostawcę usługi wykonywane jest drugie podejście do bazy danych w celu mapowania
numeru bezpłatnego na numer geograficzny.
Baza danych numerów bezpłatnych uŜywana jako pierwsza zawiera informacje „cic” dla
wszystkich aktywnych numerów bezpłatnych, natomiast druga baza danych zawiera zwykle
informacje mapowane tylko dla tych numerów bezpłatnych, które są obsługiwane przez
danego dostawcę obsługującego takie numery. PoniewaŜ operator sieci inicjującej połączenie
moŜe świadczyć usługę połączeń bezpłatnych, to jego baza danych tych numerów powinna
zawierać informacje „cic” dla wszystkich aktywnych numerów bezpłatnych oraz informacje
uzyskane w wyniku mapowania dla tych numerów, które on obsługuje.
51
W przypadku obsługi parametrów „rn” i „cic” oraz numerów telefonicznych znajdujących się
we wskaźniku „tel” URI dla potrzeb związanych z dostępem do bazy danych i rutingiem,
występujące w nich wizualne separatory są usuwane zanim jeszcze zostanie uŜyta informacja
w nich zawarta.
Kiedy węzeł sieci obsługuje „tel” URI zawierający błędną informację „rn” lub „cic” to moŜe
rozłączyć połączenie lub pominąć ten błędny parametr i skorzystać z dostępu odpowiednio z
bazy danych NP lub bazy numerów bezpłatnych, Ŝeby sprawdzić, czy moŜe pozyskać
prawidłowy numer rutingowy dla numeru geograficznego i prawidłowy „cic” dla numeru
bezpłatnego.
Kiedy wskaźnik „tel”URI zostanie odebrany z „niepewnego” źródła, węzeł sieci moŜe
skierować zapytanie do bazy NPDB.
Protokół SIP [RFC 3261] posiada mechanizmy słuŜące do wykrywania pętli rutingu (routing
loops) spowodowanych wpisywaniem nowych wartości wskaźnika „tel” URI w czasie
zestawiania połączenia. Parametr „npdi” w URI, który wskazuje, Ŝe zapytanie kierowane do
bazy NPDB miało miejsce, moŜe takŜe słuŜyć do zabezpieczenia drogi rutingu. TakŜe inne
protokoły przenoszące wskaźnik „tel” URI powinny być wyposaŜone w mechanizmy
umoŜliwiające detekcję pętli rutingu w przypadkach, kiedy zostaną wpisywane nowe wartości
tego wskaźnika.
10.5.12. Obsługa wskaźnika „tel” URI z jednym lub z wieloma parametrami
W przypadku, gdy „tel” URI zawiera parametr „npdi”, węzeł sieci nie musi pozyskiwać
informacji o przenośności dla danego numeru geograficznego, nawet gdy jest tak
skonfigurowany, Ŝe powinien to robić.
Jeśli „tel” URI zawiera parametr „cic”, w którym wartość „cic” róŜni się od wartości tego
węzła sieci, z którym jest powiązana, to taki węzeł nie musi pozyskiwać informacji o
przenośności numeru geograficznego lub podejmować pierwszej próby dostępu do bazy
danych numerów bezpłatnych dla numeru bezpłatnego odebranego w „tel” URI.
W przypadku odebrania dwóch parametrów „cic” i „rn” (albo dla numeru bezpłatnego albo
dla geograficznego), najpierw jest przetwarzana informacja związana z „cic”. Jeśli ta
informacja jest niepełna lub parametr „cic” nie wystąpił, to dopiero wówczas są przetwarzane
informacje związane z parametrem „rn”. Gdy informacja zawarta w „rn” jest niepełna lub taki
parametr w ogóle nie wystąpił, wtedy jest wykorzystywany numer bezpłatny lub
geograficzny.
W przypadku, gdy węzeł sieci nie wie jak kierować połączenia bazując na informacji „cic”
lub „rn”, wówczas lokalne przepisy powinny regulować, czy w takiej sytuacji obsługa
połączenia powinna zostać przerwana czy kontynuowana z pominięciem informacji
nieprawidłowych lub nieznanych.
Kiedy parametr „cic” istnieje w polu wskaźnika „tel” URI i jest brany pod uwagę, wówczas
węzeł sieci musi:
-
pominąć informacje „cic”, które dotyczą operatora lub dostawcy usługi z nim
powiązanych i przeanalizować informacje zawarte w parametrze „rn” w celu podjęcia
działań związanych z rutingiem,
-
wywołać specjalny proces obsługi, jeśli parametr „cic” zawiera kod, który wymaga
takiego potraktowania,
-
w przeciwnym przypadku musi podjąć decyzję odnośnie kierowania połączenia w
oparciu o informacje „cic”; nie musi usunąć parametru „cic”, chyba, Ŝe ten węzeł
52
nadal obsługuje to połączenie do sieci operatora lub dostawcy usługi wskazanego w
tym parametrze i lokalne regulacje wymagają usunięcia tego parametru.
Kiedy parametr „rn” istnieje w polu wskaźnika „tel” URI i jest brany pod uwagę, wówczas
węzeł sieci musi przeprowadzić analizę numeru bezpłatnego lub geograficznego w celu
podjęcia decyzji odnośnie kierowania połączenia w sytuacji, gdy:
-
numer rutingowy wskazuje na ten właśnie węzeł sieci (tzn. gdy połączenie osiągnęło
zamierzony węzeł sieci); usunąć parametr „rn” po zestawieniu połączenia do
następnego węzła sieci w łańcuchu połączeniowym, niezaleŜnie od tego, czy taki
węzeł znajduje się w tej samej, czy w innej sieci,
-
numer rutingowy wskazuje na sieć, w której znajduje się ten właśnie węzeł (w
niektórych krajach numer rutingowy kieruje połączenie do sieci operatora
obsługującego, w której wymagany jest dostęp do bazy danych numerów
przeniesionych w celu zlokalizowania obsługującego switch’a); moŜe ponadto
uzyskać dostęp do bazy danych numerów przeniesionych w celu pobrania informacji
rutingowej (jeśli jest tak skonfigurowany) i usunąć parametr „rn”, gdy następny węzeł
w łańcuchu połączeniowym naleŜy do innego operatora sieci lub dostawcy usługi,
-
w przeciwnym przypadku musi podjąć decyzję odnośnie kierowania połączenia w
oparciu o numer rutingowy znajdujący się w parametrze „rn”.
W przypadku, gdy parametr „cic” lub „rn” nie został zastosowany, węzeł sieci uŜywa numeru
bezpłatnego lub geograficznego przy podejmowaniu decyzji dotyczącej rutingu. Jeśli zestawia
połączenie, moŜe skorzystać z bazy danych numerów przeniesionych i skierować połączenie
do węzła sieci wyznaczonego w tej bazie lub moŜe kierować połączenie w oparciu o lokalną
tablicę rutingu.
10.5.13. Dodawanie parametru lub parametrów do wskaźnika „tel” URI
WyróŜnia się dwa przypadki dostępu do bazy danych numerów przeniesionych - jeden
dotyczy numerów geograficznych, a drugi numerów bezpłatnych. Zostały one opisane w
punktach 10.5.13.1 i 10.5.13.2, pod kątem informacji przekazywanej z bazy danych NP we
wskaźniku „tel” URI i jej wykorzystania w rutingu.
10.5.13.1
Pozyskiwanie informacji o przenośności numerów geograficznych
W przypadku, gdy węzeł sieci korzysta z dostępu do bazy danych NP w odniesieniu do
numeru geograficznego i pozyskuje informację o numerze rutingowym musi dodać parametr
„rn’ do wskaźnika „tel” URI, aby przekazać tę informację w formacie „global-rn” lub „localrn”. Musi takŜe dodać parametr „npdi”.
W sytuacji, gdy nie pozyskuje takiej informacji (np. dla nieprzenoszonych numerów
geograficznych) musi dodać tylko parametr „npdi’ do wskaźnika „tel” URI.
10.5.13.2
Pozyskiwanie informacji o przenośności numerów bezpłatnych
W przypadku, gdy węzeł sieci wykona pierwszy lub drugi dostęp do bazy danych w
odniesieniu do numeru bezpłatnego i pozyska informację „cic” wskazującą operatora sieci
albo dostawcę usługi stowarzyszonego z tym węzłem lub wskazującą, Ŝe moŜe uzyskać
wsparcie w translacji numeru geograficznego (np. w translacji numeru lokalnego), to
powinien podjąć próbę pozyskania numeru geograficznego. Nie musi dodawać parametru
„cic”, natomiast musi zastąpić we wskaźniku „tel” URI numer bezpłatny pozyskanym
numerem geograficznym, podając go albo w formacie „global-rn” albo w „local-rn”.
53
Niektóre bazy danych numerów bezpłatnych mogą nie przekazywać zwrotnie geograficznego
numeru telefonicznego tylko wewnętrzną informację rutingową w odpowiednim formacie
(np. w formie identyfikatora switch’a lub grupy łączy).
W sytuacji, gdy węzeł sieci pozyska „cic” naleŜący do innego dostawcy obsługującego
numery bezpłatne musi tę informację umieścić we wskaźniku „tel” URI w formacie „globalcic” lub „local-cic”.
Operator sieci inicjującej połączenie moŜe mieć podpisaną umowę biznesową z dostawcą
obsługującym numery bezpłatne na dostarczanie numeru geograficznego razem z informacją
„cic”. Jeśli numer geograficzny zostanie dostarczony do węzła sieci, to taki węzeł powinien
zastąpić we wskaźniku „tel” URI numer bezpłatny pozyskanym numerem geograficznym,
podając go albo w formacie „global-number” albo „local-number”.
JeŜeli węzeł sieci pozyska numer geograficzny, który jest rutynowo podawany w czasie
drugiego dostępu do bazy danych numerów bezpłatnych, musi zastąpić we wskaźniku „tel”
URI numer bezpłatny pozyskanym numerem geograficznym, podając go albo w formacie
„global-number” albo „local-number”.
W sytuacji, gdy jest podawany zwrotnie numer geograficzny (w wyniku odpowiedzi bazy na
odebrane Ŝądanie), istnieje moŜliwość podawania zwrotnie takŜe informacji o przenośności
dla tego numeru geograficznego. W takim przypadku węzeł sieci musi dodać parametr „npdi”
oraz parametr „rn” zawierający numer rutingowy w formacie „global-rn” lub „local-rn”, jeśli
taki numer jest dostępny.
10.5.14. Dodawanie informacji o lokalizacji abonenta wywołującego
Przekazywany w protokole sygnalizacyjnym SS7 parametr JIP (Jurisdiction Information
Parametr) określa switch, który inicjuje połączenie. Informacje zawarte w tym parametrze
mogą być wykorzystane przez operatora obsługującego połączenie do celów zaliczania
połączeń na konto abonenta wywołującego lub przez operatorów współpracujących do celów
rozliczeń międzyoperatorskich.
Węzeł sieci, znajdujący się jako pierwszy w łańcuchu połączeniowym obsługującym abonenta
wywołującego, moŜe włączyć parametr „rn” do wskaźnika „tel” URI stowarzyszonego z tym
abonentem. Oznacza to, Ŝe jeśli węzeł sieci stanowiący np. bramę GSTN (Global Switched
Telephone Network) odebrał wiadomość ISUP zawierającą parametr JIP, to przekazaną w
tym parametrze informację lokalizacyjną moŜe umieścić w parametrze „rn” wskaźnika „tel”
URI powiązanego z tym abonentem.
NaleŜy podkreślić, Ŝe informacja przekazywana w parametrze „rn” moŜe nie być
autoryzowana, dlatego uŜycie jej przez odbiorcę wskaźnika „tel” URI dla jakichkolwiek
działań związanych z zaliczaniem jest wykonywane na jego własne ryzyko.
10.5.15. Dodawanie parametru lub parametrów NP z powodu konwersji
protokołów
W węźle sieci GSTN jest wymagana konwersja wiadomości protokołu SS7 na odpowiadające
im wiadomości protokołu SIP lub H.323. Ten rodzaj węzła sieci musi wykonywać
mapowanie (odwzorowanie) parametrów protokołu ISUP na odpowiednie parametry
wskaźnika „tel” URI protokołu SIP lub H.323 dla celów rutingu. MoŜe takŜe mapować
parametry protokołu ISUP na odpowiednie parametry wskaźnika „tel” URI protokołu SIP lub
H.323, które są powiązane z abonentem wywołującym.
W przypadku przenoszenia numerów geograficznych, węzeł sieci musi dokonywać konwersji
numeru rutingowego z formatu przekazywanego w parametrze Numer Abonenta Źądanego
54
(Called Party Number) protokołu ISUP na format „global-rn” lub „local-rn” i przekazać go w
parametrze „rn” wskaźnika ‘tel” URI uŜywanego do celów rutingu. Węzeł sieci musi
skonwertować numer telefoniczny, który w parametrze GAP (Generic Address Parametr)
protokołu ISUP został oznaczony jako „numer przeniesiony” („ported number”) na
odpowiadający mu numer telefoniczny w formacie „global-number” lub „local-number” [9] i
wstawić go w pole oznaczone w dokumencie RFC 3966 [9] jako „global-number-digits” lub
„local-number-digits”, które stanowi część wskaźnika „tel” URI uŜywaną do rutingu.
W przypadku, gdy numer geograficzny nie jest przenoszony, węzeł sieci musi dokonywać
konwersji numeru telefonicznego z formatu przekazywanego w parametrze Numer Abonenta
śądanego (Called Party Number) protokołu ISUP na format „global-number” lub „localnumber” i wstawiać go w pole oznaczone w dokumencie RFC 3966 [9] jako „global-numberdigits” lub „local-number-digits”, które stanowi część wskaźnika „tel” URI uŜywaną do
rutingu. Parametr „rn” nie musi pojawiać się we wskaźniku „tel” URI chyba, Ŝe jest to
wymagane zgodnie z lokalną polityką regulacyjną.
Węzeł sieci musi włączać do wskaźniku „tel” URI parametr „npdi”, kiedy bit PNTI (Ported
Numer Call Indicator) parametru FCI (Forward Call Indicator) jest ustawiony na wartość „1”,
poniewaŜ jest on wykorzystywany do rutingu.
Z tego samego powodu węzeł sieci musi włączać do wskaźniku „tel” URI parametr „cic” w
formacie „global-cic” lub „local-cic”, kiedy jest prezentowany parametr CIP (Carrier
Identification Parametr).
Węzeł sieci moŜe włączać do wskaźniku „tel” URI, stowarzyszonego z abonentem
wywołującym, parametr „rn” w formacie „global-rn” lub „local-rn”, kiedy jest prezentowany
parametr JIP wiadomości ISUP, ale to moŜe zaleŜeć od zaprogramowania węzła sieci i
stosowanej wersji systemu sygnalizacji, który przenosi wskaźnik „tel” URI, czyli od lokalnej
polityki regulacyjnej.
Mapowanie informacji o przenośności numeru przekazywanych we wskaźniku „tel” URI na
odpowiadające im informacje przekazywane w wiadomościach protokołu ISUP zaleŜy od
krajowej implementacji protokołu ISUP.
10.5.16. Kwestie związane z bezpieczeństwem
Dodatkowo, w stosunku do kwestii bezpieczeństwa omówionych w standardzie [9], w
standardzie RFC 4694 [16] przedstawione zostały nowe zagadnienia powiązane z
przekazywaniem parametrów opisanych wcześniej w tym dokumencie.
W przypadku, gdy wartości parametrów „rn” lub „cic” wskaźnika „tel” URI zostaną
zmienione nielegalnie podczas ich przenoszenia w wiadomości sygnalizacyjnej w czasie
kierowania połączenia do punktu przeznaczenia, wiadomość sygnalizacyjna lub wywołanie
mogą zostać skierowane błędnie do niewłaściwej sieci lub węzła, co spowoduje, Ŝe zostaną
odrzucone. Podobnie w sytuacji, gdy wartość parametru „ndpi” zostanie nielegalnie
wprowadzona do wskaźnika „tel” URI podczas przenoszenia tego wskaźnika w czasie
kierowania połączenia do punktu przeznaczenia, wywołanie moŜe zostać skierowane błędnie
do niewłaściwej sieci lub węzła, co spowoduje, Ŝe zostanie odrzucone.
Mniejszy problem stanowi nielegalne zastąpienie istniejącej wartości „ndpi” inną, poniewaŜ
w takiej sytuacji moŜe być wykonane dodatkowe zapytanie do bazy danych NPDB (Numer
Portability Database) w sprawie pozyskania informacji o numerze rutingowym i dzięki tej
operacji moŜe być wprowadzona właściwa wartość „ndpi” korygująca poprzednią. Natomiast
jeśli zostanie w sposób nielegalny zmieniona lub wstawiona wartość parametru „rn” we
55
wskaźniku „tel” URI stowarzyszonym z abonentem wywołującym, to w oparciu o błędny
numer będzie nieprawidłowo realizowane zaliczanie połączeń.
Ze względu na te zagroŜenia, opisane tu rozszerzenia wskaźnika „tel’ URI są stosowane tylko
pomiędzy węzłami sieci, które mają do siebie wzajemne zaufanie. JeŜeli dany węzeł odbierze
wiadomość sygnalizacyjną od węzła znajdującego się wyŜej w hierarchii sieci (upstream
node), co do którego nie ma pełnego zaufania, powinien odrzucić przekazane mu parametry,
ale to będzie powodować generowanie wielu zapytań do bazy NPDB..
Aby zweryfikować, czy sąsiedni węzeł w wyŜszej warstwie sieci jest „pewny” i aby zapobiec
atakom pochodzący od środka sieci (man-in-the-middle attacks), polegającym na wstawianiu
lub modyfikacji tych parametrów, protokoły słuŜące do ich przekazywania powinny
zapewniać integrację wiadomości w trybie „hop-by-hop” (hop-by-hop message integrity),
poniewaŜ wtedy protokół SIP będzie wspomagany mechanizmem SIPS URI (Session Initlal
Protocol Secure URI).
10.5.17. Mapowanie adresów E.164 na wskaźniki URI dla „infrastrukturalnego
ENUM” przy zastosowaniu aplikacji DDDS
10.5.17.1
Informacje ogólne
Standard RFC 5526 [36] definiuje uŜycie „infrastrukturalnego ENUM” i przedstawia
propozycję jego implementacji, jako przestrzeni nazw („namespace”) uŜywanej równolegle z
rozszerzeniem „e164.arpa” zdefiniowanym w standardzie RFC 3761 [38]: „The E.164 to
Uniform Resource Identifiers (URI) Dynamic Delegation Discovery System (DDDS)
Application (ENUM)”. Ta propozycja jest traktowana jako próba rozwiązania w dłuŜszym
okresie czasu problemu dostarczania (przez operatorów sieci) rekordów DNS (dla numerów
telefonicznych) niezaleŜnie od numerów dostarczanych przez uŜytkowników końcowych.
ENUM (E.164 Number Mapping) jest systemem [39], który przekształca numery E.164 na
nazwy domenowe, a następnie wykorzystuje system DNS (Domain Name System) do
wyszukiwania rekordów NAPTR określających, które usługi są dostępne dla określonej
nazwy domenowej.
ENUM posiada ogromny potencjał do wspierania w dłuŜszym okresie czasu nowych usług i
wyborów dokonywanych przez uŜytkowników końcowych. Jest to waŜna cecha, poniewaŜ
obowiązujące obecnie wymagania w zakresie komunikacji międzyoperatorskiej przy
wykorzystaniu domen VoIP, wymagają dostarczania duŜej ilości przydzielonych lub
obsługiwanych (hosted) numerów przez współpracujących dostawców usług. Tą drogą
dostawcy usług mogą dostarczać swoje własne, odrębne informacje ENUM, które
prawdopodobnie będą się róŜnić od informacji dostarczonych przez uŜytkownika końcowego.
Jest to szczególnie waŜne, w przypadku, gdy „infrastrukturalny ENUM” zostanie
wykorzystywany do przenośności numerów, gdy np. uŜytkownik końcowy będzie
zainteresowany moŜliwością dostarczania swoich danych, a dostawca usługi znalezieniem
prawdziwych danych.
Jeśli usługi VoIP staną się powszechne, połączenia telefoniczne wykorzystujące adresy E.164
nie będą wymagały przekierowywania do sieci PSTN. Dlatego dostawcy usług VoIP są
zainteresowani uŜywaniem systemu ENUM na bazie tzw. „infastuktury” („Infrastructure”) w
celu przechowywania informacji o ruchu VoIP w trybie „od końca do końca” zarówno w
obrębie swoich własnych sieci, jak i o ruchu wymienianym między domenami róŜnych
dostawców. Wymaga to zastosowania środków do identyfikacji punktów dołączenia
(interconnection), do których połączenia z adresami E.164 mogą być dostarczone, a które
właśnie zapewnia „infrastrukturalny ENUM”. Połączenia, które się rozpoczynają i kończą w
56
sieciach IP i nie są przekierowywane do sieci PSTN wymagają mniejszej liczby punktów
transkodowania danych, a nawet mogą nie wymagać wcale stosowania takich punktów i
oprócz innych korzyści mogą słuŜyć do wywoływania innych usług IP, których realizacja nie
jest moŜliwa w sieci PSTN.
Wymagania dotyczące „Infrastrukturalnego ENUM” („Infrastructure ENUM”) zostały podane
w standardzie RFC 5067 [39]: „Infrastructure ENUM Requirements”.
10.5.17.2
Propozycja przestrzeni adresowej dla „infrastrukturalnego ENUM”
W standardzie RFC 5526 [36] proponuje się, Ŝeby „infrastrukturalny ENUM” był
implementowany przy pomocy przestrzeni nazw równoległej do przestrzeni z rozszerzeniem
„e.164.arpa (dedykowanej „infrastrukturalnemu ENUM”) w domenie, która zostanie dopiero
określona. UŜywanie równowaŜnych nazw pozwoli operatorom sieci i uŜytkownikom
końcowym kontrolować ich własne nazwy całkowicie niezaleŜnie tzn. bez angaŜowania
innych operatorów i uŜytkowników.
Rekordy zasobów „infrastrukturalnego ENUM Tier 2” powinny być kontrolowane przez
dostawcę usługi, który dostarcza usługi do danego numeru E.164, jako tzw. operator „carrierof-record”. Definicja operatora „carrier-of-record” jest sprawą regulatorów krajowych i
powinna być podana przez organ kontrolujący krajową przestrzeń adresową.
10.5.17.3
Rejestry IANA dla „Enumservices”
IANA wykreowała oryginalne rejestry dla usług „Enumservices”, wyspecyfikowane w
standardzie RFC 2916 [17] i zrewidowane w standardzie RFC 3761 [38], które są tak samo
waŜne dla „infrastrukturalnego ENUM”, jak i dla „ENUM uŜytkownika końcowego” („enduser ENUM”).
10.5.18. Wymagania na ENUM infrastrukturalny
10.5.18.1
Informacje ogólne
Wymagania na tzw. „infrastrukturalny ENUM” („infrastructure” ENUM) oraz na tzw.
„operatorski ENUM” („carrier” ENUM) zostały podane w standardzie RFC 5067 [39]:
„Infrastructurte ENUM Requirements”. Standard definiuje uŜycie technologii opisanych w
standardzie RFC 3761 [38] do komunikacji między sieciami róŜnych operatorów (to
interconnection) przy realizacji usług opatrzonych numerem E.164, w szczególności usług
VoIP, ale nie tylko.
„Infrastrukturalny ENUM” został zdefiniowany jako rozwiązanie działające na bazie systemu
opisanego w standardzie RFC 3761, stosowane przez tzw. operatora rekordów („carrier-ofrecord”) do mapowania numeru E.164 na wskaźnik URI, wskazujący określony punkt
dołączenia (interconnection) do sieci dostawcy usługi. Jest to odrębny wskaźnik URI od tego,
który uŜytkownik końcowy chciałby powiązać ze swoim numerem E.164.
ENUM „infrastrukturalny” jest czymś innym niŜ tzw. „ENUM uŜytkownika końcowego”
(„End User ENUM”), który zgodnie z definicją podaną w standardzie RFC 3761 działa w ten
sposób, Ŝe jednostka lub osoba mająca prawo do uŜywania jakiegoś numeru ma całkowitą
swobodę w zakresie uŜywania zawartości stowarzyszonej z nim domeny (content of
associated domain), a tym samym zawartości strefy (zone content). Z perspektywy rejestracji
domeny, przypisujący numer abonenta końcowego jest traktowany jako „registrant”. W
obszarze nazw „infrastrukturalnego ENUM” jest uŜywane określenie „carrier-of-record” w
odniesieniu do jednostki mającej zezwolenie na uŜywanie zawartości nazw domeny i strefy i
działającej jako „registrant”. Operatorem „carrier-of-record” moŜe być:
57
-
dostawca usługi, któremu został przydzielony (przez NRA (National Regulatory
Authority) lub ITU) numer E.164 dla przypisanego uŜytkownika końcowego np.
(+882) dla komunikacji międzynarodowej lub (+878) dla komunikacji personalnej
UPT (Universal Personal Telecommunications),
-
dostawca usługi, do którego został przeniesiony numer (w przypadku przenośności
numeru),
-
dostawca usługi, który dla przydzielonego numeru abonenta końcowego dostarcza dla
tego numeru punkt dołączenia (interconnection) w sieci PSTN/PLMN (w przypadku,
gdy numery są przypisywane bezpośrednio do uŜytkowników końcowych).
10.5.18.2
Wymagania na ENUM infrastrukturalny
1. „Infrastrukturalny ENUM” powinien zapewniać dostawcom usług środki do
generowania rekordów RR (Resource Records) systemu DNS dla zasobów
numeracyjnych E.164, z których korzysta operator „carrier-of-record” w formie
jednej, wspólnej przestrzeni nazw. Taka przestrzeń, która zostanie ostatecznie
wyznaczona moŜe, ale nie musi być taką samą przestrzenią nazw, która zostanie
wyznaczona dla „ENUM uŜytkownika końcowego” (e.164.arpa). W pełni
kwalifikowana nazwa domenowa FQDN (Fully-Qualified Domain Name) w
wynikowych rekordach RR nie musi koniecznie naleŜeć do/lub identyfikować
„operatora rekordu”.
2. Na zapytania, kierowane do „infrastrukturalnego ENUM” zawierającego nazwy
FQDN, muszą być nadawane zwrotnie odpowiedzi nawet wtedy, gdy wynik zapytania
nie zawiera właściwej odpowiedzi (RCODE=5), poniewaŜ zapytania nie mogą być
odrzucane bez odpowiedzi.
3. „Infrastrukturalny ENUM” powinien generować rekordy RR przekazujące wskaźnik
URI, który moŜe identyfikować punkt dołączenia (interconnection) dla dostarczania
do „dostawcy rekordu” komunikacji zaadresowanej zgodnie z E.164.
4. „Infrastrukturalny ENUM” powinien zapewniać wsparcie w realizacji usługi IRIS
(Internet Registry Information Service), umoŜliwiającej kwalifikowanym jednostkom
otrzymywanie informacji dotyczącej zasobów numeracyjnych E.164 i
odpowiadającego im „operatora rekordu”.
5. Implementacja „infrastrukturalnego ENUM” (w warunkach konkurencji) nie moŜe
ograniczać zdolności uŜytkownika końcowego w zakresie wyboru „registrator’a” i/lub
dostawcy serwera nazwy (name server provider) dla celów rejestracji prowadzonej w
ramach „ENUM uŜytkownika końcowego”.
6. Nazwa domenowa wybrana dla „infrastrukturalnego ENUM” oraz inne nazwy muszą
być host’owane w serwerach nazw (konfigurowanych stosownie do potrzeb
„infrastrukturalnego ENUM”), posiadających moŜliwości obsługi infrastruktury sieci
porównywalnej z tą, która jest wykorzystywana dla potrzeb serwerów „Internet root
name servers”.
7. „Infrastrukturalny ENUM” musi spełniać wszystkie istotne wymagania w zakresie
prywatności związane m.in. z uwidacznianiem informacji, za pomocą której
uŜytkownik końcowy moŜe być kontrolowany, w tym sensie, Ŝe powinien zapewniać
np. mechanizmy wyszukiwania numerów skrytych poprzez porównywanie rejestracji
ENUM z wykazami numerów katalogowych lub wyjawienie toŜsamości uŜytkownika.
58
8. Proponowane implementacje „infrastrukturalnego ENUM” powinny uwzględniać
następujące uwarunkowania:
-
minimalizować ilość zmian wymaganych do wprowadzenia w istniejących
wymaganiach zawartych standardzie RFC 3761,
-
zapewniać moŜliwość pracy zarówno na otwartym, jak i zamkniętym planie
numeracji,
-
nie wymagać (w ogólności) dodatkowych funkcjonalności w programach, które
zajmują się wysyłaniem zapytań i dostarczaniem odpowiedzi (resolvers), chociaŜ
mogą wymagać dodatkowych funkcjonalności w takich programach (będących w
posiadaniu dostawcy usługi), który będzie uŜywał „infrastrukturalny ENUM”,
-
minimalizować (w razie moŜliwości) i ilość prób pobierania rekordów NAPTR,
-
maksymalizować synergię z „ENUM uŜytkownika końcowego”,
-
zapewniać współpracę z prywatnymi aplikacjami (ENUM trees) systemu ENUM,
przez które rozumie się rozwiązania nie pracujące na nazwach „e.164.arpa” lub
jakichkolwiek innych przestrzeniach nazw wybranych dla „infrastrukturalnego
ENUM”, lecz uŜywające w zastępstwie domeny nazw prywatnych.
10.5.18.3
Podsumowanie
„ENUM Infrastrukturalny”, wykorzystujący nazwy „e164.arpa” lub inne publicznie dostępne
drzewa dla tej numeracji, zapewnia dostawcom usług moŜliwość kojarzenia zasobów
internetowych wskazywanych przez URI z numerami E.164. Pozwala to dostawcom usług
internetowych na „czystą” (peer) współpracę międzyoperatorską (interconnecting) sieci IP z
pominięciem sieci PSTN/PLMN. Dzięki temu dostawcy usług mogą ogłaszać numery E.164
oraz zakresy numeracji, które host’ują., niezaleŜnie od tego, czy wyposaŜenie sieciowe
uŜytkownika końcowego znajduje się w sieci Internet, w sieciach NGN, czy teŜ w sieci PSTN
lub PLMN, mając zapewnienie, Ŝe punkt dostępu do sieci dostawcy usługi, do której kierują
połączenia znajduje się w sieci Internet. Nie ma jednak gwarancji, Ŝe dostawca usługi w sieci
inicjującej połączenie, kierujący zapytanie do „infrastrukturalnego ENUM”, będzie w stanie
dostać się do wejściowego elementu w sieci dostawcy, do której kierowane jest połączenie.
Dlatego moŜe zachodzić konieczność dokonania dodatkowych uzgodnień dotyczących
określania toŜsamości (authentication) dla potrzeb peering’u i zaliczania połączeń.
10.6. Przenośność numeru w sieci GSTN
10.6.1. Informacje ogólne
Przenośność numeru została zestandaryzowana takŜe w dokumencie RFC 3482 [15]. Standard
ten opisuje przenośność numerów telefonicznych E.164 w sieci GSTN (Global Switched
Telephone Network), które mogą być numerami geograficznymi i niegeograficznymi.
Numery niegeograficzne nie odzwierciedlają lokalizacji, podczas gdy numery geograficzne
były z załoŜenia tworzone jako adresy hierarchicznego rutingu, które mogłyby być
sukcesywnie analizowane (cyfra po cyfrze) pod kątem numeru kraju, dostawcy sieci
obsługującej połączenie, końcowego switch’a obsługującego połączenie oraz oczywiście
numeru łącza abonenta Ŝądanego. W sieci bez moŜliwości przenoszenia numerów, abonent
zmieniający dostawcę usługi traci dotychczas uŜywany numer z tego powodu, Ŝe po takiej
zmianie jest obsługiwany przez inny switch końcowy naleŜący do innego dostawcy usługi.
Konieczność zrezygnowania z „wygody”, jaką jest moŜliwość korzystania zawsze z tego
samego numeru telefonicznego, były postrzegane jako bariera ograniczająca rozwój
konkurencji na rynku usług telekomunikacyjnych. Ta bariera nie występuje w sieciach GSTN,
59
których infrastruktura została lub zostanie adaptowana do potrzeb obsługi numerów
przeniesionych, zgodnie z regulacjami unijnymi zawartymi w dyrektywach.
Implementacja funkcji przenośności numeru w infrastrukturze krajowej sieci telefonicznej
potencjalnie, w sposób znaczący, zmienia zarządzanie numeracją, elementami sieci
sygnalizacyjnej, rutingiem, billingiem, zarządzanie usługami oraz innymi funkcjami. Przede
wszystkim jednak NP zmienia podstawową naturę wybranego numeru telefonicznego E.164 z
hierarchicznego adresu rutingowego na adres wirtualny. W implementacjach NP są
podejmowane próby realizacji NP transparentnie dla abonentów, przez wprowadzanie funkcji
translacyjnych do mapowania adresu E.164 (w odniesieniu zarówno do prefiksu, jak i
pozostałej części adresu E.164) na sieciowy adres rutingowy, który moŜe być uŜyty do
hierarchicznego kierowania. Jest to podejście trochę podobne do stosowanego do translacji
adresów sieciowych w sieci IP, które umoŜliwia przenośność adresu IP poprzez obejmowanie
zmianą adresu obszaru do brzegu sieci i pozostawieniu w uŜyciu bloków CIDR (Classless
Inter-Domain Routing) w sieci rdzeniowej, które mogą być zagregowane rutingowo przez
dostawcę usługi dla pozostałej części sieci Internet.
10.6.2. Procedury stosowane w przypadku przenośności usługowej
Standard RFC 3482 [15] podaje, Ŝe w przypadku przenośności usługowej mogą być
stosowane cztery procedury przenośności numery:
a) Onward Ruting (OR),
b) Call DropBack (CDB),
c) Query on Release (QoR),
d) All Call Query (ACQ).
Procedura OR jest realizowana w czterech podanych niŜej krokach:
-
Sieć inicjująca połączenie odbiera wywołanie od abonenta wywołującego i kieruje je
do sieci Dawcy.
-
Sieć Dawcy wykrywa, Ŝe wybrany numer katalogowy został przeniesiony poza obszar
obsługi switch’a Dawcy i wykonuje sprawdzenie w swojej wewnętrznej bazie danych
NPDB.
-
Wewnętrzna baza NPDB odsyła zwrotnie numer rutingowy stowarzyszony z
wybranym numerem katalogowym.
-
Sieć Dawcy wykorzystuje odebrany numer rutingowy do celów kierowania wywołania
do nowej sieci obsługującej połączenie.
Rysunek 10-3 przedstawia Schemat działania procedury OR.
60
Rysunek 10-3 Schemat działania procedury OR
Procedura CDB jest realizowana w pięciu podanych niŜej krokach:
-
Sieć inicjująca połączenie odbiera wywołanie od abonenta wywołującego i kieruje je
do sieci Dawcy.
-
Sieć Dawcy wykrywa, Ŝe wybrany numer katalogowy został przeniesiony poza obszar
obsługi switch’a Dawcy (donor switch) i wykonuje sprawdzenie (dokąd został
przeniesiony) w swojej wewnętrznej bazie danych NPDB (internal network-specific
NPDB).
-
Wewnętrzna baza NPDB odsyła zwrotnie numer rutingowy stowarzyszony z
wybranym numerem katalogowym.
-
Sieć Dawcy rozłącza połączenie po dostarczeniu tego numeru.
-
Sieć inicjująca wykorzystuje odebrany numer rutingowy do celów kierowania
wywołania do nowej sieci obsługującej połączenie.
Rysunek 10-4 przedstawia Schemat działania procedury CDB.
Rysunek 10-4 Schemat działania procedury CDB
Procedura QoR jest realizowana w pięciu podanych niŜej krokach:
-
Sieć inicjująca połączenie odbiera wywołanie od abonenta wywołującego i kieruje je
do sieci Dawcy (donor network).
61
-
Sieć Dawcy rozłącza zestawione połączenie i przesyła wskazanie, Ŝe wybrany numer
katalogowy został przeniesiony poza obszar obsługi tego switch’a.
-
Sieć inicjująca wysyła zapytanie do swojej kopii centralnie zarządzanej bazy danych
numerów przeniesionych NPDB.
-
Baza NPDB odsyła zwrotnie numer rutingowy stowarzyszony z wybranym numerem
katalogowym.
-
Sieć inicjująca wykorzystuje odebrany numer rutingowy do celów kierowania
wywołania do nowej sieci obsługującej połączenie.
Rysunek 10-5 przedstawia schemat działania procedury QoR.
Rysunek 10-5 Schemat działania procedury QoR
Procedura ACQ jest realizowana w trzech podanych niŜej krokach:
-
Sieć inicjująca połączenie (originating network) odbiera wywołanie od abonenta
wywołującego (caller) i wysyła zapytanie (query) do centralnie zarządzanej bazy
danych numerów przeniesionych NPDB (Number Portability Data Base), której kopia
rezyduje zwykle w tej sieci lub przekazuje to zapytanie za pośrednictwem dostawcy
tzw. trzeciej strony (third party provider).
-
Baza NPDB odsyła zwrotnie numer rutingowy stowarzyszony z wybranym numerem
katalogowym.
-
Sieć inicjująca wykorzystuje odebrany numer rutingowy do celów kierowania
wywołania do nowej sieci obsługującej połączenie (new serving network).
Rysunek 10-6 przedstawia schemat działania procedury ACQ.
62
Rysunek 10-6 Schemat działania procedury ACQ
10.6.3. Porównanie procedur przenośności usługowej
Tylko w przypadku procedury ACQ nie jest angaŜowana sieć Dawcy do kierowania
wywołania do nowej sieci obsługującej połączenie z wybranym numerem przeniesionym. W
przypadku pozostałych trzech procedur sieć Dawcy bierze udział w procesie zestawiania
połączenia lub w procesie sygnalizacji.
Procedura OR jest najmniej efektywna w zakresie wykorzystania zasobów transmisyjnych
sieci, poniewaŜ tylko w tej procedurze wymaga się zestawienia dwóch fizycznych segmentów
połączenia, jednego z sieci inicjującej do sieci Dawcy i drugiego z sieci Dawcy do nowej sieci
obsługującej połączenie. W przypadku procedur QoR i CDB najpierw jest zestawiane
połączenie do sieci Dawcy, potem rozłączane połączenie zwrotne do sieci inicjującej, po
czym jest inicjowane nowe połączenie do sieci aktualnie obsługującej połączenie. W czasie
zestawiania połączenia z sieci inicjującej do Dawcy (dla obu tych procedur) łącza między
siecią inicjującą i siecią dawcy są stale rezerwowane jedno za drugim. Te łącza są potem
uwalniane (takŜe jedno po drugim), kiedy połączenie jest rozłączane przez sieć Dawcy. W
przeciwieństwie do procedury OR, procedura ACQ jest najbardziej efektywna z punktu
widzenia wykorzystania zasobów komutacyjnych i transmisyjnych sieci dla zestawienia
połączenia.
Obie procedury ACQ i QoR angaŜują scentralizowaną bazę NPDB w celu pozyskania przez
sieć inicjującą połączenie informacji rutingowej. Określenie „scentralizowana baza NPDB”
oznacza, Ŝe taka baza zawiera informacje o przeniesionych numerach dla wielu róŜnych sieci.
Stanowi ona przeciwieństwo dla wewnętrznej bazy NPDB („internal network-specific
NPDB”) uŜywanej w realizacji procedur CDB i OR, która zawiera tylko informacje dotyczące
numerów przeniesionych z sieci dawcy. MoŜe ona takŜe moŜe rezydować w switch’u Dawcy
i zawierać wyłącznie informacje dotyczące numerów przeniesionych z tego switch’a.
Procedura ACQ ma dwie wersje. Jedna z nich pozwala sieci inicjującej połączenie zwrócić się
z zapytaniem do bazy NPDB zawsze, kiedy tylko odbierze wywołanie od abonenta
wywołującego, niezaleŜnie od tego, czy wybrany numer katalogowy naleŜy do zakresu
numerów, które podlegają przenoszeniu, oraz czy ta sieć ma przynajmniej jeden przeniesiony
numer. Druga wersja słuŜy do sprawdzenia, czy wybrany numer katalogowy naleŜy do
zakresu numerów, które podlegają przenoszeniu, oraz czy ta sieć ma przynajmniej jeden
przeniesiony numer. Jeśli tak, to jest wysyłane do bazy danych zapytanie, a jeśli nie to nie.
Pierwsza wersja działa lepiej, kiedy istnieje wiele zakresów numerów przenoszonych, a druga
odwrotnie, kiedy jest ich niewiele. Druga wersja jest podobna do procedury QoR, z
63
wyjątkiem tego, Ŝe QoR wymaga zestawienia połączenia w sieci Dawcy do przekazania
informacji o tym, Ŝe numer został przeniesiony zanim zostanie wysłane zapytanie do bazy
danych NPDB.
Dla konkretnego numeru telefonicznego, switch dawcy jest tym urządzeniem, w którym ten
numer został oryginalnie przydzielony spośród zakresu numerów przypisanego do tego
switch’a.
10.6.4. Interfejsy uŜywane między switch’em i bazą NPDB
W stanach Zjednoczonych i w Kanadzie dopuszcza się stosowanie pięciu podanych niŜej
rodzajów interfejsów dla potrzeb przekazywania zapytań do bazy danych NPDB:
a) Interfejs AIN (Advanced Intelligent Network) wykorzystujący protokół INAP
w wersji ANSI SS [43] i ANSI DB [44] zestandaryzowany przez ANSI
(American National Standard Institute). INAP stanowi protokół najwyŜszego
poziomu stosu protokołów, w którego skład wchodzą takŜe protokoły MTP,
SCCP i TCAP. Ten interfejs moŜe być uŜywany przez switch’e sieci
stacjonarnych i ruchomych i jest specyficzny dla implementacji NP w
Ameryce Północnej.
b) Interfejs IN (Intelligent Network) wykorzystujący protokół INAP, stanowiący
protokół najwyŜszego poziomu stosu protokołów, w którego skład wchodzą
takŜe protokoły MTP, SCCP i TCAP. Ten interfejs moŜe być uŜywany takŜe
przez switch’e sieci stacjonarnych i ruchomych.
c) Interfejs ANSI IS-41 zgodny ze standardem TIA/EIA IS-756 Rev. A,
„TIA/EIA -41-D Enhancements for Wireless Numer Portability Phase II”
(December 1998), „Numer Portability Network Support”; April 1998. Ten
interfejs moŜe być uŜywany przez systemy IS-41 działające na bazie sieci
komórkowych pracujących w paśmie 800 MHz oraz sieci świadczących usługi
PCS (Personal Communication Services), pracujących w paśmie 1900 MHz.
d) Interfejs GSM MAP (GSM Mobile Application Part) wykorzystujący protokół
MAP, stanowiący protokół najwyŜszego poziomu stosu protokołów, w którego
skład wchodzą takŜe protokoły MTP, SCCP i TCAP. Ten interfejs moŜe być
uŜywany przez sieci świadczące usługi PCS (Personal Communication
Services), pracujące w paśmie 1900 MHz na bazie technologii GSM.
e) Interfejs ISUP, przy uŜyciu którego translacje numerów związane z NP są
wykonywane transparentnie w sieci komutacyjnej w punktach STPs
(Signalling Transfer Points) lub w bramach sygnalizacyjnych (signalling
gateways). Sprawdzana jest zawartość wiadomości IAM, w celu określenia,
czy w polu CdPN została juŜ wykonana translacja numeru abonenta Ŝądanego.
Jeśli nie, to Ŝądanie jest obsługiwane w bazie NPDB i w wiadomości IAM są
modyfikowane odpowiednie parametry stosownie do wyniku wykonanej tu
translacji numeru. Zmodyfikowana wiadomość IAM jest kierowana przez
węzeł sygnalizacyjny do punktu DPC w celu kontynuowania procedury
zestawiania połączenia. Baza NPDB moŜe być zintegrowana z węzłem
sygnalizacyjnym lub dostępna poprzez lokalny interfejs API (Application
Programming Interface) albo za pośrednictwem zapytania skierowanego do
odległej bazy NPDB przy wykorzystaniu stosownych protokołów i opisanych
wyŜej procedur.
64
Zgodnie z dokumentem RFC 3482 [15] w Europie mogą być stosowane dwa podane niŜej
rodzaje interfejsów dla potrzeb przekazywania zapytań do bazy danych NPDB:
a) Interfejs IN CSI ( IN Capabitity Set 1) wykorzystujący protokół INAP w
wersji umoŜliwiającej realizację zestawu usług CS 1, zestandaryzowany przez
ITU i stanowiący protokół najwyŜszego poziomu stosu, w skład którego
wchodzą takŜe protokoły MTP, SCCP i TCAP.
b) Interfejs IN CS2 ( IN Capabitity Set 1) wykorzystujący protokół INAP w
wersji umoŜliwiającej realizację zestawu usług CS 2, stanowiący protokół
najwyŜszego poziomu stosu, w skład którego wchodzą takŜe protokoły MTP,
SCCP i TCAP.
Wprawdzie systemy komutacyjne w sieciach stacjonarnych krajów europejskich mogą być
wyposaŜone w interfejs CS 1 lub CS 2, ale w Europie jest wykorzystywany praktycznie tylko
interfejs CS 1. Ponadto w większości krajów europejskich przenośność numeru nie
przekracza granic sieci.
Centrale sieci ruchomych mogą uŜywać interfejsu CS 1 lub CS 2 do przekazywania zapytań
do baz NPDBs, w przypadku, gdy te bazy zawierają informacje o przeniesionych numerach
katalogowych sieci komórkowych. Określenie „przenośność numeru komórkowego” MNP
(„Mobile Numer Portability”) jest uŜywane w stosunku do przenośności operatorskiej w
europejskich sieciach GSM.
W Europie, w większości przypadków (a moŜe nawet zawsze) połączenia do numerów
katalogowych sieci ruchomych są kierowane najpierw do komórkowej sieci Dawcy i to
właśnie w niej, wewnętrzna baza NPDB jest zapytywana, czy dany numer katalogowy został
przeniesiony, czy nie.
W Europie przenośność MNP moŜe być realizowana takŜe za pomocą funkcji MNP-SRF
(MNP Signalling Relay Function). W tym przypadku zamiast wewnętrznej bazy NPDB jest
uŜywana baza zintegrowana z MNP-SRF do modyfikacji parametru „SCCP called party
address” w wiadomościach protokołu MAP, Ŝeby mogły być one przekierowane do sieci
komórkowej obsługującej połączenie (serving network).
10.7. Reprezentowanie „grupy łączy” we wskaźniku tel/sip URI
10.7.1. Informacje ogólne
Standard RFC 4904 [40] opisuje mechanizm przekazywania w protokole SIP parametru
„grupa łączy” (trunk group) zawartego we wskaźniku URI i podaje propozycje rozszerzenia
tego wskaźnika pod kątem przekazywania nowego parametru w sieci IP.
Ruting połączeń w sieci PSTN jest realizowany między centralami z komutacją kanałów
poprzez łącza międzycentralowe powszechnie nazywane „trunk’ami”. Grupa takich łączy,
poprzez które dana centrala jest połączona z inną centralą lub siecią nosi nazwę „grupy
łączy”. Grupa łączy jest rozróŜniana przez centrale uczestniczące w rutingu na podstawie
etykiety stanowiącej główny jej identyfikator.
Od czasu wprowadzenia traktów TCK 30 do komunikacji między centralami telefonicznymi,
powszechnie traktuje się grupę 30 łączy, jako najmniejszą grupę łączy czyli tzw. „trunk”.
Protokół SIP, zapewniający komunikację z bramą medialną PSTN (PSTN gateway), takŜe
moŜe być przekazywany po „trunk’ach” łączących tę bramę z sieciami róŜnych operatorów.
Dlatego dla serwera SIP Proxy waŜną sprawą jest moŜliwość określenia, od którego operatora
pochodzi połączenie, zwłaszcza, Ŝe wielu operatorów moŜe przekazywać połączenie do
65
danego numeru telefonicznego, a sam numer telefoniczny nie pozwala na skuteczną
identyfikację operatora w bramie medialnej. Dla wybrania w bramie właściwego operatora
pomocna jest dodatkowa informacja w postaci grupy łączy. Grupy łączy, łączące bramy
medialne, są uŜywane przez serwery Proxy do przekazywania do poszczególnych bram Ŝądań
zestawienia połączeń. Proxy wykorzystują w tym celu wiedzę o tym, która brama będzie
rutowała połączenie i które zasoby łączy są dołączone do danej bramy i kontrolują ten proces.
10.7.2. Wymagania związane z przekazywaniem informacji o grupie łączy
1. Parametry „grupa łączy” muszą być zdefiniowane jako rozszerzenie wskaźnika „tel”
URI.
2. Muszą być wprowadzone zabezpieczenia, aby nie było kolizji nazw „interdomenowych grup łączy”.
3. W wiadomościach SIP muszą być przenoszone informacje o grupie łączy inicjujących
(originating trunk group) i grupie łączy zakańczających (terminating trunk group).
4. Elementy intermediacyjne sieci SIP (serwery Proxy lub serwery „redirect”) powinny
móc dodawać atrybuty grupy łączy docelowych (destinating trunk group) do sesji SIP
po wybraniu drogi rutingu dla danego połączenia.
10.7.3. Przykładowa architektura odniesienia i przepływ wiadomości
Rysunek 10-7 przedstawia SIP Proxy w relacji rutingowej z trzema bramami PSTN (GW 1,
GW 2 i GW 3) znajdującymi się w jego domenie. śądanie dociera do SIP Proxy przez bramę
GW1, bramy GW2 i GW 3 są uŜywane jako bramy wyjścia z tej domeny. Brama GW2 ma
dwie grupy łączy, oznaczone jako TG2-1 i TG2-2 i brama GW3 ma teŜ dwie grupy łączy,
oznaczone jako TG3-1 i TG2-2 (ta grupa łączy została podzielona między bramy GW 2 i
GW 3).
Rysunek 10-7 Architektura odniesienia
Przedstawiony na rys. 10-8 przepływ wiadomości dotyczy architektury odniesienia podanej
na rys. 10-7. Zakłada się, Ŝe wszystkie bramy i serwer Proxy na tym rysunku naleŜą do tego
samego dostawcy usługi.
W wiadomości oznaczonej F1 (INVITE) brama GW1 odbiera z sieci PSTN Ŝądanie
zestawienia połączenia poprzez pewną grupę łączy. Brama GW1 przydziela dla tego
wywołania grupę łączy i umieszcza informację o niej w polu „contact header” Ŝądania
dostarczonego do serwera Proxy.
SIP Proxy przetwarza odebrany wskaźnik URI, dodaje do niego informację o grupie łączy
docelowych i wysyła nowy URI do bramy GW2 w wiadomości oznaczonej jako F2.
Wiadomość F3 (BYE) jest związana z rozłączeniem połączenia przez bramę GW2.
66
Rysunek 10-8 Przepływ wiadomości z informacją o grupie łączy
10.8. Wykorzystywanie systemu ENUM
świadczonych przy jego wsparciu
dla
efektywnego
rozwoju
usług
10.8.1. Informacje ogólne
Biorąc pod uwagę tempo rozwoju usług VoIP oraz sieci konwergentnych, zwłaszcza
budowanych na bazie systemu IMS, szybkość, łatwość i niezawodność administrowania
adresami IP i usługami systemu DNS staną się wkrótce czynnikami krytycznymi dla ich
dalszego rozwoju. Zdefiniowany w standardzie RFC 3761 [38] system ENUM jest tym
rozwiązaniem, które zaczyna być implementowane w systemie DNS dla wspierania róŜnych
rodzajów usług.
ENUM określa metodę zapamiętywania (storing) informacji w serwerach DNS do mapowania
numerów E.164 (numerów telefonicznych) na wskaźniki URI dla powiązanych z nimi usług
(np. VoIP). KaŜdy wskaźnik URI (dla terminala VoIP, telefonu komórkowego, poczty
elektronicznej, strony internetowej, serwera SIP Proxy itp.) jest pamiętany w rekordzie DNS
NAPTR (DNS Naming Authority Pointer), który jest w domenie E.164.
Jednym z przykładów zastosowań ENUM jest konwertowanie numeru telefonicznego
wybranego w sieci PSTN na adres IP terminala VoIP dołączonego do sieci IP (np. nazwą
domeny E.164 dla numeru (222) 333 4444 jest „4.4.4.4.3.3.3.2.2.2.e164.arpa” (zauwaŜmy, Ŝe
cyfry numeru telefonicznego w nazwie domeny E.164 są pisane w odwrotnej kolejności).
Np. firma Alcatel-Lucent dostarcza scentralizowany system zarządzania umoŜliwiający
administrowanie domenami ENUM i stowarzyszonymi z nimi rekordami NAPTR w
programie VitalQIP i serwerach DNS [45]. Część tego rozwiązania stanowi ENUM Manager,
stanowiący jeden z opcjonalnych modułów VitalQIP. Rozwiązanie to umoŜliwia kreowanie,
aktualizowanie i kasowanie rekordów NAPTR za pośrednictwem interfejsu SOAP. ENUM
Manager umoŜliwia takŜe zapamiętywanie tych rekordów w bazie danych ENUM, która jest
dzielona razem z VitalQIP. Program VitalQIP ma dostęp do tej bazy danych i uŜywa danych
w niej zawartych do uaktualniania serwerów DNS usytuowanych niŜej w hierarchii.
UŜytkownicy mogą administrować rekordami NAPTR za pośrednictwem interfejsu ENUM
Manager’s Web GUI.
Serwery DNS odpowiadają na kierowane do nich zapytania związane z translacją numeru
telefonicznego na wskaźnik URI w czasie obsługi wywołań zestawianych między sieciami,
zapewniając „partnerskim sieciom” tzw. peering.
67
10.8.2. Ogólna zasada działanie systemu ENUM
Zgodnie z definicją podaną w standardzie RFC 3403 [41], w rekordzie NAPTR wyróŜnia się
sześć pól danych zasobów: „order”, „flags”, „regular expresion”, „preference”, „service” i
„replacement”.
Konwersja numeru na nazwę domeny E.164 w systemie ENUM odbywa się w pięciu
podanych niŜej krokach:
-
klient ENUM odbiera numer abonenta Ŝądanego (np.1- 222-333-4444),
-
klient
ENUM
zamienia
4.4.4.4.3.3.3.2.2.2.e164.arpa,
-
klient uŜywa programu„resolver” do wysłania zapytania do serwera DNS
z nazwą domeny,
-
serwer DNS odsyła klientowi rekordy NAPTR w tej domenie,
-
w przypadku otrzymania wielu takich rekordów, klient wybiera tylko
jeden z nich bazując na zawartości pól: „order”, „preference” i „service”.
ten
numer
na
nazwę
domeny
Rysunek 10-9 przestawia zarys działania systemu ENUM.
Rysunek 10-9 Schemat działania systemu ENUM
10.8.3.
Działanie systemu ENUM w połączeniu między dwoma abonentami systemu
IMS
Rysunek 10-10 przedstawia działanie systemu ENUM w sytuacji zestawiania połączenia
między dwoma uŜytkownikami usługi VoIP świadczonej na bazie systemu IMS.
68
Rysunek 10-10 Obsługa połączenia VoIP systemie IMS między dwoma uŜytkownikami usługi VoIP z
uŜyciem ENUM
W tym przypadku są podejmowane podane niŜej działania w celu kierowania połączeń
między sieciami IP i zestawienia połączenia:
1. UŜytkownik A klienta SIP wybiera numer E.164 (np. 1-222-333-4444) w celu
osiągnięcia uŜytkownika B klienta SIP.
2. Jednostka S-CSCF (Serving-Call Session Control Function) komunikuje się z
serwerem aplikacyjnych w celu dostarczenia abonentowi usługi.
3. Jednostka S-CSCF wysyła do serwera DNS/ENUM zapytanie zawierające numer
E.164 i otrzymuje zwrotnie wskaźnik URI uŜytkownika B klienta SIP (np.
sip:[email protected]).
4. Jednostka S-CSCF wysyła do serwera DNS/ENUM ponownie zapytanie, aby
pozyskać adres IP hosta dla adresu „ims.acme.com”, który jest adresem jednostki ICSCF (Interrogating-CSCF). NaleŜy zauwaŜyć, Ŝe w większości sieci serwery DNS i
ENUM są przewaŜnie oddzielnymi serwerami (na rys. 10-10 zostały przedstawione
jako jeden serwer dla uproszczenia). Ponadto, (chociaŜ to nie zostało takŜe pokazane
na tym rysunku), wykonywane jest jeszcze jedno działanie, którym S-CSCF wysyła do
I-CSCF wiadomość „SIP Invite” i pyta (nie pokazany na rysunku) serwer domowy
69
abonenta (Home Subscriber Server) znajdujący się w sieci abonenta Ŝądnego o
jednostkę S-CSCF aktualnie obsługującą klienta B.
5. Jednostka S-CSCF (w sieci abonenta Ŝądanego) komunikuje się z serwerem
aplikacyjnych, Ŝeby dostarczył abonentowi usługę.
6. Zostaje zestawiona sesja między dwoma punktami końcowymi i przesyłany jest ruch
między nimi.
10.8.4.
Działanie systemu ENUM w połączeniu między abonentem systemu IMS i sieci
PSTN
Rysunek 10-11 przedstawia działanie systemu ENUM w sytuacji zestawiania połączenia
między uŜytkownikiem usługi VoIP świadczonej na bazie systemu IMS i abonentem sieci
PSTN.
Rysunek 10-11 Obsługa połączenia VoIP systemie IMS między uŜytkownikiem usługi VoIP i abonentem
PSTN z uŜyciem ENUM
10.8.5.
Architektura systemu ENUM DNS zapewniająca „peering” usług VoIP
pomiędzy sieciami IP
Rys. 10-12 przedstawia architekturę systemu ENUM DNS moŜliwą do zastosowania w
praktyce w celu zapewnienia bezpośredniej współpracy dwóch sieci IP (peering’u).
70
Rysunek 10-12 Przykład architektury ENUM DNS zapewniającej „peering” usług VoIP między sieciami
IP
71
DOKUMENTY ZWIĄZANE
[1] Ustawa Prawo Telekomunikacyjne z dnia 16 lipca 2004 r. z późn. zmianami
[2] Rozporządzenie Ministra Infrastruktury z dnia 9 stycznia 2008 r. w sprawie
szczegółowych wymagań dotyczących zasad adresowania dla właściwego
kierowania połączeń - Dz. U. Nr 14 poz. 84 z dnia 29 stycznia 2008 r.
[3] Rozporządzenie Ministra Infrastruktury z dnia 30 czerwca 2005 r. w sprawie
szczegółowych wymagań dotyczących gospodarowania numeracją w publicznych
sieciach telefonicznych (Dz. U. Nr 129, poz. 1082)
[4] Rozporządzenie Ministra Infrastruktury z dnia 11 września 2009 r. zmieniające
rozporządzenie w sprawie planu numeracji krajowej dla publicznych sieci
telefonicznych. Dziennik Ustaw Nr 153 poz. 1225
[5] Rozporządzenie Ministra Infrastruktury z dnia 17 czerwca 2009 r. w sprawie
warunków korzystania z uprawnień w publicznych sieciach telefonicznych - Dz. U.
Nr 97 poz. 810, 2009 r.
[6] Dyrektywa Parlamentu Europejskiego i Rady 2009/136/WE z dnia 25 listopada 2009
r. zmieniająca dyrektywę 2002/22/WE w sprawie usługi powszechnej i związanych z
sieciami i usługami łączności elektronicznej praw uŜytkowników, dyrektywę
2002/58/WE dotyczącą przetwarzania danych osobowych i ochrony prywatności w
sektorze łączności elektronicznej oraz rozporządzenie (WE) nr 2006/2004 w sprawie
współpracy między organami krajowymi odpowiedzialnymi za egzekwowanie
przepisów prawa w zakresie ochrony konsumentów LP9 002.21.81 Dziennik
Urzędowy Unii Europejskiej 18.12.2009
[7] Dyrektywa 2002/22/WE Parlamentu Europejskiego i Rady z dnia 7 marca 2002 r. w
sprawie usługi powszechnej i związanych z sieciami i usługami łączności
elektronicznej praw uŜytkowników (dyrektywa o usłudze powszechnej). Dziennik
Urzędowy Unii Europejskiej L 108, z 24.04.2002
[8] Przenośność numerów – stanowisko Prezesa URTiP, Warszawa maj 2004
[9] RFC 3966 - The tel URI for Telephone Numbers December 2004
[10] RFC 3372 - Session Initiation Protocol for Telephones (SIP-T) Context and
Architectures, 2002
[11] European Regulatory Group: ERG common position on VoIP, December 2007
[12] The treatment of Voice over Internet Protocol (VoIP) under the EU Regulatory
Framework, Bruksela, 14 June 2004
[13] ERG Common Statement for VoIP regulatory approaches, ERG (05) 12
[14] OFCOM "Regulation of VoIP Services, Statement and further consultation"
February 2006
[15] RFC 3482: Number portability in the Global Switched Telephone Network (GSTN);
An overview; February 2003
[16] RFC 4694: Number Portability Parameters for the “tel” URI; October 2006
[17] RFC 2916: E.164 number and DNS; September 2000
[18] RFC 2915: The Naming Authority Pointer (NAPTR) DNS Resource Record;
September 2000
[19] RFC 2396: Uniform Resource Identifier (URI), Generic syntax; August 1998
[20] RFC 4769: IANA Registration for an Enumservice Containing Public Switched
Telephobne Network (PSTN) Signalling Information; November 2006
72
[21] RFC 3261: SIP: Session Initiation Protocol; June 2002
[22] ITU-T Q.Supplement 5: Number portability – Capability set 2 requirements for
service provider portability (Query on release and Dropback); 03/99
[23] Raport ERG (09) 19: VoIP – Action Plan to achieve conformity with ERG common
position, June 2009
[24] Raport ERG (07) 56rev2: ERG common position on VoIP, December 2007
[25] Raport ERG (06) 39: VoIP and consumer issues, 2006; (The report was prepared by
the END User Working Group)
[26] Raport ERG (05) 12: ERG common statement for VoIP regulatory approachs, 2005
[27] ECC Recommendation (05)03: Numbering for nomadic voice over IP services;
Recommendation adopted by the Working Group Numbering Naming abd
Addressing (WG NNA)
[28] ECC Report 59: Numbering for VoIP services; Oxfort, December 2004
[29] Offcom Office of Telecommunicatins: Regulation of VoIP services; Statement and
further consultation; February 2006
[30] Mario Ivcek: Research & Development Centre; Ericsson Nicola Tesla d.d.: ENUM
based Number Portavbility in VoIP and IMS Networks
[31] Comments of WIND Hellas Telecommunications S.A. to “ERG common position on
VoIP” (draft) ERG (07) 56 Rev 1
[32] Federal Communications Commission: FCC expands local number portability to
VoIp; October 2007
[33] Draft ECC Report 155: Number portability procedures - Vilnius June 2010
[34] RFC 2806: URLs for Telephone Calls; April 2000
[35] RFC 3245: The History and Context of Telephone Number Mapping (ENUM)
Operational Decisions: Informational Documents Contributed to ITU-T Study Group
2 (SG2); March 2002
[36] RFC 5526: The E.164 to Uniform Identifiers (URI) Dynamic Delegation Discovery
System (DDDS) Application for Infrastructure ENUM; April 2009
[37] RFC 5341: The Internet Assigned Number Authority (IANA) tel Uniform Resource
Identifier (URI) Parameter Registry; September 2008
[38] RFC 3761: The E.164 to Uniform Resource Identifiers (URI) Dynamic Delegation
Discovery System (DDDS) Application (ENUM); April 2004
[39] RFC 5067: „Infrastructure ENUM Requirements”; November 2007
[40] RFC 4904: Representing Trunk Grups in tel/sip Uniform Resource Identifiers
(URIs); June 2007
[41] RFC 3403: Dynanic Delegation Discovery System (DDDS) Part Three: The Domain
Name System (DDS) Database; October 2002
[42] ITU-T: “The International Public Telecommunication Number Plan”;
Recommendation E.164; February 2005
[43] ANSI Technical Requirements No.2: Number portability – Switching Systems; April
1999
[44] ANSI Technical Requirements No.3: “Number portability – Database and Global
Title Translation”; April 1999
[45] Technology White Paper: ENUM Use and Management for the Successful
Deployment of ENUM-Enabled Services; Alcatel-Lucent
73
[46] RFC 2234: Augmented BNF for Syntax Specifications ABNF, November 1997
[47] ITU-T E.123: “Notation for national and international telephone numbers, e-mail
addresses and web addresses”; February 2001
[48] RFC 4234: Augmented BNF for Syntax Specifications ABNF, October 2005
74
UŜywane skróty
ASP
Application Service Provider
Dostawca aplikacji usługowych
BCP
Best Curent Practice
Najlepsza bieŜąca praktyka
BGP
Border Gateway Protocol
Protokół Bramy Brzegowej
CAP
Common Alerting Protocol
Wspólny Protokół Alarmowania
CdPN
Called Party Number
Numer abonenta Ŝądanego
CEN
European Committee for Standardisation
Europejski Komitet Normalizacyjny
CENELEC
European Committee for Electrotechnical Standardisation
Europejski Komitet Normalizacyjny Elektrotechniki
CEPT
European Conference of Post and Telecommunications
Europejska Konferencja Poczty i Telekomunikacji
CLI
Calling Line Identification
Identyfikacja łącza abonenta wywołującego
CSN
Circiut Switched Network
Sieć z komutacją kanałów
DDN
Dialled Directory Number
Wybrany numer spisu abonentów
DHCP
Dynamic Host Configuration Protocol
Protokół dynamicznej konfiguracji hosta
DNS
Domain Name System
System nazw domenowych
DoS
Denial of Service
Odmowa usługi (przy ataku DoS)
DSCP
Differentiated Service Code Point
Punkt róŜnicowania kodowania usługi
DSS1
Digital Subscriber Signalling No1
Protokół sygnalizacji w cyfrowym łączu abonenckim
75
E.164
ITU-T Recommendation – The international public telecommunication
numbering plan
Międzynarodowy plan numeracji w publicznych sieciach
telekomunikacyjnych
E2U
E.164 to URI
Translacja numerów E.164 na wskaźniki URI
ECC
Electronic Communications Committee (of the CEPT)
Komitet Komunikacji Elektronicznej (działający w ramach CEPT)
ECRIT
Emergency Context Resolution with Internet Technologies
Grupa Robocza d/s rozwiązań łączności alarmowej w technologiach
internetowych
ECS
Electronic Communication Services
Usługi Komunikacji Elektronicznej
ENS
Electronic Numbering System
Elektroniczny System Numerowania (Funkcjonalność współdziałania
systemu DNS z mechanizmami adresowania sieci telefonicznych)
ENUM
Telephony Numbering Mapping
Mapowanie Numerów Telefonicznych (Funkcjonalność powiązania
adresów E.164 z systemem adresacji DNS)
ERG
European Regulator’s Group
Europejska Grupa Regulatorów
ETNS
European Telephony Numbering Space
Europejska Przestrzeń Numerowa
ETSI
European Telecommunications Standard Institute
Europejski Instytut Norm Telekomunikacyjnych
FCC
Federal Communications Commission
Federalna Komisja Telekomunikacji
GC
General Conditions
Ogólne warunki świadczenia usług w sieci brytyjskiej
GSM
Global System for Mobile communications
System globalnej łączności komórkowej
H.323
H.323 Protocol
Protokół sygnalizacyjny H.323
HTTP
Hypertext Transfer Protocol
Protokół Przesyłania Dokumentów Hipertekstowych
76
IANA
Internet Assigned Numbers Authority
Organizacja Zarządzania Domenami IP
ICT
Information and Communications Technology
Technologie Informacyjne i Komunikacyjne
IEEE
Institute of Electrical and Electronic Engineering
Instytut InŜynierii Elektryki i Elektroniki
IEPS
Internet Emergency Preparedness Sevice
IETF
Internet Engineering Task Force
Grupa Realizacji InŜynierii Internetowej (w ramach IEEE)
IM
Instant Messaging
Komunikacja Natychmiastowa
IMS
IP Multimedia Subsystem
IN
Intelligent Network
Sieć inteligentna
IP
Internet Protocol
Protokół internetowy
IP-VPN
IP Virtual Private Network
Wirtualna sieć abonencka IP
ISDN
Integrated Services Digital Network
Sieć telefoniczna z integracją usług
ISP
Internet Service Provider
Dostawca usług internetowych
ISUP
Integrated Services User Part
Część ISDN protokołu SS7
ITU
International Telecommunications Union
Międzynarodowy Związek Telekomunikacyjny
LAN
Local Area Network
Lokalna sieć komputerowa
LLU
Local Loop Unbundling
Uwolnienie pętli abonenckiej
LNP
Location Numer Portability
Przenośność Lokalizacyjna
LSP
Label Switched Path
Etykieta ŚcieŜki Połaczenia
77
MIP
Mobile Internet Protocol
Protokół Internetowy słuŜący do obsługi mobilności uŜytkownika
MNP
Mobile Numer Portability
Przenośność numerów w sieciach ruchomych
MPLS
Multi-Protocol Label Switching
Wieloprotokołowe Przełaczanie Etykiet
MSI
International Mobile Subscriber Number
Międzynarodowy numer abonenta ruchomego
NAPTR
Naming Authority Pointer
Typ Rekordu Zasobów DNS
NGN
Next Generation Network
Sieć nowej generacji
NNI
Network-Network Interface
Interfejs sieć-sieć
NP
Number Portability
Przenośność numeru
NR
Ruting Number
Numer rutingowy
NPDB
Number Portability Database
Baza Numerów Przeniesionych
NRA
National Regulatory Authority (or Agency)
Krajowy Regulator Telekomunikacyjny
NVS
New Voice Services
Nazwa uŜywana przez Ofcom w czasie konsultacji dotyczących nowych
usług
PABX
Private Automatic Branch Exchange
Automatyczna centrala abonencka
PATS
Public Available Telephone Service
Usługa telefoniczna dostępna w sieci uŜytku publicznego
PDA
Personal Data Assistant
Personalne urządzenie transmisji danych
PNK-TF
Plan numeracji krajowej sieci telefonicznej
PLMN
Public Land Mobile Network
Ruchoma sieć uŜytku publicznego
78
POTS
Plain Old Telephony Service
Usługi świadczone abonentom analogowym
PSTN
Public Switched Telephone Network
Stacjonarna sieć telefoniczna uŜytku publicznego
Pt
Prawo telekomunikacyjne
RFC
Request for Comments
Standardy organizacji IETF
RN
Routing Number
Numer rutingowy
SIM
Subscriber Identity Module
Moduł Identyfikacyjny Abonenta
SIP
Session Initiation Protocol
Protokół Rozpoczęcia Sesji
SMTP
Simple Mail Transfer Protocol
Protokół Komunikacyjny Poczty Elektronicznej
SS7
Signalling System No 7
System sygnalizacji Nr 7
TCP/IP
Transmission Control Protocol/Internet Protocol
Protokół Sterowania Transmisją/Protokołu Internetowego
TDM
Time Division Multiplexing
Technologia zwielokrotnienia czasowego
TRIP
Telephony Routing over IP
Protokół rutingu w sieci IP
TUP
Telephone User Part
Protokół warstwy 4 sieci ISDN
UA
User Agent
Agent UŜytkownika
UDP
User Datagram Protocol
Protokół datagramowy uŜytkownika
UE
User Equipment
WyposaŜenie UŜytkownika
UNI
User-Network Interface
Interfejs UŜytkownik Sieć
URI
Uniform Resorce Identifier
Ujednolicony Wskaźnik Zasobów
79
URN
Uniform Resorce Name
Ujednolicony Format Nazw Zasobów
USD
Universal Service Directive
Dyrektywa Usługi Powszechnej
VoIP
Voice over IP
Technologia transmisji głosu w sieci IP
VPN
Virtual Private Network
Wirtualna sieć prywatna
VSP
Voice Service Provider
Dostawca usługi głosowej
WAN
Wide Area Network
Rozległa sieć transmisji danych
WWW
World Wide Web
Sieć Internetowa www
XML
Extensible Markup Language
Rozszerzony język formalny strukturalnych danych
80