[sr-dev] Possible bug in RLS module

Peter Dunkley peter.dunkley at crocodile-rcs.com
Thu Apr 7 17:06:52 CEST 2011


Thanks Daniel,

I have tested this change and it is working in my environment.

Peter

On Thu, 2011-04-07 at 12:00 +0200, Daniel-Constantin Mierla wrote:

> 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
> > > >         From:
> > > >         sip:bob at crocodile-rcs.com;tag=533cb9e91f4b999cf76861cbb9ed54ed-8c1c
> > > >         CSeq: 10 SUBSCRIBE
> > > >         Call-ID: 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
> > > >         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


-- 
Peter Dunkley
Technical Director
Crocodile RCS Ltd
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-dev/attachments/20110407/41453a76/attachment.htm>


More information about the sr-dev mailing list