[asterisk-bugs] [JIRA] (ASTERISK-27800) One way audio when calling from Asterisk(sip trunk) to another number where both are connected to a SBC using TLS+SRTP

[Kevin Harwell (JIRA)]

    [ https://issues.asterisk.org/jira/browse/ASTERISK-27800?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=243031#comment-243031 ] 

Kevin Harwell commented on ASTERISK-27800:
------------------------------------------

{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.

> One way audio when calling from Asterisk(sip trunk) to another number where both are connected to a SBC using TLS+SRTP
> ----------------------------------------------------------------------------------------------------------------------
>
>                 Key: ASTERISK-27800
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-27800
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: .Release/Targets
>    Affects Versions: 15.3.0
>            Reporter: Artur Pires
>            Assignee: Artur Pires
>         Attachments: asterisk_logs.txt, asterisk_tcpdump.pcap, topology.jpg
>
>
> Hi,
> I'm doing some tests with Asterisk 15.3.0(Ip=10.9.0.94) connected to a SBC[which has two parties: SIP message(Ip=192.168.12.18 using TLS) and Media Message(Ip=192.168.12.192 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=10.8.15.45) connected to Asterisk to a number(4509615003) connected to SBC we have one way audio. 
> Basically SRTP connects to SBC media(Ip=192.168.12.192). 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,
> Remarks: 
> 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
> Thanks,
> Artur



--
This message was sent by Atlassian JIRA
(v6.2#6252)