Support

The unsuccessful calls are cals made from phone towards a connected SIP
client,
Such calls shouldn't be successful as the call should be forward to hiSky
proxy.

The real issue are with calls from the hiSky Proxy towards Cloudonix domain
where the SIP session timeout and hangs.
I'm attaching here a SIP trace that I hope will help.

Regards,
Ofek

On Sun, Nov 30, 2025 at 1:06 PM Oded Arbel redmine@tickets.cloudonix.io
wrote:

Issue #2550 https://tickets.cloudonix.io/issues/2550#change-10458 has

been updated by Oded Arbel.¶

Do you have more information? Such as session tokens or SIP traces?
Even an exact time of a call that failed will help.

From looking at the domain I can set there were calls being run as late as

2025-11-27 (though not successful ones).¶

Support #2550: a call rejected from hisky proxy
https://tickets.cloudonix.io/issues/2550#change-10458 open

• *Author: *Hisky Ofeky
• *Status: *New
• *Priority: *High
• *Cloudonix Domain: *hisky.prod.cloudonix.net

The domain hisky.prod.cloudonix.net doesn't create a call for my

customers.¶

You have received this notification because you have either subscribed to
it, or are involved in it.
To change your notification preferences, please click here:
https://tickets.cloudonix.io/my/account

Hisky Ofeky wrote in #note-5:

The issue was with the VoIP Proxy firewall.
When the SIP ALG is disabled, the trunk starts to work properly.

Is there a way to make the trunk with Cloudonix work with SIP ALG enabled ?

A SIP ALG purpose is to modify the request so that the declared SIP and RTP ports are available for the server to connect to, when the client is behind NAT and is not using public IP addresses. This process should not make the transaction fail - let alone drop requests - unless the SIP ALG is configured incorrectly.

If the SIP ALG is so badly misconfigured that turning it off is the only remedy, then the only way for a connection to work is by not going through the SIP ALG. If actually turning off the SIP ALG in the NAT router is not an option, then the only other option is to circumvent the SIP ALG by making the router fail to detect the request as a SIP request. Cloudonix offers the following methods to escape SIP ALG detection:

1. Use a different UDP port - send your SIP UDP traffic to port 5061. This is commonly used as a SIP TLS port, though Cloudonix supports standard UDP sessions on port 5061, which is supposed to confuse SIP ALG routers.
2. Use a common non-SIP TCP port - use SIP TCP to port 80. This is the standard port for unencrypted HTTP traffic and routers usually don't investigate such TCP connections for SIP and should ignore all traffic on that port. If your router is also using a captive portal setup for HTTP traffic, it would block such connections, so this approach would not work. Cloudonix also supports TCP traffic to port 8080, which is a common alternative for unencrypted HTTP traffic, that captive portals often ignore, so that is another alternative.
3. Use TLS - send SIP TLS traffic to port 443 or 8443. Using a secure private channel would not allow any sort of packet inspection by the SIP ALG router and the connection should just go through unmodified. Cloudonix supports TLS access on ports that are commonly associated with encrypted HTTP traffic in order to further confuse SIP ALG routers, so that they don't touch the traffic, thinking its common web browsing.