Summary:ASTERISK-27800: One way audio when calling from Asterisk(sip trunk) to another number where both are connected to a SBC using TLS+SRTP
Reporter:Artur Pires (artur.pires)Labels:pjsip
Date Opened:2018-04-12 15:12:46Date Closed:2018-05-03 10:30:33
Versions:15.3.0 Frequency of
is related toASTERISK-27795 chan_sip: one way / no audio with srtp
Environment:Attachments:( 0) asterisk_logs.txt
( 1) asterisk_tcpdump.pcap
( 2) topology.jpg

I'm doing some tests with Asterisk 15.3.0(Ip= connected to a SBC[which has two parties: SIP message(Ip= using TLS) and Media Message(Ip= using SRTP)]
For sip message works fine using TLS over TCP with the key generated on Asterisk and uploaded it to SBC(sip message).
So when I call from my extension(100 - Ip= connected to Asterisk to a number(4509615003) connected to SBC we have one way audio.
Basically SRTP connects to SBC media(Ip= Please see the attached picture

It looks like Asterisk is using the wrong key to encrypt traffic when it's offered the SDP.
By replaying a packet captured on SBC(media message - SRTP) and configuring a connection, it was discovered that using the key offered to Asterisk to decrypt the traffic actually worked.
According to RFC 4568, the key provided in the SDP is used to encrypt traffic generated by the provider of the SDP.
Hence, Asterisk device should use the key provides in the answer SDP to encrypt traffic but our tests show it's using the key generated by SBC(SIP message)

Please let me know if you need further details about this issue,


1) Part of RFC 4568 which explains what I noticed(section 5.1.1) :

  The crypto-suite always applies to media in the directions supported
  by the media stream (e.g., send and receive).  The key(s), however,
  apply to data packets (e.g., SRTP and SRTCP packets) that will be
  sent by the same party that generated the SDP.  That is, each
  endpoint determines its own transmission keys and sends those keys,
  in SDP, to the other endpoint.

  The inline parameter conveys the SRTP master key used by an endpoint
  to encrypt the SRTP and SRTCP streams transmitted by that endpoint.
  The same key is used by the recipient to decrypt those streams.

  However, the receiver MUST NOT use that same key for the SRTP or
  SRTCP packets that it sends to the session because the default SRTP
  cipher and mode is insecure when the master key is reused across
  distinct SRTP streams.

2) Logs are attached

Comments:By: Asterisk Team (asteriskteam) 2018-04-12 15:12:47.015-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: Kevin Harwell (kharwell) 2018-04-12 18:46:16.791-0500

[~artur.pires] It looks like you are running chan_sip if I am not mistaken. If so then your issue might be the same or related to ASTERISK-27795. Would it be possible for you to try testing with commit 8b535a4, which is just prior to the one mentioned on the other issue and see if it then works?

By: Artur Pires (artur.pires) 2018-04-16 05:32:04.892-0500

Hi Kevin Harwell,

Yes I'm using chan_sip. I'm not sure I got it when you meant to test with commit 8b535a4. Do I have to use chan_pjsip instead in order to work it?
Or is there another configuration to use chan_sip? Can you please clarify it.


By: Kevin Harwell (kharwell) 2018-04-16 12:36:45.267-0500

{quote}Do I have to use chan_pjsip instead in order to work it? Or is there another configuration to use chan_sip?{quote}
If you are able, I'd recommend switching to chan_pjsip. If this issue is the same as the other one then switching should fix it as it seems to work as expected in chan_pjsip. Also in general switching to chan_pjsip is recommended because it is now the main SIP channel driver in Asterisk with chan_sip only receiving limited community support.

{quote}I'm not sure I got it when you meant to test with commit 8b535a4{quote}
I meant if you are building from Asterisk source and you are able to, then you could try checking out commit 8b535a4 (15 branch) from the Asterisk git repository. That is the commit just prior to commit 065c300 (mentioned on ASTERISK-27795 as the patch that is causing the bug).

If you checkout commit 8b535a4 and rebuild and re-install Asterisk and re-test, and no longer have the problem then that would confirm that your issue is the same as the other. Switching to chan_pjsip would probably also confirm that as well since it doesn't appear to be a bug in chan_pjsip.

By: Artur Pires (artur.pires) 2018-04-17 10:53:44.366-0500

Hi Kevin Harwell

Commit 8b535a4 fixes the issue
Thank you very much for your support,


By: Kevin Harwell (kharwell) 2018-04-17 13:10:43.584-0500

[~artur.pires], thanks for checking that and confirming that is the problem.

Do note that that commit does not fix the issue, but removes the code that introduced the problem (plus a bunch of other code and patches if your Asterisk branch is checked out to that). So if you run off that older code you will be missing quite a number of recent patches. Your other option is to use chan_pjsip as the problem did not seem to present itself using that channel driver.

By: Friendly Automation (friendly-automation) 2018-05-03 10:30:34.138-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:31.116-0500

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