Newsgroup: it.tlc.telefonia.voip
Titolo: Qualità telefonate con PBXES

In questi giorni da quando sono riuscito a configurare Messagenet ho
notato che la qualità delle chiamate fatta attraverso PBXES non è
uguale a quelle fatte collegando l'ATA direttamente al provider VOIP.
Influisce il fatto di selezionarre www4/www2 anzichè www nella time
zone?
Il risultato del ping è naturalmente molto diverso:
www.pbxes.org
       72ms
www.pbxes.com
    254ms
www2.pbxes.com
  219ms
www4.pbxes.com
  195ms
In famiglia si lamentano dell'effetto eco che si ottiene attraverso
PBXES. Se collego il mio c450ip direttamente invece nessuno si lamenta.

 PBXES. Se collego il mio c450ip direttamente invece nessuno si lamenta.
Come mai nessuna risposta?

 Come mai nessuna risposta?
Dopo soli 20 minuti?
-- 
Davide Granzotto 

 wrote in message

Pensavo fosse un argomento interessante. Non credo di essere il solo
ad avere notato questo problema ed a cercare una soluzione valida per
tutti.

 tutti.
Il motivo mi sembra semplice: aggiungi un "hop" nel routing dei 
pacchetti voce con gli annessi problemi di latenza.
La soluzione: usa un PBX locale.


Certo, ma non mi è chiaro il meccanismo delle time zone. Io l'ata lo
registro su 
pbxes.org
 ma la time zone punta su 
www4.pbxes.com
.
Questo fa qualche differenza?. Se si conviene spostare tutto su
www0.pbxes.org
 dove la latenza è circa 68-70 contro gli oltre 200 dei
www2 e www4 americani. Ovviamente si rinuncia ad utilizzare i provider
BETAMAX/FINAREA a scapito della qualità.

 Questo fa qualche differenza?. Se si conviene spostare tutto su
Non conosco l'argomento e magari dico cavolate. Ma tutti gli alias che 
dici si risolvono con lo stesso ip.


Ahemm... forse e dico forse, c'e' differenza tra una macchina che
risponde da Milano, una macchina che risponde da N.Y. e una macchina
che risponde da Honk Kong.
Dipende non solo dalla distanza ma dal routing.
Ad esempio, 
http://www.easynews.com
 un provider di servizi NNTP
permettte di variare il routing ai loro clienti.
Si fanno delle prove e in base ai ping, si puo' cambiare routing.
Il tedesco non lo fa. Una possibilita' in piu' per gli investitori
italiani che farebbero bene a prendere in considerazione l'idea di
fornire servizi analoghi al pbxes tedesco.
Ma poi... scusa... se e' Finarea che ti serve... io ho speso 120 Euro,
perche' non fai altrettanto?
Prendi altri 3 amici e dividete in 4 la spesa. Fanno 30 Euro/anno a
testa.
Ho preso carta e penna e poi anche la calcolatrice: fanno proprio 30
Euro/anno a testa.
Alessandro D'Arpini

 Alessandro D'Arpini
No, come sai non ci tengo a FINAREA, anzi. Perciò tornerò a mettere la
timezone su www0. Ma mi chiedo se quando chiamo con Messagenet l'eco è
dovuto a questo problema o a qualcosa d'altro.
Per chiedere a degli amici questo piccolo investimento voglio prima
capire: non vorrei fare brutte figure. Sai le famose mogli con le
padelle che si arrabbiano perchè sentono l'eco quando chiamano la
mamma che abita 100 mt. più in là di casa tua!!!!

 PBXES. Se collego il mio c450ip direttamente invece nessuno si lamenta.
Prova ad attivare l'audio bypass in tutte le schermate in cui appare. 
Potrebbe aiutarti proprio a bypassare PBXES (i terminali instaurano una 
connessione diretta).
-- 
Davide Granzotto 

 wrote in message

Intendi non solo nei tronchi ma anche negli interni ovvero negli
interni collegati agli ata. Ci proverò anche Alessandro ha sempre
sconsigliato di farlo.
Ma sperimentare in questo caso non costa nulla.

 connessione diretta).
Grazie Davide ecco a cosa serve il bypass, io li ho attivati di 
"routine" ma non mi sono mai chiesto a cosa servivano.
Tornando alla qualità delle chiamate
Sono ormai mesi che quando chiamo qualcuno invece di dire pronto chiedo 
se mi sentono bene. Sicuramente sono fortunato o magari non sto' 
utilizzando banda per scaricare qualche film.... ma la risposta è sempre 
si ti sento bene.
Penso che i motivi di una cattiva comunicazione siano molteplici alcune 
soluzioni sono state date:
1)aggiungi un "hop" nel routing dei pacchetti voce con gli annessi 
problemi di latenza.
2)Usa un PBX locale.
3) 
http://www.easynews.com
 un provider di servizi NNTP
permettte di variare il routing
Comunque Freekess io non posso aiutarti
Utilizzo Messagenet - vira - skipho - voipstunt - voipcheap e la 
differenza se esco dal mio Fritz o se esco da PBXES non la si nota.
-- 
by kandinsky62

 permettte di variare il routing
Precisazione doverosa, a scanso di equivoci:
easynews NON e' un servizio diverso dalle News, eh!
I loro clienti possono cambiare il routing in base ai risultati dei
loro ping ma questo serve UNICAMENTE per i servizi di easynews e
BASTA.
E' un servizio di News, USENET insomma, di tipo Premium.
Qualcosa che in Italia i providers NON possono offrire perche' non
hanno soldi per farlo. Almeno non come lo fa easynews oppure altri
fornitori di servizi analoghi. Punto.
Capirai.. da noi nemmeno sanno cosa sia USENET figurati se pagano 8
Euro/mese per un servizio Premium.
Qualcuno arriva a stupirsi se non puo' telefonare aggratis piu' di 4
minuti e 58 secondi...
Siamo cenerentole e pure provinciali.
Alessandro D'Arpini


Io i 3 amici che hanno voip non li ho e non riesco a sfondare il muro di 
indiffernza.. non vedono risparmi economici notevoli a fronte 
dell'investimento...
uso finarea con pbxes su ww4 come timezone...
ma ho settato 
pbxes.org
 senza niente nell'ata e sembra andare bene...
boh...
provate e fate sapere
Ciao
Daniele 

 ha scritto nel messaggio 
news:1170628829....@h3g2000cwc.googlegroups.com...

L'ho notato anch'io un piccolo peggioramento di qualità rispetto al 
collegamento diretto, probabilmente dovuto al giro "piu' lungo" che il 
collegamento deve fare. Comunque anche io ho fatto una prova molto veloce, 
non avendo ancora necessità di pbxes ho provato solo per curiosità. 

 Ma sperimentare in questo caso non costa nulla.
Infatti. Al momento non ho visto nessun effetto collaterale, ma come si sa 
le cose possono cambiare da caso a caso.
-- 
Davide Granzotto 

 uguale a quelle fatte collegando l'ATA direttamente al provider VOIP.
Ma PBXES si prende tutto il traffico da e verso il provider VoIP?
Cioè: tutti i pacchetti fanno il giro:
Softphone/ATA <-> PBXES <-> provider VoIP
oppure subito dopo che la connessione si è instaurata si passa ad un
contatto diretto softphone/ATA <-> provider VoIP?
Credo la seconda, se no quelli di PBXES dovrebbero avere una banda
enorme, comunque chiedo delucidazioni ai più esperti.
Ma se fosse valida la seconda ipotesi non ci dovrebbero essere
peggioramenti...
-- 
Ciao, Lurkos

 peggioramenti...
Dipende della impostazioni Audio Bypass, come ho detto in un mio reply su 
questo thread.
-- 
Davide Granzotto 

 vede il re-invite su Squillo.
Sarebbe come mettere canreinvite=yes su Asterisk? 

Davide Granzotto ha scritto:

Questa sembra essere la teoria esatta della quale si trova traccia
anche nel forum di PBXES. Ecco che allora se audio bypass è settato a
no ed il giro fosse   Softphone/ATA <-> PBXES <-> provider VoIP allora
pingare il server PBXES americano a 225 o quello tedesco a 35-70 a
seconda della linea fa una bella differenza in termini di latenza.
Proprio questo è il mio dubbio .....

 Sarebbe come mettere canreinvite=yes su Asterisk?
Presumo di sě, ma non ho avuto modo verificarlo sul campo.
-- 
Davide Granzotto 

 ha scritto nel messaggio 
news:eq7m77$vpf$1...@nnrp.ngi.it...

Canreinvite=yes *only* works if all devices are on the same side of the NAT, 
the
outside or the inside.
If one device is on a different side of a NAT device than another phone
or Asterisk, you can't allow re-invites for that device.
Let me explain:
Phone A -------------> Asterisk -----------------> phone B
Phone A calls phone B. The first thing you have to remember is that Asterisk
is *not* a SIP proxy, it's a SIP PBX. So phone A sends an invite to 
Asterisk.
Asterisk starts a *new* SIP dialog and sends an invite to Phone B.
If Phone B accepts the call ("answers"), it sends an "200 OK" sip message
to Asterisk. Asterisk sends a "200 OK" SIP message to phone A. We now have
*two* SIP calls, or dialogs, that are bridged through Asterisk.
The natural behaviour for the Asterisk SIP channel in this case is
to get a feeling of "Hey, these two phones are using me just for transport
of bits between themselves. Why not get out of the loop and let them
exchange these bits directly with each other? I can use the spare CPU
cycles for something more meaningful than shipping these bits..."
So, in order to get out of this meaningless position, Asterisk checks if
the phones are compatible. If they support the same codec, if they
can talk to each other. If *one* of them have canreinvite=no
or something else that stops a direct audio relationship from phone A to B,
Asterisk stays in the middle of things, shipping bits between the phones
(the audio stream).
If they are compatible, Asterisk sends a new SIP INVITE to both of the
phones, redirecting the media streams for the current calls to each
other. This is called a Re-INVITE, an INVITE where we change media
for an existing SIP dialog, not trying to start a new call.
This works perfectly well if all phones are compatible and we have
the network configured so that they can talk full duplex to each other.
If one is behind a NAT, they can't. If that's the case, we'll only
get one audio stream, from the phone on the inside to the one on the
outside. That's why we want to set canreinvite=no to make sure
Asterisk doesn't even try to re-INVITE.
------------------
Executive Summary:
canreinvite=no in a [peer] configuration makes Asterisk stay
in the middle of the media stream. This is the "safe" setting,
but remember it makes your CPU always handle the media stream.
Regards,
/Olle

 > Presumo di sì, ma non ho avuto modo verificarlo sul campo.

Chiarissime queste istruzioni.
Il consiglio è quindi quello di tenere audio bypass a no, senza quindi
che asterix attivi il re-invite. In questo modo PBXES gestisce lo
streaming audio tra i due telefoni e garantisce la perfetta
compatibilità della connessione. Tuttavia i server si sovraccaricano e
la banda si riduce.
Al contrario con audio bypass configurato su si la connessione avviene
in modo diretto dopo il re-invite che viene attivato da pbxes.
Naturalmente i problemi nascono quando i due telefoni ed il relativo
sw non usano gli stessi codecs, ovvero non sono compatibili.
Stasera ho provato a mettere yes sia sull'ata che sul tronco ed a fare
una telefonata. Non mi pare di sentrire particolari miglioramenti.
Ho provato a mettere in dmz l'ata ed ora farò qualche altra prova.

 outside or the inside.
Uhm ... di questo non ne sarei molto sicuro.
Purtroppo non ho potuto approfondire, ma in uno dei miei telefoni ho trovato 
questo:
re-Invite:oIP(
217.195.32.11:39962
),nIP(
88.149.128.60:21066
)
Il primo IP è PBXES, il secondo Squillo.
-- 
Davide Granzotto 

 Ho provato a mettere in dmz l'ata ed ora farò qualche altra prova.
Dovresti provare ad analizzare il log per vedere se effittivamente ci sono 
dei cambiamenti. Magari il tuo ATA non supporta neppure il re-invite ...
-- 
Davide Granzotto