[Home]

Summary:ASTERISK-12667: [patch] T38 gateway
Reporter:Daniel Ferenci (dafe_von_cetin)Labels:
Date Opened:2008-08-30 16:44:03Date Closed:2011-08-05 16:15:59
Priority:MajorRegression?No
Status:Closed/CompleteComponents:Applications/app_fax
Versions:Frequency of
Occurrence
Related
Issues:
is related toASTERISK-18219 t38 gateway doesn't work with ooh323
Environment:Attachments:( 0) asterisk-1.6.2.13.patch
( 1) asterisk-1.6.2.6-t38gw-dial-patch.txt
( 2) asterisk-1.6.2.9-t38gw-dial.patch
( 3) faxgateway-1.8.patch
( 4) faxgateway-1.8-v2.patch
( 5) faxgwt38ast10.zip
( 6) faxlog.txt
( 7) framehook-pre-1.8.5.patch
( 8) t38fail.pcap
( 9) t38fail2.pcap
Description:Hi all,

I'm sending you patch containing new application app_faxgateway.c
("FaxGateway") which is able to mediate T30 to T38 and vice versa.
Feature is using spands library (I used spandsp-0.0.4pre18 and spandsp-0.0.5pre4).

Best regards
Daniel.


****** ADDITIONAL INFORMATION ******

This entry is continuation of http://bugs.digium.com/view.php?id=12931 that has been closed because of the new feature = trunk submit rule.

The app_faxgateway exists for version 1.4.20.1 and 1.6.0-beta9 as well.

<offsite-patch-links-removed>


~~~~~~~~~~~~~~~~~

Note, the patches in this issue will not be merged into the Asterisk code base unless they are changed/rewritten to use the API created for T.38 Gateway support.

More information about the approach and the API are available on the mailing lists:

http://lists.digium.com/pipermail/asterisk-dev/2010-April/043789.html
http://lists.digium.com/pipermail/asterisk-dev/2010-September/046344.html
Comments:By: Sean Bright (seanbright) 2008-09-02 14:41:16

Just a cursory glance at the code, it doesn't follow the coding guidelines required for inclusion in the asterisk source tree.  Please see doc/CODING-GUIDELINES for more detail.

I initially marked the "Code Review" as failing, but that was the incorrect category.  My intention was to mark the Formatting Review.
By: Daniel Ferenci (dafe_von_cetin) 2008-09-07 15:58:44

Hi,

I've just uploaded the recent version of app_faxgateway patch that should follow
asterisk coding guidelines.  

Please let me know if there is something wrong or you need some cooperation.

Best regards
Daniel.
By: Daniel Ferenci (dafe_von_cetin) 2008-09-24 08:26:53

Hi,

what is current status?

Daniel.
By: vadim (vadim) 2008-09-27 08:38:40

The application description seems to be wrong: it mentions a TIFF file

It seems that lock here (in faxgw_exec) are superfluous...

        .....
ast_channel_lock(chan);
session.caller_mode = FALSE;
ast_channel_unlock(chan);
By: Leif Madsen (lmadsen) 2008-09-28 13:13:46

Many of us are at AstriCon and AstriDevCon this week, so it's likely there won't be anyone to move this forward until sometime next week, or perhaps the week after depending on how long it takes us all to catch up on work.
By: jun (jun_xie) 2008-10-08 04:06:30

i installed faxgateway on Fc9 with Asterisk-1.20.1,installation is fine.
but when i try to use the faxgateway application to do more test,failed.
after the FaxGateway applied,error appeared as following

####error start ###

[Oct  8 17:08:56] ERROR[6170]: chan_sip.c:12548 handle_response_invite: Got error on T.38 initial invite. Bailing out.
[Oct  8 17:08:56] ERROR[6178]: app_faxgateway.c:774 transmit: failed to get remote_channel SIP 8311861180191007@sh-5300
[Oct  8 17:08:56] NOTICE[6178]: app_faxgateway.c:787 transmit: FaxGateway exit with CONGESTION
[Oct  8 17:08:56] WARNING[6178]: app_faxgateway.c:792 transmit: Transmission error
  == Spawn extension (out, 8311861180191007, 2) exited non-zero on 'SIP/862100001-085c3908'
[Oct  8 17:11:43] NOTICE[6170]: chan_sip.c:15246 handle_request_subscribe: Received SIP subscribe for peer without mailbox: 862100001
[Oct  8 17:14:44] NOTICE[6170]: chan_sip.c:15246 handle_request_subscribe: Received SIP subscribe for peer without mailbox: 862100001
#######over#####

can anybody can give any suggestion ?Thanks
By: Gregory Hinton Nietsky (irroot) 2008-10-15 10:17:58

in exchange for a few noddy points i offer a patch against app_fax astrified ...

i will be submitting its partner app_faxdetect for generic CED/CNG detection and
t38 state negotion....
By: Leif Madsen (lmadsen) 2008-10-15 10:30:21

I'm sorry... can you be more clear as to what you're attaching here? Is this really related to this bug, or should that patch be submitted as a separate bug?
By: Gregory Hinton Nietsky (irroot) 2008-10-15 10:34:28

the patch is a rework of the existing code into a more asterisk friendly format.

and instead of been a standalone app it is merged into app_fax.c as much code was shared and imho it bellongs in that file.

esentialy a functional T.38/T.30 gateway based on the original posting in a potentialy more asterisk way.
By: Leif Madsen (lmadsen) 2008-10-15 11:14:52

Ah gotcha, thanks for clearing that up! Much obliged!
By: Gregory Hinton Nietsky (irroot) 2008-10-15 11:22:32

absolute pleasure there is still some superfluous code in there some i have just cleaned up ;)

it is functional and working ...

perhaps the category should be changed to Applications/app_fax ...

to be honest it is working on a production 1.4.22 version [T.38/app_fax backported]


By: Gregory Hinton Nietsky (irroot) 2008-10-16 17:46:47

well its 1am and im sending faxes to myself ... any testers out there with a T.38 device on internet id be keen to set up a ENUM entry for your fax and send you a few pages ... email me details

im curently using sendfax to originate a call out a BRI back in on the fax machines DDI via a SPA-3102 ... results are not spectaculiar im wanting to see if the chan_misdn in and out with send fax is partialy to blame on top of using V.17 so far faxes are flowing and no problems with * to report ie load/segfault/....

ive found some fax gateways [Fax 2 Mail] do not work at all this is something perhaps steve will be intrested in looking at.there are some terminals im getting near 100% success toyota south africa is one of them to a right fax server no details of modem used but it goes V.17 12000/14000.

ill be putting in a SPA-8000 tommorow [this is what we use as stock equipment for integration to POTS PBX] ...

thank you all for your help and intrest in this project ...
By: Martin Vit (festr) 2008-10-17 02:17:38

So, is there any doc describing how to test this patch? Not meaning how to patch but how to use, what and where to configure. I'd like to test it and make reports.

And also, you mentioned 1.4.22, is it possible to share it? festr@lam.cz
By: Leif Madsen (lmadsen) 2008-10-21 14:10:28

Can I remove the oldest file from this bug and just leave the newest one?
By: Gregory Hinton Nietsky (irroot) 2008-10-21 14:12:18

as the last one is a rework of the first one it is related id prefer it stays till there has been a review.

there are slight functional diferences that may be relevant ...

my 2c no change required
By: Leif Madsen (lmadsen) 2008-10-22 10:03:37

Works for me. The patches shall remain!
By: Martin Vit (festr) 2008-10-23 11:38:05

have anyone tryed to compile this patches against 1.6? The last patch app_fax-t38gw.patch uses LOAD_OH but it was removed years ago (http://lists.digium.com/pipermail/svn-commits/2006-December/019826.html) it seems it is mix of 1.6,1.4 code here.

also ast_mutex_lock(&s->peer->lock) is wrong, peer does not have structure lock.

irroot: can you share patches for 1.4.22 ? :)
By: Roman Yeryomin (leroi05) 2008-10-23 16:06:29

indeed! it doesn't compile on 1.6:

app_fax.c: In function ‘ast_t38_gateway’:
app_fax.c:763: error: request for member ‘ptr’ in something not a structure or union
app_fax.c:770: error: request for member ‘ptr’ in something not a structure or union
app_fax.c: In function ‘app_t38gateway_exec’:
app_fax.c:923: warning: implicit declaration of function ‘LOAD_OH’
app_fax.c:958: error: ‘struct ast_channel’ has no member named ‘lock’
app_fax.c:990: error: ‘struct ast_channel’ has no member named ‘lock’
app_fax.c:872: warning: unused variable ‘vars’
app_fax.c:871: warning: unused variable ‘account’
make[1]: *** [app_fax.o] Error 1
make: *** [apps] Error 2
By: Gregory Hinton Nietsky (irroot) 2008-10-24 02:04:16

ah ill look into that thx for your feed back ...
By: frawd (frawd) 2008-10-24 03:17:41

That's a great feature thanks!

Does it work with the latest spandsp 0.0.6pre2?

I'm also interested in testing your 1.4.22 patches if possible.
delawarde@gmail.com


By: Gregory Hinton Nietsky (irroot) 2008-10-24 07:48:28

i have the latest work in progress working with pre2 ill load new patch next week

i see the LOAD_OH snuck in sorry for that sort it out ;)


By: Sebastian (sroberts) 2008-10-24 13:51:54

I have managed to get this working quite nicely using Asterisk 1.6.0.1 and spandsp 0.0.5pre4. I had the same problem as leroi05, which I fixed, by modifying the patched code slightly.

Asterisk also crashes on startup unless I add a noload => app_faxgateway.so in modules.conf??

But once all that is done it seems to work quite happily. I've got PRI coming into my Asterisk box receives the incoming fax, this is then passed on via SIP to another box running Rightfax.

Note that the patch I uploaded is not complete as I haven't had time to test this thoroughly yet, but if anyone else is trying to get this working with 1.6.0.1, this should at least get you going in the right direction.
By: Roman Yeryomin (leroi05) 2008-10-25 05:06:01

Couldn't compile app_faxgateway also

  [CC] app_faxgateway.c -> app_faxgateway.o
app_faxgateway.c: In function ‘ast_bridge_frames’:
app_faxgateway.c:219: warning: implicit declaration of function ‘ast_dsp_set_digitmode’
app_faxgateway.c: In function ‘ast_t38_gateway’:
app_faxgateway.c:424: error: request for member ‘ptr’ in something not a structure or union
app_faxgateway.c:430: error: request for member ‘ptr’ in something not a structure or union
app_faxgateway.c:447: error: request for member ‘ptr’ in something not a structure or union
app_faxgateway.c: In function ‘faxgw_exec’:
app_faxgateway.c:796: error: request for member ‘tv_sec’ in something not a structure or union
app_faxgateway.c:797: error: request for member ‘tv_usec’ in something not a structure or union
app_faxgateway.c:820: warning: passing argument 3 of ‘__ast_string_field_ptr_grow’ from incompatible pointer type
make[1]: *** [app_faxgateway.o] Error 1
make: *** [apps] Error 2
By: Sergey Tamkovich (sergee) 2008-10-25 08:38:12

leroi05, i hope youare using spandsp-0.0.4pre18?
By: Roman Yeryomin (leroi05) 2008-10-25 16:49:55

no, I use spandsp-0.0.5pre4, it's listed as working!
By: Sebastian (sroberts) 2008-10-26 06:21:31

leroi05: Just edit app_fax.c and change f->data.ptr to f->data for those 3 instances.

Also, for tc->whentohangup.tv_sec = 0; and tc->whentohangup.tv_usec = 0; whentohangup is a time_t structure, so you can set whentohangup to 0 (ie tc->whentohangup = 0;). This worked for me anyway.

These errors don't have anything to with spandsp either as tc is an ast_channel and f is an ast_frame. Both those errors are caused by references to members that are clearly no longer part of those structs.
By: Gregory Hinton Nietsky (irroot) 2008-10-26 06:51:44

hi ya new patch will be out soon ill be in richards bay for 2 days [see if there is any one who can find it on a map.ill be doing a asterisk installation if there is a map in Digium HQ put a pin there im ammased there are E1 provisioned] so working furiously at it at the moment.

please note this patch like all new features is for TRUNK the f->data is indeed f->data.ptr in trunk.

the LOAD_OH hunk / channel locking sliped in unnoticed from 1.4 humblist appologies.

one of the changes ive added and am testing is a ast_generator on the T.30 channel to handle the frame creation.

also taken a few liberties on the actual gateway loop...

also am checking AST_LIST_NEXT im not sure if it is needed or even correct ...

-----------
               ast_activate_generator(t30chan, &t38_generator, t38_state);
               s->finished=1;
               for(;;) {
                       active=ast_waitfor_n(channels, 2, &timeout);
                       timeout=20;
                       if ((f = ast_read(active))) {
                               for(;f;f=next) {
                                       if ((active == t38chan) && (f->frametype == AST_FRAME_MODEM) &&
                                           (f->subclass == AST_MODEM_T38))
                                               t38_core_rx_ifp_packet(t38dsp, f->data.ptr, f->datalen, f->seqno);
                                       else if ((active == t30chan) && (f->frametype == AST_FRAME_VOICE) &&
                                                (f->subclass == AST_FORMAT_SLINEAR))
                                               t38_gateway_rx(t38_state, (int16_t *)(f->data.ptr), f->samples);
                                       else if (f->frametype != AST_FRAME_NULL)
                                               ast_log(LOG_NOTICE, "BAD Frame NOT Processed %i/%i %i %i\n",f->frametype, f->subclass, f->datalen, f->seqno);
                                       next=AST_LIST_NEXT(f, frame_list);
                                       ast_frame_free(f, 1);
                                       f=NULL;
                               }
                       } else if (active)
                               break;
               }
               ast_deactivate_generator(t30chan);
----------
By: Gregory Hinton Nietsky (irroot) 2008-10-28 11:06:39

ok im back http://www.bellequipment.com is now a asterisk user ill be working on this project further they are one of the implementors of this.
By: klaus3000 (klaus3000) 2008-11-06 04:24:35.000-0600

Hi! I want to test T.38 gatewaying - but from reading the thread above I still don't get if I:
- should use Asterisk 1.4 or 1.6.0, 1.6.1, trunk for testing?
- which patch I should use?

@irroot: You are talking about fixes you will upload - when will you upload?
By: Daniel Ferenci (dafe_von_cetin) 2008-11-06 04:36:13.000-0600

Hi,

patches you can download from this page are for asterisk svn head verison.
(Or at least they were by the time of upload).
I placed here links to external page where I keep patches for 1.4.20.1 and 1.6.0.
But this links were removed by admins since it is not allowed to link out from this page.

Best regards
Daniel.
By: klaus3000 (klaus3000) 2008-11-06 07:29:55.000-0600

Hi! I tried the app_fax-t38gw.patch with 1.6.1-beta2 and there is the LOAD_OH problem. So, which one should I use? app_fax-t38gw.patch or asterisk-1.6.trunk_t38_v3.diff ??? Do they already work?
By: Leif Madsen (lmadsen) 2008-11-06 08:08:04.000-0600

sroberts: your license was rejected for the patch against 1.6.0.1. Can you please refill in your license as there must have been some sort of issue with it (unfortunately I don't know why it was rejected).
By: Daniel Ferenci (dafe_von_cetin) 2008-11-06 08:21:07.000-0600

Hi,

asterisk-1.6.trunk_t38_v3.diff is patch published by me.
app_fax-t38gw.patch is rewritten and updated patch published by irroot.

I would recommend to use updated version app_fax-t38gw.patch as irroot has made some bugfixes already.
However both patches WORK with asterisk1.6 trunk version. It is the version you can get via "svn" command.
Most probably you will have problems if you want to apply those patches to one of the pre-release or relase asterisk-1.6 versions.
It is not possible (by asterisk release process) to publish patches for new functionality to not development codelines that is why you can not find here patches to asterisk-1.6-beta2.
Actually it is possible with little hacking to adapt this patches to any of
asterisk-1.6 release versions.

Daniel.
By: Daniel Ferenci (dafe_von_cetin) 2008-11-06 08:30:54.000-0600

Hi blitzrage,

I can see licenses for both patches here marked green OK.
Is it an incorrect state?

Best regards
Daniel.
By: Leif Madsen (lmadsen) 2008-11-06 08:55:20.000-0600

dafe_von_cetin: thanks for the note about applying to trunk and clarifying why people can't apply to releases. That should help people get to testing the patches.

Those 2 patches are fine, but there is a third patch you won't be able to see by sroberts because his license was rejected.
By: klaus3000 (klaus3000) 2008-11-06 09:43:39.000-0600

hi! I tried app_fax-t38gw.patch with Asterisk trunk but it does not work (as reported also from other people here):

app_fax.c:1039: warning: implicit declaration of function 'LOAD_OH'
By: Daniel Ferenci (dafe_von_cetin) 2008-11-06 10:18:22.000-0600

Hi,
I got the point.

LOAD_OH (oh)
should be probably stand for:
oh.context = context;
oh.exten = exten;
oh.priority = priority;
oh.cid_num = cid_num;
oh.cid_name = cid_name;
oh.account = account;
oh.vars = vars;

I'm going to test it soon. Then I will create update patch.
By: klaus3000 (klaus3000) 2008-11-06 10:23:01.000-0600

Yes - meanwhile I replaced the LOAD_OH macro and also removed the channel locks - not it compiles. It tested both directions - SIP-->ISDN and ISDN--> but Asterisk did not sent any reINVITEs to t.38 - in neither case.

My dialplan is really simple:
[fromISDN]
exten => 366,1,FaxGateway(SIP/fax@mydomain.at)
[fromSIP]
exten => fax936,1,FaxGateway(Dhadi/g2/06621234567)

Am I doing something wrong?

btw: are you on the asterisk-dev list? that would ease debugging
By: Daniel Ferenci (dafe_von_cetin) 2008-11-06 10:29:06.000-0600

Can you provide log with debug infos?
Yes, I'm on asterisk-dev list.
By: klaus3000 (klaus3000) 2008-11-07 02:00:14.000-0600

hi! I had to enable t38 and configure udptl.conf. Now asterisk sends reINVITEs, but my client crashes (Zoiper). I have to look for another client. Nevertheless strange things happen, e.g. if reINVITE to T.38 fails (client sends 488), Asterisk does send again an INVITE with RTP/audio and at the same time hangs up the channels (the SIP and DHADI channel) without sending BYE. This is a bug, and the second reINVITE is not needed at all, as the first reINVITE failed.

I also saw that Asterisk uses different ports for t.38 than RTP. Is there a chance to reuse the RTP ports for t.38?
By: Sebastian (sroberts) 2008-11-07 07:34:05.000-0600

blitzrage: sure, I'll do that this weekend. The patch has changed slightly anyways.

klaus: I'm interested in how you got Asterisk to send the reINVITES?
I've got a setup here where I've got a PRI coming in to my Asterisk box, on which I receive the fax. I then have a SIP trunk going into another machine running Rightfax with Brooktrout sr140 FoIP software. It seems like the Brooktrout is waiting for a reINVITE, and so is Asterisk. So they both just sit there waiting until one times out and hangs up the call.
By: klaus3000 (klaus3000) 2008-11-07 08:15:23.000-0600

IIRC Asterisk sends reINVITEs only if it is the callee. This is what T.38 equipment usually does - the receiver triggers the reINVITE.
By: klaus3000 (klaus3000) 2008-11-07 09:44:39.000-0600

There is also another problem I could not fix yet: udptl does not send symmetrically, but the the prot announced in the SDP. Thus, it does not work for clients behind NAT without STUN. Looks like the t38pt_usertpsource=yes command only sets the IP address where to send udptl, but not the port.
By: klaus3000 (klaus3000) 2008-11-07 13:41:43.000-0600

FYI: I just faxed 10 pages from Dahdi to an Linksys Adapter - it worked (after I reconfigured the firewall to open the portrange for udptl)
By: ssfarrel (ssfarrel) 2008-12-11 12:10:19.000-0600

Any sign of someone posting an updated patch for this, dying to try a working (current) version.
By: klaus3000 (klaus3000) 2008-12-11 13:46:16.000-0600

Hi!

Try the "t38-gw-r154965.patch.txt" patch. It was tested with trunk r154965 but it should not be hard to port it to new trunk or older releases. Note: I removed the channel locks to make it compile - maybe this can cause problems.

I used it with spandsp 0.0.5pre4.

I added to sip.conf [general]:
t38pt_udptl = yes
t38pt_usertpsource=yes

Make sure to configure UDPTL ports in udptl.conf (and open these ports in the firewall).

My dialplan is really simple:
[fromISDN]
exten => 366,1,FaxGateway(SIP/fax@mydomain.at)
[fromSIP]
exten => fax936,1,FaxGateway(Dhadi/g2/06621234567)
By: Daniel Ferenci (dafe_von_cetin) 2008-12-18 03:29:49.000-0600

Hi All,

some of you spotted problem with fax gateway when gatewaying from NAT-ed network  out to the public.

FAX <-> AST (with fax gateway) <- (inside) ROUTER (outside) -> AST or FAX

The problem is caused by UDPTL NAT handling.
UDPTL applies NATted address (public one of the router) just when recieve first packet.
But fax gateway (inside nat) was waiting for that packet from the peer (outside nat) that is its usual flow.
The peer outside the nat was sending such packewts but with negotiated SIP address (like 192.168.x.x) that is way the first packet never reach the fax gateway inside NAT and whole T38 communication set up is failing.

I solved this by sending NULL packet from fax gateway.
+    // a hack -> engage udptl nat on other side of T38 line
+    char nullChar [] = "\0";
+    t38_tx_packet_handler(&t38_state.t38, (void *) channels[0], (const uint8_t *) nullChar, 1, 1);


This is a useless packet for T38 so it has (I hope) no efect on T38 stack but it sets the IP address for  UDPTL nat so the communication can proceed.
Not nice but it works.

Enjoy.

Daniel.
By: klaus3000 (klaus3000) 2008-12-18 16:38:01.000-0600

Hi! What about sending a "no signal" packet instead of the 0 packet?
By: Daniel Ferenci (dafe_von_cetin) 2008-12-19 02:41:24.000-0600

Hi,

yes this is a very good idea. I'm going to test it.
Updated patch will follow.

Best regards
Daniel.
By: klaus3000 (klaus3000) 2008-12-19 04:11:57.000-0600

Also I would not send only one dummy packet, but 2 or three - so that for sure one make it through all the firewall, NATs, ...
By: klaus3000 (klaus3000) 2008-12-19 04:13:47.000-0600

Hi Dave! Have you also solved the problem with the channel lock?

btw: does the t38 gateway have a jitter buffer? Does it spoof T.30 data in case of packet loss (e.g. empty lines during high speed transmission or HDLC frames during low speed transmission)?
By: Daniel Ferenci (dafe_von_cetin) 2008-12-19 08:20:24.000-0600

Hi,

about the dummy packet: I see that we need some more complex solution.
What about sending dummy "No signal" packets every defined time until we get the first response from the other side ?

about jitter buffer and spoofing: To be honest I have no idea, whole gatewaying logic is stored inside spandsp.
I'm solving issues as they appear during testing and until now I didn't have such problem. So if they appear and my cutomer complains I will solve them and I will share.

Best regards
Daniel.
By: Leif Madsen (lmadsen) 2008-12-19 09:19:51.000-0600

Just an update question:

How much longer do you think until this is nearly complete and ready for wider testing from the community? (i.e. all major code changes are complete, and you are ready to have a larger amount of people to test and report bugs before sending to review)
By: alcazar (alcazar) 2009-02-23 21:07:14.000-0600

The new spandsp-0.0.6-pre4 breaks FaxGateway.


By: alcazar (alcazar) 2009-03-11 20:08:14

Are the maintainers of this patch letting it die?  This was a great feature, and from what I am hearing the new spandsp fixes up a lot of issues.
By: Matt Riddell (zx81) 2009-03-12 03:10:25

What's remaining to do on the patch? Is it just waiting for a review?
By: Daniel Ferenci (dafe_von_cetin) 2009-03-12 04:12:39

Hi All,

I fixed following issues on my original patch for 1.4.20.1:
- NAT issue (faxgateway was not able to set up communication when call is initiated from behind NAT)
- cooperation with SS7 channel
Now I'm facing problem with voice over the fax gateway.
Fax gateway should bridge voice g711 unless it detects fax.
Originally I wanted to fix this issues and apply them into trunk version before the review happen.
But unfortunatelly I'm running out of time.
So I can send anybody interested my latest patch for 1.4.20.1 so that he can
do merge to trunk version.
I can not post 1.4.20.1 patch here and neither send the link to external page.
So if there is somebody please send me a mail and I will reply with link to my latest patch.

Best regards
Daniel.
By: Leif Madsen (lmadsen) 2009-03-12 07:46:34

Why not just attach the patch here...?
By: Daniel Ferenci (dafe_von_cetin) 2009-03-12 08:42:28

Hi,

last time I did this the patch was removed because it was not applicable to the trunk.
But ok I've just uploaded the patch asterisk-1.4.20.1_t38_v4.diff here.

Best regards
Daniel.
By: alcazar (alcazar) 2009-03-12 12:48:12

Hi Daniel,

Your patch is not compatible with spandsp >= 0.0.6-pre4
By: Daniel Ferenci (dafe_von_cetin) 2009-03-13 03:09:22

Hi,

yes I know.
Yet I'm working with spandsp 0.0.5
After I'm ready on spandsp 0.0.5 I will move to spandsp 0.0.6 .
Then I will publish the changed patch.

Best regards
Daniel.
By: Kristijan Vrban (vrban) 2009-04-23 18:55:12

hello, is the t38-gw-r154965.patch the latest available 1.6 gateway patch? it looks slightly unfinished?
By: Daniel Ferenci (dafe_von_cetin) 2009-04-24 07:37:01

Hi,

yes, t38-gw-r154965.patch is the latest 1.6 patch.
I've been working on 1.4.20.1 patch updates since I had to work with chan_ss7 which (as far as I know) is not ported to 1.6 yet.
The last 1.4.20.1 patch version is v4.2.
It seems that work on 1.4.20.1 is almost done.
Thus I would like to continue with 1.6 trunk and post it for review by the end of this month.
I would like to backport my last fixes from 1.4.20.1 and usage of latest spandsp as well.

Best regards
Daniel.
By: Dmitry Andrianov (dimas) 2009-04-25 09:07:15

I'm curious if someone looked at new bridging API? Shouldn't T38 gateway be just a special type of bridge?
By: Gentian Bajraktari (gentian) 2009-04-29 13:29:13

I tried Asterisk 1.6.0.9 with t38-gw-r154965.patch, compile is ok, no errors. But when the call goes to ATA Linksys SPA2102 or Grandstream H286 or Zhone DSLAM with POTS ports the call fails. Every time the call is connected and switched to T38 all clients respond with:

SIP/2.0 488 Not acceptable here

and sends HangupCause: Normal Clearing so DAHDI channel hungs up and call is finished failing the fax.

some of the logs:

yy.yy.yy.yy = Asterisk Server
xx.xx.xx.xx = Linksys SPA2102

zzzzzzzzz = SIP number register on SPA to Asterisk server
nnnnnnnnn = PSTN number sending the FAX



<--- SIP read from UDP://xx.xx.xx.xx:5060 --->
INVITE sip:zzzzzzzzz@yy.yy.yy.yy SIP/2.0
Via: SIP/2.0/UDP xx.xx.xx.xx:5060;branch=z9hG4bK-d228ac1c
From: <sip:zzzzzzzzz@xx.xx.xx.xx:5060>;tag=859e1fcb4af7a47bi0
To: "nnnnnnnnn" <sip:zzzzzzzzz@yy.yy.yy.yy>;tag=as72e031a7
Remote-Party-ID: zzzzzzzzz <sip:zzzzzzzzz@yy.yy.yy.yy>;screen=yes;party=called
Call-ID: 6b1216784093afb863cb5a614ce26d45@yy.yy.yy.yy
CSeq: 101 INVITE
Max-Forwards: 70
Contact: zzzzzzzzz <sip:zzzzzzzzz@xx.xx.xx.xx:5060>
Expires: 30
User-Agent: Linksys/SPA2102-3.3.6
Content-Length: 265
Content-Type: application/sdp

v=0
o=- 35420 35420 IN IP4 xx.xx.xx.xx
s=-
c=IN IP4 xx.xx.xx.xx
t=0 0
m=image 16466 udptl t38
a=T38FaxVersion:0
a=T38MaxBitRate:14400
a=T38FaxRateManagement:transferredTCF
a=T38FaxMaxBuffer:200
a=T38FaxMaxDatagram:200
a=T38FaxUdpEC:t38UDPRedundancy


<------------->
--- (13 headers 12 lines) ---
Sending to xx.xx.xx.xx : 5060 (no NAT)
Got T.38 offer in SDP in dialog 6b1216784093afb863cb5a614ce26d45@yy.yy.yy.yy
Got T.38 Re-invite without audio. Keeping RTP active during T.38 session. Callid 6b1216784093afb863cb5a614ce26d45@yy.yy.yy.yy
Capabilities: us - 0x8 (alaw), peer - audio=0x0 (nothing)/video=0x0 (nothing)/text=0x0 (nothing), combined - 0x0 (nothing)
Non-codec capabilities (dtmf): us - 0x1 (telephone-event), peer - 0x0 (nothing), combined - 0x0 (nothing)

<--- Transmitting (no NAT) to xx.xx.xx.xx:5060 --->
SIP/2.0 100 Trying
Via: SIP/2.0/UDP xx.xx.xx.xx:5060;branch=z9hG4bK-d228ac1c;received=xx.xx.xx.xx
From: <sip:zzzzzzzzz@xx.xx.xx.xx:5060>;tag=859e1fcb4af7a47bi0
To: "nnnnnnnnn" <sip:zzzzzzzzz@yy.yy.yy.yy>;tag=as72e031a7
Call-ID: 6b1216784093afb863cb5a614ce26d45@yy.yy.yy.yy
CSeq: 101 INVITE
User-Agent: AsteriskPBX
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY
Supported: replaces, timer
Contact: <sip:zzzzzzzzz@yy.yy.yy.yy>
Content-Length: 0


<------------>
   -- Remote UNIX connection
   -- Remote UNIX connection disconnected
s1*CLI>
<--- Reliably Transmitting (no NAT) to xx.xx.xx.xx:5060 --->
SIP/2.0 488 Not acceptable here
Via: SIP/2.0/UDP xx.xx.xx.xx:5060;branch=z9hG4bK-d228ac1c;received=xx.xx.xx.xx
From: <sip:zzzzzzzzz@xx.xx.xx.xx:5060>;tag=859e1fcb4af7a47bi0
To: "nnnnnnnnn" <sip:zzzzzzzzz@yy.yy.yy.yy>;tag=as72e031a7
Call-ID: 6b1216784093afb863cb5a614ce26d45@yy.yy.yy.yy
CSeq: 101 INVITE
User-Agent: AsteriskPBX
Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY
Supported: replaces, timer
Content-Length: 0
X-Asterisk-HangupCause: Normal Clearing
X-Asterisk-HangupCauseCode: 16
By: klaus3000 (klaus3000) 2009-04-29 16:10:25

Have you enabled t38 in sip.conf?
 t38pt_udptl = yes
 t38pt_usertpsource=yes
By: Kristijan Vrban (vrban) 2009-04-29 20:53:11

@gentian

hello, same problem here with a Grandstream HT502, see bug report 14849
This problem is probably not in relationship with the gateway patch from here, i suggest to report this at 14849.
By: Gentian Bajraktari (gentian) 2009-04-30 02:36:23

Hi klaus3000

Yes I did both:
 t38pt_udptl = yes
 t38pt_usertpsource=yes

I also tried all advised configurations on SPA2102 like Passthroughmode set to ReINvite but the same happens, as soon as they try to switch to T.38 hte call is discconncted because receiving stations allways respond with 488.
By: Gentian Bajraktari (gentian) 2009-04-30 02:45:54

hi @vrban I checked your report 14849 and we experience the same problem but isn't the 488 coming from the client and not from asterisk?

anyway it is a problem that needs to be addressed otherwise there is no way we can use this good patch of FaxGateway.

i hope @daniel comes up with a review as he mentioned by the end of this month.
By: Evandro César Arruda (ecarruda) 2009-05-01 09:29:21

Hey People,

I Tryed to compile using Debian Etch and Asterisk 1.4.20.1, but on make process i Received:

  [CC] app_fax.c -> app_fax.o
app_fax.c: In function 'transmit_audio':
app_fax.c:341: error: storage size of 'fax' isn't known
app_fax.c:341: warning: unused variable 'fax'
app_fax.c: In function 'transmit_t38':
app_fax.c:522: error: storage size of 't38' isn't known
app_fax.c:522: warning: unused variable 't38'
make[1]: ** [app_fax.o] Erro 1
make: ** [apps] Erro 2


With the last patch v4.2
By: Gianluca (lilok) 2009-05-04 03:00:27

Hello guys,
i'm hardly trying to use this patch to solve my fax problems at all.
Unfortunatly i got some problems.
I'd like to explain my situation step by step so you can help me and telling me if i'm working in the correct way.

This is my scenario

E1/Pri --> (gw)Asterisk 1.6.0.6 --sip/t30 g711--> (1)Asterisk 1.4.20.1 FaxGateway(Sip/asterisk(2)/${EXTEN}) --sip/t38--> (2)Asterisk 1.4.20.1 FaxGateway(Zap/1) --t30--> Fax machine

asterisk (1) and (2)
--------------------
asterisk-1.4.20.1
asterisk-1.4.20.1_t38_v4.2.diff
spandsp-0.0.4

asterisk (gw) and (1) are on the same switch
--------------------------------------------

The problem is that fax doesn't receive documents. Sometimes the machine says "Operation complete" but it doesn't print nothing and other times it says "Incomplete document".
In the terminals on both the asterisk machines (asterisk(1)and(2)) i can see the t38 transaction but at the end the result is not the one i expect.

So i ask you the first question: is this use of the FaxGateway application correct?

If yes, what you need to understand and debug this situation?

Thanks for help.
By: Alexander V. Chernikov (bird_of_luck) 2009-05-08 05:57:02

Hello peple,
I've successfully tested asterisk-1.4.20.1_t38_v4.2.diff patch on 1.4.21.2 with spandsp_0.0.6pre7

My scenario:

E1 <-> 5350XM <-> g/711 passthrough only <-> * 1.4.21.2 711/t.38 <-> nsgate 3522 (2-port fxs device)

Voice/faxes going without any problems in both directions. Thanks for a great work!



The problem is in lack of Dial() options support, like tTM .... imho the easiest way to use this in production _at the moment_ is the following:

E1/g711uplink <-> *1.4+faxgw with simple FaxGateway() dialplan <>
* 1.4/1.6 with fax passthru patch and pbx/virtual pbx diaplans <> client devices with t.38 switchover support
By: Gentian Bajraktari (gentian) 2009-05-31 14:53:36

Tried 1.6.0.9 with the new patch from issue: "0014849: [patch] SendFax function not working as expected on > 1.6.0.7 "

and now FaxGateway works, at least the call is now answered as T.38 and I can see FAX logs but all the faxes fail.

These are the logs, am I doing smth wrong?:

[2009-05-30 22:32:39] DEBUG[28882] app_fax.c: Fax CED Tone Detected On DAHDI/2-1
[2009-05-30 22:32:39] DEBUG[28882] app_fax.c: T.38 Gateway Starting chan SIP/043300935-b7df3330 peer DAHDI/2-1
[2009-05-30 22:32:39] DEBUG[28882] app_fax.c: HDLC carrier up
[2009-05-30 22:32:40] DEBUG[28882] app_fax.c: HDLC carrier down
[2009-05-30 22:32:40] DEBUG[28882] app_fax.c: Restart rx modem - modem = 0, short train = 0, ECM = 0
[2009-05-30 22:32:40] DEBUG[28882] app_fax.c: HDLC carrier up
[2009-05-30 22:32:40] DEBUG[28882] app_fax.c: Tx     0: indicator v21-preamble
[2009-05-30 22:32:41] DEBUG[28882] app_fax.c: Corrupting NSF message to prevent recognition
[2009-05-30 22:32:41] DEBUG[28882] app_fax.c: Tx     1: (0) data v21/hdlc-data + 1 byte(s)
[2009-05-30 22:32:41] DEBUG[28882] app_fax.c: Tx     1: IFP c0 01 80 00 00 ff
[2009-05-30 22:32:41] DEBUG[28882] app_fax.c: Tx     2: (0) data v21/hdlc-data + 1 byte(s)
[2009-05-30 22:32:41] DEBUG[28882] app_fax.c: Tx     2: IFP c0 01 80 00 00 c0
[2009-05-30 22:32:41] DEBUG[28882] app_fax.c: Tx     3: (0) data v21/hdlc-data + 1 byte(s)
[2009-05-30 22:32:41] DEBUG[28882] app_fax.c: Tx     3: IFP c0 01 80 00 00 04
[2009-05-30 22:32:41] DEBUG[28882] app_fax.c: Tx     4: (0) data v21/hdlc-data
....................................................................
.....................................................................
many of these..........................................................
.......................................................................
[2009-05-30 22:33:14] DEBUG[28882] app_fax.c: HDLC frame type DIS, CRC OK
[2009-05-30 22:33:14] DEBUG[28882] app_fax.c: Monitoring DIS
[2009-05-30 22:33:14] DEBUG[28882] app_fax.c: Tx   453: (0) data v21/hdlc-fcs-OK + 0 byte(s)
[2009-05-30 22:33:14] DEBUG[28882] app_fax.c: Tx   453: IFP c0 01 20
[2009-05-30 22:33:14] DEBUG[28882] app_fax.c: HDLC carrier down
[2009-05-30 22:33:14] DEBUG[28882] app_fax.c: Tx   454: (0) data v21/hdlc-sig-end + 0 byte(s)
[2009-05-30 22:33:14] DEBUG[28882] app_fax.c: Tx   454: IFP c0 01 10
[2009-05-30 22:33:14] DEBUG[28882] app_fax.c: Tx   455: indicator no-signal
[2009-05-30 22:33:14] DEBUG[28882] app_fax.c: Restart rx modem - modem = 0, short train = 0, ECM = 0
[2009-05-30 22:33:17] DEBUG[28882] app_fax.c: HDLC carrier up
[2009-05-30 22:33:17] DEBUG[28882] app_fax.c: Tx   456: indicator v21-preamble
[2009-05-30 22:33:18] DEBUG[28882] app_fax.c: Tx   457: (0) data v21/hdlc-data + 1 byte(s)
[2009-05-30 22:33:18] DEBUG[28882] app_fax.c: Tx   457: IFP c0 01 80 00 00 ff
[2009-05-30 22:33:18] DEBUG[28882] app_fax.c: Tx   458: (0) data v21/hdlc-data + 1 byte(s)
[2009-05-30 22:33:18] DEBUG[28882] app_fax.c: Tx   458: IFP c0 01 80 00 00 c8
[2009-05-30 22:33:19] DEBUG[28882] app_fax.c: Tx   459: (0) data v21/hdlc-data + 1 byte(s)
[2009-05-30 22:33:19] DEBUG[28882] app_fax.c: Tx   459: IFP c0 01 80 00 00 5f
[2009-05-30 22:33:19] DEBUG[28882] app_fax.c: HDLC frame type DCN, CRC OK
[2009-05-30 22:33:19] DEBUG[28882] app_fax.c: Monitoring DCN
[2009-05-30 22:33:19] DEBUG[28882] app_fax.c: Tx   460: (0) data v21/hdlc-fcs-OK + 0 byte(s)
[2009-05-30 22:33:19] DEBUG[28882] app_fax.c: Tx   460: IFP c0 01 20
[2009-05-30 22:33:19] DEBUG[28882] app_fax.c: HDLC carrier down
[2009-05-30 22:33:19] DEBUG[28882] app_fax.c: Tx   461: (0) data v21/hdlc-sig-end + 0 byte(s)
[2009-05-30 22:33:19] DEBUG[28882] app_fax.c: Tx   461: IFP c0 01 10
[2009-05-30 22:33:19] DEBUG[28882] app_fax.c: Tx   462: indicator no-signal
[2009-05-30 22:33:19] DEBUG[28882] app_fax.c: Restart rx modem - modem = 0, short train = 0, ECM = 0
[2009-05-30 22:33:19] DEBUG[28882] app_fax.c: HDLC carrier up
[2009-05-30 22:33:19] DEBUG[28882] app_fax.c: HDLC carrier down
[2009-05-30 22:33:19] DEBUG[28882] app_fax.c: Restart rx modem - modem = 0, short train = 0, ECM = 0
[2009-05-30 22:33:19] DEBUG[28882] app_fax.c: HDLC carrier up
[2009-05-30 22:33:19] DEBUG[28882] app_fax.c: HDLC carrier down
[2009-05-30 22:33:19] DEBUG[28882] app_fax.c: Restart rx modem - modem = 0, short train = 0, ECM = 0
[2009-05-30 22:33:40] DEBUG[28882] app_fax.c: Connection Statistics
[2009-05-30 22:33:40] DEBUG[28882] app_fax.c: Transmission finished Ok


By: Gentian Bajraktari (gentian) 2009-06-01 02:03:28

I also get a lot of this:

DEBUG[29059] app_fax.c: Tx   462: indicator no-signal
By: Arun Pereira (arunpereira) 2009-06-09 14:19:41

Dafe,
   Is there a way we could get the patch for asterisk 1.4.24.1? Please let me know.
Thank you,
Arun.
By: Marcin Kowalczyk (kowalma) 2009-07-03 08:14:51

Is this patch going to be added to 1.6.1 or later?
By: dimitripietro (dimitripietro) 2009-07-07 21:01:17

I'm ready to help to test this patch on any version. If anyone could tell me which version of the patch to try on which asterisk version.
By: Daniel Ferenci (dafe_von_cetin) 2009-07-08 07:10:26

Hi All,

sorry for not being able to post it sooner
however please try t38-gw-r205116.patch .

Best regards
Daniel.
By: dimitripietro (dimitripietro) 2009-07-08 07:18:45

Against the trunk ?
By: Daniel Ferenci (dafe_von_cetin) 2009-07-08 07:32:50

Hi,

yes, the trunk.
Revision number is part of patch name.

Daniel.
By: dimitripietro (dimitripietro) 2009-07-22 08:25:37

Ok, Here's my test lab : Asterisk SVN-trunk-r207680M, CentOS 5 and spandsp-0.0.6pre12:

<Brother MFC8220> -- <SPA2102> -- <Asterisk> -- <TDM410> -- <PSTN> --- <FAX 2>

[GENERAL]
t38pt_udptl = yes,redundancy

udptl.conf
udptlstart=4000
udptlend=4999
T38FaxUdpEC = t38UDPRedundancy
T38FaxMaxDatagram = 400
udptlfecentries = 3
udptlfecspan = 3

extensions.conf
[faxt38]
exten => _X.,1,FaxGateway(DAHDI/G0/${EXTEN})

Asterisk and the ATA are on the same network. With or without T.38 the fax passtrought. But when I activate T.38 I can see the channel switching to T.38 but at the end always get :

[Jul 22 09:10:41] DEBUG[24819]: chan_dahdi.c:3925 dahdi_disable_ec: Disabled echo cancellation on channel 3
[Jul 22 09:10:41] NOTICE[24819]: app_fax.c:976 ast_t38_gateway: T.38 gateway exitting - channel hang up.
[Jul 22 09:10:41] DEBUG[24819]: app_fax.c:983 ast_t38_gateway: Connection Statistics
       Bit Rate :9600
       ECM : No
       Pages : 1
[Jul 22 09:10:41] WARNING[24819]: app_fax.c:1210 t38gateway_exec: Transmission failed
[Jul 22 09:10:41] DEBUG[24819]: channel.c:2133 ast_hangup: Hanging up channel 'DAHDI/3-1'

Even if it's say transmission fail, I don't know what to think about it. The transmission when throught no problem.
By: Daniel Ferenci (dafe_von_cetin) 2009-07-22 08:59:55

Hi,

the log is very weak.
I need to add more log statements.
Please wait for the next patch.

Daniel.
By: Leif Madsen (lmadsen) 2009-07-22 09:21:38

kowalma: no, this will only be put into trunk, and thus only into future 1.6.x branches (beyond 1.6.2, and potentially beyond 1.6.3 if this doesn't go in before then -- my guess is this will make it in for 1.6.4 at the earliest).
By: Dmitry Andrianov (dimas) 2009-07-22 12:09:31

1. JFYI, the semantics of T38 related control frames in Asterisk have changed significantly recently so any code using these needs to be updated appropriately. Take a look at recent changes to  chan_sip and app_fax to get in idea.

2. IIRC there was some work on new bridging API for asterisk. There are different types of bridges available (like one-to-one or one-to-many). To me it looks like the T38 fax gateway is just a special type of bridge, not a separate application.

It is just my thought but I'm thinking about the scenario:
1. at some point Asterisk bridges channels A and B
2. Later asterisk receives T38 request on channel A
3. Asterisk determines it can not pass this request to channel B because B reports it does not support T38 at all.
4. At this point Asterisk decides to temporary replace current A-B channel bridge with T38 gateway bridge.
5. new bridge does the conversion of T38 to audio (or back)

Well, it may sound weird. Probably it is weird :) But it definitely worth researching IMHO. This Asterisk will be doing translation transparenyly...
By: Daniel Ferenci (dafe_von_cetin) 2009-07-23 03:13:51

dimas: I've already thougth about transparent solution. That is a good point. I will check that API.
By: Daniel Ferenci (dafe_von_cetin) 2009-07-23 04:48:12

dimas: so checked it, bridging api seems to be nice. However app_dial doesn't use it so far. I'm not sure if I can combine two bridging approaches in one app. Does anybody know?
By: Leif Madsen (lmadsen) 2009-07-24 09:48:08

Note: all new features (such as this one) are always applied against trunk
By: dimitripietro (dimitripietro) 2009-08-04 15:39:52

dafe_von_cetin,

Any update I can try ?

Thx for your work


By: Daniel Ferenci (dafe_von_cetin) 2009-08-05 03:14:33

dimitripietro,

currently I'm investigating a transparent way for T38 gateway.
One feasible was I see in adding T38 gatewaying feature into app_dial.

What do you think? Would it be appreciated by users?

I haven't discovered any lower level approach yet.

D.
By: Martin Vit (festr) 2009-08-05 05:36:33

Transparent way is the most comfortable way how to switch to T.38. Otherwise there has to be evidence of which numbers are fax and which are not and distinguesh between Dial and T38app.
By: Daniel Ferenci (dafe_von_cetin) 2009-08-05 06:11:41

festr,

ok. And is it sufficient to implement such T.38 transparency in app_dial?

D.
By: Martin Vit (festr) 2009-08-05 06:34:09

Fully. All gateways works transparently so Asterisk should also. I think that everyone is making calls via Dial cmd from app_dial.
By: Dmitry Andrianov (dimas) 2009-08-05 06:37:34

dafe_von_cetin I would recommend you discussing the approach on asterisk developers mailing list. This way you will be consistent with plans Digium people have on bridging API or anything else related to your patch.
By: Niccolò Belli (darkbasic) 2009-10-06 16:32:42

Is there an updated version of the patch? I tried it in revision 205116 and it works very well, but it doesn't work on the latest svn trunk, and I need to use asterisk 1.6.2 :(
Thank you,
Darkbasic
By: Niccolò Belli (darkbasic) 2009-10-16 18:12:58

Is there someone still working at this patch?
By: Leif Madsen (lmadsen) 2009-11-11 08:55:46.000-0600

Well SVN trunk and the 1.6.2 branch are different beasts.

What do you mean it doesn't work? Do you mean the patch doesn't apply, or once applied and compiled the functionality no longer works?
By: Niccolò Belli (darkbasic) 2009-11-11 09:05:44.000-0600

I was talking of 1.6.2 branch, sorry.
Please see

www.mail-archive.com/asterisk-dev@lists.digium.com/msg39318.html

and

www.mail-archive.com/asterisk-dev@lists.digium.com/msg39567.html


By: Daniel Ferenci (dafe_von_cetin) 2009-11-11 17:47:53.000-0600

Hi,

I've just uploaded the patch update for the newest trunk.
The patch is still without previously mentioned transparency.

Daniel.
By: Niccolò Belli (darkbasic) 2009-11-12 05:25:35.000-0600

Hi, thank you for the update.
Does it work against 1.6.2 svn?

Darkbasic
By: Daniel Ferenci (dafe_von_cetin) 2009-11-12 06:46:35.000-0600

Hi Darkbasic,

I havn't tried but most probably not.
I will try to post a patch for 1.6.2 but it is not my priority.
First I will try to post a patch for transparent GW.

Daniel.
By: Leif Madsen (lmadsen) 2009-11-13 08:43:14.000-0600

Note that new features can only go into trunk, thus patches should be applied and tested against trunk.
By: Mina (rnbguy) 2010-01-09 22:25:41.000-0600

guys, please stop distracting developers to work on different version of asterisk, lets get it working on the intended versions and then move forward, otherwise the patch will never be released...

can i ask what is the latest status on this confirmed patch? is it working 100% without transperancy features?
By: anest (anest) 2010-01-09 22:53:07.000-0600

the patch fully working for me. and i really can't understand why not add this nice code to trunk... i understand about "freeze code" in 1.4.x but in any case have exceptions and *that* case really needs exception for faxes, im sure many ppl will be agree with me!
ps: i'm so tired to edit the patch and patched every time then update asterisk.. 1.6 not ready for serious production yet. but 1.4 get frozen on middle of the way.. its my own little hell. :((


By: Gentian Bajraktari (gentian) 2010-01-10 00:23:27.000-0600

I agree with you @anest , we have been waiting a lot, many reports say it works perfect so why not have this code in all releases so all people can use that.
somebody could patch it for  Asterisk 1.6.0.20 ??
By: Mina (rnbguy) 2010-01-10 04:48:46.000-0600

that's excellent news, it's difficult to understand this patch works perfectly just by reading these notes, so your note will be very encouraging for many... i really didnt want to move to callweaver just for T38.

could you please explain these questions for me and many others in my shoes:

1) which version of asterisk 1.4 did you use and know this patch works perfectly on
2) which patch did you use for that version of asterisk 1.4
3) which modifications did need to make to patch
4) how did you setup your dialplan
5) how was your infrastructure setup (ISDN>asterisk(patched)>ATA(T38 relay)>FAX)
6) which modules (app_fax?) are pre requirements for this to work


By: Mina (rnbguy) 2010-01-10 07:43:50.000-0600

how do i modify this patch to work with asterisk 1.4 release (not svn) version to avoid this:

patching file asterisk-1.4.20.1/res/.res_speech.moduleinfo
patch unexpectedly ends in middle of line


p.s please delete this post if its against policy, i read policy and couldnt find if this was a negative post.
By: Daniel Ferenci (dafe_von_cetin) 2010-01-11 03:54:58.000-0600

Hi Folks,

if you are satisfied with current patch functionality then from my point of view I wouldn't postpone integrating this patch into trunk with transparent GW feature.
I would create new issue for this feature.

@lmadsen: I'm not very knowledgeable with your processes. Can you please instruct me how to move this patch forward to trunk?

Best regards
Daniel.
By: Mina (rnbguy) 2010-01-11 03:58:57.000-0600

Daniel good to hear , sounds like alot tend to like this, dan could you please provide answers to my questions earlier or atleast email me on how i can patch my release version of asterisk 1.4 (which ever 1.4 version you suggest).

if your not able to provide instructions here please email to me on mina.moussa@hotmail.com

I appreciate your work alot!
By: Martin Vit (festr) 2010-01-11 04:03:17.000-0600

I'm interested in those questions about 1.4 asterisk too, can you please answer it here?
By: Gentian Bajraktari (gentian) 2010-01-11 04:19:13.000-0600

I am interested on the 1.6.0.x , as it supports DAHDI and LIBSS7 very well.
I have ss7 voice running on it, but no T38 fax gateway.
Is it possible to have it on 1.6.0.x version?
By: Daniel Ferenci (dafe_von_cetin) 2010-01-11 04:37:43.000-0600

Hi,

@1.4.20.1
simply ignore this error.

However I'm not maintaing 1.4 patches anymore.
The patch is applicable only to the older spandsp releases. (spandsp-0.0.4pre18 and spandsp-0.0.5pre4)

Best regards
Daniel.
By: Leif Madsen (lmadsen) 2010-01-11 14:20:14.000-0600

To those requesting backports: All features will only go into trunk -- no existing branches (i.e. 1.2, 1.4, 1.6.0, 1.6.1, or 1.6.2) will receive features added to them. Requesting backports for this (or any other functionality) on the issue tracker is inappropriate and not the correct forum for that.

dafe_von_cetin: the next step is likely to get this onto reviewboard (http://reviewboard.asterisk.org) and have developers review this code. You will likely get a bunch of feedback about how to move this issue forward (either code changes, formatting changes, etc...)

Once the development community is satisfied with the overall approach and coding then it will be merged into trunk, and then released along with the next branching from trunk (whether that be Asterisk 1.8, 1.10, etc...).

Thanks!
By: Mina (rnbguy) 2010-01-13 04:29:53.000-0600

works like a charm sending t38 faxes, how are you guys getting faxdetect to work on sip so that faxes can be sent from ata > asterisk > zap

or is this feature not possible with this patch?
By: Daniel Ferenci (dafe_von_cetin) 2010-01-13 04:53:49.000-0600

Hi,

irroot sent me such feature in private mail conversation.
Please try to contact him and ask him for it.

Daniel.
By: Mina (rnbguy) 2010-01-13 06:14:18.000-0600

could i please get his or your email Daniel. so i may obtain the feature, or please email me the feature or email conversation:

mina.moussa@hotmail.com
By: Grigoriy Puzankin (boroda) 2010-01-13 06:49:12.000-0600

Why not to make this feature open for others?
By: Daniel Ferenci (dafe_von_cetin) 2010-01-13 07:52:31.000-0600

Hi,

I'm not against publishing it at all.
But it is just not mine code. I don't feel allowed to publish somebody's else
code without his permission.
All I can do is to contact irroot.

Best regards
Daniel.
By: Mina (rnbguy) 2010-01-13 08:36:51.000-0600

thank you.
By: Grigoriy Puzankin (boroda) 2010-01-13 08:59:06.000-0600

To dafe_von_cetin: Sorry, I was thinking about irroot when asked about opening the code. It would be great if you can ask irroot about it.
By: Leif Madsen (lmadsen) 2010-01-13 08:59:20.000-0600

This won't do what you want? (per sip.conf.sample)

; FAX detection will cause the SIP channel to jump to the 'fax' extension (if it exists)
; when a CNG tone is detected on an incoming call.
;
; faxdetect = yes              ; Default false
By: Mina (rnbguy) 2010-01-14 06:43:04.000-0600

lmadsen: does that feature exist for 1.4.20.1?

dafe_von_cetin(daniel): im getting this erro:
Peer needs to have T.38 disabled
By: Leif Madsen (lmadsen) 2010-01-14 06:55:24.000-0600

rnbguy: I'm not sure -- check sip.conf.samples for your version.

This is a NEW FEATURE -- it is NOT supported on anything but Asterisk trunk. Backports may be all well and good if the author is willing to support them, but new features should always be tested and reported HERE against trunk. Testing backports and reporting them here isn't very productive to moving this into trunk.
By: Daniel Ferenci (dafe_von_cetin) 2010-01-14 08:11:11.000-0600

Hi everyone,

yesterday I've posted this patch to review board.
https://reviewboard.asterisk.org/r/459/

to lmadsen:
I hope I followed all the instructions you gave me and I found on review board. However I dind't get any review request mail to my asterisk-dev inbox. I applogize in advance if I did something wrong. May you please check?
Thank you in advance.

I had to hack into post-review script since at the begging I was not able to use the application. I checked out asterisk as instructed by http://www.asterisk.org/developers/get-source from
"svn checkout http://svn.digium.com/svn/asterisk/trunk asterisk"
However review borad server denied such repository as unknown.
After enabling debug I found that review board server requires
"http://svn.asterisk.org/svn/asterisk/". So I made check out from that link.
Still got the error. Then after some debugging I found that svn info (used by script) returned the repository path without trailing slash. So I had to hard code "http://svn.asterisk.org/svn/asterisk/" into script.
Did I miss something? Why it was so tricky?

I appologize for putting this memo into obiously wrong forum but yet I don't know whom to address those words.
Thank you for understaning.

Daniel.
By: Niccolò Belli (darkbasic) 2010-01-14 08:20:25.000-0600

Yeah! I hope to see it merged soon! Next step is transparent GW :)
Keep up the good work!
By: Anton Verevkin (averevkin) 2010-01-14 08:52:38.000-0600

While the programmers are busy implementing transparent GW, get the 1.6.2 patch from a sysadmin :)

asterisk-1.6.2-faxgw.patch is a modified version of t38-gw-r229603.patch which reflects the changes in 1.6.2 data structures.

It compiles with my asterisk-1.6.2.0~rc7 on Debian and runs well with spandsp 0.0.6~pre12-1 from Debian repository.

Anton
By: Leif Madsen (lmadsen) 2010-01-14 09:03:05.000-0600

dafe_von_cetin: unfortunately I'm not sure why that was so hard -- I think there are better ways of posting to reviewboard now than using that script, but obviously some documentation needs to be updated somewhere -- I've not used reviewboard yet (in terms of posting reviews there) so I'm at a bit of a loss. I'd suggest you ask the same questions you asked here to the asterisk-dev list as I believe we should get the resolved.

As for your posting to the asterisk-dev list, I didn't see it go through, so it appears something may have failed to trigger that. Checking on IRC in #asterisk-dev might also be a useful exercise as a lot of developers hang out there.

Sorry I couldn't be of more assistance.
By: Anton Verevkin (averevkin) 2010-01-14 09:05:18.000-0600

However FaxGateway application has some drawbacks like inability to transmit ring signal and failing to drop the call if the calling party decides to cancel it before it was answered (this by the way leads to PRI lines not being freed forever).

Therefore I decided to go further and make a hook to app_fax code from the Dial application. _This_is_not_a_transparent_gateway_, it's just a slightly more convenient way to make calls.

Well, if you take the asterisk-1.6.2-faxgw-dial.patch it will modify app_fax, app_dial and features.c in order to allow calling the function in app_fax from app_dial.

What it makes is a 'b' parameter to Dial application which stands for 'Bridging' and uses the Dial application code to dial and right after the calling party answers it switches to app_fax code that makes the audio bridging and t.38 gatewaying.

Nevertheless as this is not a transparent gateway, some functions like blind/operator transfer or voice recording do not work. Just do not use the 'b' parameter to your Dial application and it will get back to the default code that has all that.

Good luck.
Anton.
By: nenadr (nenadr) 2010-01-15 00:05:44.000-0600

averevkin: is there any place I can download asterisk-1.6.2-faxgw-dial.patch for testing, since it is removed fromhere because of policy rules (or can you email me patch to nenadr@snr.rs) ?
By: Gentian Bajraktari (gentian) 2010-01-15 01:43:30.000-0600

averevkin: if not possible to download it from somewhere, please also send it to my email voipstar@gmail.com
By: Daniel Ferenci (dafe_von_cetin) 2010-01-15 02:57:07.000-0600

Hi,

averevkin: please send me the patch I and will create trunk version out of it.
daniel (dot) ferenci (at) gmail (dot) com
Then I will publish it here.

lmadsen:
Yet I got no reaction on asterisk-dev, thus I made you a reviewer of my review post. However I want to check #asterisk-dev as well.
By: Niccolò Belli (darkbasic) 2010-01-15 05:39:07.000-0600

averevkin: darkbasic4 [at} gmail {dot] com

Thank you :)
By: singler (singler) 2010-01-15 06:13:16.000-0600

averevkin, may I get 1.6.2 patch too? singler -at- mail -dot- lt

Thanx in advance :)
By: Anton Verevkin (averevkin) 2010-01-15 10:37:07.000-0600

Yesterday I have uploaded the patches here as attachments but they still have License Pending status, so they will be available here soon.

I have sent the patches to everyone above. And I have also put them on my server:
verevkin.it/download/asterisk-1.6.2-faxgw.patch
verevkin.it/download/asterisk-1.6.2-faxgw-dial.patch

And for those very lazy here are the Debian binaries that I have patched and comiled myself:
verevkin.it/download/asterisk-config_1.6.2.0~rc7-1_all.deb
verevkin.it/download/asterisk_1.6.2.0~rc7-1_i386.deb

Good Luck.
Anton.
By: klaus3000 (klaus3000) 2010-01-15 11:30:22.000-0600

I wonder why t38-gatewaying is implemented as application. A normal scenario works like this: call comes from PSTN (DAHDI) and is sent to SIP (with Dial()). During call routing I usually do not know if the costumer uses the SIP account as voice or fax line.

Thus, detection of fax tones, reINVITE to t38 and fax-gatewaying must work transparently somewhere inside Dial() function. OF course it would be nice to have Dial-options to change t38-gatewaying behavior (disable, force, reinvite as caller, reinvite as callee, reinvite as caller or callee)
By: Anton Verevkin (averevkin) 2010-01-15 11:35:14.000-0600

klaus3000: You should not really know whether this call is voice or fax. Just use the FaxGateway application instead of Dial - it will work for both voice and fax.


By: Dmitry Andrianov (dimas) 2010-01-15 11:37:52.000-0600

moe properly, gateway functionality should be embedded into Dial application.
dafe_von_cetin already discussed that on -dev list some time ago IIRC.
By: Leif Madsen (lmadsen) 2010-01-15 13:24:33.000-0600

dafe_von_cetin: ya I saw the review go up. You'll just have to be patient for now until a developer has the time and resources to review it. Thanks for posting it!
By: Daniel Ferenci (dafe_von_cetin) 2010-01-19 06:00:25.000-0600

Hi all,

I'm publishing averevkin's gw-dial patch (t38-gw-dial-r240716.patch) in trunk version.
Thank you arevkin.
It is not tested. Handle with care.
I don't mean to send it for review unless the first patch is submitted to trunk.

Best regards
Daniel.
By: Leif Madsen (lmadsen) 2010-01-22 06:54:04.000-0600

FYI per IRC:

<snuff-work> i was just wondering with your new 'res_fax' stuff.. what would need to happen if ppl wanted to use the t38 gateway functionality in (13405)
<kpfleming> it's totally separate at this point
<kpfleming> once res_fax and res_fax_spandsp are merged, we have an open task to start designing how we want to do gatewaying the *right* way, post that for community input and criticism, then get it implemented
<kpfleming> the implementation will probably use some (or most) of the code from 13405, but wrapped in a different sort of object
<snuff-work> ah k good to know
<kpfleming> we'd like to have that all completed in a couple of months, so it can be part of 1.8
By: Daniel Ferenci (dafe_von_cetin) 2010-01-26 09:00:57.000-0600

Hi,

thank you for info.
Neither I get any reviews for gateway patch on reviewboard.
It seems any further development in this particular patch is not very reasonable.

Best regards
Daniel.
By: Mina (rnbguy) 2010-01-26 16:52:02.000-0600

sorry to repost this question but im still unable to fix this issue:

Peer needs to have T.38 disabled
By: klaus3000 (klaus3000) 2010-03-05 09:44:12.000-0600

Hi! I tested asterisk-1.6.2-faxgw.patch with asterisk-1.6.2.5. Building is OK, but it does not work. I tried several scenarios but none of them worked:

SIP(t38pt_udptl=no)--->Asterisk application FaxGateway-->SIP(t38pt_udptl=yes):
Callee sends reINVITE, after 5 seconds the reINVITE is rejected with 488.

DAHDI--->Asterisk application FaxGateway-->SIP(t38pt_udptl=yes):
Callee sends reINVITE. AST_CONTROL_T38_PARAMETERS(24) is sent to dahdi_indicate which returns -1 and the DAHDI channel is hangup. After 5 seconds the reINVITE is rejected with 488 followed by a BYE.

Thus is really somebody using on of the above patches sucessfully?
By: Max Molchanov (censo) 2010-03-05 09:56:37.000-0600

Hi there. I've tested the patch as well (thanks a lot to its author) and faced the same issue(t.38 reinvite, 5 seconds and '488 not acceptable'). This annoying problem existed before patch and hopefully will be fixed under https://issues.asterisk.org/view.php?id=16793 or https://issues.asterisk.org/view.php?id=16327

With the t.38 gateway patch, it starts gateway application, but due to the mentioned bug, it disconnects in 5 seconds.

Just after re-invite:
[Feb 26 02:53:51] DEBUG[3949] chan_sip.c: Trying to put 'SIP/2.0 200' onto UDP socket destined for x.x.x.x:5105
[Feb 26 02:53:51] DEBUG[3901] chan_sip.c: Stopping retransmission on
...
[Feb 26 02:53:51] DEBUG[3949] channel.c: Set channel SIP/998700493116-00000003 to write format slin
[Feb 26 02:53:51] DEBUG[3949] channel.c: Set channel SIP/998700493116-00000003 to read format slin
...
[Feb 26 02:53:51] DEBUG[3949] dsp.c: Setup tone 1100 Hz, 500 ms, block_size=160, hits_required=21
...
[Feb 26 02:53:51] DEBUG[3949] app_fax.c: Bridging started chan SIP/998700493116-00000003 peer SIP/568181989641-0000
0004
By: klaus3000 (klaus3000) 2010-03-05 14:19:54.000-0600

AFAIS this 5 seconds make sense. It is ok to not wait longer than 5 seconds. Hte problem is related to the handling of the AST_CONTROL_T38_PARAMETERS control frame.

E.g. if a reINVITE to T38 is received by Asterisk, then Asterisk will send a reINVITE on the bridged channel. If this reINVITE is rejected with 488, FaxGateway will forward the AST_T38_REFUSED refused message to the incomgin channel, whichh will refuse to. The proper action by FaxGateway would be to intercept this AST_T38_REFUSED and fake a AST_T38_NEGOTIATED. I implemented this and now FaxGateway enters next step (but still to debug).

Further, if a channel does not support T.38 (e.g. DAHDI, IAX...) and receives an AST_T38_REQUEST_NEGOTIATE indication, it should response AST_T38_REFUSED to initiate gatewaying in FaxGateway.

more to come next week .... :-)
By: Max Molchanov (censo) 2010-03-05 16:08:19.000-0600

klaus3000, thank you for clarification. But it looks for me that channels like DAHDI should not know about T38 if they do not support it. Can't we catch an event where dahdi_indicate(AST_CONTROL_T38_PARAMETERS) returns -1 and act appropriately, seeing that t38 is not supported? This approach will support any channel that returns -1 on t38 negotiate automatically.
By: klaus3000 (klaus3000) 2010-03-06 02:54:27.000-0600

good idea, I will take a look at it.
By: klaus3000 (klaus3000) 2010-03-07 17:01:55.000-0600

I now managed to have t38 gatewaying working for DAHDI->SIP. I also tried SIP->SIP but it fails due to frame timing. Current sending of voice frames is triggered by received voice frames - thus if the non-t38 client (Asterisk using SendFAX) does not send RTP then the t38-gateway also does not send voice frames.

I tried to modify the event loop to regularly check t38_gateway_tx() for new voice data to send, but t38_gateway_tx() always responds with a full voice-data bufer even it is called every ms.

So, does anybody know how t38_gateway_tx() works (no documentation :-()?

What is the preferred way to decouple frame generation from RTP reception (I think the t38-gateway should send RTP every 20ms (or whatever the frame rate is) also if it does not receive audio)?
By: Anton Verevkin (averevkin) 2010-03-08 08:12:42.000-0600

Just an idea. The end stations usually send frames regularly unless 'Voice activity detection' is on. So if you just turn this parameter off on the originating station, it will send voice frames even when the caller is silent. And these frames will trigger the gateway.
By: klaus3000 (klaus3000) 2010-03-08 09:00:13.000-0600

This is especially what I want to avoid. I do not want to rely on the other side to give timing ...
By: Mina (rnbguy) 2010-03-09 05:53:08.000-0600

can anyone help id this issue:

[Mar  9 17:57:11] DEBUG[11127] dsp.c: tone 1100, Ew=2906291064.000000, Et=4714905600.000000, s/n=      1.61
[Mar  9 17:57:11] DEBUG[11127] dsp.c: tone 1100, Ew=3128581336.000000, Et=5795307520.000000, s/n=      1.17
[Mar  9 17:57:11] DEBUG[11127] dsp.c: tone 1100, Ew=3088398368.000000, Et=4607426560.000000, s/n=      2.03
[Mar  9 17:57:11] DEBUG[11127] dsp.c: tone 1100, Ew=6986587392.000000, Et=9664716800.000000, s/n=      2.61
[Mar  9 17:57:11] DEBUG[11127] dsp.c: tone 1100, Ew=3098322160.000000, Et=5934530560.000000, s/n=      1.09
[Mar  9 17:57:11] DEBUG[11127] dsp.c: tone 1100, Ew=3110141736.000000, Et=3890913280.000000, s/n=      3.98
[Mar  9 17:57:11] DEBUG[11127] dsp.c: tone 1100, Ew=3084487360.000000, Et=3478036480.000000, s/n=      7.84
[Mar  9 17:57:11] DEBUG[11127] dsp.c: tone 1100, Ew=3079196352.000000, Et=3754598400.000000, s/n=      4.56
[Mar  9 17:57:11] DEBUG[11127] dsp.c: tone 1100, Ew=3079949768.000000, Et=3657031680.000000, s/n=      5.34
[Mar  9 17:57:11] DEBUG[3273] chan_sip.c: change_t38_state chnaged state to: 4
[Mar  9 17:57:11] DEBUG[3273] chan_sip.c: change_t38_state chnaged state to: 5
[Mar  9 17:57:11] NOTICE[11127] app_faxgateway.c: write error -1
[Mar  9 17:57:11] DEBUG[11127] app_faxgateway.c: Stop bridging frames. [ 0,4]
[Mar  9 17:57:11] NOTICE[11127] app_faxgateway.c: Doing T.38 gateway [ 0,4]
[Mar  9 17:57:11] NOTICE[11127] app_faxgateway.c: T.38 gateway started
[Mar  9 17:57:11] DEBUG[11127] app_faxgateway.c: FLOW T.38 Tx     0: indicator no-signal
[Mar  9 17:57:11] DEBUG[11127] app_faxgateway.c: FLOW T.38 Tx     1: indicator no-signal
[Mar  9 17:57:11] DEBUG[11127] app_faxgateway.c: FLOW T.38 Tx     2: indicator no-signal
[Mar  9 17:57:11] NOTICE[11127] app_faxgateway.c: FaxGateway exit with ANSWER
By: klaus3000 (klaus3000) 2010-03-09 07:29:58.000-0600

Hi! I justed uploaded a new patch:

This patch is for 1.6.2.5 - I tried with trunk too but I did not managed to get anything working with trunk - not even T38 passthrough. Further trunk has a new fax backend, thus the patch must be ported to this new frontend.

The new patch is based on asterisk-1.6.2-faxgw.patch. It adds some handling of T.38 control frames to actually trigger the t38-gateway. I also reworked the code for better readability. Integration in Dial() was skipeed as IMO either it should be standalone or directly inplemented in Dial().

I tested:

1. FerrariFaxServer<--DAHDI-->Asterisk<--SIP/T.38-->SPA3102-5.1.10
2. Hylafax/IAXModem<---IAX--->Asterisk<--SIP/T.38-->SPA3102-5.1.10

Both setups, in each case 10 pages in&out, worked.

The only thing I recognized was that fax transmission is always non-ECM (although the clients are known to support ECM). Maybe the T38 negotiation parameters needs to be adopted  --> help appreciated.
By: dalepbx (dalepbx) 2010-03-13 10:37:21.000-0600

Hi,

i have tested klaus3000's patch with 1.6.2.5  and the following setup:

HP LJ 3200m Fax <-fxs port-> Grandstream GXW4008 <-sip/t38-> Asterisk (Digium TE121) <-PRI/ISDN-> Some Canon Fax

The HP Fax is infamous for being unreliable to a point to be considered broken, even with pots pstn and 2 plain Fax machines. As we have far to many of them deployed at my company, it would be great if this could be a solid solution.

I get 10 pages transmitted correctly, but i receive a unsupported media type warning (see below). Now i am unsure if FaxGateway() is even used. Can someone please enlighten me on this?


Using SIP RTP CoS mark 5
 == Using SIP VRTP CoS mark 6
   -- Executing [001234512345@from-sip:1] FaxGateway("SIP/123-00000023", "DAHDI/g0/01234512345") in new stack
   -- Requested transfer capability: 0x00 - SPEECH
   -- Accepting call from '+1234512345' to '12345' on channel 0/18, span 1
   -- Executing [12345@from-pstn:1] FaxGateway("DAHDI/18-1", "SIP/123") in new stack
 == Using SIP RTP CoS mark 5
 == Using SIP VRTP CoS mark 6
[Mar 13 17:08:19] WARNING[19692]: chan_sip.c:8300 process_sdp: Unsupported SDP media type in offer: image 5012 udptl t38

< some time passes (and 10 pages are transmitted) >

Auto fallthrough, channel 'DAHDI/18-1' status is 'Unknown'
   -- Hungup 'DAHDI/18-1'
   -- Channel 0/1, span 1 got hangup request, cause 16
   -- Channel 0/1, span 1 received AOC-E charging 2 units
   -- Hungup 'DAHDI/1-1'
By: klaus3000 (klaus3000) 2010-03-14 07:21:21

There are several possibilities to verify if T.38 is used, for example:
A) activate channel debugging "core set debug channel all". Then you should see CONTROL frames (for T.38 negotiation) and the MODEM frames in the log file (activate "full" logging of debug messages in logger.conf)

B) watch the SIP signalling: "sip set debug on". Then you will see the reINVITE to T.38. If the reINVITE gets answered with 200 OK then you should have T.38 transmission.

C) watch RTP and UDPTL packets: "updtl set debug on", "rtp set debug on". After T.38 reINVITE the RTP logging changes to UDPTL logging
By: klaus3000 (klaus3000) 2010-03-15 13:36:06

I have just uploaded a new version of the T38gateway patch (asterisk-1.6.2.6-t38gw-dial-patch.txt):
- works now with spandsp 0.0.6pre17 too
- included Dial(,,b) (works better than FaxGateway() application)
By: Niccolò Belli (darkbasic) 2010-03-18 12:43:49

Awesome, thank you!!
By: Johann Steinwendtner (steinwej) 2010-03-19 06:26:40

Hi, the Dial() command approach is IMO more flexible than the FaxGateway() application. Further,the FaxGateway() app. is not realy useable, as the caller looses the control over the channel.
Does the CNG tone detection work ? If it is detected, I think it is better to send the T38 indication directly to the active channel.
Good work !
By: dalepbx (dalepbx) 2010-03-19 09:37:09

Thanks for the debugging info klaus3000,

unfortunately it seems that no T.38 is used. I have testet both your old Patch and the one for 1.6.2.6

Method a) throws the following:

*CLI> << [ TYPE: Control (4) SUBCLASS: Unknown control '15' (15) ] [CAPI/ISDN1#02/01234123456-5]
<< [ TYPE: Control (4) SUBCLASS: Ringing (3) ] [SIP/305-0000000a]
[Mar 19 15:29:48] NOTICE[2755]: chan_capi_supplementary.c:144 new_ccbsnr_id: No peerlink found to set CCBS/CCNR linkage ID.
<< [ TYPE: Control (4) SUBCLASS: Unknown control '14' (14) ] [CAPI/ISDN1#02/01234123456-5]
<< [ TYPE: Control (4) SUBCLASS: Ringing (3) ] [CAPI/ISDN1#02/01234123456-5]
<< [ TYPE: Null Frame (5) SUBCLASS: N/A (0) ] [SIP/1500-00000009]
<< [ TYPE: Control (4) SUBCLASS: Answer (4) ] [SIP/305-0000000a]
<< [ TYPE: Control (4) SUBCLASS: Answer (4) ] [CAPI/ISDN1#02/01234123456-5]
<< [ TYPE: Control (4) SUBCLASS: T38_Parameters/Negotiation Requested (24) ] [SIP/1500-00000009]
<< [ TYPE: Control (4) SUBCLASS: Unknown control '20' (20) ] [SIP/1500-00000009]
<< [ TYPE: Control (4) SUBCLASS: T38_Parameters/Refused (24) ] [CAPI/ISDN1#02/01234123456-5]
<< [ TYPE: Null Frame (5) SUBCLASS: N/A (0) ] [SIP/1500-00000009]
<< [ HANGUP (NULL) ] [CAPI/ISDN1#01/123456-6]

Method c) also shows nothing of UDPTL.

I am very grateful for any help...
By: klaus3000 (klaus3000) 2010-03-21 16:34:05

@steinwej: Yes, Dial(,,b) is better as pre-answer phase is better handled by Dial as by FaxGAteway.
Fax-ToneDetection always worked in my scenarios. But I do not remember now if it was CED or CNG which actually triggered the reINVITE. If enable "full" logging (logger.conf) and set a high debug level, you should see status of tone detection in the logs.

Why is it better to send T.38 request to the "active" channel instead of "inactive"? Actually I do not see a difference. Just because a tone is detected on a channel does not mean that this channel can handle T.38. Maye we could also send on both channels?

Probably the fastet approach would be to put technology information directly into the gateway application. If the application knows that all channels except SIP can not handle T.38, the gateway application could be started faster.
By: klaus3000 (klaus3000) 2010-03-21 16:41:19

@dalepbx: The trace is strange. There is one CAPI channel and 2 SIP channels.

Regarding CAPI. The non-T.38 channel must not hang up the channel on a T.38 negotiating request - it should signal "REFUSE" back to the core. Then the gateway application will trigger the gatewaying.

In my patch you will find changes for chan_sip and chan_iax which do this. So I guess you have to extend the "indicate" function of chan_capi to behave similar.
By: dalepbx (dalepbx) 2010-03-25 05:24:15

I have modified my test setup to rule out problems with chan_capi:

Fax<->ATA<-SIP->Asterisk<-SIP->ATA<->Fax

Configuration and debug output can be found here: http://pastebin.org/122582

Unfortunately it doesn't work either and the sip trace looks rather strange. I am aware that this is not a support forum, but perhaps someone can make sense out of my output and it could be of some use for refining T.38 gatewaying.
By: klaus3000 (klaus3000) 2010-03-25 05:41:50

@dalepbx:
1. in your setup, if both ATAs support T.38, then the t38-gateway will not be activated as there is no need for it.
2. in your setup, Asterisk offloads RTP by sending reINVITEs, so that the RTP stream will be directly between the ATAs. to prevent the reINVITEs set canreinvite=no in sip.conf
By: tom m (tom_m) 2010-04-20 05:18:16

Hi,

Can anybody please point out the best way to handle voice (features like transfer etc) and t.38 gatewaying (PSTN<->SIP) in the dial plan?

Version info:
Asterisk 1.6.2.6
Dahdi 2.2.1
Dahdi tool 2.2.1
libss7 version: 1.0.2 -Sangoma / libss7 version: SVN-branch-1.0-r283M -Digium
WANPIPE Release: 3.5.8 -Sangoma

When the call is placed, I do not know whether I am dialing for voice or fax endpoints, so I need to dial with the b option in case t.38 bridging is required.
exten => _X.,n,Dial(DAHDI/group1/${EXTEN},,b)

According to the documentation (and my experience) call features like transfer are lost when I use the b option.

> b: Bridge T.38 Fax. This disables other call features that are usually
>  available after the calling party answers. This includes transfer, call
> and DTMF recording, etc.

The transfer of a voice call leads to a hangup.

I can reproduce this wit both libss7 versions, and different E1 hardware.

Am I missing something? How can I get around this? Application FaxGateway cause same problem. I would like to prepare for t.38 bridging in case I have a fax call on hand, but not lose voice call transfer capability (or other voice features) if the call tuns out to be a voice call.

Here’s the associated debug output for a voice call that gets hungup on attended transfer.


   -- Executing [${CALLED_NUMBER}@dial:10] Dial("SIP/sip_proxy1-000012ac", "Dahdi/group1/${CALLED_NUMBER},,b") in new stack
   -- Called group1/${CALLED_NUMBER}
<< [ TYPE: Null Frame (5) SUBCLASS: N/A (0) ] [DAHDI/120-1]
<< [ TYPE: Null Frame (5) SUBCLASS: N/A (0) ] [DAHDI/120-1]
<< [ TYPE: Null Frame (5) SUBCLASS: N/A (0) ] [DAHDI/120-1]
.
.
<< [ TYPE: Null Frame (5) SUBCLASS: N/A (0) ] [DAHDI/120-1]
<< [ TYPE: Null Frame (5) SUBCLASS: N/A (0) ] [DAHDI/120-1]
<< [ TYPE: Null Frame (5) SUBCLASS: N/A (0) ] [DAHDI/120-1]
<< [ TYPE: Control (4) SUBCLASS: Unknown control '15' (15) ] [DAHDI/120-1]
   -- DAHDI/120-1 is proceeding passing it to SIP/sip_proxy1-000012ac
<< [ TYPE: Control (4) SUBCLASS: Ringing (3) ] [DAHDI/120-1]
   -- DAHDI/120-1 is ringing
Unhandled optional parameter 0x2d 'Unknown'
[0x0 0x5a ]
Unhandled optional parameter 0x39 'Parameter Compatibility Information'
[0x2d 0x40 0x80 ]
<< [ TYPE: Control (4) SUBCLASS: Answer (4) ] [DAHDI/120-1]
   -- DAHDI/120-1 answered SIP/sip_proxy1-000012ac
<< [ TYPE: Null Frame (5) SUBCLASS: N/A (0) ] [SIP/sip_proxy1-000012ac]
<< [ TYPE: Null Frame (5) SUBCLASS: N/A (0) ] [SIP/sip_proxy1-000012ac]
<< [ TYPE: Null Frame (5) SUBCLASS: N/A (0) ] [SIP/sip_proxy1-000012ac]
>> [ TYPE: Null Frame (5) SUBCLASS: N/A (0) ] [DAHDI/120-1]
<< [ TYPE: Null Frame (5) SUBCLASS: N/A (0) ] [SIP/sip_proxy1-000012ac]
>> [ TYPE: Null Frame (5) SUBCLASS: N/A (0) ] [DAHDI/120-1]
<< [ TYPE: Null Frame (5) SUBCLASS: N/A (0) ] [SIP/sip_proxy1-000012ac]
>> [ TYPE: Null Frame (5) SUBCLASS: N/A (0) ] [DAHDI/12-1]
Unhandled optional parameter 0x2c 'Generic Notification Indication'
[0xf9 ]I>
Unhandled optional parameter 0x39 'Parameter Compatibility Information'
[0x2c 0x50 0x80 ]
<< [ TYPE: Control (4) SUBCLASS: Unknown control '14' (14) ] [DAHDI/120-1]
>> [ TYPE: Control (4) SUBCLASS: Unknown control '14' (14) ] [SIP/sip_proxy1-000012ac]
   -- Hungup 'DAHDI/120-1'
 == Spawn extension (com_hangup, h, 16) exited non-zero on 'SIP/sip_proxy1-000012ac'


By: klaus3000 (klaus3000) 2010-04-20 08:11:16

no, you do not miss anything.

> b: Bridge T.38 Fax. This disables other call features that are usually
> available after the calling party answers. This includes transfer, call
> and DTMF recording, etc.

This means exactly what is written. It just does not work. If you want to have all features of Dial() when using the 'b' option, the whole T.38-gatewaying code needs to be implemented directly into the Dial application.
By: Joao Carvalho (foxfire) 2010-05-06 04:11:44

hello

I am trying to make your patch work with the following setup
ATA -> SIP/T.38 -> Asterisk -> DAHDI -> FAX  

The ATA is an Grandstream HT502 with the latest Firmware , tested others.
asterisk is 1.6.2.6 with the latest dahdi and libpri.

Everything seem to go well, but when the connections dies before the FAX is transmitted.


here is a part of the console log :

-- (12 headers 0 lines) ---
voip*CLI>                  
<--- SIP read from UDP:10.50.250.51:5060 --->
SIP/2.0 200 OK                              
Via: SIP/2.0/UDP 10.50.250.50:5060;branch=z9hG4bK1b45af35;rport=5060
From: <sip:300400001@10.50.250.50>;tag=as733287f0                  
To: "foxfire" <sip:foxfire@10.50.250.50>;tag=1755182005            
Call-ID: 1105754636-5060-3@10.50.250.51                            
CSeq: 102 INVITE                                                    
Contact: <sip:foxfire@10.50.250.51:5060>                            
Supported: replaces, path, timer                                    
User-Agent: Grandstream HT-502  V1.1B 1.0.1.57                      
Session-Expires: 1800;refresher=uas                                
Require: timer                                                      
Allow: INVITE, ACK, OPTIONS, CANCEL, BYE, SUBSCRIBE, NOTIFY, INFO, REFER, UPDATE
Content-Type: application/sdp                                                  
Content-Length:   266                                                          

v=0
o=foxfire 8000 8001 IN IP4 10.50.250.51
s=SIP Call                            
c=IN IP4 10.50.250.51                  
t=0 0                                  
m=image 5004 udptl t38                
a=T38FaxVersion:0                      
a=T38MaxBitRate:9600                  
a=T38FaxRateManagement:transferredTCF  
a=T38FaxMaxBuffer:400                  
a=T38FaxMaxDatagram:1400              
a=T38FaxUdpEC:t38UDPFEC                

<------------->
--- (14 headers 12 lines) ---
Got T.38 offer in SDP in dialog 1105754636-5060-3@10.50.250.51
Capabilities: us - 0xc (ulaw|alaw), peer - audio=0x0 (nothing)/video=0x0 (nothing)/text=0x0 (nothing), combined - 0x0 (nothing)
Non-codec capabilities (dtmf): us - 0x1 (telephone-event), peer - 0x0 (nothing), combined - 0x0 (nothing)                      
Got T.38 Re-invite without audio. Keeping RTP active during T.38 session.                                                      
set_destination: Parsing <sip:foxfire@10.50.250.51:5060> for address/port to send to                                          
set_destination: set destination to 10.50.250.51, port 5060                                                                    
Transmitting (no NAT) to 10.50.250.51:5060:                                                                                    
ACK sip:foxfire@10.50.250.51:5060 SIP/2.0                                                                                      
Via: SIP/2.0/UDP 10.50.250.50:5060;branch=z9hG4bK61705ec3;rport                                                                
Max-Forwards: 70                                                                                                              
From: <sip:300400001@10.50.250.50>;tag=as733287f0                                                                              
To: "foxfire" <sip:foxfire@10.50.250.50>;tag=1755182005                                                                        
Contact: <sip:300400001@10.50.250.50>                                                                                          
Call-ID: 1105754636-5060-3@10.50.250.51                                                                                        
CSeq: 102 ACK                                                                                                                  
User-Agent: "X-Lite release 1105x"                                                                                            
Content-Length: 0                                                                                                              


---
UDPTL (SIP/foxfire): packet to 10.50.250.51:5004 (type 0, seq 0, len 8)
UDPTL (SIP/foxfire): packet from 10.50.250.51:5004 (type 0, seq 0, len 6)
UDPTL (SIP/foxfire): packet from 10.50.250.51:5004 (type 0, seq 0, len 6)
UDPTL (SIP/foxfire): packet from 10.50.250.51:5004 (type 0, seq 0, len 10)
UDPTL (SIP/foxfire): packet to 10.50.250.51:5004 (type 0, seq 1, len 8)  
UDPTL (SIP/foxfire): packet to 10.50.250.51:5004 (type 0, seq 2, len 13)  
UDPTL (SIP/foxfire): packet to 10.50.250.51:5004 (type 0, seq 3, len 20)  
UDPTL (SIP/foxfire): packet to 10.50.250.51:5004 (type 0, seq 4, len 20)  
UDPTL (SIP/foxfire): packet to 10.50.250.51:5004 (type 0, seq 5, len 20)  
UDPTL (SIP/foxfire): packet to 10.50.250.51:5004 (type 0, seq 6, len 27)  
UDPTL (SIP/foxfire): packet to 10.50.250.51:5004 (type 0, seq 7, len 27)  
UDPTL (SIP/foxfire): packet to 10.50.250.51:5004 (type 0, seq 8, len 27)  
UDPTL (SIP/foxfire): packet to 10.50.250.51:5004 (type 0, seq 9, len 34)  
UDPTL (SIP/foxfire): packet to 10.50.250.51:5004 (type 0, seq 10, len 34)
UDPTL (SIP/foxfire): packet to 10.50.250.51:5004 (type 0, seq 11, len 34)
UDPTL (SIP/foxfire): packet to 10.50.250.51:5004 (type 0, seq 12, len 34)
UDPTL (SIP/foxfire): packet to 10.50.250.51:5004 (type 0, seq 13, len 34)
UDPTL (SIP/foxfire): packet to 10.50.250.51:5004 (type 0, seq 14, len 34)
UDPTL (SIP/foxfire): packet to 10.50.250.51:5004 (type 0, seq 15, len 34)
UDPTL (SIP/foxfire): packet to 10.50.250.51:5004 (type 0, seq 16, len 34)
UDPTL (SIP/foxfire): packet to 10.50.250.51:5004 (type 0, seq 17, len 34)
UDPTL (SIP/foxfire): packet to 10.50.250.51:5004 (type 0, seq 18, len 34)
UDPTL (SIP/foxfire): packet to 10.50.250.51:5004 (type 0, seq 19, len 34)
UDPTL (SIP/foxfire): packet to 10.50.250.51:5004 (type 0, seq 20, len 34)
UDPTL (SIP/foxfire): packet to 10.50.250.51:5004 (type 0, seq 21, len 34)
voip*CLI>                                                                  
<--- SIP read from UDP:10.50.250.51:5060 --->                              
BYE sip:300400001@10.50.250.50 SIP/2.0                                    
Via: SIP/2.0/UDP 10.50.250.51:5060;branch=z9hG4bK1292189383;rport          
From: "foxfire" <sip:foxfire@10.50.250.50>;tag=1755182005                  
To: <sip:300400001@10.50.250.50>;tag=as733287f0                            
Call-ID: 1105754636-5060-3@10.50.250.51                                    
CSeq: 22 BYE                                                              
Contact: <sip:foxfire@10.50.250.51:5060>                                  
Max-Forwards: 70                                                          
Supported: replaces, path, timer                                          
User-Agent: Grandstream HT-502  V1.1B 1.0.1.57                            
Allow: INVITE, ACK, OPTIONS, CANCEL, BYE, SUBSCRIBE, NOTIFY, INFO, REFER, UPDATE
Content-Length: 0                                                              


thoughts anyone ?
By: klaus3000 (klaus3000) 2010-05-06 04:24:05

@foxfire: The log does not inidicate any reason why GRandstream hung up.
It would be more useful if you can provide a tcpdump/wireshark trace (pcap file) of the complete call (including sip, rtp and udptl)
By: Joao Carvalho (foxfire) 2010-05-06 05:11:20

hello klaus,
i attached a tcpdump file.
i used the "-s 65535" option so it should load into wireshark without any problem.

by the i sent the FAX to another asterisk receiving it through TDM i got this on the other side :

   -- Channel 0/28, span 1 got hangup request, cause 16
[May  6 10:58:25] WARNING[26342]: app_fax.c:178 phase_e_handler: Error transmitting fax. result=49: The call dropped prematurely.
[May  6 10:58:25] WARNING[26342]: app_fax.c:764 transmit: Transmission error

If you need anything else please do not hesitate to ask.
By: klaus3000 (klaus3000) 2010-05-06 07:41:41

Looks like Grandsream gets confused about the T38 packets and closes the call. May Grandstream does not support forward error correction (FEC) mode (although it announces it in the SDP). Try redundancy mode in sip.conf, e.g:
t38pt_udptl = yes,redundancy,maxdatagram=400
By: Joao Carvalho (foxfire) 2010-05-06 09:00:38

yes,
i am able to send some now, some fail, i will now investigate further.
thank you
JC
By: Joao Carvalho (foxfire) 2010-05-10 04:18:42

hello
Sending FAX is now OK, without any problems. But i am having problems receiving. I have noticed that when i receive a FAX, T38 is not negotiated and the FAX passes using ulaw. Is there any way i can force the usage of T38. Also i am using dial with the b options , is there any difference to using the FaxGateway app instead ?
By: klaus3000 (klaus3000) 2010-05-10 06:41:19

@foxfire: There is no difference between incoming and outgoing fax, also no option to force T38 on a certain channel. IIRC the t38 bridge listens for CED and CNG on both channels and as soon as a tone is detected it triggers T38 initiation.

I never had any issues yet. Try to listen to the call if CED/CNG is available (e.g. use tcpdump to capture the call and then use wireshark to listen to the RTP streams)
By: Cédric Lemarchand (dafresh) 2010-05-12 08:09:48

hello,

Here is the context :

ATA Device (SPA3102, latest fw)

<== SIP/T38 (alaw, LAN 100Mbits) ==>

Asterisk 1.6.2.6-1 (squeezez) + patch  asterisk-1.6.2.6-t38gw-dial-patch.txt, libspandsp 0.0.6pre17

<== IAX (alaw, LAN 100Mbits) ==>

Asterisk 1.4.27.1 (XiVO)

<== DADHI (ISDN, T2) ==>

UDPTL is present, but faxes doesn't works as expected, seems the negotiation between modems fails :

[May 12 14:32:20] DEBUG[15730] app_fax.c: HDLC signal status is Carrier up (-2)
[May 12 14:32:20] DEBUG[15730] app_fax.c: Queued change - (0) ??? -> no-signal
[May 12 14:32:22] DEBUG[15730] app_fax.c: HDLC signal status is Carrier down (-1)
[May 12 14:32:23] DEBUG[15730] app_fax.c: HDLC signal status is Carrier up (-2)
[May 12 14:32:24] DEBUG[15730] app_fax.c: HDLC frame type DIS, CRC OK
[May 12 14:32:24] DEBUG[15730] app_fax.c: HDLC signal status is Carrier down (-1)
[May 12 14:32:27] DEBUG[15730] app_fax.c: HDLC signal status is Carrier up (-2)
[May 12 14:32:29] DEBUG[15730] app_fax.c: HDLC frame type DIS, CRC OK
[May 12 14:32:29] DEBUG[15730] app_fax.c: HDLC signal status is Carrier down (-1)
[May 12 14:32:32] DEBUG[15730] app_fax.c: HDLC signal status is Carrier up (-2)
[May 12 14:32:34] DEBUG[15730] app_fax.c: HDLC frame type DIS, CRC OK
[May 12 14:32:34] DEBUG[15730] app_fax.c: HDLC signal status is Carrier down (-1)
[May 12 14:32:34] DEBUG[15730] app_fax.c: Queued change - (0) no-signal -> v21-preamble
[May 12 14:32:35] DEBUG[15730] app_fax.c: HDLC underflow at 2
[May 12 14:32:36] DEBUG[15730] app_fax.c: HDLC frame type TSI - CRC good
[May 12 14:32:36] DEBUG[15730] app_fax.c: HDLC underflow at 2
[May 12 14:32:36] DEBUG[15730] app_fax.c: HDLC next is 0x0
[May 12 14:32:37] DEBUG[15730] app_fax.c: HDLC frame type DCS - CRC OK, sig end
[May 12 14:32:37] DEBUG[15730] app_fax.c: Queued change - (0) v21-preamble -> no-signal
[May 12 14:32:37] DEBUG[15730] app_fax.c: Queued change - (0) no-signal -> v17-14400-long-training
[May 12 14:32:37] DEBUG[15730] app_fax.c: HDLC underflow at 3
[May 12 14:32:37] DEBUG[15730] app_fax.c: HDLC next is 0x100
[May 12 14:32:37] DEBUG[15730] app_fax.c: HDLC shutdown
[May 12 14:32:41] DEBUG[15730] app_fax.c: Queued change - (0) v17-14400-long-training -> no-signal
[May 12 14:32:41] DEBUG[15730] app_fax.c: HDLC signal status is Carrier up (-2)
[May 12 14:32:42] DEBUG[15730] app_fax.c: HDLC frame type FTT, CRC OK
[May 12 14:32:42] DEBUG[15730] app_fax.c: HDLC signal status is Carrier down (-1)
[May 12 14:32:43] DEBUG[15730] app_fax.c: Queued change - (0) no-signal -> v21-preamble
[May 12 14:32:43] DEBUG[15730] app_fax.c: HDLC underflow at 8
[May 12 14:32:44] DEBUG[15730] app_fax.c: HDLC frame type TSI - CRC good
[May 12 14:32:44] DEBUG[15730] app_fax.c: HDLC underflow at 8
[May 12 14:32:44] DEBUG[15730] app_fax.c: HDLC next is 0x0
[May 12 14:32:45] DEBUG[15730] app_fax.c: HDLC frame type DCS - CRC OK, sig end
[May 12 14:32:45] DEBUG[15730] app_fax.c: Queued change - (0) v21-preamble -> no-signal
[May 12 14:32:46] DEBUG[15730] app_fax.c: Queued change - (0) no-signal -> v17-12000-long-training
[May 12 14:32:46] DEBUG[15730] app_fax.c: HDLC underflow at 9
[May 12 14:32:46] DEBUG[15730] app_fax.c: HDLC next is 0x100
[May 12 14:32:46] DEBUG[15730] app_fax.c: HDLC shutdown
[May 12 14:32:49] DEBUG[15730] app_fax.c: Queued change - (0) v17-12000-long-training -> no-signal
[May 12 14:32:49] DEBUG[15730] app_fax.c: HDLC signal status is Carrier up (-2)
[May 12 14:32:50] DEBUG[15730] app_fax.c: HDLC frame type FTT, CRC OK
[May 12 14:32:50] DEBUG[15730] app_fax.c: HDLC signal status is Carrier down (-1)
[May 12 14:32:51] DEBUG[15730] app_fax.c: Queued change - (0) no-signal -> v21-preamble
[May 12 14:32:52] DEBUG[15730] app_fax.c: HDLC underflow at 14
[May 12 14:32:52] DEBUG[15730] app_fax.c: HDLC frame type TSI - CRC good
[May 12 14:32:53] DEBUG[15730] app_fax.c: HDLC underflow at 14
[May 12 14:32:53] DEBUG[15730] app_fax.c: HDLC next is 0x0
[May 12 14:32:54] DEBUG[15730] app_fax.c: HDLC frame type DCS - CRC OK, sig end
[May 12 14:32:54] DEBUG[15730] app_fax.c: Queued change - (0) v21-preamble -> no-signal
[May 12 14:32:54] DEBUG[15730] app_fax.c: Queued change - (0) no-signal -> v27-2400-training
[May 12 14:32:54] DEBUG[15730] app_fax.c: HDLC underflow at 15
[May 12 14:32:54] DEBUG[15730] app_fax.c: HDLC next is 0x100
[May 12 14:32:54] DEBUG[15730] app_fax.c: HDLC shutdown
[May 12 14:32:59] WARNING[15730] app_fax.c: T38_FIELD_NON_ECM_SIG_END received at the end of HDLC data!
[May 12 14:32:59] DEBUG[15730] app_fax.c: Queued change - (0) v27-2400-training -> no-signal
[May 12 14:33:00] DEBUG[15730] app_fax.c: Queued change - (0) no-signal -> v21-preamble
[May 12 14:33:01] DEBUG[15730] app_fax.c: HDLC frame type DCN - CRC OK, sig end
[May 12 14:33:01] DEBUG[15730] app_fax.c: Queued change - (0) v21-preamble -> no-signal


Did i miss something ? Any ideas ?
By: Marek Cervenka (cervajs) 2010-05-20 10:32:27

for chan_ss7 is needed patch. like for chan_iax

my testing results are on
http://www.voip-info.org/wiki/view/Asterisk+T.38+Gateway
By: paleboy_nz (paleboy_nz) 2010-05-30 18:09:37

any chance of getting this patch converted for 1.4.30?
By: Niccolò Belli (darkbasic) 2010-06-22 05:46:29

How is the trasparent gatewaying implementation going? I REALLY REALLY hope to see it before the 1.8 merge window closes.
By: Marek Cervenka (cervajs) 2010-06-22 06:09:41

i'm running patch from klaus. works fine
http://www.voip-info.org/wiki/view/Asterisk+T.38+Gateway
By: Marek Cervenka (cervajs) 2010-06-22 07:20:21

uploaded patch asterisk-1.6.2.9-t38gw-dial.patch
(patch from klaus ported to 1.6.2.9)
By: Niccolò Belli (darkbasic) 2010-06-22 07:22:35

I meant: is trasparent gatewaying merged upstream?
By: Matt Watson (mwatson) 2010-06-24 21:56:06

I got the 1.6.2.9 patch up and running tonight, but having some mixed results.

My topology is: Sending Fax -> Cisco/Linksys SPA2102 ATA -> SIP -> Asterisk -> PRI -> PSTN

The sending fax I am testing with is a Ricoh Aficio 7001MP which is a big multifunction copier/fax/printer/etc.

I seem to have absolutely excellent results when faxing to myself (Out the PRI, back in the same PRI to Asterisk -> IAXmodem -> Hylafax). I can see T.38 happening on every call.

However getting mixed results when faxing to other numbers T.38 negotiation doesn't seem to always happen and best I can tell is that app_fax is not detecting the call is a fax. On the faxes to myself I see asterisk detecting the CED tones, when sending to other numbers it seems hit and miss about if it detects CED and I have yet to see it detect CNG.

Anybody else having similar issues?
By: klaus3000 (klaus3000) 2010-06-25 02:15:55

@mwatson: Strange. Do you have same results for sending to external and receiving from external fax machines?
By: Flavio Percoco Premoli (flaper87) 2010-06-26 09:33:38

@mwatson I've patched 1.6.2.9 but it is not working with iaxmodem and hylafax, could you please share what versions are you using (iaxmodem and hylfax)? what OS?

I need some help with this. I see the call being passed from asterisk to iaxmodem but something fails and I can't figure out what it is.

Could you share your configs? (using pastebin or something like that)

Thanks a lot!!!!
By: klaus3000 (klaus3000) 2010-06-26 11:10:52

@flaper87: So you are trying SIP/T.38 to IAX?. First make sure that your Hylafax+IAXmomdem setup works (we can't debug everything at the same time). Therefore try to send a fax with Hylafax from one iaxmodem to a second iaxmodem (same Hylafax). If that works fine we can go on debugging the T38 thing.
By: Marek Cervenka (cervajs) 2010-08-26 08:46:41

any news about inclusion in 1.8?
By: dalepbx (dalepbx) 2010-08-26 09:48:51

I hereby second cervajs Question ;)
(just want to let everybody know that there is (quite) some interest in this feature)
By: Matt Watson (mwatson) 2010-08-26 10:13:37

third!
By: Leif Madsen (lmadsen) 2010-08-26 11:44:14

The way this is being implemented here will not be the way it is implemented in Asterisk going forward, which means this is not a candidate for Asterisk 1.8 (especially since it has now been branched and is in beta).

Here is the T.38 Gateway Proposal from kpfleming on he mailing lists:

http://lists.digium.com/pipermail/asterisk-dev/2010-April/043789.html

T.38 Gateway support will be in some future version of Asterisk, but it has not been determined when.
By: Leif Madsen (lmadsen) 2010-08-26 11:48:52

Correction, per kpfleming, "We are actively discussing it, with a goal of making it as easy as possible for it to be added to 1.8, even if it's not in 1.8.0."

API changes are required for T.38 gateway support, and it is being evaluated to determine how invasive those changes might be.
By: Pippo Paolini (pippo) 2010-09-23 15:01:44

Did anyone have updated the patch for asterisk 1.6.2.13 ?
By: klaus3000 (klaus3000) 2010-09-24 03:07:33

Have you tried the 1.6.2.9 patch with 1.6.2.13?
By: Marek Cervenka (cervajs) 2010-09-24 04:33:40

1.6.2.9 patch works on 1.6.2.13

[root@asterisk-1.6.2.13]# patch -p1 < t38-1629.patch
patching file apps/app_dial.c
Hunk #4 succeeded at 2272 (offset 9 lines).
patching file apps/app_fax.c
patching file channels/chan_iax2.c
Hunk #1 succeeded at 5372 (offset 10 lines).
patching file channels/chan_sip.c
Hunk #1 succeeded at 5107 (offset 44 lines).
Hunk #2 succeeded at 6442 (offset 1 line).
Hunk #3 succeeded at 6574 (offset 44 lines).
Hunk #4 succeeded at 6614 (offset 1 line).
patching file include/asterisk/features.h
patching file main/channel.c
Hunk #1 succeeded at 3277 (offset 18 lines).
Hunk #2 succeeded at 3636 (offset 18 lines).
patching file main/features.c
Hunk #1 succeeded at 2483 (offset 50 lines).
By: klaus3000 (klaus3000) 2010-09-24 05:51:57

fyi: Asterisk 1.8 is ready now for inclusion of T38 gatewaying:
http://lists.digium.com/pipermail/asterisk-dev/2010-September/046344.html

So, now we need somebody ti migrate the current patch to the new fax API in 1.8.
By: dalepbx (dalepbx) 2010-09-27 02:11:23

@klaus3000: That's great news. Hopefully some skilled hacker will pick up the task. I have looked at the code of the patch, but unfortunately it's far beyond my University "CS 101" C knowledge from long ago ;)
By: Pippo Paolini (pippo) 2010-09-27 14:43:00

Thanks cervajs,
I have tryed to apply the patch and seems to works.

anybody know how debug a call to see if is in T38 mode?

thanks
By: klaus3000 (klaus3000) 2010-09-27 15:24:23

See my above comment: https://issues.asterisk.org/view.php?id=13405#c119334
By: Leif Madsen (lmadsen) 2010-10-04 12:03:29

I'd like to clean up this issue a bit. Can someone tell him which files I can delete (or which files should remain) so I can clear out any files that are not necessary? Thanks!
By: klaus3000 (klaus3000) 2010-10-04 13:18:16

IIRC asterisk-1.6.2.6-t38gw-dial-patch.txt was the first really working patch (at least for me). This patch was updated to 1.6.2.9 (=asterisk-1.6.2.9-t38gw-dial.patch) by cervajs.

I think the remainder are either outdated patches or traces - and probably can be deleted.
By: Massimo De Nadal (mdenadal) 2010-11-02 03:11:28

Just to report my successful story.
I've installed to a customer of mine an asterisk/iaxmodem/hylafax based fax server solution.
This is the architecture:

PRI Line
   ||
   ||
Cisco Router
Voice GW    
   ||
   ||
   || Sip t.38 over ethernet
   ||
   ||
Asterisk 1.6.2.13
t38gw-dial patched
   ||
   ||
   || IAX2 over loopback interface
   ||
   ||
IAXmodem
   ||
   ||
HylaFax


Works like a charm !! My best Asterisk fax experience, ever.
Thank you guys.

Massimo


By: Niccolò Belli (darkbasic) 2010-11-02 03:47:21

Is there any news about the 1.8 porting?
By: Steve (802) 2010-11-17 12:22:54.000-0600

Seeing an issue with setup as folows on asterisk 1.6.13, call are being hungup on answer

Legacy system on pri
||
||
asterisk (dial with b option)
||
||SIP
||
Asterisk
||
||
SIP GSM GATEWAY (no.t38 support)
By: Steve (802) 2010-11-17 13:14:10.000-0600

Sorry
also seeing this with debug on

ot  RTP packet from    192.168.101.5:18424 (type 97, seq 022552, ts 2979248, len 000050)
Sent RTP packet to      192.168.101.5:18424 (type 97, seq 051634, ts 024720, len 000050)
Got  RTP packet from    192.168.101.5:18424 (type 97, seq 022553, ts 2979488, len 000050
<< [ TYPE: Control (4) SUBCLASS: Answer (4) ] [SIP/GSM-00000006]
   -- SIP/GSM-00000006 answered DAHDI/45-1
<< [ TYPE: Null Frame (5) SUBCLASS: N/A (0) ] [DAHDI/45-1]
>> [ TYPE: Null Frame (5) SUBCLASS: N/A (0) ] [SIP/GSM-00000006]
Sent RTP packet to      192.168.101.5:18424 (type 97, seq 051635, ts 024960, len 000050)
Sent RTP packet to      192.168.101.5:18424 (type 97, seq 051636, ts 025200, len 000050)
Got  RTP packet from    192.168.101.5:18424 (type 97, seq 022554, ts 8313216, len 000050)
<< [ TYPE: Control (4) SUBCLASS: Unknown control '25' (25) ] [SIP/GSM-00000006]
>> [ TYPE: Control (4) SUBCLASS: Unknown control '25' (25) ] [DAHDI/45-1]




and



[Nov 17 19:19:00] DEBUG[6307] app_fax.c: Bridging started chan DAHDI/45-1 peer SIP/GSM-00000007
[Nov 17 19:19:00] NOTICE[6307] channel.c: Dropping incompatible voice frame on DAHDI/45-1 of format slin since our native format has changed to 0x8 (alaw)
[Nov 17 19:19:00] VERBOSE[6307] frame.c: << [ TYPE: Null Frame (5) SUBCLASS: N/A (0) ] [DAHDI/45-1]
[Nov 17 19:19:00] VERBOSE[6307] frame.c: >> [ TYPE: Null Frame (5) SUBCLASS: N/A (0) ] [SIP/VodafoneAndGSM-00000007]
[Nov 17 19:19:00] VERBOSE[6307] rtp.c: Sent RTP packet to      192.168.101.5:18696 (type 97, seq 057788, ts 025200, len 000050)
[Nov 17 19:19:00] VERBOSE[6307] rtp.c: Got  RTP packet from    192.168.101.5:18696 (type 97, seq 025896, ts 9412840, len 000050)
[Nov 17 19:19:00] VERBOSE[6307] rtp.c: Sent RTP packet to      192.168.101.5:18696 (type 97, seq 057789, ts 025440, len 000050)
[Nov 17 19:19:00] VERBOSE[6307] rtp.c: Got  RTP packet from    192.168.101.5:18696 (type 97, seq 025897, ts 4297072, len 000050)
[Nov 17 19:19:00] VERBOSE[6307] frame.c: << [ TYPE: Control (4) SUBCLASS: Unknown control '25' (25) ] [SIP/GSM-00000007]
[Nov 17 19:19:00] VERBOSE[6307] frame.c: >> [ TYPE: Control (4) SUBCLASS: Unknown control '25' (25) ] [DAHDI/45-1]
[Nov 17 19:19:00] DEBUG[6307] chan_dahdi.c: Requested indication 25 on channel DAHDI/45-1
[Nov 17 19:19:00] DEBUG[6307] app_fax.c: Error reading frame on DAHDI/45-1, stop bridging as the call has finished.


By: klaus3000 (klaus3000) 2010-11-17 17:11:27.000-0600

You can not fax over a normal GSM audio call. The GSM call needs to be started in dedicated FAX mode (uncompressed data call).

You should remove one Asterisk and try to fax PRI-->Asterisk-->SIPGSMGATEWAY. Only if this works then you can try adding the second Asterisk with the T38 link. Also, if the connection between the 2 Asterisk server is high quality (LAN or equivalent) I guess there is no need to use T38
By: Andre Ricardo Silva (andrerics) 2010-11-19 10:14:09.000-0600

Dafe_von_cetin (or other person)

can you send me the patch to Asterisk 1.4.20.1?

Thank you in advance!

andrerics@gmail.com
By: James Lamanna (jlamanna) 2010-11-28 23:08:14.000-0600

Is there a T38 Gateway patch/module for 1.8 yet? I'd like to start trying it out...
Thanks!
By: Niccolò Belli (darkbasic) 2010-11-29 03:51:40.000-0600

I'm interested too. Possibly a plugin, so I don't need to patch the code.
By: Gentian Bajraktari (gentian) 2010-12-18 02:45:58.000-0600

any news on adding this patch to 1.8 ? thanks!
By: Marek Cervenka (cervajs) 2010-12-22 04:12:17.000-0600

good news everyone!

dafe_von_cetin will be working on ast 1.8 T.38 gw

Happy Christmas
By: Niccolò Belli (darkbasic) 2010-12-22 04:33:23.000-0600

Yeah, best Christmas present ever :)
By: Gentian Bajraktari (gentian) 2010-12-22 15:29:56.000-0600

great news! ready to test :)
By: dovid (dovid) 2010-12-24 07:07:41.000-0600

Too much to look over here. Is the patch working for 1.6.X ? I have 1.8.0 installed. If any testing is needed there let me know.
By: Andre Ricardo Silva (andrerics) 2011-01-03 07:18:47.000-0600

Please could someone send me the latest version of this patch to Asterisk 1.4?

andrerics@gmail.com

Thank you in advance!
By: klaus3000 (klaus3000) 2011-01-03 07:49:59.000-0600

@andrerics: there is no working version for 1.4. If you want you can try to port it yourself - but I do not recommend it, as T.38 implementation of 1.4 differs a lot from 1.6 and thus would require lot of work.

If you are sticked to 1.4 you can try this T.38 implemenation:
http://www.zoiper.com/foip/
By: Joel Oliveira (joeloliveira) 2011-01-05 06:16:29.000-0600

Having a similar problem to the one reported by dalepbx on https://issues.asterisk.org/view.php?id=13405#119869 .

I am using a topology like:
Fax <-> ATA <-SIP-> Asterisk <-> Cisco <-> Asterisk <-SIP-> ATA <-> Fax

Note that both ATAs support T.38 and that the presented Asterisk is the same and only machine. i.e. both faxes are contacted via different ATAs that are clients to the Asterisk.
I am using Asterisk 1.6.2.13 on Debian OS 5.0.6 machine.

I turned udptl and channel debug on just like klaus said and the output is on http://pastebin.com/Mn4WSXmq .

Quick notes about the pastebin (there were some values that had to be cut off):
cisco-ip is representing the cisco IP
asterisk-ip is representing the Asterisk IP
receiver is the number for the receiving fax
sender is the number for the sending fax
from-pstn is the dialplan for the incoming calls
user_faxtest is the dialplan for the ougoing calls

"Any help would help". Thanks


By: klaus3000 (klaus3000) 2011-01-05 07:11:46.000-0600

@joeloliveira: What is the "Cisco"? Is it a proxy? A B2BUA? Does it work without the "Cisco"?

It seems there are several SIP errors - try to fix them first. Use "ngrep -W byline port 5060" to capture the SIP traffic and verify what is going wrong.
By: Andre Ricardo Silva (andrerics) 2011-01-05 07:34:49.000-0600

@klaus 3000. Yes, I'm sticked to 1.4.

Attrafax tested and the tests are OK.

Thanks for your suggestion!
By: Joel Oliveira (joeloliveira) 2011-01-07 07:28:34.000-0600

@klaus3000: Sorry that I did forgot to explain what was the Cisco (it was a SIP trunk with the outside of my network) but nevermind, to keep things simple I decided to go with a more simple scenario like:

Fax1 <-> ATA1 <-SIP/T38-> Asterisk <-SIP/T38-> ATA2 <-> Fax2

Both ATAs are Planet Technology's VIP-157s both capable of T.38, Asterisk is at 1.6.2.13 version and the debug is presented on http://pastebin.com/abxhReuE, with 'core set debug channel all', 'udptl set debug on' and 'rtp set debug on' executed.

In the debug I tryed to send a fax from Fax1 to Fax2, and it comes to my understanding that the callee can't negotiate T.38. I tryed the other way around, i.e. from Fax2 to Fax1, and the same thing happens: the callee can't negotiate T.38, so, as I understand it, it's not a device problem, it's Asterisk's.

A little bit more info about the debug:
asterisk-ip: it's the Asterisk's machine IP
nat-ip: it's the nat IP that both ATAs are connected
6000: is the port for the ATA1 - peer 96 (caller)
6001: is the port for the ATA2 - peer 97 (callee)

Does anyone has any clue around this issue? Thanks for reading this :)


By: Denis Luzin (dluzin) 2011-01-07 09:00:02.000-0600

T38-T38 bridging with udptl doesn't work.
Some code is lost during conversion of GNC/CED detection processing code:

Patch 1.6.2.9, starting from the end of line 396 add:

"else
      ast_write(inactive,f);"
Otherwise T38 control frames will be lost and udptl processing will report error 486 after timeout.

Anyway, thank you for great work!


By: Joel Oliveira (joeloliveira) 2011-01-07 12:31:19.000-0600

@dluzin: Was your post regarding my issue? If so, I already tryed to change the source code and recompile it and still have the same problem, the callee can't negotiate anything and therefore there is no FAX passed to the receiver.

If someone as some insight about this I would be very glad if you could share it with me. I need this to work between 2 ATAs. Thanks
By: Denis Luzin (dluzin) 2011-01-07 13:36:28.000-0600

My setup is:

Fax <-> ATA1 (D-Link DVG-5008S) <-> asterisk 1.4.21 with udptl <-> asterisk 1.4.21 with udptl <-> asterisk 1.6.13 No 1 <-> Kapanga Softphone

To realize normal functions (t.38 gatewaying + transfer and etc.) I had to install second asterisk 1.6.13 No 2 and bind it to other SIP ports and use it as 'intermediate' between caller and callee on asterisk 1.6.13 No 1 (through custom contexts of FreePBX).
This setup works quite stable after changes in patch mentioned above.
Connection between two Kapanga softphones also works well.
t.38<->t.30 gatewaying seems to be working also (I can hear CED when calling from extension with t38pt_udptl=no to Kapanga's extension) - have no physical access to the analog fax machine to test this function, will do later.

Regarding Planet VIP-157s I have couple of them and will test them when I will have a fax machine, but my past experience with small Planet ATAs is very bad - they hangs, have problems with T.38 sessions between two ATAs (Planet and non-Planet) etc. I was using VIP-156 and VIP-157s, most of VIP-157S produces quite hard noise.
By: Joel Oliveira (joeloliveira) 2011-01-07 14:14:40.000-0600

@dluzin: thanks for your input, although I don't understand part of it. Did you mean "asterisk 1.6.13 No 2" instead of the second "asterisk 1.4.21 with udptl" ?

You did remind me on some way for doing this like:

Fax1 <-> ATA1 <-SIP/T.38-> Asterisk1 <-RTP-> Asterisk2 <-SIP/T.38-> ATA2 <-> Fax2

I tryed this by creating a SIP trunk in both directions between Asterisk1 and Asterisk2 and declaring the t38pt_udptl=no in each of them, is this the way to force the Asterisk to not use T.38?

I tested this on both directions and the results were the same: Asterisk of the caller negotiates T.38 with the caller but the other Asterisk doesn't negotiate T.38 with the callee. Don't know what I am doing wrong here...

Regarding the ATAs, I tryed before a GrandStream HT286 and some Draytek (don't remember the model) and the results were not satisfatory... the only good ones that I had were with the Planets VIP-157s.

Any help appreciated and thanks for your time
By: Denis Luzin (dluzin) 2011-01-07 17:06:32.000-0600

I meant Asterisk 1.6.2.13 No 1 and Asterisk 1.6.2.13 No 2 run on the same machine bind to 5061 sip port.
My setup works as following:

Extension on Asterisk No 1 (in custom context) initiates call to some number.
Custom context changes number (add leading '1' to the number) and sends number for regular routing.
There is a route for numbers beginning from '1' that sends this call to Asterisk No 2 using regular Dial command (with rtTwW options).
Asterisk No 2 strips leading '1' from the number and sends it back to Asterisk No 1 using t.38 Dial (with b option).
Asterisk No 1 sends received number (same as initially dialed by extension) for regular routing and makes outgoing call to one of upstream Asterisk 1.4.24.1 using regular Dial command.

At the end I have full Dial function functionality and t.38 gateway as well as my favorite web-interface for trunks, peers, extensions, etc.
This setup is quite complicated, but tuned once works for years.
I had similar setup of Asterisk 1.4.24.1 and callweaver 1.2 for about 1.5 years.

Regarding your problem - check "canreinvite" parameters of all peers within ata1 <-> ata2 path. Try putting "canreinvite=no" to each peer and "nat=yes" to prevent changing of RTP/UDPTL media path and engage UDPTL passthrough.
Put to sip.conf t38pt_udptl=yes, redundancy,maxdatagram=400 and udptlstart and udptlend to udptl.conf
Do not put t38pt_usertpsource - in my case it was causing loss of udptl packets (why? I don't know).
Spandsp's modem on my x86_64 was not working properly (no sound at t.30 side), so I had to upgrade spandsp library from 0.0.5_pre4 to 0.0.6_pre12.
On x86 0.0.5_pre4 works well.
If you will upgrade spandsp do not forget to reconfigure and recompile asterisk.


By: Denis Luzin (dluzin) 2011-01-07 19:32:56.000-0600

To joeloliveira:
Tried VIP-157S I have.
T.38 implementation in this device is almost crap.
Tried firmwares 2.0, 3.0, 3.02, 3.2
Fax sending over T.38 works in 3.0 and above, needs precise tuning of sensitivity/volume levels to get fax passing through.
Fax receipt over T.38 doesn't work - no T.38 invite from VIP-157S. Sometimes it issues invite (firmware 3.2), but still producing CNG in parallel to T.30 session - no use.
Device is very buggy in relation to T.38 - useless.
By: Denis Luzin (dluzin) 2011-01-09 01:31:55.000-0600

Made some changes in code, added some checkings for T38_STATE_UNKNOWN to prevent situation when ast_t38_gateway may start before both of peers has been checked for T.38 support and some checkings for T38_STATE_NEGOTIATED to allow bridging when both channels has T.38 support. Also made some work after CED detection. Now T.38 gatewaying works well in two setups - ATA <-> asterisk <-> asterisk <-> ATA (SIP-to-SIP bridging) and FXO <-> asterisk <-> asterisk <-> ATA (SIP-to-SIP gatewaying)
Will do some code cleaning and can post reworked patch here.

@joeloliveira:
Now VIP-157S works with 3.2 firmware, but not stable. It may or may not send reinvite and also may not reply to reinvite if it does CED detection at that time - I saw situation when fax attached to it started to produce CED tone, asterisk sent a reinvite rigth before that and VIP-157S sends reinvite after CED detection completes and forgets to reply to incoming reinvite.

@klaus3000:
Are you planning to rewrite T38_STATE_... processing in ast_bridge_frames?
In my opinion it is quite complicated and hard to trace and should be fomalized into 'case - of' structure.


By: klaus3000 (klaus3000) 2011-01-09 03:09:50.000-0600

@dluzin: No, I do not plan any changes/enhancements. If you have fixes or want to clean up the code, please go on and post it here (you have to agree to the disclaimer). But, this code will never get into Asterisk. The code must be rewritten to fit Asterisk's T.38 gatewaying API. So, it would be best to port the code to this API.

See http://www.mail-archive.com/asterisk-dev@lists.digium.com/msg45518.html for details, and before porting you should ask on the dev-mailing list if somebody else is already working on it.
By: Denis Luzin (dluzin) 2011-01-09 13:22:44.000-0600

@klaus3000: Thank you for reply.

Finally got the following weird setup working(!):

T.38 Softphone <-SIP-> Asterisk 1 <-IAX2-> Asterisk 2 <-SIP-> T.38 Softphone

I had to use app-meetme on Asterisk 2 to get some timing source for both gateways as they're getting timing from voice channel.

Will post updated patch tomorrow.

What is annoying: no reliable timing, no ECM, unreliable fax detection based on non-working (had to repair and retune it) dsp fax CED detection.
By: Denis Luzin (dluzin) 2011-01-09 15:23:24.000-0600

Uploaded reworked patch.
Patch needs a lot of work in relation to coding style and state-processing algorythm, but basically works.
By: Gregory Hinton Nietsky (irroot) 2011-02-23 03:07:32.000-0600

Ok ive implemented the meat into trunk [1.10] please test it if you can need help here have no way to test at the momment

https://reviewboard.asterisk.org/r/1116/
By: Gregory Hinton Nietsky (irroot) 2011-02-23 04:23:09.000-0600

Ok have put together a 1.8 version of the patch with some cleanups in the code and move to res_fax ....

please test it and help with this i have no way of testing at the moment hoping it be of use
By: Gregory Hinton Nietsky (irroot) 2011-02-23 09:16:14.000-0600

Some more clean ups and some changes to CDR / hangup handling ...

im only bridging voice so have not tested t38_gateway yet please feed back if you can help me with this ...
By: Niccolò Belli (darkbasic) 2011-02-23 10:00:57.000-0600

What about the implementation as plugin for asterisk 1.8? Is there any news about it?
By: Leif Madsen (lmadsen) 2011-02-23 10:54:52.000-0600

I have just added this to the Additional Information:

~~~~~~~~~~~~~~~~~~~~

Note, the patches in this issue will not be merged into the Asterisk code base unless they are changed/rewritten to use the API created for T.38 Gateway support.

More information about the approach and the API are available on the mailing lists:

http://lists.digium.com/pipermail/asterisk-dev/2010-April/043789.html
http://lists.digium.com/pipermail/asterisk-dev/2010-September/046344.html
By: Gregory Hinton Nietsky (irroot) 2011-02-23 11:37:20.000-0600

@lmadsen thanx i was reading them earlier and am keen to continue to work on it along these lines the latest patch has the first part started getting the spandsp stuff into res_fax_spandsp and the core stuff in res_fax now to move the bridge bits out into the channels and core and make the options dynamic im hoping that you or russel will feed back on the res_fax_spandsp stuff i have done so far as to if its going in the right direction ...

during this upstream move i want to maintain and improve the existing code here for the existing consumers ...

many thx ...
By: Gregory Hinton Nietsky (irroot) 2011-02-24 07:29:12.000-0600

ive been striping the bits apart and making them more friendly to * and res_fax

to allow the "Gateway" to manage the T38 parameter's within res_fax i propose a callback
to be placed in the bridge config.

a further callback needs to be added for the actual gateway when the channel states are correct ast_generic_bridge must end and the
gateway start.

"t38_gateway_handle_parameters" res_fax will register this and if FAXOPTS and friends enable T38 Gateway on the call via a option this call back will return a result indicating handled / not handled / T38 Gateway Start.

if it is not handled either due to non existence or if not handled status quo is maintained.

on T38 Gateway start the audio loop must end and the T38 gateway bridge callback must be called this is in res_fax and calls
technology IE res_fax_spandsp.

this callback will need to go into ast_generic_bridge and replace the current AST_CONTROL_T38_PARAMETERS case.

Please let me know if this method is in line with the API requirements.
By: Gregory Hinton Nietsky (irroot) 2011-02-25 08:00:37.000-0600

New patch asterisk-1.8.2_fax.2.patch uploaded.

this latest patch has the old applications split off into a new file app_faxdetect.c this is where the hook for app_dial is now residing there is no fax code in this file its all been moved into the new API res_fax and res_fax_spandsp these files should be ready for upstream.

the patch for sip from ASTERISK-17478 is included here as its important.

there is a change to channel.c that uses a handle routine in res_fax so it may be functional with the standard dial command it calls the res_fax handler and this fires up the gateway.

i have not implemented FAXOPTS hooks yet to activate or deactivate the gateway in the dialplan the default is on.

im still not able to actually send a fax as i have no fax machine i can get T38 negotiated by faking CED/CNG sorry i cant test it end to end please help will send beers [virtual].

the goal is to not have to use the faxdetect dial replacement or the 'b' hack in app_dial.
By: Gregory Hinton Nietsky (irroot) 2011-03-05 07:20:24.000-0600

Ok latest patch actually works i did not have fax machine to test till yesterday this is all the patches ported to 1.8.3 [res_fax] the app_dial bits are still in here but not in the patch for trunk as its not needed any longer and will be removed.
By: Gregory Hinton Nietsky (irroot) 2011-03-05 07:20:56.000-0600

Ok latest patch actually works i did not have fax machine to test till yesterday this is all the patches ported to 1.8.3 [res_fax] the app_dial bits are still in here but not in the patch for trunk as its not needed any longer and will be removed.
By: sles (sles) 2011-03-09 01:13:38.000-0600

irroot, could you tell me- your patch works only for sip or it is possible to use it with ooh323? thank you!
By: Gregory Hinton Nietsky (irroot) 2011-03-09 12:15:32.000-0600

Latest res_fax patch uploaded there is no longer a "faxgateway" app or any options to dial there is a "faxdetect" app that will allow switchover.

to use
1) set FAXOPT(t38gateway) = yes
2) run faxdetect to kick in the T38 switchover
3) dial as per normal please note that rtp bridging is not supported at this moment but will be added if needed.

@sles any channel with a T.38/udptl stack will work with this code not sure if ooh323 does have UDPTL support not familiar with it.
By: sles (sles) 2011-03-10 03:59:37.000-0600

Hello!

irroot, ooh323 maintainer said that ooh323 supports udptl, so I'd like to test your patch.
but your instructions are not clear for me.
could you, please, provide dial plan sample?

thank you!
By: Gregory Hinton Nietsky (irroot) 2011-03-15 02:29:51

Here is a DP example im using for testing ill be pushing some tweaks latter im happy with the way it is working now.the problems i was having turned out to be a format management issue in chan_local im now focusing on the switchover API hook
i dont want any code for switchover in channel.c it must be in the channel drivers i have put a patch for T38SWITCHOVER option in sip that needs some work.

There is now no dedicated app for T38Gateway and there is no hijacking of the core bridge loop.
the gateway hooks into the core loop and replaces T.38 negotiation only if set using FAXOPT this is done entirely inside res_fax.


[faxtest]
;This can be set as a default in res_fax.conf
exten => _X.,1,SET(FAXOPT(t38gateway)=yes)
;Dial into local T.30 for testing i have removed T38 support from local for this [no queryoption] can use the F option in trunk
exten => _X.,n(out),Dial(Local/${EXTEN}@faxin)
exten => _X.,n,Hangup

[faxin]
exten => _X.,1,Answer()
exten => _X.,n,Wait(3)
exten => _X.,n,ReceiveFAX(/var/spool/asterisk/fax/${CDR(linkedid)}.tiff)

the above works with a device that switches to T.38 automagically on CNG/CED tone [Linksys 2102] the switchover im not happy with as of yet ill be working on this and should be ready soon please email me gregory at distrotech.co.za if you want to be emailed the current patch ill be posting patch >= 1.8.4 when the switchover is complete.
By: Gregory Hinton Nietsky (irroot) 2011-03-16 07:46:37

asterisk-1.8.4_fax.patch uploaded some improvement enhancements and faxdetect now will allow detection and switchover of any device on detection.

here is a example dial plan there is a switchover option now in chan_sip too

exten => _X.,1,SET(FAXOPT(t38gateway)=yes)
exten => _X.,n,FaxDetect(5)
exten => _X.,n,Dial(....)
By: dovid (dovid) 2011-03-31 01:29:56

irroot:

Will this work as a T38 Gateway to another system (SS7-> Asterisk -> Remote SIP server with T.38) or is it just local ? Also do I need to set "SET(FAXOPT(t38gateway)=yes)" to enable T38 ?
By: Gregory Hinton Nietsky (irroot) 2011-03-31 03:05:44

Here is a example output ive had some problems if the faxes negotiate to quickly
as long as one end is T.38 and the the other is not it should work.

 == Using UDPTL CoS mark 5
 == Using SIP RTP CoS mark 5
   -- Executing [XX@faxtest:1] Set("SIP/X","FAXOPT(t38gateway)=yes")
   -- Executing [XX@faxtest:2] Set("SIP/X", "FAXOPT(ecm)=yes")
   -- Executing [XX@faxtest:3] Dial("SIP/X", "DAHDI/r1/0866020007")
   -- Called r1/XXX
   -- DAHDI/1-1 answered SIP/X
   -- Running Gateway activestate=4 (SIP/X) and inactivestate=0 (DAHDI/1-1)
   -- Channel 1 detected a CED tone from the network.
   -- Hanging up on 'DAHDI/1-1'
   -- Hungup 'DAHDI/1-1'
 == Spawn extension (faxtest, XX, 3) exited non-zero on 'SIP/X'
   -- Connection Statistics
       Bit Rate :9600
       ECM : No
       Pages : 1
By: Cédric Lemarchand (dafresh) 2011-03-31 03:28:19

Hi,

I plan to do something like this :

SPA3102 < SIP G729 UDPL T38 over slow links > ASTERISK < IAX2 G711 over LAN > ASTERISK < DADHI T2 TRUNK > TELCO

Do you see any reasons for which it will not work ?

Thx for reply,

Cedric
By: Loic Didelot (voipgate) 2011-03-31 12:23:26

Hello,
I am trying AVM-Fritzbox (T.38) <=> Asterisk <=> Asterisk with PRI Card but somehow it does not switch to T.38. Settings faxdetect in sip.conf to no or yes doesnt change anything.


 == Using UDPTL CoS mark 5
 == Using SIP RTP CoS mark 5
   -- Executing [XXXX@OUTGOING:1] NoOp("SIP/90-00000002", "OUTBOUND FAX CALL") in new stack
   -- Executing [XXXX@OUTGOING:2] Set("SIP/90-00000002", "FAXOPT(t38gateway)=yes") in new stack
   -- Executing [XXXX@OUTGOING:3] Set("SIP/90-00000002", "FAXOPT(ecm)=yes") in new stack
   -- Executing [XXXX@OUTGOING:4] FaxDetect("SIP/90-00000002", "2") in new stack
[2011-03-31 19:18:59] NOTICE[12073]: chan_sip.c:8688 process_sdp: T.38 re-INVITE detected but no fax extension
   -- Executing [XXXX@OUTGOING:5] Set("SIP/90-00000002", "CARRIER=fax") in new stack
   -- Executing [XXXX@OUTGOING:6] Dial("SIP/90-00000002", "SIP/fax/2612768,60") in new stack
 == Using UDPTL CoS mark 5
 == Using SIP RTP CoS mark 5
   -- Called fax/2612768
   -- SIP/90-00000002 requested special control 20, passing it to SIP/fax-00000003
   -- SIP/fax-00000003 answered SIP/90-00000002
[2011-03-31 19:19:05] NOTICE[12073]: chan_sip.c:8688 process_sdp: T.38 re-INVITE detected but no fax extension
By: Robert Thomas (thomcr) 2011-04-08 01:40:00

I got it to install with the latest 0.6 spandps but I have trouble with the faxdetect app.

With the 1.8.4 patch and spandsp 0.6 latest

I'm having trouble testing the new 1.8.4 patch. This is the dialplan

 '_5062XXXXXXX' => 1. Set(FAXOPT(t38gateway)=yes)                [pbx_config]
                   2. Dial(DAHDI/g0/${EXTEN})                    [pbx_config]
                   3. Hangup()                                   [pbx_config]

 == Using SIP RTP CoS mark 5
   -- Executing [50624309954@termination-test:1] Set("SIP/robert-00000007", "GROUP(customers)=ibasis") in new stack
   -- Executing [50624309954@termination-test:2] Set("SIP/robert-00000007", "GROUP(termination)=ss7") in new stack
   -- Executing [50624309954@termination-test:3] Set("SIP/robert-00000007", "FAXOPT(t38gateway)=yes") in new stack
   -- Executing [50624309954@termination-test:4] Dial("SIP/robert-00000007", "DAHDI/g0/50624309954") in new stack
   -- Called g0/50624309954
   -- DAHDI/1-1 is proceeding passing it to SIP/robert-00000007
[Apr  8 00:26:35] NOTICE[31251]: chan_sip.c:8615 process_sdp: T.38 re-INVITE detected but no fax extension
   -- Running Gateway activestate=4 (SIP/robert-00000007) and inactivestate=0 (DAHDI/1-1)
[Apr  8 00:26:35] ERROR[10783]: res_fax.c:822 fax_session_reserve: Could not locate a FAX technology module with capabilities (T38_GATEWAY)
[Apr  8 00:26:35] ERROR[10783]: res_fax.c:2527 __ast_t38_gateway_handle_parameters: Unable to reserve FAX session.
   -- Running Gateway activestate=0 (DAHDI/1-1) and inactivestate=4 (SIP/robert-00000007)
[Apr  8 00:26:35] ERROR[10783]: res_fax.c:822 fax_session_reserve: Could not locate a FAX technology module with capabilities (T38_GATEWAY)
[Apr  8 00:26:35] ERROR[10783]: res_fax.c:2527 __ast_t38_gateway_handle_parameters: Unable to reserve FAX session.

T38 negotiation sip level is sucessfull. The call gets established but the fax on the other side, receive nothing and disconect. In this example I see

Running Gateway activestate=4 (SIP/robert-00000007) and inactivestate=0


I added the faxdetect app you created. Can you explain us what it actually does? As well the number parameter you pass on to it?

 '_5062XXXXXXX' => 1. Set(FAXOPT(t38gateway)=yes)                [pbx_config]
                   2. FaxDetect(5)                               [pbx_config]
                   3. Dial(DAHDI/g0/${EXTEN})                    [pbx_config]
                   4. Hangup()                                   [pbx_config]

With this setup I dont see the "running gateway"

 == Using SIP RTP CoS mark 5
   -- Executing [50624309954@termination-test:1] Set("SIP/robert-00000005", "GROUP(customers)=ibasis") in new stack
   -- Executing [50624309954@termination-test:2] Set("SIP/robert-00000005", "GROUP(termination)=ss7") in new stack
   -- Executing [50624309954@termination-test:3] Set("SIP/robert-00000005", "FAXOPT(t38gateway)=yes") in new stack
   -- Executing [50624309954@termination-test:4] FaxDetect("SIP/robert-00000005", "5") in new stack
   -- Executing [50624309954@termination-test:5] Dial("SIP/robert-00000005", "DAHDI/g0/50624309954") in new stack
   -- Called g0/50624309954
   -- DAHDI/1-1 is proceeding passing it to SIP/robert-00000005
   -- DAHDI/1-1 answered SIP/robert-00000005

Asterisk drop after 5 seconds with an 488 not acceptable here.

https://issues.asterisk.org/view.php?id=16327

Not sure if your patch, https://issues.asterisk.org/view.php?id=18889 has something to do with it, but with the 1.8.4 patch I couldn't apply the sip patch.


By: Niccolò Belli (darkbasic) 2011-04-14 10:44:32

Is there any news about T38 transparent gatewaying or the mainlining of this patch?
By: klaus3000 (klaus3000) 2011-04-15 02:53:44

@darkbasic: yes, see https://reviewboard.asterisk.org/r/1116/ with the up2date patches for Asterisk trunk
By: Niccolò Belli (darkbasic) 2011-04-15 05:30:45

Wonderful, hoping to see it merged to trunk in time for asterisk 1.10 :)
By: Niccolò Belli (darkbasic) 2011-04-21 10:21:36

My latest test was with asterisk 1.6, today I tested this patch again with asterisk 1.8.3. It does not compile with spandsp-0.0.6~pre12 (the version in the debian repositories), but it works flawlessly with spandsp-0.0.6~pre18. I sent 5 faxes with 10 pages each (total: 50 pages) with an analog fax attached to an isdn and received them using the Timenet provider, asterisk 1.8.3 with Sangoma A200 and another analog fax. Success rate: 100%. Quality: like a ISDN. I'm VERY happy with this patch, so happy that I packaged both spandsp-0.0.6~pre18 and asterisk-1.8.3+gw patch for Debian Squeeze. Also, hopefully a wanpipe drivers package for Sangoma cards will come soon thanks to Sangoma and another Debian developer :)
By: Niccolò Belli (darkbasic) 2011-04-26 18:09:00

What about *sending* faxes?

The following dialplan does not kick in t38 while sending :(

exten => _X.,1,SET(FAXOPT(t38gateway)=yes)
exten => _X.,n,FaxDetect(5)
exten => _X.,n,Dial(....)
By: Gregory Hinton Nietsky (irroot) 2011-04-27 03:05:45

@darkbasic thank you for the feed back and larger scale testing its most appreciated please upload / email me the compiler warnings if possible so i can check why / fix it.

the FaxDetect() app has 2 functions to detect the fax tones and process / trigger T38switchover as it answers the channel it probably should not be run as above.

when sending a fax if the remote is T.38 capable it will do a T.38 handshake and set up T.38 there is work to be done to get it into mainline i have not had the time i wish i had but im commited to this task.
By: Niccolò Belli (darkbasic) 2011-04-27 04:25:05

My provider does send the T.38 handshake (I checked when using T.38 originate or T.38 passthrough with FaxVoip), but for some reason it doesn't work when using t38 gw. Does it work for you?
By: Gregory Hinton Nietsky (irroot) 2011-05-05 10:43:55

@darkbasic im working on this and should have some progress.

there is much work done for trunk ill be posting a patch for 1.8 soon.
By: Niccolò Belli (darkbasic) 2011-05-05 10:48:24

Awesome, thank you very much :)
By: Gregory Hinton Nietsky (irroot) 2011-05-09 04:33:02

Ok here is the latest patch that is a mirror of the work im doing in trunk ...

faxdetect should no longer be needed the t38switchover option in sip is no longer there and faxgateway is no longer a global config option FAXOPT must be run to activate it.

when the CED tone is detected T.38 is trigged from the the non T.38 line...

been tested with OOH323 T38Modem Hylafax onto mISDN/DAHDI.

this code should not interfere with calls between T38 devices nor try negotiate
T.38

@darkbasic please check again this patch is the closest so far to comply with requirements and may get included.
By: Niccolò Belli (darkbasic) 2011-05-09 05:18:33

Is it against trunk? Unfortunately my FXS cards are in a nearly-production environment, so I can't test it against trunk :(

Against asterisk-1.8.3.3:
Applying patch faxgateway-svn_318106.patch
patching file channel.c
Hunk #1 FAILED at 4268.
1 out of 1 hunk FAILED -- rejects in file channel.c
patching file res_fax.c
Hunk #1 FAILED at 6.
Hunk #2 FAILED at 58.
Hunk #3 FAILED at 159.
Hunk #4 FAILED at 389.
Hunk ASTERISK-1 FAILED at 415.
Hunk ASTERISK-2 FAILED at 507.
Hunk ASTERISK-3 FAILED at 1002.
Hunk ASTERISK-4 FAILED at 1032.
Hunk ASTERISK-5 FAILED at 1114.
Hunk ASTERISK-6 FAILED at 1386.
Hunk ASTERISK-7 FAILED at 1785.
Hunk ASTERISK-8 FAILED at 2283.
Hunk ASTERISK-9 FAILED at 2679.
Hunk ASTERISK-10 FAILED at 2753.
14 out of 14 hunks FAILED -- rejects in file res_fax.c
patching file res_fax_spandsp.c
Hunk #1 FAILED at 5.
Hunk #2 FAILED at 46.
Hunk #3 FAILED at 57.
Hunk #4 FAILED at 75.
Hunk ASTERISK-1 FAILED at 121.
Hunk ASTERISK-2 FAILED at 428.
Hunk ASTERISK-3 FAILED at 475.
Hunk ASTERISK-4 FAILED at 537.
Hunk ASTERISK-5 FAILED at 551.
9 out of 9 hunks FAILED -- rejects in file res_fax_spandsp.c
patching file asterisk/res_fax.h
Hunk #1 FAILED at 42.
Hunk #2 FAILED at 158.
Hunk #3 FAILED at 204.
3 out of 3 hunks FAILED -- rejects in file asterisk/res_fax.h
patching file chan_sip.c
Hunk #1 FAILED at 4218.
Hunk #2 FAILED at 4877.
Hunk #3 FAILED at 6443.
Hunk #4 FAILED at 6485.
Hunk ASTERISK-1 FAILED at 8912.
Hunk ASTERISK-2 FAILED at 18727.
Hunk ASTERISK-3 FAILED at 19493.
Hunk ASTERISK-4 FAILED at 21169.
Hunk ASTERISK-5 FAILED at 22041.
9 out of 9 hunks FAILED -- rejects in file chan_sip.c
patching file sip/include/sip.h
Hunk #1 FAILED at 595.
1 out of 1 hunk FAILED -- rejects in file sip/include/sip.h
patching file app_faxdetect.c
Patch faxgateway-svn_318106.patch does not apply (enforce with -f)
By: Gregory Hinton Nietsky (irroot) 2011-05-09 06:04:00

Most odd ... the patch is agaist svn revision in the file name and should patch against older aswell except for channel.c as this is a patch on recently fixed....

here it is against clean 1.8.4-rc3

patch -p0 --dry-run < ....faxgateway-svn_318106.patch
patching file main/channel.c
Hunk #1 FAILED at 4268.
1 out of 1 hunk FAILED -- saving rejects to file main/channel.c.rej
patching file res/res_fax.c
Hunk ASTERISK-3 succeeded at 1062 (offset -1 lines).
Hunk ASTERISK-5 succeeded at 1156 (offset -1 lines).
Hunk ASTERISK-7 succeeded at 1817 (offset -2 lines).
Hunk ASTERISK-8 succeeded at 2314 (offset -1 lines).
Hunk ASTERISK-9 succeeded at 3067 (offset 4 lines).
Hunk ASTERISK-10 succeeded at 3139 (offset -1 lines).
patching file res/res_fax_spandsp.c
patching file include/asterisk/res_fax.h
patching file channels/chan_sip.c
Hunk #1 succeeded at 4210 (offset -8 lines).
Hunk #2 succeeded at 4882 (offset 2 lines).
Hunk #3 succeeded at 6422 (offset -34 lines).
Hunk #4 succeeded at 6500 (offset 2 lines).
Hunk ASTERISK-1 succeeded at 8819 (offset -106 lines).
Hunk ASTERISK-2 succeeded at 18730 (offset -10 lines).
Hunk ASTERISK-3 succeeded at 19390 (offset -116 lines).
Hunk ASTERISK-4 succeeded at 21160 (offset -22 lines).
Hunk ASTERISK-5 succeeded at 21939 (offset -115 lines).
patching file channels/sip/include/sip.h
patching file apps/app_faxdetect.c
By: Gregory Hinton Nietsky (irroot) 2011-05-09 12:01:22

file with a important fix loaded must use r318143 or latter as there is a change in asterisk core this will be 1.8.4( > -rc3)
By: dakapo (dakapo) 2011-05-10 07:17:09

I always get the follwing error when compiling 1.8.4-rc3 with r318143:

[CC] res_fax_spandsp.c -> res_fax_spandsp.o
res_fax_spandsp.c: In function ‘spandsp_fax_gateway_start’:
res_fax_spandsp.c:723: error: ‘t38_state’ undeclared (first use in this function)
res_fax_spandsp.c:723: error: (Each undeclared identifier is reported only once
res_fax_spandsp.c:723: error: for each function it appears in.)
make[1]: *** [res_fax_spandsp.o] Error 1
make: *** [res] Error 2
By: Niccolò Belli (darkbasic) 2011-05-10 07:42:47

Did you use spandsp-0.0.6~pre18?
By: dakapo (dakapo) 2011-05-10 09:42:11

Thank you. I did change from spandsp-0.0.6~pre12 to spandsp-0.0.6~pre18. Now I was able to install.

At the moment I try to get the following to run:
Hylafax/IAXModem<---IAX--->Asterisk<---SIP/T.38--->SPA2102-5.2.10

IAXModem works perfect. Linksys also does it's T38-Transfers if connected to other T38-Gateways.

At the moment my console gets fired with this messages when I try establising the call:
 -- Executing [receive@macro-fax-in:4] Set("SIP/101-00000000", "FAXOPT(t38gateway)=yes") in new stack
   -- Executing [receive@macro-fax-in:5] FaxDetect("SIP/101-00000000", "5") in new stack
[May 10 16:26:45] NOTICE[21194]: channel.c:4071 __ast_read: Dropping incompatible voice frame on SIP/101-00000000 of format slin since our native format has changed to 0x4 (ulaw)
   -- Registered IAX2 'iaxmodem104' (AUTHENTICATED) at 127.0.0.1:54757
   -- Executing [receive@macro-fax-in:6] Dial("SIP/101-00000000", "IAX2/iaxmodem104") in new stack
   -- Call accepted by 127.0.0.1 (format alaw)
   -- Called iaxmodem104
   -- Format for call is alaw
   -- IAX2/iaxmodem104-1090 is ringing
   -- IAX2/iaxmodem104-1090 answered SIP/101-00000000
[May 10 16:27:01] NOTICE[21194]: channel.c:4071 __ast_read: Dropping incompatible voice frame on IAX2/iaxmodem104-1090 of format slin since our native format has changed to 0x8 (alaw)
[May 10 16:27:01] WARNING[21194]: chan_sip.c:6633 sip_indicate: Don't know how to indicate condition 0
[May 10 16:27:01] WARNING[21194]: channel.c:4415 ast_indicate_data: Unable to handle indication 0 for 'SIP/101-00000000'
[May 10 16:27:01] WARNING[21194]: chan_sip.c:6633 sip_indicate: Don't know how to indicate condition 0
[May 10 16:27:01] WARNING[21194]: channel.c:4415 ast_indicate_data: Unable to handle indication 0 for 'SIP/101-00000000'
[May 10 16:27:01] WARNING[21194]: chan_sip.c:6633 sip_indicate: Don't know how to indicate condition 0
[May 10 16:27:01] WARNING[21194]: channel.c:4415 ast_indicate_data: Unable to handle indication 0 for 'SIP/101-00000000'
[May 10 16:27:01] WARNING[21194]: chan_sip.c:6633 sip_indicate: Don't know how to indicate condition 0
[May 10 16:27:01] WARNING[21194]: channel.c:4415 ast_indicate_data: Unable to handle indication 0 for 'SIP/101-00000000'
...
By: sles (sles) 2011-05-12 00:50:10

Hello!

I patched 1.8.4 and tried to test

how it is connected:

fax--tdm pbx--cisco3845--h323---asterisk1.8.4--tdm pbx-fax

call is from left to right.

dialplan:

exten => 4406,1,SET(FAXOPT(t38gateway)=yes)                                                                                                                  
exten =>4406,n,Dial(DAHDI/g1/5308)          

5308 is fax connected to right pbx.

what I get:

   -- Executing [4406@h323:1] Set("OOH323/192.168.22.253-1", "FAXOPT(t38gateway)=yes") in new stack
[May 12 09:45:46] ERROR[21517]: pbx.c:3571 ast_func_write: Function FAXOPT not registered
   -- Executing [4406@h323:2] Dial("OOH323/192.168.22.253-1", "DAHDI/g1/5308") in new stack
   -- Requested transfer capability: 0x00 - SPEECH
   -- Called g1/5308
   -- DAHDI/i1/5308-2 is proceeding passing it to OOH323/192.168.22.253-1
   -- DAHDI/i1/5308-2 is making progress passing it to OOH323/192.168.22.253-1
   -- DAHDI/i1/5308-2 is ringing
   -- DAHDI/i1/5308-2 answered OOH323/192.168.22.253-1
   -- fixed jitterbuffer created on channel DAHDI/i1/5308-2
   -- Channel 1 detected a CED tone from the network.
[May 12 09:46:15] WARNING[21517]: chan_dahdi.c:9056 dahdi_write: Don't know what to do with frame type '11'
[May 12 09:46:15] WARNING[21517]: chan_dahdi.c:9056 dahdi_write: Don't know what to do with frame type '11'
[May 12 09:46:15] WARNING[21517]: chan_dahdi.c:9056 dahdi_write: Don't know what to do with frame type '11'
[May 12 09:46:15] WARNING[21517]: chan_dahdi.c:9056 dahdi_write: Don't know what to do with frame type '11'
[May 12 09:46:15] WARNING[21517]: chan_dahdi.c:9056 dahdi_write: Don't know what to do with frame type '11'
[May 12 09:46:15] WARNING[21517]: chan_dahdi.c:9056 dahdi_write: Don't know what to do with frame type '11'
[May 12 09:46:15] WARNING[21517]: chan_dahdi.c:9056 dahdi_write: Don't know what to do with frame type '11'


fax doesn't pass...

Function FAXOPT not registered is what looks strange for me.
By: Gregory Hinton Nietsky (irroot) 2011-05-12 23:57:48

have you loaded res_fax and res_fax_spandsp ??


[May 12 09:45:46] ERROR[21517]: pbx.c:3571 ast_func_write: Function FAXOPT not registered

********

-- Channel 1 detected a CED tone from the network. is a message from dahdi

at this point the DSP processor in the gateway code needs to detect the CED tone in the audio path it seems it is not doing so ...


   -- Local/999@faxin-71c9;1 answered OOH323/192.168.25.1-5
   -- Got Fax Tone CED Chan Local/999@faxin-71c9;1 [0] Sending T.38 Params Peer Is OOH323/192.168.25.1-5 [1]
   -- Request on Local/999@faxin-71c9;1 [0] Storing I: OOH323/192.168.25.1-5 [1]
   -- Request on OOH323/192.168.25.1-5 [4] Ignoring I: Local/999@faxin-71c9;1 [0]
   -- T.38 Gateway starting for chan OOH323/192.168.25.1-5 and peer Local/999@faxin-71c9;1

that is why you getting error of type 11 on dahdi its a "modem" frame ...
By: Grigoriy Puzankin (boroda) 2011-05-13 09:57:15

I've tested the following patches with the same scenario.

Panasonic KX-FT938 @ Linksys SPA 9000 == <SIP G.711-voice/T.38-fax> == Asterisk 1.x [patched] == <Dynamic DAHDI> == ReceiveFAX @ Asterisk 1.8.2.3

Dialplan at patched Asterisk:

exten => _X.,1,Set(FAXOPT(t38gateway)=yes)
; for 1.8.3.2 same => n,FaxDetect(5)
same => n,Dial(DAHDI/G1/${EXTEN})
same => n,Hangup()

- asterisk-1.8.2_fax.2.patch
Segfaults after "Running Gateway activestate=4 (SIP/test-00000002) and inactivestate=0 (DAHDI/i7/123-3)"

- asterisk-1.8.3_2_fax.patch
Works only with FaxDetect application. Otherwise refuses T.38: "Called to deny a T38 reinvite if the core does not respond to our request"

- asterisk-1.8.4_fax.patch
Works fine even without FaxDetect. But there's no switchback to voice. Neither Linksys nor Asterisk sends re-INVITE to voice codec.
By: Niccolò Belli (darkbasic) 2011-05-13 11:17:55

You should try r318143 which reflects the latest changes. I will test it as soon as asterisk-1.8.4 gets released.
By: Gregory Hinton Nietsky (irroot) 2011-05-13 13:00:59

please be aware that this code is very much in flux as its moving to the framehook api and res_fax/res_fax_spandsp this is totally different from the original implementation the goal is for it to move into the mainline following the design spec the focus is on trunk but i am very committed to maintain 1.8 and have customers using it.

1.8.4 has not got the magic in it its in SVN and will be in 1.8.5-rc1 at least
By: Alexander Anikin (may213) 2011-05-14 18:37:06

few changed patch for the current trunk uploaded.
changes from previous are:
1. removed t38_gen generator, it's not a time-dependent function and it work with direct sending frames from t38_gateway (t38_tx_packet_handler) instance to t38 channel by ast_write
2. changed transmit_on_idle to FALSE. it must be configurable but suggest FALSE
here will reduce system usage.

tested on efax->t38modem->ooh323->sip(alaw)->pstn->hw fax chain.
By: Alexander Anikin (may213) 2011-05-14 18:47:02

Btw, t.38-t.30 conversion is a good process for timing modules testing.
res_timing_dahdi have stable fax sending at 14400 bps
res_timing_timerfd have unstable at 14400 and stable at 12000 (could be depend on kernel version)
res_timing_pthread doesnt work at 14400 and stable at 12000
By: Gregory Hinton Nietsky (irroot) 2011-05-15 03:04:32

@may213 thx for this most usefull ill be adding into the tree what "team" branch you use for ooh323 bits im using /irroot/t38_gateway-* i have the ooh323 bits i been fiddling in there too.

the problem with the patch is that t38_tx_packet_handler is used for fax terminal apps too so ill need to take this into account but not having T.38 on a gen makes sense
By: Niccolò Belli (darkbasic) 2011-05-15 15:44:27

Can you please tell me which commit did the magic so that I can backport it to 1.8.4?
By: sles (sles) 2011-05-15 23:38:12

irroot, thank you! I had not res_fax.

But, now, asterisk segfaults right after fax on far side accept call:

   -- DAHDI/i1/5308-1 is proceeding passing it to OOH323/192.168.22.253-9
   -- DAHDI/i1/5308-1 is making progress passing it to OOH323/192.168.22.253-9
   -- DAHDI/i1/5308-1 is ringing

and then segfault.

Program terminated with signal 11, Segmentation fault.
#0  0x00000000004ccd8a in ast_frame_free (frame=0x1, cache=1) at frame.c:377
377     frame = next, next = frame ? AST_LIST_NEXT(frame, frame_list) : NULL) {
(gdb) bt
#0  0x00000000004ccd8a in ast_frame_free (frame=0x1, cache=1) at frame.c:377
#1  0x0000000000474ec6 in ast_indicate_data (chan=0x1854cb58, _condition=22, data=0x1854d788, datalen=55) at channel.c:4421
#2  0x00002aaac333091c in wait_for_answer (in=0x1854cb58, outgoing=0x18542810, to=0x418d5fd4, peerflags=0x418d6470, opt_args=0x418d5720, pa=0x418d57e0,
   num_in=0x418d5fb0, result=0x418d57dc, dtmf_progress=0x0, ignore_cc=1) at app_dial.c:1261
#3  0x00002aaac33369d9 in dial_exec_full (chan=0x1854cb58, data=0x418d86c0 "DAHDI/g1/5308", peerflags=0x418d6470, continue_exec=0x0) at app_dial.c:2246
#4  0x00002aaac333947e in dial_exec (chan=0x1854cb58, data=0x418d86c0 "DAHDI/g1/5308") at app_dial.c:2753
ASTERISK-1  0x000000000050076b in pbx_exec (c=0x1854cb58, app=0x18419cd0, data=0x418d86c0 "DAHDI/g1/5308") at pbx.c:1406
ASTERISK-2  0x000000000050a718 in pbx_extension_helper (c=0x1854cb58, con=0x0, context=0x1854d0b0 "h323", exten=0x1854d100 "4406", priority=2, label=0x0,
   callerid=0x1855ddc0 "6401", action=E_SPAWN, found=0x418dae90, combined_find_spawn=1) at pbx.c:4085
ASTERISK-3  0x000000000050c079 in ast_spawn_extension (c=0x1854cb58, context=0x1854d0b0 "h323", exten=0x1854d100 "4406", priority=2, callerid=0x1855ddc0 "6401",
   found=0x418dae90, combined_find_spawn=1) at pbx.c:4608
ASTERISK-4  0x000000000050cb0a in __ast_pbx_run (c=0x1854cb58, args=0x0) at pbx.c:4706
ASTERISK-5  0x000000000050e7d0 in pbx_thread (data=0x1854cb58) at pbx.c:5017
ASTERISK-6 0x0000000000563635 in dummy_start (data=0x1853a130) at utils.c:973
ASTERISK-7 0x0000003f93a0673d in start_thread () from /lib64/libpthread.so.0
ASTERISK-8 0x0000003f92ed44bd in clone () from /lib64/libc.so.6


If I remove exten => 4406,1,SET(FAXOPT(t38gateway)=yes) all is OK.

btw, this is centos 5.6 on x86-64.
By: Gregory Hinton Nietsky (irroot) 2011-05-16 00:19:17

@sles you need to use a recent SVN as there is a bug in asterisk itself that will be in 1.8.5 at least not 1.8.4 and this looks like the problem experienced see ASTERISK-17784 and ASTERISK-17818 its a small patch to main/channel.c.

or get my 1.8 T38 branch

svn co http://svn.asterisk.org/svn/asterisk/team/irroot/t38gateway-1.8
By: Digium Subversion (svnbot) 2011-05-16 09:56:54

Repository: asterisk
Revision: 319087

U   trunk/CHANGES
U   trunk/channels/chan_sip.c
U   trunk/channels/sip/include/sip.h
U   trunk/res/res_fax.c

------------------------------------------------------------------------
r319087 | irroot | 2011-05-16 09:56:54 -0500 (Mon, 16 May 2011) | 16 lines

When a error in T.38 negotiation happens or its rejected on a channel the
state of the channel reverts to unknown this should be rejected.

this is important for negotiating T.38 gateway see ASTERISK-12667

This patch adds a option T38_REJECTED that behaves as T38_DISABLED except it reports state rejected.

Trivial Change to res_fax to honnor UNAVAILABLE and REJECTED states.

(closes issue ASTERISK-17478)
Reported by: irroot
Tested by: irroot, darkbasic, mnicholson

Review: https://reviewboard.asterisk.org/r/1115


------------------------------------------------------------------------

http://svn.digium.com/view/asterisk?view=rev&revision=319087
By: sles (sles) 2011-05-17 00:08:07

irroot, thank you!

I downloaded your branch, it works, if asterisk receives fax, but it crashes when it sends it from dahdi to ooh323:

  -- Executing [4406@dahdi:1] Set("DAHDI/i1/6401-26", "FAXOPT(t38gateway)=yes") in new stack
   -- Executing [4406@dahdi:2] Dial("DAHDI/i1/6401-26", "OOH323/5308") in new stack
   -- Called OOH323/5308
   -- OOH323/5308-9 is ringing
   -- OOH323/5308-9 is making progress passing it to DAHDI/i1/6401-26
   -- OOH323/5308-9 answered DAHDI/i1/6401-26
   -- fixed jitterbuffer created on channel DAHDI/i1/6401-26
   -- Channel 28 detected a CED tone towards the network.
   -- Request on OOH323/5308-9 [4] Ignoring I: DAHDI/i1/6401-26 [0]
   -- T.38 Gateway starting for chan DAHDI/i1/6401-26 and peer OOH323/5308-9
ast-ngdu2*CLI>
Disconnected from Asterisk server
Executing last minute cleanups
Asterisk cleanly ending (0).


here is backtrace:
Core was generated by `/usr/sbin/asterisk -f -U asterisk -G asterisk -p -vvvg -c'.
Program terminated with signal 11, Segmentation fault.
#0  t38_gateway_rx (s=0x2aaaabfc5c08, amp=0x0, len=160) at t38_gateway.c:2226
2226 {
(gdb) bt
#0  t38_gateway_rx (s=0x2aaaabfc5c08, amp=0x0, len=160) at t38_gateway.c:2226
#1  0x00002aaac5da737f in spandsp_fax_gateway_process (s=0x1e3bdfd8, f=0x40acdd70) at res_fax_spandsp.c:725
#2  0x00002aaac5da6c9c in spandsp_fax_write (s=0x1e3bdfd8, f=0x40acdd70) at res_fax_spandsp.c:579
#3  0x00002aaaab127fab in t38_gw_framehook (chan=0x1e3375a8, f=0x40acdd70, event=AST_FRAMEHOOK_EVENT_WRITE, data=0x1e27c538)
   at res_fax.c:2709
#4  0x00000000004d0788 in framehook_list_push_event (framehooks=0x1e327720, frame=0x40acdd70,
   event=AST_FRAMEHOOK_EVENT_WRITE) at framehook.c:83
ASTERISK-1  0x00000000004d0c80 in ast_framehook_list_write_event (framehooks=0x1e327720, frame=0x40acdd70) at framehook.c:178
ASTERISK-2  0x000000000047562b in ast_write (chan=0x1e3375a8, fr=0x40acdd70) at channel.c:4723
ASTERISK-3  0x0000000000422ddf in jb_get_and_deliver (chan=0x1e3375a8) at abstract_jb.c:424
ASTERISK-4  0x0000000000422b34 in ast_jb_get_and_deliver (c0=0x1e3375a8, c1=0x1e347b88) at abstract_jb.c:377
ASTERISK-5  0x000000000047e171 in ast_generic_bridge (c0=0x1e3375a8, c1=0x1e347b88, config=0x40acfd30, fo=0x40ace848, rc=0x40ace840)
   at channel.c:6844
ASTERISK-6 0x000000000048077d in ast_channel_bridge (c0=0x1e3375a8, c1=0x1e347b88, config=0x40acfd30, fo=0x40ace848, rc=0x40ace840)
   at channel.c:7288
ASTERISK-7 0x00000000004bc983 in ast_bridge_call (chan=0x1e3375a8, peer=0x1e347b88, config=0x40acfd30) at features.c:3612
ASTERISK-8 0x00002aaac33390ba in dial_exec_full (chan=0x1e3375a8, data=0x40ad26a0 "OOH323/5308", peerflags=0x40ad0450,
   continue_exec=0x0) at app_dial.c:2795
ASTERISK-9 0x00002aaac3339a0d in dial_exec (chan=0x1e3375a8, data=0x40ad26a0 "OOH323/5308") at app_dial.c:2895
ASTERISK-10 0x0000000000500c8f in pbx_exec (c=0x1e3375a8, app=0x2aaad00609c0, data=0x40ad26a0 "OOH323/5308") at pbx.c:1406
ASTERISK-11 0x000000000050ac6a in pbx_extension_helper (c=0x1e3375a8, con=0x0, context=0x1e337b00 "dahdi", exten=0x1e337b50 "4406",
   priority=2, label=0x0, callerid=0x1e327b10 "6401", action=E_SPAWN, found=0x40ad4e80, combined_find_spawn=1)
   at pbx.c:4102
ASTERISK-12 0x000000000050c5cb in ast_spawn_extension (c=0x1e3375a8, context=0x1e337b00 "dahdi", exten=0x1e337b50 "4406",
   priority=2, callerid=0x1e327b10 "6401", found=0x40ad4e80, combined_find_spawn=1) at pbx.c:4625
ASTERISK-13 0x000000000050d062 in __ast_pbx_run (c=0x1e3375a8, args=0x0) at pbx.c:4723
ASTERISK-14 0x000000000050ee11 in pbx_thread (data=0x1e3375a8) at pbx.c:5058
ASTERISK-15 0x0000000000563ef9 in dummy_start (data=0x1e2f9290) at utils.c:973
ASTERISK-16 0x0000003f93a0673d in start_thread () from /lib64/libpthread.so.0
ASTERISK-17 0x0000003f92ed44bd in clone () from /lib64/libc.so.6


Thank you very much for your work!
By: Gregory Hinton Nietsky (irroot) 2011-05-17 00:56:02

@sles what version of spandsp you running ?? this error is inside spandsp i may be able to prevent it latter this morning thank you for the testing also please try it without the jitterbuffer ...
By: sles (sles) 2011-05-17 01:51:10

Hello!

I use spandsp-0.0.6pre18.

jitter buffer disabling helps, fax passed at second attempt :-) :

ast-ngdu2*CLI>
   -- Accepting call from '6558' to '4406' on channel 0/6, span 1
   -- Executing [4406@dahdi:1] Set("DAHDI/i1/6558-2", "FAXOPT(t38gateway)=yes") in new stack
   -- Executing [4406@dahdi:2] Dial("DAHDI/i1/6558-2", "OOH323/5308") in new stack
   -- Called OOH323/5308
   -- OOH323/5308-1 is ringing
   -- OOH323/5308-1 is making progress passing it to DAHDI/i1/6558-2
   -- OOH323/5308-1 answered DAHDI/i1/6558-2
   -- Channel 6 detected a CED tone towards the network.
   -- Request on OOH323/5308-1 [4] Ignoring I: DAHDI/i1/6558-2 [0]
   -- T.38 Gateway starting for chan DAHDI/i1/6558-2 and peer OOH323/5308-1
 == Spawn extension (dahdi, 4406, 2) exited non-zero on 'DAHDI/i1/6558-2'
   -- Connection Statistics
Bit Rate :0
ECM : No
Pages : 0
   -- Hungup 'DAHDI/i1/6558-2'
   -- Accepting call from '6558' to '4406' on channel 0/7, span 1
   -- Executing [4406@dahdi:1] Set("DAHDI/i1/6558-3", "FAXOPT(t38gateway)=yes") in new stack
   -- Executing [4406@dahdi:2] Dial("DAHDI/i1/6558-3", "OOH323/5308") in new stack
   -- Called OOH323/5308
   -- OOH323/5308-2 is ringing
   -- OOH323/5308-2 is making progress passing it to DAHDI/i1/6558-3
   -- OOH323/5308-2 answered DAHDI/i1/6558-3
   -- Channel 7 detected a CED tone towards the network.
   -- Request on OOH323/5308-2 [4] Ignoring I: DAHDI/i1/6558-3 [0]
   -- T.38 Gateway starting for chan DAHDI/i1/6558-3 and peer OOH323/5308-2
 == Spawn extension (dahdi, 4406, 2) exited non-zero on 'DAHDI/i1/6558-3'
   -- Connection Statistics
Bit Rate :7200
ECM : No
Pages : 1
   -- Hungup 'DAHDI/i1/6558-3'


Anyway, I'd like to use jitter buffer in production environment.
Thank you!
By: Gregory Hinton Nietsky (irroot) 2011-05-17 02:28:39

@sles added NULL frame data check in SVN please "svn up" and try hope this resolves the issue.
By: sles (sles) 2011-05-17 07:45:12

thank you!
great!

it works! :-D

what is strange - passed from second attempt again, but this is very good anyway!

:-)
By: sles (sles) 2011-05-17 07:54:02

tested once again- only 1/2 (1 passes, 1 not) of all faxes passes when asterisk sending :-(

btw, will asterisk switch back to voice after fax? I have only automatic fax machines for test, so I can't test this, but this is interesting :-)
By: Grigoriy Puzankin (boroda) 2011-05-17 08:19:39

Some fax machines (non-virtual) have an option to handshake with longer delays if the previous attempt failed. Fax machine turns off this option automatically after a successful transmission.
By: Gregory Hinton Nietsky (irroot) 2011-05-17 08:36:44

strange that when i test they very reliable seldom get a retry ... im glad it works and yeah good point i should look at that ... the frame hook will only process frames when there is a gateway needed so if the channel T.38 mode changes it will return the packet unchanged to asterisk so should work if the endpoints alter T.38 state.

really appreciate the testing and feedback.
By: sles (sles) 2011-05-19 22:31:58

Hello!

irroot, I'm sorry asking you this, but...
I tried to install your brunch on production server and got problem with no sound with SIP calls to avaya (know nothing about this avaya ;-) - it is in our owner company).
1.8.4 has no such problem.
Unfortunately, I don't have an ability to get debug info yet.
Could you tell me can this problem be related to t38 gateway?
By: Gregory Hinton Nietsky (irroot) 2011-05-20 04:08:41

@sles this is odd the changes to chan_sip are to correctly report refused status of T.38 and nothing more so cant think of any reason this will affect it my branch is 1.8.5 not yet at RC1 so this could be related to some other issue post 1.8.4
By: Steve (802) 2011-05-21 09:46:37

Using  SVN-irroot-t38gateway-1.8-r320164M

try two setups
fax -> DAHDI> SIP-> Dahdi ->PSTN-> fax

T38Modem -> SIP -> DAHDI -> FAX

on both getting T.38 setting up but the lots of t.30 no signal and the fax fails


   -- Called DAHDI/g2/0430
   -- DAHDI/i5/0430-3 is proceeding passing it to SIP/192.168.101.4-00000003
   -- DAHDI/i5/0430-3 is ringing
   -- DAHDI/i5/0430-3 answered SIP/192.168.101.4-00000003
   -- fixed jitterbuffer created on channel DAHDI/i5/0430-3
   -- Channel 13 echo canceler disabled its NLP.
   -- Channel 13 detected a CED tone from the network.
   -- Got Fax Tone CED Chan DAHDI/i5/0430-3 [0] Sending T.38 Params Peer Is SIP/192.168.101.4-00000003 [1]
   -- Request on DAHDI/i5/0430-3 [0] Storing I: SIP/192.168.101.4-00000003 [1]
   -- Negotiated on SIP/192.168.101.4-00000003 [4] Ignoring I: DAHDI/i5/0430-3 [0]
   -- T.38 Gateway starting for chan SIP/192.168.101.4-00000003 and peer DAHDI/i5/0430-3

   -- Hungup 'DAHDI/i5/0430-3'
   -- fixed jitterbuffer destroyed on channel DAHDI/i5/0430-3

   -- Connection Statistics
       Bit Rate :0
       ECM : No
       Pages : 0

Ive Attached packet captures
By: Gregory Hinton Nietsky (irroot) 2011-05-21 10:53:31

T.30 packets are sent out of a generator what timmer are you using its important to have the timing spot on check modules.conf add noload res_timing_fd.so

as you have a dahdi chan you should have good timing with it ...

thx for testing
By: Steve (802) 2011-05-22 03:52:23

Using DAHDI for timing, it's source is the telco(ISDN), timing is perfect as i can fax over alaw & g726 ok on the same links, timing as follows

Module                         Description                              Use Count
res_timing_dahdi.so            DAHDI Timing Interface                   1
1 modules loaded


I think something else is up? I've tried a few setups with different machines all the same problem.
By: Gregory Hinton Nietsky (irroot) 2011-05-22 04:25:17

ok in res/res_spandsp_fax.c  change the "transmit_on_idle" setting please this has caused me some issues i have it set TRUE this works best for me ...
By: Steve (802) 2011-05-22 04:46:04

thats sets already in the revision I have

/* need to be configrable FAXOPT ??*/
       t38_gateway_set_transmit_on_idle(&p->t38_gw_state, TRUE);
       t38_set_sequence_number_handling(p->t38_core_state, TRUE);
       t38_gateway_set_supported_modems(&p->t38_gw_state, T30_SUPPORT_V27TER | T30_SUPPORT_V17 | T30_SUPPORT_V29);
By: sles (sles) 2011-05-22 22:35:49

irroot, I downloaded and installed SVN-branch-1.8-r320162 .
It has no problems with SIP connection to avaya.
Can I apply your patches on it? Will it work as t38 gateway?
If yes- I'll test this asap :-)
By: Gregory Hinton Nietsky (irroot) 2011-05-23 00:20:38

@sles indeed ill upload a new patch here soon res/res_fax.c res/res_fax_spandsp.c include/asterisk/res_fax.h are the only files that are needed the changes to chan_sip.c are for managing rejected T.38 and as you use OOH323 this should not affect you ...
By: sles (sles) 2011-05-23 00:45:35

thank you!

I use h323 in our internal network and it works OK (at least in quick tests) with you branch.
Unfortunately, I also have SIP trunk to our head company and here I have problem with your branch :-( What is good- I don't need t38-t30 gateway in this link :-)
By: Gregory Hinton Nietsky (irroot) 2011-06-03 08:34:42

new patch up this is agaist svn 321680 [> asterisk 1.8.5-rc1] yet to be released.
By: Daniele Gallina (gallysoft) 2011-06-04 03:38:40

Hi.
I have the same problem than 802.
Timing is DAHDI, Asterisk is SVN-branch-1.8-r321547M.

sip2*CLI> udptl set debug on
UDPTL Debugging Enabled

   -- Executing [0415161655@from_fax:1] Set("IAX2/fax0510980903-1769", "FAXOPT(t38gateway)=yes") in new stack
   -- Executing [0415161655@from_fax:2] Dial("IAX2/fax0510980903-1769", "SIP/0415161655@3ps_3p_cosmf,120") in new stack
 == Using UDPTL CoS mark 5
 == Using SIP RTP CoS mark 5
   -- Called SIP/0415161655@3ps_3p_cosmf
   -- SIP/3ps_3p_cosmf-00000001 is making progress passing it to IAX2/fax0510980903-1769
   -- SIP/3ps_3p_cosmf-00000001 answered IAX2/fax0510980903-1769
   -- Request on SIP/3ps_3p_cosmf-00000001 [2] Queueing I: IAX2/fax0510980903-1769 [0]
   -- Request on IAX2/fax0510980903-1769 [0] Storing I: SIP/3ps_3p_cosmf-00000001 [2]
   -- Negotiated on SIP/3ps_3p_cosmf-00000001 [4] Ignoring I: IAX2/fax0510980903-1769 [0]
   -- T.38 Gateway starting for chan IAX2/fax0510980903-1769 and peer SIP/3ps_3p_cosmf-00000001
UDPTL (SIP/0415161655): packet to 80.79.54.80:4586 (type 0, seq 0, len 6)

 == Spawn extension (from_fax, 0415161655, 2) exited non-zero on 'IAX2/fax0510980903-1769'
   -- Connection Statistics
       Bit Rate :0
       ECM : No
       Pages : 0
   -- Hungup 'IAX2/fax0510980903-1769'
By: Gregory Hinton Nietsky (irroot) 2011-06-04 03:50:10

gallysoft the IAX channel is U/A Law ?? the CED tone is been detected and the negotiation is happening  ...

at least one T.38 packet went out of the system and nothing further ...
By: Daniele Gallina (gallysoft) 2011-06-06 07:14:32.474-0500

Hi Gregory.
IAX channel il alaw, but I have tried also with slin.
SIP/3ps_3p_cosmf works well in t.38 with a GS HT-502.
What do you suggest me to do?
By: Daniele Gallina (gallysoft) 2011-06-06 09:59:28.069-0500

I have the same problem with SendFax.
Sending with call file:

   -- Attempting call on SIP/3ps_3p_cosmf/0415161655 for s@from_fax:1 (Retry 1)
 == Using UDPTL CoS mark 5
 == Using SIP RTP CoS mark 5
   -- Executing [s@from_fax:1] Set("SIP/3ps_3p_cosmf-00000001", "FAXOPT(t38gateway)=yes") in new stack
   -- Executing [s@from_fax:2] SendFAX("SIP/3ps_3p_cosmf-00000001", "/tmp/1299597946.58.tif") in new stack
   -- Channel 'SIP/3ps_3p_cosmf-00000001' sending FAX:
   --    /tmp/1299597946.58.tif
UDPTL (SIP/0415161655): packet to 80.79.54.80:4733 (type 0, seq 0, len 6)
UDPTL (SIP/0415161655): packet to 80.79.54.80:4733 (type 0, seq 1, len 8)
 == Spawn extension (from_fax, s, 2) exited non-zero on 'SIP/3ps_3p_cosmf-00000001'
[Jun  6 16:46:06] NOTICE[17432]: pbx_spool.c:362 attempt_thread: Call completed to SIP/3ps_3p_cosmf/0415161655

By: Dmitry Melekhov (slesru) 2011-06-07 00:36:22.852-0500

Hello!

Thank you! Latest patch looks good, I just installed it on production server :-)
If there will be problems I'll report :-)

By: Robert Thomas (thomcr) 2011-06-09 01:08:04.037-0500

What changes do we need for this to work with chanss7? I'll be testing this tomorrow on a live SS7 link with libss7 but I plan to use chanss7 for the long term. On the previous patch (1.6.2.9) we had to make the same modification from chan_dahdi to chan_ss7 to force T38 to refuse and the GW to kick in.

What about the patch for 1.8
By: Gregory Hinton Nietsky (irroot) 2011-07-01 06:34:28.825-0500

Ok this code has now been submited to asterisk-trunk.

the patch t38gateway-1.8.5.patch is a backport from trunk and will only work on asterisk >= 1.8.5

perhaps its time to finally close this issue

this patch is from svn branch.

team/irroot/t38gateway-1.8/
By: Gregory Hinton Nietsky (irroot) 2011-07-02 12:17:14.723-0500

Here is the full backport for all versions of 1.8

the framehook patch is required for pre 1.8.5 to fix some bugs in the framehook api.
if using a version prior to 1.8.5 this patch must be applied.

the faxgateway patch is a backport from trunk.
By: Gregory Hinton Nietsky (irroot) 2011-07-02 12:21:45.887-0500

Last upload triggered a bug in jira when trying to mark it as code.
By: copas2 (copas2) 2011-07-13 03:45:34.223-0500

Hello dear Devs, irroot,
I have a problem with the latest irroot t38gateway-1.8 trunk (revision 328009). The scenario is the following:
fax-machine on PSTN / Asterisk(t38gw-DAHDI(B410P)) / fax-machine on SPA2102 (VoIP(T.38))
There seems to be a communication error in the T.38 conversation because the call is prematurely dropped by the VoIP side. I'm not familiar with the insides of the T.38 protocol but I've already made fax gateways with CallWeaver and FreeSwitch. But since I'm sticked to Asterisk, I would really be able to use it as a T.38 gateway.
Any ideas why the transmission fails? Thank you.

|Time     | 10.199.0.1                            |
|         |                   | 10.199.253.249    |                  
|58,378   |         INVITE SDP (g711A telephone-eventRTPType-101)          |SIP From: <sip:XX@10.199.0.1 To:<sip:XXX@10.199.253.249:5061
|         |(5060)   ------------------>  (5061)   |
|58,391   |         100 Trying|                   |SIP Status
|         |(5060)   <------------------  (5061)   |
|58,399   |         180 Ringing                   |SIP Status
|         |(5060)   <------------------  (5061)   |
|63,470   |         200 OK SDP (g711A NSERTPType-100 telephone-eve...TPType-101)          |SIP Status
|         |(5060)   <------------------  (5061)   |
|63,471   |         ACK       |                   |SIP Request
|         |(5060)   ------------------>  (5061)   |
|63,478   |         RTP (g711A)                   |RTP Num packets:123  Duration:2.439s SSRC:0x1D7F0E9C
|         |(17776)  ------------------>  (16408)  |
|63,499   |         RTP (g711A)                   |RTP Num packets:123  Duration:2.440s SSRC:0x729DABA4
|         |(17776)  <------------------  (16408)  |
|65,920   |         INVITE SDP (t38)              |SIP Request
|         |(5060)   <------------------  (5061)   |
|65,921   |         100 Trying|                   |SIP Status
|         |(5060)   ------------------>  (5061)   |
|65,922   |         200 OK SDP (t38)              |SIP Status
|         |(5060)   ------------------>  (5061)   |
|65,933   |         ACK       |                   |SIP Request
|         |(5060)   <------------------  (5061)   |
|65,962   |         no-signal |                   |t38:t30 Ind:no-signal
|         |(20615)  <------------------  (16408)  |
|66,019   |         ced       |                   |t38:t30 Ind:ced
|         |(20615)  <------------------  (16408)  |
|68,822   |         v21-preamble                  |t38:t30 Ind:v21-preamble
|         |(20615)  <------------------  (16408)  |
|70,723   |         CSI Num: Fax                  |t38:v21:HDLC:Called Subscriber Identification
|         |(20615)  <------------------  (16408)  |
|71,203   |         DIS DSR:ITU-T V.27 ter, V.29, and V.17          |t38:v21:HDLC:Digital Identification Signal
|         |(20615)  <------------------  (16408)  |
|71,222   |         no-signal |                   |t38:t30 Ind:no-signal
|         |(20615)  <------------------  (16408)  |
|71,818   |         v21-preamble                  |t38:t30 Ind:v21-preamble
|         |(20615)  ------------------>  (16408)  |
|73,078   |         DCS DSR:9600 bit/s, ITU-T V.29          |t38:v21:HDLC:Digital Command Signal
|         |(20615)  ------------------>  (16408)  |
|73,158   |         no-signal |                   |t38:t30 Ind:no-signal
|         |(20615)  ------------------>  (16408)  |
|73,238   |         v29-9600-training             |t38:t30 Ind:v29-9600-training
|         |(20615)  ------------------>  (16408)  |
|73,519   |         t4-non-ecm-data:v29-9600          |t38:t4-non-ecm-data:v29-9600 Duration: 1,78s No packet lost
|         |(20615)  ------------------>  (16408)  |
|75,299   |         no-signal |                   |t38:t30 Ind:no-signal
|         |(20615)  ------------------>  (16408)  |
|75,543   |         v21-preamble                  |t38:t30 Ind:v21-preamble
|         |(20615)  <------------------  (16408)  |
|76,823   |         CFR       |                   |t38:v21:HDLC:Confirmation To Receive
|         |(20615)  <------------------  (16408)  |
|76,884   |         no-signal |                   |t38:t30 Ind:no-signal
|         |(20615)  <------------------  (16408)  |
|77,279   |         v29-9600-training             |t38:t30 Ind:v29-9600-training
|         |(20615)  ------------------>  (16408)  |
|89,249   |         BYE       |                   |SIP Request
|         |(5060)   <------------------  (5061)   |
|89,249   |         200 OK    |                   |SIP Status
|         |(5060)   ------------------>  (5061)   |

By: Steve (802) 2011-07-19 11:39:29.288-0500

Seeing exactly the same behaviour as copas here, both with irroot branch and also patch against 1.8.5
By: Matthew Nicholson (mnicholson) 2011-07-19 11:48:27.296-0500

Please test with asterisk 10.
By: Dmitry Melekhov (slesru) 2011-07-21 02:57:02.720-0500

Hello!

Just installed 1.8.5.0 , patched it with faxgateway-1.8.patch and looks like it doesn't work with ooh323 at all.
dialplan:

console:

exten => 4406,1,SET(FAXOPT(t38gateway)=yes)  
exten =>4406,n,Dial(OOH323/5308)      

  -- Executing [4406@dahdi:1] Set("DAHDI/i1/6401-6", "FAXOPT(t38gateway)=yes") in new stack
   -- Executing [4406@dahdi:2] Dial("DAHDI/i1/6401-6", "OOH323/5308") in new stack
   -- Called OOH323/5308
   -- OOH323/5308-3 is ringing
   -- OOH323/5308-3 is making progress passing it to DAHDI/i1/6401-6
   -- OOH323/5308-3 answered DAHDI/i1/6401-6
   -- fixed jitterbuffer created on channel DAHDI/i1/6401-6
   -- Channel 19 detected a CED tone towards the network.
   -- Span 1: Channel 0/19 got hangup request, cause 16

no info about T38 at all...

fax modules are loaded:

ast-ngdu2*CLI> module show like fax
Module                         Description                              Use Count
res_fax.so                     Generic FAX Applications                 1        
app_faxdetect.so               Generic FAX Applications                 0        
res_fax_spandsp.so             Spandsp G.711 and T.38 FAX Technologies  2        
3 modules loaded

By: Dmitry Melekhov (slesru) 2011-07-21 03:16:12.528-0500

btw, asked colleague to send fax:

   -- Accepting call from '6558' to '4406' on channel 0/20, span 1
   -- Executing [4406@dahdi:1] Set("DAHDI/i1/6558-7", "FAXOPT(t38gateway)=yes") in new stack
   -- Executing [4406@dahdi:2] Dial("DAHDI/i1/6558-7", "OOH323/5308") in new stack
   -- Called OOH323/5308
   -- OOH323/5308-4 is ringing
   -- OOH323/5308-4 is making progress passing it to DAHDI/i1/6558-7
   -- OOH323/5308-4 answered DAHDI/i1/6558-7
   -- fixed jitterbuffer created on channel DAHDI/i1/6558-7
   -- Channel 20 detected a CED tone towards the network.
[Jul 21 11:57:49] WARNING[30055]: chan_dahdi.c:9189 dahdi_write: Don't know what to do with frame type '11'
[Jul 21 11:57:49] WARNING[30055]: chan_dahdi.c:9189 dahdi_write: Don't know what to do with frame type '11'
[Jul 21 11:57:50] WARNING[30055]: chan_dahdi.c:9189 dahdi_write: Don't know what to do with frame type '11'
[Jul 21 11:57:50] WARNING[30055]: chan_dahdi.c:9189 dahdi_write: Don't know what to do with frame type '11'

By: copas2 (copas2) 2011-07-22 09:27:39.276-0500

And what about your branch, Matt? Which derivated from 1.8.
By: Matthew Nicholson (mnicholson) 2011-07-22 09:33:57.444-0500

I am not sure what you are referring to. I don't have a branch.
By: copas2 (copas2) 2011-07-22 10:09:29.122-0500

Matt: I've tested it with latest from svn branch (DAHDI and Asterisk-10). The results are the same with T.38 gatewaying as before, no need to repost them.
By: Matthew Nicholson (mnicholson) 2011-07-22 10:21:39.298-0500

I am having a hard time understanding what exactly is going on here. Please test with asterisk 10 using chan_sip (and chan_dahdi if appropriate). Capture a pcap using 'tcpdump -w /tmp/t38gateway.pcap -s1500 -vv' and upload that pcap on the ticket. You can remove any data you don't want others to see from the pcap using wireshark.
By: Gregory Hinton Nietsky (irroot) 2011-07-22 10:25:23.364-0500

@Dimitry the logging changed to debug level 1 as it is in 10 ...
im adding the v21 code to 1.8

the branch is
/team/irroot/t38gateway-1.8
By: Gregory Hinton Nietsky (irroot) 2011-07-23 06:29:22.744-0500

Latest Backport adding recent changes.
By: copas2 (copas2) 2011-07-23 11:06:41.465-0500

Matthew: sorry, I ment irroot's (Gregory's) branch but I was confused with your real names versus the nicks from the old bug tracking system.
By: copas2 (copas2) 2011-07-23 13:17:35.720-0500

Asterisk 10 T.38gw fails.
Attached faxgwt38ast10.zip...
( strange this Jira is... :) )
By: Dmitry Melekhov (slesru) 2011-07-25 01:14:56.088-0500

I did core set debug 10 and still have no messages about t38.
and I installed latest t38gateway-1.8 branch and result is the same- no messages about (with debug 10) and fax doesn't pass...

By: Matthew Nicholson (mnicholson) 2011-07-25 08:46:34.843-0500

In the pcap you posted, there is some fax activity, the receiving side indicates that it is ready to receive, then it disconnects the line about 14 seconds later.  That looks like some sort of timeout. Please upload the full log file from a failure with core debugging and fax debugging enabled.

Also please describe the topology of your setup.
By: copas2 (copas2) 2011-07-28 14:09:06.316-0500

Topology already described here in previous comment https://issues.asterisk.org/jira/browse/ASTERISK-12667?focusedCommentId=179819&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-179819
What do you mean by fax debugging?
By: Matthew Nicholson (mnicholson) 2011-07-28 14:55:14.723-0500

You can turn fax debugging on using 'fax set debug on' from the asterisk CLI.
By: copas2 (copas2) 2011-08-01 03:53:34.762-0500

I attached faxlog.txt
Sorry but this is an in-production pbx, so the log contains some garbage.
I turned fax logging on but I couldn't really see any rows that would state any progression of the flow itself.
By: Dmitry Melekhov (slesru) 2011-08-02 01:57:57.701-0500

Hello!

just tested 10beta1 and it still doesn't with ooh323- no messages about t38 at all..

By: Matthew Nicholson (mnicholson) 2011-08-02 14:38:03.537-0500

I'll have to do some testing of this with dahdi.  The debug you posted shows the gateway starting but doesn't show any information after that. That may be because you didn't have fax debugging enabled, and it may be because of some bug in the code.
By: Matthew Nicholson (mnicholson) 2011-08-04 15:54:02.067-0500

I tested this with dahdi locally and it appears to be working fine on my system. FYI. I still need to do some more testing to see what kind of debug output the gateway will provide. I'll have to rework my test bed a little for that though.
By: Matthew Nicholson (mnicholson) 2011-08-04 15:58:41.574-0500

I am going to close this issue. Please open a new issue for each bug you are experiencing and link them back to this issue. Please be sure to test with asterisk 10.
By: Dmitry Melekhov (slesru) 2011-08-16 23:33:54.967-0500

Hello!

I wrote here several times about not workig t38 gateway in 10beta1 , but no replies.
So I created another issue https://issues.asterisk.org/jira/browse/ASTERISK-18219 .
Now I know that t38 gateway doesn't work if jbenable=yes in chan_dahdi.conf.
Looks like Gregory Hinton Nietsky already fixed this in his branch here:
"added NULL frame data check in SVN please "svn up" and try hope this resolves the issue."

Could you add this fix to asterisk 10?
Thank you!
By: Steve (802) 2011-08-22 11:21:01.369-0500

Agreeing With Dmitry
jbenable=yes issue needs urgent fixing
By: Matthew Nicholson (mnicholson) 2011-08-22 11:28:20.475-0500

Please open a new bug for any additional issues. You can reference it here so that I will see it. Be sure to include relevant debug information (full logs with debug level set to 1 and 'fax set debug on').
By: Niccolò Belli (darkbasic) 2011-09-27 16:13:51.842-0500

Can someone please post a patch against 1.8.7?

Thanks,
Darkbasic
By: Gregory Hinton Nietsky (irroot) 2011-09-28 12:26:07.704-0500

With asterisk 10-beta2 out and this code included in there i recommend using it or get the
code/patch from svn in branch team/irroot.

thank you for all the support and testing.
By: Niccolò Belli (darkbasic) 2011-09-28 14:43:03.174-0500

Didn't notice your t38gateway-1.8 branch, I made I patch for 1.8.7 from it.
Thanks
By: Niccolò Belli (darkbasic) 2011-10-02 17:14:29.346-0500

I tested your branch, unfortunately while incoming faxes do work very well outgoing faxes don't: I didn't succeed to send a single fax with t38 on (while I had no problems with Set(FAXOPT(gateway)=no)).

This is especially sad considering I need t.38 only for outgoing faxes :(
By: Aleksandr Gordeev (axonaro) 2011-10-04 02:57:10.816-0500

With patch (https://issues.asterisk.org/view.php?id=13405) :
faxgateway-1.8.patch2 [^] (84,979 bytes) 2011-06-03 08:28 [wget patch] [License OK (v3.0)]
not work attended transef, blind transfer is work.
By: Marc (rustine22) 2011-10-18 04:14:23.147-0500

Hello,
In asterisk 10 beta.
I'm tryign to send fax using Asterisk T38 Gateway : Not working : it repeat 3 times DSI/CIS sequence en BYE. Whith same source fax and destination fax, when i use a SPA2102 with T38 enabled, it works !! See capture :

With asterisk 10 beta (T38 Gateway is 109.77.77.10) => FAIL :

|Time     | 109.77.77.10                          |
|         |                   | 109.77.77.9       |                  
|35,152   |         INVITE SDP (g711A GSM g711U telephone-eventRTP...e-101)          |SIP From: "100" <sip:100@109.77.77.10 To:<sip:0411111111@109.77.77.9
|         |(5060)   ------------------>  (5060)   |
|35,152   |         100 Trying|                   |SIP Status
|         |(5060)   <------------------  (5060)   |
|36,540   |         180 Ringing                   |SIP Status
|         |(5060)   <------------------  (5060)   |
|36,540   |         183 Session Progress SDP (g711A g711U GSM tele...ne-eventRTPType-101)          |SIP Status
|         |(5060)   <------------------  (5060)   |
|36,658   |         RTP (g711U)                   |RTP Num packets:771  Duration:15.399s SSRC:0x3400AA55
|         |(15162)  ------------------>  (11708)  |
|36,677   |         RTP (g711U)                   |RTP Num packets:877  Duration:17.603s SSRC:0x2AB49D5C
|         |(15162)  <------------------  (11708)  |
|52,075   |         200 OK SDP (g711A g711U GSM telephone-eventRTP...e-101)          |SIP Status
|         |(5060)   <------------------  (5060)   |
|52,076   |         ACK       |                   |SIP Request
|         |(5060)   ------------------>  (5060)   |
|52,078   |         RTP (g711U)                   |RTP Num packets:246  Duration:4.898s SSRC:0x3400AA55
|         |(15162)  ------------------>  (11708)  |
|56,981   |         INVITE SDP (t38)              |SIP Request
|         |(5060)   <------------------  (5060)   |
|56,981   |         100 Trying|                   |SIP Status
|         |(5060)   ------------------>  (5060)   |
|57,083   |         200 OK SDP (t38)              |SIP Status
|         |(5060)   ------------------>  (5060)   |
|57,083   |         no-signal |                   |t38:t30 Ind:no-signal
|         |(4191)   ------------------>  (4873)   |
|57,083   |         ACK       |                   |SIP Request
|         |(5060)   <------------------  (5060)   |
|57,125   |         no-signal |                   |t38:t30 Ind:no-signal
|         |(4191)   ------------------>  (4873)   |
|59,921   |         no-signal |                   |t38:t30 Ind:no-signal
|         |(4191)   <------------------  (4873)   |
|64,962   |         v21-preamble                  |t38:t30 Ind:v21-preamble
|         |(4191)   <------------------  (4873)   |
|66,623   |         NSF       |                   |t38:v21:HDLC:Non-Standard Facilities
|         |(4191)   <------------------  (4873)   |
|67,343   |         CSI Num: 0411111111           |t38:v21:HDLC:Called Subscriber Identification
|         |(4191)   <------------------  (4873)   |
|67,703   |         DIS DSR:ITU-T V.27 ter and V.29          |t38:v21:HDLC:Digital Identification Signal
|         |(4191)   <------------------  (4873)   |
|67,763   |         no-signal |                   |t38:t30 Ind:no-signal
|         |(4191)   <------------------  (4873)   |
|72,844   |         v21-preamble                  |t38:t30 Ind:v21-preamble
|         |(4191)   <------------------  (4873)   |
|74,485   |         NSF       |                   |t38:v21:HDLC:Non-Standard Facilities
|         |(4191)   <------------------  (4873)   |
|75,204   |         CSI Num: 0411111111           |t38:v21:HDLC:Called Subscriber Identification
|         |(4191)   <------------------  (4873)   |
|75,564   |         DIS DSR:ITU-T V.27 ter and V.29          |t38:v21:HDLC:Digital Identification Signal
|         |(4191)   <------------------  (4873)   |
|75,625   |         no-signal |                   |t38:t30 Ind:no-signal
|         |(4191)   <------------------  (4873)   |
|80,700   |         v21-preamble                  |t38:t30 Ind:v21-preamble
|         |(4191)   <------------------  (4873)   |
|82,361   |         NSF       |                   |t38:v21:HDLC:Non-Standard Facilities
|         |(4191)   <------------------  (4873)   |
|83,081   |         CSI Num: 0411111111           |t38:v21:HDLC:Called Subscriber Identification
|         |(4191)   <------------------  (4873)   |
|83,441   |         DIS DSR:ITU-T V.27 ter and V.29          |t38:v21:HDLC:Digital Identification Signal
|         |(4191)   <------------------  (4873)   |
|83,501   |         no-signal |                   |t38:t30 Ind:no-signal
|         |(4191)   <------------------  (4873)   |
|86,098   |         BYE       |                   |SIP Request
|         |(5060)   ------------------>  (5060)   |
|86,099   |         200 OK    |                   |SIP Status
|         |(5060)   <------------------  (5060)   |


With SPA2102 T38 enabled mode (asterisk 10 beta is T38 passthrough) => SUCCESS:

|Time     | 109.77.77.10                          |
|         |                   | 109.77.77.9       |                  
|6,898    |         INVITE SDP (t38)              |SIP From: "100" <sip:100@109.77.77.10 To:<sip:0411111111@109.77.77.9
|         |(5060)   ------------------>  (5060)   |
|6,898    |         100 Trying|                   |SIP Status
|         |(5060)   <------------------  (5060)   |
|6,928    |         200 OK SDP (t38)              |SIP Status
|         |(5060)   <------------------  (5060)   |
|6,929    |         ACK       |                   |SIP Request
|         |(5060)   ------------------>  (5060)   |
|7,034    |         no-signal |                   |t38:t30 Ind:no-signal
|         |(4158)   ------------------>  (4992)   |
|8,983    |         ced       |                   |t38:t30 Ind:ced
|         |(4158)   <------------------  (4992)   |
|11,648   |         v21-preamble                  |t38:t30 Ind:v21-preamble
|         |(4158)   <------------------  (4992)   |
|13,068   |         NSF       |                   |t38:v21:HDLC:Non-Standard Facilities
|         |(4158)   <------------------  (4992)   |
|13,768   |         CSI Num: 0411111111           |t38:v21:HDLC:Called Subscriber Identification
|         |(4158)   <------------------  (4992)   |
|14,110   |         DIS DSR:ITU-T V.27 ter and V.29          |t38:v21:HDLC:Digital Identification Signal
|         |(4158)   <------------------  (4992)   |
|14,208   |         no-signal |                   |t38:t30 Ind:no-signal
|         |(4158)   <------------------  (4992)   |
|14,957   |         v21-preamble                  |t38:t30 Ind:v21-preamble
|         |(4158)   ------------------>  (4992)   |
|16,697   |         TSI Num: Fax                  |t38:v21:HDLC:Transmitting Subscriber Identification
|         |(4158)   ------------------>  (4992)   |
|17,156   |         DCS DSR:9600 bit/s, ITU-T V.29          |t38:v21:HDLC:Digital Command Signal
|         |(4158)   ------------------>  (4992)   |
|17,176   |         no-signal |                   |t38:t30 Ind:no-signal
|         |(4158)   ------------------>  (4992)   |
|17,197   |         v29-9600-training             |t38:t30 Ind:v29-9600-training
|         |(4158)   ------------------>  (4992)   |
|17,697   |         t4-non-ecm-data:v29-9600          |t38:t4-non-ecm-data:v29-9600 Duration: 1,50s No packet lost
|         |(4158)   ------------------>  (4992)   |
|19,214   |         no-signal |                   |t38:t30 Ind:no-signal
|         |(4158)   ------------------>  (4992)   |
|19,889   |         v21-preamble                  |t38:t30 Ind:v21-preamble
|         |(4158)   <------------------  (4992)   |
|21,005   |         CFR       |                   |t38:v21:HDLC:Confirmation To Receive
|         |(4158)   <------------------  (4992)   |
|21,104   |         no-signal |                   |t38:t30 Ind:no-signal
|         |(4158)   <------------------  (4992)   |
|22,077   |         v29-9600-training             |t38:t30 Ind:v29-9600-training
|         |(4158)   ------------------>  (4992)   |
|22,097   |         t4-non-ecm-data:v29-9600          |t38:t4-non-ecm-data:v29-9600 Duration: 49,07s No packet lost
|         |(4158)   ------------------>  (4992)   |
|71,192   |         no-signal |                   |t38:t30 Ind:no-signal
|         |(4158)   ------------------>  (4992)   |
|71,354   |         v21-preamble                  |t38:t30 Ind:v21-preamble
|         |(4158)   ------------------>  (4992)   |
|72,455   |         EOP       |                   |t38:v21:HDLC:End Of Procedure
|         |(4158)   ------------------>  (4992)   |
|72,534   |         no-signal |                   |t38:t30 Ind:no-signal
|         |(4158)   ------------------>  (4992)   |
|72,926   |         v21-preamble                  |t38:t30 Ind:v21-preamble
|         |(4158)   <------------------  (4992)   |
|74,066   |         MCF       |                   |t38:v21:HDLC:Message Confirmation
|         |(4158)   <------------------  (4992)   |
|74,166   |         no-signal |                   |t38:t30 Ind:no-signal
|         |(4158)   <------------------  (4992)   |
|74,754   |         v21-preamble                  |t38:t30 Ind:v21-preamble
|         |(4158)   ------------------>  (4992)   |
|75,954   |         DCN       |                   |t38:v21:HDLC:Disconnect
|         |(4158)   ------------------>  (4992)   |
|76,032   |         no-signal |                   |t38:t30 Ind:no-signal
|         |(4158)   ------------------>  (4992)   |
|76,993   |         BYE       |                   |SIP Request
|         |(5060)   ------------------>  (5060)   |
|76,993   |         200 OK    |                   |SIP Status
|         |(5060)   <------------------  (5060)   |

Do you have an idea ?
Thanks.

By: Marc (rustine22) 2011-10-18 04:34:40.126-0500

What i see in comparaison is : After remote fax has send his TSI and DCS/TSR,  
Asterisk t38gw should send in reply his TSI and DCS/TSR. But it doesn't did it..

So after 5 second, remote fax send again his TSI , DCS 4 times then Bye ...

By: Matthew Nicholson (mnicholson) 2011-10-18 07:54:55.217-0500

Please open a new issue to track this problem.
By: Niccolò Belli (darkbasic) 2012-03-30 15:12:57.559-0500

If someone is interested I made a new patch from irroot's branch and I ported it to 1.8.11:
http://www.linuxsystems.it/2012/03/new-t-38-gateway-patch-against-asterisk-1-8-11-0/