<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">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">Spce-user@lists.sipwise.com</a><br>
<a href="http://lists.sipwise.com/mailman/listinfo/spce-user_lists.sipwise.com" rel="noreferrer" target="_blank">http://lists.sipwise.com/mailman/listinfo/spce-user_lists.sipwise.com</a><br>
</blockquote></div>