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

Mon May 17 17:26:30 EDT 2021

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…

Any idea on this?

Von: Spce-user <spce-user-bounces at lists.sipwise.com <mailto:spce-user-bounces at lists.sipwise.com> > Im Auftrag von Hohl Matthias
Gesendet: Donnerstag, 15. November 2018 13:26
An: 'Daniel Grotti' <dgrotti at sipwise.com <mailto:dgrotti at sipwise.com> >; spce-user at lists.sipwise.com <mailto:spce-user at lists.sipwise.com> 
Betreff: Re: [Spce-user] T.38 to G.711a transcoding for peerings and vice versa

Hello Daniel,

I believe it would be a problem on subscriber side:

>From SPCE to Peering Server with G.711a for faxing would be less problem because the transport will be with Sync-Ethernet and with direct peering connection.

But between subscriber PBX and SPCE there is often any kind of internet connection possible, and for this reason I think T.38 (leg from subscriber to SPCE) would make the things more stable like  G.711a.

So I think T.38 on subscriber side and G.711a on Peering side would be the most effective way to have successful fax services. Therefore SPCE has to transcode T.38 to G.711a for the peering or G.711a to T.38 for subscriber if the subscriber is supporting it.

I hope I descriped it now better 😊

Von: Spce-user <spce-user-bounces at lists.sipwise.com <mailto:spce-user-bounces at lists.sipwise.com> > Im Auftrag von Daniel Grotti
Gesendet: Donnerstag, 15. November 2018 12:00
An: spce-user at lists.sipwise.com <mailto:spce-user at lists.sipwise.com> 
Betreff: Re: [Spce-user] T.38 to G.711a transcoding for peerings and vice versa

Hi,
frankly I don't see the problem.
I would just enable t.38 anyway, in case the t38 re-negotiation fails (e.g with your peering server) the fax should go in G711, as falback.

-- 
Daniel Grotti
Head of Customer Support
Sipwise GmbH, Campus 21/Europaring F15
AT-2345 Brunn am Gebirge

Office: +43(0)130120332
Email: dgrotti at sipwise.com <mailto:dgrotti at sipwise.com> 
Website: https://www.sipwise.com

On 11/15/18 11:45 AM, Hohl Matthias wrote:

Hello,

Today I got the information that A1 Telekom is not supporting T.38 in there IC network.

Only if the traffic is a Transit Call, T.38 will be supported as “Pass-Through”.

All other Fax Calls with a Reinvite to T.38 will be “not acceptable here”.

For better fax stability I want to allow T.38 for my subscribers.

Therefore I want to allow T.38 just on subscriber side. On peering side, T.38 has to be transcoded to G.711a, if the destination network is A1 Telekom. Also if a FAX comes from A1 with G.711a it should be transcoded to T.38 for our subscribers, of the subscriber support T.38.

IS it possible to implement this transcoding option in any way on the SPCE mr6.5.1? Maybe with a SEMS patch?

Would be nice if someone has an idea to solve this 😊

Mit freundlichen Grüßen,

Matthias Hohl

_______________________________________________
Spce-user mailing list
Spce-user at lists.sipwise.com <mailto:Spce-user at lists.sipwise.com> 
https://lists.sipwise.com/listinfo/spce-user

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