[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