-
Notifications
You must be signed in to change notification settings - Fork 18
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Compatibility of Cirpack's trunks with TOPOS in Kamailio #7183
Comments
We choose to implement the 2nd solution:
|
Test case:
|
NethServer/dev#7183 Co-authored-by: Paolo <[email protected]>
* feat(trunks): add switch to enable/disable TOPOS - Added a switch in the trunks interface to enable or disable TOPOS. - When the "disable TOPOS" switch is activated, an "topos=0" header is sent in INVITE requests to instruct the nethvoice-proxy Kamailio to disable the TOPOS module for that specific invite. - TOPOS configuration for trunks is now stored in the NethCTI FreePBX module's configuration key-value store. - Modified the trunk interface and dialplan using dialplan hooks to accommodate the new feature. - Automatically set the `disable_topos` value for trunks created via the wizard. - Remove the `disable_topos` value when a trunk is deleted via the wizard. - Added a new MySQL table to store default `disable_topos` values. - If no default `disable_topos` value is specified, no header will be sent and Kamailio will use TOPOS nethesis/ns8-nethvoice-proxy#51 - Add switch to control the sending of encrypted media on trunks. - Migrate existing trunks to avoid attempting encrypted media with providers where media encryption is disabled. - Removed legacy SQL tables that were used for database initialization in previous versions. - Now all database tables are initialized in mariadb container and altered in freepbx/initdb.d NethServer/dev#7183
nethvoice:1.1.3-testing.9 |
update a nethvoice with trunk that has a trunk that uses proxy and have srtp disabled Result: from wizard, create a trunk that has srtp disabled by default Result: check that topos=0 and isTrunk=1 headers can be enabled/disabled from freepbx -> connectivity -> trunks -> pjsip settins -> advanced Result check that topos=0 and isTrunk=1 headers, if enabled for a trunk, are sent to first invite when the outgoing call start, but not in the invite of call transfer Result make an outgoing call using a trunk that requires isTrunk=1 or topos=0 headers Result |
Fix an error in code for migration of existing trunks that prevented existing trunks to be configured to avoid SRTP by default NethServer/dev#7183
Testing release |
Repeat test case 1 |
Release |
Release |
Cirpack enforces a security mechanism where outbound INVITE requests must be pre-registered and conform to specific parameters. If these conditions are not met, the system does not respond with an "Auth Required" but instead outright rejects the call.
Current Setup
TOPOS Module Usage:
We utilize the TOPOS module in Kamailio to handle packet compaction (avoiding potential MTU issues) and for security purposes (hiding the network topology).
Per the documentation, REGISTER and PUBLISH requests are bypassed by TOPOS and are expected to terminate on a local SIP server.
Observed Behavior:
The REGISTER request correctly includes two VIA headers, as there are two hops, revealing the backend topology behind Kamailio.
The INVITE request, however, undergoes "topossification," hiding the network topology as intended.
Problem
If we attempt to mask the VIA headers in the REGISTER request for consistency with INVITE, it is unclear whether Kamailio will still be able to handle:
Incoming Calls via Trunk: If the REGISTER request lacks sufficient information, the system might fail to process incoming calls correctly.
Replies Routing: Without accurate state tracking, Kamailio might not route the responses to their intended destinations.
Potential Solutions
State Preservation with Key-Value Store:
Save critical data (e.g., VIA headers) from the REGISTER request in a key-value store like $shv.
Before processing a reply, restore the saved headers using msg_apply to enable proper routing.
This approach requires thorough testing to validate its effectiveness and ensure it handles edge cases (e.g., retries, network disruptions).
Custom SIP Header in Asterisk:
Implement a custom SIP header in Asterisk to instruct Kamailio not to activate TOPOS for specific trunks.
This solution has been used successfully in the past and could provide a quicker workaround if compatible with the current scenario.
The text was updated successfully, but these errors were encountered: