Workarounds to ASTERISK-25676 RTP Bug

Asterisk Asterisk SIP
1

Hi Group

I an running Asterisk 13.14 (also noticed in 13.15) and I believe that I am running into this bug.
When I make a call via SIP Trunk to another system that only supports G711 ulaw, there is one way audio.

sip.conf:
[general]
disallow=all
allow=alaw
allow=ulaw

200 OK on SIP Trunk from other system:
<— SIP read from UDP:y.y.y.y:5060 —>
SIP/2.0 200 OK
Via: SIP/2.0/UDP x.x.x.x:5060;branch=z9hG4bK2bbb3769
Contact: sip:0312345678@y.y.y.y:5060
To: sip:0312345678@sip.iboss.com.au:5060;tag=7d8105f0-co9125-INS005
From: sip:0212345678@sip.iboss.com.au;tag=as106a88d1
Call-ID: 7cdaba5b7910b9dd738eae66297c3048@sip.iboss.com.au
CSeq: 102 INVITE
Allow: INVITE,ACK,CANCEL,BYE,REFER,OPTIONS,NOTIFY,SUBSCRIBE,PRACK,INFO
Content-Type: application/sdp
User-Agent: ENSR3.0
Content-Length: 227

v=0
o=- 2105606208 2105606208 IN IP4 125.213.162.112
s=ENSResip
c=IN IP4 125.213.162.117
t=0 0
m=audio 46336 RTP/AVP 0 101
a=rtpmap:0 PCMU/8000
a=rtpmap:101 telephone-event/8000
a=fmtp:101 0-15
a=ptime:20
a=sendrecv

Asterisk Debug:
[Nov 16 16:05:53] DEBUG[28507][C-00000d84]: res_rtp_asterisk.c:4467 bridge_p2p_rtp_write: Unsupported payload type received

I understand that this bug is resolved in 13.17.0 but I have another bug not resolved yet for this customer so I cannot upgrade.

Are there any workarounds for this bug? Am I actually experiencing this bug?

Thanks
Mike

2

Replying to my post. I tested this out in the lab on 13.17.2 and can confirm that I am experiencing this bug.
So a workaround would be fantastic!

Thanks
Mike

3

So can I assume that there are no workarounds here?

Thanks
Mike

4

You haven’t provide the first half of the SDP exchange and you haven’t provided debug level 5 or higher, logging to see how Asterisk interpreted that exchange.

Also I do not see how https://issues.asterisk.org/jira/browse/ASTERISK-25678 relates to handling of RTP.

5

???
https://issues.asterisk.org/jira/browse/ASTERISK-25676

6

The obvious work round to a problem that only happens with native bridging is to frustrate native bridging. Adding a non-optimising local channel will definitely do this. I think the same would be true, if you simply enable a feature that requires inspection of the media, e…g a feature.conf feature that does nothing.

7

Better would be to back port the change to your version, and recompile: https://gerrit.asterisk.org/#/c/5620/1/channels/chan_sip.c

8

Thanks David. Yes your first option would certainly be easier for me. As I am already using a Local Channel I could add a /n
I have also been doing some testing in which the phone only advertises a single codec and this codec only is configured in sip.conf. It does appear to fix the problem but I need to do further testing.

Thanks
Mike