Hey all
Not been around here for a while, but I've been investigating a recent problem with our FusionPBX servers where callers are reporting one way audio (Outbound call to third parties means no inbound audio, third party can hear caller fine) and it appears to be related to Broadworks servers that I assume are recording calls, the reason why I think that is because we get a 'Reason: broadworks;no-recon-on-answer' on the 200 OK from the upstream carrier on successful invites.
What's baffling to me is that these have been in place for a long time with zero issues, talking to the same SBCS, talking to the same upstream carriers; so I can only assume a tier 1 carrier in the UK is now allowing this, or maybe it was always allowed and Broadworks now does this behaviour. We can avoid this by routing it over the old BT network as I assume the SS7 just strips this out, but that's due to be decommissioned soon.
Just after the 180 Ringing, we get the 200 OK:
Note the a:inactive and the Reason header. Then after an ACK, we get a subsequent re-INVITE changing the SDP to sendrecv:
The handsets don't actually see this going on, as FreeSWITCH is dealing with this... but I end up with one way audio as if FreeSWITCH has forgotten to start sending the audio to the handset. What's strange is that you can hear the two way audio in the recording, so the carrier is sending it.
I've tried inbound-late-negotiation but that just causes more problems as we record some calls, make use of early media, etc, so we end up with all calls failing. I saw a reference to sip_renegotiate_codec_on_reinvite but in true FreeSWITCH fashion, it's in the docs but not in the code anymore (lol). I've also tried using sip_unhold_nosdp but that appears to change nothing. We have also tried an SBC manipulation that replaces the a=inactive with a=sendrecv a=recvonly , but it appears to change nothing, so I think it's more to do with the reinvite process itself, than the SDP.
There's a sanitised log file of the call setup
Anyone else seen anything similar or have some bright ideas?
Not been around here for a while, but I've been investigating a recent problem with our FusionPBX servers where callers are reporting one way audio (Outbound call to third parties means no inbound audio, third party can hear caller fine) and it appears to be related to Broadworks servers that I assume are recording calls, the reason why I think that is because we get a 'Reason: broadworks;no-recon-on-answer' on the 200 OK from the upstream carrier on successful invites.
What's baffling to me is that these have been in place for a long time with zero issues, talking to the same SBCS, talking to the same upstream carriers; so I can only assume a tier 1 carrier in the UK is now allowing this, or maybe it was always allowed and Broadworks now does this behaviour. We can avoid this by routing it over the old BT network as I assume the SS7 just strips this out, but that's due to be decommissioned soon.
Just after the 180 Ringing, we get the 200 OK:
Code:
SIP/2.0 200 OK
Via: SIP/2.0/UDP Y.Y.Y.131:5080;received=Y.Y.Y.131;branch=z9hG4bKmNBg9DvX4512B;rport=5080
From: <sip:XXX@XXXX.net>;tag=0900g11ZeBgjB
To: <sip:YYY@YYY.net>;tag=3972015649-722042918
Call-ID: adf28582-3b17-123f-26aa-6c92cf0c5e86
CSeq: 106959633 INVITE
Allow: MESSAGE,UPDATE,PRACK,INFO,OPTIONS,BYE,INVITE,ACK,CANCEL
Contact: <sip:XXX@X.X.X.196:5060;transport=udp>
Content-Type: application/sdp
Accept: application/sdp
Reason: broadworks;no-recon-on-answer
Content-Length: 262
v=0
o=BSYSW3B 96834701287024 96834701287024 IN IP4 X.X.X.196
s=sip call
c=IN IP4 X.X.X.196
t=0 0
m=audio 49174 RTP/AVP 8 101
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=silenceSupp:off - - - -
a=inactive
a=ptime:20Note the a:inactive and the Reason header. Then after an ACK, we get a subsequent re-INVITE changing the SDP to sendrecv:
Code:
INVITE sip:gw+e66098f6-7e5d-432d-a16b-95e7a0b560c7@X.X.X.131:5080;transport=udp;gw=e66098f6-7e5d-432d-a16b-95e7a0b560c7 SIP/2.0
Via: SIP/2.0/UDP X.X.X.196:5060;branch=z9hG4bKvne1pm00001rvm9qka70sb0000010.1
Max-Forwards: 15
Min-SE: 600
Supported: 100rel,timer
To: "Customer" <sip:XXXX@XXXX.net>;tag=0900g11ZeBgjB
From: <sip:YYYY@X.X.X.196>;tag=3972015649-722042918
Call-ID: adf28582-3b17-123f-26aa-6c92cf0c5e86
CSeq: 2 INVITE
Allow: MESSAGE,UPDATE,PRACK,INFO,OPTIONS,BYE,INVITE,ACK,CANCEL
Contact: <sip:YYYY@X.X.X.196:5060;transport=udp>
Content-Type: application/sdp
Accept: application/sdp
Content-Length: 259
v=0
o=BSYSW3B 96834701287024 96834701287025 IN IP4 X.X.X.196
s=sip call
c=IN IP4 X.X.X.196
t=0 0
m=audio 49174 RTP/AVP 8 0 101
a=rtpmap:8 PCMA/8000
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=sendrecv
a=ptime:20The handsets don't actually see this going on, as FreeSWITCH is dealing with this... but I end up with one way audio as if FreeSWITCH has forgotten to start sending the audio to the handset. What's strange is that you can hear the two way audio in the recording, so the carrier is sending it.
I've tried inbound-late-negotiation but that just causes more problems as we record some calls, make use of early media, etc, so we end up with all calls failing. I saw a reference to sip_renegotiate_codec_on_reinvite but in true FreeSWITCH fashion, it's in the docs but not in the code anymore (lol). I've also tried using sip_unhold_nosdp but that appears to change nothing. We have also tried an SBC manipulation that replaces the a=inactive with a=
There's a sanitised log file of the call setup
Anyone else seen anything similar or have some bright ideas?
Last edited: