[Home]

Summary:ASTERISK-18219: t38 gateway doesn't work with ooh323
Reporter:Dmitry Melekhov (slesru)Labels:
Date Opened:2011-08-02 02:54:59Date Closed:
Priority:MajorRegression?
Status:Open/NewComponents:Addons/chan_ooh323
Versions:10.0.0-beta1 13.18.4 Frequency of
Occurrence		Constant
Related
Issues:
is related toASTERISK-12667 [patch] T38 gateway
Environment:Centos5.6/x64Attachments:( 0) console_fax_jbenable_no.txt
( 1) console.fax_reverse.txt
( 2) console.fax.txt
( 3) console.txt
( 4) fax_gateway_timeout-1.8-1.diff
( 5) fax_gateway_timeout-10-1.diff
( 6) h323_log_fax_nojb
( 7) h323_log.111
( 8) h323_log.fax
( 9) h323_log.fax_reverse
Description:Asterisk doesn't switch to t38 mode with calls over h323 with chan_ooh323.

Hello!

For unknown reason there is no button add comment, so I'm writing here.
Alexander, thank you! You patch works, and I completely agree with you that users usually have some conversation (really, up to several hours) before sending fax. And they usually want to talk after this fax sending- to check fax quality, talk about what they see on fax, etc...
Comments:By: Paul Belanger (pabelanger) 2011-08-03 12:33:45.277-0500

You have provided zero information about the problem, debug logs / asterisk logs will be needed.
By: Dmitry Melekhov (slesru) 2011-08-03 23:08:42.715-0500

Just because this is all information I have.
With calls over ooh323 there is just no switch to T38mode (this is not from 10beta1, but from 1.8.5.0 with t38 gateway patch, but log is almost the same, only problem  in 10beta1 outbound calls with ooh323 don't work at all, so I did inbound call, and this is production server, so I reversed back to working version and, thus, can't provide real console output)

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...
By: Alexander Anikin (may213) 2011-08-06 08:59:19.069-0500

It'll good if you could to provide more log/debug info but i'll test this issue of my test
system.
Pls inform what version of asterisk/t38gatewy is working for you.

By: Alexander Anikin (may213) 2011-08-07 17:15:22.982-0500

Dimitry, pls try test this issue with patch from ASTERISK-18218 issue. It contain small bug fix in logical channels negotiation codes which could cause this issue.
By: Dmitry Melekhov (slesru) 2011-08-08 02:34:20.446-0500

Hello!

I applied patch, outbound calls work, but t38 gateway doesn't:

ast-ngdu2*CLI> fax set debug on


FAX Debug Enabled

     -- Accepting call from '6558' to '4406' on channel 0/23, span 1
   -- Executing [4406@dahdi:1] Set("DAHDI/i1/6558-9", "FAXOPT(t38gateway)=yes") in new stack
   -- Executing [4406@dahdi:2] Dial("DAHDI/i1/6558-9", "OOH323/5308") in new stack
   -- Called OOH323/5308
   -- OOH323/5308-8 is ringing
   -- OOH323/5308-8 is making progress passing it to DAHDI/i1/6558-9
   -- OOH323/5308-8 answered DAHDI/i1/6558-9
   -- fixed jitterbuffer created on channel DAHDI/i1/6558-9
   -- Channel 23 detected a CED tone towards the network.

Could you tell me how can I produce more logs, debugs, etc?

Thank you!

By: Dmitry Melekhov (slesru) 2011-08-08 02:36:34.932-0500

btw, working version is Asterisk SVN-branch-1.8-r321926M from irroot branch.

By: Alexander Anikin (may213) 2011-08-09 10:52:28.861-0500

Dmitry,

you can enable debug on console/log file by "ooh323 set debug" cli command
disable by "ooh323 set debug off" cli command

also pls enable more verbose tracing in /var/log/ooh323_log by tracelevel=6
in /etc/asterisk/ooh323.conf then reload ooh323 module by "ooh323 reload"

Then provide here /var/log/ooh323_log and console log for call.

I've working faxes with asterisk-10 branch for calls between dahdi and ooh323,
and haven't idea about your issue without log/debug info.

By: Dmitry Melekhov (slesru) 2011-08-09 22:47:59.738-0500

console output
By: Dmitry Melekhov (slesru) 2011-08-09 22:49:06.276-0500

h323 log
By: Dmitry Melekhov (slesru) 2011-08-09 22:51:19.902-0500

Hello!

I attached console aotput and log. Looks like asterisk switched to t38 mode, but faxes do not pass (this time I called not from fax, but from phone) and there is no fax debug output...

By: Alexander Anikin (may213) 2011-08-10 17:05:19.982-0500

Dmitry,

Looks like to log are ok you did logged call from phone not a fax, asterisk switch to t.38 by request from opposite side. Unfortunately i don't see LOG_DEBUG messages in your console, only LOG_VERBOSE are here, pls check you logger.conf and check debug in console settings.

Also please attach here log from console for real fax call, i suggest there is no problem for call that you did from phone.

By: Dmitry Melekhov (slesru) 2011-08-11 01:23:53.167-0500

console with fax
By: Dmitry Melekhov (slesru) 2011-08-11 01:24:52.273-0500

h323 log witj fax
By: Dmitry Melekhov (slesru) 2011-08-11 01:25:20.609-0500

Hello!

I attached console and h323 logs.

Thank you!

By: Alexander Anikin (may213) 2011-08-11 03:57:19.428-0500

Dmitry,

Looks like to your asterisk 10 installation haven't t38gateway codes completely, could you check presence of res_fax_spandsp.so module in your installation?

According your log t.38 frames (AST_FRAME_MODEM, type 11) go directly to chan_dahdi which don't known how to process them.

By: Dmitry Melekhov (slesru) 2011-08-11 04:06:48.066-0500

Hello!

module exists and it is loaded:

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

btw, I had similar problem with irroot branch, he said this is spandsp related and fixed something, so I have working asterisk installation.

So, as I understand, problem is not ooh323 related?


Thank you!
By: Dmitry Melekhov (slesru) 2011-08-11 04:20:57.651-0500

btw, previosly (with working version) I had message in console about swithing to t38 mode, but now there is no such message even with fax debug, and this is strange...

By: Alexander Anikin (may213) 2011-08-11 11:00:15.833-0500

You're right about switching message that shown when t38gateway codes activated and switch channel to t38. Looks like to t38gw codes don't understand what does on h323 channel side.

As i said previously i had success result on t38gw with asterisk 10 on same config but inverted direction of call, i.e. fax call from dahdi to ooh323/receivefax app. T38Gateway work in this direction, but i'll test this in reverse direction.
By: Dmitry Melekhov (slesru) 2011-08-11 23:03:57.075-0500

Hello!

There is no info about t38 in reverse direction too, but I have such output in working version.
I called from phone and I'll test and provide debug logs with call from fax to fax later.

ast-ngdu2*CLI> fax set debug on


FAX Debug Enabled

   -- Executing [4406@h323:1] Set("OOH323/192.168.22.253-13", "FAXOPT(t38gateway)=yes") in new stack
   -- Executing [4406@h323:2] Dial("OOH323/192.168.22.253-13", "DAHDI/g1/5308") in new stack
   -- Requested transfer capability: 0x00 - SPEECH
   -- Called DAHDI/g1/5308
   -- DAHDI/i1/5308-37 is proceeding passing it to OOH323/192.168.22.253-13
   -- DAHDI/i1/5308-37 is making progress passing it to OOH323/192.168.22.253-13
   -- DAHDI/i1/5308-37 is ringing
   -- DAHDI/i1/5308-37 answered OOH323/192.168.22.253-13
   -- fixed jitterbuffer created on channel DAHDI/i1/5308-37
   -- Channel 1 detected a CED tone from the network.
   -- Hungup 'DAHDI/i1/5308-37'
   -- fixed jitterbuffer destroyed on channel DAHDI/i1/5308-37
 == Spawn extension (h323, 4406, 2) exited non-zero on 'OOH323/192.168.22.253-13'


Thank you!
By: Dmitry Melekhov (slesru) 2011-08-11 23:31:06.120-0500

OK, fax do not pass in reverse (h323-dahdi) direction too.
I'll attach logs right now.

By: Dmitry Melekhov (slesru) 2011-08-11 23:32:09.065-0500

console log
By: Dmitry Melekhov (slesru) 2011-08-11 23:32:41.587-0500

h323 log
By: Dmitry Melekhov (slesru) 2011-08-16 00:27:16.021-0500

Hello!

I found reason of not passing fax, this is jbenable=yes in chan_dahdi.conf.
When I set it to no, then fax pass.
I'll attach logs right after posting this message with working fax.
AFAIR, irroot fixed something in this case for me.
But with SIP ( I just tested this too ) fax passes in both cases- with jbenable=yes and with jbenable=no, problem exists only with ooh323.

Thank you!

By: Dmitry Melekhov (slesru) 2011-08-16 00:27:42.135-0500

console jbenable=no
By: Dmitry Melekhov (slesru) 2011-08-16 00:28:45.844-0500

h323 log with jbenable=no
By: Dmitry Melekhov (slesru) 2011-08-16 00:31:47.789-0500

about fix, I don't know is this the same situation or not.

https://issues.asterisk.org/jira/browse/ASTERISK-12667

irroot wrote:


added NULL frame data check in SVN please "svn up" and try hope this resolves the issue.

By: Matthew Nicholson (mnicholson) 2011-08-17 11:57:53.046-0500

I don't believe that fix is related. Either way, that fix is in that 1.8 branch and in asterisk 10.
By: Matthew Nicholson (mnicholson) 2011-08-17 12:11:14.667-0500

In your debug logs I don't see any messages from the gateway.  Make sure you set core debug to at least 1 while testing (core set debug 1). Also enable the 'full' log in logger.conf and upload that. I don't know much about ooh323 but I should be able to determine if the problem is there or in the gateway code with the proper logs.
By: Alexander Anikin (may213) 2011-08-18 13:01:28.141-0500

Dmitry,
i think i known what is your issue and i need to read sources more attentively ;)
I had same trouble today with 1.8-irroot and go to undestand about.
There is timeout for 10 seconds to begin fax gatewaying in the res_fax module and
if there no gateway started in this time from answer of call then gateway code remove
framehook from channel and t.38 gatewaying impossible later for that call.
I think this was made for decrease system load due to gateway force call media format to slinear,
but i think we need to talk with irroot to understand how to play with this right way.

All your attached log with unsuccessful faxes contain t.38 switching after 11 seconds after,
i.e. later than timeout.

You can use this patch as temporary workaround (this change timeout to one hour):


--- res/res_fax.c       (revision 332432)
+++ res/res_fax.c       (working copy)
@@ -291,7 +291,8 @@ static int fax_logger_level = -1;
#define FAX_MAXBUCKETS 10

#define RES_FAX_TIMEOUT 10000
-#define FAX_GATEWAY_TIMEOUT RES_FAX_TIMEOUT
+/* #define FAX_GATEWAY_TIMEOUT RES_FAX_TIMEOUT */
+#define FAX_GATEWAY_TIMEOUT 3600000

/*! \brief The faxregistry is used to manage information and statistics for all FAX sessions. */
static struct {

It work for me within 1.8-irroot branch same as 10 branch.
By: Matthew Nicholson (mnicholson) 2011-08-18 13:31:54.392-0500

Debug logs should show the gateway timing out if that is what is happening here. That timeout is to free up gateway resources that are not needed. I figured 10 seconds was enough time when I wrote that code, but that timeout may need to be increased to something like 15 seconds or something.
By: Alexander Anikin (may213) 2011-08-18 19:15:44.168-0500

Matthew, how we must proccess call when caller and callee talked for 1-2 minutes
then would transfer fax in this call?
By: Matthew Nicholson (mnicholson) 2011-08-19 09:26:13.834-0500

You can leave a comment using the "Enter Feedback" button.

As far as the use case of speaking on the phone then transferring the call to a fax machine and speaking some more, I did not consider that use case when I designed the timeout. I may need to add a mechanism to disable or extend the timeout for calls that need this.
By: Dmitry Melekhov (slesru) 2011-08-19 09:41:38.476-0500

now I see comment button, may be it was there all time, looks like I'm just too busy  :-)

I'd like to add that there are still many fax machines wich can act like phones, i.e. they have handset and users usually use them as phones.

And.. Why one may need this timeout? Voip gateways we use, namely addpac and cisco, do not have such timeout at all and can swith to t38 and back to voice at any time of conversation...

By: Matthew Nicholson (mnicholson) 2011-08-19 09:56:04.163-0500

The comment button was not there because the issue was in the "feedback" state.

The timeout is there to free up resources on channels that don't need them. A fax backend may provide a limited number of fax channels, having the gateway timeout and disable itself frees up those resources. When the gateway is first attached, a "fax session" is also started as starting a fax session is an operation that can fail if there are no resources available. The dialplan can detect this and notify the user (I think). The option to disable the timeout would need to delay starting a fax session until it is actually needed, which would carry the risk of failing in the middle of a call.

I'll work on a patch to allow this functionality. It will probably be implemented as {{FAXOPT(gateway)=yes,0}} or {{FAXOPT(timeout)=no}}. I don't know which one of those I prefer yet, but I am leaing towards the latter.
By: Alexander Anikin (may213) 2011-08-19 09:57:57.078-0500

May be the case to work without timeout is to put framehook code when one from bridged channels goes to
switch t.38?
And may be we can create some application that will work as trigger on t.38 mode switching?


By: Matthew Nicholson (mnicholson) 2011-08-19 10:03:12.079-0500

There will still be a timeout for switching to t.38, but not one for actually starting the gateway session.
By: Matthew Nicholson (mnicholson) 2011-08-19 15:10:37.929-0500

I have uploaded patches to enable setting {{FAXOPT(timeout)=no}} to disable the timeout. Please test them. You can also set the timeout to any value you desire (in seconds).
By: Dmitry Melekhov (slesru) 2011-08-22 00:30:08.523-0500

Hello!

I tried patch, it is half-successeful, only 1/2 of faxes pass. AFAIR, there was no such problem with timeout extended to 1 hour.
I'll attach full log now.
btw, I think it will be better to reserve fax resources on demand, i.e. on switching to t38 mode, not for every call, which are mostly voice, not fax...

By: Dmitry Melekhov (slesru) 2011-08-22 00:33:22.133-0500

Sorry, I can't upload log, I always get:
Your session has timed out or you were logged out. Please save your work and reload the page.

So here is part of it:

[Aug 22 09:02:49] DEBUG[5519] chan_ooh323.c: Got UDPTL 5/0 len 0 for OOH323/5308-1                                                                  
[Aug 22 09:02:49] DEBUG[5519] chan_ooh323.c: Got UDPTL 5/0 len 0 for OOH323/5308-1                                                                  
[Aug 22 09:02:49] DEBUG[5519] chan_ooh323.c: Got UDPTL 5/0 len 0 for OOH323/5308-1                                                                  
[Aug 22 09:02:50] DEBUG[5519] chan_ooh323.c: Got UDPTL 5/0 len 0 for OOH323/5308-1                                                                  
[Aug 22 09:02:50] DEBUG[5519] chan_ooh323.c: Got UDPTL 5/0 len 0 for OOH323/5308-1                                                                  
[Aug 22 09:02:50] DEBUG[5519] chan_ooh323.c: Got UDPTL 5/0 len 0 for OOH323/5308-1                                                                  
[Aug 22 09:02:50] DEBUG[5519] chan_ooh323.c: Got UDPTL 5/0 len 0 for OOH323/5308-1                                                                  
[Aug 22 09:02:50] DEBUG[5519] chan_ooh323.c: Got UDPTL 5/0 len 0 for OOH323/5308-1                                                                  
[Aug 22 09:02:53] VERBOSE[5520] chan_ooh323.c: ---   close_udptl_connection                                                                        
[Aug 22 09:02:53] VERBOSE[5520] chan_ooh323.c: ---   find_call                                                                                      
[Aug 22 09:02:53] VERBOSE[5520] chan_ooh323.c: +++   find_call                                                                                      
[Aug 22 09:02:53] VERBOSE[5520] chan_ooh323.c: +++   close_udptl_connection                                                                        
[Aug 22 09:02:53] DEBUG[5519] res_fax.c: T.38 disabled on channel OOH323/5308-1    


And there is no send...

By: Dmitry Melekhov (slesru) 2011-08-22 04:23:55.657-0500

btw, reverted back to 1 hour timeout and have the same problem, i.e. not every fax passes, so this is different issue...

Thank you!

By: Matthew Nicholson (mnicholson) 2011-08-22 11:32:36.057-0500

That timeout patch has been committed.
By: Matthew Nicholson (mnicholson) 2011-08-24 11:50:57.684-0500

The name of this option has been changed to "gwtimeout".
By: Gregory Hinton Nietsky (irroot) 2011-08-29 08:17:37.811-0500

Please see https://reviewboard.asterisk.org/r/1385/ there some problems with this patch.
By: Leif Madsen (lmadsen) 2011-08-29 09:16:57.228-0500

Issue reopened per irroot on IRC.
By: Gregory Hinton Nietsky (irroot) 2011-08-29 09:49:01.286-0500

The timeout gets reset to default during negotiation this i dont think should happen esp when its set to no.

gwtimeout is only set for V21 detection period.

the resultstr is not set correctly either.
By: Gregory Hinton Nietsky (irroot) 2011-08-29 10:17:11.166-0500

What if there is only one timeout from attach to start ?? instead of multiple timers this could make more sense.

By: Matthew Nicholson (mnicholson) 2011-08-30 09:16:30.042-0500

The timeout option is now disabled by default and can be enabled as follows:

{noformat}
exten => s,1,Set(FAXOPT(gateway)=yes,10) ; set timeout to 10 seconds
{noformat}