Faxing over T.38 from experience has certainly been a better experience than over G711u bypass. Of course there are some implementations of T.38 that interoperate with each other better than others. My experience with AudioCodes, Linksys/Sipura, and Grandstream has been very positive. One of the common potential problems with either approach is the behaviour of the signaling in response to which end (caller, callee, or both) of the session is responsible for initiating the re-INVITE for T.38. When supporting wholesale customers it is not always possible to configure the behaviour of the ATAs/IADs and the only way to ensure fax will at least always be "detected" is to have one of endpoint gateways/ATAs/IADs detect fax as the caller and the callee. The next fun piece to tackle once that's configured is to ensure that all endpoints properly support handling SIP 491 Request Pending response codes to avoid a race condition which can cause INVITE "glare" if one endpoint is configured to detect faxes and re-INVITE for both caller and callee and the other is set to detect faxes and re-INVITE on either. Regards, Justin _____ From: voiceops-bounces at voiceops.org [mailto:voiceops-bounces at voiceops.org] On Behalf Of Ujjval Karihaloo Sent: Wednesday, January 06, 2010 7:01 PM To: voiceops at voiceops.org Subject: [VoiceOps] VoIP T38 Fax reliability I know this a thorn in everyones flesh, I would like to know of experiences with T38 Voip Faxing. We have had good and bad. Those that don't work just don't and they don't even want to troubleshoot and just switch over to an Analog line for Fax. We mostly use AudioCodes and Sipura T38 ATAs. Any of you folks do T38 and whats the experience like.
Correct, I have been able to get around INVITE glare etc...by tweaking ATA configs, however the problem mainly lies in UDPTL T3/T38 signaling in the RTP, E.g. TAs keep sending no signal msgs to the Provider and they don't sends a DIS back and it then just re-invites for G711 Pass-though...and that never works... I have also seen FCS-BAD (HDLC frame signal) coming from the Provider when UDPTL data is sent. From: Justin Randall [mailto:jrandall at comwave.net] Sent: Thursday, January 07, 2010 10:40 AM To: Ujjval Karihaloo; voiceops at voiceops.org Subject: RE: [VoiceOps] VoIP T38 Fax reliability Faxing over T.38 from experience has certainly been a better experience than over G711u bypass. Of course there are some implementations of T.38 that interoperate with each other better than others. My experience with AudioCodes, Linksys/Sipura, and Grandstream has been very positive. One of the common potential problems with either approach is the behaviour of the signaling in response to which end (caller, callee, or both) of the session is responsible for initiating the re-INVITE for T.38. When supporting wholesale customers it is not always possible to configure the behaviour of the ATAs/IADs and the only way to ensure fax will at least always be "detected" is to have one of endpoint gateways/ATAs/IADs detect fax as the caller and the callee. The next fun piece to tackle once that's configured is to ensure that all endpoints properly support handling SIP 491 Request Pending response codes to avoid a race condition which can cause INVITE "glare" if one endpoint is configured to detect faxes and re-INVITE for both caller and callee and the other is set to detect faxes and re-INVITE on either. Regards, Justin ________________________________ From: voiceops-bounces at voiceops.org [mailto:voiceops-bounces at voiceops.org] On Behalf Of Ujjval Karihaloo Sent: Wednesday, January 06, 2010 7:01 PM To: voiceops at voiceops.org Subject: [VoiceOps] VoIP T38 Fax reliability I know this a thorn in everyones flesh, I would like to know of experiences with T38 Voip Faxing. We have had good and bad. Those that don't work just don't and they don't even want to troubleshoot and just switch over to an Analog line for Fax. We mostly use AudioCodes and Sipura T38 ATAs. Any of you folks do T38 and whats the experience like.
Been there, done that, got the t-shirt. Main problem I ran into is that (1) Super G3 detection doesn't work on many switches, and (2) even the ones on which it does work there is not a vendor-neutral way to pass that knowledge through to the terminating gateway, and (3) T.38 support at Super G3 speeds is lacking in most implementations at this time. Between this and the problems you mention, it's just not worth it. Seriously, it's one of the least Pareto-optimal propositions in the entire business. Just sell them analog lines. I've actually managed to convert a few customers - even steadfastly traditional, paper-intensive ones - to using fast doc scanners + e-mail. :-) On 01/07/2010 12:47 PM, Ujjval Karihaloo wrote:
Correct, I have been able to get around INVITE glare etc?by tweaking ATA configs, however the problem mainly lies in UDPTL T3/T38 signaling in the RTP, E.g. TAs keep sending no signal msgs to the Provider and they don?t sends a DIS back and it then just re-invites for G711 Pass-though?and that never works?
I have also seen FCS-BAD (HDLC frame signal) coming from the Provider when UDPTL data is sent.
*From:* Justin Randall [mailto:jrandall at comwave.net] *Sent:* Thursday, January 07, 2010 10:40 AM *To:* Ujjval Karihaloo; voiceops at voiceops.org *Subject:* RE: [VoiceOps] VoIP T38 Fax reliability
Faxing over T.38 from experience has certainly been a better experience than over G711u bypass. Of course there are some implementations of T.38 that interoperate with each other better than others. My experience with AudioCodes, Linksys/Sipura, and Grandstream has been very positive.
One of the common potential problems with either approach is the behaviour of the signaling in response to which end (caller, callee, or both) of the session is responsible for initiating the re-INVITE for T.38. When supporting wholesale customers it is not always possible to configure the behaviour of the ATAs/IADs and the only way to ensure fax will at least always be ?detected? is to have one of endpoint gateways/ATAs/IADs detect fax as the caller and the callee. The next fun piece to tackle once that?s configured is to ensure that all endpoints properly support handling SIP 491 Request Pending response codes to avoid a race condition which can cause INVITE ?glare? if one endpoint is configured to detect faxes and re-INVITE for both caller and callee and the other is set to detect faxes and re-INVITE on either.
Regards,
Justin
------------------------------------------------------------------------
*From:* voiceops-bounces at voiceops.org [mailto:voiceops-bounces at voiceops.org] *On Behalf Of *Ujjval Karihaloo *Sent:* Wednesday, January 06, 2010 7:01 PM *To:* voiceops at voiceops.org *Subject:* [VoiceOps] VoIP T38 Fax reliability
I know this a thorn in everyones flesh, I would like to know of experiences with T38 Voip Faxing. We have had good and bad. Those that don?t work just don?t and they don?t even want to troubleshoot and just switch over to an Analog line for Fax. We mostly use AudioCodes and Sipura T38 ATAs.
Any of you folks do T38 and whats the experience like.
_______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops
-- Alex Balashov - Principal Evariste Systems Web : http://www.evaristesys.com/ Tel : (+1) (678) 954-0670 Direct : (+1) (678) 954-0671
We have a very good success rate here using Linksys spa2102s and asterisk 1.6. We ran into several problems mainly in t.38 negotiation. The things I would be most careful about : - Make sure the t.38 is correctly negotiated. That has been an issue in the past. A good thing that asterisk comes with enough debugging to be able to troubleshoot that. - Get rid of any SIP ALGs. We have had a strange issue where both ends couldn't negotiate t.38 because the SIP ALG implementation (namely D-LINKs implementation) would just not understand the re-invite part. In my experience once your fax voip call uses t.38 you're good. Or as somebody else said if you have 0 packet loss / 0 jitter then you're good too (as long as you use g711). On Thu, Jan 7, 2010 at 12:55 PM, Alex Balashov <abalashov at evaristesys.com> wrote:
Been there, done that, got the t-shirt. ?Main problem I ran into is that (1) Super G3 detection doesn't work on many switches, and (2) even the ones on which it does work there is not a vendor-neutral way to pass that knowledge through to the terminating gateway, and (3) T.38 support at Super G3 speeds is lacking in most implementations at this time.
Between this and the problems you mention, it's just not worth it. Seriously, it's one of the least Pareto-optimal propositions in the entire business. ?Just sell them analog lines.
I've actually managed to convert a few customers - even steadfastly traditional, paper-intensive ones - to using fast doc scanners + e-mail. ?:-)
On 01/07/2010 12:47 PM, Ujjval Karihaloo wrote:
Correct, I have been able to get around INVITE glare etc?by tweaking ATA configs, however the problem mainly lies in UDPTL T3/T38 signaling in the RTP, E.g. TAs keep sending no signal msgs to the Provider and they don?t sends a DIS back and it then just re-invites for G711 Pass-though?and that never works?
I have also seen FCS-BAD (HDLC frame signal) coming from the Provider when UDPTL data is sent.
*From:* Justin Randall [mailto:jrandall at comwave.net] *Sent:* Thursday, January 07, 2010 10:40 AM *To:* Ujjval Karihaloo; voiceops at voiceops.org *Subject:* RE: [VoiceOps] VoIP T38 Fax reliability
Faxing over T.38 from experience has certainly been a better experience than over G711u bypass. Of course there are some implementations of T.38 that interoperate with each other better than others. My experience with AudioCodes, Linksys/Sipura, and Grandstream has been very positive.
One of the common potential problems with either approach is the behaviour of the signaling in response to which end (caller, callee, or both) of the session is responsible for initiating the re-INVITE for T.38. When supporting wholesale customers it is not always possible to configure the behaviour of the ATAs/IADs and the only way to ensure fax will at least always be ?detected? is to have one of endpoint gateways/ATAs/IADs detect fax as the caller and the callee. The next fun piece to tackle once that?s configured is to ensure that all endpoints properly support handling SIP 491 Request Pending response codes to avoid a race condition which can cause INVITE ?glare? if one endpoint is configured to detect faxes and re-INVITE for both caller and callee and the other is set to detect faxes and re-INVITE on either.
Regards,
Justin
------------------------------------------------------------------------
*From:* voiceops-bounces at voiceops.org [mailto:voiceops-bounces at voiceops.org] *On Behalf Of *Ujjval Karihaloo *Sent:* Wednesday, January 06, 2010 7:01 PM *To:* voiceops at voiceops.org *Subject:* [VoiceOps] VoIP T38 Fax reliability
I know this a thorn in everyones flesh, I would like to know of experiences with T38 Voip Faxing. We have had good and bad. Those that don?t work just don?t and they don?t even want to troubleshoot and just switch over to an Analog line for Fax. We mostly use AudioCodes and Sipura T38 ATAs.
Any of you folks do T38 and whats the experience like.
_______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops
-- Alex Balashov - Principal Evariste Systems Web ? ? : http://www.evaristesys.com/ Tel ? ? : (+1) (678) 954-0670 Direct ?: (+1) (678) 954-0671 _______________________________________________ VoiceOps mailing list VoiceOps at voiceops.org https://puck.nether.net/mailman/listinfo/voiceops
participants (4)
-
a.reversat＠gmail.com -
abalashov＠evaristesys.com -
jrandall＠comwave.net -
ujjval＠simplesignal.com