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

Refused T38 reinvite on b-leg breaks T38 negotiation on a-leg when using T38 gateway mode

    Details

    • Type: Task
    • Status: Resolved
    • Priority: Minor
    • Resolution: Fixed
    • Affects Version/s: 1.6.13
    • Fix Version/s: None
    • Component/s: mod_spandsp
    • Security Level: public
    • Labels:
      None
    • Environment:
      Debian+Docker
    • CPU Architecture:
      x86-64
    • Kernel:
      Linux
    • Userland:
      GNU/Linux
    • Distribution:
      Debian
    • Distribution Version:
      Debian 8 jessie
    • Compiler:
      gcc
    • FreeSWITCH GIT Revision:
      FreeSWITCH Version 1.6.13+git~20161214T213702Z~d422498d0f~64bit (git d422498 2016-12-14 21:37:02Z 64bit)
    • GIT Master Revision hash::
      n/a
    • FSS Support Agreement Customer Number and Company name:
      Telnyx LLC

      Description

      The issue occurs when sending OB Fax calls with this call flow:

      T38 device -> FS -> PSTN vendor

      The dialplan contains the following t38 related lines:

      <action application="set" data="fax_enable_t38=true"/>
      <action application="set" data="fax_enable_t38_request=true"/>
      <action application="bridge" data="{local_var_clobber=true,refuse_t38=true,execute_on_answer='t38_gateway peer'}

      We send two calls with different results:

      Call #2 behavior
      The call is established with PCMU codec.
      FS sends a T38 reinvite to the caller on the a-leg and the fax is transmitted successfully with T38 on the a-leg and PCMU on the b-leg

      Call #1 behavior
      The call is established with PCMU codec.
      FS sends a T38 reinvite to the caller on the a-leg.
      The PSTN vendor sends a T38 reinvite on the b-leg, FS refuses it with code 488 and the vendor ACKs it, keeps the call active and the RTP stream open still sending FAX tones.
       The t38 negotiation on the a-leg fails and the fax transmission fails.

      I'm attaching FS logs and traces (signaling and RTP) for both calls.
      1. call1.log
        56 kB
        Rogelio Perez
      2. call1-aleg.pcapng
        27 kB
        Rogelio Perez
      3. call1-bleg.pcap
        1.00 MB
        Rogelio Perez
      4. call2.log
        52 kB
        Rogelio Perez
      5. call2-aleg.pcapng
        119 kB
        Rogelio Perez
      6. call2-bleg.pcap
        901 kB
        Rogelio Perez

        Issue Links

          Activity

          Hide
          brian Brian West added a comment -
          Can this be replicated on the lab2 box we were working on today?
          Show
          brian Brian West added a comment - Can this be replicated on the lab2 box we were working on today?
          Hide
          brian Brian West added a comment -
          The issue here is Sonus sends a re-invite to switch to t38 mode, Then starts sending udptl traffic, What should take place once a 488 is received a new invite from sonus should be sent to FreeSWITCH switching back to g.711, This is a vendor issue, not a FreeSWITCH issue.

          /b
          Show
          brian Brian West added a comment - The issue here is Sonus sends a re-invite to switch to t38 mode, Then starts sending udptl traffic, What should take place once a 488 is received a new invite from sonus should be sent to FreeSWITCH switching back to g.711, This is a vendor issue, not a FreeSWITCH issue. /b
          Hide
          brian Brian West added a comment -
          In addition FreeSWITCH has no ability to recover from receiving a 488 on an outbound call, This functionality was never written. It may in this case had Sonus sent the re-invite and switched back to PCMU instead of us sending PCMU and Sonus sending UDPTL. There is no way we can work around this particular behavior on our side.

          /b
          Show
          brian Brian West added a comment - In addition FreeSWITCH has no ability to recover from receiving a 488 on an outbound call, This functionality was never written. It may in this case had Sonus sent the re-invite and switched back to PCMU instead of us sending PCMU and Sonus sending UDPTL. There is no way we can work around this particular behavior on our side. /b
          Hide
          brian Brian West added a comment -
          This isn't a bug in FreeSWITCH, I've noted the observed behavior based on the data provided.
          Show
          brian Brian West added a comment - This isn't a bug in FreeSWITCH, I've noted the observed behavior based on the data provided.
          Hide
          brian Brian West added a comment -
          Need to re-review this data.
          Show
          brian Brian West added a comment - Need to re-review this data.

            People

            • Assignee:
              brian Brian West
              Reporter:
              rogelio.telnyx Rogelio Perez
            • Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Development