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

Wim De Vlaminck (JIRA) noreply at issues.asterisk.org
Wed Nov 22 02:53:07 CST 2017


Wim De Vlaminck created ASTERISK-27440:
------------------------------------------

             Summary: 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


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)



More information about the asterisk-bugs mailing list