Solved Yealinks not receiving INVITES while 3cx clients do

[George Ts]

Hello,

We are under the following environment, using all the latest supported releases for each node:
- 3cx SP6 (15.5.15502.6)
- Yealinks T26P 6.73.0.60
- Yealinks T28P 2.3.0.60

A strange issue occurred on the following simple scenario:
Incoming call from SIP trunk to E1 gateway - - > Ring Group of 5 users

Result = Only 3 out of 5 Ring Group users received the call normally to their Yealinks
Two of them only received the call on their 3cx soft clients, not on their Yealinks.

Wireshark traces show that the Yealinks were normally registered during the time of the incoming call (in fact they had registered just a few seconds before the call).
Interestingly, during the call the two Yealinks with the issue never receive an INVITE request: They only receive "TCP SYN" from the 3cx server towards their TCP port 5062, which they reject with "TCP RST,ACK".

Since 3cx initiates those TCP SYNs instead of sending INVITEs over UDP to the Yealinks, I was wondering if this is a known issue.
The attached screenshot could give a better overview of the issue:
Users RG1, RG2 and RG3 receive the call normally on their Yealinks (INVITE over UDP), while users RG4 and RG5 just receive TCP SYNs to their Yealinks.

The respective extensions are all set to accept Multiple calls and Accept Calls from Ring Groups.
Any ideas?

Thank you,
George

 

[Saqqara]

Need more info on the network setup

Are the phones on the same network as the 3CX server (not hosted), if not are the phones using stun or SBC

How are the phones provisioned - manually or 3CX templates

 

[George Ts]

Hello @Saqqara
The phones are contacting 3cx via its LAN interface (no STUN-SBC)
They are provisioned using the latest templates (version 80502) which have only been customized on very few parameters mostly concerning BLFs (irrelevant with the issue).

Important note: Forgot to mention that the issue above does not seem to happen all the time. Those two Yealinks have been receiving calls from Ring Groups normally during other times within the same day.

Please let me know if you need additional information.

Regards,
George

 

[eddv123]

Hi George,

It must be first worth noting that the Yealinks you are using are on the EOL firmware list (although it does not advise as to what firmware version this relates): https://www.3cx.com/sip-phones/

Please also advise why you have a SIP trunk to E1 gateway connection - what is the E1 gateway in place (make and model) and why do you not simply remove it and go straight to SIP trunk ? if this is indeed as I have interpreted SIP Trunk into back of E1 Gateway and output of E1 line.

In regards to the phones which exhibit the issue - does it still occur with a direct call to the extension or is it specifically a ring group issue ?

 

[George Ts]

Hi @eddv123
Well, the term "SIP trunk" was not quite right.
It is a Patton E1 gateway, having an E1 interface with the provider and a SIP interface with 3cx.
For now, we have two occurrences of the issue, both happening within 40 seconds, both for calls received by Ring Groups.
It may be interesting to mention that 3cx is trying to reach those two Yealinks' port 5062 over TCP, which is the exact port from which the Yealinks got registered over UDP, a few seconds before the call.

Regards,
George

 

[eddv123]

OK now it makes sense, you are setting up in the standard format as per: https://www.3cx.com/voip-gateways/patton-sn4940-sn4950-sn4960/

Just as an FYI (and what I was checking for) is that you did not have a setup which some providers are offering (at least in the UK here) where they terminate a SIP trunk in the back of a gateway and present and ISDN out the front (and charge for an ISDN line).

Out of interest also what model of Patton are you using ? the models running smartware (which you can see in the above link) are fully supported where Trinity OS models are not. If it is the case that you are running a Trinity OS model I do have a template for 3CX written by Patton.

The 5062 port is odd, have you set any customized ports when installing ? the only time I have ever known port incrimination is when using remote extensions with the STUN method (the ports can be seen on the extension >> provisioning section.

You can view your default ports under Settings >> Parameters in the PBX, this is a sort of settings search area - just type in a keyword - for example SIP, 5062 etc you could perhaps see if that setting resides anywhere on the PBX itself.

 

[George Ts]

Hi @eddv123
Well, it is just as you describe it (unfortunately):
Provider's SIP server - - > Provider's E1 router gateway - - > Our E1 Patton (SN4970/1E24V) - - > Our SIP 3cx server
We are in the process of migrating to a pure-SIP interconnection with the provider, but in the meantime, they offer the exact setup that you described.
I am not sure though how this could ever trigger 3cx to use TCP towards some specific extensions.
I mean, this is a totally different call leg, which starts from the Ring Group and terminates to the extensions. Please let me know how you suspect that the interconnection with the provider might affect the Yealinks.

As for port 5062, it seems that all Yealinks actually use it and disregard the default port 5060 that the templates advise them to use. This is the explanation that some brief googling gave me:
http://forum.yealink.com/forum/archive/index.php?thread-2967.html
See, it seems that Yealinks have engaged port 5060 for direct IP calls and thus will not use it for the rest of its signaling.

As a proof, please find two screenshots:
One from the template version 80502 that we use and one from one of the two Yealinks that had the issue:
You will see that in both cases, port 5060 (UDP) is advised to be used, however, the Yealinks end up using 5062.

But again, it is not still clear to me why 3cx would try to reach those Yealinks at port 5062 over TCP.
In the second screenshot, you will see that the Yealink is only using UDP for its SIP signaling, which is also confirmed through Wireshark.

Regards,
George

 

[eddv123]

Please let me know how you suspect that the interconnection with the provider might affect the Yealinks.

This setup over here is most common in a back to back situation, Audiocodes gateway from the provider normally into our orovided gateway.

Either way one thing that the Patton's include is a fantastic real time way of tracing the calls so you can at least pin point a little clearer where the issue might lie:

For ISDN (using the command line):

enable
show running‐config
debug call‐router
debug call‐control
debug ccisdn signaling
debug context sip‐gateway signaling detail 5
debug context sip‐gateway transport detail 5
debug context sip‐gateway error

Run the test and then when done enter "no debug all" to stop it running.

But again, it is not still clear to me why 3cx would try to reach those Yealinks at port 5062 over TCP.

Interesting..... I rarely have experienced issues locally in this manner that have never fully investigated as local setup is normally pretty solid, as you are probably aware SIP signalling can be used on either TCP or UDP but most commonly by UDP - I know Skype for business only use TCP now for more reliable signalling sending however it is not a requirement, 3CX should be using UDP by default, unless something has change recently.

 

[complex1]

@George Tsionos,

Please increase the "SIP Session Timer T1" from 0.5s to 1s and try again.

 

[George Ts]

@complex1 I am not aware of a way to change the SIP T1 timer on 3cx. Could you indicate how we do this?
However, I would be a bit cautious before applying such a global change.
But tell me please, how would you expect a change in the T1 timer to resolve this issue?
One interesting thing to notice on my first post's screenshot-trace, is that 3cx tries to reach the two Yealinks over TCP 0.5 seconds later than the rest of the group members (which it successfully reaches over UDP). This looks very well like the T1 timer.


@eddv123 unfortunately it is almost impossible to reproduce this issue and get the logs on the Patton... Like mentioned, it does not happen all the time. Even if I could, I still have not understood how the Patton might affect the call leg between 3cx and the Yealinks. And the heart of the issue, is the fact that 3cx tries to contact the two sole Yealinks via TCP. But thank you for the input anyway, much appreciated.

My rough estimate is that this mostly looks like a 3cx issue. It receives an inbound call to a Ring Group which has a "Ring All" policy, and then tries to reach the RG members. This is where the issue resides, on how 3cx tries to locate the two Yealinks in order to forward the INVITE request to them. How did it figure to use TCP?...

Any more comments/ideas, are more than welcome.
Thank you,
George

 

[complex1]

The timer can be found in the phone or can be set in the template.

Use WUI and go to Settings > SIP > SIP Config

In template:
#Configure the session timer (in seconds), the default value of T1, T2, T3 is 0.5, 4, 5.
account.1.advanced.timer_t1 =
account.1.advanced.timer_t2 =
account.1.advanced.timer_t4 =

 

[George Ts]

Perfect, thank you @complex1
Found the setting under Account -- Advanced -- SIP Session Timer T1
But could you please explain how this could affect the behavior?
How is this related with the fact that 3cx will use UDP instead of TCP?

 

[leejor]

Did the same issue occur, if you place a call to the ring group, from another extension (not a trunk call)?

 

[complex1]

@George Tsionos,

I can't discuss or explain, because I'm not an English speaking person,
but I'm glad the issue is resolved.

 

[eddv123]

Found the setting under Account -- Advanced -- SIP Session Timer T1

but I'm glad the issue is resolved.

There is not an exact confirmation that this issue is resolved - @George Tsionos can you confirm if this setting fixed the issue.

In answer to your question regarding what the SIP session timer does - it normally allows a gateway to check periodically during a call whether the remote gateway is still alive and if the call is still connected on the remote gateway. If the session timer feature detects that the call is no longer connected on the remote side, it will also drop the call locally.

This is normally an optional settings not enabled by default in the Patton devices.

 

[George Ts]

Hi @complex1
The issue has not exactly been resolved. We simply have not managed to reproduce it again.

@leejor it may not happen in ring groups, as well. Unfortunately we have not found a pattern of when it happens. So, either during a direct call to the extension, or during an implicit call as a member of the ring group, the issue will probably not happen. I am still puzzled of why it happened during that one single time.

@eddv123 thank you for the detailed explanation. I was actually aware of the functionality of the T1 timer, and this is why I am even more confused of how this could be related with the fact that 3cx used TCP instead of UDP in order to send the INVITE to the Yealink. Kind reminder, the Yealink was registered over UDP and did not use TCP for its signaling.

Just an idea:
Do you think that the usage of TCP instead of UDP might be related with whether 3cx Phone (soft client) was used as a "Softphone" or as "CTI" ?

Thank you,
George

 

[eddv123]

The whole TCP/UDP thing is a bit odd, the only main differences between the two (as you are probably aware) are:

TCP:

* Transmission Control Protocol or TCP is connection oriented, which means that a formal connection between two end points must be established before any data is transmitted.

* TCP guarantees the delivery of data, and it also guarantees that data packets will be delivered in the same order in which they were sent.

UDP:

* UDP is connection-less, which means that data packets can be sent without warning, preparation, or negotiation.

* Packets can be delivered in an incorrect order, but they can also get completely left out.

With that being said UDP is meant for applications where you are more concerned with keeping the stream of information going than making sure you receive every single packet. This makes UDP ideal for real-time services such as Voice over IP.

FYI SCTP is another transport protocol which is great for VoIP (and is a combination of both TCP and UDP) and offers multiple calls per stream. This is used commonly in the carrier sector but had unfortunately come out too late to be adopted widely.

Do you think that the usage of TCP instead of UDP might be related with whether 3cx Phone (soft client) was used as a "Softphone" or as "CTI" ?

UDP for a standard deskphone (without CTI) I think would be fine. When you are talking about soft-client and CTI mode the client resides on a desktop PC and thus may be better utilizing TCP.

 

[George Ts]

Hi @eddv123
Just in order to clarify, I mentioned the 3cx soft client because the Yealink users were registered from their 3cx soft clients at the same time.
The incoming calls to the ring group reached their 3cx clients, but not the Yealinks, as mentioned in my first post.
3cx server tried to reach both the 3cx soft clients and the Yealinks over TCP.
Of course, the Yealinks failed.
So, my very first question persists: Why did 3cx use TCP in order to reach the Yealinks?
By any chance, may this have happened if users were using CTI instead of Softphone in their 3cx clients?
In other words: Does the 3x phone for Windows mode (CTI or Softphone) affect the protocol (UDP or TCP) that 3cx server will use in order to reach the Yealinks?

Thank you,
George

 

[eddv123]

Apologies if my response was not clear enough.

Generally my thoughts are that 3CX would default to UDP (unless any changes I am not aware of have been introduced). The reason I say this is that not all VoIP devices support TCP, UDP is still the commonly used protocol for VoIP (although TCP is making ground).

For TCP/UDP settings in the client check under the Settings/Advanced settings section of the client itself.

The only additional point I would make is in regards to encryption. TCP is used when traffic is encrypted, i.e. TLS is used. TLS uses port 5061 normally.

 

[George Ts]

Hi @eddv123
No worries, your answer was perfectly clear and thank you for providing this
It just does not answer my question, as it is generic and not specific to what happened in my scenario.

I know that SIP uses mostly UDP, and can use TCP as well.
I know that TCP is used when TLS is also used.

I just do not know why 3cx server choosed to use TCP in my specific scenario, at the same time that the Yealinks were registered over UDP.

If anyone has any thoughts of why this may have happened, please let me know.

Thank you,
George