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