]> git.ipfire.org Git - thirdparty/asterisk.git/commit
res_pjsip/rtp: No joint capabilities between streams.
authorBen Ford <bford@digium.com>
Tue, 7 Aug 2018 15:57:29 +0000 (10:57 -0500)
committerBen Ford <bford@digium.com>
Mon, 13 Aug 2018 19:01:53 +0000 (14:01 -0500)
commita46fcaca7bcb019a1a2b29d3c9a528da637840d7
treee4e86146f2f0d323d74dfe25cf4d9130475eda16
parent914b9e193451bdfbf2037603c650c83f4af3a419
res_pjsip/rtp: No joint capabilities between streams.

When a conference contained a mixture of audio/video and audio-only
users, a NOTICE message would pop up stating there are no joint
capabilities between streams. This happens because streams can never be
removed, but they can be in a REMOVED state. If we have the scenario
where user A joins with audio/video, user B joins with audio-only, and
user C joins with audio/video, then user A leaves, the message would
be triggered. That removed stream is still in the SDP, but Asterisk
would pass it through, causing it to be seen as a ulaw stream. A check
has been added for removed streams, setting their status to REMOVED when
handling negotiated SDPs.

Also addressed an issue where user A joins, then user B joins but does
not receive video until much later. Full frames were not being sent,
causing some PLI from the browser. Because the video was flowing in one
direction, the browser sets the SSRC to 1, but Asterisk was dropping the
PLI because of that. Added a check to see if the SSRC is 1 or not, which
sends full frames and allows video to flow between user A and user B.
This should only happen when dealing with PSFB or FUR, and in the case
of PSFB, only for PLI.

ASTERISK-27398

Change-Id: I26e7c6f101bc119549eeca406b5bcd25ad8ebc5e
res/res_pjsip_session.c
res/res_rtp_asterisk.c