7 Apr
2011
7 Apr
'11
12:42 p.m.
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:
--
Peter Dunkley
Technical Director
Crocodile RCS Ltd
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@crocodile-rcs.com SIP/2.0
Via: SIP/2.0/UDP
46.38.172.248;branch=z9hG4bKf89b.b9ec2180000000000000000000000000.0
To: sip:alice@crocodile-rcs.com
From:
sip:bob@crocodile-rcs.com;tag=533cb9e91f4b999cf76861cbb9ed54ed-8c1c
CSeq: 10 SUBSCRIBE
Call-ID: 6c60e3f8-21440(a)127.0.0.1
Content-Length: 0
User-Agent: Crocodile SuperNode 1.1
Max-Forwards: 70
Event: presence
Contact: <sip:rls@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@46.38.172.248:5060 SIP/2.0
Via: SIP/2.0/UDP
127.0.0.1;branch=z9hG4bK7a28.7240a060000000000000000000000000.0
To:
sip:bob@crocodile-rcs.com;tag=533cb9e91f4b999cf76861cbb9ed54ed-8c1c
From:
sip:alice@crocodile-rcs.com;tag=a6a1c5f60faecf035a1ae5b6e96e979a-5cd7
CSeq: 1 NOTIFY
Call-ID: 6c60e3f8-21440(a)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