This patch promptly terminates the call if any of the 2 CN-sides are not already ready when the bridging is requested.

Another version of the patch which also would fix the issue would be:

"""

• call_leg_ensure_ci(cl1, RTP_TO_CN, call_id1, trans1,
• &codec, &cl2->rtp[RTP_TO_CN]->local);
• call_leg_ensure_ci(cl2, RTP_TO_CN, call_id2, trans2,
• &codec, &cl1->rtp[RTP_TO_CN]->local);
• + call_leg_ensure_ci(cl1, RTP_TO_CN, call_id1, trans1, &codec,
• + cl2->rtp[RTP_TO_CN] ? &cl2->rtp[RTP_TO_CN]->local : NULL);
• + call_leg_ensure_ci(cl2, RTP_TO_CN, call_id2, trans2, &codec,
• + cl1->rtp[RTP_TO_CN] ? &cl1->rtp[RTP_TO_CN]->local : NULL)
• """

In the version presented above, the call would continue for a few more secs, until timer X2 triggers in rtp_stream FSM.

The question here is whether in normal conditions, it can be that the RAB-ASsReq is delayed so much that it arrives after the bridging is done. In that case, maybe this version above is better since then it may end up working correctly...

Neels or others, any comments on preferred way to fix it?

View Change

To view, visit change 26917. To unsubscribe, or for help writing mail filters, visit settings.