[SR-Users] rtpproxy and CANCEL in serial forked scenarios

[Andreas Granig]

Hi,

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. What I do at the moment is force
rtpproxy in branch route, and stop rtpproxy in the failure route.

The problem with this scenario is that in rtpproxy_offer and
unforce_rtpproxy, the rtpproxy module only passes the call-id and
from-tag to rtpproxy (because there is no to-tag yet), which then in
unforce_rtpproxy for a CANCEL deletes all calls related to it (because
it can only match on from-tag and call-id, obviously). This means that
when I do a subsequent rtpproxy_answer for my new branch, rtpproxy
doesn't find the session anymore, since it has been removed with the CANCEL.

A fix I can think of is to also pass the branch of the top-most via to
rtpproxy in order to perform a more fine-grained matching. Are there
solutions to that out there somewhere, or is it something I should just
introduce, eg. as a new param to offer/answer/unforce functions?
Objections? Other approaches?

Andreas