[OpenSIPS-Users] parallel forking and CANCEL/BYE

[Uwe Kastens]

Hi,
>>  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.

You are correct. The Call-ID AND branch is the same for 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?
> 


The problem is, that:
- rtp information is mixed between ast1 and ast2
- if ast1 or ast2 is sending a BYE, the hole call is dropped


> 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.

Ok, it makes no sense then.

So there is only one possible solution....
> 
> 
>> 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

> 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 

> 
> 
>> 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?

Yes. I was able to step on testing and found out, that our reference
system (softsiwtch) is handling it correctly. The asterisk servers we
are using as mediagateways are unable to handle it correctly - so I will
need a fix for them.

Anybody know if this has been fixed on asterisk?

BR

Uwe

-- 

kiste lat: 54.322684, lon: 10.13586