SOLVED Oneway/No Audio

[DavidDec]

Sooo we have an issue when calling certain numbers where we can hear a recorded message initially then the line goes completely silent. (no ring tone etc).

We have raised this already with our supplier who initially said they identified an issue and made some changes which actually made the call quality worse.
They've now come back and said they can see in one of the packets we turned the call to one way audio and provided the below PCAP, I've sent it back to them for further investigation but doesn't hurt to get a second opinion as I can't think of any configuration that would cause no audio to specific numbers, we have a multi tenant set up couple dozen domains, care homes etc so we see thousands of calls going through a day and only had 2 numbers reported to be doing this in the last couple of days which my gut tells me points to the b party's but we did recently change a couple of outbound routes for one of the domains (not the client that reported the issue).

Spoiler: Edited PCAP

Ôò¡ @ Àd08 i i àí@·(Šg—Ì E WL 8o¼¥p¬X×<MÄÄCPINVITE sip:Bnumber@B party SIP/2.0
Via: SIP/2.0/UDP AParty;rport;branch=z9hG4bKr6mg3Fv1FQUQS
Max-Forwards: 69
From: "CallerID" <sip:AParty@AParty>;tag=8F0j27B43jeUB
To: <sip:Bnumber@B party>
Call-ID: 7a391e66-3e9b-123c-a192-020000ae5c3b
CSeq: 64931616 INVITE
Contact: <sip:gw+de1e44b1-e1a1-43d3-a6d3-6540e8ae8948@AParty:5060;transport=udp;gw=de1e44b1-e1a1-43d3-a6d3-6540e8ae8948>
User-Agent: FreeSWITCH
Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, INFO, UPDATE, REGISTER, REFER, NOTIFY, PUBLISH, SUBSCRIBE
Supported: timer, path, replaces
Allow-Events: talk, hold, conference, presence, as-feature-event, dialog, line-seize, call-info, sla, include-session-description, presence.winfo, message-summary, refer
Privacy: none
Content-Type: application/sdp
Content-Disposition: session
Content-Length: 298
X-accountcode: domain.voip.domain.co.uk
X-FS-Support: update_display,send_info
P-Asserted-Identity: "CallerID" <sip:AParty@AParty>

v=0
o=FreeSWITCH 1678949254 1678949255 IN IP4 AParty
s=FreeSWITCH
c=IN IP4 AParty
t=0 0
m=audio 21562 RTP/AVP 0 8 9 101 13
a=rtpmap:0 PCMU/8000
a=rtpmap:8 PCMA/8000
a=rtpmap:9 G722/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=rtpmap:13 CN/8000
a=ptime:20
Ád# ^ ^ ^ àí@· EhLÏ@ @§©X×<M¼¥p¬ÄÄ8®žSIP/2.0 100 Trying
Via: SIP/2.0/UDP AParty;rport=5060;received=AParty;branch=z9hG4bKr6mg3Fv1FQUQS
From: <sip:AParty@AParty>;tag=8F0j27B43jeUB
To: <sip:Bnumber@B party>
Call-ID: 7a391e66-3e9b-123c-a192-020000ae5c3b
CSeq: 64931616 INVITE
Content-Length: 0

Ád¸( ^ àí@· EhÏ@ @¥ðX×<M¼¥p¬ÄÄðoSIP/2.0 200 OK
Session-Expires: 3600;refresher=uas
Require: timer
Via: SIP/2.0/UDP AParty;rport=5060;received=AParty;branch=z9hG4bKr6mg3Fv1FQUQS
To: <sip:Bnumber@B party>;tag=3887959617-1185333938
From: <sip:AParty@AParty>;tag=8F0j27B43jeUB
Call-ID: 7a391e66-3e9b-123c-a192-020000ae5c3b
CSeq: 64931616 INVITE
Allow: UPDATE,PRACK,INFO,NOTIFY,OPTIONS,BYE,INVITE,ACK,CANCEL
Contact: <sip:Bnumber@B party:5060>
Content-Type: application/sdp
Accept: application/sdp
Content-Length: 198

v=0
o=MSX188 56611580 1 IN IP4 B party
s=sip call
c=IN IP4 0.0.0.0
t=0 0
m=audio 25514 RTP/AVP 8 101
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=ptime:20
Ád2V àí@·(Šg—Ì E L' 8rL¼¥p¬X×<MÄÄð=ƒACK sip:Bnumber@B party:5060 SIP/2.0
Via: SIP/2.0/UDP AParty;rport;branch=z9hG4bKSFe94aD5c0HaN
Max-Forwards: 70
From: "CallerID" <sip:AParty@AParty>;tag=8F0j27B43jeUB
To: <sip:Bnumber@B party>;tag=3887959617-1185333938
Call-ID: 7a391e66-3e9b-123c-a192-020000ae5c3b
CSeq: 64931616 ACK
Contact: <sip:gw+de1e44b1-e1a1-43d3-a6d3-6540e8ae8948@AParty:5060;transport=udp;gw=de1e44b1-e1a1-43d3-a6d3-6540e8ae8948>
Content-Length: 0

Âdö§ µ µ ^ àí@· Eh£Ï@ @¦PX×<M¼¥p¬ÄÄÓÈINVITE sip:gw+de1e44b1-e1a1-43d3-a6d3-6540e8ae8948@AParty:5060;gw=de1e44b1-e1a1-43d3-a6d3-6540e8ae8948;user=phone SIP/2.0
Max-Forwards: 68
Session-Expires: 3600;refresher=uac
Min-SE: 600
Supported: 100rel,timer
To: <sip:AParty@AParty>;tag=8F0j27B43jeUB
From: <sip:Bnumber@B party>;tag=3887959617-1185333938
Call-ID: 7a391e66-3e9b-123c-a192-020000ae5c3b
CSeq: 2 INVITE
Allow: UPDATE,PRACK,INFO,NOTIFY,OPTIONS,BYE,INVITE,ACK,CANCEL
Via: SIP/2.0/UDP B party:5060;branch=z9hG4bKa66805bfcfef9cbbde9ec1d79c1fd7e5
Contact: <sip:Bnumber@B party:5060>
Accept: application/sdp
Content-Length: 0

ÂdÐ
z z àí@·(Šg—Ì E hLk 8r¤¼¥p¬X×<MÄÄTù¸SIP/2.0 100 Trying
Via: SIP/2.0/UDP B party:5060;branch=z9hG4bKa66805bfcfef9cbbde9ec1d79c1fd7e5
From: <sip:Bnumber@B party>;tag=3887959617-1185333938
To: <sip:AParty@AParty>;tag=8F0j27B43jeUB
Call-ID: 7a391e66-3e9b-123c-a192-020000ae5c3b
CSeq: 2 INVITE
User-Agent: FreeSWITCH
Content-Length: 0

ÂdG àí@·(Šg—Ì E òLl 8p¼¥p¬X×<MÄÄÞlÞSIP/2.0 200 OK
Via: SIP/2.0/UDP B party:5060;branch=z9hG4bKa66805bfcfef9cbbde9ec1d79c1fd7e5
From: <sip:Bnumber@B party>;tag=3887959617-1185333938
To: <sip:AParty@AParty>;tag=8F0j27B43jeUB
Call-ID: 7a391e66-3e9b-123c-a192-020000ae5c3b
CSeq: 2 INVITE
Contact: <sip:gw+de1e44b1-e1a1-43d3-a6d3-6540e8ae8948@AParty:5060;transport=udp;gw=de1e44b1-e1a1-43d3-a6d3-6540e8ae8948>
User-Agent: FreeSWITCH
Accept: application/sdp
Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, INFO, UPDATE, REGISTER, REFER, NOTIFY, PUBLISH, SUBSCRIBE
Require: timer
Supported: timer, path, replaces
Session-Expires: 3600;refresher=uac
Content-Type: application/sdp
Content-Disposition: session
Content-Length: 238

v=0
o=FreeSWITCH 1678949254 1678949256 IN IP4 AParty
s=FreeSWITCH
c=IN IP4 AParty
t=0 0
m=audio 21562 RTP/AVP 8 101
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=sendonly
a=ptime:20
Âd] ^ àí@· EhúÏ@ @¥øX×<M¼¥p¬ÄÄæû†ACK sip:gw+de1e44b1-e1a1-43d3-a6d3-6540e8ae8948@AParty:5060;gw=de1e44b1-e1a1-43d3-a6d3-6540e8ae8948;user=phone SIP/2.0
Max-Forwards: 68
To: <sip:AParty@AParty>;tag=8F0j27B43jeUB
From: <sip:Bnumber@B party>;tag=3887959617-1185333938
Call-ID: 7a391e66-3e9b-123c-a192-020000ae5c3b
CSeq: 2 ACK
Via: SIP/2.0/UDP B party:5060;branch=z9hG4bK951d0fe40e2ad244a778ef59b0dde383
Contact: <sip:Bnumber@B party:5060>
Content-Type: application/sdp
Accept: application/sdp
Content-Length: 198

v=0
o=MSX188 56611580 2 IN IP4 B party
s=sip call
c=IN IP4 0.0.0.0
t=0 0
m=audio 25514 RTP/AVP 8 101
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=ptime:20
Âd.á µ µ ^ àí@· Eh£Ï@ @¦NX×<M¼¥p¬ÄĹINVITE sip:gw+de1e44b1-e1a1-43d3-a6d3-6540e8ae8948@AParty:5060;gw=de1e44b1-e1a1-43d3-a6d3-6540e8ae8948;user=phone SIP/2.0
Max-Forwards: 68
Session-Expires: 3600;refresher=uac
Min-SE: 600
Supported: 100rel,timer
To: <sip:AParty@AParty>;tag=8F0j27B43jeUB
From: <sip:Bnumber@B party>;tag=3887959617-1185333938
Call-ID: 7a391e66-3e9b-123c-a192-020000ae5c3b
CSeq: 3 INVITE
Allow: UPDATE,PRACK,INFO,NOTIFY,OPTIONS,BYE,INVITE,ACK,CANCEL
Via: SIP/2.0/UDP B party:5060;branch=z9hG4bK4357a527e92f821ce1da2554d2834276
Contact: <sip:Bnumber@B party:5060>
Accept: application/sdp
Content-Length: 0

Âd; z z àí@·(Šg—Ì E hL… 8rŠ¼¥p¬X×<MÄÄT)©SIP/2.0 100 Trying
Via: SIP/2.0/UDP B party:5060;branch=z9hG4bK4357a527e92f821ce1da2554d2834276
From: <sip:Bnumber@B party>;tag=3887959617-1185333938
To: <sip:AParty@AParty>;tag=8F0j27B43jeUB
Call-ID: 7a391e66-3e9b-123c-a192-020000ae5c3b
CSeq: 3 INVITE
User-Agent: FreeSWITCH
Content-Length: 0

ÂdT< àí@·(Šg—Ì E òL† 8oÿ¼¥p¬X×<MÄÄÞœÎSIP/2.0 200 OK
Via: SIP/2.0/UDP B party:5060;branch=z9hG4bK4357a527e92f821ce1da2554d2834276
From: <sip:Bnumber@B party>;tag=3887959617-1185333938
To: <sip:AParty@AParty>;tag=8F0j27B43jeUB
Call-ID: 7a391e66-3e9b-123c-a192-020000ae5c3b
CSeq: 3 INVITE
Contact: <sip:gw+de1e44b1-e1a1-43d3-a6d3-6540e8ae8948@AParty:5060;transport=udp;gw=de1e44b1-e1a1-43d3-a6d3-6540e8ae8948>
User-Agent: FreeSWITCH
Accept: application/sdp
Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, INFO, UPDATE, REGISTER, REFER, NOTIFY, PUBLISH, SUBSCRIBE
Require: timer
Supported: timer, path, replaces
Session-Expires: 3600;refresher=uac
Content-Type: application/sdp
Content-Disposition: session
Content-Length: 238

v=0
o=FreeSWITCH 1678949254 1678949256 IN IP4 AParty
s=FreeSWITCH
c=IN IP4 AParty
t=0 0
m=audio 21562 RTP/AVP 8 101
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-16
a=sendonly
a=ptime:20
Âd-Ì ^ àí@· EhÏ@ @¥åX×<M¼¥p¬ÄÄ÷n¦ACK sip:gw+de1e44b1-e1a1-43d3-a6d3-6540e8ae8948@AParty:5060;gw=de1e44b1-e1a1-43d3-a6d3-6540e8ae8948;user=phone SIP/2.0
Max-Forwards: 68
To: <sip:AParty@AParty>;tag=8F0j27B43jeUB
From: <sip:Bnumber@B party>;tag=3887959617-1185333938
Call-ID: 7a391e66-3e9b-123c-a192-020000ae5c3b
CSeq: 3 ACK
Via: SIP/2.0/UDP B party:5060;branch=z9hG4bKdb09c05ce5497e8d16c777d235f5bc5d
Contact: <sip:Bnumber@B party:5060>
Content-Type: application/sdp
Accept: application/sdp
Content-Length: 215

v=0
o=MSX188 56611580 3 IN IP4 B party
s=sip call
c=IN IP4 88.215.60.78
t=0 0
m=audio 25514 RTP/AVP 8 101
a=recvonly
a=rtpmap:8 PCMA/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=ptime:20
ÍdÌÎ j j àí@·(Šg—Ì E XT' 8iø¼¥p¬X×<MÄÄDÜáBYE sip:Bnumber@B party:5060 SIP/2.0
Via: SIP/2.0/UDP AParty;rport;branch=z9hG4bK4p8yUUjFUpaHF
Max-Forwards: 70
From: "CallerID" <sip:AParty@AParty>;tag=8F0j27B43jeUB
To: <sip:Bnumber@B party>;tag=3887959617-1185333938
Call-ID: 7a391e66-3e9b-123c-a192-020000ae5c3b
CSeq: 64931617 BYE
User-Agent: FreeSWITCH
Allow: INVITE, ACK, BYE, CANCEL, OPTIONS, MESSAGE, INFO, UPDATE, REGISTER, REFER, NOTIFY, PUBLISH, SUBSCRIBE
Supported: timer, path, replaces
Reason: Q.850;cause=16;text="NORMAL_CLEARING"
Content-Length: 0

Íd
ý ° ° ^ àí@· EhžÏ @ @§PX×<M¼¥p¬ÄÄŠéÝSIP/2.0 200 OK
Via: SIP/2.0/UDP AParty;rport=5060;received=AParty;branch=z9hG4bK4p8yUUjFUpaHF
To: <sip:Bnumber@B party>;tag=3887959617-1185333938
From: <sip:AParty@AParty>;tag=8F0j27B43jeUB
Call-ID: 7a391e66-3e9b-123c-a192-020000ae5c3b
CSeq: 64931617 BYE
Allow: UPDATE,PRACK,INFO,NOTIFY,OPTIONS,BYE,INVITE,ACK,CANCEL
Content-Length: 0

 

[DavidDec]

Supplier has provided the below showing the media traffic. I still cant think of a reason why out of over 5000 calls a day only these 3 numbers that we're aware of would have 1 way audio.

 

[Adrian Fretwell]

David,
I have seen this kind of thing before, and in my case it was third party endpoint specific.

I found my problem occurred when the 3rd party sends an SDP with the media attribute 'a=sendonly' on an existing session then follows with a RE-INVITE without an SDP body. The 200 OK provided by FreeSWITCH reflects the current hold status, not the status now required by the third party as defined in the ACK with SDP which at this point we have not yet received!

Relevant RFCs:
RFC 3264 section 8 supports what FreeSWITCH does as it states that the offer MAY be identical to the last SDP:

RFC 3264 section 8 - Modifying the Session
At any point during the session, either participant MAY issue a new
offer to modify characteristics of the session. It is fundamental to
the operation of the offer/answer model that the exact same
offer/answer procedure defined above is used for modifying parameters
of an existing session.

The offer MAY be identical to the last SDP provided to the other
party (which may have been provided in an offer or an answer), or it
MAY be different. We refer to the last SDP provided as the "previous
SDP". If the offer is the same, the answer MAY be the same as the
previous SDP from the answerer, or it MAY be different. If the
offered SDP is different from the previous SDP, some constraints are
placed on its construction, discussed below...

I believe there are some products out there which use the re-INVITE without SDP and ACK with SDP to take calls off hold. Currently, this method is not explicitly mentioned in RFC2543 and it is argued that it is illogical and inconsistent with how SDP is used with SIP today. Basically, if you want to modify anything to do with the media stream then send an updated SDP with the re-INVITE.

The work around for me was to add:

action export nolocal:sip_unhold_nosdp=true

in the outbound route just prior to the bridge statement.

Cheers,
Adrian.

 

[DavidDec]

Thanks for that Adrian, strangely all of our calls this morning began to be effected by the 1 way or no audio issue intermittently. We use Gamma Telecoms for the SBC and they swore they made no changes but after I escalated the ticket we noticed our Promax environment starting to lockup so we restarted the machine and then updated the schema and all calls including the effected initial problem numbers all worked as expected. Problem there is can't be sure if they resolved something or the restart/schema resolved.

One factor that did link the 3 effected numbers were they NHS systems using IVR's.

 

[Adrian Fretwell]

One factor that did link the 3 effected numbers were they NHS systems using IVR's.

That was the same with us!

When a call is placed from our FreeSWITCH to the NHS number, we hear an IVR: if we press 5 for reception the call gets hung up by the distant end.

When we press option 5 we receive a re-invite without an SDP body. For each INVITE FreeSWITCH responds with 200 with SDP and we get an ACK back with SDP. During the post choosing options stage the ACK SDP contains a=sendonly. All previous SDP have implied sendrecv on both sides. All is OK at this stage, but when the call is finally put through to the reception queue (according to RFC 6337 section 5.3 "the use of sendonly/recvonly is not limited to hold") we get an INVITE without SDP and FreeSWITCH responds with SDP including a=sendonly, to which the remote replies with a=sendrecv, and then hangs up.

 

[DavidDec]

When a call is placed from our FreeSWITCH to the NHS number, we hear an IVR: if we press 5 for reception the call gets hung up by the distant end.

Glad to know it wasn't just us then, we had that exact issue with the disconnect and Gamma told us we were requesting the termination, funnily enough the NHS numbers were managed by Gamma. We self resolved by switching the gateway to an internal profile until this 1 way audio reared it's head in the last week.