[sr-dev] RLS/PUA concurrency issue

[Daniel-Constantin Mierla]

Hello,

... just few more thoughts since I was offline -- I kind of understood that
the issue was over UDP, with TCP the UA should re-use the connection
(kamailio does it if it is not configured to close the connection
immediately), so the order should be ensured.

Meanwhile, the other soulution would have been to use the new async module,
like:
- if the subscribe dialog does not exist, call async_route() with some sleep
interval (1 sec) which should allow the 200ok to come and be processed

That as a workaround, nicer should be fixed in the code, if Peter did it,
that is great, otherwise I will look over it in the next days -- either with
creation of 'early' dialog on SUBSCRIBE, accept NOTIFY and confirmation on
200ok or a queue to keep a list of pending NOTIFYs for processing.

Cheers,
Daniel

On Thu, Aug 11, 2011 at 9:51 AM, Andrew Miller <
andrew.miller at crocodile-rcs.com> wrote:

> 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
>>>>>>>
>>>>>>> --
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-dev/attachments/20110811/830cb164/attachment.htm>