Hi Robert,
The case you describe normally happens when subsequent requests are sent
very fast after another, without waiting for any reply or the like. This
is the price to pay for having more than one thread processing the UDP
traffic arriving on the same address:port. However, you can turn this
off by configuring only one signaling thread (sip_server_threads=1 in
sems.conf) if this better suits your application.
In general, it might better to wait for some reply or at least some time
before a new request is sent (if the sending application is under your
control).
Cheers
Raphael.
On 08.02.11 17:43, Robert Szokovacs wrote:
Hi,
In the process of trialing the SEMS1.3.1, I have noticed that in certain
cases, some UDP packets can be processed out-of-order, because the UDP
receiver threads happen to run that way. The problem arises when the
AmSipDialog checks the CSeq and rejects the first message (processed later
then the second one).
I'm not entirely sure if it's a bug in SEMS or my application bends the SIP
protocol too much.
Any advice is appreciated!
br
Szo
_______________________________________________
Semsdev mailing list
[email protected]
http://lists.iptel.org/mailman/listinfo/semsdev
_______________________________________________
Semsdev mailing list
[email protected]
http://lists.iptel.org/mailman/listinfo/semsdev
