[Home]

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:38Date Closed:2020-01-14 11:14:03.000-0600
Priority:MajorRegression?
Status:Closed/CompleteComponents:Addons/chan_ooh323
Versions:1.8.13.1 Frequency of
Occurrence
Related
Issues:
Environment:Debian Wheezy H323 trunk with an ACM r6.2Attachments:( 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