DTMF bleed through in conference
I'm encountering what I would probably best describe as some bleed through of inbound DTMF when in a conference, and I was wondering if anyone might have suggestions for likely causes or troubleshooting? DTMF detection itself seems fine, and appears to properly be using rfc2833 (the SDPs all show include "a=rtpmap:101 telephone-event/8000"). I get "RTP RECV DTMF" logs for each digit that is recognized. However, a reasonable percentage of the time, some small fraction of the DTMF appears to be heard by the conference as a whole. Never the whole thing, and sometimes it's a bit distorted (though that may just be due to it being so short). Almost as if a small portion of a sound sample makes it through. For testing, I'm using internal phones with direct SIP connections to the switch so no PSTN or gateways involved, though it also occurs with a PSTN caller coming in through multiple gateways. For the internal phones, I've tried both a physical phone through a PAP2T, as well as a PC soft phone. This is with git-868d823 from Jul 29, so a few weeks old but reviewing the more recent commits there weren't any seemingly related to DTMF or conferencing. Any suggestions on places to look or things to try would be most appreciated. -- David
Are the devices that send the DTMFs using 2833? Sounds like possibly they are using inband. I would get a pcap with RTP of the conference and see what, exactly, the device is sending. Some tips for this can be found here: http://wiki.freeswitch.org/wiki/Packet_Capture -MC On Mon, Aug 15, 2011 at 3:48 PM, David Bolen <db3l.net@gmail.com> wrote:
I'm encountering what I would probably best describe as some bleed through of inbound DTMF when in a conference, and I was wondering if anyone might have suggestions for likely causes or troubleshooting?
DTMF detection itself seems fine, and appears to properly be using rfc2833 (the SDPs all show include "a=rtpmap:101 telephone-event/8000"). I get "RTP RECV DTMF" logs for each digit that is recognized. However, a reasonable percentage of the time, some small fraction of the DTMF appears to be heard by the conference as a whole. Never the whole thing, and sometimes it's a bit distorted (though that may just be due to it being so short). Almost as if a small portion of a sound sample makes it through.
For testing, I'm using internal phones with direct SIP connections to the switch so no PSTN or gateways involved, though it also occurs with a PSTN caller coming in through multiple gateways. For the internal phones, I've tried both a physical phone through a PAP2T, as well as a PC soft phone.
This is with git-868d823 from Jul 29, so a few weeks old but reviewing the more recent commits there weren't any seemingly related to DTMF or conferencing.
Any suggestions on places to look or things to try would be most appreciated.
-- David
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
Agreed. Sounds like an analog device not clamping inband DTMF -> RFC 2833 events properly (or quickly enough). Grab a pcap and look at the audio. See if you can see DTMF in the audio stream itself. On Mon, Aug 15, 2011 at 7:09 PM, Michael Collins <msc@freeswitch.org> wrote:
Are the devices that send the DTMFs using 2833? Sounds like possibly they are using inband. I would get a pcap with RTP of the conference and see what, exactly, the device is sending. Some tips for this can be found here: http://wiki.freeswitch.org/wiki/Packet_Capture -MC On Mon, Aug 15, 2011 at 3:48 PM, David Bolen <db3l.net@gmail.com> wrote:
I'm encountering what I would probably best describe as some bleed through of inbound DTMF when in a conference, and I was wondering if anyone might have suggestions for likely causes or troubleshooting?
DTMF detection itself seems fine, and appears to properly be using rfc2833 (the SDPs all show include "a=rtpmap:101 telephone-event/8000"). I get "RTP RECV DTMF" logs for each digit that is recognized. However, a reasonable percentage of the time, some small fraction of the DTMF appears to be heard by the conference as a whole. Never the whole thing, and sometimes it's a bit distorted (though that may just be due to it being so short). Almost as if a small portion of a sound sample makes it through.
For testing, I'm using internal phones with direct SIP connections to the switch so no PSTN or gateways involved, though it also occurs with a PSTN caller coming in through multiple gateways. For the internal phones, I've tried both a physical phone through a PAP2T, as well as a PC soft phone.
This is with git-868d823 from Jul 29, so a few weeks old but reviewing the more recent commits there weren't any seemingly related to DTMF or conferencing.
Any suggestions on places to look or things to try would be most appreciated.
-- David
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
-- Kristian Kielhofner
Kristian Kielhofner <kris@kriskinc.com> writes:
Agreed. Sounds like an analog device not clamping inband DTMF -> RFC 2833 events properly (or quickly enough).
Grab a pcap and look at the audio. See if you can see DTMF in the audio stream itself.
Thanks. I do believe the problem is while tones are using RFC2833. I did some separate in-band testing (manually configuring the PAP2T for in-band and using start_dtmf on the switch) and in that case full tones go through to the conference while also being recognized (though in that case by switch_ivr_async, not switch_rcp). What I hear in the 2833 case is a more truncated/clipped "blip" of sound. I just ran a specific test with two conference participants - blink on a Mac (software sipphone), and an analog phone through a PAP2T. Both connections direct to the FreeSWITCH server, no PSTN gateway involved. I used blink as the DTMF generator. I pressed "4" 4 times in blink, 3 of which (cases 1,2 and 4) were audible blips to the other phone. A summary of the blink outbound rtp is at the bottom. It seems to have the c101 types properly for the presses. Not sure if the occasional repeated sequence number is an issue. The pcap for the outbound leg is entirely c0 rtp types. I used wireshark to generate audio files from the inbound blink leg and the outbound PAP2T leg of the call and verified that the inbound leg from blink to FreeSwitch was silent, while you can clearly hear the brief blips of tones on the outbound leg. So whatever is happening (even if not FreeSWITCH but networking or some other host issue) doesn't appear to be the end device(s). -- David Inbound packets (sipphone -> FreeSWITCH): 17:23:24.954474 udp/rtp 160 c0 6611 197118243 1533652571 17:23:24.973732 udp/rtp 160 c0 6612 197118403 1533652571 17:23:25.053559 udp/rtp 4 c101 * 6613 197118723 1533652571 17:23:25.053588 udp/rtp 4 c101 * 6613 197118723 1533652571 17:23:25.053594 udp/rtp 4 c101 * 6613 197118723 1533652571 17:23:25.098159 udp/rtp 4 c101 * 6614 197118723 1533652571 17:23:25.098389 udp/rtp 4 c101 * 6615 197118723 1533652571 17:23:25.114263 udp/rtp 4 c101 * 6616 197118723 1533652571 17:23:25.114377 udp/rtp 4 c101 * 6617 197118723 1533652571 17:23:25.114392 udp/rtp 4 c101 * 6617 197118723 1533652571 17:23:25.114402 udp/rtp 4 c101 * 6617 197118723 1533652571 17:23:25.127360 udp/rtp 160 c0 6618 197119763 1533652571 17:23:25.142563 udp/rtp 160 c0 6619 197119923 1533652571 17:23:25.157877 udp/rtp 160 c0 6620 197120083 1533652571 17:23:25.241723 udp/rtp 4 c101 * 6621 197120403 1533652571 17:23:25.241751 udp/rtp 4 c101 * 6621 197120403 1533652571 17:23:25.241766 udp/rtp 4 c101 * 6621 197120403 1533652571 17:23:25.260182 udp/rtp 4 c101 * 6622 197120403 1533652571 17:23:25.313686 udp/rtp 4 c101 * 6623 197120403 1533652571 17:23:25.313708 udp/rtp 4 c101 * 6624 197120403 1533652571 17:23:25.313721 udp/rtp 4 c101 * 6624 197120403 1533652571 17:23:25.313728 udp/rtp 4 c101 * 6624 197120403 1533652571 17:23:25.320545 udp/rtp 160 c0 6625 197121363 1533652571 17:23:25.325668 udp/rtp 160 c0 6626 197121523 1533652571 17:23:25.355376 udp/rtp 160 c0 6627 197121683 1533652571 17:23:25.360447 udp/rtp 160 c0 6628 197121843 1533652571 17:23:25.385616 udp/rtp 160 c0 6629 197122003 1533652571 17:23:25.486738 udp/rtp 4 c101 * 6630 197122243 1533652571 17:23:25.486777 udp/rtp 4 c101 * 6630 197122243 1533652571 17:23:25.486826 udp/rtp 4 c101 * 6630 197122243 1533652571 17:23:25.486921 udp/rtp 4 c101 * 6631 197122243 1533652571 17:23:25.492201 udp/rtp 4 c101 * 6632 197122243 1533652571 17:23:25.534484 udp/rtp 4 c101 * 6633 197122243 1533652571 17:23:25.534505 udp/rtp 4 c101 * 6634 197122243 1533652571 17:23:25.534514 udp/rtp 4 c101 * 6634 197122243 1533652571 17:23:25.534519 udp/rtp 4 c101 * 6634 197122243 1533652571 17:23:25.540002 udp/rtp 160 c0 6635 197123283 1533652571 17:23:25.540155 udp/rtp 160 c0 6636 197123443 1533652571 17:23:25.580041 udp/rtp 160 c0 6637 197123603 1533652571 17:23:25.640075 udp/rtp 4 c101 * 6638 197123923 1533652571 17:23:25.640106 udp/rtp 4 c101 * 6638 197123923 1533652571 17:23:25.646655 udp/rtp 4 c101 * 6638 197123923 1533652571 17:23:25.705011 udp/rtp 4 c101 * 6639 197123923 1533652571 17:23:25.710230 udp/rtp 4 c101 * 6640 197123923 1533652571 17:23:25.710259 udp/rtp 4 c101 * 6641 197123923 1533652571 17:23:25.710286 udp/rtp 4 c101 * 6641 197123923 1533652571 17:23:25.710301 udp/rtp 4 c101 * 6641 197123923 1533652571 17:23:25.710313 udp/rtp 160 c0 6642 197124883 1533652571 17:23:25.723594 udp/rtp 160 c0 6643 197125043 1533652571 17:23:25.745100 udp/rtp 160 c0 6644 197125203 1533652571 17:23:25.762744 udp/rtp 160 c0 6645 197125363 1533652571
Could this be a keypad sound that gets picked up by the microphone? -Avi On Wed, Aug 17, 2011 at 12:55 AM, David Bolen <db3l.net@gmail.com> wrote:
Kristian Kielhofner <kris@kriskinc.com> writes:
Agreed. Sounds like an analog device not clamping inband DTMF -> RFC 2833 events properly (or quickly enough).
Grab a pcap and look at the audio. See if you can see DTMF in the audio stream itself.
Thanks. I do believe the problem is while tones are using RFC2833. I did some separate in-band testing (manually configuring the PAP2T for in-band and using start_dtmf on the switch) and in that case full tones go through to the conference while also being recognized (though in that case by switch_ivr_async, not switch_rcp). What I hear in the 2833 case is a more truncated/clipped "blip" of sound.
I just ran a specific test with two conference participants - blink on a Mac (software sipphone), and an analog phone through a PAP2T. Both connections direct to the FreeSWITCH server, no PSTN gateway involved. I used blink as the DTMF generator.
I pressed "4" 4 times in blink, 3 of which (cases 1,2 and 4) were audible blips to the other phone. A summary of the blink outbound rtp is at the bottom. It seems to have the c101 types properly for the presses. Not sure if the occasional repeated sequence number is an issue. The pcap for the outbound leg is entirely c0 rtp types.
I used wireshark to generate audio files from the inbound blink leg and the outbound PAP2T leg of the call and verified that the inbound leg from blink to FreeSwitch was silent, while you can clearly hear the brief blips of tones on the outbound leg. So whatever is happening (even if not FreeSWITCH but networking or some other host issue) doesn't appear to be the end device(s).
-- David
Inbound packets (sipphone -> FreeSWITCH): 17:23:24.954474 udp/rtp 160 c0 6611 197118243 1533652571 17:23:24.973732 udp/rtp 160 c0 6612 197118403 1533652571 17:23:25.053559 udp/rtp 4 c101 * 6613 197118723 1533652571 17:23:25.053588 udp/rtp 4 c101 * 6613 197118723 1533652571 17:23:25.053594 udp/rtp 4 c101 * 6613 197118723 1533652571 17:23:25.098159 udp/rtp 4 c101 * 6614 197118723 1533652571 17:23:25.098389 udp/rtp 4 c101 * 6615 197118723 1533652571 17:23:25.114263 udp/rtp 4 c101 * 6616 197118723 1533652571 17:23:25.114377 udp/rtp 4 c101 * 6617 197118723 1533652571 17:23:25.114392 udp/rtp 4 c101 * 6617 197118723 1533652571 17:23:25.114402 udp/rtp 4 c101 * 6617 197118723 1533652571 17:23:25.127360 udp/rtp 160 c0 6618 197119763 1533652571 17:23:25.142563 udp/rtp 160 c0 6619 197119923 1533652571 17:23:25.157877 udp/rtp 160 c0 6620 197120083 1533652571 17:23:25.241723 udp/rtp 4 c101 * 6621 197120403 1533652571 17:23:25.241751 udp/rtp 4 c101 * 6621 197120403 1533652571 17:23:25.241766 udp/rtp 4 c101 * 6621 197120403 1533652571 17:23:25.260182 udp/rtp 4 c101 * 6622 197120403 1533652571 17:23:25.313686 udp/rtp 4 c101 * 6623 197120403 1533652571 17:23:25.313708 udp/rtp 4 c101 * 6624 197120403 1533652571 17:23:25.313721 udp/rtp 4 c101 * 6624 197120403 1533652571 17:23:25.313728 udp/rtp 4 c101 * 6624 197120403 1533652571 17:23:25.320545 udp/rtp 160 c0 6625 197121363 1533652571 17:23:25.325668 udp/rtp 160 c0 6626 197121523 1533652571 17:23:25.355376 udp/rtp 160 c0 6627 197121683 1533652571 17:23:25.360447 udp/rtp 160 c0 6628 197121843 1533652571 17:23:25.385616 udp/rtp 160 c0 6629 197122003 1533652571 17:23:25.486738 udp/rtp 4 c101 * 6630 197122243 1533652571 17:23:25.486777 udp/rtp 4 c101 * 6630 197122243 1533652571 17:23:25.486826 udp/rtp 4 c101 * 6630 197122243 1533652571 17:23:25.486921 udp/rtp 4 c101 * 6631 197122243 1533652571 17:23:25.492201 udp/rtp 4 c101 * 6632 197122243 1533652571 17:23:25.534484 udp/rtp 4 c101 * 6633 197122243 1533652571 17:23:25.534505 udp/rtp 4 c101 * 6634 197122243 1533652571 17:23:25.534514 udp/rtp 4 c101 * 6634 197122243 1533652571 17:23:25.534519 udp/rtp 4 c101 * 6634 197122243 1533652571 17:23:25.540002 udp/rtp 160 c0 6635 197123283 1533652571 17:23:25.540155 udp/rtp 160 c0 6636 197123443 1533652571 17:23:25.580041 udp/rtp 160 c0 6637 197123603 1533652571 17:23:25.640075 udp/rtp 4 c101 * 6638 197123923 1533652571 17:23:25.640106 udp/rtp 4 c101 * 6638 197123923 1533652571 17:23:25.646655 udp/rtp 4 c101 * 6638 197123923 1533652571 17:23:25.705011 udp/rtp 4 c101 * 6639 197123923 1533652571 17:23:25.710230 udp/rtp 4 c101 * 6640 197123923 1533652571 17:23:25.710259 udp/rtp 4 c101 * 6641 197123923 1533652571 17:23:25.710286 udp/rtp 4 c101 * 6641 197123923 1533652571 17:23:25.710301 udp/rtp 4 c101 * 6641 197123923 1533652571 17:23:25.710313 udp/rtp 160 c0 6642 197124883 1533652571 17:23:25.723594 udp/rtp 160 c0 6643 197125043 1533652571 17:23:25.745100 udp/rtp 160 c0 6644 197125203 1533652571 17:23:25.762744 udp/rtp 160 c0 6645 197125363 1533652571
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
Avi Marcus <avi@avimarcus.net> writes:
Could this be a keypad sound that gets picked up by the microphone?
Yeah, I considered that (wouldn't be the first time I've confused things while running experiments with a bunch of microphones and outputs next to each other), but in past tests, I've muted all input devices in the conference, and still hear it. Not sure I remembered to do that in the test in my last message, so I just re-ran it, with both blink and the PAP2T analog phone muted, and it still occurred. In taking it one step further though, if the leg using DTMF is muted at the conference level (either via the cli or invoking mute through the DTMF bindings), then while DTMF is still recognized, nothing makes it to other participants. Which I guess either means something really is in-band (which doesn't explain my rtp pcap being silent, plus if in-band I'd expect to hear the full tone, since blink, which no analog DTMF detector should be all or nothing) or that flag is indirectly covering up the issue by avoiding whatever processing is putting the glitch on the other participant leg. I'll probably try adding some debugging to mod_conference at a few points to see if I can at least identify where it thinks the audio may be coming from (or at least confirm it thinks there is audio on the muted channel). -- David
even when you have 100% soft phones you hear the blip? Do you hear the blip on every phone? Something in the mix must be doing generated tones or you would not hear them. FS would not just invent them. On Tue, Aug 16, 2011 at 5:55 PM, David Bolen <db3l.net@gmail.com> wrote:
Avi Marcus <avi@avimarcus.net> writes:
Could this be a keypad sound that gets picked up by the microphone?
Yeah, I considered that (wouldn't be the first time I've confused things while running experiments with a bunch of microphones and outputs next to each other), but in past tests, I've muted all input devices in the conference, and still hear it. Not sure I remembered to do that in the test in my last message, so I just re-ran it, with both blink and the PAP2T analog phone muted, and it still occurred.
In taking it one step further though, if the leg using DTMF is muted at the conference level (either via the cli or invoking mute through the DTMF bindings), then while DTMF is still recognized, nothing makes it to other participants. Which I guess either means something really is in-band (which doesn't explain my rtp pcap being silent, plus if in-band I'd expect to hear the full tone, since blink, which no analog DTMF detector should be all or nothing) or that flag is indirectly covering up the issue by avoiding whatever processing is putting the glitch on the other participant leg. I'll probably try adding some debugging to mod_conference at a few points to see if I can at least identify where it thinks the audio may be coming from (or at least confirm it thinks there is audio on the muted channel).
-- David
FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org
-- Anthony Minessale II FreeSWITCH http://www.freeswitch.org/ ClueCon http://www.cluecon.com/ Twitter: http://twitter.com/FreeSWITCH_wire AIM: anthm MSN:anthony_minessale@hotmail.com GTALK/JABBER/PAYPAL:anthony.minessale@gmail.com IRC: irc.freenode.net #freeswitch FreeSWITCH Developer Conference sip:888@conference.freeswitch.org googletalk:conf+888@conference.freeswitch.org pstn:+19193869900
Anthony Minessale <anthony.minessale@gmail.com> writes:
even when you have 100% soft phones you hear the blip? Do you hear the blip on every phone?
Of the two phones in my recent tests, the DTMF originator was the soft phone, the other participant was an analog handset through the PAP2T. Both were muted (locally on the analog phone, and in the software for the soft phone). I can try a test with just multiple soft phones though. I seem to get the exact same thing regardless of DTMF source (soft phone, analog through PAP2T, analog through PSTN independent of gateway) or other participants on the call. So if the tone was in-band, it would have to be multiple similar failures of all those sources. And yes, though I haven't run that as recently, if there are >2 participants I'm pretty sure all others other than the DMTF source hear the blip.
Something in the mix must be doing generated tones or you would not hear them. FS would not just invent them.
That certainly seems to be the simplest/most plausible answer, I just don't know how it could be happening with the softphone as DTMF source since there should be no in-band tone. I did see where mod_conference can have a member flag to replicate DTMF to other participants, but I don't have that on, so I don't think that's it. It would probably be a full tone too, not the brief burst. I'm sure it's got to be explainable, but so far I guess I just haven't looked in the right place. -- David
participants (5)
-
Anthony Minessale
-
Avi Marcus
-
David Bolen
-
Kristian Kielhofner
-
Michael Collins