iaxmodem-users — Users discussion forum for IAXmodem

Re: [iaxmodem-users] IAXmodem for data

[Lee H. <fa...@ho...>]

IAXmodem doesn't support traditional data modes.  The fax modes that 
IAXmodem supports communicate data in half duplex.

However, fax communication is data communication.  So, if you have a 
custom application (which appears is not the case with your retro 
computers) then it would be possible to use current IAXmodem to make an 
awkward type of half-duplex data link.

Most retro computers can be networked with native network hardware.  
However, in the event that you're not wanting to modify the retro 
hardware or don't want to purchase native network hardware compatible 
for the retro computer, then maybe data modems will be the only 
available interface... and without purchasing hardware for the ISP side 
of the equation that may be difficult.

I assume that maybe you have a couple of spare ATAs and an available 
Asterisk system, and that's why IAXmodem may be attractive to use in 
your situation.  But, if I were to do it and for whatever reason 
absolutely needed to use dial-up networking I would just purchase used 
V.34, V.90, or V.92 hardware modems for the ISP side and then use phone 
line emulators such as Teltones or Viking DLE-200B rather than 
Asterisk.  If using Asterisk were necessary then I'd use FXS devices 
such as a TDM400P with FXS modules (and buying this may certainly be 
less expensive than buying Teltones).

My worry with using Asterisk in general - and specifically with using 
VoIP ATAs is jitter... repeated jitter is likely to be eventually be the 
death of a long-running data connection.  Fax generally tolerates some 
jitter to an extent because of it being half duplex.  So, as long as 
jitter isn't affecting most every signal fax (traditional fax - not 
V.34-Fax / SuperG3) can survive okay when there's jitter.  Long-running 
data modes will not likely survive long if they have to continually 
renegotiate every time there is jitter.

spandsp, the DSP under the hood of IAXmodem, does have V.34 code there.  
So, for someone who is capable it may be possible to get that V.34 modem 
working and then make some small modifications to IAXmodem in order to 
get it to support that V.34 in data mode.  I don't imagine that's you... 
but I'm saying this just in case someone else eventually is.  I've spent 
a minimal amount of time trying to get those V.34 modems working, but 
it's not in my priorities because it would have a limited benefit to my 
primary interests in fax.

Thanks,

Lee.


On 9/6/23 9:05 AM, Nick Vella wrote:
> Hi all,
>
> I’ve had an idea recently for a retro computing project involving dial-up connections; effectively I want to set up my own personal dial-up ISP for my retro computers. I don’t have many modems or ATAs, so I thought it may’ve been fruitful to stand-up Asterisk and IAXmodem to serve as the ‘ISP’ side of the equation; long story short I’m having a very hard time getting IAXmodem to talk data to my test modem, or another instance itself. I have a feeling IAXmodem is fax-mode only, is that the case?
>
> Many thanks for the project regardless, it’s an impressive piece of software.
>
> Cheers, Nick.
>
>
> _______________________________________________
> iaxmodem-users mailing list
> iax...@li...
> https://lists.sourceforge.net/lists/listinfo/iaxmodem-users

[iaxmodem-users] IAXmodem for data

[Nick V. <ni...@nx...>]

Hi all,

I’ve had an idea recently for a retro computing project involving dial-up connections; effectively I want to set up my own personal dial-up ISP for my retro computers. I don’t have many modems or ATAs, so I thought it may’ve been fruitful to stand-up Asterisk and IAXmodem to serve as the ‘ISP’ side of the equation; long story short I’m having a very hard time getting IAXmodem to talk data to my test modem, or another instance itself. I have a feeling IAXmodem is fax-mode only, is that the case?

Many thanks for the project regardless, it’s an impressive piece of software.

Cheers, Nick.

Re: [iaxmodem-users] iaxmodem and systemd device units

[Lee H. <fa...@ho...>]

My responses are in-line below...

On 2/20/23 6:00 AM, deb...@dc... wrote:
> Lee, let me summarize the situation: In Debian (and probably it's 
> derivatives) it seems like we have two issues when hylafax interacts 
> with iaxmodem:
>
> 1) faxaddsetup
> As mentioned here earlier 
> (https://sourceforge.net/p/iaxmodem/mailman/message/37198241/), 
> faxaddsetup hangs while detecting a modem created with iaxmodem. While 
> faxaddsetup asks the modem for it's supported classes, the script 
> hangs and can only stopped with SIGKILL.
> This, for me, is a minor issue, because a user can skip this step and 
> just copy config.ttyIAX to the config directory of hylafax (as 
> mentioned in FAQ as well). Nevertheless it's an annoying bug.


(I believe that you mean faxaddmodem or faxsetup and not faxaddsetup - 
unless Debian has its own faxaddsetup script.) Guiseppe's HylaFAX 
package in Debian uses source code from hylafax.org... so currently 
v6.0.7.  These releases omit the majority of the development work that 
has gone on for the last 15 years in HylaFAX+.  Because I suspect that 
most IAXmodem users are running HylaFAX+, and *I* am certainly running 
HylaFAX+... it's difficult for me to know precisely what problems 
continue to exist in the hylafax.org versions.

This annoying bug is likely something to do with the fuser command being 
used somewhere in faxaddmodem when it shouldn't be (especially not when 
iaxmodem is being used).  A quick look at the v6.0.7 code doesn't reveal 
anything obvious to me, so maybe it's different on Debian or maybe it's 
running with '-f' for some reason.  I don't know.

The thing is, though, that if *I* were using Debian and wanted to fax 
with it I would either build my own package using HylaFAX+ or I would 
install HylaFAX+ from source.  I wouldn't use the HylaFAX package 
provided by Debian because I don't want to deal with various omissions 
of 15 years of software development.  I don't think that I'm alone, 
either.  So, maybe you want to try HylaFAX+ and see if the faxaddmodem 
there behaves the same way, and if it does, then respond to the 
instructions I gave Fabio Gastaldi two years ago in that same email 
thread.  (Maybe Fabio didn't ever make it to his office.)


> 2) General behavior of iaxmodem
> As I learned during the past days, a device in /dev/pts behaves 
> different than other devices of /dev.
> If I understand this right, faxgetty needs full control to a modem 
> device in order to work properly. This is why the systemd unit of 
> faxgetty has the line BindsTo=dev-%i.device, so if faxgetty starts and 
> grabs the device, it cannot be detached easily and if the device 
> disappears, faxgetty also terminates.


I don't think that BindsTo is necessary or even desireable. faxgetty can 
operate to a limited extent without the modem being there... it will 
send alerts to notify someone about the modem being unresponsive.  So, 
if iaxmodem disappears without the administrator deliberately making it 
stop, then there is a problem (that I'd certainly like to know about), 
and the notification from faxgetty should be desirable.  Furthermore, if 
iaxmodem restarts quickly then the same faxgetty process could likely 
reattach to it and continue on its merry way.


> For a software device like iaxmodem this rule doesn't work. Not sure 
> what is the most elegant way to solve this. Maybe something outside of 
> udev? We'll see, when it comes to systemd units, this is totally up to 
> Giuseppe's decision how to handle this, we can skip this discussion 
> here too.


I'm sure that BindsTo is useful for other things.  I just don't think 
that it's useful for iaxmodem or faxgetty.


> At next, the question arised how iaxmodem handles it's devices. In 
> order to give faxgetty full control over the device, the daemon must 
> be kind of robust which means it must take notice of any running 
> instances or existing ttyIAX-devices. This doesn't seem to be the case 
> for iaxmodem. If I understand this right, iaxmodem runs at startup 
> through all available configs and creates the devices. If, by 
> accident, another instance of iaxmodem is started manually, the 
> symlinks are overwritten with new target in /dev/pts.


If being robust requires that it check for exclusivity then that 
certainly could be done.  You're welcome to make a code patch that 
accomplishes this and submit it.  However, I'm not sure why it's 
necessary.  Why is iaxmodem being started multiple times by accident?  
Isn't that accident of more concern than how iaxmodem responds to the 
accident?  Maybe both are valid concerns, but if the accident didn't 
happen in the first place then iaxmodem wouldn't need to cope with it.


> So, the device node (symlink actually) is not stable and changes.


I disagree.  The symlink is constant until iaxmodem is restarted.  If 
iaxmodem is restarting without the administrator's intention, then there 
is another problem (a more serious problem) besides the symlink that 
needs to be addressed.


> I'm not sure how this affects the behavior of faxgetty. I started 
> several instances of iaxmodem to test this and could see in logs of 
> asterisk how different ports are used for the same device, although 
> sending faxes seemed to work. Not sure about receiving faxes, because 
> I wasn't successfull yet with receiving faxes at all (iaxmodem rings 
> but faxgetty doesn't pick up!?).


I don't know what this is.  Maybe it has something to do with the tests 
you're trying to run.  I'd need to see some logs to know what's happening.


> Lee, do you think this behavior of iaxmodem could cause some trouble? 
> Would it make sense to implement something like a file lock for the 
> symlinks then? Do file locks even work with symlinks?


Well, faxgetty does put a lock on the symlink to prevent other processes 
from attempting to use it.  I'm not sure what you are getting at, though.

As for trouble being caused by iaxmodem behavior... I don't know what 
trouble you refer to.

I've attached a sample copy of systemd service files that I use for a 
single iaxmodem/faxgetty pair.  These work fine for me.

Thanks,

Lee.

Re: [iaxmodem-users] iaxmodem and systemd device units

[<deb...@dc...>]

Hello Lee,
hello Giuseppe,

thanks for bringing this issue on the mailing list, Giuseppe.

Lee, let me summarize the situation: In Debian (and probably it's derivatives) it seems like we have two issues when hylafax interacts with iaxmodem:

1) faxaddsetup
As mentioned here earlier (https://sourceforge.net/p/iaxmodem/mailman/message/37198241/), faxaddsetup hangs while detecting a modem created with iaxmodem. While faxaddsetup asks the modem for it's supported classes, the script hangs and can only stopped with SIGKILL.
This, for me, is a minor issue, because a user can skip this step and just copy config.ttyIAX to the config directory of hylafax (as mentioned in FAQ as well). Nevertheless it's an annoying bug.

2) General behavior of iaxmodem
As I learned during the past days, a device in /dev/pts behaves different than other devices of /dev.
If I understand this right, faxgetty needs full control to a modem device in order to work properly. This is why the systemd unit of faxgetty has the line BindsTo=dev-%i.device, so if faxgetty starts and grabs the device, it cannot be detached easily and if the device disappears, faxgetty also terminates.

For a software device like iaxmodem this rule doesn't work. Not sure what is the most elegant way to solve this. Maybe something outside of udev? We'll see, when it comes to systemd units, this is totally up to Giuseppe's decision how to handle this, we can skip this discussion here too.

At next, the question arised how iaxmodem handles it's devices. In order to give faxgetty full control over the device, the daemon must be kind of robust which means it must take notice of any running instances or existing ttyIAX-devices. This doesn't seem to be the case for iaxmodem. If I understand this right, iaxmodem runs at startup through all available configs and creates the devices. If, by accident, another instance of iaxmodem is started manually, the symlinks are overwritten with new target in /dev/pts. So, the device node (symlink actually) is not stable and changes. I'm not sure how this affects the behavior of faxgetty. I started several instances of iaxmodem to test this and could see in logs of asterisk how different ports are used for the same device, although sending faxes seemed to work. Not sure about receiving faxes, because I wasn't successfull yet with receiving faxes at all (iaxmodem rings but faxgetty doesn't pick up!?).

Lee, do you think this behavior of iaxmodem could cause some trouble? Would it make sense to implement something like a file lock for the symlinks then? Do file locks even work with symlinks?


Thanks,
Tino

Re: [iaxmodem-users] iaxmodem and systemd device units

[Lee H. <fa...@ho...>]

Hello Giuseppe,

If I understand correctly, Tino would like to have udev trigger systemd 
to start faxgetty processes when udev notices an iaxmodem start up.  I'm 
guessing that Tino has some kind of experience with this functionality 
based on connecting and disconnecting removable modems, like USB ones, 
and he'd like to use the same functions with iaxmodems.

Since it's rather trivial to configure systemd to have faxgettys start 
at boot time after their corresponding iaxmodem starts, I'm guessing 
that Tino intends to start and stop iaxmodems at will and wants that 
action to trigger faxgettys to start, rather than starting faxgettys 
separately and rather than scripting both iaxmodem and faxgetty to 
operate together and to toggle that script rather than whatever iaxmodem 
toggle he has.

I don't mean to trivialize Tino's request, but it does seem a bit 
esoteric when there are so many other ways to accomplish iaxmodems and 
faxgettys to start in order.

As for the appropriateness of udev to monitor created ptys, directly, I 
don't think that it should... since those ptys mostly get created for 
other things besides iaxmodems.

Maybe someone here on this list has some experience with udev and knows 
how to configure or modify udev to trigger things based on the 
appearance of a symlink.  If so, hopefully they'll chime in.

Maybe there is something that iaxmodem could do differently to assist 
this udev trigger.  If there is something, then I'm happy to make 
appropriate modifications to iaxmodem.

However, my guess is that Tino and others who want to start or stop 
iaxmodems and have that operation trigger faxgetty to start or stop 
should consider the other ways to accomplish the same.

Thanks,

Lee.


On 2/18/23 5:17 AM, Giuseppe Sacco via iaxmodem-users wrote:
> Hello,
> I am writing here for help about the integration of iaxmodem and udev events
> (and systemd device unit).
> The original problem is described in Debian bug #1031200
> (http://bugs.debian.org/1031200).
>
> The question is: how may I start a systemd service based on the activation of
> a device such /dev/ttyIAX<n>? From what I understood, this path corresponds to
> a link to a the real device node in /dev/pts. When such a link is created, no
> udev events are triggered, so no systemd units can be started automatically.
>
> Before getting here, I also asked this question on the systemd-devel mailing
> list. You may read the thread here:
> https://lists.freedesktop.org/archives/systemd-devel/2023-February/048814.html
>
> Thank you,
> Giuseppe
>
>
> _______________________________________________
> iaxmodem-users mailing list
> iax...@li...
> https://lists.sourceforge.net/lists/listinfo/iaxmodem-users

[iaxmodem-users] iaxmodem and systemd device units

[Giuseppe S. <giu...@sg...>]

Hello,
I am writing here for help about the integration of iaxmodem and udev events
(and systemd device unit).
The original problem is described in Debian bug #1031200
(http://bugs.debian.org/1031200).

The question is: how may I start a systemd service based on the activation of
a device such /dev/ttyIAX<n>? From what I understood, this path corresponds to
a link to a the real device node in /dev/pts. When such a link is created, no
udev events are triggered, so no systemd units can be started automatically.

Before getting here, I also asked this question on the systemd-devel mailing
list. You may read the thread here:
https://lists.freedesktop.org/archives/systemd-devel/2023-February/048814.html

Thank you,
Giuseppe

[iaxmodem-users] iaxmodem v1.3.4 released

[Lee H. <fa...@ho...>]

Hello Everyone,

I've released IAXmodem version 1.3.4 today.

As usual it can be downloaded from links at http://iaxmodem.sourceforge.net.

The changes are as follows:

         implement S11 and S12 jitter counters
         try to cope with upstream jitter
         avoid superfluous CONNECT message when delayed after +FTH=3
         send NO CARRIER message if hangup occurs during data transmit

These are probably self-explanatory for those interested. However, I 
feel that the changes regarding coping with upstream jitter may warrant 
some explanation.

On the inbound audio path jitter generally appears as null audio data.  
One VoIP packet is 20ms, and because there is no normal fax signaling 
where a 20ms period of silence is useful or specified, one can safely 
conclude that 20ms of null audio data is jitter and can safely be ignored.

In fact, there is no expected fax signaling where anything less than 
60ms of silence is useful or specified.  So, because a VoIP packet is 
20ms, one can safely conclude that anything from about 20ms to about 
60ms of null data can only be introduced jitter, and may thus be safely 
ignored.

So the changes in iaxmodem 1.3.4 have code that deliberately discards 
suspected jitter audio data as described.

These changes will not likely save fax sessions that are plagued with a 
significant amount of jitter.  However, these changes will likely 
improve fax sessions where a very limited amount of jitter can sometimes 
interrupt incoming fax signals.  So, it can help avoid needing to have 
the remote end retransmit the signal, and thus can slightly speed up fax 
sessions or possibly prevent those sessions from failing.

Again, it's not going to help enough to rescue audio that is plagued 
with a lot of jitter.  Expect only minor, perhaps even undetectable 
improvement.

Thanks,

Lee.

[iaxmodem-users] iaxmodem-1.3.3 released

[Lee H. <fa...@ho...>]

Everyone,

I've released IAXmodem v1.3.3 today.

The changes are as follows:

         prevent multiple CONNECT messages after +FRH=3
         initialize tioflags before using (Robert Boisvert, Alpine Linux 
team)
         partially import a change from upstream libiax2 to address 
invalid read
             size in iax_get_event (Robert Boisvert, Alpine Linux team)
         import a change from upstream spandsp to address uninitialixed 
value
             in at_cmd_plus_VSID (Robert Boisvert, Alpine Linux team)

As always, please let me know if you have any issues.

Thank you,

Lee.

Re: [iaxmodem-users] Robustness of V.17 (no ECM) over VoIP?

[Lee H. <fa...@ho...>]

Hello Gert.

I'm always glad to hear from you.

My replies are in-line below.

On 02/08/2021 12:05 AM, Gert Doering wrote:
> Good morning,
>
> I am trying to understand something - or, more precisely, I have a theory
> how the world should work, but observation conflicts with the theory.  I'm
> sending this *here* because I assume that this is the last bastion of
> "in-depth fax signal understanding"...

For myself, I've been missing Steve Underwood.  I haven't heard from him 
in over a year now.

> Theory first:
>
>    "14400 fax is more robust than 9600 fax over VoIP, because typical
>     problems with VoIP (packet loss) should apply in a statistical manner,
>     and since the 9600 bps call takes *longer*, statistics should make
>     packet losses hit more often"  (without ECM).

It's complicated, though.

In its smallest form, jitter amounts to a single 20ms of missing audio 
somewhere in the audio stream.  If using V.17 14400 bps then the 
likelihood that the jitter falls on a time in the fax session where it 
causes failure or where the image data is completely corrupted is less 
than with V.29 9600 bps because the fax session is quicker at 14400.  
However, if that 20ms of missing audio lands within the Phase C portions 
of the protocol then the jitter will do more damage to the data at 14400 
bps than at 9600 bps.

So, on a theoretical level there is an interesting situation here. If 
you know that the jitter bullets are being fired in your direction you 
want to be as thin and as compressed as possible in order to avoid 
getting hit.  However, if you know that the jitter bullet is going to 
hit you, then you want to be as uncompressed as possible so that the 
jitter bullet does as little damage as possible.

That's the theory, anyway.  I think that the actual practice of 
resilience from jitter damage is going to be deeper in the nuts and 
bolts, algorithms, and specific implementations of V.29 versus V.17.

> Experiment 1:
>
>    freeswitch/spandsp --(SIP, G.711) --> 3CX PBX --(SIP)--> Telco
>      --> same Telco --(ISDN)--> old Ackermann PBX --(analog)--> ZyXEL 1496
>
>    What I observe is that pages sent with 14400/v.17 have a significant
>    number of lines missing.  Like, 2380 lines sent, 1600 lines received(!).
>
>    If I send with V.17 turned off, using 9600 bps, the received pages
>    are fine.
>
>
> Experiment 2:
>
>    same SIP and ISDN path, just using a USR I-Modem as receiver, also no ECM
>
>    freeswitch/spandsp --(SIP, G.711) --> 3CX PBX --(SIP)--> Telco
>      --> same Telco --(ISDN)--> USR I-Modem
>
>    *most* pages are perfect with V.17/14400 (one page in a 11-page fax is
>    missing some lines).
>
>
> I can't remember ever having such massive problems with the ZyXEL 1496
> on the old PBX - usually the 1496s have been my workhorses, and always work.

I presume that by "9600 bps" you mean V.29 9600 bps and not V.17 9600 bps.

I think what you're seeing here is a weakness in the ZyXEL 1496 
implementation of V.17 when involving either jitter and/or audio 
artifacts introduced by the call audio path (namely the 3C PBX and the 
Ackermann PBX) as compared to the V.17 implementation on the USR 
I-Modem.  It may or may not have much to do with VoIP and jitter at all.

I think if you were dealing with a significant VoIP/jitter issue that 
you'd see a lot of lines also missing with V.29 on the ZyXEL. That the 
ZyXEL has no missing lines with V.29 seems to suggest that there is no 
real jitter at play.  V.29 doesn't have any ability to magically 
resurrect missing data.

> So - after this introduction, now the questions :-)
>
>   - should 9600 be more robust than 14400 over VoIP?
>     - why (either way)?

It depends.  See my explanation about dodging bullets above.

As for how well a V.17 demodulator can theoretically recover from a 
jitter bullet as compared to a V.29 demodulator, I honestly don't know.  
However, my suspicion is that V.29 is likely to recover marginally 
better because less damage is done overall by 20 ms of missing audio.  
That said, neither V.17 nor V.29 were designed to cope with jitter 
(which would require regular re-syncs within the modulation - and to the 
best of my knowledge neither do).  So, for there to be any performance 
difference between them in the presence of jitter is not terribly useful 
as both of them will fare poorly with jitter.  Whether one is less-poor 
than the other seems rather unhelpful.

Again, I suspect that the issue you're examining is less about VoIP 
jitter and more about audio artifacts and perturbations due to the 
specific equipment involved.

>   - what are the effects of VoIP mistreatment of "fax audio"?

As long as it's G.711 alaw/ulaw then the answer is jitter and only 
jitter.  It's jitter either to latency or jitter due to packet loss.

And, I guess to be fair, also because T.38 is so prevalent in VoIP 
networks then there's also that to worry about.  If T.38 is involved 
then there's double the trouble because each endpoint is really doing 
its T.30 with a T.38 gateway rather than with the remote endpoint.  So, 
then there's not only jitter to worry about but also T.38 resiliency and 
compatibility.

>     I can see "packet loss" leading to "missing lines" or "prematurely
>     ending pages", and "wrong codec negotiated" leading to "fax is
>     compressed to death, and not working at all anymore"
>
>
> What I already know is "with ECM, things usually work" :-)  (even with
> higher bit rates, though I can't use them with freeswitch/spandsp).

By "higher bit rates" I presume that you mean V.34?

Steve did a considerable amount of work for V.34 in spandsp... however, 
I've not been able to get it to work, and I haven't spent that much time 
on it because V.34-Fax (SuperG3) requires the carrier to be up for the 
entire call.  Jitter is likely to kill any V.34-Fax session, and because 
of the likelihood of there being some jitter on the call I've just not 
worried much about it.

While I have your attention, can I interest you in looking at 
implementing SSL Fax?  If you control both endpoints (and this scenario 
turns out to be very commonplace) and can ensure that both endpoints 
support SSL Fax, then VoIP jitter becomes irrelevant.  And as SSL Fax 
becomes more widely adopted then you'll naturally be able to tap into 
that growing advantage over time.

https://hylafax.sourceforge.io/sslfax.php

Thanks,

Lee.

[iaxmodem-users] Robustness of V.17 (no ECM) over VoIP?

[Gert D. <ge...@gr...>]

Good morning,

I am trying to understand something - or, more precisely, I have a theory
how the world should work, but observation conflicts with the theory.  I'm 
sending this *here* because I assume that this is the last bastion of
"in-depth fax signal understanding"...

Theory first: 

  "14400 fax is more robust than 9600 fax over VoIP, because typical
   problems with VoIP (packet loss) should apply in a statistical manner,
   and since the 9600 bps call takes *longer*, statistics should make
   packet losses hit more often"  (without ECM).

Experiment 1:

  freeswitch/spandsp --(SIP, G.711) --> 3CX PBX --(SIP)--> Telco
    --> same Telco --(ISDN)--> old Ackermann PBX --(analog)--> ZyXEL 1496

  What I observe is that pages sent with 14400/v.17 have a significant 
  number of lines missing.  Like, 2380 lines sent, 1600 lines received(!).

  If I send with V.17 turned off, using 9600 bps, the received pages
  are fine.


Experiment 2: 

  same SIP and ISDN path, just using a USR I-Modem as receiver, also no ECM

  freeswitch/spandsp --(SIP, G.711) --> 3CX PBX --(SIP)--> Telco
    --> same Telco --(ISDN)--> USR I-Modem

  *most* pages are perfect with V.17/14400 (one page in a 11-page fax is 
  missing some lines).


I can't remember ever having such massive problems with the ZyXEL 1496
on the old PBX - usually the 1496s have been my workhorses, and always work.


So - after this introduction, now the questions :-)

 - should 9600 be more robust than 14400 over VoIP?
   - why (either way)?

 - what are the effects of VoIP mistreatment of "fax audio"?

   I can see "packet loss" leading to "missing lines" or "prematurely
   ending pages", and "wrong codec negotiated" leading to "fax is
   compressed to death, and not working at all anymore"


What I already know is "with ECM, things usually work" :-)  (even with
higher bit rates, though I can't use them with freeswitch/spandsp).

thanks,

gert

-- 
"If was one thing all people took for granted, was conviction that if you 
 feed honest figures into a computer, honest figures come out. Never doubted 
 it myself till I met a computer with a sense of humor."
                             Robert A. Heinlein, The Moon is a Harsh Mistress

Gert Doering - Munich, Germany                             ge...@gr...

Re: [iaxmodem-users] Can IAXModem receive a call, and will it work on 32-bit ARM?

[Lee H. <fa...@ho...>]

Even if spandsp within iaxmodem were capable of traditional data modes 
(and it isn't) the first bit of jitter that you experienced in the call 
would probably derail the connection unless the data carrier mode were 
capable of renegotiating/retraining after carrier loss occurred.

The reason that fax will somewhat reliably work sometimes in good 
conditions over a VoIP connection with jitter is because in traditional 
fax modes (e.g. V.17 and V.21) the data carriers are deliberately and 
predictably started and stopped.  So a bit of jitter turns into a 
premature carrier loss, but the fax protocol is sometimes able to 
recover from it.

I don't think that the outcome will be satisfactory even if data modes 
were possible on iaxmodem (and they're not).

Thanks,

Lee.


On 01/24/2021 11:10 PM, Andrew Bobulsky wrote:
> Hello,
>
> I'm exploring using IAXModem as a pppd modem bank, in a manner similar
> to the attached photo. After reviewing the documentation, I don't see
> any reason it wouldn't work, but the use case for which the software
> was designed appears to be quite literally the opposite of what I'm
> trying to achieve, and I don't see any mention of receiving calls in
> the docs. I thought I'd ask the experts for their opinion.
>
> Also, any idea if it'll work on a Raspberry Pi running 32-bit
> Raspbian?  I was able to build the statically compiled version of the
> app and it starts up enough to complain about the missing config
> files. I'll figure it out soon enough but just asking for convenience
> sake. Moving to x86 isn't a big deal.
>
> Thanks,
> Andrew
>
>
>
>
> _______________________________________________
> iaxmodem-users mailing list
> iax...@li...
> https://lists.sourceforge.net/lists/listinfo/iaxmodem-users

[iaxmodem-users] Can IAXModem receive a call, and will it work on 32-bit ARM?

[Andrew B. <ru...@gm...>]

Hello,

I'm exploring using IAXModem as a pppd modem bank, in a manner similar
to the attached photo. After reviewing the documentation, I don't see
any reason it wouldn't work, but the use case for which the software
was designed appears to be quite literally the opposite of what I'm
trying to achieve, and I don't see any mention of receiving calls in
the docs. I thought I'd ask the experts for their opinion.

Also, any idea if it'll work on a Raspberry Pi running 32-bit
Raspbian?  I was able to build the statically compiled version of the
app and it starts up enough to complain about the missing config
files. I'll figure it out soon enough but just asking for convenience
sake. Moving to x86 isn't a big deal.

Thanks,
Andrew

Re: [iaxmodem-users] Issue with Hylafax on Ubuntu 20

[Lee H. <fa...@ho...>]

faxaddmodem should work fine with iaxmodem.  It does for me.

The problem may be due to lockfile configuration or some other matter.

faxaddmodem is just a shell script.  It will throw a lot of output, but 
you can run it this way:

sh -x /usr/sbin/faxaddmodem ttyIAX

See what that does.  (I assume that /usr/sbin/faxaddmodem is the correct 
path.)

Thanks,

Lee.


On 01/15/2021 06:09 AM, Fabio Gastaldi via iaxmodem-users wrote:
>
> Hello i tried two time to install hylafax with iaxmodem (it’s not the 
> first time I install this configuration)
>
> This time I’m on a Ubuntu 20
>
> The issue appear when I try to use FAXADDMODEM it stuck during probing 
> phase  just after 38400 I left it there for hours.
>
> I tried to reinstall everythings and same issue.
>
> No informations from logs
>
> I installed minicom and ttyIAX (iaxmodem port) is working perfectly 
> and I’m able to dialout.
>
> I really don’t know where the problem is.
>
> Any help will be much appreciate.
>
> Regards
>
> Fabio
>
> Advnet Logo
>
> 	
>
> Fabio Gastaldi
> Managing Director
> fab...@ad...
> *************************
> Advnet s.r.l.
> Via Marco Corner, 19/21 - 36016 Thiene (VI) Italy
> +39 0445-371093
> +39 0445-371094
> www.advnet.it
> Privacy Email <https://www.advnet.it/privacy-email>
> *************************
> Linkedin logo <https://www.linkedin.com/company/advnet-s.r.l.>
>
>
> 	
>
> Please consider the environment before printing this email message. 
>  Please consider the environment before printing this email message.
>
>
>
>
>
> _______________________________________________
> iaxmodem-users mailing list
> iax...@li...
> https://lists.sourceforge.net/lists/listinfo/iaxmodem-users

Re: [iaxmodem-users] Issue with Hylafax on Ubuntu 20

[Fabio G. <Fab...@ad...>]

Thank you Lee i will try that on monday as soon i will get to the office. Best regards
Fabio




[https://www.advnet.it/wp-content/uploads/2017/07/logo-15-90px_new.png]




Fabio Gastaldi
Managing Director
*************************
Advnet s.r.l.
Via Marco Corner, 19/21 - 36016 Thiene (VI) Italy
www.advnet.it
Privacy Email<https://www.advnet.it/privacy-email>





[https://www.advnet.it/wp-content/uploads/2016/10/please-think-the-enviroment-before-printing.gif]<http://>
Please consider the environment before printing this email message.

Il giorno 15 gen 2021, alle ore 18:58, Lee Howard <fa...@ho...> ha scritto:


Questa è la prima volta che ricevi un'email da questo mittente. Assicurati che sia qualcuno di cui ti fidi.
faxaddmodem should work fine with iaxmodem.  It does for me.

The problem may be due to lockfile configuration or some other matter.

faxaddmodem is just a shell script.  It will throw a lot of output, but you can run it this way:

sh -x /usr/sbin/faxaddmodem ttyIAX

See what that does.  (I assume that /usr/sbin/faxaddmodem is the correct path.)

Thanks,

Lee.


On 01/15/2021 06:09 AM, Fabio Gastaldi via iaxmodem-users wrote:
Hello i tried two time to install hylafax with iaxmodem (it’s not the first time I install this configuration)
This time I’m on a Ubuntu 20
The issue appear when I try to use FAXADDMODEM it stuck during probing phase  just after 38400 I left it there for hours.

I tried to reinstall everythings and same issue.
No informations from logs
I installed minicom and ttyIAX (iaxmodem port) is working perfectly and I’m able to dialout.

I really don’t know where the problem is.
Any help will be much appreciate.
Regards
Fabio





[Advnet                      Logo]




Fabio Gastaldi
Managing Director
fab...@ad...<mailto:fab...@ad...>
*************************
Advnet s.r.l.
Via Marco Corner, 19/21 - 36016 Thiene (VI) Italy
+39 0445-371093
+39 0445-371094
www.advnet.it<http://www.advnet.it>
Privacy Email<https://www.advnet.it/privacy-email>
*************************
[Linkedin logo]<https://urlsand.esvalabs.com/?u=https%3A%2F%2Fwww.linkedin.com%2Fcompany%2Fadvnet-s.r.l.&e=3d7b0c5a&h=78389943&f=n&p=y>





 [Please consider the environment before                        printing this email message.]    Please consider the environment before printing this email message.





_______________________________________________
iaxmodem-users mailing list
iax...@li...<mailto:iax...@li...>
https://lists.sourceforge.net/lists/listinfo/iaxmodem-users<https://urlsand.esvalabs.com/?u=https%3A%2F%2Flists.sourceforge.net%2Flists%2Flistinfo%2Fiaxmodem-users&e=3d7b0c5a&h=21ff0af6&f=n&p=y>



--
Questo messaggio e' stato analizzato con Libraesva ESG ed e' risultato non infetto.
Clicca qui per segnalarlo come spam.<https://antispam.advnet.it/action/84DBA41D10.A3066/learn-spam>
Clicca qui per metterlo in blacklist<https://antispam.advnet.it/cgi-bin/learn-msg.cgi?blacklist=1&id=84DBA41D10.A3066>

[iaxmodem-users] Issue with Hylafax on Ubuntu 20

[Fabio G. <Fab...@ad...>]

Hello i tried two time to install hylafax with iaxmodem (it’s not the first time I install this configuration)
This time I’m on a Ubuntu 20
The issue appear when I try to use FAXADDMODEM it stuck during probing phase  just after 38400 I left it there for hours.

I tried to reinstall everythings and same issue.
No informations from logs
I installed minicom and ttyIAX (iaxmodem port) is working perfectly and I’m able to dialout.

I really don’t know where the problem is.
Any help will be much appreciate.
Regards
Fabio





[Advnet Logo]




Fabio Gastaldi
Managing Director
fab...@ad...
*************************
Advnet s.r.l.
Via Marco Corner, 19/21 - 36016 Thiene (VI) Italy
+39 0445-371093
+39 0445-371094
www.advnet.it
Privacy Email<https://www.advnet.it/privacy-email>
*************************
[Linkedin logo]<https://www.linkedin.com/company/advnet-s.r.l.>




 [Please consider the environment before printing this email message.]           Please consider the environment before printing this email message.

Re: [iaxmodem-users] IAXmodem 1.3.2 released

[Tim N. <tn...@sa...>]

That's great Lee, thank you!

--Tim

On Thu, Jul 16, 2020 at 10:44 PM Lee Howard <fa...@ho...> wrote:

> Everyone,
>
> I have released IAXmodem v1.3.2 today.  You can download it from links
> at http://iaxmodem.sourceforge.net.
>
> The changes from v1.3.0 are as follows:
>
>         add audiobuflen feature
>         fix file modification times on spandsp in tarball
>         stop fast looping after 45 seconds of calling state
> 1.3.1
>          fix bug (segfault) on some hangups (Stephan Eisvogel)
>         support passing "+" in the dialstring
>         simulate hangup when replay EOF is encountered
>
> There was an unannounced v1.3.1 release which did not compile well due
> to make problems with file modification times in spandsp.  This was
> fixed in v1.3.2.
>
> There is nothing particularly urgent in needing to update from v1.3.0,
> however, the bug fixes (the segfault and fast looping) are nice.
>
> The audiobuf has been fixed at 100 packets.  On some systems which
> encounter occasional heavy loads it may be necessary to increase this
> to, say, 500.  A setting of 100 is still the default.
>
> Also, I haven't heard from Steve Underwood (spandsp author) since
> September of 2018.  So, if any of you know of his whereabouts, please
> let me know.
>
> Thanks,
>
> Lee.
>
>
>
> _______________________________________________
> iaxmodem-users mailing list
> iax...@li...
> https://lists.sourceforge.net/lists/listinfo/iaxmodem-users
>

[iaxmodem-users] IAXmodem 1.3.2 released

[Lee H. <fa...@ho...>]

Everyone,

I have released IAXmodem v1.3.2 today.  You can download it from links
at http://iaxmodem.sourceforge.net.

The changes from v1.3.0 are as follows:

        add audiobuflen feature
        fix file modification times on spandsp in tarball
        stop fast looping after 45 seconds of calling state
1.3.1
         fix bug (segfault) on some hangups (Stephan Eisvogel)
        support passing "+" in the dialstring
        simulate hangup when replay EOF is encountered

There was an unannounced v1.3.1 release which did not compile well due
to make problems with file modification times in spandsp.  This was
fixed in v1.3.2.

There is nothing particularly urgent in needing to update from v1.3.0,
however, the bug fixes (the segfault and fast looping) are nice.

The audiobuf has been fixed at 100 packets.  On some systems which
encounter occasional heavy loads it may be necessary to increase this
to, say, 500.  A setting of 100 is still the default.

Also, I haven't heard from Steve Underwood (spandsp author) since
September of 2018.  So, if any of you know of his whereabouts, please
let me know.

Thanks,

Lee.

Re: [iaxmodem-users] Dial issues with numbers prefixed with +

[Hans-Peter J. <hp...@ur...>]

Dear Lee,

On Montag, 10. September 2018 21:11:43 Lee Howard wrote:
> On 09/10/2018 04:25 AM, Hans-Peter Jansen wrote:
> > In my tests, I stumbled across a small nuisance though, when it comes to
> > dialing destinations prefixed with +.
> > 
> > Sending a fax with:
> > sendfax -Gnd +491234567890 testfax.pdf results in:
> > .....
> > iaxmodem debug log:
> > [2018-09-10 12:31:21.170383] Registration completed successfully.
> > [2018-09-10 12:31:52.297789] Hanging Up
> > [2018-09-10 12:32:00.831813] Hanging Up
> > [2018-09-10 12:32:03.920988] Dialing '491234567890'
> 
> ITU-T V.250 6.3.1 defines the ATD command.  It states:
> 
> "Any characters appearing in the dial string that the DCE does not
> recognize as a valid part of the call addressing information or as a
> valid modifier shall be ignored. This permits characters such as
> parentheses and hyphens to be included that are typically used in
> formatting of telephone numbers."
> 
> The permissible dialing digits are defined in the following section:
> 6.3.1.1.  The "+" character is permissible, as with *, #, A, B, C, and
> D.  However, spandsp is removing/ignoring the "+".  The untested,
> attached patch should get it to pass the "+" along.

Thank you for pointing me to the right place. 

Since falling through the switch is smelling a bit, I came up with the 
attached patch.

Works fine here (yours would work fine as well, of course!). Allowing a single 
+ prefix only might avoid any nasty surprises down the road...

Again, thank you very much for everything!

Cheers,
Pete

Re: [iaxmodem-users] Dial issues with numbers prefixed with +

[Lee H. <fa...@ho...>]

On 09/10/2018 04:25 AM, Hans-Peter Jansen wrote:
> In my tests, I stumbled across a small nuisance though, when it comes to 
> dialing destinations prefixed with +.
>
> Sending a fax with:
> sendfax -Gnd +491234567890 testfax.pdf results in:
> .....
> iaxmodem debug log:
> [2018-09-10 12:31:21.170383] Registration completed successfully.
> [2018-09-10 12:31:52.297789] Hanging Up
> [2018-09-10 12:32:00.831813] Hanging Up
> [2018-09-10 12:32:03.920988] Dialing '491234567890'

ITU-T V.250 6.3.1 defines the ATD command.  It states:

"Any characters appearing in the dial string that the DCE does not
recognize as a valid part of the call addressing information or as a
valid modifier shall be ignored. This permits characters such as
parentheses and hyphens to be included that are typically used in
formatting of telephone numbers."

The permissible dialing digits are defined in the following section:
6.3.1.1.  The "+" character is permissible, as with *, #, A, B, C, and
D.  However, spandsp is removing/ignoring the "+".  The untested,
attached patch should get it to pass the "+" along.

Thanks,

Lee.

[iaxmodem-users] Dial issues with numbers prefixed with +

[Hans-Peter J. <hp...@ur...>]

Dear Lee,

I'm enjoying your iaxmodem package in a test setup, that should go into 
production soon. Thank you for all your invest to keep faxing possible.

It's a small Asterisk 15.5.0 system, with Hylafax+-5.6.0, spandsp 0.0.6, 
and iaxmodem 1.3.0, based on openSUSE Leap 15.0.

In my tests, I stumbled across a small nuisance though, when it comes to 
dialing destinations prefixed with +.

Sending a fax with:
sendfax -Gnd +491234567890 testfax.pdf results in:

Hylafax+ log:
Sep 10 12:32:03.87: [11325]: SESSION BEGIN 000000154 +491234567890
Sep 10 12:32:03.87: [11325]: HylaFAX (tm) Version 5.6.0
Sep 10 12:32:03.87: [11325]: SEND FAX: JOB 23 DEST +491234567890 COMMID 000000154 DEVICE '/dev/ttyIAX0' FROM 'Hans-Peter Jansen <hp@local-site>' USER hp
Sep 10 12:32:03.87: [11325]: STATE CHANGE: RUNNING -> SENDING
Sep 10 12:32:03.87: [11325]: <-- [12:AT+FCLASS=1\r]
Sep 10 12:32:03.87: [11325]: --> [2:OK]
Sep 10 12:32:03.87: [11325]: MODEM set XON/XOFF/FLUSH: input ignored, output disabled
Sep 10 12:32:03.92: [11325]: DIAL +491234567890
Sep 10 12:32:03.92: [11325]: <-- [18:ATDT+491234567890\r]
Sep 10 12:32:03.92: [11325]: --> [4:BUSY]
Sep 10 12:32:03.92: [11325]: SEND FAILED: JOB 23 DEST +491234567890 ERR Busy signal detected {E001}
Sep 10 12:32:04.92: [11325]: <-- [5:ATH0\r]
Sep 10 12:32:04.92: [11325]: --> [2:OK]
Sep 10 12:32:04.92: [11325]: MODEM set DTR OFF
Sep 10 12:32:04.92: [11325]: MODEM set baud rate: 0 baud (flow control unchanged)
Sep 10 12:32:04.92: [11325]: STATE CHANGE: SENDING -> MODEMWAIT (timeout 5)
Sep 10 12:32:04.95: [11325]: SESSION END

iaxmodem debug log:
[2018-09-10 12:31:21.170383] Registration completed successfully.
[2018-09-10 12:31:52.297789] Hanging Up
[2018-09-10 12:32:00.831813] Hanging Up
[2018-09-10 12:32:03.920988] Dialing '491234567890'
Tx-Frame Retry[010] -- OSeqno: 000 ISeqno: 000 Type: IAX     Subclass: NEW    
   Timestamp: 00003ms  SCall: 21508  DCall: 00000 [127.0.0.1:4569]
   VERSION         : 2
   CALLING NUMBER  : +491357913579
   CALLING NAME    : Some Company
   FORMAT          : 64
   CAPABILITY      : 76
   USERNAME        : iaxmodem0
   CALLED NUMBER   : 491234567890
   DNID            : 491234567890

asterisk log:
[Sep 10 12:31:21]     -- Registered IAX2 'iaxmodem0' (AUTHENTICATED) at 127.0.0.1:4570
[Sep 10 12:32:03]     -- Accepting AUTHENTICATED call from 127.0.0.1:4570:
[Sep 10 12:32:03]     --        > requested format = slin,
[Sep 10 12:32:03]     --        > requested prefs = (),
[Sep 10 12:32:03]     --        > actual format = ulaw,
[Sep 10 12:32:03]     --        > host prefs = (ulaw|alaw),
[Sep 10 12:32:03]     --        > priority = mine
[Sep 10 12:32:03]     -- Executing [491234567890@outbound:1] Verbose("IAX2/iaxmodem0-15876", "1,"Outgoing call from +491357913579 to 491234567890"") in new stack
[Sep 10 12:32:03]  "Outgoing call from +491357913579 to 491234567890"
[Sep 10 12:32:03]     -- Auto fallthrough, channel 'IAX2/iaxmodem0-15876' status is 'UNKNOWN'
[Sep 10 12:32:03]     -- Hungup 'IAX2/iaxmodem0-15876'
[Sep 10 12:33:43] NOTICE[2265]: chan_iax2.c:12303 __iax2_poke_noanswer: Peer 'iaxmodem0' is now UNREACHABLE! Time: 1


E.g. the hylafax dial command seems fine, but somewhere in iaxmodem, the 
plus gets lost. Replacing the + with the land line prefix: 001234567890 
works fine. Calls to +something work fine as well.

iaxmodem uses the system provided spandsp version, that differs in one 
place from the version, included in iaxmodem:

diff -up -r ../iaxmodem/iaxmodem-1.3.0/lib/spandsp/src/v17rx.c spandsp-0.0.6/src/v17rx.c
--- ../iaxmodem/iaxmodem-1.3.0/lib/spandsp/src/v17rx.c  2016-02-07 02:24:28.000000000 +0100
+++ spandsp-0.0.6/src/v17rx.c   2014-06-30 18:21:39.000000000 +0200
@@ -1046,10 +1046,10 @@ static void process_half_baud(v17_rx_sta
             s->carrier_track_i = 100.0f;
             s->carrier_track_p = 500000.0f;
 #endif
-            /* We need to be liberally accepting of poor fast-train training errors here.
-               Doing this affords the DTE the opportunity to make some use of whatever 
-               valid Phase C data can be decoded. */
-            if (s->training_error < (V17_TRAINING_SHORT_SEG_2_LEN - 8)*10.0f*constellation_spacing[s->space_map])
+            /* TODO: This was increased by a factor of 10 after studying real world failures.
+                     However, it is not clear why this is an improvement, If something gives
+                     a huge training error, surely it shouldn't decode too well? */
+            if (s->training_error < (V17_TRAINING_SHORT_SEG_2_LEN - 8)*4.0f*constellation_spacing[s->space_map])
             {
                 s->training_count = 0;
                 if (s->bits_per_symbol == 2)

I'm going to add this patch to spandsp now, but it doesn't matter for 
this case here.

For the record, I build my packages in public, available here:
https://build.opensuse.org/project/monitor/home:frispete:telephony:asterisk

Thanks in advance,
Pete

Re: [iaxmodem-users] "DTE was slow"

[Nabeel J. <na...@ja...>]

Thank you, Lee. I discovered the problem elsewhere. Now that the fax calls
are successful, I still see "DTW was slow" messages as you explained.

--
Nabeel Jafferali

On Tue, Sep 26, 2017 at 11:06 AM, Lee Howard <fa...@ho...>
wrote:

> The message "DTE was slow" means that the DTE (in your case this is
> HylaFAX) had the modem in command mode while the modem was off-hook and
> receiving audio.  This is not necessarily a problem and may happen to some
> extent normally as the DTE will have to issue various commands during a
> call, and that does take a split second or two to switch between commands.
>
> IAXmodem will buffer some audio received in the condition of the modem
> being in off-hook command-mode so that it will process it after the modem
> leaves command-mode.  This is to compensate for the slow DTE and to help
> avoid "missed" signals.
>
> I don't think that the problem is going to be visible in the IAXmodem
> logging.  Rather, I think that we need to look at the HylaFAX session log
> from /var/spool/hylafax/log.
>
> Thanks,
>
> Lee.
>
>
>
> On 09/25/2017 11:58 AM, Nabeel Jafferali wrote:
>
> Hello.
>
> I'm using Hylafax+ 5.5.9 with iaxmodem 1.3.0 and Asterisk 13.17.2. This is
> a new setup which I am trying to get to work.
>
> When sending faxes (sendfax -d 4165551212 <(416)%20555-1212>
> /etc/networks), I see the following on the iaxmodem console:
>
> [2017-09-25 14:36:17.076467] Call accepted.
> [2017-09-25 14:36:29.056984] Remote answered.
> [2017-09-25 14:36:37.416261] IAX2 jitter - last_ts: 20319, ts: 20360
> [2017-09-25 14:36:37.416396] Adjusting skew to -10.
> [2017-09-25 14:36:38.735735] DTE was slow.  Playing 160 samples of
> buffered audio.
> [2017-09-25 14:36:39.975046] DTE was slow.  Playing 160 samples of
> buffered audio.
> [2017-09-25 14:36:42.093991] DTE was slow.  Playing 960 samples of
> buffered audio.
> [2017-09-25 14:36:45.072521] DTE was slow.  Playing 16000 samples of
> buffered audio.
>
> and so on, until the remote part hangs up. The fax does fail.
>
> I'm not sure what I've configured wrong. Any ideas?
>
> --
> Nabeel Jafferali
>
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>
>
>
> _______________________________________________
> iaxmodem-users mailing lis...@li...https://lists.sourceforge.net/lists/listinfo/iaxmodem-users
>
>
>

Re: [iaxmodem-users] "DTE was slow"

[Lee H. <fa...@ho...>]

The message "DTE was slow" means that the DTE (in your case this is 
HylaFAX) had the modem in command mode while the modem was off-hook and 
receiving audio.  This is not necessarily a problem and may happen to 
some extent normally as the DTE will have to issue various commands 
during a call, and that does take a split second or two to switch 
between commands.

IAXmodem will buffer some audio received in the condition of the modem 
being in off-hook command-mode so that it will process it after the 
modem leaves command-mode.  This is to compensate for the slow DTE and 
to help avoid "missed" signals.

I don't think that the problem is going to be visible in the IAXmodem 
logging.  Rather, I think that we need to look at the HylaFAX session 
log from /var/spool/hylafax/log.

Thanks,

Lee.


On 09/25/2017 11:58 AM, Nabeel Jafferali wrote:
> Hello.
>
> I'm using Hylafax+ 5.5.9 with iaxmodem 1.3.0 and Asterisk 13.17.2. 
> This is a new setup which I am trying to get to work.
>
> When sending faxes (sendfax -d 4165551212 /etc/networks), I see the 
> following on the iaxmodem console:
>
> [2017-09-25 14:36:17.076467] Call accepted.
> [2017-09-25 14:36:29.056984] Remote answered.
> [2017-09-25 14:36:37.416261] IAX2 jitter - last_ts: 20319, ts: 20360
> [2017-09-25 14:36:37.416396] Adjusting skew to -10.
> [2017-09-25 14:36:38.735735] DTE was slow.  Playing 160 samples of 
> buffered audio.
> [2017-09-25 14:36:39.975046] DTE was slow.  Playing 160 samples of 
> buffered audio.
> [2017-09-25 14:36:42.093991] DTE was slow.  Playing 960 samples of 
> buffered audio.
> [2017-09-25 14:36:45.072521] DTE was slow.  Playing 16000 samples of 
> buffered audio.
>
> and so on, until the remote part hangs up. The fax does fail.
>
> I'm not sure what I've configured wrong. Any ideas?
>
> --
> Nabeel Jafferali
>
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>
>
> _______________________________________________
> iaxmodem-users mailing list
> iax...@li...
> https://lists.sourceforge.net/lists/listinfo/iaxmodem-users

[iaxmodem-users] "DTE was slow"

[Nabeel J. <na...@ja...>]

Hello.

I'm using Hylafax+ 5.5.9 with iaxmodem 1.3.0 and Asterisk 13.17.2. This is
a new setup which I am trying to get to work.

When sending faxes (sendfax -d 4165551212 /etc/networks), I see the
following on the iaxmodem console:

[2017-09-25 14:36:17.076467] Call accepted.
[2017-09-25 14:36:29.056984] Remote answered.
[2017-09-25 14:36:37.416261] IAX2 jitter - last_ts: 20319, ts: 20360
[2017-09-25 14:36:37.416396] Adjusting skew to -10.
[2017-09-25 14:36:38.735735] DTE was slow.  Playing 160 samples of buffered
audio.
[2017-09-25 14:36:39.975046] DTE was slow.  Playing 160 samples of buffered
audio.
[2017-09-25 14:36:42.093991] DTE was slow.  Playing 960 samples of buffered
audio.
[2017-09-25 14:36:45.072521] DTE was slow.  Playing 16000 samples of
buffered audio.

and so on, until the remote part hangs up. The fax does fail.

I'm not sure what I've configured wrong. Any ideas?

--
Nabeel Jafferali

Re: [iaxmodem-users] Adjusting skew

[Lee H. <fa...@ho...>]

On 07/28/2016 09:20 PM, Joseph Jackson wrote:
>
> Jul 29 04:11:58.89: [15934]: <-- [18:ATDTXXXXXXXXXXXXX\r]
>
> Jul 29 04:12:57.74: [15934]: --> [10:NO CARRIER]
>

So, at that point you're going to need to get an audio recording because 
iaxmodem is simply saying that it doesn't detect fax tones in the call 
audio.

Put "record" into your iaxmodem config file, restart iaxmodem, and then 
reproduce this "no carrier" result.  Then, take /tmp/<device>-iax.raw 
and convert it to a wav file following the instructions in the README ...

   sox -s -w -r 8000 -c 1 ttyIAX-iax.raw playable.wav

... or ...

   sox -e signed-integer -b 16 -r 8000 -c 1 ttyIAX-iax.raw playable.wav

Then listen to the wav file.  If you can't hear the problem audibly then 
you'll need to open the file in a WAV editor such as audacity and 
*inspect* the audio to see if there are gaps (jitter) or something.

Normally the problem will be obvious by listening, but not always.

Thanks,

Lee.

Re: [iaxmodem-users] Adjusting skew

[Joseph J. <jja...@an...>]

Evening Lee,


Here is the logging from hylafax for two calls. First is a failure that I then had hylafax retry automatically after 4 minutes.  The second attempt was successful.

No changes to routing or anything were made between these two attempts.

****FAILURE****

Jul 29 04:11:58.86: [15934]: SESSION BEGIN 000000099 XXXXXXXXXXXXX
Jul 29 04:11:58.86: [15934]: HylaFAX (tm) Version 5.5.8
Jul 29 04:11:58.86: [15934]: SEND FAX: JOB 67 DEST XXXXXXXXXXXXX COMMID 000000099 DEVICE '/dev/ttyIAX0' FROM 'root <root@localhost>' USER admin
Jul 29 04:11:58.86: [15934]: STATE CHANGE: RUNNING -> SENDING
Jul 29 04:11:58.86: [15934]: <-- [12:AT+FCLASS=1\r]
Jul 29 04:11:58.86: [15934]: --> [2:OK]
Jul 29 04:11:58.86: [15934]: MODEM set XON/XOFF/FLUSH: input ignored, output disabled
Jul 29 04:11:58.89: [15934]: DIAL XXXXXXXXXXXXX
Jul 29 04:11:58.89: [15934]: <-- [18:ATDTXXXXXXXXXXXXX\r]
Jul 29 04:12:57.74: [15934]: --> [10:NO CARRIER]
Jul 29 04:12:57.74: [15934]: SEND FAILED: JOB 67 DEST XXXXXXXXXXXXX ERR No carrier detected {E002}
Jul 29 04:12:58.74: [15934]: <-- [5:ATH0\r]
Jul 29 04:12:58.74: [15934]: --> [2:OK]
Jul 29 04:12:58.74: [15934]: MODEM set DTR OFF
Jul 29 04:12:58.74: [15934]: MODEM set baud rate: 0 baud (flow control unchanged)
Jul 29 04:12:58.74: [15934]: STATE CHANGE: SENDING -> MODEMWAIT (timeout 5)
Jul 29 04:12:58.74: [15934]: SESSION END

****SUCCESSFUL****
Jul 29 04:18:00.94: [16256]: SESSION BEGIN 000000100 XXXXXXXXXXXXX
Jul 29 04:18:00.94: [16256]: HylaFAX (tm) Version 5.5.8
Jul 29 04:18:00.94: [16256]: SEND FAX: JOB 67 DEST XXXXXXXXXXXXX COMMID 000000100 DEVICE '/dev/ttyIAX0' FROM 'root <root@localhost>' USER admin
Jul 29 04:18:00.94: [16256]: STATE CHANGE: RUNNING -> SENDING
Jul 29 04:18:00.94: [16256]: <-- [12:AT+FCLASS=1\r]
Jul 29 04:18:00.95: [16256]: --> [2:OK]
Jul 29 04:18:00.95: [16256]: MODEM set XON/XOFF/FLUSH: input ignored, output disabled
Jul 29 04:18:00.98: [16256]: DIAL XXXXXXXXXXXXX
Jul 29 04:18:00.98: [16256]: <-- [18:ATDTXXXXXXXXXXXXX\r]
Jul 29 04:18:12.51: [16256]: --> [7:CONNECT]
Jul 29 04:18:14.13: [16256]: --> HDLC<25:FF C0 02 8C 0C EC AC 8C 4C CC 0C 8C CC 04 04 04 04 04 04 04 04 04 04 E6 15>
Jul 29 04:18:14.13: [16256]: --> [2:OK]
Jul 29 04:18:14.13: [16256]: REMOTE CSI "3103215701"
Jul 29 04:18:14.13: [16256]: <-- [9:AT+FRH=3\r]
Jul 29 04:18:14.69: [16256]: --> [7:CONNECT]
Jul 29 04:18:14.69: [16256]: --> HDLC<19:FF C8 01 04 77 1F 23 01 F9 01 01 01 05 01 01 01 00 AE 10>
Jul 29 04:18:14.71: [16256]: --> [2:OK]
Jul 29 04:18:14.71: [16256]: REMOTE best rate 33600 bit/s
Jul 29 04:18:14.71: [16256]: REMOTE max A4 page width (215 mm)
Jul 29 04:18:14.71: [16256]: REMOTE max unlimited page length
Jul 29 04:18:14.71: [16256]: REMOTE best vres R16 x 15.4 line/mm
Jul 29 04:18:14.71: [16256]: REMOTE format support: MH, MR, MMR, JBIG
Jul 29 04:18:14.71: [16256]: REMOTE supports T.30 Annex A, 256-byte ECM
Jul 29 04:18:14.71: [16256]: REMOTE best 0 ms/scanline
Jul 29 04:18:14.71: [16256]: USE 14400 bit/s
Jul 29 04:18:14.71: [16256]: USE error correction mode
Jul 29 04:18:14.71: [16256]: SEND file "docq/doc83.ps;1c00"
Jul 29 04:18:14.71: [16256]: USE A4 page width (215 mm)
Jul 29 04:18:14.71: [16256]: USE unlimited page length
Jul 29 04:18:14.71: [16256]: USE 3.85 line/mm
Jul 29 04:18:14.71: [16256]: USE JBIG
Jul 29 04:18:14.71: [16256]: USE 0 ms/scanline
Jul 29 04:18:14.71: [16256]: SEND training at v.17 14400 bit/s
Jul 29 04:18:14.71: [16256]: <-- [9:AT+FRS=7\r]
Jul 29 04:18:14.83: [16256]: --> [2:OK]
Jul 29 04:18:14.83: [16256]: <-- [9:AT+FTH=3\r]
Jul 29 04:18:14.85: [16256]: --> [7:CONNECT]
Jul 29 04:18:14.85: [16256]: <-- HDLC<23:FF C0 C2 0E AE 2E A6 CA E6 76 96 16 2E F6 72 04 04 04 04 04 04 04 04>
Jul 29 04:18:14.85: [16256]: <-- data [23]
Jul 29 04:18:14.85: [16256]: <-- data [2]
Jul 29 04:18:16.39: [16256]: --> [7:CONNECT]
Jul 29 04:18:16.39: [16256]: <-- HDLC<13:FF C8 C1 00 44 1F 21 01 01 01 01 01 04>
Jul 29 04:18:16.39: [16256]: <-- data [13]
Jul 29 04:18:16.39: [16256]: <-- data [2]
Jul 29 04:18:16.95: [16256]: --> [2:OK]
Jul 29 04:18:16.95: [16256]: <-- [9:AT+FTS=7\r]
Jul 29 04:18:17.05: [16256]: --> [2:OK]
Jul 29 04:18:17.05: [16256]: MODEM set XON/XOFF/FLUSH: input interpreted, output disabled
Jul 29 04:18:17.05: [16256]: <-- [11:AT+FTM=145\r]
Jul 29 04:18:17.07: [16256]: --> [7:CONNECT]
Jul 29 04:18:17.07: [16256]: DELAY 400 ms
Jul 29 04:18:17.47: [16256]: <-- data [1024]
Jul 29 04:18:17.47: [16256]: <-- data [1024]
Jul 29 04:18:17.47: [16256]: <-- data [652]
Jul 29 04:18:17.47: [16256]: <-- data [2]
Jul 29 04:18:20.03: [16256]: --> [2:OK]
Jul 29 04:18:20.03: [16256]: MODEM set XON/XOFF/DRAIN: input ignored, output disabled
Jul 29 04:18:20.03: [16256]: <-- [9:AT+FRH=3\r]
Jul 29 04:18:20.85: [16256]: --> [7:CONNECT]
Jul 29 04:18:21.93: [16256]: --> HDLC<5:FF C8 21 57 BE>
Jul 29 04:18:21.95: [16256]: --> [2:OK]
Jul 29 04:18:21.95: [16256]: TRAINING succeeded
Jul 29 04:18:21.95: [16256]: SEND begin page
Jul 29 04:18:21.95: [16256]: Reading MH-compressed image file
Jul 29 04:18:21.98: [16256]: SEND send frame number 0
Jul 29 04:18:21.98: [16256]: SEND send frame number 1
Jul 29 04:18:21.98: [16256]: SEND send frame number 2
Jul 29 04:18:21.98: [16256]: SEND send frame number 3
Jul 29 04:18:21.98: [16256]: SEND send frame number 4
Jul 29 04:18:21.98: [16256]: MODEM set XON/XOFF/FLUSH: input interpreted, output disabled
Jul 29 04:18:21.98: [16256]: <-- [9:AT+FRS=7\r]
Jul 29 04:18:22.07: [16256]: --> [2:OK]
Jul 29 04:18:22.07: [16256]: <-- [11:AT+FTM=146\r]
Jul 29 04:18:22.09: [16256]: --> [7:CONNECT]
Jul 29 04:18:22.09: [16256]: DELAY 400 ms
Jul 29 04:18:22.49: [16256]: <-- data [1027]
Jul 29 04:18:22.49: [16256]: <-- data [695]
Jul 29 04:18:22.49: [16256]: <-- data [2]
Jul 29 04:18:23.53: [16256]: --> [2:OK]
Jul 29 04:18:23.53: [16256]: MODEM set XON/XOFF/DRAIN: input ignored, output disabled
Jul 29 04:18:23.53: [16256]: <-- [9:AT+FTS=9\r]
Jul 29 04:18:23.65: [16256]: --> [2:OK]
Jul 29 04:18:23.65: [16256]: <-- [9:AT+FTH=3\r]
Jul 29 04:18:23.67: [16256]: --> [7:CONNECT]
Jul 29 04:18:23.67: [16256]: <-- HDLC<7:FF C8 FD F4 00 00 20>
Jul 29 04:18:23.67: [16256]: <-- data [7]
Jul 29 04:18:23.67: [16256]: <-- data [2]
Jul 29 04:18:24.85: [16256]: --> [2:OK]
Jul 29 04:18:24.85: [16256]: SEND send PPS (partial page signal)
Jul 29 04:18:24.85: [16256]: SEND send EOP (no more pages or documents)
Jul 29 04:18:24.85: [16256]: <-- [9:AT+FRH=3\r]
Jul 29 04:18:25.97: [16256]: --> [7:CONNECT]
Jul 29 04:18:27.05: [16256]: --> HDLC<5:FF C8 31 45 8F>
Jul 29 04:18:27.07: [16256]: --> [2:OK]
Jul 29 04:18:27.07: [16256]: SEND recv MCF (message confirmation)
Jul 29 04:18:27.07: [16256]: <-- [9:AT+FRS=7\r]
Jul 29 04:18:27.19: [16256]: --> [2:OK]
Jul 29 04:18:27.19: [16256]: SEND end page
Jul 29 04:18:27.19: [16256]: SEND FAX (000000100): FROM root@localhost TO XXXXXXXXXXXXX (docq/doc83.ps;1c00 sent in 0:00:13)
Jul 29 04:18:27.19: [16256]: SEND FAX (000000100): FROM root@localhost TO XXXXXXXXXXXXX (page 1 of 1 sent in 0:00:13)
Jul 29 04:18:28.19: [16256]: <-- [9:AT+FTH=3\r]
Jul 29 04:18:28.21: [16256]: --> [7:CONNECT]
Jul 29 04:18:28.21: [16256]: <-- HDLC<3:FF C8 DF>
Jul 29 04:18:28.21: [16256]: <-- data [3]
Jul 29 04:18:28.21: [16256]: <-- data [2]
Jul 29 04:18:29.29: [16256]: --> [2:OK]
Jul 29 04:18:29.29: [16256]: MODEM input buffering enabled
Jul 29 04:18:30.29: [16256]: <-- [5:ATH0\r]
Jul 29 04:18:30.31: [16256]: --> [2:OK]
Jul 29 04:18:30.31: [16256]: MODEM set DTR OFF
Jul 29 04:18:30.31: [16256]: MODEM set baud rate: 0 baud (flow control unchanged)
Jul 29 04:18:30.31: [16256]: STATE CHANGE: SENDING -> MODEMWAIT (timeout 5)
Jul 29 04:18:30.31: [16256]: SESSION END


From: Lee Howard [mailto:fa...@ho...]
Sent: Thursday, July 28, 2016 6:52 PM
To: Joseph Jackson
Cc: iax...@li...
Subject: Re: [iaxmodem-users] Adjusting skew

On 07/28/2016 02:27 PM, Joseph Jackson wrote:
I did a pcap of the call and I'm able to hear both legs trying to negotiate the fax setup.

Then it would seem that the audio is getting through.

Assuming that you're using HylaFAX, what does the HylaFAX session log (/var/spool/hylafax/log/...) show?

Thanks,

Lee.