Uploaded image for project: 'FreeSWITCH'
  1. FreeSWITCH
  2. FS-11833

mod_sofia: reINVITE fails after T38 invite failed

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: New
    • Priority: Minor
    • Resolution: Unresolved
    • Affects Version/s: 1.8.5
    • Fix Version/s: None
    • Component/s: mod_sofia
    • Labels:
      None
    • Environment:
      Debian Stretch
    • CPU Architecture:
      x86-64
    • Kernel:
      Linux
    • Userland:
      GNU/Linux
    • Distribution:
      Debian
    • Distribution Version:
      Debian 8 jessie
    • Compiler:
      gcc
    • FreeSWITCH GIT Revision:
      1.8.5
    • GIT Master Revision hash::
      1.8.5

      Description

      Hello FreeSWITCHers,

      I've been wrong before, but I think I found a bug. The call flow is like this:

      1. FS sends INVITE (destination is a fax machine)
      2. Call connects with "8 101"
      3. FS sends reINVITE to T38
      4. T38 rejected (488)
      5. FS receives INVITE to "8"
      6. FS replies with 200 OK without SDP
      7. Call fails

      I've attached a log with debug and SIP traces.

      When I call the same number with fax_enable_t38_request=false there's no problem, the reINVITE is replied by FS with SDP containing "8".

      I put a lot of printfs in the code. It occurred to me that the bug is related to TFLAG_SDP. This flag is set when a media session is established. And when there's a reINVITE sofia_glue_do_invite() from sofia_glue.c is called, which clears the flag again:

      sofia_clear_flag_locked(tech_pvt, TFLAG_SDP);

      So when FS sends a reINVITE to T38 the flag gets cleared. But when the reINVITE is rejected with 488 the flag is not set again. It stays cleared. But the call continues with the previously negotiated media, fax passthrough (8 101 in this case).

      So when FS receives a reINVITE at this point it doesn't see the need to renegotiate anything, even though it realizes that 2833 DTMF is now off:

      2019-04-30 16:42:12.478025 [DEBUG] switch_core_media.c:5478 Audio Codec Compare [PCMA:8:8000:20:64000:1]/[PCMA:8:8000:20:64000:1]
      2019-04-30 16:42:12.478025 [DEBUG] switch_core_media.c:5533 Audio Codec Compare [PCMA:8:8000:20:64000:1] ++++ is saved as a match
      2019-04-30 16:42:12.478025 [DEBUG] switch_core_media.c:5802 No 2833 in SDP. Disable 2833 dtmf and switch to INFO

      When FS doesn't send a reINVITE (fax_enable_t38_request=false) and the reINVITE to "8" is received, TFLAG_SDP is still set and then FS understands that it needs to renegotiate and replies with a 200 OK that includes SDP:

      2019-04-30 16:41:19.358028 [DEBUG] switch_core_media.c:5478 Audio Codec Compare [PCMA:8:8000:20:64000:1]/[PCMA:8:8000:20:64000:1]
      2019-04-30 16:41:19.358028 [DEBUG] switch_core_media.c:5533 Audio Codec Compare [PCMA:8:8000:20:64000:1] ++++ is saved as a match
      2019-04-30 16:41:19.358028 [DEBUG] switch_core_media.c:5802 No 2833 in SDP. Disable 2833 dtmf and switch to INFO
      2019-04-30 16:41:19.358028 [DEBUG] sofia.c:8237 skemper was here in line 8232
      2019-04-30 16:41:19.358028 [DEBUG] switch_core_media.c:8390 skemper was here in line 8390.
      2019-04-30 16:41:19.358028 [DEBUG] switch_core_media.c:8496 Audio params are unchanged for sofia/external/+called_number.
      2019-04-30 16:41:19.358028 [DEBUG] sofia.c:8243 Processing updated SDP

      I found that if I add

      sofia_set_flag(tech_pvt, TFLAG_SDP);

      into the if-block in sofia.c (around line 787) that clears the T38 flags

      if (status > 299 && switch_channel_test_app_flag_key("T38", tech_pvt->channel, CF_APP_T38_REQ))

      { ... sofia_set_flag(tech_pvt, TFLAG_SDP); }

      then FS works as expected (SDP in reply).

      I'm not sure this is the right way to fix this. But I think it might be.

      Would be nice if you could double-check. If my proposition is correct then I can raise a pull request if you want.

      Thanks and kind regards,
      Seb

        Attachments

          Activity

            People

            • Assignee:
              mikej Mike Jerris
              Reporter:
              Sebastian Sebastian Kemper
            • Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

              Dates

              • Created:
                Updated: