GNOME Bugzilla – Bug 327988
It is not possible to generate dialtones to manage voicemail
Last modified: 2007-01-02 18:13:46 UTC
Please describe the problem: I'm using Ekiga 1.99.0-20060118 together with sipgate, a german sip provider. They offer a free voice mail system, which is controled by dialtones. So you call the voice mail number, and a voice tells you "press one on your diealpad for new messages" etc. But nothing happens when you hit one (or any oher number) inside ekiga, except that the status bar displays Send DTMF <Number> But the dialtone isn't generated. Steps to reproduce: 1. Start a call 2. Hit any number Actual results: No dialtone beeps Expected results: Does this happen every time? yes Other information:
Ekiga supports DTMFs using RFC2833. Probably sipgate doesn't support RFC2833, but SIP Info, or something else. We do not plan to support SIP Info shortly, but not supporting RFC2833 for a provider such as sipgate is not admissible. Please report the bug to them. I keep the bug assigned to me for further reference, but do not expect any fix before several months. Thanks,
Thank you, i reported that bug to the sipgate support.
Same problem for wengo. I'll report the issue to them too.
I got this answer from sipgate support: -- Es macht leider keinen grossen Sinn sich mit den Entwicklern zusammenzusetzen. Wir unterstützen in der Tat kein RFC (und planen es auch nicht einzuführen), sondern ausschliesslich SIP-INFO. Da die Software dies nicht unterstützt, können sie die Voicemail damit leider nicht nutzen. Die Düsseldorfer Voicemailnummer (0211 58 000 111) unterstützt etwas mehr als die 50000. Sie können diese einmal probieren (vom Sipgateanschluss ebenfalls kostenlos; ansonsten normale Festnetzgebühren). -- In short: We don't support and will never support RFC :(
Damien: is it planned to add an in-band mode support for DTMF too? FWIW, I contacted Wengo and supporting the RFC2833 mode is on their TODO list now.
I plan adding at least SIP INFO support. Not sure for the rest.
*** Bug 332869 has been marked as a duplicate of this bug. ***
From: https://launchpad.net/distros/ubuntu/+source/ekiga/+bug/52610 "When using voicemail with asterisk via ekia I noticed that attempts to enter numbers (extensions, passwords, whatever) with repeated digits would fail. Adding some debug code to asterisk showed that the the repeated digits were being collapsed, e.g. typing 6099 would come through to the other end as 609. If I deliberately paused for a second after entering the first nine, both nines did get through. I got several people to independently reproduce this problem with ekiga so I don't think it's something specific to my setup. I also got several people to test the same thing with non-ekiga clients and no one else could reproduce the duplicate digit lossage."
I am having this problem with Ekiga 2.0.2 as shipped with Fedora Core 6. I am registering to an Asterisk 1.4.0-beta4 server. I added comments and uploaded debug output from the Asterisk console to the Digium bug 8521 (http://bugs.digium.com/view.php?id=8521). According to an Asterisk developer it appears that "the Ekiga RFC2833 packets are awfully broken." It appears from the debug output that Ekiga never says when the digit actually ends. Looking at an RTP debug output from a SIP softphone that works (Twinkle), that assumption seems to be the case. Twinkle sends an RTP RFC2833 end (I may not be stating that in correct developer-speak, but that's what appears to be happening). I will upload both debug outputs as text files to this bug, but just a synopsis: Ekiga DTMF: Got RTP RFC2833 from 192.168.20.1:5028 (type 101, seq 049982, ts 006080, len 000004, mark 0, event 00000005, end 0, duration 00000) Got RTP packet from 192.168.20.1:5028 (type 101, seq 049983, ts 006080, len 000004) Got RTP RFC2833 from 192.168.20.1:5028 (type 101, seq 049983, ts 006080, len 000004, mark 0, event 00000005, end 0, duration 00000) Sent RTP packet to 192.168.20.1:5028 (type 00, seq 018453, ts 012640, len 000160) Sent RTP packet to 192.168.20.1:5028 (type 00, seq 018454, ts 012800, len 000160) Got RTP packet from 192.168.20.1:5028 (type 101, seq 049984, ts 006080, len 000004) Got RTP RFC2833 from 192.168.20.1:5028 (type 101, seq 049984, ts 006080, len 000004, mark 0, event 00000005, end 0, duration 00000) Twinkle DTMF: Got RTP RFC2833 from 192.168.20.1:8000 (type 101, seq 061570, ts 2243930113, len 000004, mark 0, event 00000005, end 0, duration 00640) Sent RTP packet to 10.1.107.131:8000 (type 00, seq 003899, ts 022080, len 000160) Got RTP packet from 192.168.20.1:8000 (type 101, seq 061571, ts 2243930113, len 000004) Got RTP RFC2833 from 192.168.20.1:8000 (type 101, seq 061571, ts 2243930113, len 000004, mark 0, event 00000005, end 1, duration 00800) Got RTP packet from 192.168.20.1:8000 (type 101, seq 061572, ts 2243930113, len 000004) Got RTP RFC2833 from 192.168.20.1:8000 (type 101, seq 061572, ts 2243930113, len 000004, mark 0, event 00000005, end 1, duration 00800) Notice the "end 1" in the output from the Twinkle DTMF. Also, Ekiga doesn't seem to send a duration for the keypress. It looks like Ekiga is not registering key-down, key-up. Again, I'm not a developer, but from a lay-person's view, that seems to be what's happening.
Created attachment 78635 [details] Asterisk SIP and RTP debug from Ekiga phone call Shows DTMF RTP packets from Ekiga client to an Asterisk server.
Created attachment 78636 [details] Asterisk SIP and RTP debug from Twinkle phone call DTMF packets from a Twinkle client connection to an Asterisk server
OK, it is already fixed in CVS since a while.
Is there anyway you can detail what was done in the code to fix this issue? I'd like to backport the fix to the current stable version for Fedora Core. Thanks.
Not sure it is enough, but : http://openh323.cvs.sourceforge.net/openh323/opal/src/sip/sipcon.cxx?r1=2.120.2.19&r2=2.120.2.20 http://openh323.cvs.sourceforge.net/openh323/opal/src/codec/rfc2833.cxx?r1=2.2&r2=2.2.2.1
Perfect. Those patches fixed my Ekiga issue. I'm going to open a Red Hat bugzilla for their build of opal and see if I can get them in. Thanks again.
*** Bug 348171 has been marked as a duplicate of this bug. ***