Newsgroup: it.tlc.telefonia.voip
Titolo: One-way-audio su hold/resume o hold/transfer

Ok, e' il piu' classico dei problemi, il piu' delle volte causato
dal nat.
Peccato che il problema si verifichi anche se il pbx asterisk (1.4.32
su debian lenny) e' collegato direttamente a internet, con ip pubblico
statico attestato su interfaccia ppp. :-)
Il firewall e' anch'esso una debian lenny, con i moduli nat helper e
conntrack del sip caricati, e con tcpmss clamp attivo (anche se, per
l'udp non fa testo), double link (una hdsl e una adsl per la fonia) e
policy routing. BTW, ripeto che il problema e' immutato quando asterisk
si trova su internet con ip direttamente attestato.
Non avrei postato qua, se non fosse che sono ormai mesi (da gennaio)
appresso a questo problema... :-(
Allora, il pbx e i telefoni (tutti linksys spa942 versione firmware
6.1.5a) sono su lan privata, sulla stessa subnet.
Il problema si verifica solo con un account voip (univoice), mentre con
un altro account voip (eutelia) NON si verifica.
In breve, e solo con le *chiamate entranti* e non quelle uscenti, se le
si mette in attesa e poi le si riprende o le si trasferisce, il
chiamante non ci sente mentre noi possiamo sentirlo. Se il periodo in
cui la chiamata rimane in hold e' breve, e' possibile spesso vedere
riprendere l'audio interrotto dopo un po' di tempo (10-40sec). Il
problema si verifica SEMPRE, e non si verifica MAI con l'altro
sip provider.
Dopo interminabili ricerche, letture, riconfigurazioni, prove etc. etc.,
ho l'impressione che anche gli interni spa942 siano coinvolti in questo.
Tant'e' che con un telefono ip all7950 il problema e' anche peggiore,
il one-way-audio si presenta subito rispondendo alla chiamata, mentre
con eutelia va tutto liscio.
Certo, qui c'e' un mix di elementi che concorrono al problema: il
provider, i telefoni, forse anche asterisk. (N.B.: i telefoni non
possono navigare, e percio' NON possono instaurare dialoghi sip o flussi
rtp se non con asterisk, non so se questo sia un problema, ma non penso
proprio)
Posso naturalmente postare le configurazioni, non lo faccio adesso
perche' il post e' gia' abbastanza lungo.
Grazie anticipatamente per i suggerimenti che vorrete dare, almeno per
capire dove iniziare a studiare il problema.
bye G.L.
-- 
"E' assolutamente evidente che l'arte del cinema si ispira
alla vita, mentre la vita si ispira alla TV" - Woody Allen

Renaissance wrote:
Parzialmente risolto. E' quasi sicuramente un problema di music on hold.
Uso mpg123 per suonare degli mp3, ed e' questo il problema. Provato con
un centralino askozia al volo, e il problema non si verifica. Una volta
disabilitato il music on hold sul centralino "di produzione", anche li'
il problema e' scomparso. Penso proprio che dovro' far lavorare moh in
modalita' nativa, e ricavare dalle versioni wav degli mp3 le codifiche
ulaw, alaw, g729.
Per a questo punto sarei curioso di sapere il perche', e perche' solo
con un provider e l'altro no... :-)


 ricavare dalle versioni wav degli mp3 le codifiche ulaw, alaw, g729.
Niente da fare. Comunque la giri, evitando le trascodifiche usando solo
file g729 (l'unico codec che uso per tutto), il solo fatto che ci sia il
moh causa su asterisk 1.4.32 il problema. E solo con le chiamate
ricevute, e solo con quel provider...
Mi sa che piglio i log di debug sip e rpt e apro una segnalazione a
digium, giusto per capire chi e' il "colpevole".


 ricevute, e solo con quel provider...
Aggiornamento: lo fa anche con asterisk 1.6.2.9 (current), nonostante
abbia copiato pari pari sip.conf ed extension.conf presi da askozia
asterisk 1.6.1.x... e gli altri file di configurazione di askozia non
abbiano differenze tali da far supporre che il problema sia altrove.
Penso che a questo punto askozia abbia le sue custom patch, o forse sue
opzioni di compilazione di asterisk che fixano il problema.
A meno che a questo punto non mandi tutto a*******o e usi direttamente
trixbox, se anche li' il problema non sussiste. :-)
