[Spce-user] T.38 <-> G.711 Transcoding

[Gabriel Kuri]

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.

If I may make a couple suggestions, it would be good if there were 2
additional options in C5 or rtpengine:

- t38_refuse
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).

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



On Wed, Sep 2, 2020 at 6:08 AM Richard Fuchs <rfuchs at sipwise.com> wrote:

> On 02/09/2020 01.37, Gabriel Kuri wrote:
> > Hi Richard,
> >
> > Thanks for the info, I tried those settings and it seems to transcode.
> > However, sometimes the carrier does a T.38 Re-INVITE before the ATA
> > does the T.38 Re-INVITE, and C5 passes the T.38 Re-INVITE through to
> > the ATA rather than rejecting it and staying on G.711 on the carrier
> > side. Is it possible to reject the T.38 from the carrier side and stay
> > G.711 so that only the ATA side of the call does T.38 and the call is
> > transcoded?
>
> I'm afraid that's not a use case we had envisioned -- We expected people
> would want to use T.38 when available and not reject it. :) So the
> options we were designed for cases where one side just doesn't support
> T.38.
>
> May I ask why you want to reject the T.38 offer from the carrier?
>
> Cheers
>
>
> --
> Spce-user mailing list
> Spce-user at lists.sipwise.com
> http://lists.sipwise.com/mailman/listinfo/spce-user_lists.sipwise.com
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sipwise.com/pipermail/spce-user_lists.sipwise.com/attachments/20200902/8711d97a/attachment-0002.html>