Using ring-kde 3.0.0 as SIP client. When attempting to dial password for voicemail, or dial pin for joining a bridge line, tones are not heard, and sometimes are not accepted by the destination STEPS TO REPRODUCE 1. Setup SIP account 2. Dial access number for voicemail 3. Dial pin number for mailbox OBSERVED RESULT when dialing a SIP number, a tone is heard for the first number but not the rest of the numbers. Once the call connects and the voicemail or bridge asks for the pin, tones for typing numbers are not heard, sporadically the voicemail pin will be taken EXPECTED RESULT Expect all tones to be heard to verify they were taken by the software and passed to the voicemail server SOFTWARE VERSIONS Kubuntu Xenial KDE Plasma Version: 4:5.8.9 KDE Frameworks Version: 5.36.0 Qt Version: 5 ADDITIONAL INFORMATION
Tested on KDE Neon current. dial tones are heard but not being accepted.
Have you tried to toggle between RTP and SIP DTMF modes? For some providers, one work and the other doesn't. Not saying this isn't a bug, these features come from the ring-daemon and that part of the code has decayed in recent years.
On my old Xenial system I am now able to enter the DTMF tones and get into voicemail and my bridge line. I cannot hear the tones when I type them, but it seems to be taking them. I'm not really sure what I've changed in the config, but the DTMF is currently set to Over SIP. On my newer KDE Neon system, I can sometimes hear the tones, or some of the tones, but they are not being accepted the DTMF is set to Over SIP on this machine also. I've attempted to change this to Over RTP but that option will not save, and is always reverted to Over SIP.
Are both systems using Ring-KDE 3.0? Did you use the AppImage or the system packages? If you didn't use the AppImage, try the AppImage on both systems (make sure to kill all `dring` process and ring-kde first or it wont start). If it works on one system and not the other one and the only change is the ring-daemon version, then the bug must be reported at ring.cx.
Both Systems are using the ring-kde_3.0.0_x86_64.AppImage Initally both systems would not allow me to dial the DTMF codes to get into my voicemail. I've made a bunch of changes to the config on the old system, and quit the app and restarted it and the DTMF codes are somewhat working on it now. I can't hear the tones but the system seems to be taking them. On the newer kde neon machine I've tried to match all my settings from the old machine. This machine I can sometimes hear the tones, sometimes all tones, sometimes just a couple of the tones, but the voicemail system seems to never take the tones advising that they are invalid.
Umm, it makes little sense. You you try to move the ~/.config/ring/dring.yml from the working machine to the not working one (with backup, of course). The way AppImage works is that they ship all dependencies internally. In theory, it should behave exactly the same on all systems (beside things like screen resolution, DPI and color scheme, of course). This probably fall into "there is too many config variables because each SIP provider do things differently and users get lost" category.
I agree it does not make a lot of sense. I asked a colleague of mine to download the appimage (he is also running kde neon) and he also advised that he was not able to get DTMF tones to be taken by the phone system. I did not know about the .config/ring/dring.yml I was copying everything from .local/share/ring, and .local/share/kde-ring. I just copied it from my old machine to my kde neon machine and now it appears that DTMF codes are now being accepted. I didn't hear all of the tones but it did log me in to my bridge line.
Maybe you could `diff` the 2 files and get an idea what went wrong. Otherwise I assume i can close this bug? The old config dialog will be gone in v3.2 to make way for the one compatible with Android and Plasma mobile. Maybe I can work out something with the KDE VDG to make it less confusing. I don't want to go down the rabbit hole of making templates per provider. It is too hard to maintain and will always fall out of sync with their changes. SIP is a very flexible, but complex, protocol. Just for DTMF, there is 3 totally incompatible modes (ok, 2.5 modes, analog and RTP are close). And yet, it's one of the simplest part of it all.
looking more at the dring.yml file that you suggested, it appears that the gui is not actually saving the DTMF setting. In my working config the dring.yml is correctly showing dtmfType: oversip In the config that is not working, the gui is showing "Over SIP", but when checking the dring.yml, it still shows dtmfType: overrtp changing this in the gui does not keep "Over RTP", but seems to default to it in the config.
Dear Bug Submitter, This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information as soon as possible and set the bug status as REPORTED. Due to regular bug tracker maintenance, if the bug is still in NEEDSINFO status with no change in 30 days the bug will be closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging If you have already provided the requested information, please mark the bug as REPORTED so that the KDE team knows that the bug is ready to be confirmed. Thank you for helping us make KDE software even better for everyone!
This bug has been in NEEDSINFO status with no change for at least 30 days. The bug is now closed as RESOLVED > WORKSFORME due to lack of needed information. For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging Thank you for helping us make KDE software even better for everyone!