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

[Klaus Feichtinger]

> I think it would be nice if the CANCELs are sent before the INVITE. 
> But this will never ensure the order how they are received at the 
> client side. E.g. there can be packet loss which drops the CANCEL but 
> not the INVITE, or with load balancing the INVITE can overtake the 
> CANCEL. And if the client is not single-threaded, it may happen that 
> the INVITE is processed before the CANCEL, although the CANCEL is 
> received first.
>
That´s all true. But in our scenario we have the problem that the client 
cannot differ between the old and new transaction, as it seems it is 
using the typical dialog attributes for differing transactions only. I 
know that this is not correct, but this problem cannot be solved so easy 
and fast.
> I suspect that the client is just buggy with transaction matching. 
> Transactions are identified by the branch parameter in the topmost Via 
> header. The CANCEL should have the branch parameter matching the first 
> INVITE, and the second INVITE to the same client should have a new 
> branch parameter.
>
> Thus, the client should be able to separate the transactions, and the 
> INVITE can be accepted creating a second transcation. Then the CANCEL 
> cancels the first transaction.
>
> regards
> Klaus
Finally I found today a solution for this problem by using the ASYNC 
module, which I´veused for delaying the new transaction within the 
failure_route. It was not so easy, as the initially selected function 
"sleep()" does not work within the failure_route.......

regards
klaus
>
> On 06.11.2013 21:16, Klaus Feichtinger wrote:
>> 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
>>
>>
>>
>> _______________________________________________
>> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
>> sr-users at lists.sip-router.org
>> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
>>
>