8 Nov
2013
8 Nov
'13
2:46 p.m.
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.
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
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(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users