[asterisk-bugs] [JIRA] (ASTERISK-29937) res_rtp_asterisk: Resending of NACK requested packet sends different packet

[Erik Bergschöld (JIRA)]

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

Erik Bergschöld commented on ASTERISK-29937:
--------------------------------------------

Got it to work by adding 

policy->sp.allow_repeat_tx = 1;

in res_srtp.c

static int ast_srtp_add_stream(struct ast_srtp *srtp, struct ast_srtp_policy *policy)
{
    struct ast_srtp_policy *match;

    /* For existing streams, replace if its an SSRC stream, or bail if its a wildcard */
    if ((match = find_policy(srtp, &policy->sp, OBJ_POINTER))) {
        if (policy->sp.ssrc.type != ssrc_specific) {
            ast_log(AST_LOG_WARNING, "Cannot replace an existing wildcard policy\n");
            ao2_t_ref(match, -1, "Unreffing already existing policy");
            return -1;
        } else {
            if (srtp_remove_stream(srtp->session, match->sp.ssrc.value) != err_status_ok) {
                ast_log(AST_LOG_WARNING, "Failed to remove SRTP stream for SSRC %u\n", match->sp.ssrc.value);
            }
            ao2_t_unlink(srtp->policies, match, "Remove existing match policy");
            ao2_t_ref(match, -1, "Unreffing already existing policy");
        }
    }

    policy->sp.allow_repeat_tx = 1; //Solution for RTP retransmission

    ast_debug(3, "Adding new policy for %s %u\n",
        policy->sp.ssrc.type == ssrc_specific ? "SSRC" : "type",
        policy->sp.ssrc.type == ssrc_specific ? policy->sp.ssrc.value : policy->sp.ssrc.type);
    if (srtp_add_stream(srtp->session, &policy->sp) != err_status_ok) {
        ast_log(AST_LOG_WARNING, "Failed to add SRTP stream for %s %u\n",
            policy->sp.ssrc.type == ssrc_specific ? "SSRC" : "type",
            policy->sp.ssrc.type == ssrc_specific ? policy->sp.ssrc.value : policy->sp.ssrc.type);
        return -1;
    }

    ao2_t_link(srtp->policies, policy, "Added additional stream");

    return 0;
}

I'm unsure of the security risks with this solution though. This is a note from libsrtp
int        allow_repeat_tx;  /**< Whether retransmissions of
				*   packets with the same sequence number
				*   are allowed.  (Note that such repeated
				*   transmissions must have the same RTP
				*   payload, or a severe security weakness
				*   is introduced!)                      */

This could of course be added as a conf setting. I found the rtp.conf setting "srtpreplayprotection", but it did not work in my case since it's only used in decrypt and by looking at the description and implementation it's seems that it creates a new srtp instance everytime and that is probably not suitable for NACK retransmissions since they can occur often

> res_rtp_asterisk: Resending of NACK requested packet sends different packet
> ---------------------------------------------------------------------------
>
>                 Key: ASTERISK-29937
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-29937
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: Resources/res_rtp_asterisk
>    Affects Versions: 18.8.0
>         Environment: Asterisk running on Alma linux 8 and WebRTC on Google chrome Version 98.0.4758.109 Mac OS 12.2
>            Reporter: Erik Bergschöld
>            Assignee: Unassigned
>              Labels: webrtc
>         Attachments: asterisk_full, clientrtpdump.pcap, serverrtpdump.pcap
>
>
> I'm testing a 1 to 1 video call with WebRTC to WebRTC through Asterisk. The network has sporadic packetloss, but most often a single package in a few seconds. The package lost causes a freeze for about 2 seconds until the video starts working again. I guess this should not happen if NACK was working? So I've looked at wireshark on both client side and server side and I can see that Webrtc is sending a NACK to Asterisk and asterisk is responding by sending the package again with the right seqnumber and I can see the package arriving at the client side, but Chrome WebRTC does not seem to accept the package because after that Chrome sends the same NACK over and over again for 2 seconds while asterisk is responding with the same package.
> By looking at wireshark I can see that the first package sent by Asterisk (The package that was lost) is 10 bytes larger than the package sent as a response to the NACK message. There is also a diff when comparing the payload. Shouldn't the payload be the same for the same package?
> This happens everytime there is a single packetloss and is causing the video to freeze alot. I can provide wireshark traces and examples if necessary



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