NethVoice: FollowMe or "No Answer" queue forwarding to external numbers fails due to SDP encryption being forced

[mgarra]

Description:
When using FollowMe to forward a call to an external number, the call fails.
The same issue also occurs when using a queue as the "No Answer" destination of an extension (a more common scenario for this use case).

We discovered that the issue only happens when at least one extension is configured in UDP.

In this case, after a recent update, new dialplan rules are added in extensions_additional.conf like the following:

exten => s,n,GosubIf($["${FROMMACRODIALONE}" = "1" & x${REGEX("^(24|9124|9224|27|9127|9227|26|9126|9226|10|9110|9210|25|9125|9225|28|9128|9228|23|9219|9211|29|9129|18|9118|9218|9318|21|9121|9221|09|15|9115|222|223)$" ${CALLERID(num)})}x = x1x]?func-set-sipheader,s,1(isTrunk,1))
exten => s,n,GosubIf($["${FROMMACRODIALONE}" = "1" & x${REGEX("^(24|9124|9224|27|9127|9227|26|9126|9226|10|9110|9210|25|9125|9225|28|9128|9228|23|9219|9211|29|9129|18|9118|9218|9318|21|9121|9221|09|15|9115|222|223)$" ${CALLERID(num)})}x = x0x]?func-set-sipheader,s,1(isTrunk,unset))

Because of this logic, in the forwarded external call, the flag isTrunk=1 is removed.

As a result, SDP encryption is included in the INVITE, and the call fails with the provider:

-- Called PJSIP/0721405516@GNR
-- Connected line update to PJSIP/GNR-00000c0e prevented.
== Everyone is busy/congested at this time (1:0/1/0)
-- Executing [s@macro-dialout-trunk:33] NoOp("Local/870721405516@from-internal-00000427;2", "Dial failed for some reason with DIALSTATUS = CONGESTION and HANGUPCAUSE = 34") in new stack

How to reproduce:

1. Configure at least one extension in UDP.
2. Set FollowMe to forward calls to an external number, or configure a queue as "No Answer" destination for an extension, with the queue forwarding externally.
3. Place a call to the extension.
4. The forwarded external call will fail.

Expected behavior:
The external forwarded call should be placed correctly without forcing SDP encryption.

Actual behavior:
The INVITE contains SDP with encryption parameters, causing the provider to reject the call (513 Message too big or Congestion / Hangupcause 34).

Additional case with the same behavior:
There’s another scenario that shows the same symptom and is caused by the same issue.
Incoming calls that originate from a ring group also do not make the extensions ring for the same reason.
In this case, the INVITE message still contains the SDP with encryption enabled, which leads to the same handling problem.

[Stell0]

1.5.1-testing.12
Test case:

• verify the issue is no more reproducible
• verify again NethVoice: SRTP not working if one extension in the dial string has it disabled #7560 to avoid regressions
• verify again Nethvoice Proxy: Compatibility issue with initial SDP Offer using SRTP from NethVoice Proxy #7524 to avoid regressions