Summary: | ASTERISK-25330: Failed to originate a call using AMI on OOH323 channel (Avaya) | ||
Reporter: | Vincent BEZARD (vbezard) | Labels: | |
Date Opened: | 2015-08-19 07:17:38 | Date Closed: | 2020-01-14 11:14:03.000-0600 |
Priority: | Major | Regression? | |
Status: | Closed/Complete | Components: | Addons/chan_ooh323 |
Versions: | 1.8.13.1 | Frequency of Occurrence | |
Related Issues: | |||
Environment: | Debian Wheezy H323 trunk with an ACM r6.2 | Attachments: | ( 0) mylogger.txt |
Description: | I want to originate a call using AMI to a device localized on the Avaya side.
My issue: no call is distributedto the ACM. Here is the AMI message: {noformat} Action: Originate ActionID: 12036987_35# Channel: OOH323/avaya-acm/4102 Context: observeRecord Exten: Local/observe Priority: 1 Async: false Timeout: 0 Variable: var1=TOTO|var2=TITI|var3=TUTU {noformat} On the CLI, here is the H323 traces: {noformat} --- ooh323_request - data avaya-acm/4102 format 0x40 (slin) --- ooh323_alloc +++ ooh323_alloc --- find_peer "avaya-acm" comparing with "192.168.10.102" found matching peer +++ find_peer "avaya-acm" --- ooh323_new - avaya-acm, 64 +++ h323_new +++ ooh323_request --- ooh323_call- avaya-acm/4102 --- onNewCallCreated 2d1f8b8: ooh323c_o_13 --- find_call +++ find_call +++ ooh323_call > Channel OOH323/avaya-acm-13 was never answered. --- ooh323_hangup hanging avaya-acm with cause: 16 +++ ooh323_hangup Outgoing call avaya-acm(ooh323c_o_13) - Codec prefs - (alaw) Adding capabilities to call(outgoing, ooh323c_o_13) Adding g711 alaw capability to call(outgoing, ooh323c_o_13) --- configure_local_rtp +++ configure_local_rtp +++ onNewCallCreated ooh323c_o_13 --- onOutgoingCall 2d1f8b8: ooh323c_o_13 --- find_call +++ find_call +++ onOutgoingCall ooh323c_o_13 --- onCallCleared ooh323c_o_13 --- find_call +++ find_call +++ onCallCleared --- ooh323_destroy Destroying avaya-acm Destroying ooh323c_o_13 +++ ooh323_destroy {noformat} I do not see the call incoming on the ACM side. So, I have made some network traces, and I can see that the only H323 message is related to a RELEASE_COMPLETE => There is no setup message. Here is the ooh323.conf: {noformat} [general] port=1720 bindaddr=192.168.40.13 progress_setup=8 progress_alert=8 faststart=yes h245tunneling=yes gatekeeper=DISABLE disallow=all allow=alaw dtmfmode=inband context=internal [avaya-acm] type=friend context=internal host=192.168.10.102 port=1720 disallow=all allow=alaw canreinvite=no dfmfmode=inband e164=#41 h323id=Asterisk {noformat} Please, advise, Vincent | ||
Comments: | By: Asterisk Team (asteriskteam) 2015-08-19 07:17:40.368-0500 The severity of this issue has been automatically downgraded from "Blocker" to "Major". The "Blocker" severity is reserved for issues which have been determined to block the next release of Asterisk. This severity can only be set by privileged users. If this issue is deemed to block the next release it will be updated accordingly during the triage process. By: Asterisk Team (asteriskteam) 2015-08-19 07:17:41.234-0500 Thanks for creating a report! The issue has entered the triage process. That means the issue will wait in this status until a Bug Marshal has an opportunity to review the issue. Once the issue has been reviewed you will receive comments regarding the next steps towards resolution. A good first step is for you to review the [Asterisk Issue Guidelines|https://wiki.asterisk.org/wiki/display/AST/Asterisk+Issue+Guidelines] if you haven't already. The guidelines detail what is expected from an Asterisk issue report. Then, if you are submitting a patch, please review the [Patch Contribution Process|https://wiki.asterisk.org/wiki/display/AST/Patch+Contribution+Process]. By: Vincent BEZARD (vbezard) 2015-08-19 09:05:59.398-0500 Here is the logger content. By: Vincent BEZARD (vbezard) 2015-08-19 09:55:03.850-0500 I have made further tests: if I made a call from a SIP extension to the H323 trunk, it works. it means that the issue is on the Originate AMI. By: Vincent BEZARD (vbezard) 2015-08-19 10:21:05.260-0500 Another information: If make the originate from the CLI, it works: channel originate OOH323/4102@avaya-acm extension SIP/1000 By: Alexander Anikin (may213) 2015-08-19 11:12:21.707-0500 Hello Vincent, Could you please set up tracelevel=6 in your ooh323.conf, reload chan_ooh323, try AMI originate and attach here /var/log/h323_log? By: Vincent BEZARD (vbezard) 2015-08-19 11:14:50.447-0500 Well .. .I have spent a huge amount of time on this issue. In fact, using AMI, there are some mandatory data, but if there are not set, there is not error. It seens then that ooh323 is missing some parameters, and make it failed. It counlt be great to check the mandatory data to give an error message. Issue is solved for me, but may be is could be transformed into evolution. If needed, contact me: vbezard@hotmail.com Regards, Vincent By: Vincent BEZARD (vbezard) 2015-08-19 11:16:28.076-0500 @Alexander: regarding to my last comment, do you need me to raise to tracelevel 6? By: Alexander Anikin (may213) 2015-08-19 13:34:53.545-0500 Vincent, I assume that there are no problem from ooh323 side. Asterisk core send hangup to OOH323 channel by calling ooh323_hangup function. You can see it from your log: --- ooh323_hangup hanging avaya-acm with cause: 16 +++ ooh323_hangup So call disconnect was initiated from Asterisk core. But it could be interested what is reason of that. Please explain which data you add to Originate AMI command for OOH323 calls. By: Vincent BEZARD (vbezard) 2015-08-21 02:11:13.033-0500 Hi Alexander, Sorry for the delay. In fact using AMI, if I do not set the timeout property, then the ORIGINATE failed. Feel free to contact me if you need more information. Regards, Vincent By: Rusty Newton (rnewton) 2015-09-05 11:46:20.498-0500 [~vbezard] to confirm the issue: Are you saying that if you do not define a timeout property at all (undefined) then the originate fails every-time? Does it matter what channel technology you use? Can you try this with a SIP or PJSIP channel? By: Alexander Anikin (may213) 2015-09-08 18:14:43.119-0500 Vincent, You set 'Timeout: 0' in your Originate AMI command and this mean exactly 0 but not default timeout value. It is according the codes from main/manager.c: if (!ast_strlen_zero(timeout) && (sscanf(timeout, "%30d", &to) != 1)) { astman_send_error(s, m, "Invalid timeout"); return 0; So this way dialout procedure just return back from creating outgoing channel and timeout expire immediately. Same behaviour found in all versions of asterisk. Please close this issue and open for asterisk core component if you think that is wrong. By: Asterisk Team (asteriskteam) 2015-09-23 12:00:18.913-0500 Suspended due to lack of activity. This issue will be automatically re-opened if the reporter posts a comment. If you are not the reporter and would like this re-opened please create a new issue instead. If the new issue is related to this one a link will be created during the triage process. Further information on issue tracker usage can be found in the Asterisk Issue Guidlines [1]. [1] https://wiki.asterisk.org/wiki/display/AST/Asterisk+Issue+Guidelines |