Bridge Early Media - Event Socket

Hi All (trying in here as well as posted in slack #freeswitch about a 1 week ago.)

I believe this is a bug rather than something being done incorrectly then please let me know so i can open a github

Hoping for a bit of guidance. We have a scenario where Early media does not get sent out of FreeSWITCH to the Originating Party (SIP Device)

FreeSWITCH Versions tested (tried 1.10.6, 1.10.7 and 1.10.9)

SIP Device calls PSTN with 183 SDP plays Early Media’ and then Call Drop, SIP Device sits in Silence.

We have a build using FreeSWITCH and ESL…

As a test, we bypassed the ESL and and everything worked as expected, pointing to an issue with the ESL and the Bridge of Early Media.

Having looked at the PCAPs taken from FreeSWITCH, the RTP is definitely received from PSTN, The SIP Device has had a 183 SDP which from a signaling perspective looks good but what we see is FreeSWITCH never send the audio onto then SIP Device.

We have done alot of testing but I wont detail it all here. We are currently using originate &intercept ignore_early_media=false all the messaging is good but it is like the FreeSWITCH wont send the Audio to the SIP Device (Originating Party) despite it having the RTP Stream.

Reviewing and Comparing DEBUG traces the difference seems to be a lack of sofia_on_exchange_media after everything is setup.

2023-02-23 13:06:21.261722 99.70% [DEBUG] switch_core_state_machine.c:650 (sofia/external/**************) State EXCHANGE_MEDIA
freeswitch@ip-172-20-57-99> [DEBUG] esl.c:1303 esl_recv_event() RECV HEADER [Content-Type] = [log/data]
[DEBUG] esl.c:1303 esl_recv_event() RECV HEADER [Content-Length] = [79]
[DEBUG] esl.c:1303 esl_recv_event() RECV HEADER [Log-Level] = [7]
[DEBUG] esl.c:1303 esl_recv_event() RECV HEADER [Text-Channel] = [3]
[DEBUG] esl.c:1303 esl_recv_event() RECV HEADER [Log-File] = [mod_sofia.c]
[DEBUG] esl.c:1303 esl_recv_event() RECV HEADER [Log-Func] = [sofia_on_exchange_media]
[DEBUG] esl.c:1303 esl_recv_event() RECV HEADER [Log-Line] = [671]
[DEBUG] esl.c:1303 esl_recv_event() RECV HEADER [User-Data] = [3befd875-0c43-4d06-b98a-a590f0c2ff83]
[DEBUG] esl.c:1467 esl_recv_event() RECV MESSAGE
Content-Type: log/data
Content-Length: 79
Log-Level: 7
Text-Channel: 3
Log-File: mod_sofia.c
Log-Func: sofia_on_exchange_media
Log-Line: 671
User-Data: 3befd875-0c43-4d06-b98a-a590f0c2ff83
Content-Length: 79

Can you provide a complete sip trace with ‘sofia loglevel all 9’ ?


1 Like

Yes leave it with me I will get one done today or tomorrow (UK)

Thank you! I’ll be on the look out for it.


Hi Brian

I have everything you have asked including some notes and call flow details. The whole lot breaches the character limit on here so going to have to post it in sections… Apologies

Part 1 - Details

FreeSWITCH Version 1.10.9-release-21-a615e85afc~64bit (-release-21-a615e85afc 64bit)

Tested this on 1.10.6 and 1.10.7 as well = SIP Device Location IP (Redacted) = SIP Device Registrar IP (Redacted) = SIP Trunk SBC (Redacted) = SIP Provider (Redacted) = FreeSWITCH Public IP (Redacted) = RTPengine Public IP (Redacted)
01444332211 = Number Dialed for Early Media (Redacted)
01143211234 = Calling Party reciever of Early Media (Redacted)

Call Flow

Signaling Flow
SIP Device > SIP Device Registrar > FreeSWITCH > SIP Trunk SBC > PSTN

Media Flow
PSTN > RTPengine > FreeSWITCH > RTPengine > SIP Device

PCAP Trace shows
PSTN > RTPengine > FreeSWITCH xxxxxxx
As this is a number that plays an early media announcement then clears down the media only flows 1 ways and what we see is it comes all the way to FreeSWITCH from PSTN announcement but then never leaves FreeSWITCH towards RTPengine and SIP Device when call is via ESL.

Using the standard application=“bridge” it works fine, this issue is only when using ESL

<action application="bridge" data="{sip_cid_type=pid,origination_caller_id_number=**********}sofia/gateway/labsbca/$1"/>

OK i will re post… Apologies
I will also try and fix PCMA

This is missing the ‘sofia global siptrace on’, Try setting only PCMA, it feels like a codec interop issue.

1 Like

Is there an easier way i can send this trace to you rather than splitting all of it up to fit in this channel parameters… Its a bit of a pain. rather just send 1 file?

I have pinned SIP Device to PCMA, FreeSWITCH to PCMA, RTPengine to PCMA and the Trunk only supports PCMA but it has not made any difference. I have captured a trace with the below, please advise how to share a file this large or if you want me to post it in small sections.

freeswitch@ip-172-20-57-99> sofia loglevel all 9
Sofia log level for component [all] has been set to [9]
freeswitch@ip-172-20-57-99> sofia global siptrace on
+OK Global siptrace on


Should be able to attach here. What is the file size?

I cant upload anything other than images and when trying to upload the trace as text I get error

“An error occurred: Body is limited to 32000 characters; you entered 70743.”

Anyone??? This is proving to be a bit of a painful point for us as it’s an ‘Ofcom’ requirement

email it to

1 Like

Sent! Many thanks, Look forward to hearing your feedback (Sincerely hope it’s not something silly on my side)

I’ve responded, we need to do a deep dive.


No problem, anything else you need let me know. I noticed it was down as a fix on a previous release notes but couldn’t find any details to investigate myself.

just come across this and wanted to update for anyone reading it

With a great deal of effort and messing around with the flow, CHANNEL_EVENTS pre_answer, uuid_bridge originate &park() vs originate &intercept() managed to get this working…

The key steps where

bgapi originate &park (without bgapi we observed blocking the CHANNEL_EVENTS needed)

On receipt of CHANNEL_PROGRESS_MEDIA trigger pre_answer (aleg) then straight away uuid_bridge (aleg & bleg)

Also ontop of this in some cases on receipt of a 200OK if the far end answered (i.e the early media is PSTN Ringback) handle this messaging and ANSWER as well ass CHANNEL_PROGRESS_MEDIA