[Serusers] dealing with parallel forking ...

[Olaf Bergmann]

Cesc Santa wrote:
> On 8/3/07, Olaf Bergmann <Olaf.Bergmann at freenet-ag.de> wrote:
>> samuel wrote:
>>> inline...
>>>
>>> 2007/8/3, Olaf Bergmann <Olaf.Bergmann at freenet-ag.de
>>> <mailto:Olaf.Bergmann at freenet-ag.de>>:
>>>
>>>     Cesc Santa wrote:
>>>
>>>
>>>     > I am doing some tests and it is not really a problem ... but maybe
>>>     > someone has a better idea. In my configuration, the first 200 OK
>>>     > received is forwarded to the caller and the whole SIP session setup
>>>     > (caller + 1st callee).
>>>     > Next 200 OKs are also delivered to the caller,
>>>
>>>     That is the correct behavior of a SIP proxy.
>>>
>>>
>>> I think the proper forking behaviour is to send a CANCEL to all branches
>>> upon receiving a 200 from one of them and I think that SER does this
>>> automatically... isn't it??
>> Correct: if you used append_branch (IIRC you did) the call leg will
>> be canceled by SER. But as there is a race condition due to network
>> latency, a 200 OK might have been sent by the receiving UA before
>> the CANCEL was received.
>>
> 
> Hi Olaf,
> 
> It seems that, for some reason, my SER is not cancelling the branches
> after reception
> of the first 200 OK ... any idea? where would the code be?
> For testing, one of the endpoints is asterisk's echo ...
> The other callee is a phone, and apart from sending 100 and 183, I
> wait some seconds before I decide to pick up ... enough for SER to
> send a CANCEL, which never happends.
> 
> The second 200 OK is not matched to any transaction, so it would seem
> like SER has already deleted it ... when does that happen? I've done
> some stuff with SER ... but the TM module is really hardcore :)

So, which version of SER are you using? IIRC---for some reason, I
did not recently check with the TM code---the outstanding branches
are cancelled automatically after receiving a 200 OK in recent
versions of the TM module. Not sure here---it simply works for us.

Regards,
Olaf