0

Phones always register on 5060

Ron Romano

April 06, 2018 12:52

None

Follow

It seems that when we try to register phones on a TCP port, PBX monitor shows the phone registered to port 5060. If I us TCP port 5000 to register phones, the monitor shows IP:5060

This seems to happen on all systems where the phone is on the same subnet as the SPBX.  If I use remote phones I see the random port that is generated in the connection as I would expect. I am using Yealink T46G phones at the locations this is happening.  Possibly a setting on the phone as well?

There seems to be some system limitation/bug/setting that is causing this. Does anyone have a feel for why this is?  Its an issue because park buttons were becoming unregistered on random phones all over a few customer's offices.  Once I set the phones back to UDP 5060 the Issues went away.  I would expect that all the phones would show IP:5000 when I use TCP on that port.

Thanks for reading.

• Facebook
• Twitter
• LinkedIn

8 comments

• 0
  
  Larry Neblett April 07, 2018 13:25

  Fundamentally, there are 2 sides to the communications between the devices - 

  The port that the PBX is listening on and the port that the endpoint device (phone) is listening on as well. 

  An INVITE starts the call handling process and in the INVITE the originating device will send it message to the IP and port that was programmed or made known it by having manually set same or by the registration process. 

  So, when you set the phone up, you likely told the phone the IP and port of the PBX, but inside the phone there is a setting called "local SIP port" or something similar. This is the setting that the phone will be using to tell the PBX how to communicate back to the phone and it is this port that you are seeing in the PBX system as the phones are all likely defaulted to the standard 5060 port. 

  I am uncertain why TCP and why a non-standard port, but both sides would also need to have their transport protocols set to TCP if such is the case. 

  The issue with the BLF may be associated to how the remote phones are connected and how many there are behind a common firewall/router. The BLF function is based upon a SIP subscribe/notify message. If you have multiple phones behind a common firewall and the connection between the PBX and the remote site is on an open Internet (no VPN), then the issue may be that the remote firewall is not able to keep the NAT/PAT tables correct. 

  When a message is sent from a remote phone, the message has to traverse the firewall on the way to the PBX. When the PBX sees the message it sees the remote public IP in the message and responds to same. It is up to the remote router to maintain a table so that the message sent from extension 100 (ip XXX.XXX.XX1) will also receive its associated response back to same and the router does not confuse it with a message that may be destined for extension 101 (ip XXX.XXX.XXX.XX2). The router knows nothing other than IPs and ports. If all the phones behind the router are using local SIP port 5060 and local RTP 5004 (for example) then it may be that the router is having a hard time routing the correct message to the correct IP as all messages are received at the WAN side and the IP looks all the same and now, all are using the same ports even though the responses are for different phones. Some routers are better than others, but it likely depends on the grade of router and the number of remote phones behind same. If this is an issue, then you should consider setting up VPNs between the remote sites and the PBX site is possible. Otherwise, you would be better off assigning different SIP and RTP ports for each remote phone behind a given router so as to provide for uniqueness between them and then port forward to same by reserving the IP of each phone so that the IP and port for each is implicit. 

  The other reasons that BLF may not be correct is the possibility that there are simply too many and the PBX cannot update all within the dynamics of the environment. By this I mean that if you have a large quantity of phones and each has a large number of BLF keys, then consider that each change of state of any monitored extension now has to be transmitted to all phones monitoring same. 

   

   

   

   

• 0
  
  Ron Romano April 07, 2018 18:52

  Thanks for taking the time to reply, i do appreciate it!  I understand how sip works and how the phones register.  If I tell the phone to use tcp and port 2000 for example and I turn on tcp 2000 on the SPBX and both are on the same subnet, my expectation is that the phone would register on 2000 TCP and PBX monitor would reflect that.  This is not the case.  I am using 5060 UDP on SPBX so I don;t see why 5060 would come into play in this scenario. This seems like a bug, but there no doubt I could be missing something.

   

   

   

• 0
  
  Oscar Colka April 08, 2018 02:59

  I test this with S100 firmware version 30.7.0.11, and what I saw seems normal:

  S100  IP address: 192.168.9.62

  Yealink T28P IP address: 192.168.9.34

  Yealink T27P IP address: 192.168.6.104

  

   

  If I re-register the T28 or T27, the port displayed on PBX monitor will changed to another one.

  By the way, as my understanding, the port display on PBX monitor page is what IP phone used to register the SIP account, this means the port number is related to the IP phone but not with the S PBX. But if it always display the same number, either the Phone or the PBX has issues.

• 0
  
  Larry Neblett April 08, 2018 12:53

  I also tested, using different phones. If I use UDP I can set the port to anything I want at the local SIP port setting within the phone and the phone will register to the SPBX and the SPBX will reflect the phone and the port that the phone wants to see. 

  If I change to TCP, the Yealink phone will then use the TCP stack, create a socket and use an ephemeral port by which it wants to listen. 

  

   

  Then, as you can see, I set the local SIP port to be 2000, but when it registers to the PBX, the phone's ephemeral port  of 11962 is being used instead of the 2000 as reflected. 

  
  So, this indicates that when using TCP, the TCP stack that Yealink is using is not implicit; yet it does show correctly in that the port can be changed when set in the phone to use TCP and the extension is also set to use TCP. It must be changed in both places. 

   

  More in next post.

• 0
  
  Larry Neblett April 08, 2018 13:11

  Now then, if I use a Grandstream phone and replicate the test - 

   

  Then in the SIP settings page of the phone:

   

  And now to the S20-

  

  As you can see, I can exert more control with the GS model as the SIP port on the phone and the PBX agree. You will also note the dual mode enforce BLF setting. As the SIP standard is 5060 and UDP, some devices do not always like to play nice with the messaging when using different transports. Hence my original question about why is TCP being used? This setting allows the phone to listen to both UDP and TCP and also inserts a "transport = tcp" into the contact header in an effort to force the PBX to use TCP on all BLF notifications. 

  I have a number of different phone makes and models as well as multiple PBXs of various makes. The s20 settings are:

  In this case, I am using 5080 UDP and I have a different PBX using 5060, another on 5070 and one more on 5090 in addition the S model. 

• 0
  
  Ron Romano April 08, 2018 16:39

  Thanks again for testing to both of you.  So this is more confusing than before.  In some cases we are seeing random ports in examples and in others we are seeing the static ports assigned at the phone.  At this point I have to do some testing of my own.  It does seem to me that the phone is responsible (or a least the phone side of the interaction) for determining what port the SPBX sees as the registration port.  I expect this to be the case.  What I don't expect is that in some cases we have a random port and in others we have a static port on the same subnet.  I will research tis more tomorrow.

• 0
  
  Ron Romano April 09, 2018 13:04

  I see why this is happening but I'm not sure if it matters or if changing to 5060 in registration really solved my issue.  It seems to have with park BLF.  On my T46G and S phones under Settings>SIP  the local port it was set to 5060.  This means the port shown in PBX monitor is the port the phone is using not the port the phone used to connect in the account tab.  When you use the standard UDP 5060 in the account tab to connect this doesn't look strange.  But when you use a non standard port it does.  The SPBX provisioning does not change the local SIP port and I don't know that it needs to.

  What I am not clear on is if this causes issues.  We do a lot of remote phones.  Non standard SIP ports have been good for us.  It helps get around the router where the remote phone is and some other things too.  I can tell you there is a limitation on the number of TCP connections S100 can handle as I have run into it.  I'm waiting to hear what the limitations are from Yeastar support.

  Thanks to the two of you, Larry and Oscar for helping me with this.

• 0
  
  Larry Neblett April 09, 2018 14:28

  As I stated in the original post - 

  "inside the phone there is a setting called "local SIP port" or something similar. This is the setting that the phone will be using to tell the PBX how to communicate back to the phone and it is this port that you are seeing in the PBX system as the phones are all likely defaulted to the standard 5060 port.

  The phones. like the PBX, are independent of one another and each has to be told what to do and what to expect. The SPBX. like many others, does not have the means to accommodate all the various makes and model of phones and their firmware versions to accommodate  all the various variables that define their ways to change certain settings. As a result, most just default to the standards. I simply assumed that the TCP settings in the extension settings of the SPBX, were merely letting the PBX know what to expect. It never occurred to me that it may have been a provisioning variable, but I do see your point. 

  In any event, you may also want to examine some of the messaging to see how TCP works. Like everything, there are usually pros and cons to everything that is VoIP - VLANs must be used, Data and Voice should be separate, do not open ports, etc. 

  The issue with TCP is that it is not real-time, it is a trade off of reliability over speed as the main factor. While I do not know that it might be an issue, consider that you have numerous phones all using multiple BLF. As TCP does error correction, it could be that Notify messages (or parts) are not all getting through (for whatever reason) and the retry is coming after the fact with the data that failed to make it originally. So, as a (poor) example, if you have BLF conditions for a given extension that were 1, 2, & 3, but due to the retry were seen as 1, 3, and 2, perhaps this is some of the cause. In this case, condition 2 was not able to be acted upon, but rather than ignoring, and moving on to 3, the TCP allowed 2 to come in late and reapply a condition that is not in sync with where the phone should be. 

  This may be a reason as to why when you changed back to UDP all seemed well. As you have not reported any other issues about calls not getting thru, dropping, etc., this may be because the notify messaging is far more prevalent (more phones all with BLF constantly getting updated) and therefore more apt to be affected. 

  Finally, the RFC calls for the removal (should remove) of a Subscriber from the Notify list in the event of a timeout to the response had the Subscribe query been used to establish the notifies. "Should" is the operative word and is not mandatory and I do not know how the SPBX reacts to this. The assumption is that the subscriber is no longer reachable and rather than tie up the network with what is assumed to be extraneous data, the Subscribing unit is expected to re-subscribe upon becoming reachable again. 

  A Wireshark capture may shed some light on this in addition to the query you have into support as to how many simultaneous TCP connections are supported. 

  Good luck.