mirror of https://github.com/asterisk/asterisk
Found during some testing, there is a race condition between selecting an appropriate bridge type for a call versus the applying of media on the callee's session. In some instances a native bridge type would have been chosen, but due to the callee's media not yet being established at bridge compatibility check time the simple bridge type is picked instead. When using chan_pjsip this initiates a topology change event. The topologies are then compared for the two sessions. However, when the topology was created for the caller its streams are initialized to "inactive". This topology is then used as a base when creating the callee's topology, and streams. Soon after the caller's topology's stream(s) get updated based on the sdp (get set to sendrecv in the failing scenario). Now when the topology change event is raised, and the two topologies are compared, the comparison fails due to a stream state mismatch (sendrecv vs inactive). And since they differ a reinvite is sent out (to the caller in this case). This patch makes it such that when the caller's topology is initially created it gets created based on its configured endpoint's media topology. When the endpoint's topology is created its stream's state(s) are initialized to sendrecv instead of inactive. Subsequently, now when the callee's topology is created its topology streams are now initialized to sendrecv. Thus when the topology change event occurs due to the mentioned scenario the stream states match for the given sessions, and the reinvite is not sent unless due to some other valid mismatch. Note, this patch only changes one pending media state's creation point. It's possible other places *could* be changed, however for now it was deemed best to only alter what's here. Change-Id: I6ba3a6a75f64824a1b963044c37acbe951c389c717.1
parent
36b28c98dd
commit
ea3daa94c8
Loading…
Reference in new issue