This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

VoIP and SIP Module - Phones not registering

Ok. So I have a unique situation. We have implemented VoIP in our network and I have everything up and running and working great. Our XG currently has the SIP Module enabled and we are working. We have another company working within our network that has their own VoIP provider and their phones will not provision. They are standard Yealink T42S devices and they use ATT with ringcentral. I am trying to look at the logs, but from what I've read with the SIP Module enabled, I cannot see log information for that traffic specifically port 5060. I can see the device request time on port 123, and the time sets, but when it tries the request for registration, it never get a response. I have created and exception for ringcentral to bypass https checks and policy checks. Are there any logs that can be viewed via GUI or Device Console to see the SIP information? Any guidance or assistance is appreciated.



Edited TAGs
[edited by: emmosophos at 7:06 PM (GMT -7) on 7 Jun 2021]
  • Hi,

    try creating a clientless group for those phones and then create a specific firewall rule. You should be able to see the initial connection in the logviewer files. Almostsonds like the SIP traffic is getting lost in your network?

    Ian

    XG115W - v20 GA - Home

    XG on VM 8 - v20 GA

    If a post solves your question please use the 'Verify Answer' button.

  • Thanks for the suggestion. I never really paid any attention to clientless as we always authenticated. I would just build create DHCP reservations for devices and then firewall rules to allow the need traffic for specified traffic. i will let you know if this helps. Thanks again.

  • This did not help. I created the clientless user and added to the clientless group. I created a firewall rule to allow all traffic to WAN, but it still does not register. I see port 123 (Time) go out and the phone updates the time, so I don't think it is a routing issue.

  • Hi,

    please post a copy of your firewall rule and logviewer traffic associated with the rule.

    Ian

    XG115W - v20 GA - Home

    XG on VM 8 - v20 GA

    If a post solves your question please use the 'Verify Answer' button.

  • FormerMember
    0 FormerMember in reply to tomrgsd

    Request to also take a packet capture on XG when VoIP phone tries to register itself on RingCentral server.

    =============================================

    ==> Login to SSH > 4. Device Console

    console> tcpdump 'host <ringcentral server domain/IP address>

    eg.: console> tcpdump 'host 11.11.11.11

    ==> In another SSH session run the below command.

    console> drop-packet-capture 'host <ringcentral server domain/IP address>

    eg.: console> drop-packet-capture 'host 11.11.11.11

    =============================================

    After executing above commands try to register VoIP phone and share SSH output here or in PM.

  • This is what I shows. I picked one of the IPs from their list that I see show up in the logs. Since they have multiple, I assumed this one would be best for the packet capture.

  • FormerMember
    0 FormerMember in reply to tomrgsd

    In tcpdumps I can see the source port remains same when the request gets sent OUT through PortD2.

    Suspecting the packets going out to 199.255.120.167 IP for SIP(5060) aren’t getting translated with the WAN IP(PortD2 IP).

    If there’s a firewall rule configured with 199.255.120.167 destination then add a lined NAT rule with SNAT as MASQ.

    If there any specific NAT policy configured for 199.255.120.167 destination, then apply SNAT as MASQ on it.

    Attaching a snapshot for reference.

  • Ok. I figured it out. The phone was trying to register via port 5090 which is not listed on any of the DNAT rules. I added the port to our default dnat rule and the phone registered. Your tip about the dnat is what made me check those rules. Normally I do not have to modify those as 5090 is not a typical SIP port, but it now works. Thanks again.