Few faxes to this destination last 13 inutes with 3 pages.......
SEND FAX (000000506): FROM xxxxxxxx@xxxxx.xx TO 986825573 (docq/doc183.ps;1d81 sent in 0:13:44)
SEND FAX (000000506): FROM xxxxxxxx@xxxxx.xxs TO 986825573 (page 3 of 3 sent in 0:09:51)
I go to get more info and ask later
regards,
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Since you're the sender the audio from your side doesn't really matter that much. To know if the audio is good or not you'd need to get the audio from the receiver. That said, having looked at your session log and with my experience in the matter... unless there was some kind of malfunction at the receiver - the problem almost certainly is an issue with the call audio quality. Whether that is a fault on your side or on the receiver's side or somewhere in-between, I can't say. To know that you'd have to go through a lot of troubleshooting. But, if you're using VoIP on your side then there is really no way to eliminate your end as a possible culprit.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Your incoming audio quality may tell you something about the quality of your outgoing, but not necessarily.
Again, normally speaking (i.e. there is not a bug involved or a malfunction somewhere) any protocol-related failures are due to problems with the call audio quality. Because you're using a VoIP leg in-between your Asterisk system and the E1 there really is no way to eliminate that link as possible culprit unless you've taken steps to assure that the link is jitter-proof.
Doing that (ensuring that the link is jitter-proof) is a matter of network infrastructure design... and even then may be impossible to completey guarantee ... after all, IP communication specifically permits it (whether with UDP packet loss or with TCP latency).
For example, if you have a dedicated link (e.g. cross-over cable) between the Asterisk system and the gateway over which the SIP runs, then you have a much lower likelihood of jitter... but depending on the interface drivers on both sides it may be possible to overrun them with traffic and create jitter that way.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi,
We have to send faxes to an usual number that when not in office there are 30 seconds rings before fax tone.
There are any config/option to manage long fax tone hang up?
Hylafax 5.5.9 + iaxmodem 1.3.0
Regards,
Last edit: Alessan 2018-06-14
Seems problem is not hangup time.......
Few faxes to this destination last 13 inutes with 3 pages.......
SEND FAX (000000506): FROM xxxxxxxx@xxxxx.xx TO 986825573 (docq/doc183.ps;1d81 sent in 0:13:44)
SEND FAX (000000506): FROM xxxxxxxx@xxxxx.xxs TO 986825573 (page 3 of 3 sent in 0:09:51)
I go to get more info and ask later
regards,
Hi again,
Threre are more random errors at this number, audio seems clear...
No response to PPS repeated 3 times.
I have logs and audio, can someone help me to debug this?
https://drive.google.com/drive/folders/1Sm43XWStQjJb0E9u2mYwd0MA3SqRR3MR?usp=sharing
Since you're the sender the audio from your side doesn't really matter that much. To know if the audio is good or not you'd need to get the audio from the receiver. That said, having looked at your session log and with my experience in the matter... unless there was some kind of malfunction at the receiver - the problem almost certainly is an issue with the call audio quality. Whether that is a fault on your side or on the receiver's side or somewhere in-between, I can't say. To know that you'd have to go through a lot of troubleshooting. But, if you're using VoIP on your side then there is really no way to eliminate your end as a possible culprit.
I guess i can do audio capture on incoming faxes to see audio quality. It is right?
We have an asteisk +iaxmodem (ulaw) ---> sip trunk (ulaw) ---> sangoma vega gateway 200 ----> E1
Last edit: Alessan 2018-06-15
Your incoming audio quality may tell you something about the quality of your outgoing, but not necessarily.
Again, normally speaking (i.e. there is not a bug involved or a malfunction somewhere) any protocol-related failures are due to problems with the call audio quality. Because you're using a VoIP leg in-between your Asterisk system and the E1 there really is no way to eliminate that link as possible culprit unless you've taken steps to assure that the link is jitter-proof.
Doing that (ensuring that the link is jitter-proof) is a matter of network infrastructure design... and even then may be impossible to completey guarantee ... after all, IP communication specifically permits it (whether with UDP packet loss or with TCP latency).
For example, if you have a dedicated link (e.g. cross-over cable) between the Asterisk system and the gateway over which the SIP runs, then you have a much lower likelihood of jitter... but depending on the interface drivers on both sides it may be possible to overrun them with traffic and create jitter that way.
What do you think about if i change iaxmodem to t38modem? sangoma vega gateway supports t38
Last edit: Alessan 2018-06-16
I've never been able to get t38modem to work reliably-enough with T.38/SIP providers that I've tested to where I was tempted to stop using PSTN.