SL2100 not binding media ports on calls with Remote IP phones

[Tristan C]

Preface: I've limited exposure to NEC products, but am very familiar with VOIP

Looking for some insights here, backstory is a firewall was replaced and the port forward for the signaling (5080-5081 udp) and media ports (10020-100587 udp) were copied over. Everything works internally just fine, and calls to/from the PRI from internal. Everything involving the Remote IP Phones has no audio either way.

If we call the vendor I'm guessing they are going to blame the firewall, however I've done a packet capture on the interface that the phone system resides on (already past kernel/filtering and on the wire): I can see the SIP legs establish successfully and media packets flowing from the remote phone to the SL2100, but the SL2100 responds with ICMP unreachable for the media port and there is no media flowing from the SL2100 to the phone. The call terminates properly when either end hangs up - no issue with the signaling.

Unfortunately we lack the installer account and only have an SA level account, so I can't do debugging.

Is there anything that could be causing the issue on the SL2100? Something for me to guide the vendor to if Installer access is required, or that I can check myself?

(64.141.x.x remote phone external, 184.67.x.x SL2100 external, 172.22.x.x SL2100 internal)

 

[CoralTech]

Well, if it worked before and now after changing the firewall it doesn't....why do you think it's the phone system?

The port forwarding will be to 2 internal IP addresses. 5080 will be the signaling the other 10020-10531 will go to the media gateway IP. Looks to me like your firewall is not doing this from your wireshark. Check your programming.

What firewall are you using?

 

[belevedere]

The attached document may help.

 

[Tristan C]

The firewall is a Fortigate, the packet capture was done on the interface where the SL2100 is hosted. The port forwards are in place correctly: it is the SL2100 sending the ICMP unreachable - a flow debug also shows this

During the replacement, gear was shifted around in the racks and there was a loss of power to the rack due to a failed UPS. I wasn't sure if the SL2100 maybe lost some settings, or had a failure in a component used to pin media to the SL1200 like a DSP chip


id=20085 trace_id=316 func=print_pkt_detail line=5727 msg="vd-root:0 received a packet(proto=17, 64.141.x.x:3462->184.67.x.x:10020) from wan1. "
id=20085 trace_id=316 func=init_ip_session_common line=5898 msg="allocate a new session-0021970f"
id=20085 trace_id=316 func=fw_pre_route_handler line=181 msg="VIP-172.22.x.x:10020, outdev-wan1"
id=20085 trace_id=316 func=__ip_session_run_tuple line=3484 msg="DNAT 184.67.x.x:10020->172.22.x.x:10020"
id=20085 trace_id=316 func=vf_ip_route_input_common line=2621 msg="find a route: flag=00000000 gw-172.22.x.x via Servers"
id=20085 trace_id=316 func=fw_forward_handler line=799 msg="Allowed by Policy-6:"
id=20085 trace_id=316 func=ipd_post_route_handler line=490 msg="out Servers vwl_zone_id 0, state2 0x0, quality 0.
"
id=20085 trace_id=317 func=print_pkt_detail line=5727 msg="vd-root:0 received a packet(proto=1, 172.22.x.x:0->64.141.x.x:771) from Servers. type=3, code=3, id=0, seq=0." <-- unreachable from the SL2100
id=20085 trace_id=317 func=vf_ip_route_input_common line=2621 msg="find a route: flag=04000000 gw-184.67.x.y via wan1"
id=20085 trace_id=317 func=__ip_session_run_tuple line=3470 msg="SNAT 172.22.x.x->184.67.x.x:10020"
id=20085 trace_id=317 func=ipd_post_route_handler line=490 msg="out wan1 vwl_zone_id 1, state2 0x0, quality 1.

 

[CoralTech]

Well, here's the deal. You gotta check the phone system programming. If IP phones are working internally....the Fortigate is the issue unless there has been a change to Network, GW, IP etc. SIP ALG needs to be turned off and that Fortigate IP phone system software running in background on that router needs to be disabled.

FWIW, if you change something that has been working and that one item causes it to stop working you need to start there with trouble shooting. I cannot tell you the amount of time I have to work through routers that are not configured correctly or do not report their true status correctly in their GUI. If you are not telnet into that router what you see in the GUI may be false.

 

[OzzieGeorge]

All I can say is we have stopped selling Fortigate! Here we have the usual, I changed my side and it stopped working so it must be something wrong with your side! This will probably not be solved by any help we here can provide, my suggestion would be put the old arrangement back and if it works, that proves where the issue lies! The Sl2100 memory is not that volatile, I can remove the memory back up battery to replace it and the memory is retained so no not the NEC's issue!