We want to resolve the issue where calls between “internal and external lines” cannot be maintained using ARI

Asterisk Asterisk SIP
1

Hello, community members.
I’ve reviewed existing community posts and worked hard to solve the problem using AI, but I couldn’t resolve it, so I’m asking here.

What I’m Developing

I’m developing a service that transcribes and translates call audio.

Implementation Method

Using Asterisk 16, I created an ARI client application. I use externalmedia and snoop to send call audio to an external application,
and I use a different externalmedia to feed audio received from the external application back into the main call bridge.

Development Environment

ARI Client App: Node.js
Asterisk: 16.15.1
The Asterisk server is hosted on AWS EC2, while the external SIP-GW resides on a separate network.
Therefore, both internal and external calls are routed through the SIP-GW.
The Asterisk server and SIP-GW communicate via VPN.

Issue

There are three call patterns: internal-to-internal, external-to-internal, and internal-to-external.
During internal-to-external calls, the moment the external terminal rings and is answered,
a hangup request occurs, abruptly ending the call.
Internal-to-internal and external-to-internal calls function correctly, but the issue occurs only with internal-to-external calls.
Tracking logs from the CLI and client applications revealed the following sequence occurring within milliseconds:

  1. The client application originates the external call.
  2. External GW responds: The external GW returns a 200 OK and waits on RTP port 16908.
  3. Asterisk sends an ACK: The call is established.
  4. Bridge technology switch:
    • switching from simple_bridge technology to native_rtp
    • (Immediately afterward, Snoop starts) switching from native_rtp technology to simple_bridge
  5. Asterisk immediately sends Re-invite: Asterisk changes its receiving port to 10640 and re-sends to the external GW.
  6. External GW sends BYE: Disconnects with X-Asterisk-HangupCauseCode: 58.

Steps Taken for Improvement

The following actions were attempted, but did not resolve the issue; the call still disconnects with HangupCauseCode: 58.

  • Codec standardization: Logs indicated the internal codec was attempting to switch to GSM, causing transcoding with the external line (ulaw). Therefore, ulaw was set as the only allowed codec in sip.conf.
  • Delayed Snoop creation timing: Snoop creation occurred immediately when the external line went Up (answered), so we introduced a 1500ms delay.

Desired Outcome

We want to maintain calls from internal to external lines without triggering forced hangups.

I have attached the source code for the ARI client application and the text file containing the CLI logs. I would appreciate it if you could review them.

cli_log.txt (11.4 KB)

ari_client.zip (8.7 KB)

2

Be aware that this is a 5+ year old version of Asterisk. It’s entirely possible there was a bug back then in some usage that has since been resolved. Nothing springs to mind but it being so old it’s probably gone from my mind, and it’s not something I’m going to dig into myself. I’m also not aware of any current issues involving chan_sip exhibiting this behavior.

3

Thank you very much for your prompt reply.

It’s possible that this might be a bug due to the outdated version.

We plan to update Asterisk to version 20 in the future. Have you encountered similar issues with that version?

4

Issues are public, so you or anyone can check things yourself[1] but I am not aware of any such issues.

[1] https://github.com/asterisk/asterisk/issues

5

I had overlooked the GitHub issues.

I will also check the GitHub issues on my end.

As a follow-up, I’ve attached the source code for the ARI client application and the CLI logs for your reference.

Thank you for your assistance.

6

There is nothing that stands out in the SIP signaling. The specific leg that was hung up by the remote Asterisk was ulaw always. Why it didn’t like ulaw after it was already negotiated and accepted, no idea.

7

Thank you for your confirmation.

According to AI, this error occurs even with the correct codec because the external line gateway (carrier-side equipment) has fallen into the following state. Is this truly possible?

・State Inconsistency (Race Condition): On the external line gateway side, the next 103 INVITE arrived before processing for the initial INVITE (resource allocation and billing initiation) was completed.

・Rejection of Port Change: Although RTP had started flowing normally on the initial connection, within less than 0.1 seconds, it was requested to “change the port to 10640 after all.” The carrier-side equipment determined that it “cannot handle such a rapid media change (Bearer capability not available)” and processed it as an error.

8

shrug I don’t have anything else to add to this discussion, don’t know.

9

Understood. Thank you for taking the time out of your busy schedule.