[sr-dev] Possible bug in RLS module
Peter Dunkley
peter.dunkley at crocodile-rcs.com
Thu Apr 7 11:42:13 CEST 2011
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.
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
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-dev/attachments/20110407/01656c69/attachment.htm>
More information about the sr-dev
mailing list