<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<div class="moz-cite-prefix">Thanks for the suggestions, I'll pass
them on to see what we can do.</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">Cheers</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix"><br>
</div>
<div class="moz-cite-prefix">On 03/09/2020 02.21, Gabriel Kuri
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CAO3KpR1BGA9fNV8KgG3u3koPZr8yrQ0gWgyvbGQ=ZhNz1jO8_A@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<div dir="ltr">
<div>The reason for rejecting T.38 from the carrier is that it
sucks... Faxes work sometimes and other times don't when using
T.38 with them. They also disable ECM which is a bad idea.
Using G.711 is a reliable option since we're on-net with them
and there's no latency or jitter, which is why we'd want to
keep the call on G.711 and not switch to T.38. From the ATA
perspective, that's an unreliable connection susceptible to
latency and jitter and must be T.38.</div>
<div><br>
</div>
<div>If I may make a couple suggestions, it would be good if
there were 2 additional options in C5 or rtpengine:</div>
<div><br>
</div>
<div>- t38_refuse</div>
<div>This option would refuse a T.38 Invite on a leg with a 488
and keep the call at the current codec. This would be used on
the leg facing the carrier to reject their T.38 invite and
keep the call on the current codec (ie PCMU or PCMA).<br>
</div>
<div><br>
</div>
<div>- t38_send_invite</div>
<div>This option would force C5 to send a T.38 invite on a leg
of the call to get that leg to switch over to T.38 rather than
relying on the ATA or other endpoint to make the switchover.
The main reason is to eliminate the late T.38 reinvite issue
that occurs and causes Faxes to fail at times. If C5 did the
T.38 invite within a very short interval at the start of the
call (assuming you know it's always a Fax call), it would
eliminate the late reinvite issue associated with T.38. This
would be used on the leg facing the ATA or other device you
want to use T.38 and ensure the T.38 invite comes early enough
into the call to switchover and have a successful Fax.<br>
</div>
<div><br>
</div>
<div><br>
</div>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">On Wed, Sep 2, 2020 at 6:08 AM
Richard Fuchs <<a href="mailto:rfuchs@sipwise.com"
moz-do-not-send="true">rfuchs@sipwise.com</a>> wrote:<br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On
02/09/2020 01.37, Gabriel Kuri wrote:<br>
> Hi Richard,<br>
><br>
> Thanks for the info, I tried those settings and it seems
to transcode. <br>
> However, sometimes the carrier does a T.38 Re-INVITE
before the ATA <br>
> does the T.38 Re-INVITE, and C5 passes the T.38 Re-INVITE
through to <br>
> the ATA rather than rejecting it and staying on G.711 on
the carrier <br>
> side. Is it possible to reject the T.38 from the carrier
side and stay <br>
> G.711 so that only the ATA side of the call does T.38 and
the call is <br>
> transcoded?<br>
<br>
I'm afraid that's not a use case we had envisioned -- We
expected people <br>
would want to use T.38 when available and not reject it. :) So
the <br>
options we were designed for cases where one side just doesn't
support T.38.<br>
<br>
May I ask why you want to reject the T.38 offer from the
carrier?<br>
<br>
Cheers<br>
<br>
<br>
-- <br>
Spce-user mailing list<br>
<a href="mailto:Spce-user@lists.sipwise.com" target="_blank"
moz-do-not-send="true">Spce-user@lists.sipwise.com</a><br>
<a
href="http://lists.sipwise.com/mailman/listinfo/spce-user_lists.sipwise.com"
rel="noreferrer" target="_blank" moz-do-not-send="true">http://lists.sipwise.com/mailman/listinfo/spce-user_lists.sipwise.com</a><br>
</blockquote>
</div>
</blockquote>
</body>
</html>