11 Oct
2012
11 Oct
'12
4:49 p.m.
I can confirm this behavior.
I had a similar scenario when 2 or more branches were setup. First branch
timed out, while second branch was being processed a reply from first
branch arrived and handled improperly by a routing logic which was
configured for the second branch.
I isolated each response from the different branches by parsing the branch
ID that Kamailio adds to the via header after processing the request.
Through this mean, I managed to handle correctly each reply from different
branches no matter when the response was received.
Regards.
Carlos.
On Thu, Oct 11, 2012 at 10:35 AM, Alex Hermann <alex(a)speakup.nl> wrote:
On Thursday 11 October 2012, Juha Heinanen wrote:
No, let me explain it a bit more.
At step 2a) a provisional response is received.
The proxy is configured with a maximum ringtime (fr_inv_timeout). If that
expires, an internal 408 is generated and failure_route is entered (which
will
launch branch 2.
At (almost) the same time the proxy sends a CANCEL to abort branch 1. The
uas
at the receiving end of branch 1 will however still respond to the INVITE
(as
it should), hence the 487 from step 7.
I need to do specific processing when branch 1 receives a reply, and do
that
in onreply_route A. Unfortunately, the reply never reaches that code.
(In reality, branch 1 is not just 1 branch, but consists of multiple
parallel
branches, all receiving a reply on the cancelled INVITE. Most of them
arrive
before the 2nd branch is relayed, those are handled correctly by
onreply_route
A, but replies that come in later are incorrectly handled by onreply_route
B)
--
Greetings,
Alex Hermann
_______________________________________________
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
sr-users(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
Alex Hermann writes:
> 1) set onreply_route to A
> 2) relay 1st branch
> 3) 1st branch times out, internal 408 is created
> 4) tm send CANCEL to 1st branch
>
> 5) in failure route, onreply_route is set to B
> 6) relay 2nd branch
> 7) 1st branch responds with 487, and goes into reply_route B instead
of A
I think each branch should take the reply_route which was set before it
got relayed and not pick up later changes meant for other branches.
if first branch already timed out, shouldn't reply in step(7) go to
garbage pin instead?