Newsgroup: it.comp.reti.cisco
Titolo: Voice over IP

Qualcuno ha già implementato con successo Voice-over-IP con router
Cisco su linee NON-CDN, intendo dire le nuove proposte TeleCom
DataWan, HyperWay, ecc.?
A me risultano esserci grossi problemi dovuti alla latenza non
garantita e problemi simili, ma volevo sentire altre opinioni PRIMA di
proporlo a qualche cliente e poi sbattere il naso su qualità non
accettabili.
Claudio



io sono a favore dell'ipotesi problemi.
in realta' ho un cliente che ha una hyperway su tutto il territorio
nazionale, sul quale fa voip (lo fanno i centralini tra loro) e non
lementa problemi. media di 5 user/sede con una 15ina di sedi da cui ogni
utente fa voip/tn5250/rdp. sembra funzionare tutto molto bene, persino
senza qos. vedremo a settembre (la rete sta uscendo ora dallo startup.
il cliente la ha scelta ed io sto cercando di supportarlo per ottenere i
risultati migliori, e fino ad ora devo dire che i risultati sono
soddisfacenti ...
un mayhem con il mal di stomaco
-- 
 Diplomazia: dire bravo cagnetto fino a che non trovi il bastone. 
 Cisco  FAQ: 
http://mayhem.oltrelinux.com/icrc
 SPP  wpage: 
http://www.spippolatori.com
 Key on 
pgp.mit.edu
 ID C7393613


Parto con una banalità, che però è una delle prime cose che insegnano a chi
si avvicina al voip .... la qualità dipende da quello che si aspetta il
cliente, se tu riesci a convincerlo che deve confrontare il voip alla
qualità gsm vivrai molto tranquillo, se invece il cliente prende come
paragone il suo stereo surround 5.1 sei fritto.
Detto questo posso riportarti delle mie esperienze su datawan telecom (frame
relay) dove ho clienti mediamente soddisfatti, una di queste installazioni è
in piedi da quasi 3 anni ed ha subito una migrazione da cdn senza traumi da
parte del cliente; va detto che si tratta di un cliente che non ne fa un uso
esasperato e soprattutto non è un rompiballe, ma non è nemmeno babbo natale,
per cui se non  si è mai lamentato vuol dire che funziona bene.
In tuoi dubbi sono comunque legittimi, in Italia ci sono poche offerte in
termini di linee (in teoria quasi solo mpls) che hanno caratteristiche che
aziende come Cisco considerano sufficienti per il voip, ma tant'è .... ci
sono molte installazioni in giro che funzionano.
Ho addirittura un cliente che è soddisfatto del suo voip tra due adsl su
internet, si tratta ovviamente di una specie rara che a fronte di un bel
risparmio è disposto a tollerare qualche problema inevitabile di qualità.
Ciao,
        Tosh.

Come IOS che features avete utilizzato? Voice-over-IP č
necessario/sufficiente anche quando č il centralino a fare il VoIP?
E qualche "trucco" particolare nella configurazione?
Intendo, oltre al solito "IP rtp header-compression" avete usato il
"multilink" con "IP RTP priority" o "IP RTP reserve" e/o controllo
frammentazione?
Cioč, la stessa configurazione utilizzata con le linee CDN ?

 Cioè, la stessa configurazione utilizzata con le linee CDN ?
Su FR ed ATM le cose cambiano radicalmente ed in teoria si farebbero molto
più complicate (almeno in teoria), ma come dicevo nel post precedente, ho
clienti soddisfatti con il voip configurato su linee FR senza nemmeno la
priorità.
In realtà la priorità e la frammentazione sono meno utili nel caso, a dire
il vero piuttosto raro, che il traffico dati sia quasi esclusivamente di
tipo telnet, come capita ai miei clienti soddisfatti; se hai traffico molto
più pesante, come ftp o netbios, non ti conviene rischiare e devi
concentrarti sui meccanismi di priorità e frammentazione dei pacchetti.
Ovviamente non sono le uniche considerazioni da fare, entrano in gioco anche
altri fattori come l'occupazione della rete (se hai una rete congestionata
non puoi fare a meno della priorità), le aspettative del cliente e chissà
quanti atri fattori..
Ciao,
        Tosh

         Tosh
GRAZIE

 sia come ??? che come memoria.


 o altro.
SI, ma la rete è mista, per cui avrò anche dei 2610/2620, forse dei
1750 e nel centro-stella un 3725; comunque sul "features nevigator" di
Cisco non dovrei avere problemi a trovare gli IOS necessari.
GRAZIE

 tempo di transito dei pacchetti?
sempre se andrai in direzione di Datawan e tutte le sedi utilizzeranno
accessi HDSL e solo con encapsulation FR di tipo 'cisco', potrai
implementare il cRTP; a quel punto la dimensione del payload diventa meno
importante.
Per payload s'intende la dimensione del pacchetto voce 'nudo', cioè prima di
essere incapsulato di RTP/UDP/IP e quindi si misura in bytes. Dal punto di
vista pratico però per i DSP, cioè i processori che codificano la fonia
analogica, il tutto si traduce in un intervallo di tempo alla fine del quale
vengono formattati i pacchetti voce, una specie di campionamento. Quindi può
capitare di trovare apparati che misurano la dimensione del pacchetto non in
bytes ma in millisecondi.
Alla fine, senza cRTP, si tratta di aumentare la dimensione del payload per
fare in modo che gli header RTP/UDP/IP, che non compressi sono circa 40
bytes, pesino il meno possibile.
In funzione del codec utilizzato il payload di default varia; con G.723 o
G.729 si consigliano circa 20 - 30 bytes, ma se vuoi abbassare i consumi
puoi arrivare a 60 o 80 bytes. Io non andrei oltre, infatti in presenza di
perdita di pacchetti o fuori sequenza, considerando che RTP non ritrasmette,
avresti dei buchi di fonia che ne degraderebbero notevolmente la qualità.
Un' ultima cosa da tenere presente in caso di bande minime sui PVC FR basse,
< di 512 o 768Kbps,  è la necessità di frammentare, ma questa è un altra
storia.
ciao
Andrea

Direi che c'è poco da aggiungere alla bellissima spiegazione di Andrea,
forse manca solo di abbassare la mtu per spezzettare il traffico pesante
tipo ftp; da qualche parte debbo avere una bella tabellina che indica il
valore da utilizzare in funzione della banda disponibile, in attesa che lo
trovo direi che non ti sbagli se la imposti a 300.
Posso aggiungere anche che CBWFQ ed LLQ sono disponibili su IP standard
mentre per il cRTP dovrebbe essere ancora indispensabile avere IP+ (a
differenza di quello che avevo scritto per errore il post precedente).
Una curiosità ... il Tc che dichiara TI per Datawan (a più riprese i loro
tecnici mi hanno garantito che è fissato ad 1 secondo), oltre ad essere più
alto del massimo teorico (125mS) è in teoria molto più elevato di quello che
dovrebbe essere il minimo sindacale per una rete Voip (Cisco consiglia
attorno al mS) .... eppure funziona.
Qualcuno ne sa qualcosa di più?
Ciao,
        Tosh.
"Andrea Gelati" <ass...@TOGLIperlaRISPOSTA.inwind.it.invalid> ha scritto nel
messaggio news:Y0a_a.239870$lK4.7...@twister1.libero.it...


         Tosh.
Scusami se il lunedì mattina sono poco sveglio: TC sta per ...? e TI
sta per TeleCom Italia?
Grazie e CIAO,
Claudio


Tc rappresenta l'intervallo di tempo tra due "burst" di dati nella
trasmissione frame relay, più è grande questo intervallo è più si ritarda la
trasmissione dei pacchetti da parte del router; nel caso dei dati non è un
problema, nel caso della voce può voler dire "sfondare" il budget di tempo a
disposizione del ricevente per ricostruire i pacchetti voce senza degrado di
qualità apprezzabile.
TI sta proprio per quello che hai detto.
Ciao,
        Tosh.

 trovo direi che non ti sbagli se la imposti a 300.
come accennavo nel mio ultimo post, il problema della frammentazione è da
affrontare solo in quei casi in cui le bande minime, o meglio i colli di
bottiglia, siano inferiori a 512 o 768Kbps. Infatti solo in quel caso la
serializzazione in presenza di pachetti lunghi può introdurre dei ritardi
preoccupanti per la trasmissione del traffico voce.
Lavorare sull'MTU, permette si di raggiungere lo scopo di diminuire il
delay, ma riduce le performance del link e aumenta i consumi di banda,
infatti si tratta di un metodo 'statico', inoltre i pacchetti 'dati'
arriverebbero frammentati alla destinazione.
Credo che sia più pulito ed indicato implementare una frammentazione Frame
Relay di tipo FRF.12, anche se dal punto di vista dei consumi di banda non
cambia molto rispetto a modificare l'MTU, utlizzando il comando 'fragment
<vedi valori sotto>'  nella 'map-class frame-relay' del traffic shapping.
64 Kbps  = 80 bytes
128 Kbps = 160 bytes
256 Kbps = 320 bytes
512 Kbps = 640 bytes
768 Kbps = 1000 bytes
Valori calcolati per frammentare ogni 10ms.
Quando serve frammentare e si vuole ottimizzare al massimo il rendimento di
un link, il metodo più efficace è quello di implementare l'LFI che richiede
il Multilink PPP che tra l'altro permette di implementare il cRTP. Quando
c'è di mezzo una rete Frame Relay occorre implementare l'MLPoFR.
ciao
Andrea
