Se all'interno della vostra LAN avete un centralino VOIP e ha problemi con il provider, questi sono i passaggi per un corretto troubleshooting
Dopo aver individuato le policy di traffico tra il centralino e provider, provare a cambiarle da Flow a Proxy
Provate a disabilitare la funzione ALG, di default è impostata in proxy, provare a metterla in kernel.
FW# config system settings
FW(settings)# set default-voip-alg-mode proxy-based/kernel-helper-based
Provate a cancellare il SIP helper
FW# config system session-helper
FW(session-helper)# show
FW(session-helper)# edit 13
set name sip
set protocol 17
set port 5060
FW(session-helper)# delete 13
Se queste soluzioni non dovessero funzionare, ripristinare come prima e procedere con il debug
Verificare se la sessione viene correttamente instaurata:
FW# diagnose system session filter src <IP centralino>
FW# diagnose system session filter dst <IP provider>
FW# diagnose system session list
L'output che dovreste trovare è il seguente:
session info: proto=17 proto_state=01 duration=142250 expire=3596 timeout=3600 flags=00000000 sockflag=00000000 sockport=0 av_idx=0 use=4
origin-shaper=
reply-shaper=
per_ip_shaper=
class_id=0 ha_id=0 policy_dir=0 tunnel=/ helper=rsh vlan_cos=255/255
state=local
statistic(bytes/packets/allow_err): org=9376719/61304/1 reply=3930213/32743/1 tuples=2
tx speed(Bps/kbps): 65/0 rx speed(Bps/kbps): 27/0
orgin->sink: org out->post, reply pre->in dev=13->0/0->13 gwy=0.0.0.0/10.5.27.238
hook=out dir=org act=noop 10.5.27.238:16844->173.243.132.165:514(0.0.0.0:0)
hook=in dir=reply act=noop 173.243.132.165:514->10.5.27.238:16844(0.0.0.0:0)
pos/(before,after) 0/(0,0), 0/(0,0)
misc=0 policy_id=0 auth_info=0 chk_client_info=0 vd=0
serial=0161f3cf tos=ff/ff app_list=0 app=0 url_cat=0
rpdb_link_id = 00000000
dd_type=0 dd_mode=0
Prestate attenzione al protocollo utilizzato e alla policy che viene usata.
Se la sessione viene instaurata, vedere le chiamate attive
FW#diagnose sys sip-proxy calls list | grep -B7 -A3 <numero di telefono da filtrare>
vdom 0 (root) vrf 0 call 7f5a40ed9600
call-id: 9017997241972024165753@<IP provider>
txn 7f5a40efa300 (INVITE)
cseq 102 dir 1 state 11 status 200 expiry 143 HA 1
i_session: 7f5a40e35000 r_session: 7f5a40e35000
register: not-present
from: sip:<numero sorgente>@10.39.31.123;user=phone
to: sip:<numero destinazione>@10.39.31.20;user=phone
src: <IP centralino>:5060
dst: <IP provider>:5060
Se ancora ci sono problemi, provate a tracciare il flusso.
FW# diagnose debug console timestamp enable
FW# diagnose debug flow filter saddr <IP centralino>
FW# diagnose debug flow show function-name enable
FW# diagnose debug flow show iprope enable
FW# diagnose debug enable
FW# diagnose debug flow trace start 1000
Prestare attenzione se nel debug compare un messaggio del genere
msg="iprope_in_check() check failed on policy 0, drop
potrebbe voler dire che l'IP che sta usando il centralino per uscire è usato da un VIP che ha l'ARP reply abilitato, la soluzione è disabilitare l'arp replay al VIP
Dopo aver individuato le policy di traffico tra il centralino e provider, provare a cambiarle da Flow a Proxy
Provate a disabilitare la funzione ALG, di default è impostata in proxy, provare a metterla in kernel.
FW# config system settings
FW(settings)# set default-voip-alg-mode proxy-based/kernel-helper-based
Provate a cancellare il SIP helper
FW# config system session-helper
FW(session-helper)# show
FW(session-helper)# edit 13
set name sip
set protocol 17
set port 5060
FW(session-helper)# delete 13
Se queste soluzioni non dovessero funzionare, ripristinare come prima e procedere con il debug
Verificare se la sessione viene correttamente instaurata:
FW# diagnose system session filter src <IP centralino>
FW# diagnose system session filter dst <IP provider>
FW# diagnose system session list
L'output che dovreste trovare è il seguente:
session info: proto=17 proto_state=01 duration=142250 expire=3596 timeout=3600 flags=00000000 sockflag=00000000 sockport=0 av_idx=0 use=4
origin-shaper=
reply-shaper=
per_ip_shaper=
class_id=0 ha_id=0 policy_dir=0 tunnel=/ helper=rsh vlan_cos=255/255
state=local
statistic(bytes/packets/allow_err): org=9376719/61304/1 reply=3930213/32743/1 tuples=2
tx speed(Bps/kbps): 65/0 rx speed(Bps/kbps): 27/0
orgin->sink: org out->post, reply pre->in dev=13->0/0->13 gwy=0.0.0.0/10.5.27.238
hook=out dir=org act=noop 10.5.27.238:16844->173.243.132.165:514(0.0.0.0:0)
hook=in dir=reply act=noop 173.243.132.165:514->10.5.27.238:16844(0.0.0.0:0)
pos/(before,after) 0/(0,0), 0/(0,0)
misc=0 policy_id=0 auth_info=0 chk_client_info=0 vd=0
serial=0161f3cf tos=ff/ff app_list=0 app=0 url_cat=0
rpdb_link_id = 00000000
dd_type=0 dd_mode=0
Prestate attenzione al protocollo utilizzato e alla policy che viene usata.
Se la sessione viene instaurata, vedere le chiamate attive
FW#diagnose sys sip-proxy calls list | grep -B7 -A3 <numero di telefono da filtrare>
vdom 0 (root) vrf 0 call 7f5a40ed9600
call-id: 9017997241972024165753@<IP provider>
txn 7f5a40efa300 (INVITE)
cseq 102 dir 1 state 11 status 200 expiry 143 HA 1
i_session: 7f5a40e35000 r_session: 7f5a40e35000
register: not-present
from: sip:<numero sorgente>@10.39.31.123;user=phone
to: sip:<numero destinazione>@10.39.31.20;user=phone
src: <IP centralino>:5060
dst: <IP provider>:5060
Se ancora ci sono problemi, provate a tracciare il flusso.
FW# diagnose debug console timestamp enable
FW# diagnose debug flow filter saddr <IP centralino>
FW# diagnose debug flow show function-name enable
FW# diagnose debug flow show iprope enable
FW# diagnose debug enable
FW# diagnose debug flow trace start 1000
Prestare attenzione se nel debug compare un messaggio del genere
msg="iprope_in_check() check failed on policy 0, drop
potrebbe voler dire che l'IP che sta usando il centralino per uscire è usato da un VIP che ha l'ARP reply abilitato, la soluzione è disabilitare l'arp replay al VIP
