1 chiamata su X è muta solo sul canale audio in ingresso

[Aliax]

Salve a tutti!

Il problema:
Con la versione di asterisk 1.8.8.0 rc5 ogni numero casuale di chiamate una o piu chiamate verso l'esterno sono mute solo per il canale audio in ingresso.
Ad esempio se A è un interno del centralino e chiama B(un numero esterno che sia cellulare o fisso)
Se B(il numero esterno) parla, A(interno) non sente nulla, mentre se A(interno) parla, B(il numero esterno) sente tutto quello che dice.

Situazione:
Ho un firewall linux con shorewall, ho nattato le porte udp 5060,5061,5062 verso l'indirizzo ip(eth0) del centralino telefonico.
Ho aperto tutte le porte dalla 10000 alla 20000 udp e tcp per permettere il traffico rtp.
I telefoni sono connessi direttamente al centralino telefonico(eth1 10.100.0.1) senza passare da nessun firewall/router quindi stessa rete.
Prima utilizzavo la versione asterisk 1.6.2 e la chiamata in uscita avveniva corretamente con la stessa ubicazione del centralino (stessa identica struttura di rete).

Ho creato un centralino nuovo con installato asterisk, ho scritto un semplicissimo dialplan con lua (credo sia facilmente interpretabile anche per chi sa conf e ael):

extensions = {}
-- CONTESTO DI USCITA ALL'ESTERNO --
extensions["outgoing"] = {
["h"] = function(c,e)
app.hangup()
end;
["_0."] = function(c,e) -- se premo 0 esco dal trunk sip
app.dial("SIP/" .. string.sub(e,2) .. "@XXXXXXXXXXX") -- tolgo la prima cifra corrispondente al prefisso (0) dall'estensione ed esco dal trunk
end;
["_."] = function(c,e) -- se il primo tasto non è 0 allora chiamo un interno
app.dial("SIP/" .. e) -- chiamata verso il numero interno chiamato
end;
};
-- CONTESTO DI INGRESSO DALL'ESTERNO --
extensions["incoming"] = {
["h"] = function(c,e)
app.hangup()
end;
["_."] = function(c,e)
app.dial("SIP/120", 10, m) -- CHIAMO l'interno 120 per 10 secondi
end;
};

ho registrato i trunk sip di eutelia nel sip-registry: (La registrazione verso eutelia avviene correttamente e si registra in una trentina di millisecondi.)

register => XXXXXXXXXXX:[email protected]:5060/XXXXXXXXXXX

ho configurato il trunk sip di eutelia:

[XXXXXXXXXXX]
defaultuser=XXXXXXXXXXX
fromuser=XXXXXXXXXXX
secret=PASSWORD
fromdomain=voip.eutelia.it
canreinvite=no
type=friend
qualify=6000
port=5060
nat=yes
insecure=invite,port
host=voip.eutelia.it
disallow=all
allow=ulaw
allow=alaw
allow=gsm
dtmfmode=rfc2833
context=incoming
transport=udp,tcp
auth=XXXXXXXXXXX:[email protected]:5060/XXXXXXXXXXX

ho configurato un paio di interni in questo modo:

[120]
language=it
deny=0.0.0.0/0.0.0.0
type=friend
secret=PASSWORD
qualify=yes
port=5060
permit=10.100.1.0/255.255.255.0
nat=no
host=dynamic
dtmfmode=rfc2833
dial=SIP/120
call-limit=10
callerid=("Interno di Prova" <120>)
context=outgoing
canreinvite=no
mohinterpret=musiconhold
disallow=all
allow=ulaw
allow=alaw
allow=gsm

Ho modificato il file sip.conf nel seguente modo:

[general]
#include "sip-registry.conf"

context=default
allowoverlap=no
udpbindaddr=0.0.0.0
tcpenable=no
tcpbindaddr=0.0.0.0
srvlookup=yes
sendrpid = yes
sendrpid = rpid
videosupport=yes

#include "sip-trunk.conf"

inoltre ho notato una cosa strana, ma non so se centra:
se faccio sip show channels nella CLI di Asterisk vedo dei canali aperti che poi vengono distrutti ( anche 5 o 6) senza che nessuno stia effettuando chiamate

Se vi può servire allego 3 file di log, di 1 chiamata muta e delle X chiamate corrette, e il "sip show channels".

Se potete aiutarmi a trovare il problema magari insieme troviamo anche la soluzione, grazie 1000 per la pazienza.

[devilevoxxx]

Uso la 1.8.8.0 ( non rc), e non ho questo tipo di problemi. Considerando che il server in questione routa qualcosa come 7000 chiamate / day penso sia un problema di NAT / firewall.
Il server ha ip pubblico o privato? Puoi postare la configurazione della general section di sip.conf?

Ciao,
Davide

[Aliax]

Ciao, grazie per la risposta!

Allora la sezione general è gia nel post precedente, ho dimenticato di scrivere queste impostazioni:

externip = [ip-pubblico]

[Aliax]

Qualcuna sa come potrei risolvere?

Grazie

[devilevoxxx]

Dalla 1.6, se leggi bene il changelog delle configurazioni oltre al canreinvite=no, c'è una cosa nuova chiamata directmedia ( e anche altri parametri relativi a rtp). Prova a giocare con quelli, di solito si usa directmedia=no. Tuttavia penso che il problema stia nel fw, per fare un debug bisognerebbe avere un dump di SIP e SDP, o se puoi diprodurre una sola chiamata "muta" all'interno di asterisk abilitando il debug rtp va bene lo stesso.


Ciao
Davide

[Aliax]

Grazie!
ora mi metto a loggare il traffico rtp sperando di beccare una chiamata muta

[Aliax]

Ho allegato il debug rtp sia con la chiamata funzionante che con la chiamata muta.
Ora sto provando a mettere il centralino in un ip esterno senza nat così afccio la prova del nove.
Intanto ci sono soluzioni in merito?

Grazie 1000

[devilevoxxx]

Allora, gia adesso è un po più chiara.

Mi puoi dire cosa hai aperto sul firewall? Hai aperto entrambe gli ip ( signaling / rtp) verso eutelia?


ciao, Davide

[Aliax]

La configurazione di shorewall è la seguente:

DNAT INT:83.211.227.21 DMZ:10.0.1.204 udp 5060,5061,5062,5063,5064
DNAT INT:83.211.227.21 DMZ:10.0.1.204 tcp 5060,5061,5062,5063,5064
DNAT INT DMZ:10.0.1.204 udp 10000:20000
ACCEPT DMZ:10.0.1.204 INT

________________________________________

INT = eth0 #connessa alla rete internet con ip pubblici
DMZ = eth1 #connessa alla DMZ

Grazie

[devilevoxxx]

Dato che non conosco shorewall visto che i firewall me li configuro direttamente con iptables, ti direi di provare ad aggiungere un altro ip al tuo fw. Se noti bene dal tuo debug che hai postato, c'è un ip 62.x.x.x che è proprio l'rtp-proxy di eutelia.



Prova cosi e fammi sapere,


Ciao,
Davide

[Aliax]

mi pare che Eutelia cambi l'ip ad ogni chiamata.
Se vedi nel debug la chiamata non funzionante aveva ip 83.xxx.xxx.xxx e quella funzionante 62.xxx.xxx.xxx

comunque ti spiego queste righe di codice per capire se è corretto:

#Accetto le registrazioni sulle porte dalla 5060 alla 5064 soltanto dall'indirizzo ip 83.211.227.21 sia tcp che udp.
DNAT INT:83.211.227.21 DMZ:10.0.1.204 udp 5060,5061,5062,5063,5064
DNAT INT:83.211.227.21 DMZ:10.0.1.204 tcp 5060,5061,5062,5063,5064

#Accetto da qualiasi indirizzo ip sulle porte dalla 10000 alla 20000 verso il centralino 10.0.1.204.
DNAT INT DMZ:10.0.1.204 udp 10000:20000

#Lascio uscire tutto dal centralino verso internet.
ACCEPT DMZ:10.0.1.204 INT

[Aliax]

Ho appena fatto una prova facendo un nat 1:1 aprendo tutte le porte verso il centralino e dopo circa 25 telefonate mi è successo di nuovo il problema del canale muto ora la configurazione del sip.conf è stata cambiata nel seguente modo:

[general]
externip = XXX.XXX.XXX.XXX ( ip pubblico)
canreinvite=no

#include "sip-registry.conf"

context=default ; Default context for incoming calls
allowtransfer=yes
udpbindaddr=0.0.0.0
tcpenable=no ; Enable server for incoming TCP connections (default is no)
tcpbindaddr=0.0.0.0
srvlookup=yes
tos_sip=cs3 ; Sets TOS for SIP packets.
tos_audio=ef ; Sets TOS for RTP audio packets.
tos_video=af41 ; Sets TOS for RTP video packets.
tos_text=af41 ; Sets TOS for RTP text packets.
cos_sip=3 ; Sets 802.1p priority for SIP packets.
cos_audio=5 ; Sets 802.1p priority for RTP audio packets.
cos_video=4 ; Sets 802.1p priority for RTP video packets.
cos_text=3 ; Sets 802.1p priority for RTP text packets.
maxexpiry=3600 ; Maximum allowed time of incoming registrations
minexpiry=60 ; Minimum length of registrations/subscriptions (default 60)
defaultexpiry=120
qualifyfreq=60
disallow=all
allow=ulaw
allow=alaw
sendrpid = yes ; per passare il numero chiamante sulle chiamate trasferite
sendrpid = rpid
dtmfmode = rfc2833
videosupport=yes
maxcallbitrate=384
callevents=yes
alwaysauthreject = yes
directmedia=nonat

;----------------------------------- MEDIA HANDLING --------------------------------
; By default, Asterisk tries to re-invite media streams to an optimal path. If there's
; no reason for Asterisk to stay in the media path, the media will be redirected.
; This does not really work well in the case where Asterisk is outside and the
; clients are on the inside of a NAT. In that case, you want to set directmedia=nonat.
;
directmedia=nonat ; Asterisk by default tries to redirect the
; RTP media stream to go directly from
; the caller to the callee. Some devices do not
; support this (especially if one of them is behind a NAT).
; The default setting is YES. If you have all clients
; behind a NAT, or for some other reason want Asterisk to
; stay in the audio path, you may want to turn this off.

; This setting also affect direct RTP
; at call setup (a new feature in 1.4 - setting up the
; call directly between the endpoints instead of sending
; a re-INVITE).

; Additionally this option does not disable all reINVITE operations.
; It only controls Asterisk generating reINVITEs for the specific
; purpose of setting up a direct media path. If a reINVITE is
; needed to switch a media stream to inactive (when placed on
; hold) or to T.38, it will still be done, regardless of this
; setting. Note that direct T.38 is not supported.

;directmedia=nonat ; An additional option is to allow media path redirection
; (reinvite) but only when the peer where the media is being
; sent is known to not be behind a NAT (as the RTP core can
; determine it based on the apparent IP address the media
; arrives from).

;directmedia=update ; Yet a third option... use UPDATE for media path redirection,
; instead of INVITE. This can be combined with 'nonat', as
; 'directmedia=update,nonat'. It implies 'yes'.

;directrtpsetup=yes ; Enable the new experimental direct RTP setup. This sets up
; the call directly with media peer-2-peer without re-invites.
; Will not work for video and cases where the callee sends
; RTP payloads and fmtp headers in the 200 OK that does not match the
; callers INVITE. This will also fail if directmedia is enabled when
; the device is actually behind NAT.

;directmediadeny=0.0.0.0/0 ; Use directmediapermit and directmediadeny to restrict
;directmediapermit=172.16.0.0/16; which peers should be able to pass directmedia to each other
; (There is no default setting, this is just an example)
; Use this if some of your phones are on IP addresses that
; can not reach each other directly. This way you can force
; RTP to always flow through asterisk in such cases.

#include "sip-trunk.conf"

[devilevoxxx]

ascolta, ho visto ora che hai due interfaccie di rete su questo pc..(svista mia), e hai la bind su 0.0.0.0 (in ascolto su tutte).

Fare nat 1:1 per poi dare un ip pubblico sull'interfaccia del server, a questo punto non era meglio dare l'ip pubblico direttamente sul server egestire il tutto in routing, togliendo il nat dalle palle?


Prova a configurare sip.conf in questo modo

port=5060
bindaddr=IP_PRIVATO
externip=IP_PUBBLICO


Ho come l'impressione che ti vada fuori un po di roba da una parte e un po da un altra..ma senza avere le "mani in pasta" non ti so dire di sicuro.


Ciao, Davide

[Aliax]

Si, si faceva prima a togliere il nat dalle scatole, ma il mio scopo era risolvere il problema del nat perchè non voglio un centralino diretto all'esterno,è troppo poco sicuro e poi voglio capirla una volta per tutte questa disgrazia di NAT con asterisk

Ho provato ad aggiungere questi parametri:
port=5060
bindaddr=IP_PRIVATO
externip=IP_PUBBLICO

però ha fatto sempre la solita chiamata muta....

"Ho come l'impressione che ti vada fuori un po di roba da una parte e un po da un altra..ma senza avere le "mani in pasta" non ti so dire di sicuro."
in che senso?

[devilevoxxx]

Ho 3 server con ip pubblico diretto da piu di 5 anni, e non ne hanno mai bucato uno. Nessuna interfaccia web tra le palle, e poi, per quanto riguarda a sicurezza basta configurare asterisk in modo corretto. Se vuoi ci sono tool come fail2ban, o puoi sempre scriverti a mano un packet-ispector per vedere quante richieste vengono da un certo IP (usando le libipq di unix/linux).

Andare a scoprire errori di nat, soprattutto se ce ne sono piu di uno, o come nel tuo 1:1 (simmetrico) è un po difficile non essendo direttamente sulla macchina in diretta a vedere cosa succede.

Tuttavia, prova quest'ultima cosa,
1) bindaddress = 0.0.0.0
2) externip = IP_PUBBLICO
3) localnet = net_privata


sui trunk verso l'esterno :
nat=route

Spero di aver capito bene la tua situazione ( strutturale).
Mal che vada mandami un pm che ci sentiamo su skype per una cosa "real time" altrimenti è un casino.


Ciao e Buone Feste


Davide