[sr-dev] Possible bug in RLS module

[Daniel-Constantin Mierla]

Hi Peter,

On 4/7/11 11:42 AM, Peter Dunkley wrote:
> Hi Daniel,
>
> This SUBSCRIBE is a back-end SUBSCRIBE generated by RLS and directed 
> to PRESENCE.
>
> The RLS module sends that SUBSCRIBE and gets a 202 back from 
> PRESENCE.  The PRESENCE module is then sending that NOTIFY back to the 
> RLS module after the unSUBSCRIBE is complete.
ok, now I have the proper message flow.

> So:
> - Either the PRESENCE module should not send this NOTIFY to the RLS 
> after the unSUBSCRIBE, or
> - The RLS module should be prepared to receive a NOTIFY from PRESENCE 
> after the unSUBSCRIBE

Perhaps the best will be to have delayed delete of un-SUBSCRIBEd 
dialogs. The quick solution is to reply 200ok for NOTIFY requests with 
state terminated. I will make a patch for the later.

Thanks,
Daniel

>
> Thanks,
>
> Peter
>
> On Thu, 2011-04-07 at 11:34 +0200, Daniel-Constantin Mierla wrote:
>> Hi Peter,
>>
>> On 4/4/11 3:39 PM, Peter Dunkley wrote:
>>> Hello Daniel,
>>>
>>> I have looked into the new error message.  I now get:
>>>
>>>     7(21352) ERROR: rls [resource_notify.c:250]: record not found
>>>
>>> This looks very similar to the previous issue.  What appears to be 
>>> happening is that the RLS is successfully un-subscribing from the 
>>> presence module with a SUBSCRIBE that looks like:
>>>
>>>     SUBSCRIBE sip:alice at crocodile-rcs.com SIP/2.0
>>>     Via: SIP/2.0/UDP
>>>     46.38.172.248;branch=z9hG4bKf89b.b9ec2180000000000000000000000000.0
>>>     To: sip:alice at crocodile-rcs.com <sip:alice at crocodile-rcs.com.>
>>>     From:
>>>     sip:bob at crocodile-rcs.com;tag=533cb9e91f4b999cf76861cbb9ed54ed-8c1c
>>>     CSeq: 10 SUBSCRIBE
>>>     Call-ID: 6c60e3f8-21440 at 127.0.0.1 <mailto:6c60e3f8-21440 at 127.0.0.1.>
>>>     Content-Length: 0
>>>     User-Agent: Crocodile SuperNode 1.1
>>>     Max-Forwards: 70
>>>     Event: presence
>>>     Contact: <sip:rls at 46.38.172.248:5060>
>>>     Expires: 0
>>>     Supported: eventlist
>>>     Accept: application/pidf+xml, application/rlmi+xml,
>>>     application/watcherinfo+xml, multipart/related
>>>
>>>
>>> After accepting (with 202) this SUBSCRIBE the presence module tries 
>>> to send a NOTIFY back to the RLS module:
>>>
>>>     NOTIFY sip:rls at 46.38.172.248:5060 SIP/2.0
>>>     Via: SIP/2.0/UDP
>>>     127.0.0.1;branch=z9hG4bK7a28.7240a060000000000000000000000000.0
>>>     To:
>>>     sip:bob at crocodile-rcs.com;tag=533cb9e91f4b999cf76861cbb9ed54ed-8c1c
>>>     From:
>>>     sip:alice at crocodile-rcs.com;tag=a6a1c5f60faecf035a1ae5b6e96e979a-5cd7
>>>     CSeq: 1 NOTIFY
>>>     Call-ID: 6c60e3f8-21440 at 127.0.0.1 <mailto:6c60e3f8-21440 at 127.0.0.1.>
>>>     Content-Length: 0
>>>     User-Agent: Crocodile SuperNode 1.1
>>>     Max-Forwards: 70
>>>     Event: presence
>>>     Contact: <sip:127.0.0.1:5060;transport=udp>
>>>     Subscription-State: terminated;reason=timeout
>>>
>>> This NOTIFY is passed into the RLS module using rls_handle_notify() 
>>> and the error message from above appears in the log file.  There is 
>>> no final response sent to the NOTIFY so the error message appears 
>>> repeatedly for 32 seconds until the presence module times out.
>>>
>>> I think there are two issues here:
>>>
>>>     * After completing the unSUBSCRIBE the RLS module removes the
>>>       dialog from the hash table.  This means that the NOTIFY from
>>>       presence doesn't match a dialog - hence the error message.
>>>
>> is this SBSCRIBE request handled by RLS module, not by presence (ie, 
>> it is for a resource list or for an user)?
>>
>>>     * rls_handle_notify() does not send an Fxx (or at least does not
>>>       in this case) when it receives a validly formed NOTIFY that
>>>       still causes an error.
>>>
>>>
>>> Can you suggest a work-around?
>> rls_handle_notify() sends 200ok only when returning true to config. 
>> In this case, since it hasn't found the proper dialog, will return false.
>>
>> Try:
>>
>> if(!rls_handle_notify()) {
>>    send_reply("404", "Not found");
>>   exit;
>> }
>>
>> Perhaps will be nicer to differentiate between the cases of internal 
>> error, whether it is some server fault (e.g., out of memory, broken 
>> db connection) or the dialog is not found, to be able to send back 
>> either 500 or 404.
>>
>> Cheers,
>> Daniel
>> -- 
>> Daniel-Constantin Mierla
>> http://www.asipto.com
>
> -- 
> Peter Dunkley
> Technical Director
> Crocodile RCS Ltd
>

-- 
Daniel-Constantin Mierla
http://www.asipto.com

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-dev/attachments/20110407/7befaa15/attachment.htm>