Ever since upgrading to V20, yealink phones have had some difficulty dialling back numbers from their call history.
Their call history contains 'Caller ID's, which, as far as I can understand, are not actually 'phone numbers' in a SIP message, but just pieces of text that can be just about anything, but in practice contains phone numbers. They can also be overwritten/rewritten by SIP providers, and many, in fact, do so, so does ours. They do provide some settings to adjust the behaviour for compatibility reasons, but not enough to reliably solve issues like this: 3CX has to, ideally, deal with whatever strange thing the service provider sends it (the whole "Be liberal in what you accept and convervative with what you emit" programming guideline).
Anyhow, this number gets shunted into the phone's history table, and, when the user lazily redials using the history rather than recalling the number from memory or their address book, this 'caller ID' is dialled. Obviously, users expect this to work. It did, prior to the V20 upgrade.
After looking into it by turning up the log verbosity a notch, I found that the phones on the upgrade test customer (ourselves) were receiving a "dialled number has no route" error from the PBX, which was the reason for being unable to call back. Manually pressing the number i.e. '0101234567' on the phone's buttons still works, as does manually pressing the international equivalent number on the phone, i.e. '0031101234567. Of course, that's not what our SIP provider is sending back as the caller ID, it's sending '+31101234567', which, as far as computers, who are not humans, are concerned, is something entirely different from '0031101234567'
So this 'strange' E164 string (from the code's perspective) that isn't a proper phone number is supposed to go through four systems, in and back out, without getting mangled: from the original caller's phone to their VOIP provider, then to our VOIP provider, then the PBX, then SBC, then the phone. When the call happens from history, this data goes from the phone, then to the SBC, then the PBX, then finally the VOIP provider, but it's dropped at the PBX stage on the way out (as I see the error there). At this point the number has morphed into '31310101234567'. (Notice that the country code is there twice, but without an international dial prefix). I "fixed" the problem by creating an outbound rule that changes all numbers with >10 digits that start with '3131' by stripping 2 digits and replacing them with '00'. I don't like this 'fix', as it's really a silly hack, for if there are other phones without the bug, my fix will make them unable to redial any local numbers that just so happen to start with the international dial code (and I checked, they exist, several localities in fact).
On the phone (a yealink T4xx), the example number would show as '+31101234567', if that's any help. (You can't manually dial those, but you can press 'OK' in the history view to still do so).
I wonder if anyone has seen a similar problem, and, if so, what they've done to resolve it.
.
Their call history contains 'Caller ID's, which, as far as I can understand, are not actually 'phone numbers' in a SIP message, but just pieces of text that can be just about anything, but in practice contains phone numbers. They can also be overwritten/rewritten by SIP providers, and many, in fact, do so, so does ours. They do provide some settings to adjust the behaviour for compatibility reasons, but not enough to reliably solve issues like this: 3CX has to, ideally, deal with whatever strange thing the service provider sends it (the whole "Be liberal in what you accept and convervative with what you emit" programming guideline).
Anyhow, this number gets shunted into the phone's history table, and, when the user lazily redials using the history rather than recalling the number from memory or their address book, this 'caller ID' is dialled. Obviously, users expect this to work. It did, prior to the V20 upgrade.
After looking into it by turning up the log verbosity a notch, I found that the phones on the upgrade test customer (ourselves) were receiving a "dialled number has no route" error from the PBX, which was the reason for being unable to call back. Manually pressing the number i.e. '0101234567' on the phone's buttons still works, as does manually pressing the international equivalent number on the phone, i.e. '0031101234567. Of course, that's not what our SIP provider is sending back as the caller ID, it's sending '+31101234567', which, as far as computers, who are not humans, are concerned, is something entirely different from '0031101234567'
So this 'strange' E164 string (from the code's perspective) that isn't a proper phone number is supposed to go through four systems, in and back out, without getting mangled: from the original caller's phone to their VOIP provider, then to our VOIP provider, then the PBX, then SBC, then the phone. When the call happens from history, this data goes from the phone, then to the SBC, then the PBX, then finally the VOIP provider, but it's dropped at the PBX stage on the way out (as I see the error there). At this point the number has morphed into '31310101234567'. (Notice that the country code is there twice, but without an international dial prefix). I "fixed" the problem by creating an outbound rule that changes all numbers with >10 digits that start with '3131' by stripping 2 digits and replacing them with '00'. I don't like this 'fix', as it's really a silly hack, for if there are other phones without the bug, my fix will make them unable to redial any local numbers that just so happen to start with the international dial code (and I checked, they exist, several localities in fact).
On the phone (a yealink T4xx), the example number would show as '+31101234567', if that's any help. (You can't manually dial those, but you can press 'OK' in the history view to still do so).
I wonder if anyone has seen a similar problem, and, if so, what they've done to resolve it.
.
Last edited:
