[OpenSIPS-Users] parallel forking and CANCEL/BYE

[Iñaki Baz Castillo]

El Jueves, 22 de Octubre de 2009, Uwe Kastens escribió:
> Hi Borgan,
> 
> Sorry by trying to debug the problem I understood the hole picture. I
> think it might be a bug or a feature request for the tm module.
> 
> The setup is:
> 
> PSTN-GW <-> opensips as statefull proxy <-> AST1 + AST2
> 
> If I make a call from pstn over the opensips to a specific SIP-URI, the
> call will be forked parallel to AST1 and AST2. This is done statefull
> via tm (relay). AST1 will send a 200 OK with SDP, tm will generate a
> CANCEL message for the 2nd branch to AST2. 
> AST2 has already sent a 200
> OK with SDP and will therefore send 200 OK for the CANCEL request.
 
> The problem is, that both 200 OK with SDP are sent back to the PSTN GW,
>  which has ACKed one call already and will get a 2nd 200 OK with the
> same branch but different call-id. 

Different call-id? Perhaps yo mean "different To tag" as the Call-ID is 
generated by the UAC (the gw) and must be the same in both legs.


> This is ignored because the PSTN-GW
> is not aware about branches/call-id.

But what is the real problem? in the gw side you said that it ignores the 
second 200 coming from AST2, so there is no problem in the gw, right?

Perhaps the problem could be that AST2 replies the INVITE so it will be 
waiting for the ACK for ~32 seconds.

You could also drop the second 200 in OpenSIPS by checking in reply_route[0] 
"check_trans()". It will return false for the second 200 OK as the transaction 
was removed upon recepit of the first 200. So the call "drop()". However it 
solves nothing since AST2 remains waiting for the ACK.


> So there are 2 possible solutions:
> 
> - The PSTN GW needs to send a BYE to the branch which comes later on
> with the same branch but different call-id.

Again: replace "call-id" with "To-tag" :)

Yes, this is the RFC 3261 solution. The issue should be handled by the UAC 
rather than by a proxy.


> - opensips TM should send a bye if the CANCEL if the call is forked
> parallel and the CANCEL Message is answered with a 200 OK.

The fact is that a proxy should never send a BYE. Yes, it could and it's 
useful for some stuff, but cannot be a MUST.

Also you forget that before sending the BYE, OpenSIPS TM should also send a 
ACK for that 200. This is really complex as OpenSIPS is behaving as a UAC. 
Sincerely, I don't expect that OpenSIPS implements the logic to send an ACK 
for a 200 (INVITE). Note that this ACK is transaction stateful, so in case the 
UAS re-sends the 200 OpenSIPS should retransmit the ACK, timers...


> I know there is a lot of discussion about this issue, but I need a
> solution....

What is exactly the issue? is the above explained by me?






-- 
Iñaki Baz Castillo <ibc at aliax.net>