Newsgroup: it.tlc.telefonia.voip
Titolo: SIP, htb, openvpn...

Ho due sedi collegate con una VPN fatta con openvpn, traffico
priorizzato con tc (HTB, 
http://luxik.cdi.cz/~devik/qos/htb/
), la banda
è sufficiente e non particolarmente satura.
Su questa 'linea' faccio passare del traffico VoIP, codec GSM, ma la
qualità è scarsa, classico effetto 'a salti'...
Contemporaneamente ho il mio telefono VoIP connesso al sistema di casa,
senza VPN, e a me sembra decisamente meglio.
A parte eventuali 'sensazioni', do per scontato che la fase di codifica
e decodifica di openvpn aggiunge un overhead, ma non capisco se e come
questa possa comportare effettivi problemi.
Nel dettaglio: ho abilitato la compressione in Openvpn, è chiaro che in
questo caso sicuramente aggiunge un overhead inutile, ma mi chiedo se
in qualche maniera c'è anche modo di evitare la cosa, ovviamente a
parte creare un tunnel openvpn a parte, maggiormente priorizzato, per
questo.
-- 
  ...noi leggiamo il Vangelo come se non avessimo soldi,
  e usiamo i soldi come se non conoscessimo nulla del Vangelo...
						(un Gesuita inglese)

 priorizzato con tc (HTB,
http://luxik.cdi.cz/~devik/qos/htb/
), la banda

perdonami se ti rispondo con altre domande, ma nel tuo post non
specifichI il tipo di trunk voip (sip, IAX2 od H323)..
Inoltre, non ricordo dove, ho letto che il trasporto RTP (solitamente
UDP, lossy) perde la sua peculiarità di real.time nel mentre è
pacchettizzato in TCP (usato per trasporto lossless, senza perdita
d'informazione).
Credo che nel tuo caso sia utile scindere i dati dallo stream RTP
facendo passare quest'ultimo per la rete in formato UDP..
Ad maiora..

Mandi! redoctober71
  In chel dì si favelave...
r> perdonami se ti rispondo con altre domande, ma nel tuo post non
r> specifichI il tipo di trunk voip (sip, IAX2 od H323)..
Hai ragione, semplice SIP.
r> Credo che nel tuo caso sia utile scindere i dati dallo stream RTP
r> facendo passare quest'ultimo per la rete in formato UDP..
Anche su questo hai ragione, ma la VPN è in UDP mode...
-- 
  If SMB was an animal it would go wolf and most people would have shot it
  or put it down humanely.				(Rod Boyce)

 
1. Spiegami perché fai passare del traffico UDP attraverso una VPN... Se 
hai bisogno di sicurezza, usa SRTP, oppure un trunk punto-punto in IAX.
2. Da quello che dici (il tuo telefono verso casa fuori dalla VPN 
funziona meglio) è ovvio che l'elaborazione a più stadi che introduci 
causa degli /accodamenti/ di pacchetti. Se il tempo che un pacchetto UDP 
ci mette a raggiungere l'endpoint finale è più di 250 millisecondi 
*dimenticati* il VoIP. Per il VoIP non serve banda - non più di quella 
che una buona ADSL offre - ma velocità punto-punto (basso ping time), 
affidabilità (possibilmente zero jitter), *nessun* lag (figurati che fa 
differenza tra avere l'ADSL in modalità FAST o INTERLEAVED).
3. Il codec GSM ha un rapporto qualità/banda uguale al g711a, cioè meno
banda = meno qualità, ed è più /processor intensive/ che il g711. Se hai 
dei limiti sulla banda disponibile, compra delle licenze g729.
4. Sei sicuro di avere configurato correttamente il QOS? Come stai 
discriminando il traffico VoIP dal resto? Stai marcando i pacchetti SIP 
ed RTP, o prioritizzi il traffico UDP sulle porte SIP e sul range di 
porte RTP?
Io ho diversi uffici con server Asterisk interconnessi tra di loro, 
senza VPN, QoS, ed altre diavolerie: un trunk IAX con autenticazione MD5 
e un pinhole nel router-firewall da entrambi i lati sulla porta 4569 
aperto solo all'IP dell'altra connessione.
Tutto il traffico (segnalazione e voce) viaggia in multiplex sul trunk 
IAX, e con una ADSL con 512 Kb di upstream passano fino a 20 
conversazioni in g711 senza difetti/artefatti.
-- 
Bodincus - The Y2K Druid
************************
Law 42 on computing:
Anything that could fail, will break at the worst possible mom%*= ?@@
# Access Violation - Core dumped
# Kernel Panic

 conversazioni in g711 senza difetti/artefatti.
:O
Sei sicuro sulle 20 conv. contemporanee? Io ho difficoltà a farne 
passare 25 su una HDSL da 2 Mbit/s !
-- 
Traveller, not tourist!
www.inter-rail.it

 passare 25 su una HDSL da 2 Mbit/s !
Perché hai scelto l'hdsl sbagliata :PPP
e ben ti sta! :)
Però anche a me pare un po' tirata per i capelli pretenderne 25 su
512Kbps, perché sono 20Kb a chiamata saturando tutto. Mah...
ciao :)
Gabriele

 512Kbps, perché sono 20Kb a chiamata saturando tutto. Mah...
manco il gsm scende a 20kb :/


 
Più che sicuro, ricordati che sto parlando di un trunk IAX punto-punto, 
non SIP+RTP da/verso multiple destinazioni.
IAX fa multiplex di dati + audio sullo stesso stream e trasmette audio 
solo quando è necessario, non c'è uno stream RTP costante per ogni 
conversazione su porte random all'interno del range che assegni tu. 
Tutto passa sulla porta 4569, per cui il carico di lavoro sui router e 
sulle ADSL è concentrato su un unico flusso di dati.
Certo, 20 conversazioni SIP + RTP contemporanee verso differenti 
destinazioni possono essere problematiche, ma i problemi non dipendono 
solo dalla larghezza di banda: a volte la capacità di calcolo di un 
routerino da 30 euro non è eccelsa, e - oltretutto - UDP è un protocollo 
per definizione /best effort/ (lo faccio se posso) per cui non sono 
sorpreso se qualche router /nicchia/ un po' e ritarda a forwardare un 
pacchetto UDP.
Posso garantirti che con IAX funziona... Se non funzionasse sarei nei 
guai, uno dei miei clienti è uno studio di avvocati con tre sedi. Quelli 
ci mettono un attimo a crocifiggermi se ci sono dei problemi!


Mandi! Bodincus
  In chel dì si favelave...
B> 1. Spiegami perché fai passare del traffico UDP attraverso una VPN... Se 
B> hai bisogno di sicurezza, usa SRTP, oppure un trunk punto-punto in IAX.
Eh... perchè il routing è complicato e questo è il modo più semplice
per farlo... ;)))
B> 2. Da quello che dici (il tuo telefono verso casa fuori dalla VPN 
B> funziona meglio) è ovvio che l'elaborazione a più stadi che introduci 
B> causa degli /accodamenti/ di pacchetti. Se il tempo che un pacchetto UDP 
B> ci mette a raggiungere l'endpoint finale è più di 250 millisecondi 
B> *dimenticati* il VoIP. Per il VoIP non serve banda - non più di quella 
B> che una buona ADSL offre - ma velocità punto-punto (basso ping time), 
B> affidabilità (possibilmente zero jitter), *nessun* lag (figurati che fa 
B> differenza tra avere l'ADSL in modalità FAST o INTERLEAVED).
Sulla rete pubblica le due sedi hanno un RTT medio nelle ultime 10 ore di
114ms, un tasso di perdita di pacchetti attorno allo 0,28%.
Chiaramente, da dentro la VPN il RTT aumenta di qualche millisecondo,
comunque meno di 10.
B> 3. Il codec GSM ha un rapporto qualità/banda uguale al g711a, cioè meno
B> banda = meno qualità, ed è più /processor intensive/ che il g711. Se hai 
B> dei limiti sulla banda disponibile, compra delle licenze g729.
Provato con G729, mi pare che sia assolutamente la stessa cosa.
B> 4. Sei sicuro di avere configurato correttamente il QOS? Come stai 
B> discriminando il traffico VoIP dal resto? Stai marcando i pacchetti SIP 
B> ed RTP, o prioritizzi il traffico UDP sulle porte SIP e sul range di 
B> porte RTP?
Avendo fatto io lo script con tc e htb, sicuro è una parola grossa, ma
sono anni che lo uso e sono 'abbastanza sicuro'.
Marco tutto il traffico con iptables (e ip_conntrack_sip) e poi lo
classifico con tc.
B> Io ho diversi uffici con server Asterisk interconnessi tra di loro, 
B> senza VPN, QoS, ed altre diavolerie: un trunk IAX con autenticazione MD5 
B> e un pinhole nel router-firewall da entrambi i lati sulla porta 4569 
B> aperto solo all'IP dell'altra connessione.
B> Tutto il traffico (segnalazione e voce) viaggia in multiplex sul trunk 
B> IAX, e con una ADSL con 512 Kb di upstream passano fino a 20 
B> conversazioni in g711 senza difetti/artefatti.
Eh, magari potessi usare IAX... ;(((
-- 
  Quante persone e quanti cuori, quanti colori
  al posto di quel grigio quante novita`
  c'e` un'altro tipo di futuro che aspetta, Capata`z	(F. De Gregori)