TCP / UDP - That is the queston

Status
Not open for further replies.

Andrew Byrd

Member
Feb 16, 2018
309
10
18
53
I have seen the TCP / UDP debate often in most very voip related forum. I have been using UDP simply because TCP has created new issues I never had with UDP. Some say that TCP did not create these new issues, but the fact remains that when I was on UDP the issues did not surface.

To be more specific I have a client that has 4 spa508G devices. 3 are in one office and one is in another office 30 miles away. I tried setting all 4 on TCP at device level. The 3 in the office work excellent thus far, but the 1 in the other office when idle for more than 30 or 45 minutes loses registration and has to be rebooted to register again. I changed that one phone that was on TCP back to UDP and now it stays registered. Any insight on this would be greatly appreciated.
 

Andrew Byrd

Member
Feb 16, 2018
309
10
18
53
Thank you Adrian. I just received a call from my client at the office that has 3 phones on TCP and he said that one of those phones were not registered. He said if he rebooted the phone it would register but after about an hour or less, it would lose registration again. I changed it back to UDP and no issues now. I would really love to use TCP for the other benefits, but until I can figure this registration issue out I will have to stay with UDP
 

DigitalDaz

Administrator
Staff member
Sep 29, 2016
3,038
556
113
So, on those Ciscos, do you have, insert via rport and handle via rport set?

What you should also do is a capture with sngrep. Phones do not LOSE registration. They fail to register within the required time period. What are your reg timers set to, 120?
 

Adrian Fretwell

Well-Known Member
Aug 13, 2017
1,386
364
83
Using UDP should not be seen as a problem unless you get to needing larger packets than your end to end MTU will allow. TCP will handle fragmentation, but it has a bigger overhead, however its use is specified in the SIP RFC:
If a request is within 200 bytes of the path MTU, or if it is larger
than 1300 bytes and the path MTU is unknown, the request MUST be sent
using an RFC 2914 [43] congestion controlled transport protocol, such
as TCP.
 

DigitalDaz

Administrator
Staff member
Sep 29, 2016
3,038
556
113
I have now disabled UDP entirely on port 5060 on a couple of servers, we never see ANY hack attempts now :)
 

Andrew Byrd

Member
Feb 16, 2018
309
10
18
53
Yes on the rport

1200 on subscription expires

See 2 attached images
 

Attachments

  • 5048350641225728.png
    5048350641225728.png
    88.4 KB · Views: 27
  • 5611300594647040.png
    5611300594647040.png
    106.8 KB · Views: 23

DigitalDaz

Administrator
Staff member
Sep 29, 2016
3,038
556
113
You know the registration timer is different to the subscription timer you mentioned?
 

Andrew Byrd

Member
Feb 16, 2018
309
10
18
53
Are these the correct settings that you are recommending for TCP?
 

Attachments

  • 5165645661208576.png
    5165645661208576.png
    70 KB · Views: 31
  • 5022924434833408.png
    5022924434833408.png
    101.8 KB · Views: 29

Andrew Byrd

Member
Feb 16, 2018
309
10
18
53
Client called me this morning and said they could not receive calls or dial out. They had the amber lights showing on the keys. They rebooted their phones and then all was well. About 3 hours later, the phone became what I call "unregistered" again. Not sure what you would call it but I call it NOT registered when someone can't make outbound or inbound calls and all their blf lights go amber

Anyway - I changed them back to UDP and no issues

I have tried TCP many times and maybe it is a setting somwhere but I have never been successful with it. I really wanted it to work due to Nat

But, until I can find what settings are causing the registration to drop, I have to use what is working - UDP
 

DigitalDaz

Administrator
Staff member
Sep 29, 2016
3,038
556
113
You are never going to diagnose ANYTHING until you start doing some captures, something I pointed out to you to do a number of posts ago.
 

bcmike

Active Member
Jun 7, 2018
326
54
28
53
In your keep alive message field try $REGISTER instead of $NOTIFY.

Honestly I'm not sure why this would have a different effect, but its something to try.
 

bcmike

Active Member
Jun 7, 2018
326
54
28
53
Ok I'm supporting a few Cisco spas and am seeing the same behavior when using TCP. I'm behind a pfsense firewall and the Cisco were recently moved from an enterprise that also had a pfsense router out into home offices.

I'm thinking the cheap routers at the home offices probably have their TCP connection timers set too low while my pfsense box has them set fairly conservatively and therefore we get orphaned states.

I had the registration timers set at 120 seconds and have brought them down to 60 to see if this will make a difference. I'm thinking the keep alive method for the Ciscos must be different from Yealink as I don't seem to have this problem with Yealink (yet). Will update if this works.
 

DigitalDaz

Administrator
Staff member
Sep 29, 2016
3,038
556
113
You shouldn't need keepalives with the Ciscos, they should have anything related to the NAT turned off. I've had an office of 65 SPA303 handsets running solidly since 2015 that are sat behind a pfsense router. They just have the reg timers set to 120 and the 'insert via rport' and 'handle via rport' enabled.
 

bcmike

Active Member
Jun 7, 2018
326
54
28
53
'insert via rport' and 'handle via rport' are enabled.

So the phones were on a site behind a pfsense router that registered over the public network to our FusionPBX box also behind a pfsense router. The workers were sent home with their phones and are behind different consumer grade routers. I don't know what the connection timers are on those routers but wwhat I do know is whenever one of the phones in question loses reg I go into the pfsense router on our end and kill the states related to that phone and it immediately re-establishes reg.
 
Status
Not open for further replies.