Klaus Darilion writes:
Maybe the description is bad/wrong, but the details are described in this thread:
http://lists.sip-router.org/pipermail/sr-users/2012-February/071943.html
klaus,
that description there is not very clear either:
I ran into a scenario with couple of serial forks where kamailio loops to itself and, due to the looping, the INVITE to a new branch happens before the CANCEL to an old branch.
is the setup without the 1/2 flags like this:
uac invite -> proxy -> invite -> proxy -> invite -> first uas -> cancel -> proxy -> cancel -> first uas -> invite -> second uas where second proxy instance calls unforce_rtpproxy when it receives the cancel, thus tearing down also the rtpproxy session for the second leg?
is so, why would second proxy instance be involved with rtpproxy stuff at all because that has been already taken care of by the first instance?
-- juha