29 Mar
2011
29 Mar
'11
5:10 p.m.
Hello,
I think I may have found a bug in the RLS module.
Take two subscribers (alice and bob) who have each other in their
contact lists. Log them in (so REGISTER, SUBSCRIBE(presence.winfo),
SUBSCRIBE(presence), PUBLISH, and so on). Log one (bob) out. bob's
status remains online in alice's client. Restart alice's client
(logging her out and in again). bob's status is still shown as online.
Has anyone encountered this before?
I think it might be related to some errors I am seeing. When my client
unSUBSCRIBEs on sign-out I get the following errors (the line numbers
may be slightly out from the base 3.1.2 version as I added some
diagnostics to try and find the problem):
Mar 29 13:57:51 supernode /usr/sbin/kamailio[20259]: ERROR: rls
[notify.c:280]: updating in hash table
Mar 29 13:57:51 supernode /usr/sbin/kamailio[20259]: ERROR: rls
[notify.c:150]: in function agg_body_sendn_update
Mar 29 13:57:51 supernode /usr/sbin/kamailio[20259]: ERROR: rls
[subscribe.c:638]: failed sending full state notify
Mar 29 13:57:51 supernode /usr/sbin/kamailio[20259]: ERROR: rls
[subscribe.c:678]: occured in rls_handle_subscribe
I believe this is happening because send_full_notify() is called after
update_rlsubs() is called in rls_handle_subscribe(). update_rlsubs()
will delete the entry from the hash table when "Expires: 0" is set - as
is the case for an unSUBSCRIBE.
Can anyone suggest what the correct behaviour should be?
Thanks,
Peter
30 Mar
30 Mar
5:49 p.m.
Hello,
On 3/29/11 4:10 PM, Peter Dunkley wrote:
Hello,
I think I may have found a bug in the RLS module.
Take two subscribers (alice and bob) who have each other in their
contact lists. Log them in (so REGISTER, SUBSCRIBE(presence.winfo),
SUBSCRIBE(presence), PUBLISH, and so on). Log one (bob) out. bob's
status remains online in alice's client. Restart alice's client
(logging her out and in again). bob's status is still shown as online.
Has anyone encountered this before?
to understand properly, bob's presence
document is deleted when he
logged out, but alice still sees bob online after her client is logged
out and then logged in?
Is this happening all the time when doing such operations?
I will try to check the sources, the module was hard to test without a
SIP client supporting rls properly and reproducing what you say is not
trivial as well because of the same reasons.
Cheers,
Daniel
I think it might be related to some errors I am seeing. When my
client unSUBSCRIBEs on sign-out I get the following errors (the line
numbers may be slightly out from the base 3.1.2 version as I added
some diagnostics to try and find the problem):
Mar 29 13:57:51 supernode /usr/sbin/kamailio[20259]: ERROR: rls
[notify.c:280]: updating in hash table
Mar 29 13:57:51 supernode /usr/sbin/kamailio[20259]: ERROR: rls
[notify.c:150]: in function agg_body_sendn_update
Mar 29 13:57:51 supernode /usr/sbin/kamailio[20259]: ERROR: rls
[subscribe.c:638]: failed sending full state notify
Mar 29 13:57:51 supernode /usr/sbin/kamailio[20259]: ERROR: rls
[subscribe.c:678]: occured in rls_handle_subscribe
I believe this is happening because send_full_notify() is called after
update_rlsubs() is called in rls_handle_subscribe(). update_rlsubs()
will delete the entry from the hash table when "Expires: 0" is set -
as is the case for an unSUBSCRIBE.
Can anyone suggest what the correct behaviour should be?
Thanks,
Peter
_______________________________________________
sr-dev mailing list
sr-dev(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
--
Daniel-Constantin Mierla
http://www.asipto.com
6:24 p.m.
Hello,
On Wed, 2011-03-30 at 16:49 +0200, Daniel-Constantin Mierla wrote:
Hello,
On 3/29/11 4:10 PM, Peter Dunkley wrote:
When bob logs out alice still sees him as online. This happens every
time.
If alice then logs out and logs back in immediately she sees bob as
still online.
If alice logs out, waits a while, and then logs back in she sees bob as
offline.
I think:
- The issue I'm encountering stops alice getting the correct NOTIFY when
bob goes offline and (possibly) stops the database being correctly
updated.
- The database does get "fixed" eventually as presence states time-out.
Thanks,
Peter
--
Peter Dunkley
Technical Director
Crocodile RCS Ltd
Hello,
I think I may have found a bug in the RLS module.
Take two subscribers (alice and bob) who have each other in their
contact lists. Log them in (so REGISTER, SUBSCRIBE(presence.winfo),
SUBSCRIBE(presence), PUBLISH, and so on). Log one (bob) out. bob's
status remains online in alice's client. Restart alice's client
(logging her out and in again). bob's status is still shown as
online.
Has anyone encountered this before?
to understand properly, bob's presence document is deleted when he
logged out, but alice still sees bob online after her client is logged
out and then logged in?
1 Apr
1 Apr
1:22 p.m.
Hi Peter,
can you fetch the latest git of branch 3.1 and try again the scenario? I
broke the update_rlsubs() in two functions, so that deletion from hash
table can be done later, after sending the notify requests.
Let me know if it work now for you.
Thanks,
Daniel
On 3/30/11 5:24 PM, Peter Dunkley wrote:
Hello,
On Wed, 2011-03-30 at 16:49 +0200, Daniel-Constantin Mierla wrote:
--
Daniel-Constantin Mierla
http://www.asipto.com
Hello,
On 3/29/11 4:10 PM, Peter Dunkley wrote:
When bob logs out alice still sees him as online. This happens every
time.
If alice then logs out and logs back in immediately she sees bob as
still online.
If alice logs out, waits a while, and then logs back in she sees bob
as offline.
I think:
- The issue I'm encountering stops alice getting the correct NOTIFY
when bob goes offline and (possibly) stops the database being
correctly updated.
- The database does get "fixed" eventually as presence states time-out.
Thanks,
Peter
--
Peter Dunkley
Technical Director
Crocodile RCS Ltd
_______________________________________________
sr-dev mailing list
sr-dev(a)lists.sip-router.org
http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev Hello,
I think I may have found a bug in the RLS module.
Take two subscribers (alice and bob) who have each other in their
contact lists. Log them in (so REGISTER, SUBSCRIBE(presence.winfo),
SUBSCRIBE(presence), PUBLISH, and so on). Log one (bob) out. bob's
status remains online in alice's client. Restart alice's client
(logging her out and in again). bob's status is still shown as online.
Has anyone encountered this before?
to understand properly, bob's presence
document is deleted when he
logged out, but alice still sees bob online after her client is
logged out and then logged in?
3 Apr
3 Apr
8:33 p.m.
Hi Daniel,
I've tried out the latest branch 3.1 and the issue I reported is fixed. I
am now getting a different error message - but this may have something to
do with the other changes to RLS that I am working on.
I'll investigate this further and let you know what I find.
Thanks for your help.
Peter
Hi Peter,
can you fetch the latest git of branch 3.1 and try again the scenario? I
broke the update_rlsubs() in two functions, so that deletion from hash
table can be done later, after sending the notify requests.
Let me know if it work now for you.
Thanks,
Daniel
--
Peter Dunkley
Technical Director
Crocodile RCS Ltd
4 Apr
4 Apr
4:39 p.m.
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.
* 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?
Regards,
Peter
On Sun, 2011-04-03 at 18:33 +0100, Peter Dunkley wrote:
Hi Daniel,
I've tried out the latest branch 3.1 and the issue I reported is fixed. I
am now getting a different error message - but this may have something to
do with the other changes to RLS that I am working on.
I'll investigate this further and let you know what I find.
Thanks for your help.
Peter
--
Peter Dunkley
Technical Director
Crocodile RCS Ltd
Hi Peter,
can you fetch the latest git of branch 3.1 and try again the scenario? I
broke the update_rlsubs() in two functions, so that deletion from hash
table can be done later, after sending the notify requests.
Let me know if it work now for you.
Thanks,
Daniel
7 Apr
7 Apr
12:34 p.m.
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@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 <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 <mailto:6c60e3f8-21440@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 <mailto:6c60e3f8-21440@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
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
1 p.m.
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:
--
Daniel-Constantin Mierla
http://www.asipto.com
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 <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 <mailto:6c60e3f8-21440@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 <mailto:6c60e3f8-21440@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
6:06 p.m.
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:
--
Peter Dunkley
Technical Director
Crocodile RCS Ltd
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:
--
Daniel-Constantin Mierla
http://www.asipto.com 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
4978
days inactive
4987
days old
9 comments
2 participants
participants (2)
-
Daniel-Constantin Mierla -
Peter Dunkley