Summary:ASTERISK-27795: chan_sip: one way / no audio with srtp
Reporter:Florian Kaiser (fmkaiser)Labels:pjsip
Date Opened:2018-04-08 05:36:50Date Closed:2018-05-03 10:30:31
Versions:15.3.0 Frequency of
is related toASTERISK-27604 chan_sip: turning on srtp results in one way audio in Asterisk 15
is related toASTERISK-27800 One way audio when calling from Asterisk(sip trunk) to another number where both are connected to a SBC using TLS+SRTP
Description:Same behavior as described in ASTERISK-27604:
One-way audio between srtp and non-srtp clients.
No audio between two srtp clients.

No problem with just one client (e.g. echotest).

Analysis of tcpdump (available on request) reveals that for the srtp stream Asterisk -> client, the wrong - local - encryption key is being used.

That explains the behaviour: Client can't decode incoming stream -> no audio.

Git bisect narrows it down to commit 065c300 / ASTERISK-27118.
Comments:By: Asterisk Team (asteriskteam) 2018-04-08 05:36:51.959-0500

Thanks for creating a report! The issue has entered the triage process. That means the issue will wait in this status until a Bug Marshal has an opportunity to review the issue. Once the issue has been reviewed you will receive comments regarding the next steps towards resolution.

A good first step is for you to review the [Asterisk Issue Guidelines|https://wiki.asterisk.org/wiki/display/AST/Asterisk+Issue+Guidelines] if you haven't already. The guidelines detail what is expected from an Asterisk issue report.

Then, if you are submitting a patch, please review the [Patch Contribution Process|https://wiki.asterisk.org/wiki/display/AST/Patch+Contribution+Process].

By: Asterisk Team (asteriskteam) 2018-04-08 05:36:52.751-0500

The module you are reporting the issue against is no longer supported as a core module but your issue is in the queue. Your patience is appreciated as a community developer may work the issue when time and resources become available.

Asterisk is an open source project and community members work the issues on a voluntary basis. You are welcome to develop your own patches and submit them to the project.[1]

If you are not a programmer and you are in a hurry to see a patch provided then you might try rallying support on the Asterisk users mailing list or forums.[2] Another alternative is offering a bug bounty on the asterisk-dev mailing list.[3] Often a little incentive can go a long way.

[1]: https://wiki.asterisk.org/wiki/display/AST/Patch+Contribution+Process
[2]: http://www.asterisk.org/community/discuss
[3]: https://wiki.asterisk.org/wiki/display/AST/Asterisk+Bug+Bounties

By: Kevin Harwell (kharwell) 2018-04-09 15:19:43.339-0500

I've somewhat confirmed this with a little bit different results. With Asterisk 15 running at commit just prior to 065c300 I saw the following:

srtp->dialpan (playback) - heard audio
srtp->non srtp endpoint - two way audio
srtp->srtp endpoint - two way audio

However, once I updated to commit 065c300 I then saw the below:

srtp->dialpan (playback) - heard audio
srtp->non srtp endpoint - two way audio
srtp->srtp endpoint - one way audio

So there does appear to be a problem.

By: Kevin Harwell (kharwell) 2018-04-09 15:38:01.395-0500

Also tested with chan_pjsip and there does not appear to be any problem when using that channel driver.

By: Addix Internet Services GmbH (addix) 2018-04-19 03:37:38.478-0500

Can reproduce this issue here also. Thats a big show-stopper for us in the transistion to asterisk 15 as we liked the idea of having both sip stacks to make a slow transition of the users between the sip stacks.

By: Addix Internet Services GmbH (addix) 2018-05-03 01:20:00.658-0500

Thanks, patch from gerrit 8886 solved that for us.

By: Friendly Automation (friendly-automation) 2018-05-03 10:30:32.484-0500

Change 8886 merged by Jenkins2:
res_rtp_asterisk: Always update SRTP on local SSRC change.


By: Friendly Automation (friendly-automation) 2018-05-03 10:33:30.132-0500

Change 8885 merged by Jenkins2:
res_rtp_asterisk: Always update SRTP on local SSRC change.