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

[Daniel-Constantin Mierla]

Hello,

On 2/9/12 5:13 PM, Andreas Granig wrote:
> 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?
if you do rtpproxy handling on an instance that received a parallel 
forked call, then it is better to add the condition on top via branch, I 
don't see other solution for now and I am not aware of an implementation 
for it. I would add a new flag to rtpproxy parameters to send the branch 
value, that will allow to use old rptproxy versions when the flag is not 
given.

Cheers,
Daniel

-- 
Daniel-Constantin Mierla -- http://www.asipto.com
http://linkedin.com/in/miconda -- http://twitter.com/miconda