[asterisk-bugs] [JIRA] (ASTERISK-27440) Strictrtp has issues to qualify video rtp streams

[Friendly Automation (JIRA)]

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

Friendly Automation commented on ASTERISK-27440:
------------------------------------------------

Change 7573 merged by Jenkins2:
res_rtp_asterisk.c: Disable packet flood detection for video streams.

[https://gerrit.asterisk.org/7573|https://gerrit.asterisk.org/7573]

> Strictrtp has issues to qualify video rtp streams
> -------------------------------------------------
>
>                 Key: ASTERISK-27440
>                 URL: https://issues.asterisk.org/jira/browse/ASTERISK-27440
>             Project: Asterisk
>          Issue Type: Bug
>      Security Level: None
>          Components: Resources/res_rtp_asterisk
>    Affects Versions: 13.18.0
>            Reporter: Wim De Vlaminck
>            Assignee: Richard Mudgett
>         Attachments: example.tgz
>
>
> We have noticed difficulties with video doorphones since the rtpbleed fix.
> On this setup we have devices behind nat on a publically hosted asterisk.
> Incoming calls need to have both audio and video rtp streams qualified. For audio there's never a problem, but video doesn't get qualified.
> The cli logs non stop "dropping due to strict RTP protection. Will switch to it in 3 packets."
> After some digging I've found that disabling strictrtp resoved the issue.
> After some more digging I've found why strictrtp was causing problems. 
> There's a check that compares the arrival time to the arrival time since the last rtp packet. If it's less than 5 ms the rtp packet is rejected and the qualifying counter is reset. 
> For voice rtp you should get an rtp packet every 20 ms so that 5 ms limit seems reasonable. The problem for video is that when a single frame doesn't fit into a single rtp packet, it creates multiple rtp packets and sends them one after the other with no delay, causing the "flood of packets".
> A possible workaround could be that the option strictrtp is not limited to yes/no but maybe has an extra option audioonly. I'm not sure if it's possible to know if an rtp stream is audio or video?
> If not, maybe there could be an option in rtp.conf of payload type to not apply strict rtp on?
> I managed to bypass the qualifying based on payloadtype 99 and added the option in rtp.conf. 



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