Ciao a tutti: sto incontrando qualche grattacapo di troppo nel far funzionare l'ata in oggetto con 3cx. I due soggetti stanno sotto subnet diverse ma routate tra di loro e non filtrate tra questi ip. Dopo aver creato su 3cx il device, assegnato l'interno e caricato l'xml sul grandstream, l'ata (con l'ultimo firmware disp) si registra correttamente. Le chiamate in & out sono ok ma da quel telefono non si sente l'audio, mentre lo trasmette. Guardano negli states di pfsense che sta in mezzo, Il problema sta nell'rtp: il 3cx fa partire una connessione udp dal suo range di porte (7000-8999 LAN audio/video/t38 streams) ma verso la 5005 udp che il grandstream non accetta. Localmente è ancora configurata di default la 5004 per l'rtp. Provato con rtp simmetrico e altre impostazioni ma nulla da fare. Avete qualche idea? grazie
Granstream ht 801 & 3cx: no inbound audio
Tagga qualche "voipparo" come ziomatt o kmorwath...
- Modificato
vediamo se @[cancellato] e/o @[cancellato] mi sapranno aiutare, intanto vedrò di procurarmi qualche log dettagliato nel mentre di una chiamata
[cancellato]
Controlla che il pfSense non riscriva le porte. In modalità solo routing non dovrebbe farlo, ma controlla che non sia rimasto qualche NAT non richiesto - è una delle cause dell'audio monodirezionale con pfSense. Non capisco perché usi la porta 5005 se l'ATA gl comunica la 5004.
Pupi anche provare a mettere momentaneamente l'ATA nella stessa subnet del 3CX per vedere se il problema è il pfSense.
- Modificato
Eh mi sa di si che vengano riscritte le porte: avevo anche provato su due piedi ad impostare una regola full-cone nat impostando porte statiche per l'ip del pbx da e per quella rete ma il risultato non cambia.
l'82.15 è il 3cx, il 54.100 è l'ata, il 54.107 è il cellulare chiamante con il client voip.
Durante la pausa pranzo ho segato via il gateway da pfsense sulla rete 54, che usavo fino a 2 sett fa quando era tutto sotto fttc per usare anche l'ip pubblico del modem tim. Dopo provo ad effettuare un'altra call di test.
L'ata è fisicamente in un'altra abitazione, dove arriva la connettività: potrei provare ma spererei di farlo funzionare li dov'è senza altri giri.
Ho anche un log ma vorrei pulire e anonimizzare le 700 e rotte righe prima di pubblicarlo
[cancellato] Non capisco perché usi la porta 5005 se l'ATA gl comunica la 5004.
La porta dispari + 1 di quella negoziata pari e' l'RTCP, e' normale che ci sia anche se non e' mai negoziata esplicitamente.
v8star quel NAT a 192.168.54.254 sta creando il problema secondo me, riscrive sia l'IP che pure le porte. Si puo' togliere? Perche' non basta attivare il NAT per SIP ma serve anche riscrivere gli indirizzi e porte nei pacchetti SIP, e spesso i conntrack helper (di Linux, non so l'eventuale equivalente di BSD/pfSense come si chiama) che fanno questo lavoro per SIP, quando ci sono, fanno solo piu' danni che altro.
LATIITAY ho provato anche senza rtcp ma il risultato non cambia: dal log le porte negoziate dall'ata sono 5004 & 5005.
Si ho tolto quel nat sul firewall 82/3cx e ora quantomeno sul firewall .54 non vedo più ip nattati sorgenti ma i nativi .82 ma comunque il problema persiste. Mi sto concentrando ora più sul firewall lato 54: è (era) un openwrt con una route statica verso la rete 82 con gw 54.254 che è l'ip dell'if rete 54 del firewall 82 (in sostanza la tagged sulla rete di trasporto). Non vorrei che il problema fosse proprio wrt: non offrendo molto logging non so cosa passa e cosa no e quindi ora ho avviato un pfsense con la stessa conf di rete e domani farò altre call di prova, quantomeno ho più visibilità.
Ah, dimenticavo: tutto allegramente virtuale 
v8star RTCP ci deve essere, non e' lui il problema. Ci passano le statistiche di RTP. Anzi se non passa ci potrebbero essere altri problemi...
Su OpenWrt (e Linux in generale) puoi vedere tutte le connessioni con cat /proc/net/nf_conntrack
Sarebbe probabilmente utile anche un tcpdump fatto tra l'ATA e il suo uplink, e tra il 3CX e il suo uplink, tanto per capire che cosa effettivamente contengono esattamente le SDP nei pacchetti SIP che transitano...
LATIITAY sono riuscito a sistemare facendo le seguenti modifiche:
1 - ho impostato uno stun esterno e fatto utilizzare dall'ata (e tolto il provisioning dall'ht verso 3cx, altrimenti al riavvio lo zappava via)
2 - via WRT e su con psense lato 54 (peccato che via pppoe pf vada la metà rispetto a wrt, ma ero già in ottica di cambiare l'amd a4-5050 sotto, che il gigabit lo vede col binocolo)
3 - cambiata la rete lato ata spostandola da 54.x a 46.x e mantenendo la rete 54 per il "bridge" tra i due firewall in modo da non dover variare vlan e aggiunte route statiche incrociate tra 46 e 82 attraverso la 54. Questo per evitare routing asimmetrico che a PF piace poco
in sostanza, bella rottura di 
ma quantomeno ora funziona: tra pochi giorni dovrei avere il numero migrato in olimontel.
[cancellato]
v8star peccato che via pppoe pf vada la metà rispetto a wrt, ma ero già in ottica di cambiare l'amd a4-5050 sotto, che il gigabit lo vede col binocolo
Perché lato BSD PPPoE è single threaded, quindi sei limitato alle performance di un solo core.
- Modificato
v8star ottimo che adesso funzioni, ma mi resta qualche dubbio...
v8star 1 - ho impostato uno stun esterno e fatto utilizzare dall'ata (e tolto il provisioning dall'ht verso 3cx, altrimenti al riavvio lo zappava via)
Con STUN ottieni che ti va ad utilizzare l'IP pubblico nella SDP... Qui invece se ho capito bene hai due LAN con IP privati e senza NAT tra loro (NAT solo verso internet), interconnesse mediante un qualche link. (Cmq non ho ben chiara la topologia di rete, c'e' una VPN tra i due siti? Come sono connessi ad internet e tra di loro?)
Insomma mi sa che cosi' facendo la voce potrebbe non passare dagli IP privati ma potrebbe passare tramite internet.
L'unica per capirci meglio sarebbe ottenere una SIP trace dall'ATA, o un tcpdump, insomma un qualcosa che faccia vedere le SDP cosi' come vengono trasmesse e (soprattutto) ricevute dalle varie parti coinvolte.
v8star 3 - cambiata la rete lato ata spostandola da 54.x a 46.x e mantenendo la rete 54 per il "bridge" tra i due firewall in modo da non dover variare vlan e aggiunte route statiche incrociate tra 46 e 82 attraverso la 54.
Ok, ci sta. Almeno e' tutto piu' "pulito" con sottoreti designate ad un singolo scopo.
v8star routing asimmetrico che a PF piace poco
Il routing asimmetrico non piace ai firewall stateful, come puo' essere anche il conntrack di Linux... Se poi ci si mette anche il reverse path filtering di mezzo... 
LATIITAY n STUN ottieni che ti va ad utilizzare l'IP pubblico nella SDP... Qui invece se ho capito bene hai due LAN con IP privati e senza NAT tra loro (NAT solo verso internet), interconnesse mediante un qualche link. (Cmq non ho ben chiara la topologia di rete, c'e' una VPN tra i due siti? Come sono connessi ad internet e tra di loro?)
Insomma mi sa che cosi' facendo la voce potrebbe non passare dagli IP privati ma potrebbe passare tramite internet
Dal dump degli states di pfsense in-call gli ip erano tutti locali, posso anche provare a togliere lo stun nei prossimi test, confido funzioni lo stesso.
Non ho i log ma.secondo me prima c'era qualche problema col percorso di ritorno: la sola route statica lato ata non bastava, oltre al nat lato 3cx.
Il collegamento tra i 2 fw é un p2p wifi da 1km con ubiquiti. Arrivo untagged su uno switch tra ont e firewall per la vlan 835 per avere anche un altro ip pubblico e tagged per il traffico intra
