[Freeswitch-dev] mod_fax
Hi all, I finally started to play with mod_fax today. First, a couple of little observations. Although there is a config file for fax, modules.conf.xml doesn't contain an entry for mod_fax, and dialplan/default.xml doesn't contain a demo like <extension name="test_rxfax_stream"> <condition field="destination_number" expression="^9011$"> <action application="answer" /> <action application="playback" data="silence_stream://2000"/> <action application="rxfax" data="rxfax.tif"/> <action application="hangup"/> </condition> </extension> <extension name="test_txfax_stream"> <condition field="destination_number" expression="^9012$"> <action application="txfax" data="txfax.tif"/> <action application="hangup"/> </condition> </extension> as it does for other modules. For more serious things..... If the far end of a SIP FAX transaction sends a reinvite to switch to T.38, FS sends a 488 back and everything fouls up. Other boxes send back the previous codec as the new one to use, and everything carries on smoothly in audio mode. I'm not a SIP expert, so I don't know the details of what it says on the topic, but in the real world successful continuance of a call requires a response other than 488. As an aside, the called party should be the one to initiate an attempt to use T.38, but in the real world the calling party often does. If T.38 is not available (which it isn't ever right now), and the call starts with a low bit rate codec, we should initiate a reinvite to use Alaw or ulaw. If that fails we might as well abandon the call. mod_fax currently follows the practice of my old and crude demo programs for *, and has apps called rxfax and txfax. This is taking a very narrow view of a FAX machine, and I think is too limiting. I think the following is how things should be: - One app, probably just called FAX. - It will be started with a flag saying if it should act as the calling party or the called party. - The app will be given optional lists of files to send, and files to receive. - The app will do its best to exchange all the files it can, including the use of poll mode FAXing. The module documentation says page by page events should be added (which spandsp supports), and this seems a sound idea. FAXback and other services might be implemented through this. Regards, Steve
Hello, Some notes based on my past experience with fax-relay. Sorry for the long-ish post.
As an aside, the called party should be the one to initiate an attempt to use T.38, but in the real world the calling party often does.
Depending on whether CNG shows up first or CED shows up first, the switch to fax-relay might happen one way or another. Fax server entities also tend to bypass some steps and start in fax mode (some even forget to negotiate a voice codec).
If T.38 is not available (which it isn't ever right now), and the call starts with a low bit rate codec, we should initiate a reinvite to use Alaw or ulaw. If that fails we might as well abandon the call.
BTW the full specs are available for free: http://www.itu.int/rec/T-REC-T.38/en http://www.itu.int/rec/T-REC-T.30/en T.38 Annex D has an example for a fax-only call, but generally speaking, in the PSTN there's no such thing as "a fax call" (or a "modem call"). A call always starts as a voice call, and might switch to fax mode (and back). The basic issue Steve mentioned is that if you negotiate (at the start of the VoIP call) a codec that is supposed to use, say, 28kb/s (G.729), then to respect QoS over the entire call you should only accept fax calls that will fit within that amount of bandwidth (accounting for IP/UDPTL overhead, that might be up to 14,400b/s for example -- don't quote me on the numbers). In the early days, one would renegotiate the codec to G.711 ("upspeed") when a fax tone was detected (assuming all fax calls use 64kb/s); if QoS denied the bandwidth upspeed (either because of per-call bandwidth restriction configured on the gateway, Call Admission Control, RSVP, ..), then the call would be dropped. However, I don't think the upspeed to G.711 is strictly required, and in a fax-relay scenario, the hop-on and hop-off gateways could also decide to only offer the appropriate fax rates to the fax machines (overriding the speeds offered by the actual fax machines in the T.30 stream; see spec T.30 page 53). So if the call started as a G.729 call, the gateway(s) could "clear the bits" in T.30 for anything above the matching bandwidth. Where it gets tricky is that some T.38 options (for example UDPTL redundancy) might mean that the actual bandwidth available to T.30 is much lower than the bandwidth available to the voice codec; if you start with G.729 and then switch to T.38 with one-time redundancy, the "assumed bandwidth" falls to 28kb/s/2=14kb/s, so you might only be able to drive 9,600b/s fax out of that. Another issue is that some fax models use proprietary mechanism to switch to higher speeds. So a fax machine from brand A might do 14,400b/s with a fax machine from brand A, regardless of what the T.30 negotiated speed was. (I never looked into the gory details, so take this as hearsay.) However in that last case there's little you can do anyhow -- you will most probably end up oversubscribing the bandwidth assumed for the call in any case. Finally, in some environments, it might be OK to go over the bandwidth assumed for a voice call in order to get a fax call through (call completion is more important, and the network is over-engineered to account for this). Also, fax is only half-duplex, so in large installations, things tend to level out statistically speaking (most traffic in fax-relay is from the sender to the receiver; however the caller might not be the sender). Finally, fax bandwidth usage can go over voice codec bandwidth usage in regular scenarios -- there's nothing restricting fax-relay UDPTL traffic to 64kb/s. HTH, Stéphane
Stéphane Alnet wrote:
Hello,
Some notes based on my past experience with fax-relay. Sorry for the long-ish post.
As an aside, the called party should be the one to initiate an attempt to use T.38, but in the real world the calling party often does.
Depending on whether CNG shows up first or CED shows up first, the switch to fax-relay might happen one way or another. Fax server entities also tend to bypass some steps and start in fax mode (some even forget to negotiate a voice codec).
T.38 specifically says the called end is the one which should initiate T.38 negotiation. The presence of absence of CED and CNG has nothing to do with it. If the calling end tries to initiate T.38 its a protocol error, though a common one. As with most SIP implementation, the industry standard is "as broken as our bunch of monkeys could make it".
If T.38 is not available (which it isn't ever right now), and the call starts with a low bit rate codec, we should initiate a reinvite to use Alaw or ulaw. If that fails we might as well abandon the call.
BTW the full specs are available for free: http://www.itu.int/rec/T-REC-T.38/en http://www.itu.int/rec/T-REC-T.30/en
T.38 Annex D has an example for a fax-only call, but generally speaking, in the PSTN there's no such thing as "a fax call" (or a "modem call"). A call always starts as a voice call, and might switch to fax mode (and back).
The basic issue Steve mentioned is that if you negotiate (at the start of the VoIP call) a codec that is supposed to use, say, 28kb/s (G.729), then to respect QoS over the entire call you should only accept fax calls that will fit within that amount of bandwidth (accounting for IP/UDPTL overhead, that might be up to 14,400b/s for example -- don't quote me on the numbers).
In the early days, one would renegotiate the codec to G.711 ("upspeed") when a fax tone was detected (assuming all fax calls use 64kb/s); if QoS denied the bandwidth upspeed (either because of per-call bandwidth restriction configured on the gateway, Call Admission Control, RSVP, ..), then the call would be dropped. However, I don't think the upspeed to G.711 is strictly required, and in a fax-relay scenario, the hop-on and hop-off gateways could also decide to only offer the appropriate fax rates to the fax machines (overriding the speeds offered by the actual fax machines in the T.30 stream; see spec T.30 page 53). So if the call started as a G.729 call, the gateway(s) could "clear the bits" in T.30 for anything above the matching bandwidth.
Where it gets tricky is that some T.38 options (for example UDPTL redundancy) might mean that the actual bandwidth available to T.30 is much lower than the bandwidth available to the voice codec; if you start with G.729 and then switch to T.38 with one-time redundancy, the "assumed bandwidth" falls to 28kb/s/2=14kb/s, so you might only be able to drive 9,600b/s fax out of that. Another issue is that some fax models use proprietary mechanism to switch to higher speeds. So a fax machine from brand A might do 14,400b/s with a fax machine from brand A, regardless of what the T.30 negotiated speed was. (I never looked into the gory details, so take this as hearsay.) However in that last case there's little you can do anyhow -- you will most probably end up oversubscribing the bandwidth assumed for the call in any case.
Finally, in some environments, it might be OK to go over the bandwidth assumed for a voice call in order to get a fax call through (call completion is more important, and the network is over-engineered to account for this). Also, fax is only half-duplex, so in large installations, things tend to level out statistically speaking (most traffic in fax-relay is from the sender to the receiver; however the caller might not be the sender). Finally, fax bandwidth usage can go over voice codec bandwidth usage in regular scenarios -- there's nothing restricting fax-relay UDPTL traffic to 64kb/s.
QoS is a largely unrelated issue, in that SIP servers don't cooperate with QoS managers. The SIP server needs to do its best to get the calls through, and hasn't the slightest clue what the channel's capacity might be. Whilst switching to a higher bit rate might overwhelm the channel, the SIP server has no way of telling in advance. To stick with a low bit rate codec is completely useless. Renegotiating to a usable codec is the less worst thing we can do. Regards, Steve
mod_fax is an unfunded work in progress so calling it crude means I guess we are not off to a very good start. Your input is nonetheless appreciated as the small group of 3 or 4 coders continue to try and find time to add t.30 and t.38 support to FreeSWITCH in our spare time with little or no help. So eventually your concerns will probably be addressed but Rome was not built in a day........ You do seem to have a talent for writing. May I suggest your volunteer your skills on our WIKI? http://wiki.freeswitch.org/ On Sun, Jan 4, 2009 at 9:21 AM, Steve Underwood <steveu@coppice.org> wrote:
Hi all,
I finally started to play with mod_fax today. First, a couple of little observations. Although there is a config file for fax, modules.conf.xml doesn't contain an entry for mod_fax, and dialplan/default.xml doesn't contain a demo like
<extension name="test_rxfax_stream"> <condition field="destination_number" expression="^9011$"> <action application="answer" /> <action application="playback" data="silence_stream://2000"/> <action application="rxfax" data="rxfax.tif"/> <action application="hangup"/> </condition> </extension>
<extension name="test_txfax_stream"> <condition field="destination_number" expression="^9012$"> <action application="txfax" data="txfax.tif"/> <action application="hangup"/> </condition> </extension>
as it does for other modules.
For more serious things.....
If the far end of a SIP FAX transaction sends a reinvite to switch to T.38, FS sends a 488 back and everything fouls up. Other boxes send back the previous codec as the new one to use, and everything carries on smoothly in audio mode. I'm not a SIP expert, so I don't know the details of what it says on the topic, but in the real world successful continuance of a call requires a response other than 488. As an aside, the called party should be the one to initiate an attempt to use T.38, but in the real world the calling party often does.
If T.38 is not available (which it isn't ever right now), and the call starts with a low bit rate codec, we should initiate a reinvite to use Alaw or ulaw. If that fails we might as well abandon the call.
mod_fax currently follows the practice of my old and crude demo programs for *, and has apps called rxfax and txfax. This is taking a very narrow view of a FAX machine, and I think is too limiting. I think the following is how things should be:
- One app, probably just called FAX. - It will be started with a flag saying if it should act as the calling party or the called party. - The app will be given optional lists of files to send, and files to receive. - The app will do its best to exchange all the files it can, including the use of poll mode FAXing.
The module documentation says page by page events should be added (which spandsp supports), and this seems a sound idea. FAXback and other services might be implemented through this.
Regards, Steve
_______________________________________________ Freeswitch-dev mailing list Freeswitch-dev@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev http://www.freeswitch.org
-- Anthony Minessale II FreeSWITCH http://www.freeswitch.org/ ClueCon http://www.cluecon.com/ AIM: anthm MSN:anthony_minessale@hotmail.com <MSN%3Aanthony_minessale@hotmail.com> GTALK/JABBER/PAYPAL:anthony.minessale@gmail.com<PAYPAL%3Aanthony.minessale@gmail.com> IRC: irc.freenode.net #freeswitch FreeSWITCH Developer Conference sip:888@conference.freeswitch.org <sip%3A888@conference.freeswitch.org> iax:guest@conference.freeswitch.org/888 googletalk:conf+888@conference.freeswitch.org<googletalk%3Aconf%2B888@conference.freeswitch.org> pstn:213-799-1400
I think i'm a bit overworked. Steve is one of the small group of people I was mentioning above so I am not sure why I am reminding him of the obvious. We thank him profusely for his involvement. On Mon, Jan 5, 2009 at 8:17 AM, Anthony Minessale < anthony.minessale@gmail.com> wrote:
mod_fax is an unfunded work in progress so calling it crude means I guess we are not off to a very good start. Your input is nonetheless appreciated as the small group of 3 or 4 coders continue to try and find time to add t.30 and t.38 support to FreeSWITCH in our spare time with little or no help. So eventually your concerns will probably be addressed but Rome was not built in a day........
You do seem to have a talent for writing. May I suggest your volunteer your skills on our WIKI? http://wiki.freeswitch.org/
On Sun, Jan 4, 2009 at 9:21 AM, Steve Underwood <steveu@coppice.org>wrote:
Hi all,
I finally started to play with mod_fax today. First, a couple of little observations. Although there is a config file for fax, modules.conf.xml doesn't contain an entry for mod_fax, and dialplan/default.xml doesn't contain a demo like
<extension name="test_rxfax_stream"> <condition field="destination_number" expression="^9011$"> <action application="answer" /> <action application="playback" data="silence_stream://2000"/> <action application="rxfax" data="rxfax.tif"/> <action application="hangup"/> </condition> </extension>
<extension name="test_txfax_stream"> <condition field="destination_number" expression="^9012$"> <action application="txfax" data="txfax.tif"/> <action application="hangup"/> </condition> </extension>
as it does for other modules.
For more serious things.....
If the far end of a SIP FAX transaction sends a reinvite to switch to T.38, FS sends a 488 back and everything fouls up. Other boxes send back the previous codec as the new one to use, and everything carries on smoothly in audio mode. I'm not a SIP expert, so I don't know the details of what it says on the topic, but in the real world successful continuance of a call requires a response other than 488. As an aside, the called party should be the one to initiate an attempt to use T.38, but in the real world the calling party often does.
If T.38 is not available (which it isn't ever right now), and the call starts with a low bit rate codec, we should initiate a reinvite to use Alaw or ulaw. If that fails we might as well abandon the call.
mod_fax currently follows the practice of my old and crude demo programs for *, and has apps called rxfax and txfax. This is taking a very narrow view of a FAX machine, and I think is too limiting. I think the following is how things should be:
- One app, probably just called FAX. - It will be started with a flag saying if it should act as the calling party or the called party. - The app will be given optional lists of files to send, and files to receive. - The app will do its best to exchange all the files it can, including the use of poll mode FAXing.
The module documentation says page by page events should be added (which spandsp supports), and this seems a sound idea. FAXback and other services might be implemented through this.
Regards, Steve
_______________________________________________ Freeswitch-dev mailing list Freeswitch-dev@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev http://www.freeswitch.org
-- Anthony Minessale II
FreeSWITCH http://www.freeswitch.org/ ClueCon http://www.cluecon.com/
AIM: anthm MSN:anthony_minessale@hotmail.com <MSN%3Aanthony_minessale@hotmail.com> GTALK/JABBER/PAYPAL:anthony.minessale@gmail.com<PAYPAL%3Aanthony.minessale@gmail.com> IRC: irc.freenode.net #freeswitch
FreeSWITCH Developer Conference sip:888@conference.freeswitch.org <sip%3A888@conference.freeswitch.org> iax:guest@conference.freeswitch.org/888 googletalk:conf+888@conference.freeswitch.org<googletalk%3Aconf%2B888@conference.freeswitch.org> pstn:213-799-1400
-- Anthony Minessale II FreeSWITCH http://www.freeswitch.org/ ClueCon http://www.cluecon.com/ AIM: anthm MSN:anthony_minessale@hotmail.com <MSN%3Aanthony_minessale@hotmail.com> GTALK/JABBER/PAYPAL:anthony.minessale@gmail.com<PAYPAL%3Aanthony.minessale@gmail.com> IRC: irc.freenode.net #freeswitch FreeSWITCH Developer Conference sip:888@conference.freeswitch.org <sip%3A888@conference.freeswitch.org> iax:guest@conference.freeswitch.org/888 googletalk:conf+888@conference.freeswitch.org<googletalk%3Aconf%2B888@conference.freeswitch.org> pstn:213-799-1400
Tony, Steve, & team,
mod_fax is an unfunded work in progress so calling it crude means I guess we are not off to a very good start.
One idea and one question: - It seems that doing fax detection over RTP/RFC2833 would be fairly easy if the RFC2833_CHARS in switch_utils.c was extended to support values like 36 (CNG) and the range 32-35 (ANS* messages). Or more simply if the original RFC2833 event value could be accessed directly. For example (in Javascript) if one could write: function onInput( session, type, data, arg ) { if ( type == "dtmf" ) { /* uses the plain RTP NTE event */ if ( data.nte_event == 36 ) { /* <-- e.g. "nte_event" instead of "digit" */ console_log( "info", "CNG received\n" ); /* Caller is a sending fax macine, start rx_fax, etc. */ } } ... /* Play voicemail prompt and attempt fax or DTMF detection */ session.streamFile( "somefile.wav", onInput ); /* No DTMF or fax detected, start recording the voicemail message. */ - Is there anything to be learned from T.38 and fax in CallWeaver? app_rxfax, app_txfax, app_t38gateway... have Steve's and Tony's names on them. Is the design there just plain wrong? Is it a licensing issue? On the other hand in FS's mod_fax.c I still read "the pieces are already in place" for T.38, even though obviously the whole story isn't ready. Can someone elaborate on what's already there, what's missing (UDPTL? triggering the codec changeover?), and maybe we can attack this piece by piece? (While using the ideas Steve put forward in his first email about merging rxfax and txfax.) S.
Tony, Steve, & team,
mod_fax is an unfunded work in progress so calling it crude means I guess we are not off to a very good start.
One idea and one question:
- It seems that doing fax detection over RTP/RFC2833 would be fairly easy if the RFC2833_CHARS in switch_utils.c was extended to support values like 36 (CNG) and the range 32-35 (ANS* messages). Or more simply if the original RFC2833 event value could be accessed directly. For example (in Javascript) if one could write:
function onInput( session, type, data, arg ) { if ( type == "dtmf" ) { /* uses the plain RTP NTE event */ if ( data.nte_event == 36 ) { /* <-- e.g. "nte_event" instead of "digit" */ console_log( "info", "CNG received\n" ); /* Caller is a sending fax macine, start rx_fax, etc. */ } }
...
/* Play voicemail prompt and attempt fax or DTMF detection */ session.streamFile( "somefile.wav", onInput ); /* No DTMF or fax detected, start recording the voicemail message. */
In RFC2833, support for relaying modem connect tones (CNG, [/]ANS[am] and co) is optional, and relatively few implementations support them. It also has to be supported on both sides for it to work. Carrying these tones over compressing codecs distorts them, often beyond recognition - that's why in T.38 it is the answering end, which has a clear channel to the answering fax machine, that initiates the T.38 switchover. Also CNG and ANS are not generated or generated incorrectly by many fax machines, you need to look for V.21H HDLC flags, or even T.30 data in the HDLC frames, to know for sure that it's a fax. Damjan
In RFC2833, support for relaying modem connect tones (CNG, [/]ANS[am] and co) is optional, and relatively few implementations support them. [...] Also CNG and ANS are not generated or generated incorrectly by many fax machines, you need to look for V.21H HDLC flags, or even T.30 data in the HDLC frames, to know for sure that it's a fax.
Alright, I guess that from an application perspective, developers generally are not really trying to do fax detection. They are only trying to differentiate between a "human" and a fax machine (or modem). So I guess "fax detection" in that relaxed sense can be summarized as: - on an attached audio channel (AUDIO_MODE), did we detect CNG, ANS*, or anything that would make the software switch to fax-relay mode -- I would assume there's some kind of event that spandsp generates in that case(?); - on a SIP/H.323 channel supporting T.38, did a switch-over to T.38 occur. - (any other channel mode?) (Not that I want to drag the discussion any further if nobody cares about it.) S.
participants (4)
-
Anthony Minessale
-
damjan＠ecntelecoms.com
-
Steve Underwood
-
Stéphane Alnet