11 Aug
2011
11 Aug
'11
9:27 a.m.
it still may happen:
200 OK is received and handled over to TCP worker process A
NOTIFY is received and handled over to TCP worker process B
scheduler puts process A on hold and gives resources to B
so NOTIFY still may overtake 200 OK.
regards
Klaus
Am 10.08.2011 16:58, schrieb Peter Dunkley:
I've been playing around with this here and making
presence and rls use
TCP instead of UDP seems to help with this problem. Presumably this is
because using TCP enforces in-order delivery of messages.
To make presence and rls use TCP I:
* Added a ;transport=tcp parameter to the SIP URI I had set for
presence server_address
* Added a ;transport=tcp parameter to the SIP URI I had set for rls
server_address
* Set the rls outbound_proxy parameter to "sip:127.0.0.1;transport=tcp"
It's not a proper fix, but I think it works around the issue.
Regards,
Peter
On Mon, 2011-08-01 at 13:40 +0200, Klaus Darilion wrote:
Am 01.08.2011 12:28, schrieb Andrew Miller:
--
Peter Dunkley
Technical Director
Crocodile RCS Ltd
_______________________________________________
sr-dev mailing list
sr-dev(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev I attempted to insert a dialog entry in the hash
table on sending the
SUBSCRIBE, unfortunately this did not cure the problem
Has anyone any suggestions for the cleanest and easiest method to ensure
that the 200 is handled before the NOTIFY?
The cleanest solution would be to establish the dialog when the NOTIFY
is received although the 200 OK is missing.
The NOTIFY can be seen as an implicit 200 OK.
regards
Klaus
_______________________________________________
sr-dev mailing list
sr-dev(a)lists.sip-router.org <mailto:sr-dev@lists.sip-router.org>
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev