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
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_subscribeI 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@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
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:
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?
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
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:
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?
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@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
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
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@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@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
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
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 foundThis 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@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/relatedAfter 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@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=timeoutThis 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
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 foundThis 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@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/relatedAfter 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@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=timeoutThis 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
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 foundThis 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@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/relatedAfter 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@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=timeoutThis 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
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 notfound
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@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/relatedAfter 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@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=timeoutThis 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
-
Daniel-Constantin Mierla -
Peter Dunkley