[Bug]: Incoming and Missed call log history broken since 5.2.0 on Linux #813
Labels
Comments
|
This is the log from Linphones startup sequence, just missed to post that: |
|
Hi, do you still have the issue after refreshing the page(changing page from chat for example)? |
|
Unfortunately yes – the issue is persistent and I never see any of the old missed/incoming entries and also none of the new ones. Ever. :/ Also the search does not find any of these entries. |
|
Last thing, I don't see any successfully registration sate but, I guess that you are not using the default local account? |
|
I just skipped those lines as I would have to redact so much stuff there. I could not identify any useful information in there either. Do you still need any log?
I have a total of three accounts registered.
|
|
I belive i have similar issue on Linphone 5.2 on Windows, missed call are stored on default sip local account, but not in active proxy account. in active proxy account missed call log are empty. in 5.1.2 no this issue |
|
Thanks to @Olkilv I checked my default SIP account and as he said the incoming and missed call logs for all accounts have been stored there.
An upgrade to Desktop 5.2.1 - Qt5.15.2 / Core 5.3.14 did not change anything in this behaviour. |
hi Olkilv, is there a workaround to see all calls in a single list? (and not switching between the "main" and "proxy" account? I thought I only had 1 account.. |
|
I have the same issue, but on MacOS Sonoma (14.3.1) |
|
Hi, I confirm this behaviour. Missed calls are always listed on the local default account which I am not using. Switching once between the local and the sip proxy account makes them visible on the sip account.
|
|
Hello, Do you have any update on this ? We still have the problem on Desktop 5.2.3 on windows. Best regards |
|
Hi When selecting an account, if they don't display then the call log was simply not associated to this account. |
|
But there seems something wrong if the incoming calls are not assigned to the correct account. 🤔 |
|
Technically, incoming call are assigned to the correct account. I'm still waiting for 5.2.6 logs which illustrate that the address of call logs doesn't correspond to the 'To' headers of SIP packets. Else, the issue remains on the caller side (which don't call the correct account) or the proxy (which change headers). |
|
switching from #831 where something like this was set: Now I've changed the sip-address to With this settings the history for the proxy-account changed to
So this seems to work but: how should we deal with changing IPs? I assume that I'll get a different list when I'm in the office becuase there I'll have an IP like w.x.y.z. 🤔 Is it maybe possible to define multiple sip-adresses in one proxy-account? btw. some of my colleagues are still usimg 5.1.x and don't have this issue - in this version there is a litte phone icon to show the complete history. |
|
Same on Mac and it drives me crazy!! |
Exact same thing is happening with my missed calls, they are showing up under my default SIP IP address account, instead of the SIP account configured for my ITSP, voip.ms. This includes current version linux desktop Appimage 5.2.6 |
|
I wonder why the calls are displayed correctly in the old 5.1.x versions. I enter the absolutely identical SIP account in version 5.1.2 and everything works as I would expect. There must be a difference somewhere in how the two versions handle the calls. |
Obviously there was some regression bug introduced with a later version. You'd think their QA process would have caught this several releases ago, but apparently not. |
|
Hi,
So if you don't get them, then you don't technically call the correct account. It must be a hint to correct your old buggy behavior because user@ipv4, user@localhost, user@ipv6, user@domain are not the same account. That is defined by the RFC. There is no name/ip resolution. As long as you don't use correctly the application, it is not a regression. Logs that we received till now don't match the account while the user think it is. |
|
While you might be technically correct, there are users who have a problem how LinPhone works. Eg I can't change anything on our SIP server's side, so missed calls will never be shown correctly for me. |
|
As long as bugs are coming from third-parties, Linphone don't have to fix them. They should be reported to other parties. Changing the behavior because you want to be a call of B is currently outside of the scope of the application. You should ask it to the sales to reach more technical people because it is more like a feature to be implemented (and it must not be a mess). There is already a workaround by displaying the default account. But if you WANT to have this fixed, please report it to the other party. |
|
The 'P-Asserted-Identity' header (https://www.ietf.org/rfc/rfc3325.txt) can be used on the proxy. |
|
Using Linphone 5.2.6, can you explain what we need to change to the configuration when using an OVH SIP account ? In my settings I have in the "Sip address" : "sip:0033972515187@sbc6.fr.sip.ovh". When I have a call, i see that in the log : So if I understand what you said, the problem is that the "To:" has a value "09XXXXXXXX@10.7.1.60" and not "sip:00339XXXXXXX@sbc6.fr.sip.ovh" ? It's not clear to me sorry... |
|
So, if I understand correctly, if Linphone receives an INVITE with an To header like this : And my account is The call will not be put in my account history ? What needs to match ? account@location ? what's between < and > ? everything ? |
|
I'm sorry, but this is ridiculous. |
If Linphone's position is correct, and the issue is ultimately with the SIP server software not conforming to the RFC, maybe some of us subscribed to this issue can identify the projects and developers who can fix it upstream, and raise the issue with them. I'll try and figure out which server my provider voip.ms is using, and post that info here in the issue. |
|
I did the same with my VoIP provider (inopla / ComDesk) and either the provider itself will post the results here or I will do. So stay tuned 🙏 |
|
My provider (inopla / ComDesk) answered really quick and I'll sum up his answer here: He tested calling internally (directly from one VoIP extension line to another within the same customer account over a speed dial or a "username") getting the following event in the log: Gegenstelle hat aufgelegt. => Remote station has hung up. If an external call is incoming to that number the log entries are different: He assumed that the problem might have to do with the "Notify event count". Incoming call from external number: Incoming call from internal number (extension line): Unfortunately he cannot tell us the software being used as VoIP backend server because of security reasons. Maybe this still helps tracking down this issue? |
|
Just filed a support ticket with Voip.ms, I suspect they will also refuse to identify the SIP server software in use for 'security reasons'. 🫤 Don't even get me started on the futility of 'security via obscurity'. Will update this issue with any pertinent info once I get a cogent response.
|
If you get a minute, could you please link or quote the exact portion of the RFC where SIP vendors are out of compliance with regards to the 'To' header? Will make it easier for those of us opening support tickets with them. I want to pin them down on the issue so they can't pass the buck. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Context
I use Linphone since years on my Linux machine and after upgrading to 5.2.0 the call log history seems to be broken partly. It does not show incoming and missed calls anymore but the outgoing calls are being appended like always.
General information
Expected behaviour
The call log history should also show missed and incoming calls correctly
To Reproduce
Missed call section:
Incoming call section:
The Outgoing call section is up to date:
All three log types were working before updating to 5.2.0 but I really recognized this bug just today 😥
Additional context
Log file:
SDK logs URL
No response
The text was updated successfully, but these errors were encountered: