[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