[OpenSIPS-Users] parallel forking and CANCEL/BYE

Uwe Kastens kiste at kiste.org
Tue Oct 20 20:53:04 CEST 2009


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?

BR

Uwe

> Regards,
> Bogdan
> 
> Uwe Kastens wrote:
>> Hello again,
>>
>> I was wondering if there might be a bug with the correct handling of
>> Cancel in case of receiving and final answer.
>>
>> I will fork one Call to 2 nodes. One node answers a little faster than
>> the other and will get the call. Opensips will send a CANCEL for the
>> other node which is sending a SIP/2.0 200 OK before receiving the
>> CANCEL. So this node is not answering with a 487 but with a 200/OK.
>>
>> Opensips seems to drop the call leg and so the BYE from that node could
>> not be handled.
>>
>> Is this behaviour RFC conform?
>>
>> I will attach one ngrep and one opensips logfile
>>
>> BR
>>
>> Uwe
>>
>>
>>
>>
>> Uwe Kastens schrieb:
>>   
>>> Hi,
>>>
>>> I am using opensips to fork calls to UAs which are registrered from 
>>> different IPs/Ports.
>>>
>>> If one UA accepts the INVITE the other UAs will get a CANCEL.
>>>
>>> Now I have one subscriber with 2 asterisk server which asked me to send 
>>> a BYE after the CANCEL. Otherwise he wants me to send an BYE which could 
>>> not be processed correctly on the opensips.
>>>
>>> I am pretty sure, that this kind of handling would not be RFC conform 
>>> and so its not possible to handle this inside the routing script. Or did 
>>> I missed something?
>>>
>>> BR
>>>
>>> Uwe
>>>
>>>
>>> _______________________________________________
>>> 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
>>   
> 
> 
> _______________________________________________
> Users mailing list
> Users at lists.opensips.org
> http://lists.opensips.org/cgi-bin/mailman/listinfo/users


-- 

kiste lat: 54.322684, lon: 10.13586



More information about the Users mailing list