<div dir="ltr"><div dir="ltr">On Wed, May 11, 2022 at 9:54 AM Joshua C. Colp <<a href="mailto:jcolp@sangoma.com" target="_blank">jcolp@sangoma.com</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div dir="ltr">On Wed, May 11, 2022 at 11:50 AM Fridrich Maximilian <<a href="mailto:M.Fridrich@commend.com" target="_blank">M.Fridrich@commend.com</a>> wrote:<br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">> You're in off-nominal untested un thought of territory, so the code behavior<br>
> probably reflects that. Specifically having both audio and video, and doing<br>
> hold/unhold. Audio hold is special and separate from stream negotiation,<br>
> while video isn't, so things probably don't handle that.<br>
<br>
Considering that, I would like to have a discussion about considering reverting<br>
ASTERISK-28783 [1]. This change showed that the handling of non-default streams<br>
is not mature enough yet to be used in production environments. Specifically,<br>
one-way streams and hold/unhold are not handled correctly. In order to keep<br>
Asterisk reliably usable for many different use-cases (Swiss Army Knife), I<br>
would suggest reverting this change for now until the handling of non-default<br>
streams is mature enough to handle more than just the most basic use-cases.<br>
<br>
Please let me know what you think about this suggestion.<br></blockquote><div><br></div><div>Oh, that's my change from long ago. That change has existed in the code base for quite a long time. It's not something that can likely just be reverted, and I'd be hesitant in doing so. It would also require disabling the test coverage for it too I think. It could also cause ripples elsewhere. I'd be against it.</div><div><br></div><div>Thoughts from others?</div></div><div><br></div>-- <br><div dir="ltr"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><div style="font-family:tahoma,sans-serif"><font color="#073763">Joshua C. Colp</font></div><div style="font-family:tahoma,sans-serif"><font color="#073763">Asterisk Technical Lead</font></div><div style="font-family:tahoma,sans-serif"><font color="#073763">Sangoma Technologies</font></div><div style="font-family:tahoma,sans-serif"><font color="#073763">Check us out at <a href="http://www.sangoma.com" target="_blank">www.sangoma.com</a> and <a href="http://www.asterisk.org" target="_blank">www.asterisk.org</a></font></div></div></div></div></div></div></div></div></div></div></div></blockquote><div><br></div><div>I too would be hesitant in doing a straight revert of the patch. I think at this point a new patch would be needed that fixes the newly reported bug (<span style="color:rgb(80,0,80)">ASTERISK-30051)</span>, but also maintains the current behavior of ASTERISK-28783 in some way.</div></div></div>