19 Feb
2007
19 Feb
'07
5:56 p.m.
Jiri Kuthan wrote:
It appears that there are two things mixed together.
The 100 is sent upstream
whereas the problem appears downstream. Not sending 100 downstream doesn't
solve the race conditions located downstream.
The problem is that SER doesn't delay sending the CANCEL, it just gives up
on it.
As a side observation regarding to protocol's fault tolerance / race
prone, it would seem there's no way for a stateful proxy to let a callee
(1) whose provisional reply got lost (or not sent, in the first place,
as provisionals is a MUST only for stateful proxies), but (2) whose
final answer was received, about the fact that the call was canceled in
the meantime, even though the proxy has the clear picture - and the only
one that can have it - at the moment it sees the final reply from
callee; (callee which will, however, time out, eventually, waiting for
the ACK).
Bogdan.
The issues is being bug-tracked now, there is no ETA
yet.
Thank you for reporting!
-jiri
--
Jiri Kuthan http://iptel.org/~jiri/
_______________________________________________
Serusers mailing list
Serusers(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers
--
Bogdan Pintea
iptego GmbH - VoIP Security
http://www.iptego.de
Is there
any way I can stop 100 Trying message and still run statefull SER,
so that I can verify what nokia said. Any ideas suggestions are welcome.
Thanking you all in advance.
Best Regards,
Abdul Qadir
________________________________
Don't be flakey. Get Yahoo! Mail for Mobile and
always stay connected to friends.
_______________________________________________
Serusers mailing list
Serusers(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers
_______________________________________________
Serusers mailing list
Serusers(a)lists.iptel.org
http://lists.iptel.org/mailman/listinfo/serusers