[Home]

Summary:ASTERISK-17172: [patch] OOH323 Incoming and Outgoing Calls Fail Avaya with Asterisk 1.8.1.1
Reporter:Vladimir Mikhelson (vmikhelson)Labels:
Date Opened:2010-12-28 11:26:37.000-0600Date Closed:2011-06-01 05:45:15
Priority:MajorRegression?No
Status:Closed/CompleteComponents:Addons/chan_ooh323
Versions:Frequency of
Occurrence
Related
Issues:
Environment:Attachments:( 0) 16min_disconnect.pcap
( 1) 16_minutes_drop,_packet_20_discarded.pcap
( 2) 2011-01-25-h245tunneling--packet-c.cap
( 3) 30_seconds_drop.pcap
( 4) 5_minute_drop.pcap
( 5) avaya.txt
( 6) GDB.TXT
( 7) H323_LOG_18542_PATCH1
( 8) H323_LOG-16_minutes_failure_and_undalanced_structures
( 9) H323_LOG-32sec_disconnect
(10) h323_log-5_minute_drop
(11) H323_LOG-both_incoming_and_outgoing
(12) H323_LOG-h245_disabled.txt
(13) H323_LOG-h245tunneling=on_no_sound_30_seconds_disconnect.txt
(14) H323_LOG-incoming_16_min_disconnect.txt
(15) H323_LOG-incoming_inconsistency
(16) H323_LOG-no__r__in_dial_command_options.txt
(17) h323_log-patch1+no_h245_tunneling.txt
(18) H323_LOG-patch2-dropped_incoming_call.txt
(19) H323_LOG-see_Avaya_Log.txt
(20) issue18542.patch
(21) issue18542-2.patch
(22) issue18542-3.patch
(23) issue18542-4.patch
(24) issue18542-5.patch
(25) issue18542-6.patch
(26) issue18542-final-3.patch
(27) issue18542-final-3-1.8.2.3.patch
(28) OOH323.CONF
Description:1. Upgraded to Asterisk 1.8.1.1 from Asterisk 1.6.2.15.

2. All outgoing calls started to fail.

3. "ooh323 show" was not recognized as a valid command. Auto-complete worked though.

4 Rebooted the system.

CLI:

pbx*CLI> ooh323 show peers
Name             Accountcode      ip:port                  Formats
avaya            h3230101         172.17.135.2:1720        0x4 (ulaw)

FreePBX 2.8.0.4
AsteriskNOW 1.7


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

Sections form the logs with the failure reason.

Console log:

   -- Executing [s@macro-dialout-trunk:27] Dial("DAHDI/7-1", "OOH323/352/avaya,300,tr") in new stack
 == Everyone is busy/congested at this time (1:0/0/1)
   -- Executing [s@macro-dialout-trunk:28] NoOp("DAHDI/7-1", "Dial failed for some reason with DIALSTATUS = CHANUNAVAIL and HANGUPCAUSE = 0") in new stack

Asterisk log:

[Dec 28 11:09:27] VERBOSE[3230] pbx.c: -- Executing [s@macro-dialout-trunk:27] Dial("DAHDI/7-1", "OOH323/352/avaya,300,tr") in new stack
[Dec 28 11:09:27] ERROR[3230] chan_ooh323.c: Call to undefined peer 352[Dec 28 11:09:27] WARNING[3230] app_dial.c: Unable to create channel of type 'OOH323' (cause 0 - Unknown)
[Dec 28 11:09:27] VERBOSE[3230] app_dial.c: == Everyone is busy/congested at this time (1:0/0/1)

Asterisk log:

[Dec 28 10:54:09] VERBOSE[2700] config.c: == Parsing '/etc/asterisk/ooh323.conf': [Dec 28 10:54:09] VERBOSE[2700] config.c: == Found
[Dec 28 10:54:09] VERBOSE[2700] chan_ooh323.c: -- == Setting default context to default
[Dec 28 10:54:09] VERBOSE[2700] channel.c: == Registered channel type 'OOH323' (Objective Systems H323 Channel Driver)
[Dec 28 10:54:09] VERBOSE[2700] rtp_engine.c: == Registered RTP glue 'OOH323'
[Dec 28 10:54:09] VERBOSE[2700] loader.c: chan_ooh323.so => (Objective Systems H323 Channel)

h323_log:

Shows the time stamp of the system restart.  Zero bytes.

Comments:By: Vladimir Mikhelson (vmikhelson) 2010-12-28 11:57:03.000-0600

Tried to use the current code.  Did not discover a branch for 1.8 (maybe this is the problem.)

svn checkout http://svn.digium.com/svn/asterisk-addons/branches/1.6.2/
/.configure
make menuselect

[root@pbx 1.6.2]# make
make[1]: Entering directory `/usr/src/1.6.2/channels'
  [CC] chan_ooh323.c -> chan_ooh323.o
In file included from chan_ooh323.c:18:
chan_ooh323.h:53:26: error: asterisk/rtp.h: No such file or directory
chan_ooh323.c:55: warning: 'struct ast_rtp' declared inside parameter list
chan_ooh323.c:55: warning: its scope is only this definition or declaration, which is probably not what you want
chan_ooh323.c:56: warning: 'struct ast_rtp' declared inside parameter list
chan_ooh323.c:58: warning: 'struct ast_rtp' declared inside parameter list
chan_ooh323.c:70: warning: initialization from incompatible pointer type
chan_ooh323.c:82: error: 'ast_rtp_bridge' undeclared here (not in a function)
chan_ooh323.c:85: error: variable 'ooh323_rtp' has initializer but incomplete type
chan_ooh323.c:86: error: unknown field 'type' specified in initializer

etc, etc, etc.

Here is the list of packages currently installed:

asterisk18.i386                                                  1.8.1.1-1_centos5                                   installed
asterisk18-addons.i386                                           1.8.1.1-1_centos5                                   installed
asterisk18-addons-bluetooth.i386                                 1.8.1.1-1_centos5                                   installed
asterisk18-addons-core.i386                                      1.8.1.1-1_centos5                                   installed
asterisk18-addons-mysql.i386                                     1.8.1.1-1_centos5                                   installed
asterisk18-addons-ooh323.i386                                    1.8.1.1-1_centos5                                   installed
asterisk18-core.i386                                             1.8.1.1-1_centos5                                   installed
asterisk18-dahdi.i386                                            1.8.1.1-1_centos5                                   installed
asterisk18-devel.i386                                            1.8.1.1-1_centos5                                   installed
asterisk18-doc.i386                                              1.8.1.1-1_centos5                                   installed
asterisk18-voicemail.i386                                        1.8.1.1-1_centos5                                   installed


By: Vladimir Mikhelson (vmikhelson) 2010-12-28 12:42:38.000-0600

Tested incoming calls.

They get connected.  DTMF is not working.  All calls are disconnected after 32 seconds.

The h323_log is still empty.
By: Alexander Anikin (may213) 2010-12-28 14:50:01.000-0600

Hi,

there "- Executing [s@macro-dialout-trunk:27] Dial("DAHDI/7-1", "OOH323/352/avaya,300,tr") in new stack" you dial to peer 352 dest number avaya, change to right order OOH323/avaya/352 or use 2nd form OOH323/352@avaya.

about addons compiltaion - 1.6.2 will not compile and work 1.8.x series, but 1.8.x contain their addon's in main tree.

h323_log please set tracelevel=6 in general section by default it contain error messages only.

for dtmf checking - please set tracelevel, make incoming call and attach h323_log and your ooh323.conf here.
By: Vladimir Mikhelson (vmikhelson) 2010-12-28 15:47:30.000-0600

Hi may213,

Changed to "OOH323/avaya/352" and it worked.  Interestingly, needed to change syntax to "OOH323/352/avaya" from "OOH323/352@avaya" after upgrading to 1.6.2. This quote is from the ooh323.conf:
; For dialing into another asterisk peer at a specific exten
;       OOH323/exten/peer OR OOH323/exten@ip


Added "tracelevel=6" to ooh323.conf, in [general]. That fixed the empty log issue.  Interestingly, never had this issue with older versions.

Tried incoming call, was disconnected in 32 seconds.  See log attached.

Thank you,
Vladimir


By: Vladimir Mikhelson (vmikhelson) 2010-12-28 15:51:28.000-0600

Hi may213,

I have just verified DTMF does not work in both directions.

Do you want the log or do you want to fix the disconnect problem first?

Thank you,
Vladimir
By: Vladimir Mikhelson (vmikhelson) 2010-12-28 18:31:16.000-0600

Hi may213,

A little bit more information.

Outgoing calls do not fail at 32 seconds, just incoming.

Call setup is different in regards to DTMF capabilities processing compared to what happened in Asterisk 1.6.2.

I have "RFC2833" set in [general] and "h245alphanumeric" in [avaya] sections of ooh323.conf.

Here is what we see for an outgoing call:
17:47:38:941  Enabled RTP/CISCO DTMF capability for (outgoing, ooh323c_o_1)
17:47:38:941  Enabled RFC2833 DTMF capability for (outgoing, ooh323c_o_1)
17:47:38:941  Dtmf mode set to H.245(alphanumeric) for (outgoing, ooh323c_o_1)
17:47:38:941  Dtmf mode set to H.245(signal) for (outgoing, ooh323c_o_1)

The same for incoming:
18:16:30:557  Enabled RTP/CISCO DTMF capability for (incoming, ooh323c_2)
18:16:30:557  Enabled RFC2833 DTMF capability for (incoming, ooh323c_2)
18:16:30:557  Dtmf mode set to H.245(alphanumeric) for (incoming, ooh323c_2)
18:16:30:558  Dtmf mode set to H.245(signal) for (incoming, ooh323c_2)

It looked like incorrect processing of a peer specific "dtmfmode=" setting. To troubleshoot I tried setting "h245alphanumeric" in [general]. It helped for outgoing calls.

Incoming calls still terminate at 32 seconds and no DTMF information is passed by the channel.

Thank you,
Vladimir


By: Alexander Anikin (may213) 2010-12-29 01:48:41.000-0600

Vladimir,

can you compile and use latest svn code for 1.8 branch? I suggest that incoming call bug was resolved in one of previous bugs (tcs and msd correction)
about dtmf - are you known which dtmf mode use your Avaya PBX? I suggest it's rfc2833, so you can set dtmfmode rfc2833 in general and don't set any dtmfmode in peer section.
about number and peer name in dialing string - i think current order is more general for asterisk, chan_h323 and chan_sip use same syntax.
By: Vladimir Mikhelson (vmikhelson) 2010-12-29 08:31:17.000-0600

Hi may213,

It would be problematic for me to build the whole project as the machine I am running Asterisk on is not that powerful. On top of that I have no idea how AsteriskNOW people run the compilation.  I mean what they include, parameters, etc.

Is there any way to compile addons separately?

Avaya uses h245alphanumeric which is forced by me in [general] and for the peer (see 0130020). It did resolve outgoing DTMF issue. Incoming DTMFS are still ignored.

I would suggest to document the dial string syntax change in .conf comments and in Whatsnew if it is not done already.

Thank you,
Vladimir


By: Alexander Anikin (may213) 2010-12-29 10:42:11.000-0600

Vladimir,

incoming dtmf issue is a part of incoming common issue which is related to incorrect capability exchange procedure between avaya and asterisk. Can you attach log for success outgoing call?  I will try to see difference in incoming and outgoing call processing.
By: Vladimir Mikhelson (vmikhelson) 2010-12-29 11:09:04.000-0600

May213,

I have attached the log with several incoming and outgoing calls.

Please let me know if you need anything else.

Thank you,
Vladimir
By: Alexander Anikin (may213) 2011-01-03 15:02:13.000-0600

Vladimir, seems like avaya can't process properly packets from asterisk on incoming to asterisk calls due to they come too fast without any delay and waiting of responses from avaya. As I understand avaya drop TCS packet and asterisk abort TCS exchange procedure  by timeout then drop call.
Latest svn codes contain fix of this trouble but there can be workaround without code updates.
You can disable h.245 tunneling for avaya peer by h245tunneling=no in your ooh323.conf (it's possible what you can disable this globally only, there was bug about it which is fixed but i don't known from which version asteriknow codes are built).
If tunneling will disabled any H.245 packets will go on additional tcp connection which cause some delay in processing.
By: Vladimir Mikhelson (vmikhelson) 2011-01-03 15:48:46.000-0600

May213,

Thank you for the reply.

Unfortunately disabling h.245 did not fly.

I ran into two (2) issues:

1. Still no DTMF on incoming calls

2. Call disconnect was not processed by Asterisk for quiet some time

I have uploaded the log of two (2) incoming calls, one to a DAHDI ext. 423, another to the IVR ext. 400.  DTMF did not work in both cases. Second call was on after Avaya hang up the call.

I used "ooh323 reload" vs. reloading Asterisk to force OOH323 reading the new configuration. Is that OK?

Thank you,
Vladimir


By: Vladimir Mikhelson (vmikhelson) 2011-01-03 18:55:26.000-0600

May213,

Thank you for removing the file.

Can you please also mask the personally identifiable information in the latest log.  For some reason it logged the communication with voipcheap which I never expected to be there.

Thank you,
Vladimir
By: Alexander Anikin (may213) 2011-01-03 19:19:38.000-0600

Vladimir,

unfortunatelly i see same result. There is no any packet from avaya side other than setup.
I have additional assumption also. There is incorrect signalling packet order from asterisk to avaya, first packet is call proceeding (it's normal), second is alerting (normal but progress is more generic way), third is progress and next packet is alerting again that is incorrect. I think first alerting generate by FreePBX dial options "r". You can try to remove "r" from "asterisk dial options" in FreePBX General settings then signalling packet order will be more properly.
By: Alexander Anikin (may213) 2011-01-03 19:25:10.000-0600

Vladimir,

i reloaded log with removed your private info.
By: Vladimir Mikhelson (vmikhelson) 2011-01-03 21:07:33.000-0600

May213,

Thank you for cleaning the log.  BTW, how did the OOH323 log capture an unrelated SIP message?

I do not think that removing "r" from the Dialing Command Options globally is reasonable as it will remove the ringing tone for a calling party.

I am a little bit confused. Is the problem in the channel driver or outside?  Nothing changed on the Avaya end, that is for sure. Everything worked fine in 1.6.2.15 and now we are having all these problems in 1.8.1.1. What is the cause?

Also it sounds as if what is happening is not in your control.  Am I understanding you right?

Thank you,
Vladimir


By: Alexander Anikin (may213) 2011-01-04 07:49:14.000-0600

Vladimir,

main change is progress sending by ooh323 channel, 1.6 addons version doesn't provide progress signal, current version send progress on ast_control_progress frame or by 1st rtp packet from asterisk core.
Btw, if you setup globally progressinband=yes in sip.conf then ringing tone will generate by asterisk even you don't use r dialing option.
But 'r' option generate fictive ringing (alerting) signal which is first real signalling packet from called side (call proceeding generate by ooh323 for any accepted by channel driver call). In this we have 1st ringing (caused by 'r' option), progress (caused by 1st sound packet) and 2nd ringing (caused by alerting from called endpoint). But possible it's vice-versa, 1st ring go from endpoint and 2nd is fictive by 'r'.
In any case i think you can try to remove 'r' for testing for short time and see on result.
I will see more accurately on app_dial code, i think root of this trouble is here and we must generate right packet stream to avaya for solving trouble.
Also you can replace 'r' by 'm' option, then asterisk will generate background music sound instead of ringing tone.
By: Vladimir Mikhelson (vmikhelson) 2011-01-04 12:58:17.000-0600

May213,

Removed the "r" key.  Placed two (2) test calls.  Did not observe any difference, i.e. no DTMF and call disconnect after 30 seconds for incoming calls.

Uploaded the respective log section.

Thank you,
Vladimir
By: Vladimir Mikhelson (vmikhelson) 2011-01-04 13:19:43.000-0600

May213,

In case it can be of any help let me upload another h323_log and the respective Avaya log for an incoming call.

I called ext. 423 on Asterisk from Avaya, pushed "*" two (2) times. Call got disconnected by itself.

The Avaya IP is 172.17.135.2.  The log was collected from 172.17.135.5.  Asterisk is on 172.17.137.11. Avaya log uses relative time stamps and UTC time in some log messages.

Thank you,
Vladimir
By: Alexander Anikin (may213) 2011-01-05 11:13:24.000-0600

Vladimir,
seems like to your Avaya can't start TCS exchange procedure until connection is answered. Not all Avaya PBX do so and i couldn't suggest this at once.
Unfortunatelly it can't solved without patching codes, but i think you can get 1.8.1.1 source, apply patch then configure without any specific parms, select chan_ooh323 in addons (unselected by default) and make.
When building done replace /usr/lib/asterisk/modules/chan_ooh323.so by new chan_ooh323.so from build, channel driver doesn't have too much dependences from compilation options.
By: Alexander Anikin (may213) 2011-01-06 04:40:35.000-0600

forgot one detail, attached patch correct sending h.245 address in connect packet which mean that it work with h245tunneling=no.
By: Vladimir Mikhelson (vmikhelson) 2011-01-06 22:50:07.000-0600

May213,

Compiled as you advised, i.e. unchecked everything in "make menuselect" which could have been unchecked, checked Addons/chan_ooh323, ran make, copied the new .so.

Unfortunately, no fun.  Outgoing and incoming calls both fail. The reason was simple.

Here is a fragment of the Asterisk log:

[Jan 6 22:42:10] WARNING[7234] loader.c: Module 'chan_ooh323.so' was not compiled with the same compile-time options as this version of Asterisk.
[Jan 6 22:42:10] WARNING[7234] loader.c: Module 'chan_ooh323.so' will not be initialized as it may cause instability.
[Jan 6 22:42:10] WARNING[7234] loader.c: Module 'chan_ooh323.so' could not be loaded.

Any ideas which options to use?  I left Compiler Flags intact with LOADABLE_MODULES checked by default. All other check boxes were clear except for the obligatory ones.

Thank you,
Vladimir
By: Vladimir Mikhelson (vmikhelson) 2011-01-14 18:19:33.000-0600

May213,

I have checked out the current trunk, applied the patch, compiled the whole project with addons/chan_ooh323 selected.

Testing did not show any variance, i.e. the same disconnect on an incoming call. Outgoing call was placed with no problems. Log attached.

Thank you,
Vladimir
By: Alexander Anikin (may213) 2011-01-16 02:59:53.000-0600

Vladimir, you have h245tunellilng=yes in last test, please set this to no and retest calls.
By: Vladimir Mikhelson (vmikhelson) 2011-01-16 18:31:58.000-0600

May213,

Set h245tunneling=no, reloaded ooh323.

Outgoing call was still working fine.

Incoming call did not drop at 30 seconds which was good.  Unfortunately after the call was hung by Avaya Asterisk kept the channel up for about 30 seconds.  I will be able to test DTMF for incoming calls tomorrow, I will update the case then.

Also I experienced the same log "poisoning" with SIP messages as I did when I disabled h245tunneling last time in our troubleshooting.  The log is attached with the sensitive information masked.

Thank you,
Vladimir
By: Vladimir Mikhelson (vmikhelson) 2011-01-17 17:23:39.000-0600

May213,

Tested incoming calls. Received inconsistent results. See the log attached.

1. Call placed at 10:41 lasted more than 30 seconds and DTMF worked fine. Call disconnection took about 30 seconds to be processed on the Asterisk end;
2. Calls placed at 1:48 and 10:49 were dropped at 33 seconds, DTMF was not working. Call disconnection was processed properly;
3. Call placed at 12:56 was not interrupted and DTMF worked fine. Call disconnection was processed properly.

No changes were done on either Avaya or Asterisk sides in between the test calls. All outgoing calls were processed fine.

The log is still showing some SIP information, now in a different format.

Another issue related to the previous one -- CDR shows CLID with "SIP suffixes" like in the log, e.g. Vlad Mikhelson.r" <352> or Vlad Mikhelsonpg" <352>.

Thank you,
Vladimir


By: Alexander Anikin (may213) 2011-01-18 16:03:25.000-0600

Vladimir,

new patch attached, it must solve incoming call drop issue (removed start of tcs procedure by called side if h245tunelling isn't active) and disconnection delay issue.

incoming call drop issue found because your Avaya can't start tcs procedure until call is answered, you had inconsistent results because there was different dealys between setup and answer, calls worked fine if tcs timer on asterisk wasn't expired. With new patch ooh323 channel will wait start tcs procedure from Avaya. I'm not sure that it's best choice for all cases and i think to implement config option about it.
Issue of 30 secs disconnection is related to simple mistake of codes, there need to clear h.323 connection after h.245 sessions closed. Most of H.323 endpoints clear connection regardless of call direction, but not your avaya and asterisk didn't it also.

Unforunatelly previous patch isn't functional and you can not use him.
By: Alexander Anikin (may213) 2011-01-18 16:08:05.000-0600

About log/cdr poisoning issue - i think we will work about it in another issue due to it's separate issue.
By: Vladimir Mikhelson (vmikhelson) 2011-01-19 11:02:56.000-0600

May213,

All tested well with the new patch. Call setup seems to take longer, but all the rest works fine.

First tested with "h245tunneling=no" in [general]. Then set "h245tunneling=yes" in [general] and "h245tunneling=no" in [avaya].  Both setups worked fine.

Verified Avaya IPOffice 403 settings for an IP line. I can pick H450 support level. Options are: "none", "QGIG", and "H450". There is no area for H245 tuning. "Enable Faststart" is another option, but I believe it is different.

Interestingly, I do not see any of the log "poisoning" with the new patch. I will continue watching and will let you know if it reappears.

Thank you,
Vladimir
By: Vladimir Mikhelson (vmikhelson) 2011-01-20 14:26:27.000-0600

May213,

Everything worked fine for a day, and just of a sudden one of the incoming calls was dropped. Please see the attached log.

Thank you,
Vladimir
By: Alexander Anikin (may213) 2011-01-20 14:32:49.000-0600

Vladimir,

i will see on attached log, but i recommend to enable fast start on your avaya, with this option enabled early media (inband ringing and other tones before answer) must work and without you can hear only local generated inband tones.
By: Alexander Anikin (may213) 2011-01-20 15:22:46.000-0600

Vladimir,

i forgot in prevoius patch one place where tcs exchange proc can start on incoming call, fixed in new patch, please try it. Also i see that fast start already enable on your Avaya.
By: Vladimir Mikhelson (vmikhelson) 2011-01-20 17:09:02.000-0600

May213,

Installed the patch. So far so good. I will let you know whether I will have had more issues in a couple days.

Do you think we should change the issue Summary to say "OOH323 Incoming and Outgoing Calls Fail with Asterisk 1.8.1.1"?

The reason we still need to leave Outgoing calls in the title is the dial string format change which caused the initial issue.

Thank you,
Vladimir


By: Alexander Anikin (may213) 2011-01-20 17:40:17.000-0600

Vladimir,

Ok, issue summary changed to "OOH323 Incoming and Outgoing Calls Fail Avaya with Asterisk 1.8.1.1". I'll change sample config to correct dial string syntax before closing this issue.
Also please see on poisoning issue in your tests, if it still found we must open new issue and work about it.
By: Vladimir Mikhelson (vmikhelson) 2011-01-21 10:18:16.000-0600

May213,

I have experienced a disconnect of a fairly long incoming call. The call was dropped at 16:22 per CDR log. The h323 log is attached.

I am not sure but it may be related to that round trip request not being processed by 00H323 you fixed some time ago. Maybe something else.

Garbage in the logs is still present, we will work on that after this ticket is resolved.

Another observation. After the call was dropped I tried to redial the number and experienced some problems which looked like my call was connecting to an existing call in progress , and I was hearing a continuation of an "all circuits are busy" or an "extension not available" announcements.  It looked like the original call was not torn down completely. Or maybe it was another problem. Some of the attempts did not go through at all.

Thank you,
Vladimir


By: Alexander Anikin (may213) 2011-01-21 16:54:23.000-0600

Vladimir,

Seems like to my previous suggestions about initiating side of tcs and msd procedures was incorrect. I see in last log that tcs exchange procedure simple don't start and i think it's reason of call termination after 16 mins.
RoundTrip request and replies are proccessed normal in this call, but h.323 connection closed unexpectly from avaya side.

I think there is difference in tcs exchange procedure in H.323v2 (which use your Avaya) and H.323v4 (which use ooh323) and we must work properly with v2 endpoints. I'll read h.323v2 specs tomorrow and will try to see how this proc work in opal/openh323 libraries.
By: Vladimir Mikhelson (vmikhelson) 2011-01-21 23:51:11.000-0600

May213,

Thank you for the update.

If I understand you correctly the current version of OOH323 supports h323v4 and is not backwards compatible with h323v2 which you will try to fix. Is that correct?

What about addons version from 1.6? Was it h323v2 compliant?

Thank you,
Vladimir
By: Alexander Anikin (may213) 2011-01-22 15:58:46.000-0600

Vladimir,

Seen on openh323 source and itu-t h.323/h.245 recommendation.
Unfortunately, i can't find any direct definitions about starting point of tcs
exchange procedure in itu recs.
Openh323 start tcs proc after answer signal is received or sent or start_h245 facility message is received regardless of H.323/H.245 version indicated by opposite side. Also openh323 send start_h245 facility after progress signal sending, ooh323 do same already.
By: Alexander Anikin (may213) 2011-01-22 16:18:43.000-0600

Respective patch uploaded (issue18542-4).
Difference to previous patch are send tcs in ooAcceptCall (start tcs after call answered by us), move send tcs from ooCreateH245Connection to ooHandleStartH245FacilityMessage (we start tcs after getting signal to start only not in all cases of creating h245 connection).

sending of StartH245 message logic wasn't done there (we send this messages regard on tunneling setting not fast start, it's incorrect in common but insignificant in our tests for now) and i'll done this in closing patch.
By: Vladimir Mikhelson (vmikhelson) 2011-01-23 20:49:13.000-0600

May213,

Thank you for the new patch. Applied it to the SVN trunk with no trouble.

Tested outgoing calling, did not experience any problems. DTMF works fine, 17 minutes call was not disconnected, call tear down was instantaneous.

Tested incoming. Placed one call with the intention to test long calls. Placed the call on hold on the Avaya end after the call was in progress for about 10 minutes. Tried to dial another Asterisk extension from the same extension on Avaya. That crashed Asterisk.

Reproduced the crash in a slightly different scenario. Placed outgoing call from Asterisk to Avaya. Took the call on Avaya extension and placed it on hold. Placed an incoming call to Asterisk form the same extension on Avaya, then conferenced the calls on the Avaya end. Everything was fine that far. Was able to control the Asterisk IVR through the bridge. Then I dropped the Avaya to Asterisk leg and tried to dial the same number again. At that time Asterisk crashed.

Please let me know what should I submit for the Asterisk crash analysis.

Thank you,
Vladimir
By: Alexander Anikin (may213) 2011-01-24 11:52:32.000-0600

Vladimir, i think call hold/call forward crash is subject for another issue also. I don't touch this part of original codes only for succesfull compilation.
I can simple drop this part of codes then hold/forward functions must be proccessed on Avaya side only but we can try to implement this functions
on asterisk.
Unfortunately i don't have any pbx which can interconnect by h.323 and can't make this without help from other people.

For this issue i can delete call of hold/forward functions and we will solve this crash.
By: Vladimir Mikhelson (vmikhelson) 2011-01-24 12:26:40.000-0600

May213,

It looks like all other incoming tests passed fine except for the 16 minutes drop. This one still happened.

I tried placing incoming call, and it worked fine with DTMF being processed without a glitch.  Then I called into Asterisk from another Avaya extension, and this one was processed just fine. While I had two (2) incoming calls in progress I placed the first call on hold and placed another call from the same extension which was processed with no problems as well.  So I have had three (3) incoming calls with one on hold at one point and have not experienced any problems.

Then finally I placed another long call, and unfortunately it got disconnected at 16 minute mark.

I will submit the log shortly.

If you feel like it could be beneficial to contact directly regarding the testing scenarios or to discuss the setup in more detail you can e-mail me at my <user-name-here>@AOL

Thank you,
Vladimir
By: Alexander Anikin (may213) 2011-01-24 15:11:03.000-0600

Vladimir,

It's possible that 16 mins issue is related to keepalive settings on tcp connection, i don't see other reason now. Signalling for this call is ok and hangup reason there is aborted h.225 tcp connection from avaya.

There are log records about it:

12:11:35:096  Sending H245 message (incoming, ooh323c_4)
12:11:35:096  Sending OORequestDelayResponse H245 message over H.245 channel. (incoming, ooh323c_4)
12:11:35:096  H245 Message sent successfully (incoming, ooh323c_4)
12:11:38:089  Error:Transport failure while reading Q931 message (incoming, ooh323c_4)
12:11:38:089  In ooEndCall call state is - OO_CALL_CLEARED (incoming, ooh323c_4)
12:11:38:089  Cleaning Call (incoming, ooh323c_4)- reason:OO_REASON_TRANSPORTFAILURE

I'll try to produce patch with keepalive enabled.


By: Vladimir Mikhelson (vmikhelson) 2011-01-24 15:32:12.000-0600

May213,

Let me ask you a question.

If it were TCP timeout would it affect both incoming and outgoing calls equally?

In my note ASTERISK-1239206 I reported an outgoing call of more than 17 minutes not being disconnected. The only difference with this call I can think of is that Avaya tried to make sure that the call was not abandoned as I was calling myself and did not talk. It asked to punch a certain keys combination to keep the call active which I did once a minute.

This whole thing resembles an issue you fixed before where a call got disconnected since some signaling was missing on OOH323 end.

Thank you,
Vladimir
By: Alexander Anikin (may213) 2011-01-24 15:50:58.000-0600

Vladimir,

Okay, i can suggest that there was some signalling is missing but i don't have idea about what is missing except one. Some endpoints send openlogical channels regardless they are opened by fast start and it's possible that avaya have 16mins timeout for opening LC's but they aren't opened by signalling because already by faststart.
For testing this suggestion you can disable faststart in ooh323 and place call.
For this call logical channels will be opened by H.245 signalling.
By: Alexander Anikin (may213) 2011-01-24 16:19:28.000-0600

And one more thing  to previous.
Since reworked chan_ooh323 fast start propagation is sent only one time. It's possible that Avaya require fs propagation in connect signal packet. patch is uploaded. Can be tested with fast start enabled.
By: Vladimir Mikhelson (vmikhelson) 2011-01-24 16:50:26.000-0600

May213,

Here are the original Avaya peer details:

pbx*CLI> ooh323 show peer avaya
Name:          avaya
FastStart/H.245 Tunneling:yes,no
Format Prefs:  (ulaw:20)
DTMF Mode:     h245alphanumeric
T.38 Mode:     faxgw/chan_sip compatible
AccountCode:   h3230101
AMA flags:     Unknown
IP:Port:       172.17.135.2:1720
OutgoingLimit: 0
rtptimeout:    60

I have set "faststart=no" for the Avaya peer and reloaded OOH323.

pbx*CLI> ooh323 reload
Reloading H.323
 == Parsing '/etc/asterisk/ooh323.conf':   == Found
   --   == Setting default context to default
pbx*CLI> ooh323 show peer avaya
Name:          avaya
FastStart/H.245 Tunneling:no,no
Format Prefs:  (ulaw:20)
DTMF Mode:     h245alphanumeric
T.38 Mode:     faxgw/chan_sip compatible
AccountCode:   h3230101
AMA flags:     Unknown
IP:Port:       172.17.135.2:1720
OutgoingLimit: 0
rtptimeout:    60
pbx*CLI>

Then I placed a call from Avaya to Asterisk. I made sure to make some noises so that RTP timeout would not kick in.

I observed the following messages in the Avaya Monitor:

  67151mS H245Tx: v=10287 peb=9
           MultimediaSystemControlMessage = request = roundTripDelayRequest

  67197mS H245Rx: v=10287 peb=9
           MultimediaSystemControlMessage = response = roundTripDelayResponse

  73199mS H245Tx: v=10287 peb=9
           MultimediaSystemControlMessage = request = roundTripDelayRequest

  73248mS H245Rx: v=10287 peb=9
           MultimediaSystemControlMessage = response = roundTripDelayResponse

They were produced every 6 seconds.

At 16 minutes mark Asterisk stopped responding and Avaya started the count down:

206196mS H245Tx: v=10287 peb=9
           MultimediaSystemControlMessage = request = roundTripDelayRequest

206196mS PRN: Round trip delay timeout retry=9, lost ack: seq=157, ack=156 on call 0.10287.0
212198mS H245Tx: v=10287 peb=9
           MultimediaSystemControlMessage = request = roundTripDelayRequest

212198mS PRN: Round trip delay timeout retry=8, lost ack: seq=158, ack=157 on call 0.10287.0

Asterisk dropped the call almost immediately whereas Avaya still did not disconnect.

Finally Avaya gave up and dropped the call too.

What do you think?  Should I apply the latest patch or does this test give some additional information to think about?

Thank you,
Vladimir


By: Vladimir Mikhelson (vmikhelson) 2011-01-24 17:10:18.000-0600

May213,

I have verified my firewalls' settings.

Default TCP Connection Timeout is 5 minutes on the Avaya end and 15 minutes on the Asterisk end.

Thank you,
Vladimir
By: Vladimir Mikhelson (vmikhelson) 2011-01-24 17:26:47.000-0600

May213,

Here is the respective portion of the h323_log:

16:41:04:748  Queued H245 messages 1. (incoming, ooh323c_7)
16:41:04:748  msgCtxt Reset? Done (incoming, ooh323c_7)
16:41:04:748  Finished handling H245 message. (incoming, ooh323c_7)
16:41:04:748  Sending H245 message (incoming, ooh323c_7)
16:41:04:748  Sending OORequestDelayResponse H245 message over H.245 channel. (incoming, ooh323c_7)
16:41:04:749  H245 Message sent successfully (incoming, ooh323c_7)
16:41:10:956  Receiving H245 message
16:41:10:956  Complete H245 message received (incoming, ooh323c_7)
16:41:10:956  Received H.245 Message = {
16:41:10:956     request = {
16:41:10:956        roundTripDelayRequest = {
16:41:10:956           sequenceNumber = {
16:41:10:957              155
16:41:10:957           }
16:41:10:958        }
16:41:10:958     }
16:41:10:958  }
16:41:10:958  Handling H245 message. (incoming, ooh323c_7)
16:41:10:959  Received roundTripDelayRequest - 155 (incoming, ooh323c_7)
16:41:10:959  Built RoundTripDelayResponse message (incoming, ooh323c_7)
16:41:10:959  Sending H.245 Message = {
16:41:10:959     response = {
16:41:10:959        roundTripDelayResponse = {
16:41:10:959           sequenceNumber = {
16:41:10:960              155
16:41:10:960           }
16:41:10:961        }
16:41:10:961     }
16:41:10:961  }
16:41:10:961  Queued H245 messages 1. (incoming, ooh323c_7)
16:41:10:961  msgCtxt Reset? Done (incoming, ooh323c_7)
16:41:10:962  Finished handling H245 message. (incoming, ooh323c_7)
16:41:10:962  Sending H245 message (incoming, ooh323c_7)
16:41:10:962  Sending OORequestDelayResponse H245 message over H.245 channel. (incoming, ooh323c_7)
16:41:10:962  H245 Message sent successfully (incoming, ooh323c_7)
16:41:11:759  Error:Transport failure while reading Q931 message (incoming, ooh323c_7)
16:41:11:759  In ooEndCall call state is - OO_CALL_CLEARED (incoming, ooh323c_7)
16:41:11:760  Cleaning Call (incoming, ooh323c_7)- reason:OO_REASON_TRANSPORTFAILURE
16:41:11:760  Clearing all logical channels (incoming, ooh323c_7)
16:41:11:760  Clearing logical channel number 1001. (incoming, ooh323c_7)
16:41:11:760  Stopped Transmit channel 1001 (incoming, ooh323c_7)
16:41:11:760  Removed logical channel 1001 (incoming, ooh323c_7)
16:41:11:760  Clearing logical channel number 258. (incoming, ooh323c_7)
16:41:11:760  Stopped Receive channel 258 (incoming, ooh323c_7)
16:41:11:760  Removed logical channel 258 (incoming, ooh323c_7)
16:41:11:760  Closing H.245 connection (incoming, ooh323c_7)
16:41:11:760  Closed H245 connection. (incoming, ooh323c_7)
16:41:11:760  Closing H.245 Listener (incoming, ooh323c_7)
16:41:11:760  Removing call e2050d8: ooh323c_7
16:41:11:760  Removed call (incoming, ooh323c_7) from list
16:41:11:761  Ending Call Monitor thread

Thank you,
Vladimir
By: Vladimir Mikhelson (vmikhelson) 2011-01-24 17:53:10.000-0600

May213,

Here is a snapshot of a firewall traffic monitor on the Asterisk end. Interestingly the first TCP connection which looks like a control connection to me does not send back any traffic. It initially sent 750 bytes. Then it periodically receives packets but does not reply. One-time increment is around 153 bytes.

# Source IP Source Port Destination IP Destination Port Protocol Src Interface Dst Interface Tx Bytes Rx Bytes
1 172.17.135.2 4488 172.17.137.11 1720 TCP OPT LAN 750 2513
2 172.17.135.2 51081 172.17.137.11 12113 UDP OPT LAN 9288 7728
3 172.17.135.2 51080 172.17.137.11 12112 UDP OPT LAN 4239200 207800
4 172.17.135.2 4489 172.17.137.11 12037 TCP OPT LAN 9687 3893

Here is the snapshot in 12.5 minutes:

# Source IP Source Port Destination IP Destination Port Protocol Src Interface Dst Interface Tx Bytes Rx Bytes
1 172.17.135.2 4488 172.17.137.11 1720 TCP OPT LAN 750 2972
2 172.17.135.2 51081 172.17.137.11 12113 UDP OPT LAN 16416 13616
3 172.17.135.2 51080 172.17.137.11 12112 UDP OPT LAN 7405600 716400
4 172.17.135.2 4489 172.17.137.11 12037 TCP OPT LAN 16164 6290

Here is a final snapshot at 16 minutes when the call was dropped:

# Source IP Source Port Destination IP Destination Port Protocol Src Interface Dst Interface Tx Bytes Rx Bytes
1 172.17.135.2 4488 172.17.137.11 1720 TCP OPT LAN 750 3125
2 172.17.135.2 51081 172.17.137.11 12113 UDP OPT LAN 21060 17664
3 172.17.135.2 51080 172.17.137.11 12112 UDP OPT LAN 2400 0

As you see the non-responsive TCP connection did not drop but another TCP connection was dropped and one of the UDP connections was reset.

This test pretty much rules out a TCP timeout as a cause of the disconnect.

Some H323 control signaling is not understood by Avaya and is left unanswered.  Asterisk apparently gives up after a certain number of attempts.

Thank you,
Vladimir


By: Vladimir Mikhelson (vmikhelson) 2011-01-24 18:38:34.000-0600

May213,

I have captured the packet trace on port 1720.

It pretty much shows that there is some negotiation problem where Asterisk sends some control information which Avaya does not respond to.  Sounds like a protocol version issue to me.  Or maybe just a bug.

Asterisk re-sent the same packet 16 times and then dropped the connection. Interestingly, Asterisk sent these packets with a 120 seconds interval after the 9th packet in series. It did not send the 17th packet. At that same time as we know from the prior log analysis Avaya did not receive a roundTripDelayRequest message response and started its retries with countdown. It took Avaya about 15-20 seconds to finish its countdown. Then it tore down the call and sent out the RST.

Please see the trace.

Thank you,
Vladimir


By: Alexander Anikin (may213) 2011-01-25 15:58:28.000-0600

Vladimir,

seen trace, it's like to firewall issue on avaya side (but possible on asterisk side). Asterisk receive ack for all sended tcp packets except connect packet for which ack isn't received. Asterisk try resend connect message increasing resending interval step by step up to 2 mins between tries. On 16th attempt reset packet arrive from avaya.
It's very similar there is l7 (application layer) firewall which can't interpret signalling packets properly. Also i see you disable fast start but don't capture h.245 session (it's additional tcp connect between avaya and asterisk).
What firewall software you use on asterisk and avaya? Btw, i seen similar troubles on old version h323 conntrack module from netfilter linux firewall module.
By the way, you can try do tests with h245tunneling enabled on asterisk and avaya, with latest patch it must work also. But i think what we can accept this issue as resolved when we will receive god results for all configurations of h.323 options.

Also, please try calls between avaya and asterisk without any firewalls on
route if it's possible.


By: Vladimir Mikhelson (vmikhelson) 2011-01-25 18:08:08.000-0600

May213,

There are no firewalls on either Asterisk or Avaya boxes. They are connected via unrestricted IPSEC tunnel terminated on the respective gateways.

One comment on the RST packet. Asterisk failed to produce RST although it tore down the call. Avaya sent RST only after it finished it re-connect count down.

I will try the same with h245tunneling enabled.

Thank you,
Vladimir


By: Vladimir Mikhelson (vmikhelson) 2011-01-25 18:31:04.000-0600

May213,

I turned on h245tunneling, left faststart off.

pbx*CLI> ooh323 show peer avaya
Name:          avaya
FastStart/H.245 Tunneling:no,no
Format Prefs:  (ulaw:20)
DTMF Mode:     h245alphanumeric
T.38 Mode:     faxgw/chan_sip compatible
AccountCode:   h3230101
AMA flags:     Unknown
IP:Port:       172.17.135.2:1720
OutgoingLimit: 0
rtptimeout:    60
pbx*CLI> ooh323 reload
Reloading H.323
 == Parsing '/etc/asterisk/ooh323.conf':   == Found
   --   == Setting default context to default
pbx*CLI> ooh323 show peer avaya
Name:          avaya
FastStart/H.245 Tunneling:no,yes
Format Prefs:  (ulaw:20)
DTMF Mode:     h245alphanumeric
T.38 Mode:     faxgw/chan_sip compatible
AccountCode:   h3230101
AMA flags:     Unknown
IP:Port:       172.17.135.2:1720
OutgoingLimit: 0
rtptimeout:    60
pbx*CLI>

Tried placing calls. No fun. Calls dropped in 30 seconds. Also there was no sound both ways.

I will attach the packet trace of one call and the log.

Thank you,
Vladimir


By: Vladimir Mikhelson (vmikhelson) 2011-01-25 18:47:19.000-0600

May213,

I just realized that your latest patch5 was not applied by me as you never replied to my question in note ASTERISK-1239868 regarding its application.

I am assuming you still want me to try it. So I will apply it now and re-run the test.

Thank you,
Vladimir
By: Vladimir Mikhelson (vmikhelson) 2011-01-25 19:48:08.000-0600

May213,

I went ahead applied the patch and placed the incoming call with the same settings. Observed the same 30 seconds disconnect. Please let me know if you need the log and trace.

Returned h245tunneling to off, reloaded ooh323. That crashed the Asterisk. That was quite unexpected.  The log for the interrupted call is not available as it is wiped out upon the Asterisk restart, sorry. Packet trace was saved.

After the Asterisk returned back I placed a test incoming call. Sound was present, 30 second disconnect did not occur as expected.

Unfortunately, no difference in behavior. The call was interrupted at 16 minutes by Asterisk with Avaya following it at 17 minute mark with the similar packet exchange.

Thank you,
Vladimir


By: Vladimir Mikhelson (vmikhelson) 2011-01-28 15:31:59.000-0600

May213,

I have some news.

First, I am back to patch 4 as after I have applied patch 5 Asterisk crashed periodically.  It may be related to other bugs in the SVN trunk though.

Second, I discovered that some of the port 1720 traffic was dropped by the tunnel end-point on the Avaya end. The traffic was dropped as it did not comply with H.323. As I turned off the compliance check, and packets started flowing, I got a rather unexpected result. The incoming call was dropped in 5 minutes.

The respective log and packet trace are attached.

Thank you,
Vladimir
By: Alexander Anikin (may213) 2011-01-29 09:56:10.000-0600

Vladimir,

5 minutes issue like to the previous, h.323 connection was aborted by avaya.


15:00:22:890  Sending OORequestDelayResponse H245 message over H.245 channel. (incoming, ooh323c_1)
15:00:22:890  H245 Message sent successfully (incoming, ooh323c_1)
15:00:26:007  Error:Transport failure while reading Q931 message (incoming, ooh323c_1)
15:00:26:007  In ooEndCall call state is - OO_CALL_CLEARED (incoming, ooh323c_1)
15:00:26:007  Cleaning Call (incoming, ooh323c_1)- reason:OO_REASON_TRANSPORTFAILURE


I think it can be related to 5 minutes TCP timeout on Avaya.
By: Vladimir Mikhelson (vmikhelson) 2011-01-29 17:23:59.000-0600

May213,

We are facing two (2) separate issues.

1. SonicWall end-point dropping H.323 traffic as not H.323 compliant. First packet dropped was packet # 20 as I documented in the .pcap name. All other devices but Asterisk are working fine with the enforcement activated. Asterisk version 1.6.2.15 worked fine as well. The implementation coming with 1.8.x does not pass the test, and the traffic is dropped as a result.
2. "Default TCP Connection Timeout" is a global SonicWall setting applicable to all connections, it is not specific to Avaya. I can force it to 10, 15 minutes, etc. That will mean that the call will be dropped at that time. On top of that it is insecure.

The bottom line there is some H.323 in-compliance and there are no keep alive messages to keep the established TCP connection on. It would be nice to fix both, but keep-alive for a lengthy TCP connection is a must.

Thank you,
Vladimir


By: Vladimir Mikhelson (vmikhelson) 2011-01-29 17:26:49.000-0600

May213,

The level of my Asterisk instability (built from SVN Trunk) became intolerable. Can I apply your patches to the 1.8.x tags?

Thank you,
Vladimir


By: Alexander Anikin (may213) 2011-01-29 18:04:39.000-0600

Vladimir,

Can you attach gdb backtrace from core dump of asterisk after crash? It possible
ooh323 issue with patches posted here or not.

Also can you setup previous version of asterisk with previous ooh323 wich work well on your environment? I will try to understand what changed from previous version and why your firewall not understand packets as h.323 compliant. There will need ooh323_log and cap file. If you can do this with previous version please send me files to email: <my nic here> @ yandex.ru.
Btw, i don't see any keepalive support in previous version of ooh323, but i prepared patch for keepalive support and will upload it now.

You can apply patches to 1.8 tags, there are no significant changes since 1.8.1 even which can prevent it.
By: Alexander Anikin (may213) 2011-01-29 18:21:05.000-0600

Vladimir,

patch uploaded, it's 5th patch + keepalive setup on tcp sockets.

But i'm inclined to think that main issue reason is a misunderstanding packets
as H.323 signalling by your firewall and it's possible only reason.
By: Vladimir Mikhelson (vmikhelson) 2011-01-30 03:33:48.000-0600

May213,

As the Asterisk was compiled with the "DONT_OPTIMIZE" unchecked the core dumps I currently have are not very usable according to the https://wiki.asterisk.org/wiki/display/AST/Getting+a+Backtrace.  I will compile now with the flag checked.

Unfortunately it is virtually impossible for me to roll back to 1.6.2.x as the system I am running is production with a limited resources as I mentioned before.

I failed to apply your patches to 1.8.2.3 due to multiple errors, and I am applying them to the SVN trunk again.

All tests passed fine with SonicWall H.323 inspection turned off. I captured the trace and observed Asterisk sending keep-alive packets every 2 minutes with Avaya properly acknowledging them. The test call lasted 20 minutes with no interruption.

It looks like we are making progress.

Thank you,
Vladimir
By: Vladimir Mikhelson (vmikhelson) 2011-01-31 15:40:17.000-0600

May213,

Some good and some bad news.

Good news. All tests passed well with the latest patch. First I tested with FastStart and H245Tunnelling off, then I turned both on, reloaded ooh323 with no problems, Asterisk did not crash that far. I have placed a 25 minutes incoming call, tested incoming and outgoing DTMF, placed outgoing calls, placed calls on hold on Avaya end, conferenced calls. I have not experienced virtually any problems. The biggest problem I hit so far was I lost the Music on Hold after a took away one leg of the conference call and placed the remaining leg on hold. They did not hear any more MOH. I will let you know how the testing goes in couple days.

Bad news. When I placed an incoming call from Avaya to Asterisk, Asterisk crashed.

Core was generated by `/usr/sbin/asterisk -f -U asterisk -G asterisk -vvvg -c'.
Program terminated with signal 11, Segmentation fault.
#0  0x01201dc1 in ooTrace (traceLevel=) at ooh323c/src/ootrace.c:53

I will attach the gdb backtrace.

Thank you,
Vladimir
By: Vladimir Mikhelson (vmikhelson) 2011-01-31 18:33:10.000-0600

May213,

I have tried enabling H.323 processing in SonicWall. Incoming call failed in 30 seconds.

Pcap is attached.

Thank you,
Vladimir
By: Alexander Anikin (may213) 2011-02-09 17:14:34.000-0600

Final patch for this issue uploaded.

Changes are:
process remote side H.225 version, don't start TCS and MSD before connect with H.323v2 (older) endpoints, don't start TCS and MSD by accepting H.245 connection, start TCS and MSD by StartH245 facility message,
fix non zeroended remoteDisplayName issue,
small fixes in call clearing by closing H.245 connection,
tcp keepalive introduced on TCP connections (now is hardcoded, will be configurable in the future),
don't force H.245tunneling if FastStart is active,
don't send Alerting singal more than once per call.
By: Vladimir Mikhelson (vmikhelson) 2011-02-09 19:17:13.000-0600

May213,

Everything works fine with patches applied to the latest tag 1.8.2.3.  Unfortunately I was unable to test with either branch 1.8 or SVN trunk as both had voice mail broken so badly that Asterisk crashed when I tried to use them.

With patched ver. 1.8.2.3 both incoming and outgoing calls are placed and terminated as expected, no delays are experienced. SonicWall's deep packet inspection is turned on and no packets are being dropped by it. Keep alive packets prevent TCP and UDP connections' timeouts. No calls are prematurely terminated.

There is no log "poisoning" experienced any more.

OOH323 did not cause Asterisk segmentation faults in my experiments.

The only risk is the patch going to be merged is technically different from what I tested with in 1.8.2.3. Hopefully it is still addressing all the issues and we will not hit any regression here.  I will retest everything as the voice mail issue is fixed.

Thank you for your great work,
Vladimir


By: Alexander Anikin (may213) 2011-02-10 07:18:55.000-0600

Due to some trouble with trunk patch for 1.8.2.3 uploaded also.
By: Alexander Anikin (may213) 2011-02-10 07:23:43.000-0600

Vladimir,

As everything for this issue is fixed, i'll close this one.
Feel free to reopen issue if it will needed.

Thank you for intensive testing.
By: Digium Subversion (svnbot) 2011-02-10 07:29:22.000-0600

Repository: asterisk
Revision: 307396

U   trunk/addons/chan_ooh323.c
U   trunk/addons/ooh323c/src/ooCalls.h
U   trunk/addons/ooh323c/src/ooSocket.c
U   trunk/addons/ooh323c/src/ooStackCmds.c
U   trunk/addons/ooh323c/src/oochannels.c
U   trunk/addons/ooh323c/src/ooh245.c
U   trunk/addons/ooh323c/src/ooh323.c
U   trunk/addons/ooh323c/src/ooq931.c

------------------------------------------------------------------------
r307396 | may | 2011-02-10 07:29:20 -0600 (Thu, 10 Feb 2011) | 23 lines

Corrections for properly work with H.323v2 (older) endpoints and other
small fixes.

Interpret remote side H.225 version.

Corrections for H.323v2 endpoints:
don't start TCS and MSD before connect,
don't start TCS and MSD by accepting H.245 connection,
start TCS and MSD by StartH245 facility message.

Other fixes:
fix non zeroended remoteDisplayName issue, small fixes in call clearing
by closing H.245 connection, tcp keepalive introduced on TCP
connections (now is hardcoded, will be configurable in the future),
don't force H.245tunneling if FastStart is active, don't send Alerting
singal more than once per call.

(closes issue ASTERISK-17172)
Reported by: vmikhelson
Patches:
     issue18542-final-3.patch uploaded by may213 (license 454)
Tested by: vmikhelson

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

http://svn.digium.com/view/asterisk?view=rev&revision=307396
By: Digium Subversion (svnbot) 2011-06-01 05:40:22

Repository: asterisk
Revision: 321528

U   branches/1.8/addons/chan_ooh323.c
U   branches/1.8/addons/ooh323c/src/oochannels.c
U   branches/1.8/addons/ooh323c/src/ooh245.c

------------------------------------------------------------------------
r321528 | may | 2011-06-01 05:40:22 -0500 (Wed, 01 Jun 2011) | 14 lines

Fix double alerting, add forced alerting before answer

Fix double alerting (it wasn't fixed here by issue ASTERISK-17172)
Add forced alerting before connect (if it wasn't before)
Try to send all packets from outgoing queue rather than one only
Call goes into clearing state when disconnect command is received

(closes issue ASTERISK-17919)
Reported by: vmikhelson
Patches:
     issue19361-3.patch uploaded by may213 (license 454)
Tested by: vmikhelson


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

http://svn.digium.com/view/asterisk?view=rev&revision=321528
By: Digium Subversion (svnbot) 2011-06-01 05:45:15

Repository: asterisk
Revision: 321529

_U  trunk/
U   trunk/addons/chan_ooh323.c
U   trunk/addons/ooh323c/src/oochannels.c
U   trunk/addons/ooh323c/src/ooh245.c

------------------------------------------------------------------------
r321529 | may | 2011-06-01 05:45:15 -0500 (Wed, 01 Jun 2011) | 20 lines

Merged revisions 321528 via svnmerge from
https://origsvn.digium.com/svn/asterisk/branches/1.8

........
 r321528 | may | 2011-06-01 14:40:19 +0400 (Wed, 01 Jun 2011) | 14 lines
 
 Fix double alerting, add forced alerting before answer
 
 Fix double alerting (it wasn't fixed here by issue ASTERISK-17172)
 Add forced alerting before connect (if it wasn't before)
 Try to send all packets from outgoing queue rather than one only
 Call goes into clearing state when disconnect command is received
 
 (closes issue ASTERISK-17919)
 Reported by: vmikhelson
 Patches:
       issue19361-3.patch uploaded by may213 (license 454)
 Tested by: vmikhelson
........

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

http://svn.digium.com/view/asterisk?view=rev&revision=321529
By: AvayaXAsterisk (avayax) 2014-09-20 17:19:47.355-0500

Running into exactly the same console and log messages with outgoing calls. Using Asterisk 11.6. Incoming calls are fine. Help appreciated
By: Alexander Anikin (may213) 2014-09-21 13:34:09.949-0500

Hi,
please attach asterisk verbose and ooh323_log for the problematic call.