Details

    • Type: Bug
    • Status: Resolved
    • Priority: Minor
    • Resolution: Fixed
    • Affects Version/s: None
    • Fix Version/s: 1.8
    • Component/s: mod_sofia
    • Security Level: public
    • Labels:
      None
    • CPU Architecture:
      x86-64
    • Kernel:
      Linux
    • Userland:
      GNU/Linux
    • Distribution:
      Debian
    • Distribution Version:
      Debian 8 jessie
    • Compiler:
      gcc
    • FreeSWITCH GIT Revision:
      Version 1.7.0 git 2b1f0da 2016-09-23 20:50:47Z 64bit
    • GIT Master Revision hash::
      2b1f0da

      Description

      When receiving (INVITE) a dynamic payload type of 97 like so:
      m=audio 7446 RTP/AVP 8 0 97
      a=rtpmap:97 telephone-event/8000

      FreeSWITCH answers (200 OK) by forcing payload type 101 like so:
      m=audio 10442 RTP/AVP 8 101
      a=rtpmap:101 telephone-event/8000

      And ignores any DTMF received with payload type 97.


      Apparently it is "widely understood" that the reply should keep the proposed dynamic payload.

      See: https://www.ietf.org/mail-archive/web/sip/current/msg27927.html
      "It doesn't quite say that the offerer must send with a pt listed in the answer, but its clear for consistency that it should. That is widely understood to be the intent."

        Activity

        Hide
        mikej Mike Jerris added a comment -
        FreeSWITCH by default mirrors back the pt for this exact reason. This could happen in proxy mode or bypass mode if the other endpoint is doing this. Can you tell us more about what settings you have for setting up this call, and include debug logs.
        Show
        mikej Mike Jerris added a comment - FreeSWITCH by default mirrors back the pt for this exact reason. This could happen in proxy mode or bypass mode if the other endpoint is doing this. Can you tell us more about what settings you have for setting up this call, and include debug logs.
        Hide
        francois François added a comment -
        See relevant parts of log in pastebin including received SDP and local SDP:
        https://pastebin.freeswitch.org/view/661fdd9c

        The most interesting part seems to come when parsing the incoming SDP, we can see that it detects "telephone-event payload 97@8000" but sets "2833 dtmf send payload to 101 recv payload to 101"

        [DEBUG] switch_core_media.c:4299 Audio Codec Compare [PCMA:8:8000:20:64000:1]/[PCMA:8:8000:20:64000:1]
        [DEBUG] switch_core_media.c:4354 Audio Codec Compare [PCMA:8:8000:20:64000:1] ++++ is saved as a match
        [DEBUG] switch_core_media.c:4299 Audio Codec Compare [PCMU:0:8000:20:64000:1]/[PCMA:8:8000:20:64000:1]
        [DEBUG] switch_core_media.c:4215 Set telephone-event payload to 97@8000
        [DEBUG] switch_core_media.c:3019 Set Codec sofia/192.168.10.200/262086050@187.239.216.12:5060 PCMA/8000 20 ms 160 samples 64000 bits 1 channels
        [DEBUG] switch_core_codec.c:111 sofia/192.168.10.200/262086050@187.239.216.12:5060 Original read codec set to PCMA:8
        [DEBUG] switch_core_media.c:4560 Set telephone-event payload to 97@8000
        [DEBUG] switch_core_media.c:4619 sofia/192.168.10.200/262086050@187.239.216.12:5060 Set 2833 dtmf send payload to 101 recv payload to 101
        Show
        francois François added a comment - See relevant parts of log in pastebin including received SDP and local SDP: https://pastebin.freeswitch.org/view/661fdd9c The most interesting part seems to come when parsing the incoming SDP, we can see that it detects "telephone-event payload 97@8000 " but sets "2833 dtmf send payload to 101 recv payload to 101" [DEBUG] switch_core_media.c:4299 Audio Codec Compare [PCMA:8:8000:20:64000:1]/[PCMA:8:8000:20:64000:1] [DEBUG] switch_core_media.c:4354 Audio Codec Compare [PCMA:8:8000:20:64000:1] ++++ is saved as a match [DEBUG] switch_core_media.c:4299 Audio Codec Compare [PCMU:0:8000:20:64000:1]/[PCMA:8:8000:20:64000:1] [DEBUG] switch_core_media.c:4215 Set telephone-event payload to 97@8000 [DEBUG] switch_core_media.c:3019 Set Codec sofia/192.168.10.200/262086050@187.239.216.12:5060 PCMA/8000 20 ms 160 samples 64000 bits 1 channels [DEBUG] switch_core_codec.c:111 sofia/192.168.10.200/262086050@187.239.216.12:5060 Original read codec set to PCMA:8 [DEBUG] switch_core_media.c:4560 Set telephone-event payload to 97@8000 [DEBUG] switch_core_media.c:4619 sofia/192.168.10.200/262086050@187.239.216.12:5060 Set 2833 dtmf send payload to 101 recv payload to 101
        Hide
        mikej Mike Jerris added a comment -
        please attach full debug log as .txt file to the jira
        Show
        mikej Mike Jerris added a comment - please attach full debug log as .txt file to the jira
        Hide
        mikej Mike Jerris added a comment -
        with sip trace enabled
        Show
        mikej Mike Jerris added a comment - with sip trace enabled
        Hide
        francois François added a comment -
        Hi Mike, I think i know how to reproduce and how to fix this issue (pending tests and patch).

        I have a profile variable "dtmf_type" set to "none" to force a default value, like so:
        <variable name="dtmf_type" value="none"/>

        Apparently, FS ignores the variable "dtmf_type" set in the channel and always uses the profile's "dtmf_type".

        It seems ok because sofia_glue calls this function that parses the variable:
        switch_core_media_check_dtmf_type(session);

        But it does so too early because the media handle and its parameters are initialized *after*, so the values are reset to profile default:
        switch_media_handle_create(&tech_pvt->media_handle, session, &tech_pvt->mparams);

        The fix would be to just move the "switch_core_media_check_dtmf_type" call *after* creating the media handle.
        Show
        francois François added a comment - Hi Mike, I think i know how to reproduce and how to fix this issue (pending tests and patch). I have a profile variable "dtmf_type" set to "none" to force a default value, like so: <variable name="dtmf_type" value="none"/> Apparently, FS ignores the variable "dtmf_type" set in the channel and always uses the profile's "dtmf_type". It seems ok because sofia_glue calls this function that parses the variable: switch_core_media_check_dtmf_type(session); But it does so too early because the media handle and its parameters are initialized *after*, so the values are reset to profile default: switch_media_handle_create(&tech_pvt->media_handle, session, &tech_pvt->mparams); The fix would be to just move the "switch_core_media_check_dtmf_type" call *after* creating the media handle.
        Hide
        francois François added a comment -
        Show
        francois François added a comment - Pull-req added, currently compiling for tests: https://freeswitch.org/stash/projects/FS/repos/freeswitch/pull-requests/987/
        Hide
        francois François added a comment -
        Last pull-req did not work for inbound calls.

        Adding new pull-req that checks for the dtmf_type variable whenever negociating SDP (as is done with liberal_dtmf and other variables):

        https://freeswitch.org/stash/projects/FS/repos/freeswitch/pull-requests/1007/overview
        Show
        francois François added a comment - Last pull-req did not work for inbound calls. Adding new pull-req that checks for the dtmf_type variable whenever negociating SDP (as is done with liberal_dtmf and other variables): https://freeswitch.org/stash/projects/FS/repos/freeswitch/pull-requests/1007/overview

          People

          • Assignee:
            mikej Mike Jerris
            Reporter:
            francois François
          • Votes:
            0 Vote for this issue
            Watchers:
            2 Start watching this issue

            Dates

            • Created:
              Updated:
              Resolved:

              Development