Javna rasprava - Odluka i Dokument o uvjetima IP međupovezivanja

KLASA:UP/I-344-01/15-03/04                                   PRIJEDLOG ZA JAVNU RASPRAVU

URBROJ: 376-11-16-10

Zagreb, 14. prosinca 2016.

Na temelju članka 12. i članka 58. stavka 3. Zakona o elektroničkim komunikacijama (NN br. 73/08, 90/11, 133/12, 80/13 i 71/14), u postupku pokrenutom po službenoj dužnosti radi izmjena standardne i minimalnih ponuda, Vijeće Hrvatske regulatorne agencije za mrežne djelatnosti na sjednici održanoj 14. prosinca 2016. donosi

ODLUKU

I. Hrvatski Telekom d.d., Zagreb, Roberta Frangeša Mihanovića 9, obvezan je, u roku od 15 dana od dana donošenja ove odluke u Standardnu ponudu Hrvatskog Telekoma d.d. za usluge međupovezivanja u nepokretnoj mreži ugraditi dokument „Uvjeti IP međupovezivanja“, a koji je u cijelosti sastavni dio ove odluke.

II. Trgovačka društva:

•       BT Net d.o.o., Zagreb, Dubravkin trg 5;

•       Fenice telekom grupa d.o.o., Rijeka, Gornja Vežica 16/a;

•       H1 Telekom d.d.,¸ Split, Put Trščenice 10;

•       Iskon Internet d.d., Zagreb, Garićgradska 18;

•       Magić Net d.o.o., Ludbreg, Koprivnička 17/c;

•       Metronet d.o.o., Zagreb, Ulica grada Vukovara 269d;

•       Metronet telekomunikacije d.d. Zagreb, Ulica grada Vukovara 269d;

•       Net-connect d.o.o. Zagreb, Petrovaradinska 1;

•       Novi-Net d.o.o., Selnica, Merhatovec 5;

•       Omonia d.o.o., Zagreb, Sisačka cesta 20/a;

•       Optika kabel TV d.o.o., Zaprešić, Drage Švajcera 1;

•       Orinoco d.o.o., Zagreb, Hebrangova 38;

•       OT-Optima Telekom d.d., Zagreb, Bani 75/a;

•       Skvid d.o.o., Zagreb, Jalševečka cesta 40;

•       Softnet d.o.o., Zagreb, Cebini 37/2;

•       Terrakom d.o.o., Zagreb, Radnička cesta 48/1;

•       VIPnet d.o.o., Zagreb, Vrtni put 1;

obvezna su, u roku od 15 dana od dana donošenja ove odluke, u minimalne ponude ugraditi dokument „Uvjeti IP međupovezivanja“, a koji je u cijelosti sastavni dio ove odluke.

Obrazloženje

Odlukama od 30. ožujka 2015. (KLASA: UP/I-344-01/14-03/13, URBROJ: 376-11-15-11, KLASA: UP/I-344-01/14-03/14, URBROJ: 376-11-15-12) određeni su operatori sa značajnom tržišnom snagom na tržištu započinjanja poziva iz javnih komunikacijskih mreža koje se pruža na fiksnoj lokaciji te tržištu veleprodajnog završavanja poziva u vlastitoj javnoj telefonskoj mreži koja se pruža na fiksnoj lokaciji (dalje: Analize). Na temelju provedenih Analiza društvima iz točke I. i II. izreke ove odluke Hrvatska regulatorna agencija za mrežne djelatnosti (dalje: HAKOM) je odredila regulatornu obvezu transparentnosti uz obvezu objave standardne ponude međupovezivanja odnosno objave minimalne ponude uvjeta međupovezivanja, a po donošenju odluke kojom će se definirati uvjeti IP međupovezivanja i obvezu da iste ugrade u svoje standardne/minimalne ponude.

Navedenim određenjem HAKOM je želio osigurati ispunjavanje obveza iz članka 5. stavka 5. točke 2. Zakona o elektroničkim komunikacijama (dalje: ZEK) prema kojoj HAKOM pridonosi razvoju unutarnjeg tržišta Europske unije, između ostalog, i poticanjem uspostave i razvoja transeuropskih mreža te međusobnog djelovanja (interoperabilnosti) sveeuropskih usluga i povezanosti između krajnjih korisnika usluga. Naime, niti s ekonomske, a niti s tehnološke strane, nije opravdano da svaki operator zasebno implementira svoje protokole za IP-IP međupovezivanje, jer u tom slučaju ne bi bila osigurana interoperabilnost između usluga i povezanosti krajnjih korisnika usluga različitih operatora na tržištu.

HAKOM je stoga u svrhu osiguranja interoperabilnosti krajem 2014. organizirao radionice na temu IP međupovezivanja čiji je cilj bio usuglašavanje uvjeta IP međupovezivanja između operatora i HAKOM-a. Na temelju zaključaka s održanih radionica, HAKOM je izradio dokument o „Uvjetima IP međupovezivanja“ (dalje: Dokument) kojim su se definirali SIP/SDP standardi koji se u svrhu IP međupovezivanja za javnu govornu uslugu, kao i s njom povezane usluge, koriste između operatora u Republici Hrvatskoj.

S obzirom da je Odlukom (KLASA: UP/I-344-01/15-03/04, URBROJ: 376-11-15-09, od 28. svibnja 2015.) privitak koje je Dokument, predviđeno da će se isti ažurirati po potrebi kako bi odražavao stvarno stanje, HAKOM je u rujnu 2016., u svrhu ažuriranja postojećeg dokumenta o IP međupovezivanju ponovno pokrenuo radionice o IP međupovezivanju.

Na dvije održane radionice, u rujnu i studenom 2016. operatori su usuglasili otvorena tehnička pitanja koja su ugrađena u najnoviju verziju dokumenta o IP međupovezivanju iz privitka ove Odluke.

Kako su uvjeti IP međupovezivanja prethodno usuglašeni između operatora i HAKOM-a, HAKOM je odredio rok od 15 (petnaest) dana u okviru kojeg su trgovačka društva iz točke 1. i 2. izreke ove odluke u svoje standardne/minimalne ponude obvezna ugraditi uvjete iz Dokumenta.

O prijedlogu Odluke HAKOM je proveo javnu raspravu od 14. prosinca 2016. do 9. siječnja 2017.

Slijedom svega navedenoga, HAKOM je temeljem članka 58. stavka 3. ZEK-a odlučio kao u izreci.

UPUTA O PRAVNOM LIJEKU:

Protiv ove odluke nije dopuštena žalba, ali se može pokrenuti upravni spor pred Visokim upravnim sudom Republike Hrvatske u roku od 30 dana od primitka odluke.

Dostaviti:

1. BT Net d.o.o., Zagreb, Dubravkin trg 5- osobna dostava

2. Fenice telekom grupa d.o.o., Rijeka, Gornja Vežica 16/a – UP-osobna dostava i faksom na broj: 051/770 005

3. Hrvatski Telekom d.d., Roberta Frangeša Mihanovića 9, Zagreb - osobnom dostavom

4. H1 Telekom d.d.,¸ Split, Put Trščenice 10- UP-osobna dostava i faksom na broj: 021/ 555 019

5. Iskon Internet d.d., Zagreb, Garićgradska 18- osobna dostava

6. Magić Net d.o.o., Ludbreg, Koprivnička 17/c - UP-osobna dostava i faksom na broj: 042/ 420 429

7. Metronet d.o.o., Zagreb, Ulica grada Vukovara 269d - osobna dostava

8. Metronet telekomunikacije d.d. Zagreb, Ulica grada Vukovara 269d - osobna dostava

9. Net-connect d.o.o. Zagreb, Petrovaradinska 1- osobna dostava

10. Novi-Net d.o.o., Selnica, Merhatovec 5 - UP-osobna dostava i faksom na broj: 040/ 500 010

11. Omonia d.o.o., Zagreb, Sisačka cesta 20/a - osobna dostava

12. Optika kabel TV d.o.o., Zaprešić, Drage Švajcera 1- UP-osobna dostava i faksom na broj: 01/ 339 2979

13. Orinoco d.o.o., Zagreb, Hebrangova 38- osobna dostava

14. OT-Optima Telekom d.d., Zagreb, Bani 75/a-  osobna dostava

15. Skvid d.o.o., Zagreb, Jalševečka cesta 40-  osobna dostava

16. Softnet d.o.o., Zagreb, Cebini 37/2 - osobna dostava

17. Terrakom d.o.o., Zagreb, Radnička cesta 48/1- osobna dostava

18. VIPnet d.o.o., Zagreb, Vrtni put 1 - osobna dostava

19. U spis

UVJETI IP MEĐUPOVEZIVANJA Verzija 1.1	2016
Hrvatska regulatorna agencija za mrežne djelatnosti

Sadržaj

1. KONTEKST

1.1. Svrha dokumenta

1.1.1. Osnovne usluge/Upravljanje pozivom

1.1.2. Dodatne usluge

1.2. Standardi i protokoli

2. REFERENTNI DOKUMENTI

3. KRATICE

4. SIP SIGNALIZACIJSKE PORUKE

4.1. Definicije

4.2. Transportni protokol

4.3. SIP metode i headeri

4.3.1. SIP metode

4.3.2. Ponašanje mreže u prijemu

4.3.3. Ponašanje mreže u odašiljanju (Network behaviour in emission)

4.3.4. Inicijalna INVITE metoda (Initial INVITE method)

4.3.5. Re-INVITE zahtjev

4.3.6. CANCEL metoda

4.3.7. ACK metoda

4.3.8. BYE metoda

4.3.9. OPTIONS metode

4.4. Kompaktna forma SIP zaglavlja (headera) (SIP headers compact form)

4.5. Maksimalna duljina poruke (Maximum message size)

5. TIJELA PORUKE (MESSAGE BODIES)

6. PODRŽANE OZNAKE MOGUĆNOSTI SIP EKSTENZIJA (SUPPORTED OPTION TAGS OF SIP EXTENSIONS)

7. FORMAT IDENTIFIKACIJE, PARAMETRI ADRESE I SIGNALIZACIJSKI MOD (IDENTITIES FORMAT, ADDRESS PARAMETERS AND SIGNALLING MODE)

8. UPRAVLJANJE MEDIJSKOM SESIJOM (MEDIA SESSION MANAGEMENT)

8.1. Uspostava medijske sesije (Media session establishment)

8.1.1. Inicijalna INVITE poruka (Initial INVITE message)

8.1.2. Pravila dogovora o kodecima (Codec negotiation rules)

8.1.3. Slanje medije prije uspostave poziva (Early media)

8.2. Modifikacija medijske sesije (Media session modification)

8.3. Završavanje sesije (Terminating a session)

8.4. RTP/RTCP paketski izvori (RTP/RTCP packet source)

9. KODECI ZA GOVOR

10. OSTALI KODECI I PROCEDURE

11. „KEEP ALIVE“ MEHANIZMI

11.1. „Keep alive“ mehanizam za aktivne SIP sesije (sessions)

11.2. „Keep alive“ mehanizam za provjeru statusa SIP signalnih linkova

12. DOMENE

13. USMJERAVANJE I OSTVARIVANJE VISOKE RASPOLOŽIVOSTI

14. OBRAČUN PROMETA

15. TESTIRANJE

16. QOS

17. VODOVI U SVRHU IP MEĐUPOVEZIVANJA

18. ARHITEKTURA POVEZIVANJA

18.1. Povezivanje dva operatora s po jednim SBC-om

18.2. Povezivanje operatora s jednim SBC-om i operatora s dva SBC-a

18.3. Povezivanje dva operatora s po dva SBC-a

19. POVEZIVANJE PUTEM JAVNOG INTERNETA

20. AŽURIRANJE DOKUMENTA O UVJETIMA IP MEĐUPOVEZIVANJA

PRIVITAK

1. KONTEKST

1.1. Svrha dokumenta

Svrha ovoga dokumenta je odabrati SIP/SDP standarde koji će se koristiti u svrhu IP međupovezivanja između operatora u Republici Hrvatskoj za javnu govornu uslugu, kao i s njom povezane usluge. Ovaj dokument definira i ostale bitne uvjete IP međupovezivanja. Uvjete IP međupovezivanja operatori elektroničkih komunikacija moraju ugraditi u svoje standardne/minimalne ponude međupovezivanja.

Ovaj dokument podržava sljedeće osnovne usluge:

1.1.1. Osnovne usluge/Upravljanje pozivom

Podržane su sljedeće osnovne usluge:

-         Uspostava poziva

-         Održavanje poziva

-         Raskidanje poziva

-         Podrška za slanje faksa

-         Podrška za modemsku dial-up podatkovnu vezu (alarm, POS i sl.)

-         Podrška za ISDN clear channel podatkovnu vezu

-         Podrška za prijenos DTMF tonova

-         Tranzitiranje poziva

1.1.2. Dodatne usluge

Uz osnovne usluge, podržane su i sljedeće dodatne usluge:

-         CLIP (Calling Line Identification Presentation)

-         CLIR (Calling Line Identification Restriction)

-         CNIP (Calling Name Identification Presentation)

-         CNIR (Calling Name Identification Restriction)

-         CONP (Connected Name Identification Presentation)

-         COLP (Connected Line Identification Presentation)

-         CLIPRO (Callling Line Presentation Restriction Override)

-         Call hold

-         Call waiting

-         3-way conference

-         Call Transfer (Call Divert)

-         Call Forwarding:

◦ Unconditional

◦ No Answer

◦ Busy

◦ Unavailable

-         ACR (Anonymous Call Restriction)

1.2. Standardi i protokoli

U pravilu, IP međupovezivanje pokretnih mreža u RH će se voditi načelima propisanim odgovarajućim 3GPP specifikacijama. Isto tako, međupovezivanje nepokretnih mreža u RH će se voditi načelima propisanim odgovarajućim TISPAN/3GPP normama/specifikacijama.

ETSI/3GPP:

-          TS 123 228

-          TS 124 229

-          TS 129 165

Za nepokretne mreže koristit će se SIP protokol, dok se za spajanje mreže pokretnih komunikacija može koristiti i SIP-I protokol.

Korištenje SIP-I protokola će se dogovarati na bilateralnoj razini između operatora pokretnih komunikacije do trenutka trajnog prelaska na SIP.

2. REFERENTNI DOKUMENTI

3. KRATICE

CLIPCalling Line Identity Presentation

CLIRCalling Line Identity Restriction

DTMFDual-Tone Multi-Frequency

M2MMachine To Machine

MIMEMultipurpose Internet Mail Extensions

NNINetwork To Network Interface

SIPSession Initiation Protocol

SDPSession Description Protocol

TCPTransport Control Protocol

UDPUser Datagram Protocol

URIUniform Resource Identifier

4. SIP SIGNALIZACIJSKE PORUKE

SIP poruke (messages) i zaglavlja (headeri) specificirani u ovom poglavlju moraju se enkodirati, popunjavati i dalje predavati (encoded, filled and handled) kao što je specificirano referentnim normama odnosno specifikacijama kojima su isti definirani, a koje su navedene u poglavlju 2.

Request-URI u svim SIP zahtjevima moraju se kodirati i popunjavati sukladno [RFC3261] i kao što je opisano u poglavlju 8.1.1. Inicijalna INVITE poruka (Initial INVITE message) .

4.1. Definicije

Smjerovi „prijam“ (reception) i „odašiljanje“ (transmission) odnose se na smjer poruke.

U prijemnom smjeru (reception direction):

-          „Supported“ (podržan) znači da zaglavlje (header) može biti prisutno i ako je primljeno (recevied), s istim se mora postupati sukladno primjenjivim normama.

-          „Mandatory“ (obvezno) znači da primatelj očekuje da zaglavlje (header) bude prisutno.

-          „Not applicable“ (nije primjenjivo) znači da se prijam zaglavlja (headera) prema sadašnjim specifikacijama ne može dogoditi. Po načelu simetrije, „Not applicable“ (nije primjenjivo) se odnosi samo na zaglavlja (headere) sa statusom „not sent“ u emisiji.

U smjeru odašiljanja (transmission direction):

-          „May be sent“ (može biti poslan) znači da zaglavlje (header) može biti prisutno ili izostavljeno ovisno o transakciji (transaction) ili kontekstu poziva.

-          „Mandatory“ (obvezno) znači da je zaglavlje (header) uvijek prisutno.

-          „Not sent“ znači da zaglavlje (header) neće biti poslano.

4.2. Transportni protokol

Preferirani protokol za nepokretne mreže su UDP i TCP, a za mreže pokretnih komunikacija osim ovih bit će podržan i SCTP protokol. Vidjeti maksimalnu duljinu poruke u odlomku 4.5.

4.3. SIP metode i headeri

Operatori moraju u svojim standardnim/minimalnim ponudama navesti podržana zaglavlja (headere) i metode koje su u skladu s ovim dokumentom. U slučaju da netko od operatora podržava dodatne metode i zaglavlja, iste je dužan navesti u svoju standardnu/minimalnu ponudu.

4.3.1. SIP metode

Tablica 1 sadrži SIP metode koje su potrebne kako bi se podržale mogućnosti i usluge opisane u odjeljku 1.1.

Tablica 1: Obvezne SIP metode

Obvezno je podržati OPTIONS jedino u prijamnom smjeru.

4.3.2. Ponašanje mreže u prijemu

4.3.2.1 Provjera metode

Ako je SIP metoda koja je primljena prepoznata, ali ne i podržana, bit će odbijena kako je definirano RFC 3261 s odgovorom 405 „Method not allowed“.

Ako SIP metoda koja je primljena nije prepoznata (npr. nije implementirana), bit će odbijena kako je definirano RFC 3261 s odgovorom 501 „Not implemented“.

4.3.2.2 Provjera statusnog koda

Ako je primljena poruka o grešci koja nije podržana“ (non-suported error response) u SIP poruci onda odgovarajući poziv ili transakcija propada (fail). Popis podržanih i neprimjenjivih odgovora s detaljnim uputama za njihovo rukovanje je dan i odjeljku 4.3. Tablice 3.

Ako je u SIP poruci primljen odgovor koji nije prepoznat (non – recognized final response), tj. koji nije naveden u odjeljku 4.3. Tablice 3, s njim će se postupati kao da je ekvivalentan x00 kodu odgovara tog razreda. Ako je u SIP poruci primljen odgovor za vrijeme uspostave poziva (provisional response) koji nije prepoznat a različit je od 100 zadnjeg odgovora, tj. nije naveden u odjeljku 4.3. Tablice 3, s njim će se postupati kao da je ekvivalentan s 183 „session progress“.

4.3.2.3 Provjera zaglavlja (headera) u zahtjevima (Header inspection in requests)

Ako se u SIP zahtjevu (request) primi nepodržano SIP zaglavlje (header), bit će ignorirano (ignored) osim ako je njegova odgovarajuća oznaka (option tag) prisutna u zaglavlju „Zahtijevano“ (Required). Zaglavlja (Headeri) ili parametri koji nisu navedeni u tablicama od odjeljka 4.3.4 do odjeljka 4.3.9 se smatraju neprimjenjivim zaglavljima (not-applicable headers) ili parametrima.

Ako obvezno zaglavlje (header) nije prisutno u zahtjevu ili je deformirano (malformed), zahtjev će biti odbijen (rejected) kako je definirano RFC 3261.

4.3.2.4 Provjera zaglavlja (headera) u odgovorima (Header inspection in responses)

Ako se u SIP odgovoru (response) primi nepodržano SIP zaglavlje (header), bit će ignorirano (ignored). Zaglavlja (Headeri) ili parametri koji nisu navedeni u tablicama od odjeljka 4.3.4 do odjeljka 4.3.9 se smatraju nepodržanim zaglavljima (non-suported headers) ili parametrima.

Ako zaglavlje (header) koje je nužno za obradu odgovora nije prisutno ili je deformirano (malformed) u odgovoru za vrijeme uspostave poziva (provisional response), odgovor (response) će biti odbačen/ignoriran „(discarded)“.

Ako zaglavlje (header) koje je nužno za obradu odgovora (response) nije prisutno ili je deformirano (malformed) u konačnom odgovoru (response) izuzev 2XX odgovora, odgovor (reponse) će se tretirati kao odgovor (response) 500 „ Server Internal Error“.

Ako zaglavlje (header) koje je nužno za obradu odgovora (response) nije prisutno ili je deformirano (malformed) u konačnom 2XX odgovoru (response) na INVITE zahtjev (request), odgovor (response) će biti prihvaćen („acknowledged“) slanjem ACK poruke i nakon toga će dijalog biti završen (terminated) slanjem poruke BYE.

Ponašanje u slučaju primanja SIP odgovora (response) koji je označen kao „Not applicable“ (nije primjenjivo) nije definirano ovom specifikacijom obzirom da se odnosi na kontekst koji je izvan opsega trenutačnog dokumenta.

4.3.3. Ponašanje mreže u odašiljanju (Network behaviour in emission)

Zadano je da se mogu slati samo SIP signalizacijski elementi (metode, zaglavlja (headeri), parametri zaglavlja (headera), statusni kod odgovora, oznake (tagovi) opcija, …) koji su definirani i autorizirani (kao obvezni (mandatory) ili opcionalni (optional)) ovim dokumentom.

No, bez obzira na gore navedeno, sukladno bilateralnim sporazumima, SIP signalizacijski elementi koji nisu definirani ili autorizirani sadašnjom specifikacijom mogu se razmjenjivati preko sučelja za međupovezivanje.

4.3.4. Inicijalna INVITE metoda (Initial INVITE method)

Inicijalni INVITE zahtjev (request) je obvezan (mandatory) kako je definirano RFC3261.

4.3.4.1. Postupanje sa SIP zahtjevom (SIP request handling)

Postupanje s ovim zahtjevom (request) mora biti u skladu s RFC3261.

4.3.4.2. Zaglavlja (Headeri) podržana u zahtjevu (Supported headers in the request)

Tablica 2 daje status zaglavlja (headera) u inicijalnom INVITE i za smjer prijama i za smjer odašiljanja.

Tablica 2: Podržana SIP zaglavlja (headeri) u inicijalnom INVITE zahtjevu

4.3.4.3. Postupanje sa SIP odgovorom (SIP response handling)

Sa SIP odgovorima (responses) se postupa sukladno RFC3261 uz pojašnjenje dano u Tablici 3 dolje. Ako je zaprimljen odgovor, koji nije podržan (non-suported error response) onda odgovarajući poziv (relative call) ili transakcija propadaju (fails).

Višestruki SIP odgovori za vrijeme uspostave poziva (provisional responses) koji kreiraju odvojene rane dijaloge (early dialogs), kako je specificirano RFC3261, su podržani (supported) uz sljedeće pojašnjenje:

• Po primitku odgovora za vrijeme uspostave poziva (provisional responses) koji sadrže SDP tijela (SDP bodies), primatelj mora koristiti najnoviju primljenu informaciju o medijskoj sesiji (media session) za slanje media paketa za vrijeme faze ranog dijaloga (early dialog phase),

• Potvrđeni dijalozi (confirmed dialogs) koji su kreirani prvim 200 OK odgovorom (response) za nepostojeće rane dijaloge (non-existing early dialogs) će zamijeniti (override) bilo koju ranije pohranjenu informaciju o dijalogu.

Tablica 3: Postupanje sa SIP odgovorima

* ako je maksimalan broj simultanih sesija premašen, morat će biti poslan odgovor (response) 503 uz sljedeću frazu objašnjenja razloga: "Service Not Available“

4.3.4.4. Podržana zaglavlja (headeri) u odgovorima (Supported headers in the responses)

Tablica 4 daje status zaglavlja (headera) u SIP odgovorima (responses) na inicijalni INVITE zahtjev (request) i za smjer prijama i za smjer odašiljanja:

Tablica 4: Podržana SIP zaglavlja (headeri) u odgovorima na inicijalni INVITE zahtjev

4.3.5. Re-INVITE zahtjev

Re-INVITE zahtjev (request) mora biti podržan (supported) kako je definirano RFC3261.

4.3.5.1. Postupanje sa SIP zahtjevom (SIP request handling)

Postupanje s ovim zahtjevom mora biti u skladu s RFC3261.

4.3.5.2. Zaglavlja (Headeri) podržana u zahtjevu (Supported headers in the request)

Tablica 5 daje status zaglavlja (headera) u re-INVITE zahtjevu (request) i za smjer prijama i za smjer odašiljanja:

Tablica 5: Podržana SIP zaglavlja (headeri) u re-INVITE zahtjevu

4.3.5.3. Postupanje sa SIP odgovorom (SIP response handling)

Postupanje s odgovorima (responsed) mora biti u skladu s RFC3261.

1xx odgovori (responses) različiti od 100 se ne očekuju (not expected) kao odgovor (response) na re-INVITE zahtjev (request)

4.3.5.4. Podržana SIP zaglavlja (headeri) u odgovorima (responses)

Tablica 6 daje status zaglavlja (headera) u SIP odgovorima (responses) na re-INVITE zahtjev (request) i za smjer prijama i za smjer odašiljanja.

Tablica 6: Podržana SIP zaglavlja (headeri) u odgovorima (responses) na re-INVITE zahtjev (request)

4.3.6. CANCEL metoda

CANCEL zahtjev (request) mora biti podržan (supported) kako je definirano RFC3261.

4.3.6.1. Postupanje sa SIP zahtjevom (SIP request handling)

Postupanje s ovim zahtjevom (request) mora biti u skladu s RFC3261.

Kada pozivajuća strana želi završiti sesiju (terminate session) za vrijeme faze ranog dijaloga (early dialog phase) preporučuje se uporaba CANCEL metode umjesto BYE metode.

4.3.6.2. Podržana zaglavlja (headeri) u zahtjevu (Supported headers in the request)

Tablica 7 daje status zaglavlja (headera) u SIP CANCEL zahtjevu (request) i za smjer prijama i za smjer odašiljanja.

Tablica 7: Podržana SIP zaglavlja (headeri) u CANCEL zahtjevu (request)

SIP statusni kodovi i ITU-T Q.850 release cause vrijednosti prikazani u decimalnom obliku podržani su (supported) u Reason zaglavlju (headeru), sukladno RFC3326.

4.3.6.3. Postupanje sa SIP odgovorom (SIP response handling)

Postupanje s odgovorima (reponses) mora biti u skladu s RFC3261.

4.3.6.4. Podržana zaglavlja (headeri) u odgovorima (Supported headers in the responses)

Tablica 8 daje status zaglavlja (headera) u odgovorima (responses) na CANCEL zahtjev (request) i za smjer prijama i za smjer odašiljanja.

Tablica 8: Podržana SIP zaglavlja (headeri) u SIP odgovorima (response) na CANCEL zahtjev (request)

4.3.7. ACK metoda

ACK zahtjev (request) mora biti podržan (supported) kako je specificirano RFC3261.

4.3.7.1. Postupanje sa SIP zahtjevom (SIP request handling)

Postupanje s ovim zahtjevom (request) mora biti u skladu s RFC3261.

4.3.7.2. Zaglavlja (Headeri) podržana u zahtjevu (Supported headers in the request)

Tablica 9 daje status zaglavlja (headera) u ACK zahtjevu (request) i za smjer prijama i za smjer odašiljanja.

Tablica 9: Podržana SIP zaglavlja (header) u ACK zahtjevu (request)

4.3.8. BYE metoda

BYE zahtjev (request) mora biti podržan (supported) kako je specificirano RFC3261.

4.3.8.1. Postupanje sa SIP zahtjevom (SIP request handling)

Postupanje s ovim zahtjevom mora biti u skladu s RFC3261.

4.3.8.2. Zaglavlja (Headeri) podržani u zahtjevu (Supported headers in the request)

Tablica 10 daje status zaglavlja (headera) u BYE zahtjevu (request) i za smjer prijama i za smjer odašiljanja.

Tablica 10: Podržana SIP zaglavlja (headeri) u BYE zahtjevu (request)

I SIP statusni kodovi i ITU-T Q.850 cause vrijednosti prikazane u decimalnom obliku trebale bi biti podržane (supported) u Reason zaglavlju (headeru), sukladno RFC3326 .

4.3.8.3. Postupanje sa SIP odgovorom (SIP response handling)

Postupanje odgovorima mora biti u skladu s RFC3261.

4.3.8.4. Zaglavlja (Headeri) podržana u odgovorima (Supported headers in the responses)

Tablica 11 daje status zaglavlja (headera) u SIP odgovorima (responses) na BYE zahtjev (request) i za smjer prijama i za smjer odašiljanja.

Tablica 11: Podržana SIP zaglavlja (headeri) u odgovorima (responses) na BYE zahtjev (request)

4.3.9. OPTIONS metode

Napomena: OPTIONS metode su opcionalne

Ako se upotrebljava, OPTIONS metoda mora biti podržana (supported) kako je specificirano RFC3261.

4.3.9.1. Postupanje sa SIP zahtjevom (SIP request handling)

Postupanje s ovim zahtjevom mora biti u skladu s RFC3261.

4.3.9.2. Zaglavlja (Headeri) podržana u zahtjevu (Supported headers in the request)

Tablica 12 daje status zaglavlja (headera) u OPTION zahtjevu (request) i za smjer prijama i za smjer odašiljanja.

Tablica 12: Podržana SIP zaglavlja (headeri) u OPTION zahtjevu (request)

4.3.9.3. Postupanje sa SIP odgovorom (SIP response handling)

Postupanje s odgovorima (responses) mora biti u skladu s RFC3261.

4.3.9.4. Zaglavlja (Headeri) podržana u odgovoru (Supported headers in the response)

Tablica 13 daje status zaglavlja (headera) u SIP odgovoru (response) na OPTIONS zahtjev (request) i za smjer prijama i za smjer odašiljanja.

Tablica 13: Podržana SIP zaglavlja (headeri) u odgovoru (response) na OPTION zahtjev (request)

4.4. Kompaktna forma SIP zaglavlja (headera) (SIP headers compact form)

Kako se navodi i u normi RFC3261, slanje SIP zaglavlja (headera) u kompaktnu formu je opcionalno (optional). Preporuča se izbjegavanje korištenje kompakt forme SIP zaglavlja. Ako se ipak koriste, korištenje kompaktne forme zaglavlja trebalo bi se temeljiti na bilateralnom dogovoru između operatora.

4.5. Maksimalna duljina poruke (Maximum message size)

Preporučuje se da veličina SIP poruke ne prelazi 2048 okteta (byte). Veličina SDP tijela (SDP bodies) ne bi trebala prelaziti 1024 okteta (byte). Preporučene duljine poruka rezultat su dogovora između operatora.

Napomena: Sadržaj poglavlja od 4.3.1. do 4.5. bit će ažuriran sukladno realnom stanju po završetku testiranja kod uspostave IP međupovezivanja između operatora.

5. TIJELA PORUKE (MESSAGE BODIES)

U kontekstu ovog dokumenta, jedino SIP tijelo poruke (SIP message body) koje je podržano (supported) je SDP (podtip aplikacije „application/sdp“).

6. PODRŽANE OZNAKE MOGUĆNOSTI SIP EKSTENZIJA (SUPPORTED OPTION TAGS OF SIP EXTENSIONS)

U kontekstu ovog dokumenta dopuštene su slijedeće oznake opcionalnih mogućnosti (option tags):

• „timer“ -  ako je u bilateralnom sporazumu korišten izborni „keep alive“ mehanizam za aktivne SIP sesije na način kako je definiran RFC4028;

• „100rel“ - ako je u bilateralnom sporazumu korišten izborni „reliable transmission of provisional responses“ mehanizam na način kako je definiran RFC3262.

7. FORMAT IDENTIFIKACIJE, PARAMETRI ADRESE I SIGNALIZACIJSKI MOD (IDENTITIES FORMAT, ADDRESS PARAMETERS AND SIGNALLING MODE)

Formati identifikacije podržani za parametar Request – URI kao i From, To, P-Asserted Identity i Diversion zaglavlja (headers) opisani su tablicom 14.

Formati adresa podržani za Route, Via i Contact zaglavlja (headere) opisani su također u tablici 14.

SIP URI format mora biti u skladu s RFC3261/19.1, a TEL URI u skladu s RFC3966 pri čemu je korištenje TEL URI formata opcionalno i mora biti dogovoreno bilateralnim sporazumom.

Tablica 14: Podržani formati identifikacije

Dodatno, u obzir treba uzeti sljedeće detalje:

• U "globalnumber" formatu broja obavezno je korištenje znaka "+" ispred E.164 formata broja u skladu s RFC3966. Prethodno ne vrijedi za CPS/WLR pozive, kao ni za nacionalne lokalno ustrojene žurne brojeve (EN).

• Parametar Request-URI i To zaglavlje (header) sadrže informaciju o pozvanom broju. From i P-Asserted-Identity zaglavlja (headers) sadrže informaciju o pozivajućem broju. Diversion zaglavlje (header) sadrži informaciju o broju s kojeg je poziv preusmjeren. Spomenuta su zaglavlja uvijek u formatu E.164, osim parametra Request-URI i To zaglavlja (header) za slučaj CPS/WLR poziva, te poziva prema nacionalnim lokalno ustrojenim žurnim brojevima (EN).

• Koristit će se isključivo "en bloc" signalizacija, dakle cijeli pozvani broj očekuje se unutar jednog INVITE zahtjeva (request).

Formati brojeva za HT CPS/WLR uslugu

Sljedeći formati pozivanog broja (B-broja) bit će podržani na sučelju HT -> FNO za CPS/WLR uslugu, gdje je "XY" oznaka mreže operatora (NetID):

• Međunarodni B-broj (CC+AC+SNB)

U R-URI B-broj u formatu 10XY [CC] [AC] [SNB]

• Nacionalni B-broj u rasponu 1-9 (AC+SNB)

U R-URI B-broj u formatu 10XY [385] [AC] [SNB]

• Županijsko ustrojeni kratki kod (AC+SC) npr. služba 18095

U R-URI B-broj u formatu 10XY [385] [AC] [SC]

• Nacionalno ustrojeni kratki kod (SC) npr. služba 11888

U R-URI B-broj u formatu 10XY [385] „C“ [SC] (varijanta s overdecadic C znamenkom)

• Županijsko ustrojeni žurni broj (AC+EN) npr. služba 112 ili 194

U R-URI B-broj u formatu 10XY [385] „C“ [EN] (varijanta s overdecadic C znamenkom)

• Nacionalno ustrojeni žurni broj (EN) npr. služba 195 ili 1987

U R-URI B-broj u formatu 10XY [385] „C“ [EN] (varijanta s overdecadic C znamenkom)

Napomena: Obzirom da se radi o lokalnom formatu, R-URI će uvijek sadržavati i phone-context=+385.

NP (Number Portability) koncept

Format na sučelju za terminaciju i tranzitiranje NP poziva:

• U R-URI B-broj u formatu E.164

Napomena: Za pozive prema prenesenim brojevima (NP) koristit će se "globalnumber" format broja (obavezno je korištenje znaka "+" ispred E.164 formata broja) jer svi operatori koriste ACQ (All Call Query) metodu za dohvaćanje odredišne mreže u koju je broj prenesen.

Nomadi

Nezemljopisni broj usluge osobnog broja (nomadska numeracija)

Radi se o numeraciji 074xxxxxx i 075xxxxxx kod koje nije moguće raditi geopozicioniranje. Ova numeracija je izuzeta od pravila terminacije poziva prema područnim žurnim službama na osnovu geokoordinata.

Terminacija žurnih poziva se radi isključivo na županijske žurne službe ukoliko je nomadski korisnik birao žurni poziv sa area code-om:

• U R-URI B-broj u formatu E.164 koji se sastoji od +385 [AC] [EN]

U slučaju da je nomadski korisnik birao žurni poziv bez area code-a operator davatelj usluge je dužan modificirati zaprimljeni B-broj u jedinstveni broj +3851112 (nacionalni DUZS):

• U R-URI B-broj u formatu E.164 koji se sastoji od +3851112

Formati kratkih kodova za govorne usluge (SC) na sučelju između operatora

Županijsko ustrojen SC npr. 18095:

• U R-URI B-broj u formatu E.164 koji se sastoji od +385 [AC] [SC]

Nacionalno ustrojen kratki kod SC npr. 11888:

• U R-URI B-broj u formatu E.164 koji se sastoji od +385 “C” [SC]

Obzirom da za nacionalne servise ne postoji area code dogovor među operatorima je da se na mjesto AC fiktivno ubacuje znamenka „1“ --> Prijedlog je „1“ zamijeniti s overdecadic „C“ (primjer E.164 koji se sastoji od +385“C“SC). Na ovaj način postoji unifikacija za isti format u različitim uslugama.

Formati brojeva žurnih službi (EN) na sučelju između operatora

Nacionalno ustrojene žurne službe 195 i 1987:

• U R-URI B-broj u formatu E.164 koji se sastoji od +385 “C” [EN]

Obzirom da za nacionalne ŽS ne postoji area code dogovor među operatorima je da se na mjesto AC fiktivno ubacuje znamenka „1“ za 1987 i „51“ za 195 --> Prijedlog je da se „1“ „51“ zamijeni s overdecadic „C“ (primjer E.164 koji se sastoji od +385“C“EN) . Na ovaj način dolazi do unifikacije za isti format u različitim uslugama.

Županijsko ustrojene žurne službe 112, 192, 193, 194:

• U R-URI B-broj u formatu E.164 koji se sastoji od +385 [AC] [EN]

Područne žurne službe

• U R-URI B-broj u formatu EXYAE [AC] [SNB] i phone-context= +385 -->Lista ovih brojeva je poznata i radi se isključivo o područnim žurnim službama.

E-call

Promet isključivo od mobilnih operatera prema Operatoru kod kojega se nalazi točka terminacije.

• U R-URI B-broj u formatu EXYEC1112 i phone-context= +385.

Napomena: Operatori koji to mogu podržati, za sve će pozive prema žurnim brojevima (hitne službe) dodati zaglavlje (header) : Resource: priority (RFC4412).“

8. UPRAVLJANJE MEDIJSKOM SESIJOM (MEDIA SESSION MANAGEMENT)

Razmjena SDP ponuda/odgovora offer/answer odvijat će se sukladno RFC3261, RFC3264 i RFC4566.             

SDP informacija je podržana jedino u tijelu INVITE, re-INVITE, ACK, 200 OK (INITE, re-INVITE) i 18x(INVITE) poruka (messages) i PRACK poruci.

Minimalno, moraju biti podržani (suported) SDP parametri korišteni u RF3264 .

Mehanizmi i parametri definirani za preduvjete RFC3312 kao i za SDP jednostavnu deklaraciju sposobnosti (SDP simple capability declaration) su izborni (optional).

8.1. Uspostava medijske sesije (Media session establishment)

8.1.1. Inicijalna INVITE poruka (Initial INVITE message)

Ovaj odlomak pretpostavlja pravila ponude/odgovora (offer/answer) koja su temeljena isključivo na RFC3261 i RFC3264. Dodatna pravila ponude/odgovora (offer/answer) definirana u RFC3262 i RFC3311 mogu se koristiti na temelju bilateralnih sporazuma, ali isti su izvan djelokruga ovog dokumenta.

Inicijalne INVITE poruke (messages) mogu, ali i ne moraju sadržavati SDP ponudu (offer).

Napomena: Zadano je (By default), ako inicijalna INVITE poruka (message) ne sadrži SDP ponudu (offer), onda slanje medija prije uspostave poziva prema izvoru poziva (backward early-media) nije moguć. (8.1.3.).

Inicijalna INVITE poruka (message) sa SDP ponudom (offer) se ne smije kodirati s konekcijskom adresom(("c=" line) postavljenom na 0.0.0.0

Kada inicijalni INVITE sadrži SDP ponudu (offer), SDP odgovor (answer) mora biti prisutan u 200 OK odgovoru (response).

Kada inicijalni INVITE ne sadrži SDP ponudu (offer), SDP ponuda (offer) mora biti prisutna u 200 OK odgovoru (response). U ovom slučaju, strana koja je uputila INVITE bez SDP ponude (offer), mora poslati SDP ponudu (offer) u ACK poruci (message). U slučaju da strana koja je uputila INVITE bez SDP ponude (offer) koristi PRACK metodu (method), SDP ponudu (offer) može poslati i u PRACK poruci (message).

8.1.2. Pravila dogovora o kodecima (Codec negotiation rules)

U medijskom toku (stream) “m=” line, kodeci moraju biti navedeni po redu preferencije za SDP pregovore, na način da je prvi kodek format na listi preferirani.

Ako primljeni SDP odgovor (answer) pokazuje podržavanje više od jednog kodeka različitog od “telephone-event” među kodecima predloženim u SDP ponudi (offer), samo će se prvi uzeti u razmatranje. Kako bi se prešlo na drugi predloženi medija format iz SDP odgovora (answer) različit od “telephone-event”, moraju se obaviti ponovni SDP pregovori (8.2).

"a=ptime" je media atribut koji pokazuje željeni interval paketizacije kojeg bi završna točka željela uzeti u razmatranje u prijemu za specifični medijski tok (media stream) ali ne za specifični kodek. Ako je informacija dostupna, preporučuje se slanje "a=ptime" parametra preko intekonekcijskog sučelja.

Ako nema zajedničkih media formata u SDP ponudi (offer) primljenoj u:

Incijalnoj INVITE poruci (message) ili re_INVITE poruci (message), ista će biti će odbijena s 488 „"Not acceptable here" odgovorom (response);

200 OK odgovor (response) na INVITE poruku (message), poziv će biti raskinut (realesed).

8.1.3. Slanje medije prije uspostave poziva (Early media)

Prijam SDP odgovora (answer) u 18x (183 SDP) odgovoru (response) može biti dovoljan pokazatelj slanja medija prije uspostave poziva (early media) s izvora poziva (downstream domain), pri čemu je mreža koja pošalje takav odgovor (reponse) odgovorna za izvođenje odgovarajućih tonova ili poruka. Ako se oba operatera međusobno dogovore, P-Early-Media zaglavlje (header) bit će uključen kako bi garantirao da će tok medija prije uspostave poziva (early media stream) poslan u smjeru prema izvoru (in the backward direction) biti uzet u obzir u svim slučajevima. P-Early-Media zaglavlje (header) koje je prisutno u 18x odgovoru (response) mora sadržavati parametre usmjeravanja postavljene na “sendrecv” ili “sendonly”. Ako se koristi druga vrijednost, P-Early-Media zaglavlje (header) mora biti ignorirano (ignored). Sintaksa P-Eearly-Media zaglavlja (header) je definirana u specifikacijama RFC5009 i TS 24.628.

8.2. Modifikacija medijske sesije (Media session modification)

Jednom kad je sesija uspostavljena, modifikacija parametara medijske sesije se mora podržati (support) kroz re-INVITE poruku (message) sukladno RFC3261.

8.3. Završavanje sesije (Terminating a session)

Procedure koje se koriste za završetak sesije (termination of seession) opisane su u RFC3261, precizirajući sljedeće: kada strana pozivatelja želi završiti sesiju za vrijeme early-dijalog faze, preporučuje se korištenje CANCEL metode umjesto BYE metode.

8.4. RTP/RTCP paketski izvori (RTP/RTCP packet source)

U sesiji, za slanje i primanje RTP paketa moraju se koristiti ista IP adresa i broj porta – simetrično.

Napomena: Broj porta za slanje/primanje RTCP paketa MORA biti jednak „broju porta ispregovaranog za RTP“+1. ("the port number negotiated for RTP" + 1.)

RFC3556 koji definira SDP modifikatore propusnosti (Bandwidth) za RTCP može biti izborno podržan (optionaly supported) temeljem bilateralnog ugovora između strana.

9. KODECI ZA GOVOR

U nastavku su navedeni preferirani i podržani kodeci za govor:

Napomena: Za sve nove kodeke koji će biti podržani u budućnosti, mora postojati dogovor između operatora.

Transkodiranje se obavlja na strani originirajuće mreže.

10. OSTALI KODECI I PROCEDURE

Ostali kodeci i procedure primjenjive u mreži pokretnih i nepokretnih komunikacija:

• DTMF - RFC4733 (payload type '101') ili in-band (G.711a (payload type '8'))

• Tonovi i govorne poruke – prema 8.1.3., odnosno RFC5009 u slučaju da se koristi P-Early Media

• FAX – G.711 a (payload type '8') ili T.38 s prelaskom na G.711a (payload type '8')

• Modem/POS - G.711a (payload type '8')

• ISDN Clear channel - CLEARMODE RFC4040

Transkodiranje se obavlja na strani originirajuće mreže.

11. „KEEP ALIVE“ MEHANIZMI

11.1. „Keep alive“ mehanizam za aktivne SIP sesije (sessions)

Korištenje „keep alive“ mehanizma za provjeru aktivnih SIP sesija (sessions) je opcionalno i mora biti dogovoreno bilateralnim sporazumom. Mehanizam se koristi slanjem periodičkih re-INVITE, UPDATE ili OPTIONS zahtjeva vezanih uz SIP sesije na način kako je definiran RFC4028.

11.2. „Keep alive“ mehanizam za provjeru statusa SIP signalnih linkova

Korištenje „keep alive“ mehanizma za provjeru statusa SIP signalnih linkova mora biti podržano te jedogovoreno bilateralnim sporazumom. Mehanizam se koristi slanjem zasebnih periodičkih OPTIONS zahtjeva koji nisu vezani uz SIP sesije. U slučaju zaprimanja bilo kakvog SIP odgovora od suprotne strane smatra se da je SIP signalni link funkcionalan.

12. DOMENE

Operatori će svoje domene specificirati u svojim standardnim/minimalnim ponudama za IP međupovezivanje. Preporuka je, zbog unifikacije naziva usluge, koristiti standard „sip.naziv operatera.hr“.

Radi izbjegavanja dvojbi, standard „sip.naziv operatora.hr“ nije obvezan, već samo preporučen, što znači da operatori mogu u svojim standarnim/minimalnim ponudama koristiti i drugačiji standard.

13. USMJERAVANJE I OSTVARIVANJE VISOKE RASPOLOŽIVOSTI

Općenito, usmjeravanje prometa i arhitektura IP međupovezivanja mora biti takva da se osigura visoka razina raspoloživosti.

Za potrebe međupovezivanja s HT-om operatori se spajaju u dva pristupna područja. Operatori usmjeravaju promet prema HT-u prema oba pristupna područja u omjeru 50%-50%, u svrhu uravnoteženja opterećenja (load balancing), neovisno o području iz kojeg je poziv započeo i gdje završava. Radi osiguranja odgovarajuće razine pouzdanosti, operatori su obavezni povezati se s HT mrežom u oba pristupna područja, putem jedne ili više pristupnih točaka u svakom od dva pristupna područja.

Iznimno i isključivo u prijelaznom razdoblju, sve dok pojedini operator ima realizirano PSTN/TDM međupovezivanje, IP međupovezivanje s HT-om je moguće realizirati putem samo jednog pristupnog područja.

U slučaju da se Operator s HT-om povezuje redundantno na obje pristupne točke unutar istog pristupnog područja, u tu svrhu koristiti će se eBGP protkol kao podrazumijevana opcija za međumrežno povezivanje. Obzirom na metrike usmjeravanja (rutiranja) jedan od linkova kod redundantnog spajanja će biti primarni/aktivan, a drugi sekundardni/rezervni (backup), što će se dogovarati između operatora prilikom same realizacije spajanja kao i ostali BGP routing parametri (mreže, MD5 password itd). Dodatna mogućnost za ostvarivanje međumrežnog povezivanja u ovom slučaju je korištenje statičkog usmjeravanja i IP SLA ICMP Echo metode kao alternativa BGP rutingu.

U slučaju da se Operator s HT-om povezuje samo u jednoj točci unutar istog pristupnog područja, u tu svrhu će se koristiti statičko usmjeravanje kao podrazumijevana opcija za međumrežno povezivanje.

Ukoliko operator ima ili namjerava u svojoj mreži imati hitnu službu dužan je radi osiguranja odgovarajuće razine sigurnosti ostalim operatorima omogućiti redundantno spajanje.

Usmjeravanje prema hitnim službama obavljat će se prema istim principima i pravilima kao i za TDM/PSTN međupovezivanje.

14. OBRAČUN PROMETA

Za potrebe obračuna prometa u IP međupovezivanju, u CDR-ovima će se bilježiti isti podaci koji se bilježe i sada kod TDM/PSTN međupovezivanja:

-          oznaka interkonekcijske točke (SBC uređaja)

-          A-broj

-          B-broj

-          odlazni smjer

-          dolazni smjer

-          kod operatora

-          datum početka poziva

-          vrijeme početka poziva

-          trajanje poziva

15. TESTIRANJE

Testiranja bi trebala obuhvatiti slijedeća poglavlja:

-          Inicijalna IP testiranja povezivanja/Initial IP Testing between Carrier A and Carrier B

-          Osnovni pozivi/Basic Call Flow and Basic Fax Tests for Carrier A and Carrier B

-          Ispitivanja dodatnih usluga/Supplementary Services Tests

-          Ispitivanja kvalitete govora i FAX uređaja /Voice Quality Tests for Carrier A/Carrier

-          Ispitivanja naplate/CDR Validation Tests

-          Ispitivanja govornih poruka (announcement)

-          Ispitivanje modemske veze/dial-up/POS/alarm/ISDN data

-          Pozivi prema prenesnim brojevima, CPS pozivi, pozivi prema hitnim službama (Ported Number calling, Carrier Pre-select calls, Emergency number calling)

-          Transkodiranje poziva

-          Ispitati CLIP funkcionalnost

-          Ostalo

Napomena: Sadržaj ovog poglavlja bit će ažuriran sukladno realnom stanju po završetku testiranja kod uspostave IP međupovezivanja između operatora.

16. QOS

Operatori moraju imati ispravno konfiguriranu kvalitetu usluge (QoS) u svojoj mreži. Moguća je prilagodba QoS oznaka na međupovezivanju.

Operatori će međusobno dogovoriti o pokazateljima kvalitete transporta (bazirani na osnovu IR.34) koji će se mjeriti i međusobno izmjenjivati u proceduri provjere kvalitete transporta.

Operatori će međusobno dogovoriti o pokazateljima kvalitete usluge (npr. MOS, ASR, NER, Nepropusnost, IR.34) koji će se mjeriti i međusobno izmjenjivati u proceduri provjere kvalitete usluge, te će svaki u operator u odlaznom prometu slati QoS parametre kakve druga strana očekuje.

17. VODOVI U SVRHU IP MEĐUPOVEZIVANJA

Vodovi koji se koriste u svrhu IP međupovezivanja bit će dvosmjerni, osim ako se obje ugovorne strane ne dogovore drugačije.

U slučaju povezivanja s mobilno-fiksnim operatorom, moguće je koristiti iste vodove i za fiksni i za mobilni promet.

U slučaju kada vodove u svrhu IP međupovezivanja osigurava operator sa značajnom tržišnom snagom na mjerodavnom tržištu iznajmljenih vodova, cijene vodova bit će sukladne obvezama propisanim odgovarajućim analizama na mjerodavnim tržištima iznajmljenih vodova.

18. ARHITEKTURA POVEZIVANJA

Zbog ostvarenja visoke raspoloživosti, operatori su dužni povezati se putem minimalno dvije IP veze u dvije različite točke, neovisno da li se povezuju unutar istog grada ili u različitim gradovima[1].

Također, dužni su uspostaviti minimalno dva SIP linka, neovisno da li se radi o dva aktivna SIP linka ili jedan aktivan SIP link i jedan standbySIP link.

U nastavku su navedennu prijedlozi mogućih arhitektura međupovezivanja.

18.1. Povezivanje dva operatora s po jednim SBC-om

U slučaju da svaki od operatora ima po jedan SBC, preporučena arhitektura je slijedeća:

Operatori uspostavljaju jedan aktivan SIP link uz jedan standby SIP link koji će se koristiti u slučaju ispada IP povezivosti između SBC-ova.

Detekcija ispada i zaštitno usmjeravanje ostvaruje se na IP sloju.

18.2. Povezivanje operatora s jednim SBC-om i operatora s dva SBC-a

U slučaju da jedan operator ima jedan SBC, a drugi operator dva SBC-a, preporučena arhitektura je slijedeća:

Operatori uspostavljaju dva aktivna SIP linka koji rade u load balancing načinu rada, pri čemu u slučaju ispada jednog linka, drugi preuzima potpunu razmjenu prometa između operatora.

Detekcija ispada i zaštitno usmjeravanje ostvaruje se na aplikacijskom sloju tj na SIP razini.

Ovisno o potrebama operatora i bilateralnom dogovoru između operatora, detekciju ispada i zaštitno usmjeravanje moguće je ostvariti i na IP sloju.

18.3. Povezivanje dva operatora s po dva SBC-a

U slučaju da svaki od operatora ima po dva SBC, preporučena arhitektura je slijedeća:

Operatori uspostavljaju četiri aktivna SIP linka koji rade u load balancing načinu rada, pri čemu u slučaju ispada jednog linka, preostali preuzimaju potpunu razmjenu prometa između operatora.

Ovisno o potrebama operatora i bilateralnom dogovoru između operatora, alternativno je moguće ostvariti povezivanje putem dva aktivna SIP koji rade u load balancing načinu rada, pri čemu u slučaju ispada jednog linka, drugi preuzima potpunu razmjenu prometa između operatora.

Detekcija ispada i zaštitno usmjeravanje ostvaruje se na aplikacijskom sloju tj na SIP razini.

Ovisno o potrebama operatora i bilateralnom dogovoru između operatora, detekciju ispada i zaštitno usmjeravanje moguće je ostvariti i na IP sloju.

19. POVEZIVANJE PUTEM JAVNOG INTERNETA

Međupovezivanje između operatora putem javnog interneta nije dozvoljeno, zbog potrebe osiguranja dostatne kakvoće usluga za krajnje korisnike.

Za one operatore koji su do trenutka stupanja na snagu ovog dokumenta imali uspostavljeno međupovezivanje putem javnog interneta, isto će biti moguće i dalje, zbog osiguranja regulatorne predvidljivosti.

20. AŽURIRANJE DOKUMENTA O UVJETIMA IP MEĐUPOVEZIVANJA

Dokument o IP međupovezivanju će se redovito ažurirati u skladu s potrebama i novim saznanjima s tržišta.

PRIVITAK

Tablica kratkih kodova s formatima i opisom

U slučaju dizanja novog kratkog koda koji se ne nalaze u tablici iz privitka, operator je dužan o tome obavijestiti HAKOM te mu dostaviti format i opis novog kratkog koda. HAKOM će nakon toga ažurirati tablicu iz privitka ovog dokumenta te o tome obavijestiti preostale operatore.