<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40"><head><meta http-equiv=Content-Type content="text/html; charset=utf-8"><meta name=Generator content="Microsoft Word 15 (filtered medium)"><style><!--
/* Font Definitions */
@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:Consolas;
panose-1:2 11 6 9 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{margin:0cm;
font-size:11.0pt;
font-family:"Calibri",sans-serif;
color:black;
mso-fareast-language:EN-US;}
span.E-MailFormatvorlage23
{mso-style-type:personal-reply;
font-family:"Calibri",sans-serif;
color:windowtext;}
.MsoChpDefault
{mso-style-type:export-only;
font-size:10.0pt;}
@page WordSection1
{size:612.0pt 792.0pt;
margin:70.85pt 70.85pt 2.0cm 70.85pt;}
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]--></head><body lang=DE-AT link="#0563C1" vlink=purple style='word-wrap:break-word'><div class=WordSection1><p class=MsoNormal><span style='color:windowtext'>Hello Richard,<o:p></o:p></span></p><p class=MsoNormal><span style='color:windowtext'>thanks for your details.<o:p></o:p></span></p><p class=MsoNormal><span style='color:windowtext'><o:p> </o:p></span></p><p class=MsoNormal><span lang=EN-US style='color:windowtext'>Are there already any plans for developing such kind of conditional T.38 probing support in a future release?<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-US style='color:windowtext'><o:p> </o:p></span></p><p class=MsoNormal><span lang=EN-US style='color:windowtext'>I think the more complex scenario with DSP sounds also interesting but is it worth investing so much time a dying technology?<o:p></o:p></span></p><p class=MsoNormal><span lang=EN-US style='color:windowtext'>FAX at all is in my opinion in year 2021 not really needed anymore but a handful people still use it instead of E-Mail… </span><span lang=EN-US style='font-family:"Segoe UI Emoji",sans-serif;color:windowtext'>😃</span><span lang=EN-US style='color:windowtext'><o:p></o:p></span></p><p class=MsoNormal><span lang=EN-US style='color:windowtext'><o:p> </o:p></span></p><p class=MsoNormal><span lang=EN-US style='color:windowtext'><o:p> </o:p></span></p><p class=MsoNormal><span lang=EN-US style='color:windowtext'><o:p> </o:p></span></p><div><div style='border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0cm 0cm 0cm'><p class=MsoNormal><b><span lang=DE style='color:windowtext;mso-fareast-language:DE-AT'>Von:</span></b><span lang=DE style='color:windowtext;mso-fareast-language:DE-AT'> Richard Fuchs <rfuchs@sipwise.com> <br><b>Gesendet:</b> Dienstag, 18. Mai 2021 15:03<br><b>An:</b> spce-user@lists.sipwise.com<br><b>Betreff:</b> Re: [Spce-user] T.38 to G.711a transcoding for peerings and vice versa<o:p></o:p></span></p></div></div><p class=MsoNormal><o:p> </o:p></p><div><p class=MsoNormal>On 17/05/2021 17.26, [ EXT ] Matthias Hohl wrote:<span style='mso-fareast-language:DE-AT'><o:p></o:p></span></p></div><blockquote style='margin-top:5.0pt;margin-bottom:5.0pt'><p class=MsoNormal><span lang=EN-US style='color:windowtext;mso-fareast-language:DE-AT'>Hello,</span><o:p></o:p></p><p class=MsoNormal><span lang=EN-US style='color:windowtext;mso-fareast-language:DE-AT'> </span><o:p></o:p></p><p class=MsoNormal><span lang=EN-US style='color:windowtext;mso-fareast-language:DE-AT'>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.</span><o:p></o:p></p><p class=MsoNormal><span lang=EN-US style='color:windowtext;mso-fareast-language:DE-AT'>So I take some time to think over about this topic…</span><o:p></o:p></p><p class=MsoNormal><span lang=EN-US style='color:windowtext;mso-fareast-language:DE-AT'> </span><o:p></o:p></p><p class=MsoNormal><span lang=EN-US style='color:windowtext;mso-fareast-language:DE-AT'>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.</span><o:p></o:p></p><p class=MsoNormal><span lang=EN-US style='color:windowtext;mso-fareast-language:DE-AT'>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.</span><o:p></o:p></p><p class=MsoNormal><span lang=EN-US style='color:windowtext;mso-fareast-language:DE-AT'> </span><o:p></o:p></p><p class=MsoNormal><span lang=EN-US style='color:windowtext;mso-fareast-language:DE-AT'>In detail I try to explain it:</span><o:p></o:p></p><p class=MsoNormal><span lang=EN-US style='color:windowtext;mso-fareast-language:DE-AT'> </span><o:p></o:p></p><p class=MsoNormal><b><span lang=EN-US style='color:windowtext;mso-fareast-language:DE-AT'>Outbound FAX (subscriber to peering):</span></b><o:p></o:p></p><p class=MsoNormal><span lang=EN-US style='color:windowtext;mso-fareast-language:DE-AT'>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.</span><o:p></o:p></p><p class=MsoNormal><span lang=EN-US style='color:windowtext;mso-fareast-language:DE-AT'>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.</span><o:p></o:p></p><p class=MsoNormal><span lang=EN-US style='color:windowtext;mso-fareast-language:DE-AT'> </span><o:p></o:p></p><p class=MsoNormal><b><span lang=EN-US style='color:windowtext;mso-fareast-language:DE-AT'>Inbound FAX (peering to subscriber):</span></b><o:p></o:p></p><p class=MsoNormal><span lang=EN-US style='color:windowtext;mso-fareast-language:DE-AT'>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.</span><o:p></o:p></p><p class=MsoNormal><span lang=EN-US style='color:windowtext;mso-fareast-language:DE-AT'>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.</span><o:p></o:p></p><p class=MsoNormal><span lang=EN-US style='color:windowtext;mso-fareast-language:DE-AT'> </span><o:p></o:p></p><p class=MsoNormal><span lang=EN-US style='color:windowtext;mso-fareast-language:DE-AT'>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><o:p></o:p></p></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).<o:p></o:p></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.<o:p></o:p></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.)<o:p></o:p></p><p>Cheers<o:p></o:p></p></div></body></html>