[OpenSIPS-Users] parallel forking and CANCEL/BYE

[Uwe Kastens]

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. This is ignored because the PSTN-GW
is not aware about branches/call-id.

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

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

BR

Uwe



Bogdan-Andrei Iancu schrieb:
> Hi Uwe,
> 
> as I understand from you, from end devices (GW, as1 and as2) everything 
> work ok, but the dialog state on opensips is not properly kept??
> 
> Regards,
> Bogdan
> 
> Uwe Kastens wrote:
>> Hello Bogdan,
>>
>> Now we changed the behaviour of the UAC. One of them will send a BYE and
>> this is relayed to the PSTN GW which drops the call, since opensips will
>> not handle the BYE locally. So loose_route is done and the BYE is
>> relayed to the PSTN GW.
>>
>> The following is happening:
>>
>> 1) INVITE from PSTN GW
>> 2) parallel forking to ast1 and ast2 (branches z9hG4bK51f6.9afa91c3.1
>> and z9hG4bK51f6.9afa91c3.0)
>> 3) ast1 sends an 200 OK (branch z9hG4bK51f6.9afa91c3.0)
>> 4) opensips sends an cancel to ast2 (branch z9hG4bK51f6.9afa91c3.1)
>> 5) opensips receives the 200 OK from ast1 and sends an ACK (branch is
>> changing here to z9hG4bK51f6.9afa91c3.3)
>> 6) opensips receives 200 OK from ast2 from the INVITE (branch
>> z9hG4bK51f6.9afa91c3.1)and sends an ACK (branch is changing to
>> z9hG4bK51f6.9afa91c3.3)
>> 7) opensips reives 200 OK from ast2 for the cancel request ( branch
>> z9hG4bK51f6.9afa91c3.1)
>> 8) opensips receives BYE from ast2 with branch z9hG4bK40d1af5d
>> 9) opensips is doing loose_route and sends the BYE to the PSTN GW
>>
>>
>> The only thing I could see on the logs is:
>>
>>  WARNING:dialog:dlg_onroute: tight matching failed for BYE with
>> callid='393105a419950c1f265f298914662393 at 10.20.30.100'/46,
>> ftag='as63949c6e'/10, ttag='as0d1597ca'/10 and direction=0
>> Oct 21 09:09:15 asne02 /usr/sbin/opensips[15615]:
>> WARNING:dialog:dlg_onroute: dialog identification elements are
>> callid='393105a419950c1f265f298914662393 at 10.20.30.100'/46, caller
>> tag='as0d1597ca'/10, callee tag='as79debd51'/10
>>
>> Why is the opensips not handling the BYE locally and only closing one
>> branch?
>>
>> BR
>>
>> UWe
>>
>>
>> Bogdan-Andrei Iancu schrieb:
>>   
>>> Hi Uwe,
>>>
>>> Uwe Kastens wrote:
>>>     
>>>> Hi Bogdan,
>>>>
>>>>   
>>>>       
>>>>> So actually both legs do send 200 OK (but one faster than the 
>>>>> other)......so there is kind on race between the 200 OK from the slow 
>>>>> branch and the CANCEL from OpenSIPS...is this the case?
>>>>>     
>>>>>         
>>>> Exactly
>>>>
>>>>   
>>>>       
>>>>> If so, the UAS will simply reply with negative reply to CANCEL (decline 
>>>>> it) and opensips (for INVITE transaction) will not close the second 
>>>>> branch as there is a 200 OK (and not a 487) received ....RFC3261 says 
>>>>> that a proxy must send all 200 OK (for a call), even if more than one, 
>>>>> to the UAC - the UAC is the one who will decide what branch to keep and 
>>>>> it will fire a BYE for the other branch.
>>>>>
>>>>>     
>>>>>         
>>>> Could this explan, why only the 2nd Node will get the BYE, if the call
>>>> is released "behind" the opensips?
>>>>   
>>>>       
>>> yes, because the caller will hung up only one of the callee branch, so 
>>> the BYE will go to only one of them. The other branch will remain up and 
>>> will be the ongoing call.
>>>
>>> Regards,
>>> Bogdan
>>>
>>> _______________________________________________
>>> Users mailing list
>>> Users at lists.opensips.org
>>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
>>>     
>>
>>   
> 
> 
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users


-- 

kiste lat: 54.322684, lon: 10.13586