2 thoughts on - Chan_pjsip: DTMF Mode “auto_info” On Endpoints

• Have you bumped up the core debug to see what’s going on underneath? There will be information about whether it is really generating the DTMF in the core, and if so then it’d be a result of the digit_begin function of chan_pjsip returning a value it shouldn’t.

  —
  Joshua Colp Digium – A Sangoma Company | Senior Software Developer
  445 Jan Davis Drive NW – Huntsville, AL 35806 – US
  Check us out at: http://www.digium.com & http://www.asterisk.org

  —

• Yeah, I did enable core debug level 5 but I don’t get something that would point me in the right direction.

  [“2018-09-26 11:39:28.6507”] DTMF[105612][C-00000001] channel.c: DTMF end ‘1’ received on PJSIP/XXXXX-00000001, duration 250 ms
  [“2018-09-26 11:39:28.6507”] DTMF[105612][C-00000001] channel.c: DTMF begin emulation of ‘1’ with duration 250 queued on PJSIP/XXXXX-00000001
  [“2018-09-26 11:39:28.9137”] DTMF[105612][C-00000001] channel.c: DTMF end emulation of ‘1’ queued on PJSIP/XXXXX-00000001
  [“2018-09-26 11:39:28.9139”] DEBUG[105597][C-00000001] chan_pjsip.c: Told to send end of digit on Auto-Info channel PJSIP/XXXXX-00000000 RFC4733 NOT negotiated using INFO instead.
  [“2018-09-26 11:39:28.9139”] DEBUG[105391] res_pjsip_session.c: Method is INFO

  Here’s my plan now:
  The chan_pjsip_digit_begin() function in channels/chan_pjsip.c does not have any debug output in the code, only chan_pjsip_digit_end() does and I do see that in the log. Maybe I need to insert additional debug statements in chan_pjsip_digit_begin() and see if it’s really doing the right stuff in the case AST_SIP_DTMF_AUTO_INFO. Another step would probably be then to have a look into ast_rtp_instance_dtmf_begin().

  By the way I forgot to mention that Asterisk actually does send SIP INFO with DTMF to Endpoint B (which is what is expected) but it seems that the inband audio is added additionally (which is a problem).

  With best regards

  Florian Floimair Innovation – Software-Development

  COMMEND INTERNATIONAL GMBH
  A-5020 Salzburg, Saalachstraße 51
  http://www.commend.com <http://www.commend.com/>

  Security and Communication by Commend

  FN 178618z | LG Salzburg

  Am 26.09.18, 15:47 schrieb “asterisk-users im Auftrag von Joshua Colp” :

  > Hey all!
  >
  > I recently tried the dtmf_mode “auto_info” on my setup to support
  > endpoints that only understand SIP INFO as a fallback.
  >
  > My setup is the following:
  >
  > Endpoint A (RFC4733) –> Asterisk <-- Endpoint B (SIP INFO) >
  > Both are configured with “auto_info” dtmf_mode in pjsip.conf.
  > What I ran into is, that DTMF sent from endpoint A to endpoint B is
  > additionally sent via inband audio on the RTP stream from Asterisk to
  > endpoint B, as one can clearly hear the DTMF tone in the audio stream,
  > when a capture is played back on Wireshark. On the leg from endpoint A
  > to Asterisk there is no inband DTMF signal in the RTP audio stream.
  >
  > Can someone confirm this behavior? If yes than this is clearly a bug.
  > I had a look in the code which introduced this feature and couldn’t find
  > anything obvious why this is happening.

  Have you bumped up the core debug to see what’s going on underneath? There will be information about whether it is really generating the DTMF in the core, and if so then it’d be a result of the digit_begin function of chan_pjsip returning a value it shouldn’t.