0

SIP Trunk REGISTER retransmission

Brian Flinte

October 18, 2019 21:38

None

Follow

Hello,

I have a TE100 SIP trunk connecting to a provider with FreeSWITCH. I am able to register the TE100, however the TE100 will send many retransmissions to the registrar. Traffic is going through a firewall which has a known good configuration (We have 3000+ sip devices traversing it. I have packet captures verifying traffic ingress and egress). The Yeastar sees all the SIP packets. It likes some 200 OKs and it doesn't like others. If it doesn't like the 200 OK's it will say something like this "Retransmitting #3 (NAT) to x.x.x.x:5060:"

Things i have tried:

* increasing the T1min timer

* setting the public IP in the NAT configuration

* tried every setting under NAT (yes, no, never,etc)

* connect to an OpenSIPS proxy instead of Freeswitch

* use IP instead of DNS for server

* tcp/udp

* changed to port 5080 instead of 5060

* upgraded TE100 firmware to the latest

* tinker with reregisterstion timers

* force expiration from the registrar

 

I would be grateful for any assistance. Thanks!

• Facebook
• Twitter
• LinkedIn

4 comments

• 0
  
  Larry Neblett October 19, 2019 10:38

  Can you post a pcap log (a network capture using Wireshark)?

  I assume the TE is local to the PBX, correct? If not, what are local/private IPs for each?

  What issues does this present to the callers/callees?

  I am a little confused with some of the explanations.

  The only two devices communicating at a SIP level are the TE and your PBX.

  The TE will sent a register request which the PBX may challenge in order to force the TE to resent the request again, but this time with the credentials. In the request, the TE may have requested a expires time, which is the amount of time it seeks before having to re-register. The PBX will respond to the second register request with a 200OK or with another challenge if the credential are not correct. IT may also respond with a forbidden.

  If an 200OK is seen, then that message may also have an expires header. When the TE sent the register with its expires header the PBX is under no obligation to accept that time, but instead can offer its own time which the TE must accept.

  You should not mess with the registration timers, ports, transport (tcp/udp), proxy or T1 timers. A packet capture will show the messaging between the two devices and from there we can determine the issue.

  My guess at this point is that one or the other (TE or PBX) is sending an incorrect IP in the contact header. The contact header is used to tell a device(1) what the other end device(2) wants device(1) to use when sending a message. The reverse is also true in the device(1) will also tell device(2) what it wants device(2) to use.

   

  So, what happens is that the initial contact between the devices is made. Once this occurs then the contact header comes into play and my suspicion is that instead of using the local IP, the header is specifying to use the public IP. This results in a shift were the device does indeed respond to the public and the receiving device is not seeing it. As a result the message is never acknowledged which results in a number of attempts to retry, but as nothing has changed, the same thing occurs until either Timer B or Timer F kick in and the message is cancelled or a call drops.

  Timer T1 is the amount of time a device will wait for a response. This is typically set for 500ms. If no response is seen the message will be resent at 1000ms. If no response is seen again, it will be resent in 2000ms and this will continue at 4,000, 8,000, 16,000 and 32,000ms intervals, The intent is to allow for the possibility that the connection or far end has an issue and needed some time to come back online. In essence a 32 second time period before Timer B or F fire.

  If I am correct, which a capture will quickly show, then playing with ports, timers, expiries and such will have no affect, but instead may cause other unwanted issues.

  Looking at a pcap you can see the flow of messages and then expand the message to show all of the elements contained therein. You would need to look at an INVITE from one device and then a 200OK/SDP in response from the other device. You are looking for the Contact and Connect headers in both. The Contact header has the IP for the SIP messaging aspect and the Connect header has the IP for the RTP stream (audio) headers.

  The other possibility may be the size of certain messages and if the packets are fragmented. You should set the codecs in both the trunk settings of the PBX and the TE to only use the codec desired which I assume will be PCMU or PCMA (g711u & g711a....same as PCMU/A0 and g729. g711u is used in North America and a few other locales, while PCMA is used in EMEA and most of AP. I assume your provider indicated the needed codec. Doing this will help to reduce the message size.

   

   

• 0
  
  Brian Flinte October 20, 2019 00:42

  Thanks for the taking time for such an in depth response. 

  Short answer...I got it working with TCP. 

  Long answer... When I originally used TCP I was able to get one call up, but after that I my FreeSWITCH registrar would stop responding to traffic. I moved on and tried UDP. 

  FreeSWITCH (Public IP) <---> Firewall (NAT) <----> TE(private IP)

  The issue with UDP was that the TE registration was flapping. I could get it to register and make calls across just fine, however trunk would go unregistered a lot. When I started digging in I found that the TE would send a REGISTER and receive a 200 OK, but it would only accept these 200 OK's randomly. Sometimes it would accept the 200 OK and other times it would retry 2 to 8 times. That's when I tried playing with expiration timers and t1 timers. 

  I went back to TCP and I found that after a call, my FreeSWITCH SIP profile would stop responding. I would have to restart the SIP interface on FreeSWITCH. I noticed in a pcap that Wireshark considered the TE's 200 OK in response to the INVITE to be malformed. That's when I noticed video in the SDP and TE's malformed video's response. I believe Wireshark & FreeSWITCH considered in an incomplete SDP with video.

  After I changed FreeSWITCH's INVITE to include only PCMU and not video everything started working fine. 

  I still don't understand why UDP is not consistent, but I'm fine with using TCP. 

  Thanks again for your input. 

   

• 0
  
  Larry Neblett October 20, 2019 11:59

  TCP is a stateful connection, UDP is stateless.

  If the TE is local to the PBX, then you should have no issue with UDP.

  TCP being stateful is aware of the transmissions and will retry in the event of an error or drop. UDP does not. It is a question of reliability versus speed.

  While TCP may sound great, it can under certain circumstances cause issues, A voice stream is just that, a continuous stream of data which when using UDP if a packet is dropped, it is dropped and there is no attempt to recover. With TCP there is an attempt to recover but the results may look like -

  WIth UDP and  dropped packets -

  1, 2, 4, 5, 6, 7,10, 11, 12, 14, etc.

  With TCP it may look like

  1, 2, 4. 3. 5, 6, 7, 10 , 8. 11. 9. 12. 14, 13.

   

  As the packets are sent at 20ms intervals (depending on codecs), the loss of some with UDP may be irritable, but tolerable to the extent that you can still understand.

  With TCP the insertion of packets out of order may cause the conversation to be somewhat less understandable due to the insertion of packets during a conversation, but the timing is off. It' somewhat akin to speaking a greeting of "Hello, how are you" and the other end hears, "Hello, are you how".

  The above is merely an illustration of the process, not necessarily a real example. 

  The point being that if the network connection between the TE and PBX is reliable and steady, then UDP is the better choice as it also does not add the overhead that a TCP connection does.

  I suspect the added info by the codec caused the packet to be too large and was therefore fragmented (split into more than one packet); hence the reason to only use that which is needed and discard the others to prevent the possibility. 

  Glad its working.

• 0
  
  Riddhe M October 23, 2019 03:02

  I think it might have something with the firewall to TE. Like the UDP packets beyond a specific rate then the TE firewall drop the packets.. But I dont' see any problem on web in firewall menu. Maybe it's a bug for Yeastar that it had hidden some defense rules.