Kosta Pribić, dipl. ing. - cisco.com · Prezentacija diskutira tehnička rješenja i izazove, ne...

© 2010 Cisco and/or its affiliates. All rights reserved. Cisco Confidential 2 © 2010 Cisco and/or its affiliates. All rights reserved. Cisco Confidential 2 © 2010 Cisco and/or its affiliates. All rights reserved. Cisco Confidential 2

Kosta Pribić, dipl. ing.

Uvod

  Razvoj VoIP tehnologije kod CSPova (Communication Service Provider) omogućuje konekciju CUCM centrala u mreže koje koriste VoIP sa kraja na kraj

  Prijelaz na all-IP mrežu za IP PBX centrale nije “plug&play” rješenje   Veliki poslovni korisnici imaju već izgrađene CUCM infrastrukture

integrirane u korisnikovu internu IT mrežu sa vlastitim specifičnostima   CSP treba podržati različite korisnike sa različitim korisničkim internim

arhitekturama po mogućnosti bez promjene na korisničkim stranama   Unatoč arhaičnosti faks tehnologije, u poslovnom svijetu se i dalje

koristi tako da je vrlo bitno osigurati ispravno slanje faksova   U ovoj prezentaciji se nudi pregled nekih tipičnih situacija koje se javljaju

kod tranzicije na mreže koje su VoIP sa kraja na kraj te opis tehničkog rješenja spajanja CUCMa pomoću više SIP trunkova

  Prezentacija diskutira tehnička rješenja i izazove, ne odnosi se na konkretne implementacije u praksi

3 16.3.2011 Kosta Pribić - Izazovi integracije Cisco Unified Communications Managera u all-IP mrežama

Sadržaj

1.  VoIP “otok” vs VoIP mreža sa kraja na kraj 2.  VoIP interoperabilnost 3.  FoIP (Fax over IP) 4.  SIP Trunking failover 5.  Zaključak


VoIP “otok”

  U pravilu rješenja samo jednog proizvođača   Mala količina problema

oko interoperabilnosti   Prema “svijetu” se pristupa

preko VGa (voice gateway) na PSTN koristeći TDM linkove

  Unutar “otoka” se koriste VoIP protokoli   SIP, SCCP, MGCP, H.

323…   Sve VoIP usluge pruža IP

PBX centrala   Glazba na čekanju   Konferencije   …


End-to-end VoIP

  SIP protokol   Niža cijena usluge   Nije rješenje sa

samo jednim proizvođačem   Interoperabilno

st postaje značajan faktor

  Na stare usluge i tehnologije treba posebno obratiti pozornost:   ISDN usluge   Faks


VoIP interoperabilnost - Standardi

  Standardi   IETF – RFC

  Specificiraju SIP   Brzo se mijenjanju   Primjer:

  “The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [2] and indicate requirement levels for implementations compliant with this RTP profile.”

  ITU-T   Detaljno speficirani (primjer: H.323)   Sporo se pišu


VoIP interoperabilnost – kodeci i DTMF

  Koristi se mnogo kodeka   G.729 (r8, ar8, br8, abr8)   G.711 (a, u)   G.722   G.726   XCCD ili clear-channel (ekvivalent ISDN unrestricted digital 64k)   …

  Postoji više metoda slanja DTMFa   NTE   SIP INFO   SIP NOTIFY   SIP KPML   RTP (inband)


VoIP interoperabilnost – Primjer SIP poruke

INVITE sip:[email protected]:5060;user=phone;transport=udp SIP/2.0 Via: SIP/2.0/UDP 192.168.99.2:5060;branch=z9hG4bKp9ufij20bghgrq0f97s0.1 From: “9876543" <sip:[email protected]>;tag=96479bc8-2cd7-c8bf To: sip:[email protected] Call-ID: [email protected] CSeq: 1 INVITE Max-Forwards: 64 Allow:

INVITE,BYE,ACK,CANCEL,PRACK,REFER,OPTIONS,REGISTER,NOTIFY Min-SE: 1800 Supported: replaces,timer P-Asserted-Identity: “9876543" sip:[email protected] Contact: sip:[email protected]:5060;transport=udp Content-Length: 288 Content-Type: application/sdp


VoIP interoperabilnost – Primjer SDP poruke

v=0 o=016172390 10019 10019 IN IP4 192.168.100.59 s=Cisco 7912 SIP Call c=IN IP4 192.168.100.59 t=0 0 m=audio 16384 RTP/AVP 18 8 0 101 a=rtpmap:18 G729/8000/1 a=fmtp:18 annexb=yes a=rtpmap:8 PCMA/8000/1 a=rtpmap:0 PCMU/8000/1 a=rtpmap:101 telephone-event/8000 a=fmtp:101 0-15


VoIP interoperabilnost – Pregovor oko kodeka

  Pregovor oko kodeka – “Early offer”   Uobičajena metoda   B strana bira kodek

  A strana nudi SDP A:   G.729, G.711a, G.711u

  B strana vraća SDP B   G.729

  U slučaju da niti jedan kodek nije prihvatljiv B strana vraća poruku “Media not supported”



  Pregovor oko kodeka – “Delayed offer”

  A strana ne šalje SDP u INVITE poruci i efektivno prisiljava B stranu da prva ponudi SDP

  A strana na kraju bira kodek

  Nije uobičajen model pregovora oko kodeka



  Više kodeka u SDP odgovoru   Na slici je rješenje prema RFCu:

Poslati treći SDP sa samo jednim kodekom

  SDP A1 – G.729, G.711a, G.711u

  SDP B – G.711a, G.711u   SDP A2 – G.711a

  Praksa:   Implicitno VGovi odaberu prvi

kodek i ignoriraju drugi   Neslaganje oko RTPa (RTP

mismatch )– jedna strana odabere prvi kodek a druga strana odabere drugi kodek


VoIP interoperabilnost – Primjer usluge poziv na čekanju   Poziv iniciran delayed

offer INVITE porukom sa A strane

  Drugi INVITE je B strana koja inicira poziv na čekanju

  Treći INVITE je B strana koja prekida poziv na čekanju i vraća poziv u aktivno stanje

  Napomena – snimano na B strani, RTP paketi na glazbu na čekanju nisu vidljivi


VoIP interoperabilnost – RTP

  Neslaganje oko kodeka   Kako dolazi do nesporazuma?

  SDP odgovor sa više kodeka, ali različiti prioriteti u biranju   CUBE (Cisco Unified Border Element) sam pregovara o kodecima,

a CUCM koristi ograničenja u kodecima između regija   Moguće posljedice

  Prekid poziva   Jednosmjerna čujnost ili potpuni prekid čujnosti   Nepotrebno korištenje transkodera

  Rješenja:   Ograničiti se na zajednički nazivnik prilikom izbora kodeka – obično

g711a   Transkoderi i/ili MTP konverzija g711a <-> g771u   Markiranje odlaznih poziva iz regija u kombinaciji sa Delayed offer

(komplicirano)


VoIP interoperabilnost - Primjer

  Česta situacija: mala količina “zalutalih” RTP paketa


VoIP interoperabilnost - Koncepti

  Koncepti iz VoIP “otoka” koji se ne translatiraju dobro VoIP sa kraja na kraj

  CUCM uvijek želi puštati glazbu na čekanju   Što ako i VoIP core želi puštati glazbu na čekanju?   Rješenje 1: MTP (Media Termination Point) – CUCM sam pušta

glazbu na čekanju, VoIP core uopće nije svjestan usluge   Rješenje 2: SIP manipulacija

  CUCM “vidi” SIP trunk kao još jedan VG i ne očekuje promjene voice kodeka   Glazba na čekanju - pregovor o kodecima neovisan o inicijalnom –

potencijalno sa različitim rezultatom od inicijalnog pregovora   Rješenja: transkoding – nove verzije CUCMa i CUBEa podržavaju

aktivaciju transkodera nakon početka sesije


VoIP interoperabilnost - DTMF

  DTMF (Dual Tone Multi Frequency) - potencijalni problemi   INBAND prijenos DTMFa ne radi dobro sa svim kodecima (kodeci sa

visokim stupnjem kompresije ne prenose dobro kompleksnije tonove)   Rješenje: koristiti NTE

  Starija oprema koja ne podržava sve metode (npr. VG248 ne podržava NTE)   Rješenje: MTP za konverziju metoda slanja DTMFa

  CUCM uvijek koristi 101 za NTE za DTMF ( i 100 za NSE)   Potencijalni problem – ako druga strana koristi kodek koji dinamički

određuje tip RTP paketa ( npr. G.726), a on se ručno namjesti na 101

  Rješenje 1 : ručno fiksirati kodeke koji zahtijevaju dinamičko određivanje tipa na neki broj u rasponu 96-127, osim 101.

  Rješenje 2 : CUBE od verzije 15.1 podržava “translaciju” NTE brojeva


FoIP (Fax over IP)

  Usluga orijentirana prema kanalu, krajnje neprikladna za prijenos preko IP mreže

  Protokoli za prijenos faksa   Fax passthrough: G.711a i G.711u   Fax relay: T.38

  Iniciranje “faks mod” rada   Detekcija – faks tonovi

  cng, ced, ans, /ans, preambula   Prvi bi trebao reagirati odredišni VG, u praksi ima svih kombinacija

  Parametri: fiksiran dejitter buffer, ugašen VAD (Voice Activation Detection) i algoritmi za smanjenje jeke (echo cancelation)

  Metode iniciranja   SIP REINVITE   NSE poruke – Cisco proprietary   Proizvoljna promjena kodeka (!?)


FoIP (Fax over IP) – Preporuka za konfiguriranje korisničkih faks uređaja

  Isključiti ECM (Error Correction Mode).   Isključenje ove opcije je ključno za povećanje otpornosti transmisije na

gubitak paketa. U suprotnom (ukoliko je funkcija uključena), a terminirajući faks uređaj nije u stanju primiti stranice bez pogrešaka, faks transmisija može biti neuspješna.

  Podešavanje maksimalne brzine u TX/RX smjeru na 14400 bps (V.17 modulaciju, te po potrebi smanjiti na 9600 (v.29).   Smanjenje brzine utječe na vrijeme trajanja slanja fax poruke.

Smanjenjem brzine izbjegavaju se upotrebe SG3 (v.34 33600 bps brzine rada).


FoIP (Fax over IP) – Fax passthrough   Fax passthrough G.711a ili G.711u

  Svi voice gatewayi podržavaju fax passthrough   Ne podržavaju svi pregovor SIP porukama   Primjer: NSE poruke

  Ne zahtjeva kompleksan uređaj   Protokol je osjetljiv na kvalitetu linka   Brzinu limitiraju DSPovi u VGovima

  Cisco ATA 186 je vrlo čest uređaj, Cisco preporuka je maksimalno 14400 ili bolje 9600 kao maksimalnu dopuštenu brzinu slanja faksa

  Komplicirana analiza, potreban specijalan softver za analizu audio snimki


FoIP (Fax over IP) – Fax passthrough primjer

  Primjer signalizacije za pregovor oko fax passthrough metode slanja faksa

  Na slici:   Uspostavi se voice poziv   Voice gateway A detektira cng, ced

faks tonove   Šalje reinvite sa faks protokolom

  U praksi možete očekivati i A stranu i B stranu da šalje reinvite


FoIP (Fax over IP) – Fax passthrough

  Na primjer: Uspješno slanje faksa sa fax passthrough iako signalizacijski nije inicijaliziran faks mod


FoIP (Fax over IP) – T.38

  T.38   Podržava ga većina voice gatewaya

  Cisco ATA 186 ne podržava, VG248 podržava T.38, ali ne i SIP pregovor

  VG224, Cisco ATA 187 podržavaju T.38   Manje osjetljiv na kvalitetu linka

  Može se podesiti koliko se redundantnih paketa šalje: 1, 2 ili 3   Zahtjeva manje propusnosti na linku (ovisno o redundanciji) i to samo

u jednom smjeru   Lakši za analizirati (wireshark)

  U pravilu je lako moguće utvrditi koji element u mreži ne radi dobro   Zahtijeva kompleksniji softver na uređajima (jači procesor, više

memorije)   Algoritamski je svjestan faksa – mora biti svjestan točke u kojoj se

dogodio reinvite   Skloniji bugovima zbog kompleksnosti


FoIP (Fax over IP) – T.38 primjer

  T.38 sesija – pregovor


FoIP (Fax over IP) – T.38 primjer

  T.38 sesija – slanje jedne stranice (nastavak sa prethodnog slidea)


FoIP (Fax over IP) – T.38 – primjer neuspjelog slanja više stranica

  T.38 neuspjelo slanje faksa, B strana prestala odgovarati (parcijalan prikaz snimke prometa, ne ide od početka sesije)

  Uspješno poslane tri stranice

  U jednom trenutku B strana prestaje odgovarati na poruke


FoIP (Fax over IP) - Testiranje

  Metodologija testiranja   Sve kombinacije uređaja   Analiza signalizacije u snimkama

prometa   Minimalno 10 stranica po testu   Stress testovi

  Višestrukim paralelnim slanjem fakseva

  Izrazito velika količina stranica poslana u jednoj sesiji

  Korištenje kompleksnih stranica


SIP Trunking failover

  SIP trunk   nema registracija   tretira se kao gateway

  Metode failovera   IP baziran failover

  U slučaju pucanja jednog linka SIP sloj nije svjestan prekida   SIP bazirani failover

  U slučaju pucanja jednog linka SIP sloj je svjestan prekida – moguće su dodatne usluge


SIP Trunking failover


SIP Trunking failover – SIP OPTION

  SIP bazirani trunk failover   SIP OPTION PING (ne koristi se SIP KEEPALIVE)   Poruke se šalju po svim trunkovima   CUCM zna odgovarati na OPTION poruke, ali ih ne šalje   CUBE zna i slati OPTION poruke i odgovarati na njih


SIP Trunking failover – Primjer

  Primjer topologije


SIP Trunking failover - Primjer

  Topolgija iz perspektive trunkova


SIP Trunking failover – Primjer scenarij 1

34

  Scenarij: ispad linka između CUCMa i korisničkih CUBEova, odlazni pozivi

  CUCM čeka 5 minuta prije nego utvrdi da je CUBE1 nedostupan

  Unutar 5 minuta svi pozivi prema van kasne 8 sekundi (parametar Retry count for SIP INVITE = 3)

  CUCM “čeka” 8 sekundi da mu se CUBE1 javi, a zatim preusmjeri poziv na CUBE2

  Nakon 5 minuta prestane slati pozive prvo na CUBE1, nego sve pozive odmah upućuje na CUBE2

16.3.2011 Kosta Pribić - Izazovi integracije Cisco Unified Communications Managera u all-IP mrežama


  Scenarij: ispad linka između CUCMa i korisničkih CUBEova, dolazni pozivi

  Nakon što mu CUCM prestane odgovarati na SIP OPTION poruke, CUBE1 čeka 60 sec zatim stavi dial-peer u stanje Busy out i na sve dolazne pozive odgovara sa 404 Not Found bez kašnjenja

  Unuter jedne minute svi pozivi kasne 8 sekundi prije nego CUBE vrati poruku 408 Timeout

  8 sekundi je definirano sa sip-ua retry INVITE = 3

  U oba slučaja poziv će se vratiti jedan “korak” unazad i pokušati drugim putem



  Scenarij: ispad linka između dva CUBEa   CUBEovi provjeravaju odredišta svojih dial-

peerova sa SIP OPTION porukama i očekuju 200 OK poruku kao odgovor

  Timer je podešen na 60 sekundi, ako unutar 60 sekundi nema odgovora odgovarajući dial-peer se stavlja u stanje busy out

  CUBE nastavlja slati SIP OPTION iako je dial-peer u busy out stanju, kada počne ponovo dobivati odgovore čeka 60 sekundi i ponovo aktivira dial-peer

  Ako link ispadne, a poziv dođe prije nego što je dial peer u stanju busy-out CUBE čeka 8 sekundi pa vraća 408 Timeout poruku.



  Scenarij: ispad linka između CUBEa i Core mreže

  Odlazni pozivi se ponašaju kao i između dva CUBEa

  Dolazni pozivi 60 sekundi nakon ispada prelaze na trunk E bez kašnjenja

  Unutar 60 sekundi prvih 5 poziva propada sa timeoutom 30 sekundi

  6. poziv ili prvi poziv nakon 60 sekundi će preći na E trunk bez kašnjenja


SIP Trunking failover - Kašnjenja

Vrijeme nakon ispada linka

Smjer poziva

Link koji ispada

CUCM - Korisnik CUBE

Korisnik CUBE – CSP

CUBE

CSP CUBE – CSP CORE

< 1 min

Korisnik->CSP

*<5 min, ne <1min 8 sec, za svaki

poziv

8 sec za svaki poziv

8 sec za svaki poziv

CSP->Korisnik

8 sec, za svaki poziv

8 sec, za svaki poziv

30 sec timeout za

prvih 5 poziva, neće

proći

>1 min

Korisnik->CSP

* Nakon 5 minuta, ~0 sec

~0 sec ~0 sec

CSP->Korisnik ~0 sec ~0 sec ~0 sec

38

Kašnjenja u slučaju pucanja jednog linka


SIP Trunking failover – Različite numeracije

  Failover između lokacija sa različitim numeracijama   Prebacivanje dolaznih poziva sa lokacije A na lokaciju B   Lokacije A i B imaju različite numeracije

  Primjer:   Lokacija A: Zagreb, pozivni 01   Lokacija B: Split, pozivni 021   Pozivi za Zagreb idu kroz trunk u Zagrebu, ali u slučaju ispada trunka

u Zagrebu pozivi se preusmjeravaju na trunk u Splitu te prolaze kroz internu mrežu korisnika sve do telefona u Zagrebu



40

Poziv za broj u Zagrebu 01 1234567



41

Poziv za broj u Zagrebu 01 1234567 u slučaju ispada trunka u Zagrebu se preusmjerava u Split


Zaključak

  VOIP interoperabilnost ovisi u mnogo većoj mjeri o krajnjim uređajima nego u TDM svijetu zbog velikog raspona tehničkih mogućnosti konfiguracije te implementacija specifičnih za pojedine proizvođače

  Testiranja interoperabilnosti u VoIP okruženju sa više proizvođača su vrlo bitna za uspostavu kvalitetnog rješenja:   Problemi sa interoperabilnošću su često specifični za pojedine

korisničke mreža   Transkoderi su ponekad jedino rješenje za rubne slučajeve

  FoIP slično VoIPu u velikoj mjeri ovisi o faks uređajima i VGovima, preporuka je smanjenje brzine zbog osiguravanja stabilnosti rada faks uređaja


Zaključak (nastavak)

  Preporučujemo SIP TRUNKING sa SIP OPTION baziranim failoverom budući da CSPu omogućuje da kontrolira i usmjerava pozive kada dođe do prekida, u odnosu na IP bazirani failover gdje se na nivou SIPa ne zna ta informacija

  Opisana rješenja testirana su koristeći CUCM i CUBE Cisco opremu   nove verzije donose funkcionalnosti koji rješavaju specifične probleme

sa interoperabilnošću


Dodatak – korisni linkovi

  Dobro mjesto za početi čitati o SIP protokolu   http://www.voip-info.org/wiki/view/SIP

  Popis svega što se može pojaviti u SDP sa referencama na odgovarajući RFC   http://www.iana.org/assignments/sdp-parameters

  IETF http://www.ietf.org   RFC 3261 – SIP općenito   RFC 2833, RFC 4733 – DTMF

  Wireshark wiki   http://wiki.wireshark.org/RTP_statistics   http://wiki.wireshark.org/VoIP_calls


16.3.2011 Kosta Pribić - Izazovi integracije Cisco Unified Communications Managera u all-IP mrežama 45

Hvala na pažnji.

Date post:	28-Oct-2019
Category:	Documents
Upload:	others
View:	0 times
Download:	0 times

Kosta Pribić, dipl. ing. - cisco.com · Prezentacija diskutira tehnička rješenja i izazove, ne...

Documents