TCP / UDP - That is the queston

[Andrew Byrd]

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.

 

[Adrian Fretwell]

It can be confusing and there are good reasons to use either in different situations.
There is a good read here: https://accu.org/index.php/journals/2180

 

[Andrew Byrd]

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]

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]

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]

I have now disabled UDP entirely on port 5060 on a couple of servers, we never see ANY hack attempts now

 

[Adrian Fretwell]

we never see ANY hack attempts now

That's interesting...

 

[Andrew Byrd]

Yes on the rport

1200 on subscription expires

See 2 attached images

 

[DigitalDaz]

What about the registration timer?

 

[Andrew Byrd]

I had it set at 1200. I just changed it to 120 and I will see if that makes a difference

 

[DigitalDaz]

You know the registration timer is different to the subscription timer you mentioned?

 

[Andrew Byrd]

Are these the correct settings that you are recommending for TCP?

 

[DigitalDaz]

Yes, that should do it.

 

[Andrew Byrd]

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]

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.

 

[Andrew Byrd]

I will set up an in house phone and run some captures. Thanks Daz

 

[bcmike]

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]

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]

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]

'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.