Outbound call problem with audio

DigitalDaz

Administrator
Staff member
Sep 29, 2016
3,173
644
113
I have had a couple of issues with outbound calling....

On the occasional call we are having a problem with no audio. I have tracked the issue and discovered the following.

A normal INVITE goes out from freeswitch to the trunk the call is answered at the remote end and we receive a 200OK with a=inactive in the SDP, this gets relayed by freeswitch to the handset and so we now have a call in progress without audio.

Immediately after this, we receive a re-INVITE from the trunk with a=sendrecv in the SDP which should then restore the audio. The problem is, this reinvite is never forwarded to the handset so it is still stuck without audio.

Has anyone ever come across behaviour and if so, how did you resolve it?

TIA
Daz
 
Yeh, Broadworks PBXs seem to immediately start with sdp=inactive and then immediately switch to sendrecv. FreeSWITCH doesn't like it, so the SDP never starts flowing. We did it in a rather janky manner and replaced the SDP inactive message with just sendrecv on our SBCs. I just really couldn't be bothered to paw through the FreeSWITCH code, submit a pull request, wait for it to hit master, etc.

That pull request looks exactly what our problem was.
 
Yeh, Broadworks PBXs seem to immediately start with sdp=inactive and then immediately switch to sendrecv. FreeSWITCH doesn't like it, so the SDP never starts flowing. We did it in a rather janky manner and replaced the SDP inactive message with just sendrecv on our SBCs. I just really couldn't be bothered to paw through the FreeSWITCH code, submit a pull request, wait for it to hit master, etc.

That pull request looks exactly what our problem was.

Did you fix it Kamailio side, I have a kamailio billing server sat in front of them too, it would be nice to fix all my PBXs with it.
 
Nah, ACME Packet gateways, or wherever Oracle calls them now. I'm surey associate, Claude would know how to do it Kamailio side though.

We didn't notice any side effects, most phone systems will send hold music instead of outright flipping to inactive, though you might need to keep an eye on whatever the RTP timeout is in your profiles if you do notice calls dropping when people are placed on hold.
 
Nah, ACME Packet gateways, or wherever Oracle calls them now. I'm surey associate, Claude would know how to do it Kamailio side though.

We didn't notice any side effects, most phone systems will send hold music instead of outright flipping to inactive, though you might need to keep an eye on whatever the RTP timeout is in your profiles if you do notice calls dropping when people are placed on hold.

Well, what I would be thinking here is that I would only ever swap the a=inactive on the 200OK from the carrier, the carrier should never be doing holds anyway so it should be safe.
 
@hfoster Also, what carrier are you seeing this with? I'm seeing it with Simwood. Another thing this makes me think is that we are getting a 180 Ringing rather than a 183. This could potentially lead to a ringing followed by a busy etc where we are not actually getting call progress.
 
All three of our upstream carriers (for clarity, we are an ITSP, so this is carriers like BT IP Exchange, not just SIP Trunk providers); it's limited to Broadworks PBXs on the far end though from the user agents, basically exactly as that pull request states. If I had to guess, this is a change that Broadworks made in approximately November 2025, as that is when we first received reports. One of those things that is technically fine from the SIP/SDP spec, but nobody ever did it, so FreeSWITCH never caught the bug.
 
  • Like
Reactions: DigitalDaz