[Spce-user] T.38 to G.711a transcoding for peerings and vice versa

[Richard Fuchs]

On 17/05/2021 17.26, [ EXT ] Matthias Hohl wrote:
>
> Hello,
>
> 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.
>
> So I take some time to think over about this topic…
>
> 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.
> 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.
>
> 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.
>
> In detail I try to explain it:
>
> *Outbound FAX (subscriber to peering):*
>
> 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.
>
> 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.
>
> *Inbound FAX (peering to subscriber):*
>
> 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.
>
> 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.
>
> 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…
>
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).

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.

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

Cheers

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sipwise.com/pipermail/spce-user_lists.sipwise.com/attachments/20210518/b6c6758d/attachment-0001.html>