Yealink T41P phone does not ring when dialed directly from number with "," in caller-id

[caldwell]

Weird issue I discovered in working at a customer site to debug an issue for them. Details follow:

The 3CX system is set as auto-update. It is a "Pro" level license.

Firmware on Yealink phones are MANUALLY upgraded only as needed (could be months between firmware upgrades). Currently, they are on the latest firmware and have been for some time.

Some time in the past 2-3 (?) months, some of their clientele began complaining that they could not get through the phone system from external calls by dialing DIRECTLY to individual extensions. After questioning from me, they began to write the names/numbers down. Yesterday, I had a chance to visit the site and begin debugging.

I spent time having one lady (we'll call her Sue) call in repeatedly to test. Here is what I have found when she calls the 3CX system:

1. When Sue tries to call an extension directly (x272) with a Yealink T41P with latest 3CX supported firmware, the call NEVER rings the extension. Never.

2. The logs indicate that 3CX has built the call, sent the SIP packet and has tried to reach x272.

3. 20 seconds go by (per the settings on the extension), and then the call gets sent back to a general queue.

4. The call then gets sent to a phone in the queue (x232) where it is then answered.

5. If Sue calls another extension directly (x260) with a Yealink T48S (not a T41P) with latest 3CX supported firmware, the call rings immediately.

6. If Sue calls another extension directly (x221) with a Yealink T41S (not a T41P) with latest 3CX supported firmware, the call rings immediately.

7. If the lady tries to call the queue and waits, the call will rings x272 -IF IT IS COMING FROM THE QUEUE-.

8. The different models of Yealink phones are obviously running different firmware since they are not the same model. But it's worth noting that only the T41P phones running 38.83.0.130 have the issue.

9. I tried downgrading x272 to 38.83.0.120 and then further down to 38.83.0.50, but this did NOT affect the behavior.

10. As a further twist to all of this, upon spending times working through the debug logs, I found that ALL OF THE PEOPLE who have problems calling one of these extensions directly have a COMMA (",") in their caller-id data. Here are examples of caller-id which work and which fail when calling directly:

CAN call directly to x272:
From: "423505xxxx" <sip:[email protected]:5060;nf=e>;tag=83e40c56

CANNOT call directly to x272:
From: "423479xxxx"<sip:Lastname,[email protected]:5060;nf=e>;tag=9b3b8115

As noted above, when we began to look through logs at the names/caller-ids of all the people complaining about this problem, every single one of them have a comma in the caller-id name.

11. In the SIP packets sent to the phone, this appears like so:

03/12/2020 2:12:02 PM - Route to L:55.3[Extn:272] sends Invite-OUT Send Req INVITE from 0.0.0.0:0 tid=92c49b61135dc472 Call-ID=FpKe_y4FiclztHzt0QXY_Q..:
INVITE sip:[email protected]:5060 SIP/2.0
Via: SIP/2.0/ ;branch=z9hG4bK-524287-1---92c49b61135dc472;rport
Max-Forwards: 70
Contact: <sip:Lastname,[email protected]:5060>
To: <sip:[email protected]>
From: "423479xxxx"<sip:Hysinger,[email protected]:5060;nf=e>;tag=9b3b8115
Call-ID: FpKe_y4FiclztHzt0QXY_Q..
CSeq: 1 INVITE
Alert-Info: <http://www.notused.invalidtld>;info=external
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REGISTER, SUBSCRIBE, NOTIFY, REFER, INFO, MESSAGE, UPDATE
Supported: replaces, timer
Referred-By: <sip:[email protected]>
Content-Length: 0

These people have not ALWAYS had this issue and have, in fact, been able to call directly for the past few years since setting up the 3CX system. The customer does not know when it started exactly. Logs don't likely go back that far. Sometime in the past 3 months, so presumably due to an auto-update of 3CX.

My best guess is that this is an issue with 3CX and how it handles/write the SIP packets to the phones.

OR, a second guess is that in the Yealink firmware 38.83.0.xxx for the T41P phones, it cannot handle the comma.

Either way, this appears to be a bug and not a direct support ticket issue. I could not fathom a support technician receiving this and saying, "Click this GUI setting, and it will fix this." I would be happy to be proven wrong on this, however.

 

[leejor]

Actually this is not the first time a "comma in caller ID" issue has come up. In the past it has been issues with caller ID from some providers, and some cases involving an SPA-3102.

If you do a Google search, you will find that 3CX, or Yealinks are not the only ones that have been affected. Is there a specific reason you use the comma, or put the last name first?

 

[caldwell]

The caller-id is being sent from the calling party's carrier and then (ultimately) passed via the SIP provider along the trunk. The customer's 3CX system is only receiving what is sent. So, "is there a specific reason you use the comma" is not a relevant question. Asking why providers send it may be relevant. Or asking what can be done in the 3CX system to strip, fix, ignore or work around it is what I'm trying to find out.

 

[cobaltit]

If it's caller-id reformatting you want to try you can follow this:

https://www.3cx.com/docs/cid-reformatting/

Can't say I've ever seen a comma in caller-id as I believe only alpha characters are allowed, at least in the US. Sometimes on-net calls are a little looser with the CID rules so it might be a conversation with the carrier.

 

[leejor]

Sorry, my bad, I had it in my mind that it was internal calls.

Although I can't find anything on a comma being specifically prohibited in CNAM, it is not commonly seen, as many major providers, using their own database will list personal names as... first last. Your provider may use a "low cost" company to do the CNAM "DIP".

 

[caldwell]

Here's what the SIP trunk provider said:

That's super-ugly. And massively bone headed, given the long established URI requirements.

Now, technically CNAM is supposed to be alpha-numeric only, with the addition of a space (' ') - but most companies will return location data at a minimum so the number of calls flying around with "FL, TAMPA" and "GA, ATLANTA" as names is too massive to consider. And lots of places stick characters that shouldn't be in CNAM in CNAM anyway (Underscores, dashes, I've even seen exclamation points).

Anyways, long story short, my brain aches from how stupid that is, but I kludged the dialer on the inbound box to strip "," from the text section of the To headers - aka, Caller ID Name/CNAM for the customer's trunks. Please test and let me know if you see anything odd.

But 3CX is failing RFC compliance by bombing on this, so it's squarely at fault with this one.

The 'name' portion of a URI can contain commas legally - as well as all sorts of other things - whether it's passing calls from the PSTN or direct machine-to-machine SIP which might have all sorts of identifiers there, it needs to support this properly. It's an embarrassing bug.

So, the short news is, he is stripping the comma, and the external users can call extensions directly again.

The bad news is, no idea if 3CX cares to fix this bug -- or if it's really a Yealink bug.

Either way, it would be nice for someone from 3CX to show some interest.

End customers shouldn't have to pay for support for bug fixes.

 

[cobaltit]

So I don't know if that answer is correct. Your provider is saying the name part can contain a comma, but in your example, the comma is in the user part, not what would be considered the name part.

So my interpretation of his explanation is that this is ok:

From: "Lastnam, Firstname"<sip:1234@192.168.21.228:5060;nf=e>;tag=9b3b8115

But your example is:
From: "423479xxxx" <sip:Lastname, Firstname@192.168.21.228:5060;nf=e>;tag=9b3b8115

But that may be easily corrected but adjusting the inbound parameters of the trunk which I assume is unsupported given that this thread exists.

 

[leejor]

Unfortunately, your provider believes that it is a 3CX issue where it would appear to be a particular set problem. 3CX is simply passing on the caller Id as received. I would be following up with Yealink (possibly on their forum) , as some of their sets firmware versions already seem to be able to handle the comma.