<html>
  <head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
  </head>
  <body>
    <div class="moz-cite-prefix">On 17/05/2021 17.26, [ EXT ] Matthias
      Hohl wrote:<br>
    </div>
    <blockquote type="cite"
      cite="mid:1085998959.11680494.1621286790020.JavaMail.zimbra@mx">
      <meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
      <meta name="Generator" content="Microsoft Word 15 (filtered
        medium)">
      <style>@font-face
        {font-family:"Cambria Math";
        panose-1:2 4 5 3 5 4 6 3 2 4;}@font-face
        {font-family:Calibri;
        panose-1:2 15 5 2 2 2 4 3 2 4;}@font-face
        {font-family:"Segoe UI Emoji";
        panose-1:2 11 5 2 4 2 4 2 2 3;}@font-face
        {font-family:Consolas;
        panose-1:2 11 6 9 2 2 4 3 2 4;}p.MsoNormal, li.MsoNormal, div.MsoNormal
        {margin:0cm;
        font-size:11.0pt;
        font-family:"Calibri",sans-serif;
        color:black;
        mso-fareast-language:EN-US;}a:link, span.MsoHyperlink
        {mso-style-priority:99;
        color:#0563C1;
        text-decoration:underline;}pre
        {mso-style-priority:99;
        mso-style-link:"HTML Vorformatiert Zchn";
        margin:0cm;
        margin-bottom:.0001pt;
        font-size:10.0pt;
        font-family:"Courier New";
        color:black;}tt
        {mso-style-priority:99;
        font-family:"Courier New";}span.HTMLVorformatiertZchn
        {mso-style-name:"HTML Vorformatiert Zchn";
        mso-style-priority:99;
        mso-style-link:"HTML Vorformatiert";
        font-family:Consolas;
        color:black;}span.E-MailFormatvorlage26
        {mso-style-type:personal-reply;
        font-family:"Calibri",sans-serif;
        color:windowtext;}.MsoChpDefault
        {mso-style-type:export-only;
        font-size:10.0pt;}div.WordSection1
        {page:WordSection1;}</style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
      <div class="WordSection1">
        <p class="MsoNormal"><span
            style="color:windowtext;mso-fareast-language:DE-AT"
            lang="EN-US">Hello,<o:p></o:p></span></p>
        <p class="MsoNormal"><span
            style="color:windowtext;mso-fareast-language:DE-AT"
            lang="EN-US"><o:p> </o:p></span></p>
        <p class="MsoNormal"><span
            style="color:windowtext;mso-fareast-language:DE-AT"
            lang="EN-US">Today I stumble over this topic again by
            testing around with a peering partner which doesn’t support
            T.38 fax, so I checked the settings t38_decode and t38_force
            in the handbook but it doesn’t read like this is what I
            need.<o:p></o:p></span></p>
        <p class="MsoNormal"><span
            style="color:windowtext;mso-fareast-language:DE-AT"
            lang="EN-US">So I take some time to think over about this
            topic…<o:p></o:p></span></p>
        <p class="MsoNormal"><span
            style="color:windowtext;mso-fareast-language:DE-AT"
            lang="EN-US"><o:p> </o:p></span></p>
        <p class="MsoNormal"><span
            style="color:windowtext;mso-fareast-language:DE-AT"
            lang="EN-US">What should be solved: try to solve some
            internet connection problems between subscribers/peerings
            and the sipwise if fax could only be done with T.30 (G.711)
            cause subscriber or peering doesn’t support T.38. <br>
            so if think the solution could be that if one call-leg
            (subscriber to server or peering to server) support T.38,
            T.38 should be used on this call-leg independently if the
            other call-leg support it.<o:p></o:p></span></p>
        <p class="MsoNormal"><span
            style="color:windowtext;mso-fareast-language:DE-AT"
            lang="EN-US">So the rtpengine should work as a
            man-in-the-middle fax transcoder/decoder for maximum fax
            stability to use T.38 on every call-leg where it could be
            possible.<o:p></o:p></span></p>
        <p class="MsoNormal"><span
            style="color:windowtext;mso-fareast-language:DE-AT"
            lang="EN-US"><o:p> </o:p></span></p>
        <p class="MsoNormal"><span
            style="color:windowtext;mso-fareast-language:DE-AT"
            lang="EN-US">In detail I try to explain it:<o:p></o:p></span></p>
        <p class="MsoNormal"><span
            style="color:windowtext;mso-fareast-language:DE-AT"
            lang="EN-US"><o:p> </o:p></span></p>
        <p class="MsoNormal"><b><span
              style="color:windowtext;mso-fareast-language:DE-AT"
              lang="EN-US">Outbound FAX (subscriber to peering):<o:p></o:p></span></b></p>
        <p class="MsoNormal"><span
            style="color:windowtext;mso-fareast-language:DE-AT"
            lang="EN-US">Case 1: If an invite is coming with T.30 from
            the subscriber, the sipwise should send an invite to the
            peering and ask if T.38 is supported or not. If supported
            the server should take the T.30 fax and transcode it to
            T.38. If not supported, pass-through.<o:p></o:p></span></p>
        <p class="MsoNormal"><span
            style="color:windowtext;mso-fareast-language:DE-AT"
            lang="EN-US">Case 2: If an invite is coming with T.38 from
            the subscriber, the sipwise should send an invite to the
            peering and ask if T.38 is supported or not. If supported
            pass-through, if not supported, sipwise server should take
            the T.38 fax and transcode it to T.30 fax for the peering.<o:p></o:p></span></p>
        <p class="MsoNormal"><span
            style="color:windowtext;mso-fareast-language:DE-AT"
            lang="EN-US"><o:p> </o:p></span></p>
        <p class="MsoNormal"><b><span
              style="color:windowtext;mso-fareast-language:DE-AT"
              lang="EN-US">Inbound FAX (peering to subscriber):<o:p></o:p></span></b></p>
        <p class="MsoNormal"><span
            style="color:windowtext;mso-fareast-language:DE-AT"
            lang="EN-US">Case 1: If an invite is coming with T.30 from
            the peering, the sipwise should send an invite to the
            subscriber and ask if T.38 is supported or not. If supported
            the server should take the T.30 fax and transcode it to
            T.38. If not supported, pass-through.<o:p></o:p></span></p>
        <p class="MsoNormal"><span
            style="color:windowtext;mso-fareast-language:DE-AT"
            lang="EN-US">Case 2: If an invite is coming with T.38 from
            the peering, the sipwise should send an invite to the
            subscriber and ask if T.38 is supported or not. If supported
            pass-through, if not supported, sipwise server should take
            the T.38 fax and transcode it to T.30 fax for the
            subscriber.<o:p></o:p></span></p>
        <p class="MsoNormal"><span
            style="color:windowtext;mso-fareast-language:DE-AT"
            lang="EN-US"><o:p> </o:p></span></p>
        <p class="MsoNormal"><span
            style="color:windowtext;mso-fareast-language:DE-AT"
            lang="EN-US">Is this working also in practice or is this a
            technical overkill and will bring more problems as it
            solves? In theory it sounds useful but who knows…</span></p>
      </div>
    </blockquote>
    <p>The T.38 options as we have them now are unconditional, which
      means that if they're enabled, then the T.38 gateway is active and
      that's it. If the called peer then doesn't support T.38, the call
      will fail. Or, if the gateway isn't active and T.38 was offered
      and is then rejected, the call will also fail (or fall back to
      T.30 if so done by the caller).</p>
    <p>The sort of conditional T.38 probing you're describing is
      possible and is done by certain CPEs, but is not currently
      supported by us. It's independent of the actual T.38 transcoding
      capabilities and would have to be implemented on a SIP level
      (offer T.38 first, receive rejection, offer again with T.30).
      Another possible approach is to simply offer both T.38 and T.30 at
      the same time in the same SDP (two media sections) and then let
      the receiver choose the mode, but this is non-standard and is also
      not supported by us.</p>
    <p>(An even more complex scenario would be to detect fax tones in
      audio calls and then start the T.38 negotiation when a fax tone is
      detected. This would require running all calls through a DSP, at
      least during the initial phase of the call.)<br>
    </p>
    <p>Cheers<br>
    </p>
  </body>
</html>