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

[Matthias Hohl]

Hello Richard,

thanks for your details.

 

Are there already any plans for developing such kind of conditional T.38 probing support in a future release?

 

I think the more complex scenario with DSP sounds also interesting but is it worth investing so much time a dying technology?

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… 😃

 

 

 

Von: Richard Fuchs <rfuchs at sipwise.com> 
Gesendet: Dienstag, 18. Mai 2021 15:03
An: spce-user at lists.sipwise.com
Betreff: Re: [Spce-user] T.38 to G.711a transcoding for peerings and vice versa

 

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/20210519/b4a25d3e/attachment-0002.html>