You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Making a call to a remote side that sends RTP in sessions in progress but when it answers there is no audio.
The problem is caused that it sends in the 200 OK SDP a different port number and crypto key, that SDP is not processed by FS.
I could reproduce the issue using sipp escenario with plain RTP and using the parameter:
NOTE: with plain RTP FS can ajust to the correct port or IP using the rtp_auto_adjust parameter, but with SRTP is not possible since the key is diferent from the SIP/183 SDP.
knowing that is not a rfc behaviour (it should send a re-invite first i think), in the code it looks that is supported, in sofia.c, line:8501
if (!switch_channel_test_flag(channel, CF_PROXY_MODE) && !switch_channel_test_flag(channel, CF_PROXY_MEDIA) &&
r_sdp && (!is_dup_sdp || sofia_test_flag(tech_pvt, TFLAG_NEW_SDP)) && switch_core_media_ready(tech_pvt->session, SWITCH_MEDIA_TYPE_AUDIO) && !sofia_test_flag(tech_pvt, TFLAG_NOSDP_REINVITE)) {
/* sdp changed since 18X w sdp, we're supposed to ignore it but we, of course, were pressured into supporting it */
uint8_t match = 0;
sofia_clear_flag(tech_pvt, TFLAG_NEW_SDP);
switch_channel_set_flag(tech_pvt->channel, CF_REINVITE);
From the results, it looks taht this only applies to aleg and not to the remote side (bleg), after answer i see:
2024-10-22 12:22:42.256892 97.97% [DEBUG] sofia.c:8519 Processing updated SDP
2024-10-22 12:22:42.256892 97.97% [DEBUG] switch_core_media.c:8640 Audio params are unchanged for sofia/main/1000@default.com:5060.
It shows info only for channel 1000@default.com and not for the 00310@192.168.10.1:6070, the one that had changed SDP in the 200 OK.
I'm using late negotiation, <param name="inbound-late-negotiation" value="true"/> i also tried without, but same result.
Making a call to a remote side that sends RTP in sessions in progress but when it answers there is no audio.
The problem is caused that it sends in the 200 OK SDP a different port number and crypto key, that SDP is not processed by FS.
I could reproduce the issue using sipp escenario with plain RTP and using the parameter:
NOTE: with plain RTP FS can ajust to the correct port or IP using the rtp_auto_adjust parameter, but with SRTP is not possible since the key is diferent from the SIP/183 SDP.
I found old debates about this issue:
https://forum.signalwire.community/t/freeswitch-ignores-sdp-in-200-ok-after-183/748
https://freeswitch-dev.freeswitch.narkive.com/LoQ0LunD/fs-doesn-t-update-rtp-port-when-sdp-changed-in-200ok-response-for-invite-message
knowing that is not a rfc behaviour (it should send a re-invite first i think), in the code it looks that is supported, in sofia.c, line:8501
From the results, it looks taht this only applies to aleg and not to the remote side (bleg), after answer i see:
It shows info only for channel 1000@default.com and not for the 00310@192.168.10.1:6070, the one that had changed SDP in the 200 OK.
I'm using late negotiation,
<param name="inbound-late-negotiation" value="true"/>
i also tried without, but same result.The dial string is:
Attach the sipp scenario to reproduce the issue.
uas.xml.txt
Full call log:
The text was updated successfully, but these errors were encountered: