Hello,
I am having some issues ensuring t38 faxes are being received reliably. I am currently using kamailio as an inbound sbc with freepbx as the endpoint. I understand that potentially stripping other codecs except for g711a/u makes inbound faxes reliable, but beyond that I am having trouble determining how to ensure reliable faxing. Is this something kamailio can handle (such as an error correction mode or pass through setting or module?) I would appreciate any insight as I have hit a wall when it comes to this issue.
Thank you, Temi
Hello,
Kamailio will not handle media usually, but have a look to rtpengine. This can supports different T.38 options for transcoding or disabling certain modes in the current versions.
Cheers,
Henning
Hi Temi
I am having some issues ensuring t38 faxes are being received reliably. I am currently using kamailio as an inbound sbc with freepbx as the endpoint. I understand that potentially stripping other codecs except for g711a/u makes inbound faxes reliable, but beyond that I am having trouble determining how to ensure reliable faxing. Is this something kamailio can handle (such as an error correction mode or pass through setting or module?) I would appreciate any insight as I have hit a wall when it comes to this issue.
Fax over VoIP is a very complicated issue, there are various very different implementations.
audio works fine, if you have basically no jitter end to end. t.38 tends to work better if there is jitter.
In my experience, it is best to basically try to leave the codec negotiation to the involved endpoints and not to try to build some kind of T.38 to audio gateway.
If the involved endpoints fail in negotiate a codec, they probably misbehave.
What you can do to try to improve the situation if there is an issue with T.38, is to force the endpoints to use audio and strip image from the codec list. But this is not as easy as in the usual situation where the connections starts with audio, then one party detects fax-tone and re-invites with only image (maybe several times when the fax-tone is re-detected on every page boundary), you can not just strip image and forward the empty codec list to the other party, this is sure to end up with an error.
You would need to reply 488 to the party initiating T.38 and hope it correctly falls back to audio. This can either happen with a re-invite back to audio, or just by doing nothing. 488 according to RFC should result in the previously negotiated codec to stay valid!
So when you using rtpengine, make sure you have something like this in your reply route:
if ($rs != 488) { # do NOT manage reply on 488 to allow t.38 fallback to previously negotiated codec. rtpengine_manage("some options"); }
Mit freundlichen Grüssen
-Benoît Panizzon-