[sr-dev] RLS/PUA concurrency issue

[Andrew Miller]

FYI, Just seen an internal e-mail from Peter saying he thinks he has 
fixed it. I will test this as soon as I get into the office this morning 
and we will report back

Didn't want anyone putting more time into this if Peter has fixed it.

Andy

On 11/08/2011 08:42, Andrew Miller wrote:
> Klaus,
>
> Sorry we should have mentioned that we did investigate this option, 
> however we do not think it will work.
>
> I may have got the details below wrong, as Peter has been looking at 
> this, however the reason is something like the following:
>
> The main job of the 200 handler is to write a database entry that 
> binds the incoming RLS subscription to the back-end presence 
> subscription. A pointer to the RLS subscription is bound to the INVITE 
> transaction, and is therefore available to the 200 call back function. 
> The same information is not available to the NOTIFY handler - it 
> expects to get this information FROM the database. Therefore, we 
> cannot (unfortunately) handle the NOTIFY in exactly the same way as 
> the 200.
>
> Is that right Peter?
>
> Andy
>
>
> On 11/08/2011 08:30, Klaus Darilion wrote:
>>
>> Am 10.08.2011 18:54, schrieb Daniel-Constantin Mierla:
>>> Hello,
>>>
>>> I would like to look closer at the issue and figure out possible
>>> solution, but I am traveling for time being, so just quick thoughts.
>>>
>>> One approach would the similar solution as for the fast CANCEL (which
>>> gets to the server before the INVITE). What we do (in config), we check
>>> if there is an INVITE transaction for the CANCEL and if not we just 
>>> drop
>>> the CANCEL (no reply). That will force the UA to do retransmissions,
>>> which eventually will come after the INVITE is received/processed.
>> Does not work with TCP requests.
>>
>>> The second idea would be to have a pending queue, keep the NOTIFY for a
>>> while there and when 200ok is coming, look in the queue if it is
>>> something for respective dialog. If no dialog is created after a while,
>>> request that are older in the queue will be just discarded.
>> The NOTIFY is in an implicit 200 OK. So if there is an ongoing SUBSCRIBE
>> transaction which matches the NOTIFY, the NOTIFY should trigger the same
>> actions as the 200 OK. The later arriving 200 OK can then be ignored.
>>
>> regards
>> klaus
>>
>>> Cheers,
>>> Daniel
>>>
>>> On 8/10/11 6:19 PM, Andrew Miller wrote:
>>>> Sorry Pete,
>>>>
>>>> That seems to make things better, but does not solve the issue for me.
>>>>
>>>> Most times this now clean when a client logs in, but about 1 in 10 I
>>>> am still getting an error message. In one case I had 9 error messages
>>>> on one log-in.
>>>>
>>>> Andy.
>>>>
>>>> On 10/08/2011 15:58, Peter Dunkley wrote:
>>>>> 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
>>>>
>>>>
>>>> _______________________________________________
>>>> sr-dev mailing list
>>>> sr-dev at lists.sip-router.org
>>>> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
>>> -- 
>>> Daniel-Constantin Mierla -- http://www.asipto.com
>>> Kamailio Advanced Training, Oct 10-13, Berlin: http://asipto.com/u/kat
>>> http://linkedin.com/in/miconda -- http://twitter.com/miconda
>>>
>>>
>>>
>>> _______________________________________________
>>> sr-dev mailing list
>>> sr-dev at lists.sip-router.org
>>> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
>> _______________________________________________
>> sr-dev mailing list
>> sr-dev at lists.sip-router.org
>> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
>
>
> _______________________________________________
> sr-dev mailing list
> sr-dev at lists.sip-router.org
> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev