<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>