[SR-Users] #TM: timing problem in serial forking (INVITE vs. CANCEL)

[Klaus Feichtinger]

Hello list,

I have troubles with serial forking in kamailio 3.2.4, which is mixed 
with parallel forking. In the scenario that an initial INVITE message, 
which is addressed to sip:A, is coming in to the server, it is doing a 
lookup in the DB and forking (parallel) the request to e.g. 3 SIP user 
agents. I have set the timer to 20 seconds transaction timeout and after 
that timeout, the server is handling the original request in the 
FAILURE_ROUTE[xy]. In this failure route, the request-URI username is 
overwritten to an alternative one -- e.g. sip:B. Then the server is 
doing a DB lookup again and forking the request to the number of 
registered user agents.

A specialiy of this scenario is that it can be possible, that user 
agents have registered for username "A" and username "B" -- in other 
words: they are members of the parallel forking group in serial forking 
step 1 and step 2. When the CANCEL and INVITE message would be sent out 
(to the user agents) in the correct order, then it would be no problem. 
But in my case the server is sending the "new" INVITE message (2^nd step 
in the serial forking procedure) to user agents BEFORE the CANCEL 
request. Therefore, these user agents are rejecting the INVITE message 
with "500".

Signalisation scenario
==================

INVITE -> SRV
SRV -> INVITE (branch-1)  UA1
SRV -> INVITE (branch-2)  UA2
SRV -> INVITE (branch-3)  UA3
SRV <- 180 (branch-1)       UA1
SRV <- 180 (branch-2)       UA2
SRV <- 180 (branch-3)       UA3
.....  [timeout]
SRV -> CANCEL (branch-1) UA1
SRV -> CANCEL (branch-2) UA2
SRV -> INVITE (branch-4)   UA4
SRV -> INVITE (branch-5)   UA5
SRV -> INVITE (branch-6)   UA3    (!!!)
SRV -> CANCEL (branch-3) UA3
SRV <- 500 (branch-6)        UA3

It was quasi reproduceable that only the last branch of the initial 
transaction had that timing problem (INVITE <- vs -> CANCEL).
My question is:  why does the server send the (last) CANCEL message only 
after the INVITE message for some branch(es)? Could this behaviour be 
prohibited in any way?

Thanks in advance!

Klaus

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20131106/7813eaad/attachment.html>