[sr-dev] RLS/PUA concurrency issue

[Klaus Darilion]

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:
>> > 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 at lists.sip-router.org <mailto:sr-dev at lists.sip-router.org>
>> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
> 
> -- 
> Peter Dunkley
> Technical Director
> Crocodile RCS Ltd
> 
> 
> 
> _______________________________________________
> sr-dev mailing list
> sr-dev at lists.sip-router.org
> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev