3 Aug
2007
3 Aug
'07
4:33 p.m.
On 8/3/07, Olaf Bergmann <Olaf.Bergmann(a)freenet-ag.de> wrote:
Cesc Santa wrote:
I'm using 0.9.6 ...
It is good that it works in yours (which r u using?) ... i can try to
track the problem in the cvs ...
Cesc
On 8/3/07, Olaf Bergmann
<Olaf.Bergmann(a)freenet-ag.de> wrote:
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
samuel wrote:
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 :) inline...
2007/8/3, Olaf Bergmann <Olaf.Bergmann(a)freenet-ag.de
<mailto:Olaf.Bergmann@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.