Re: [EXTERNAL] Attempt to remove unwanted media streams has no effect
David Villasmil via sr-users <[email protected]> Mon, 20 Apr 2026 02:42:25 +0200
| Newsgroups | gmane.comp.voip.ser |
|---|---|
| Message-ID | <CAFGRPVrnaoFptSFLoZKaR8dC2NPX45kuaH7d-F056ofZ2Ep0bA@mail.gmail.com> |
Hello all,
Here's a quick run-down of the flow:
I have a FS behind my outbound proxy. We want to do failiover on the proxy
itself instead of FS. FS is sending kamailio a X- header with the list of
gateways to try, i.e.: gw1,gw2.
I have a dialplan rule to match the received gw name which points at a
dispatcher list defining the gw (including ;transport=tls if the endpoint
is TLS).
When i receive an INVITE, i create the rules and load the dispatcher with
ds_select_routes("$var(rules)", "d")
and set failure routes, and send to RELAY.
The caveat is, some gws might be UDP and some might be TLS/SRTP, meaning
from FS i need to send out rtp_secure_media as optional, which includes an
SDP with BOTH RTP/AVP and RTP/SAVP.
Carriers do NOT want to see hybrid SDPs so i need to remove from the SDP
whatever's not supported by the gw, so on the outbound route (i.e. initial
INVITE processing):
if ( is_method("INVITE") ) {
if ( $du =~ "tls" ) {
xlogl("L_ERR", "[RELAY] TLS INVITE - Strippping RTP/AVP media
attributes\n");
sdp_remove_transport("RTP/AVP");
} else {
xlogl("L_ERR", "[RELAY] NON-TLS INVITE - Stripping RTP/SAVP
media attributes\n");
sdp_remove_transport("RTP/SAVP");
}
}
this works perfectly and the initial forwarded INVITE doesn't contain the
removed stream, i.e.: no RTP/AVP or no RTP/SAVP, which works ok, but on the
failover, it doesn't do what it's supposed to, or I'm not doing it right.
Here's a snippet of the important routes:
route[OUTBOUND_DISPATCH] {
xlogl("L_NOTICE", "[OUTBOUND_DISPATCH] X-Gateways=$hdr(X-Gateways)
rU=$rU\n");
# ds_select_routes selects dests from all groups in order:
# all active dests from first setid, then all from second, etc.
# Stored in XAVP for ds_next_dst() failover
if (!ds_select_routes("$var(rules)", "d")) {
xlogl("L_ERR", "[OUTBOUND_DISPATCH] No active carrier
destinations\n");
sl_send_reply("503", "No carrier destinations available");
exit;
}
t_set_fr(CARRIER_FR_INV_TIMER, CARRIER_FR_TIMER);
t_on_failure("RTF_CARRIER");
# If this is an initial INVITE and NOT tls, remove RTP/SAVP media
attributes to prevent downstream TLS negotiation issues
if ( is_method("INVITE") ) {
if ( $du =~ "tls" ) {
xlogl("L_ERR", "[RELAY] TLS INVITE - Strippping RTP/AVP media
attributes\n");
sdp_remove_transport("RTP/AVP");
#msg_apply_changes();
} else {
xlogl("L_ERR", "[RELAY] NON-TLS INVITE - Stripping RTP/SAVP
media attributes\n");
sdp_remove_transport("RTP/SAVP");
#msg_apply_changes();
}
}
route(RELAY);
exit;
}
failure_route[RTF_CARRIER] {
if (t_is_canceled()) exit;
...
if (t_check_status("[45][0-9][0-9]") || (t_branch_timeout() &&
!t_branch_replied())) {
if (ds_next_dst()) {
# Update carrier attrs for new destination
$dlg_var(carrier_attrs) = $xavp(_dsdst_=>attrs);
$dlg_var(auth_attempted) = "";
xlogl("L_NOTICE", "[RTF_CARRIER] Failing over to $du\n");
# If this is an initial INVITE and NOT tls, remove RTP/SAVP
media attributes to prevent downstream TLS negotiation issues
if ( is_method("INVITE") ) {
if ( $du =~ "tls" ) {
sdp_remove_transport("RTP/AVP");
} else {
sdp_remove_transport("RTP/SAVP");
}
}
t_set_fr(CARRIER_FR_INV_TIMER, CARRIER_FR_TIMER);
t_on_failure("RTF_CARRIER");
route(RELAY);
exit;
}
xlogl("L_ERR", "[RTF_CARRIER] All carrier destinations
exhausted\n");
append_to_reply("X-Carrier-Route: $dlg_var(carrier_route)\r\n");
t_reply("503", "All carriers exhausted");
exit;
}
}
Regards,
David Villasmil
email: [email protected]
On Sat, Apr 18, 2026 at 3:26 PM Richard Fuchs via sr-users <
[email protected]> wrote:
> Do you have something else in your Kamailio config that makes any changes
> to the SDP (rtpengine being the usual suspect)?
>
> On 17/04/2026 16.28, David Villasmil via sr-users wrote:
>
> Hello all,
>
> It's been a while!
>
> I'm receiving from freeswitch an INVITE with both RTP/AVP and RTP/SAVP.
> Providers don0t like this, they want to see a single audio stream offer,
> and i want to remove the non-supported stream on kamailio, since i have to
> mix and match on failover.
>
> I see kamailio attempting to remove the streams but it has no effect
> whatsoever, you'll see below enumerating the streams to remove, but doesn't
> actually removes them... (i didn't print out the SDP, it's done by the
> module, so it should be ok, furthermore that's what i see being forwarded):
>
> ```
> 5(13) DEBUG: INVITE <null> 1.2.3.4:5080
> 59bb066c-b53d-123f-47b3-1228f25c4047 sdpops [sdpops_mod.c:1374]:
> sdp_remove_transport(): attempting to search for transport type: [RTP/AVP]
> 5(13) DEBUG: INVITE <null> 1.2.3.4:5080
> 59bb066c-b53d-123f-47b3-1228f25c4047 sdpops [sdpops_mod.c:1390]:
> sdp_remove_transport(): stream 0 of 0 - transport [RTP/SAVP]
> 5(13) DEBUG: INVITE <null> 1.2.3.4:5080
> 59bb066c-b53d-123f-47b3-1228f25c4047 sdpops [sdpops_mod.c:1390]:
> sdp_remove_transport(): stream 1 of 0 - transport [RTP/AVP]
> 5(13) DEBUG: INVITE <null> 1.2.3.4:5080
> 59bb066c-b53d-123f-47b3-1228f25c4047 sdpops [sdpops_mod.c:1398]:
> sdp_remove_transport(): removing transport stream: RTP/AVP 5(13) DEBUG:
> INVITE <null> 1.2.3.4:5080 59bb066c-b53d-123f-47b3-1228f25c4047 sdpops
> [sdpops_mod.c:1390]: sdp_remove_transport(): stream 2 of 0 - transport
> [RTP/SAVP]
> 5(13) DEBUG: INVITE <null> 1.2.3.4:5080
> 59bb066c-b53d-123f-47b3-1228f25c4047 sdpops [sdpops_mod.c:1390]:
> sdp_remove_transport(): stream 3 of 0 - transport [RTP/AVP]
> 5(13) DEBUG: INVITE <null> 1.2.3.4:5080
> 59bb066c-b53d-123f-47b3-1228f25c4047 sdpops [sdpops_mod.c:1398]:
> sdp_remove_transport(): removing transport stream: RTP/AVP 5(13) DEBUG:
> INVITE <null> 1.2.3.4:5080 59bb066c-b53d-123f-47b3-1228f25c4047 textops
> [textops.c:2524]: ki_set_body(): new body: [v=0
> o=FreeSWITCH 1776432039 1776432040 IN IP4 1.2.3.4
> s=FreeSWITCH
> c=IN IP4 1.2.3.4
> t=0 0
> m=audio 25032 RTP/SAVP 0 8 101 13
> a=rtpmap:0 PCMU/8000
> a=rtpmap:8 PCMA/8000
> a=rtpmap:101 telephone-event/8000
> a=fmtp:101 0-15
> a=rtpmap:13 CN/8000
> a=crypto:1 AEAD_AES_256_GCM_8
> inline:SJqvkk2FLvI0tOHPkn7Ac8TkrADNB7buSM6h9ZTBZHHh1OV9uOkGV1DF1DU=
> a=crypto:2 AEAD_AES_256_GCM
> inline:jnzCFpgWPjCIAz13r3vCfqbGzxE1x30DJl/0xOVWWS1m34Ka+dD1c45GQX4=
> a=crypto:3 AEAD_AES_128_GCM_8
> inline:B4mysNibq+BH01ASVvceC7g69HmZUHrYtMVmDA==
> a=crypto:4 AEAD_AES_128_GCM inline:NLVvi1aEW+oWM+AQtV/5hKgMR274BscLBZAJRw==
> a=crypto:5 AES_256_CM_HMAC_SHA1_80
> inline:eE3dGn207RnrLSeeTvSP05vUnQax7jATdiizGrVS9mxJQo/pcvvMlhoJdSYT+w==
> a=crypto:6 AES_192_CM_HMAC_SHA1_80
> inline:VDveo9syEdOzxaIn9dpcMfG5ygdOv68yCpAnYwA8f0YlY51lElk=
> a=crypto:7 AES_CM_128_HMAC_SHA1_80
> inline:8025UxyTFme6casTeasbrPYUt/ta2yoZGlQFvags
> a=crypto:8 AES_256_CM_HMAC_SHA1_32
> inline:Ux9cBuGGe1Ft8knU7ZeWqnrOETHIqmVGjOTdi78GesXti6wO1ud0gvneW2JT+Q==
> a=crypto:9 AES_192_CM_HMAC_SHA1_32
> inline:kxmHW+oXsu0NuCOwW3uXRmlMAgT1+2GUZjK2ExPC8sD2Xckonms=
> a=crypto:10 AES_CM_128_HMAC_SHA1_32
> inline:MigohPAYbhU2QbJCRN6UUXcKIRAdhFur6EMDAziM
> a=crypto:11 AES_CM_128_NULL_AUTH
> inline:R9Aw9RUizWe8r07U8oV02fU+nQ4FkGmkhGflcoPY
> a=ptime:20
> m=audio 25032 RTP/AVP 0 8 101 13
> a=rtpmap:0 PCMU/8000
> a=rtpmap:8 PCMA/8000
> a=rtpmap:101 telephone-event/8000
> a=fmtp:101 0-15
> a=rtpmap:13 CN/8000
> a=ptime:20
> m=video 23724 RTP/SAVP 102
> b=AS:1024
> a=rtpmap:102 VP8/90000
> a=rtcp-fb:102 ccm fir
> a=rtcp-fb:102 ccm tmmbr
> a=rtcp-fb:102 nack
> a=rtcp-fb:102 nack pli
> a=crypto:1 AEAD_AES_256_GCM_8
> inline:EzIhXMiY/IU6pwGdiwIGs43YlIoBYrNyiK8XR1lc3auF3qf2GNCIrADZh8k=
> a=crypto:2 AEAD_AES_256_GCM
> inline:rSsEBQWi3qlC6nOcYD+xoz8Ux2dlPZDFf2zUOKR6XREkwvbExgQp1RCOjsQ=
> a=crypto:3 AEAD_AES_128_GCM_8
> inline:nwMmmSlFJjhgrqCujnsXV2nFsCBpmkeZ9y5FMA==
> a=crypto:4 AEAD_AES_128_GCM inline:bAWJtV65VMLHXVvfHwbgwBEYa5Fqi0t9DCB2zg==
> a=crypto:5 AES_256_CM_HMAC_SHA1_80
> inline:5m+7Gpqd1AIK8gEAMwti3yrS/cf5ig75Z9OSAAnjT6X8fDG9rBnYVZu0n9pyWg==
> a=crypto:6 AES_192_CM_HMAC_SHA1_80
> inline:zbzJ7sGdUdytETroy6Txg4YU/qBjl1/JKR7VadHx8y61tfTfEaA=
> a=crypto:7 AES_CM_128_HMAC_SHA1_80
> inline:5UiBkGVL9s/CjGIb3SPODZkTwJcfCipkiGZH4KI6
> a=crypto:8 AES_256_CM_HMAC_SHA1_32
> inline:KzBizz3SfxkK8n3MRvA70hCT9X95imVZldDAWzeHEjobSzzEGbAyc7YCZFYE1g==
> a=crypto:9 AES_192_CM_HMAC_SHA1_32
> inline:hwSaAGg6n6loiNLIqg30ZAVaor5pm/ds8Llf2ti95pYR2kGPG3Y=
> a=crypto:10 AES_CM_128_HMAC_SHA1_32
> inline:3/cf0KoXXso4L3+vpL95iBe3Nnu+QGdZxIDC1ulq
> a=crypto:11 AES_CM_128_NULL_AUTH
> inline:61izsKf/RCgzBtsNAAiTe+3w1sW/8GP6oET7cWcK
> m=video 23724 RTP/AVP 102
> b=AS:1024
> a=rtpmap:102 VP8/90000
> a=rtcp-fb:102 ccm fir
> a=rtcp-fb:102 ccm tmmbr
> a=rtcp-fb:102 nack
> a=rtcp-fb:102 nack pli
> ]
> ```
> Any help is greatly appreciated, thanks!
>
> Regards,
>
> David Villasmil
> email: [email protected]
>
>
> __________________________________________________________
> Kamailio - Users Mailing List - Non Commercial Discussions -- [email protected]
> To unsubscribe send an email to [email protected]
> Important: keep the mailing list in the recipients, do not reply only to the sender!
>
> __________________________________________________________
> Kamailio - Users Mailing List - Non Commercial Discussions --
> [email protected]
> To unsubscribe send an email to [email protected]
> Important: keep the mailing list in the recipients, do not reply only to
> the sender!
>
__________________________________________________________
Kamailio - Users Mailing List - Non Commercial Discussions -- [email protected]
To unsubscribe send an email to [email protected]
Important: keep the mailing list in the recipients, do not reply only to the sender!