ConfBridge Dtmf_passthrough=no Doesn’t Have Any Effect. Bug?

Home » Asterisk Users » ConfBridge Dtmf_passthrough=no Doesn’t Have Any Effect. Bug?
Asterisk Users 9 Comments

Hi list!

ConfBridge DTMF_passthrough=no doesn’t seem to have any effect. DTMF
gets transmitted throughout the conference. I’ve tried Asterisk 10.7.1
from the official RPMs and 10.8.0 compiled from source.

I’ve confirmed that it’s disabled via the CLI “confbridge show profile user “.

It’s an all-SIP scenario with RFC2833 as the DTMF protocol.

Is this a known bug?

Thank you!
Markus

9 thoughts on - ConfBridge Dtmf_passthrough=no Doesn’t Have Any Effect. Bug?

  • Searching the issue tracker (hint, hint) does not return any dtmf_passthrough issues other than this one[0], which doesn’t look to be related.

    Is another channel connected to the conference receiving the DTMF? Is that what you’re intending? Because from my understand that is the intention, and not simply to limit the DTMF from being in the conference in the first place. At least that is almost how it reads in your message.

    [0] https://issues.asterisk.org/jira/browse/ASTERISK-20150

  • Hi Leif,

    Am 28.09.2012 13:24, schrieb Leif Madsen:

    thanks for your reply.

    Right, doesn’t look related.

    All I’m trying to achieve is that the rest of the conference doesn’t hear the “beep”‘s when a user presses a key. Users press keys to adjust the volume of the conference, for example. And these key presses get transmitted to all the other users in the conference, which can become quite annoying when there is a larger amount of users.

    Are you refering to my previous mails about adjusting volume of background music/speech in the conference? This is unrelated – in my test scenario I just set up a simple ConfBridge with no features at all, then dialed in via PSTN (arrives as SIP) from two different phones, and on each phone I can hear the key presses of the other party.

    OH! I just tested with a SIP softphone (X-Lite), and DTMF does not get passed to the other users! In X-Lite I can hear the DTMF keypresses of the users connected via PSTN (incoming via SIP), but when I hit a key in X-Lite I can’t hear that on the PSTN phones. Hmmm …

    Thank you!
    Markus

  • I am not referring to your previous posts, but your test and results seem to indicate what I had somewhat thought.

    When you’re using X-Lite, you’re likely using RFC2833 for the DTMF
    method, which is out of band, and gets absorbed by Asterisk by it not playing the DTMF into the conference. This is how it should work (and likely does for most scenarios/phones).

    It sounds like maybe either a configuration or implementation issue on the carrier side though. Are you using inband DTMF there? Asterisk should really be absorbing that too, but sometimes it can’t get it all. If you switch to an out of band method like info or rfc2833, does that help?

    Do you hear the DTMF on a normal call outside of ConfBridge() with the same carrier?

    I suspect this isn’t a ConfBridge() problem, but a general DTMF one. Nice idea on the dtmf_passthrough setting, but it’s not really the solution to your problem here.

  • Hi again Leif,

    Am 28.09.2012 13:42, schrieb Leif Madsen:

    Thanks for the suggestions. (RFC2833 was already set on the SIP peer in question) For further debugging I’ve just done the following tests with these results:

    DID provider 1, incoming via SIP (Germany):

    PSTN to DID to X-Lite, RFC2833: hear DTMF, not logged on console PSTN to DID to X-Lite, inband: hear DTMF, not logged on console PSTN to DID to X-Lite, INFO: hear DTMF, not logged on console

    PSTN to DID to ConfBridge, RFC2833: hear DTMF, LOGGED on console PSTN to DID to ConfBridge, inband: hear DTMF, not logged on console PSTN to DID to ConfBridge, INFO: hear DTMF, not logged on console

    DID provider 2, incoming via SIP (UK and Netherlands):

    PSTN to DID to X-Lite, RFC2833: hear DTMF, LOGGED on console PSTN to DID to X-Lite, inband: hear DTMF, LOGGED on console PSTN to DID to X-Lite, INFO: hear DTMF, not logged on console

    PSTN to DID to ConfBridge, RFC2833: hear DTMF, LOGGED on console PSTN to DID to ConfBridge, inband: hear DTMF, LOGGED on console PSTN to DID to ConfBridge, INFO: hear DTMF, not logged on console

    DID provider 3, incoming via SIP (Nigeria and Kazakhstan):

    PSTN to DID to ConfBridge, inband: hear DTMF, LOGGED on console

    DID provider 4, incoming via SIP (US):

    PSTN to DID to ConfBridge, RFC2833: hear DTMF, LOGGED on console

    X-Lite 3.0 to ConfBridge:

    X-Lite peer is set to dtmfmode=rfc2833 in Asterisk.

    X-Lite force inband YES, RTP 2833 YES: don’t hear DTMF, LOGGED on console X-Lite force inband NO, RTP 2833 YES: don’t hear DTMF, LOGGED on console X-Lite force inband YES, RTP 2833 NO: hear DTMF, not logged on console X-Lite force inband NO, RTP 2833 NO: don’t hear DTMF, LOGGED on console

    The last result is kinda strange. Hm.

    PSTN means that I’ve tested two times, from a regular landline and from a mobile. Always calling to the providers DID which ends up in Asterisk via SIP. In the case of ConfBridge there were always 2 participants in the conference so that I could check if I hear the DTMF on the “other end”.

    “not logged on console” means that I can hear the DTMF tones in X-Lite/ConfBridge but Asterisk doesn’t seem to recognize them (which is fine as not all providers support all DTMF variants).

    My resume is: DTMF is just fine, ConfBridge dtmf_passthrough is not working at all. Agree? 🙂

    Thank you, Markus

  • Markus wrote:

    I think your results are sort of skewed. In the case of SIP < -> SIP if a local bridge occurs things will optimize and you most likely won’t see DTMF related messages. They get passed through as packets and not fully interpreted.

    What log message are you using to determine this?

    I’ve looked at the code for dtmf_passthrough, it’s dead simple and should be working fine PROVIDED your DTMF is not going through as audio.

    My suggestion is to take a step back further.

    Just send incoming calls to the Read application and have it store the received DTMF in a variable. Next step have it output what was received.

    If that works for all cases then Asterisk is recognizing DTMF fine. This does *not* mean that the tone will be muted fully as my previous email mentioned.

    You can further test if all cases check out by sending calls to Record and playing back the audio to yourself. If you hear tones and Asterisk also recognized the DTMF then it’s not fully muted, or the hardware in question is sending *both* inband and out of band, which is not supported.

    Cheers,

  • Hi Joshua,

    Am 28.09.2012 15:56, schrieb Joshua Colp:

    ah, ok! That explains why nothing was logged when testing PSTN to DID to X-Lite, RFC2833, and something was logged when repeating the call to ConfBridge.

    Just by watching the console for DTMF after I press a key (logger.conf:
    console => dtmf). And confirmed by the fact that the DTMF keypress didn’t have any effect (such as adjusting the volume, for example).

    You’re right, I was wrong. It is working, but in my tests only in the X-Lite scenario.

    Ok, good idea, here are the results of Read() and SayDigits():

    DID provider 1, RFC2833: input 123, output 123
    DID provider 1, inband: input 123, output “User entered nothing.”
    DID provider 1, INFO: input 123, output “User entered nothing.”

    DID provider 2, RFC2833: input 123, output 123
    DID provider 2, inband: input 123, output “User entered nothing.”
    DID provider 2, INFO: input 123, ouput “User entered nothing.”

    DID provider 3, RFC2833 1st test: input 123, output 1233
    DID provider 3, RFC2833 2nd test: input 123, output 12333
    DID provider 3, RFC2833 3rd test: input 123, output 123
    DID provider 3, inband: input 123, output 123
    DID provider 3, INFO: input 123, output “User entered nothing.”

    (RFC2833 seems a bit flakey with that provider, thats why I use inband with them.)

    DID provider 4, RFC2833: input 123, output 123
    DID provider 4, inband: input 123, output “User entered nothing.”, but something strange happened here. Console shows:
    channel.c:4143 __ast_read: DTMF begin ‘1’ received on SIP
    channel.c:4147 __ast_read: DTMF begin ignored ‘1’ on SIP
    channel.c:4143 __ast_read: DTMF begin ‘2’ received on SIP
    channel.c:4147 __ast_read: DTMF begin ignored ‘2’ on SIP
    channel.c:4143 __ast_read: DTMF begin ‘3’ received on SIP
    channel.c:4147 __ast_read: DTMF begin ignored ‘3’ on SIP
    channel.c:4143 __ast_read: DTMF begin ‘#’ received on SIP
    channel.c:4147 __ast_read: DTMF begin ignored ‘#’ on SIP
    DID provider 4, INFO: input 123, output “User entered nothing.”, and again the same on the console:
    channel.c:4143 __ast_read: DTMF begin ‘1’ received on SIP
    channel.c:4147 __ast_read: DTMF begin ignored ‘1’ on SIP
    channel.c:4143 __ast_read: DTMF begin ‘2’ received on SIP
    channel.c:4147 __ast_read: DTMF begin ignored ‘2’ on SIP
    channel.c:4143 __ast_read: DTMF begin ‘3’ received on SIP
    channel.c:4147 __ast_read: DTMF begin ignored ‘3’ on SIP
    channel.c:4143 __ast_read: DTMF begin ‘#’ received on SIP
    channel.c:4147 __ast_read: DTMF begin ignored ‘#’ on SIP

    (Asterisk sees the DTMF but doesn’t like it?)

    I don’t see any previous eMail from you on the list and there is nothing in the archives either. Could you re-send it, please? Maybe the info that I’m missing is inside that mail. 🙂

    Ok, here are the results of Record() and Playback():

    DID provider 1, RFC2833: input 123, output hear DTMF (123)
    DID provider 1, inband: input 123, output hear DTMF (123)
    DID provider 1, INFO: input 123, output hear DTMF (123)

    DID provider 2, RFC2833: input 123, output hear DTMF (123)
    DID provider 2, inband: input 123, output hear DTMF (123)
    DID provider 2, INFO: input 123, output hear DTMF (123)

    DID provider 3, RFC2833: input 123, output hear DTMF (123)
    DID provider 3, inband: input 123, output hear DTMF (123)
    DID provider 3, INFO: input 123, output hear DTMF (123)

    DID provider 4, RFC2833: input 123, output hear DTMF (123)
    DID provider 4, inband: input 123, output hear DTMF (just 1 digit)
    (Console showed: DTMF begin passthrough)
    DID provider 4, INFO: input 123, output hear DTMF (just 1 digit)
    (Console showed: DTMF begin passthrough)

    X-Lite, RFC2833 in sip.conf: input 123, output hear NOTHING
    X-Lite, inband in sip.conf: input 123, output hear DTMF (123)
    X-Lite, INFO in sip.conf: input 123, output hear DTMF (123)
    (X-Lite tests only with force inband YES, RTP 2833 YES)

    If I understand right, all my four DID providers are “broken”?

    Thank you!
    Markus

  • Markus wrote:

    Hola,

    How are you changing the DTMF for each provider? If you are merely changing it using dtmfmode in sip.conf this may or may not change how the provider side sends it. In the case of setting it to rfc2833 it causes RFC2833 to be negotiated in the SDP. Some equipment MAY change to using inband if it has not been negotiated.

    I think I wrote the email in my head, oops.

    Essentially when doing conversion of inband DTMF to out of band DTMF it is possible for some parts of tones to get through unmuted. You have to strike a balance between detecting the DTMF early enough, not detecting other stuff as DTMF, and muting it. Some implementations may let some
    “leak” through. The only way to completely overcome that is to buffer enough audio and delay the stream.

    If the provider is doing the conversion their equipment should mute the inband DTMF as best it can and you should not hear it.

    How much of the tone are you hearing?

  • Markus wrote:

    There isn’t. It’s up to them.

    Correct. The equipment doing the conversion may or may not fully remove the tone.

    It’s not completely useless. Some equipment completely removes the tone and life is good. It’s also perfectly fine for IVRs. Where it can fall apart is in this exact situation where you have someone on the other side who shouldn’t hear the DTMF. That’s not often.

    As for the glub I would say that is a partial squelching (muting). It was able to mute most of the tone but not completely.

    Unfortunately there’s nothing I can suggest to help improve the situation, sorry.

  • Am 28.09.2012 17:33, schrieb Joshua Colp:

    Yes, only via dtmfmode in sip.conf. I have no control over the provider side, of course. 🙂 Or are there other options?

    Ah! So because I’m calling from PSTN which is “naturally” inband (I
    guess?) my DID provider (or rather some provider in front of him)
    converts to out of band (RFC2833), but the conversion cannot be fully accurate?

    About the tone itself: it’s always different for each DTMF
    method/provider I would say. Sometimes it’s just a really short “glub”
    (no idea how to describe that better), and sometimes it’s a full-length
    “beeep”. But in any case except for provider 4 inband + INFO I’m hearing all of it (123), so it’s anything from glub-glub-glub to beeep-beeep-beeep. 🙂

    Right now, after what you wrote, I’m left with the feeling that RFC2833
    is pretty much, well, hmm… useless in a PSTN-VoIP scenario? It works fine when using X-Lite, I suppose because there is no conversion involved and therefore the tones can get completely muted.

    I’m sad now. Is there nothing I can do to remove DTMF tones from my conferences? 🙁

    Thank you!
    Markus