<p>Maximilian Fridrich <strong>uploaded patch set #2</strong> to this change.</p><p><a href="https://gerrit.asterisk.org/c/asterisk/+/19059">View Change</a></p><pre style="font-family: monospace,monospace; white-space: pre-wrap;">core & res_pjsip: Improve topology change handling.<br><br>This PR contains two relatively separate changes in channel.c and<br>res_pjsip_session.c which ensure that topology changes are not ignored<br>in cases where they should be handled.<br><br>For channel.c:<br><br>The function ast_channel_request_stream_topology_change only triggers a<br>stream topology request change indication, if the channel's topology<br>does not equal the requested topology. However, a channel could be in a<br>state where it is currently "negotiating" a new topology but hasn't<br>updated it yet, so the topology request change would be lost. Channels<br>need to be able to handle such situations internally and stream<br>topology requests should therefore always be passed on.<br><br>In the case of chan_pjsip for example, it queues a session refresh<br>(re-INVITE) if it is currently in the middle of a transaction or has<br>pending requests (among other reasons).<br><br>Now, ast_channel_request_stream_topology_change always indicates a<br>stream topology request change even if the requested topology equals the<br>channel's topology.<br><br>For res_pjsip_session.c:<br><br>The function resolve_refresh_media_states does not process stream state<br>changes if the delayed active state differs from the current active<br>state. I.e. if the currently active stream state has changed between the<br>time the sip session refresh request was queued and the time it is being<br>processed, the session refresh is ignored. However, res_pjsip_session<br>contains logic that ensures that session refreshes are queued and<br>re-queued correctly if a session refresh is currently not possible. So<br>this check is not necessary and led to some session refreshes being<br>lost.<br><br>Now, a session refresh is done even if the delayed active state differs<br>from the current active state and it is checked whether the delayed<br>pending state differs from the current active - because that means a<br>refresh is necessary.<br><br>Further, the unit test of resolve_refresh_media_states was adapted to<br>reflect the new behavior. I.e. the changes to delayed pending are<br>prioritized over the changes to current active because we want to<br>preserve the original intention of the pending state.<br><br>ASTERISK-30184<br><br>Change-Id: Icd0703295271089057717006730b555b9a1d4e5a<br>---<br>M main/channel.c<br>M res/res_pjsip_session.c<br>2 files changed, 62 insertions(+), 19 deletions(-)<br><br></pre><pre style="font-family: monospace,monospace; white-space: pre-wrap;">git pull ssh://gerrit.asterisk.org:29418/asterisk refs/changes/59/19059/2</pre><p>To view, visit <a href="https://gerrit.asterisk.org/c/asterisk/+/19059">change 19059</a>. To unsubscribe, or for help writing mail filters, visit <a href="https://gerrit.asterisk.org/settings">settings</a>.</p><div itemscope itemtype="http://schema.org/EmailMessage"><div itemscope itemprop="action" itemtype="http://schema.org/ViewAction"><link itemprop="url" href="https://gerrit.asterisk.org/c/asterisk/+/19059"/><meta itemprop="name" content="View Change"/></div></div>

<div style="display:none"> Gerrit-Project: asterisk </div>
<div style="display:none"> Gerrit-Branch: 16 </div>
<div style="display:none"> Gerrit-Change-Id: Icd0703295271089057717006730b555b9a1d4e5a </div>
<div style="display:none"> Gerrit-Change-Number: 19059 </div>
<div style="display:none"> Gerrit-PatchSet: 2 </div>
<div style="display:none"> Gerrit-Owner: Maximilian Fridrich <m.fridrich@commend.com> </div>
<div style="display:none"> Gerrit-Reviewer: Friendly Automation </div>
<div style="display:none"> Gerrit-MessageType: newpatchset </div>