Folks,
I've been having a bit of a battle with a concurrency issue.
If we have a reasonable number of contacts in an RLS resource list (around 50 does it on my test server), we see a get the following error message thrown up between 2 and 6 times whenever the client logs in. ERROR: rls [resource_notify.c:663]: no presence dialog record for non-TERMINATED state uri pres_uri = sip:0033@lab8.croc.internal watcher_uri = sip:ernie@lab8.croc.internal (I've extended the debug here to include the URIs, so I can see what is not being found)
It is not always the same URIs that go missing, nor is it always the same number of faults.
On investigation this turns out to be a race condition.
subs_cback_func (pua/send_subscribe.c) locks the presentity hash table and inserts a dialog entry when it receives a 200 to the subscribe. rls_handle_notify (rls/resource_notify.c) calls pua_get_record_id (pua/hash.c get_record_id()) which also locks the presentity hash table looks up the dialog.
It seems that in some cases the NOTIFY is getting the lock before the 200 to the SUBSCRIBE. Thus the NOTIFY handler is looking for the dialog before the 200 handler has inserted it.
I attempted to insert a dialog entry in the hash table on sending the SUBSCRIBE, unfortunately this did not cure the problem
Has anyone any suggestions for the cleanest and easiest method to ensure that the 200 is handled before the NOTIFY?
Andy Miller Crocodile RCS
Am 01.08.2011 12:28, schrieb Andrew Miller:
I attempted to insert a dialog entry in the hash table on sending the SUBSCRIBE, unfortunately this did not cure the problem
Has anyone any suggestions for the cleanest and easiest method to ensure that the 200 is handled before the NOTIFY?
The cleanest solution would be to establish the dialog when the NOTIFY is received although the 200 OK is missing.
The NOTIFY can be seen as an implicit 200 OK.
regards Klaus
I've been playing around with this here and making presence and rls use TCP instead of UDP seems to help with this problem. Presumably this is because using TCP enforces in-order delivery of messages.
To make presence and rls use TCP I:
* Added a ;transport=tcp parameter to the SIP URI I had set for presence server_address * Added a ;transport=tcp parameter to the SIP URI I had set for rls server_address * Set the rls outbound_proxy parameter to "sip:127.0.0.1;transport=tcp"
It's not a proper fix, but I think it works around the issue.
Regards,
Peter
On Mon, 2011-08-01 at 13:40 +0200, Klaus Darilion wrote:
Am 01.08.2011 12:28, schrieb Andrew Miller:
I attempted to insert a dialog entry in the hash table on sending the SUBSCRIBE, unfortunately this did not cure the problem
Has anyone any suggestions for the cleanest and easiest method to ensure that the 200 is handled before the NOTIFY?
The cleanest solution would be to establish the dialog when the NOTIFY is received although the 200 OK is missing.
The NOTIFY can be seen as an implicit 200 OK.
regards Klaus
sr-dev mailing list sr-dev@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
Sorry Pete,
That seems to make things better, but does not solve the issue for me.
Most times this now clean when a client logs in, but about 1 in 10 I am still getting an error message. In one case I had 9 error messages on one log-in.
Andy.
On 10/08/2011 15:58, Peter Dunkley wrote:
I've been playing around with this here and making presence and rls use TCP instead of UDP seems to help with this problem. Presumably this is because using TCP enforces in-order delivery of messages.
To make presence and rls use TCP I:
- Added a ;transport=tcp parameter to the SIP URI I had set for presence server_address
- Added a ;transport=tcp parameter to the SIP URI I had set for rls server_address
- Set the rls outbound_proxy parameter to "sip:127.0.0.1;transport=tcp"
It's not a proper fix, but I think it works around the issue.
Regards,
Peter
On Mon, 2011-08-01 at 13:40 +0200, Klaus Darilion wrote:
Am 01.08.2011 12:28, schrieb Andrew Miller:
I attempted to insert a dialog entry in the hash table on sending the SUBSCRIBE, unfortunately this did not cure the problem
Has anyone any suggestions for the cleanest and easiest method to ensure that the 200 is handled before the NOTIFY?
The cleanest solution would be to establish the dialog when the NOTIFY is received although the 200 OK is missing.
The NOTIFY can be seen as an implicit 200 OK.
regards Klaus
sr-dev mailing list sr-dev@lists.sip-router.org mailto:sr-dev@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
-- 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
Hello,
I would like to look closer at the issue and figure out possible solution, but I am traveling for time being, so just quick thoughts.
One approach would the similar solution as for the fast CANCEL (which gets to the server before the INVITE). What we do (in config), we check if there is an INVITE transaction for the CANCEL and if not we just drop the CANCEL (no reply). That will force the UA to do retransmissions, which eventually will come after the INVITE is received/processed.
The second idea would be to have a pending queue, keep the NOTIFY for a while there and when 200ok is coming, look in the queue if it is something for respective dialog. If no dialog is created after a while, request that are older in the queue will be just discarded.
Cheers, Daniel
On 8/10/11 6:19 PM, Andrew Miller wrote:
Sorry Pete,
That seems to make things better, but does not solve the issue for me.
Most times this now clean when a client logs in, but about 1 in 10 I am still getting an error message. In one case I had 9 error messages on one log-in.
Andy.
On 10/08/2011 15:58, Peter Dunkley wrote:
I've been playing around with this here and making presence and rls use TCP instead of UDP seems to help with this problem. Presumably this is because using TCP enforces in-order delivery of messages.
To make presence and rls use TCP I:
- Added a ;transport=tcp parameter to the SIP URI I had set for presence server_address
- Added a ;transport=tcp parameter to the SIP URI I had set for rls server_address
- Set the rls outbound_proxy parameter to "sip:127.0.0.1;transport=tcp"
It's not a proper fix, but I think it works around the issue.
Regards,
Peter
On Mon, 2011-08-01 at 13:40 +0200, Klaus Darilion wrote:
Am 01.08.2011 12:28, schrieb Andrew Miller:
I attempted to insert a dialog entry in the hash table on sending the SUBSCRIBE, unfortunately this did not cure the problem
Has anyone any suggestions for the cleanest and easiest method to ensure that the 200 is handled before the NOTIFY?
The cleanest solution would be to establish the dialog when the NOTIFY is received although the 200 OK is missing.
The NOTIFY can be seen as an implicit 200 OK.
regards Klaus
sr-dev mailing list sr-dev@lists.sip-router.org mailto:sr-dev@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
-- 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
sr-dev mailing list sr-dev@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
Hi Daniel,
Will Kamailio presence retransmit the NOTIFY even if the transport is TCP? I've been working under the assumption that there are no re-transmissions on a reliable transport and (in some cases at least) we may be using TCP.
The idea I am currently working on is to create a partially filled in entry in the hash table when the SUBSCRIBE is sent. This should be just enough for RLS to be able to determine the SUBSCRIBE did for filling in the rls_presentity table when the NOTIFY arrives. This partial entry can be deleted if/when the transaction fails or the 2xx response comes in.
Thanks,
Peter
On Wed, 2011-08-10 at 18:54 +0200, Daniel-Constantin Mierla wrote:
Hello,
I would like to look closer at the issue and figure out possible solution, but I am traveling for time being, so just quick thoughts.
One approach would the similar solution as for the fast CANCEL (which gets to the server before the INVITE). What we do (in config), we check if there is an INVITE transaction for the CANCEL and if not we just drop the CANCEL (no reply). That will force the UA to do retransmissions, which eventually will come after the INVITE is received/processed.
The second idea would be to have a pending queue, keep the NOTIFY for a while there and when 200ok is coming, look in the queue if it is something for respective dialog. If no dialog is created after a while, request that are older in the queue will be just discarded.
Cheers, Daniel
On 8/10/11 6:19 PM, Andrew Miller wrote:
Sorry Pete,
That seems to make things better, but does not solve the issue for me.
Most times this now clean when a client logs in, but about 1 in 10 I am still getting an error message. In one case I had 9 error messages on one log-in.
Andy.
On 10/08/2011 15:58, Peter Dunkley wrote:
I've been playing around with this here and making presence and rls use TCP instead of UDP seems to help with this problem. Presumably this is because using TCP enforces in-order delivery of messages.
To make presence and rls use TCP I: * Added a ;transport=tcp parameter to the SIP URI I had set for presence server_address * Added a ;transport=tcp parameter to the SIP URI I had set for rls server_address * Set the rls outbound_proxy parameter to "sip:127.0.0.1;transport=tcp"
It's not a proper fix, but I think it works around the issue.
Regards,
Peter
On Mon, 2011-08-01 at 13:40 +0200, Klaus Darilion wrote:
Am 01.08.2011 12:28, schrieb Andrew Miller:
I attempted to insert a dialog entry in the hash table on sending the SUBSCRIBE, unfortunately this did not cure the problem
Has anyone any suggestions for the cleanest and easiest method to ensure that the 200 is handled before the NOTIFY?
The cleanest solution would be to establish the dialog when the NOTIFY is received although the 200 OK is missing.
The NOTIFY can be seen as an implicit 200 OK.
regards Klaus
sr-dev mailing list sr-dev@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
-- 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
sr-dev mailing list sr-dev@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
-- Daniel-Constantin Mierla -- http://www.asipto.com Kamailio Advanced Training, Oct 10-13, Berlin: http://asipto.com/u/kat http://linkedin.com/in/miconda -- http://twitter.com/miconda _______________________________________________ sr-dev mailing list sr-dev@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
Am 10.08.2011 18:54, schrieb Daniel-Constantin Mierla:
Hello,
I would like to look closer at the issue and figure out possible solution, but I am traveling for time being, so just quick thoughts.
One approach would the similar solution as for the fast CANCEL (which gets to the server before the INVITE). What we do (in config), we check if there is an INVITE transaction for the CANCEL and if not we just drop the CANCEL (no reply). That will force the UA to do retransmissions, which eventually will come after the INVITE is received/processed.
Does not work with TCP requests.
The second idea would be to have a pending queue, keep the NOTIFY for a while there and when 200ok is coming, look in the queue if it is something for respective dialog. If no dialog is created after a while, request that are older in the queue will be just discarded.
The NOTIFY is in an implicit 200 OK. So if there is an ongoing SUBSCRIBE transaction which matches the NOTIFY, the NOTIFY should trigger the same actions as the 200 OK. The later arriving 200 OK can then be ignored.
regards klaus
Cheers, Daniel
On 8/10/11 6:19 PM, Andrew Miller wrote:
Sorry Pete,
That seems to make things better, but does not solve the issue for me.
Most times this now clean when a client logs in, but about 1 in 10 I am still getting an error message. In one case I had 9 error messages on one log-in.
Andy.
On 10/08/2011 15:58, Peter Dunkley wrote:
I've been playing around with this here and making presence and rls use TCP instead of UDP seems to help with this problem. Presumably this is because using TCP enforces in-order delivery of messages.
To make presence and rls use TCP I:
- Added a ;transport=tcp parameter to the SIP URI I had set for presence server_address
- Added a ;transport=tcp parameter to the SIP URI I had set for rls server_address
- Set the rls outbound_proxy parameter to "sip:127.0.0.1;transport=tcp"
It's not a proper fix, but I think it works around the issue.
Regards,
Peter
On Mon, 2011-08-01 at 13:40 +0200, Klaus Darilion wrote:
Am 01.08.2011 12:28, schrieb Andrew Miller:
I attempted to insert a dialog entry in the hash table on sending the SUBSCRIBE, unfortunately this did not cure the problem
Has anyone any suggestions for the cleanest and easiest method to ensure that the 200 is handled before the NOTIFY?
The cleanest solution would be to establish the dialog when the NOTIFY is received although the 200 OK is missing.
The NOTIFY can be seen as an implicit 200 OK.
regards Klaus
sr-dev mailing list sr-dev@lists.sip-router.org mailto:sr-dev@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
-- 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
sr-dev mailing list sr-dev@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
-- Daniel-Constantin Mierla -- http://www.asipto.com Kamailio Advanced Training, Oct 10-13, Berlin: http://asipto.com/u/kat http://linkedin.com/in/miconda -- http://twitter.com/miconda
sr-dev mailing list sr-dev@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
Klaus,
Sorry we should have mentioned that we did investigate this option, however we do not think it will work.
I may have got the details below wrong, as Peter has been looking at this, however the reason is something like the following:
The main job of the 200 handler is to write a database entry that binds the incoming RLS subscription to the back-end presence subscription. A pointer to the RLS subscription is bound to the INVITE transaction, and is therefore available to the 200 call back function. The same information is not available to the NOTIFY handler - it expects to get this information FROM the database. Therefore, we cannot (unfortunately) handle the NOTIFY in exactly the same way as the 200.
Is that right Peter?
Andy
On 11/08/2011 08:30, Klaus Darilion wrote:
Am 10.08.2011 18:54, schrieb Daniel-Constantin Mierla:
Hello,
I would like to look closer at the issue and figure out possible solution, but I am traveling for time being, so just quick thoughts.
One approach would the similar solution as for the fast CANCEL (which gets to the server before the INVITE). What we do (in config), we check if there is an INVITE transaction for the CANCEL and if not we just drop the CANCEL (no reply). That will force the UA to do retransmissions, which eventually will come after the INVITE is received/processed.
Does not work with TCP requests.
The second idea would be to have a pending queue, keep the NOTIFY for a while there and when 200ok is coming, look in the queue if it is something for respective dialog. If no dialog is created after a while, request that are older in the queue will be just discarded.
The NOTIFY is in an implicit 200 OK. So if there is an ongoing SUBSCRIBE transaction which matches the NOTIFY, the NOTIFY should trigger the same actions as the 200 OK. The later arriving 200 OK can then be ignored.
regards klaus
Cheers, Daniel
On 8/10/11 6:19 PM, Andrew Miller wrote:
Sorry Pete,
That seems to make things better, but does not solve the issue for me.
Most times this now clean when a client logs in, but about 1 in 10 I am still getting an error message. In one case I had 9 error messages on one log-in.
Andy.
On 10/08/2011 15:58, Peter Dunkley wrote:
I've been playing around with this here and making presence and rls use TCP instead of UDP seems to help with this problem. Presumably this is because using TCP enforces in-order delivery of messages.
To make presence and rls use TCP I:
- Added a ;transport=tcp parameter to the SIP URI I had set for presence server_address
- Added a ;transport=tcp parameter to the SIP URI I had set for rls server_address
- Set the rls outbound_proxy parameter to "sip:127.0.0.1;transport=tcp"
It's not a proper fix, but I think it works around the issue.
Regards,
Peter
On Mon, 2011-08-01 at 13:40 +0200, Klaus Darilion wrote:
Am 01.08.2011 12:28, schrieb Andrew Miller:
I attempted to insert a dialog entry in the hash table on sending the SUBSCRIBE, unfortunately this did not cure the problem
Has anyone any suggestions for the cleanest and easiest method to ensure that the 200 is handled before the NOTIFY?
The cleanest solution would be to establish the dialog when the NOTIFY is received although the 200 OK is missing.
The NOTIFY can be seen as an implicit 200 OK.
regards Klaus
sr-dev mailing list sr-dev@lists.sip-router.orgmailto:sr-dev@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
-- 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
sr-dev mailing list sr-dev@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
-- Daniel-Constantin Mierla -- http://www.asipto.com Kamailio Advanced Training, Oct 10-13, Berlin: http://asipto.com/u/kat http://linkedin.com/in/miconda -- http://twitter.com/miconda
sr-dev mailing list sr-dev@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
sr-dev mailing list sr-dev@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
FYI, Just seen an internal e-mail from Peter saying he thinks he has fixed it. I will test this as soon as I get into the office this morning and we will report back
Didn't want anyone putting more time into this if Peter has fixed it.
Andy
On 11/08/2011 08:42, Andrew Miller wrote:
Klaus,
Sorry we should have mentioned that we did investigate this option, however we do not think it will work.
I may have got the details below wrong, as Peter has been looking at this, however the reason is something like the following:
The main job of the 200 handler is to write a database entry that binds the incoming RLS subscription to the back-end presence subscription. A pointer to the RLS subscription is bound to the INVITE transaction, and is therefore available to the 200 call back function. The same information is not available to the NOTIFY handler - it expects to get this information FROM the database. Therefore, we cannot (unfortunately) handle the NOTIFY in exactly the same way as the 200.
Is that right Peter?
Andy
On 11/08/2011 08:30, Klaus Darilion wrote:
Am 10.08.2011 18:54, schrieb Daniel-Constantin Mierla:
Hello,
I would like to look closer at the issue and figure out possible solution, but I am traveling for time being, so just quick thoughts.
One approach would the similar solution as for the fast CANCEL (which gets to the server before the INVITE). What we do (in config), we check if there is an INVITE transaction for the CANCEL and if not we just drop the CANCEL (no reply). That will force the UA to do retransmissions, which eventually will come after the INVITE is received/processed.
Does not work with TCP requests.
The second idea would be to have a pending queue, keep the NOTIFY for a while there and when 200ok is coming, look in the queue if it is something for respective dialog. If no dialog is created after a while, request that are older in the queue will be just discarded.
The NOTIFY is in an implicit 200 OK. So if there is an ongoing SUBSCRIBE transaction which matches the NOTIFY, the NOTIFY should trigger the same actions as the 200 OK. The later arriving 200 OK can then be ignored.
regards klaus
Cheers, Daniel
On 8/10/11 6:19 PM, Andrew Miller wrote:
Sorry Pete,
That seems to make things better, but does not solve the issue for me.
Most times this now clean when a client logs in, but about 1 in 10 I am still getting an error message. In one case I had 9 error messages on one log-in.
Andy.
On 10/08/2011 15:58, Peter Dunkley wrote:
I've been playing around with this here and making presence and rls use TCP instead of UDP seems to help with this problem. Presumably this is because using TCP enforces in-order delivery of messages.
To make presence and rls use TCP I:
- Added a ;transport=tcp parameter to the SIP URI I had set for presence server_address
- Added a ;transport=tcp parameter to the SIP URI I had set for
rls server_address
- Set the rls outbound_proxy parameter to "sip:127.0.0.1;transport=tcp"
It's not a proper fix, but I think it works around the issue.
Regards,
Peter
On Mon, 2011-08-01 at 13:40 +0200, Klaus Darilion wrote:
Am 01.08.2011 12:28, schrieb Andrew Miller: > I attempted to insert a dialog entry in the hash table on > sending the > SUBSCRIBE, unfortunately this did not cure the problem > > Has anyone any suggestions for the cleanest and easiest method > to ensure > that the 200 is handled before the NOTIFY? The cleanest solution would be to establish the dialog when the NOTIFY is received although the 200 OK is missing.
The NOTIFY can be seen as an implicit 200 OK.
regards Klaus
sr-dev mailing list sr-dev@lists.sip-router.orgmailto:sr-dev@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
-- 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
sr-dev mailing list sr-dev@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
-- Daniel-Constantin Mierla -- http://www.asipto.com Kamailio Advanced Training, Oct 10-13, Berlin: http://asipto.com/u/kat http://linkedin.com/in/miconda -- http://twitter.com/miconda
sr-dev mailing list sr-dev@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
sr-dev mailing list sr-dev@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
sr-dev mailing list sr-dev@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
Hello,
... just few more thoughts since I was offline -- I kind of understood that the issue was over UDP, with TCP the UA should re-use the connection (kamailio does it if it is not configured to close the connection immediately), so the order should be ensured.
Meanwhile, the other soulution would have been to use the new async module, like: - if the subscribe dialog does not exist, call async_route() with some sleep interval (1 sec) which should allow the 200ok to come and be processed
That as a workaround, nicer should be fixed in the code, if Peter did it, that is great, otherwise I will look over it in the next days -- either with creation of 'early' dialog on SUBSCRIBE, accept NOTIFY and confirmation on 200ok or a queue to keep a list of pending NOTIFYs for processing.
Cheers, Daniel
On Thu, Aug 11, 2011 at 9:51 AM, Andrew Miller < andrew.miller@crocodile-rcs.com> wrote:
FYI, Just seen an internal e-mail from Peter saying he thinks he has fixed it. I will test this as soon as I get into the office this morning and we will report back
Didn't want anyone putting more time into this if Peter has fixed it.
Andy
On 11/08/2011 08:42, Andrew Miller wrote:
Klaus,
Sorry we should have mentioned that we did investigate this option, however we do not think it will work.
I may have got the details below wrong, as Peter has been looking at this, however the reason is something like the following:
The main job of the 200 handler is to write a database entry that binds the incoming RLS subscription to the back-end presence subscription. A pointer to the RLS subscription is bound to the INVITE transaction, and is therefore available to the 200 call back function. The same information is not available to the NOTIFY handler - it expects to get this information FROM the database. Therefore, we cannot (unfortunately) handle the NOTIFY in exactly the same way as the 200.
Is that right Peter?
Andy
On 11/08/2011 08:30, Klaus Darilion wrote:
Am 10.08.2011 18:54, schrieb Daniel-Constantin Mierla:
Hello,
I would like to look closer at the issue and figure out possible solution, but I am traveling for time being, so just quick thoughts.
One approach would the similar solution as for the fast CANCEL (which gets to the server before the INVITE). What we do (in config), we check if there is an INVITE transaction for the CANCEL and if not we just drop the CANCEL (no reply). That will force the UA to do retransmissions, which eventually will come after the INVITE is received/processed.
Does not work with TCP requests.
The second idea would be to have a pending queue, keep the NOTIFY for a
while there and when 200ok is coming, look in the queue if it is something for respective dialog. If no dialog is created after a while, request that are older in the queue will be just discarded.
The NOTIFY is in an implicit 200 OK. So if there is an ongoing SUBSCRIBE transaction which matches the NOTIFY, the NOTIFY should trigger the same actions as the 200 OK. The later arriving 200 OK can then be ignored.
regards klaus
Cheers,
Daniel
On 8/10/11 6:19 PM, Andrew Miller wrote:
Sorry Pete,
That seems to make things better, but does not solve the issue for me.
Most times this now clean when a client logs in, but about 1 in 10 I am still getting an error message. In one case I had 9 error messages on one log-in.
Andy.
On 10/08/2011 15:58, Peter Dunkley wrote:
I've been playing around with this here and making presence and rls use TCP instead of UDP seems to help with this problem. Presumably this is because using TCP enforces in-order delivery of messages.
To make presence and rls use TCP I:
- Added a ;transport=tcp parameter to the SIP URI I had set for presence server_address
- Added a ;transport=tcp parameter to the SIP URI I had set for rls server_address
- Set the rls outbound_proxy parameter to "sip:127.0.0.1;transport=tcp"
It's not a proper fix, but I think it works around the issue.
Regards,
Peter
On Mon, 2011-08-01 at 13:40 +0200, Klaus Darilion wrote:
> Am 01.08.2011 12:28, schrieb Andrew Miller: > >> I attempted to insert a dialog entry in the hash table on sending >> the >> SUBSCRIBE, unfortunately this did not cure the problem >> >> Has anyone any suggestions for the cleanest and easiest method to >> ensure >> that the 200 is handled before the NOTIFY? >> > The cleanest solution would be to establish the dialog when the > NOTIFY > is received although the 200 OK is missing. > > The NOTIFY can be seen as an implicit 200 OK. > > regards > Klaus > > --
Daniel-Constantin Mierla -- http://www.asipto.com Kamailio Advanced Training, Oct 10-13, Berlin: http://asipto.com/u/kat http://linkedin.com/in/miconda -- http://twitter.com/miconda
Hi,
I have a candidate code fix that I have been testing today. It looks good so far.
If the things continue to go well I will check it into a branch before the end of the day. I'd appreciate it if some others could look over it before I put it back into master.
Thanks,
Peter
On Thu, 2011-08-11 at 15:20 +0200, Daniel-Constantin Mierla wrote:
Hello,
... just few more thoughts since I was offline -- I kind of understood that the issue was over UDP, with TCP the UA should re-use the connection (kamailio does it if it is not configured to close the connection immediately), so the order should be ensured.
Meanwhile, the other soulution would have been to use the new async module, like:
- if the subscribe dialog does not exist, call async_route() with some
sleep interval (1 sec) which should allow the 200ok to come and be processed
That as a workaround, nicer should be fixed in the code, if Peter did it, that is great, otherwise I will look over it in the next days -- either with creation of 'early' dialog on SUBSCRIBE, accept NOTIFY and confirmation on 200ok or a queue to keep a list of pending NOTIFYs for processing.
Cheers, Daniel
On Thu, Aug 11, 2011 at 9:51 AM, Andrew Miller andrew.miller@crocodile-rcs.com wrote:
FYI, Just seen an internal e-mail from Peter saying he thinks he has fixed it. I will test this as soon as I get into the office this morning and we will report back Didn't want anyone putting more time into this if Peter has fixed it. Andy On 11/08/2011 08:42, Andrew Miller wrote: Klaus, Sorry we should have mentioned that we did investigate this option, however we do not think it will work. I may have got the details below wrong, as Peter has been looking at this, however the reason is something like the following: The main job of the 200 handler is to write a database entry that binds the incoming RLS subscription to the back-end presence subscription. A pointer to the RLS subscription is bound to the INVITE transaction, and is therefore available to the 200 call back function. The same information is not available to the NOTIFY handler - it expects to get this information FROM the database. Therefore, we cannot (unfortunately) handle the NOTIFY in exactly the same way as the 200. Is that right Peter? Andy On 11/08/2011 08:30, Klaus Darilion wrote: Am 10.08.2011 18:54, schrieb Daniel-Constantin Mierla: Hello, I would like to look closer at the issue and figure out possible solution, but I am traveling for time being, so just quick thoughts. One approach would the similar solution as for the fast CANCEL (which gets to the server before the INVITE). What we do (in config), we check if there is an INVITE transaction for the CANCEL and if not we just drop the CANCEL (no reply). That will force the UA to do retransmissions, which eventually will come after the INVITE is received/processed. Does not work with TCP requests. The second idea would be to have a pending queue, keep the NOTIFY for a while there and when 200ok is coming, look in the queue if it is something for respective dialog. If no dialog is created after a while, request that are older in the queue will be just discarded. The NOTIFY is in an implicit 200 OK. So if there is an ongoing SUBSCRIBE transaction which matches the NOTIFY, the NOTIFY should trigger the same actions as the 200 OK. The later arriving 200 OK can then be ignored. regards klaus Cheers, Daniel On 8/10/11 6:19 PM, Andrew Miller wrote: Sorry Pete, That seems to make things better, but does not solve the issue for me. Most times this now clean when a client logs in, but about 1 in 10 I am still getting an error message. In one case I had 9 error messages on one log-in. Andy. On 10/08/2011 15:58, Peter Dunkley wrote: I've been playing around with this here and making presence and rls use TCP instead of UDP seems to help with this problem. Presumably this is because using TCP enforces in-order delivery of messages. To make presence and rls use TCP I: * Added a ;transport=tcp parameter to the SIP URI I had set for presence server_address * Added a ;transport=tcp parameter to the SIP URI I had set for rls server_address * Set the rls outbound_proxy parameter to "sip:127.0.0.1;transport=tcp" It's not a proper fix, but I think it works around the issue. Regards, Peter On Mon, 2011-08-01 at 13:40 +0200, Klaus Darilion wrote: Am 01.08.2011 12:28, schrieb Andrew Miller: I attempted to insert a dialog entry in the hash table on sending the SUBSCRIBE, unfortunately this did not cure the problem Has anyone any suggestions for the cleanest and easiest method to ensure that the 200 is handled before the NOTIFY? The cleanest solution would be to establish the dialog when the NOTIFY is received although the 200 OK is missing. The NOTIFY can be seen as an implicit 200 OK. regards Klaus-- Daniel-Constantin Mierla -- http://www.asipto.com Kamailio Advanced Training, Oct 10-13, Berlin: http://asipto.com/u/kat http://linkedin.com/in/miconda -- http://twitter.com/miconda
sr-dev mailing list sr-dev@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
Hello,
I have committed my fix to the pd/pua_fix branch (commit id: b93149c756d3e983c70608938f1142ed43ee1834).
I would appreciate it if some other on this list could look it over before I push it into master.
Thanks,
Peter
On Thu, 2011-08-11 at 15:25 +0100, Peter Dunkley wrote:
Hi,
I have a candidate code fix that I have been testing today. It looks good so far.
If the things continue to go well I will check it into a branch before the end of the day. I'd appreciate it if some others could look over it before I put it back into master.
Thanks,
Peter
On Thu, 2011-08-11 at 15:20 +0200, Daniel-Constantin Mierla wrote:
Hello,
... just few more thoughts since I was offline -- I kind of understood that the issue was over UDP, with TCP the UA should re-use the connection (kamailio does it if it is not configured to close the connection immediately), so the order should be ensured.
Meanwhile, the other soulution would have been to use the new async module, like:
- if the subscribe dialog does not exist, call async_route() with
some sleep interval (1 sec) which should allow the 200ok to come and be processed
That as a workaround, nicer should be fixed in the code, if Peter did it, that is great, otherwise I will look over it in the next days -- either with creation of 'early' dialog on SUBSCRIBE, accept NOTIFY and confirmation on 200ok or a queue to keep a list of pending NOTIFYs for processing.
Cheers, Daniel
On Thu, Aug 11, 2011 at 9:51 AM, Andrew Miller andrew.miller@crocodile-rcs.com wrote:
FYI, Just seen an internal e-mail from Peter saying he thinks he has fixed it. I will test this as soon as I get into the office this morning and we will report back Didn't want anyone putting more time into this if Peter has fixed it. Andy On 11/08/2011 08:42, Andrew Miller wrote: Klaus, Sorry we should have mentioned that we did investigate this option, however we do not think it will work. I may have got the details below wrong, as Peter has been looking at this, however the reason is something like the following: The main job of the 200 handler is to write a database entry that binds the incoming RLS subscription to the back-end presence subscription. A pointer to the RLS subscription is bound to the INVITE transaction, and is therefore available to the 200 call back function. The same information is not available to the NOTIFY handler - it expects to get this information FROM the database. Therefore, we cannot (unfortunately) handle the NOTIFY in exactly the same way as the 200. Is that right Peter? Andy On 11/08/2011 08:30, Klaus Darilion wrote: Am 10.08.2011 18:54, schrieb Daniel-Constantin Mierla: Hello, I would like to look closer at the issue and figure out possible solution, but I am traveling for time being, so just quick thoughts. One approach would the similar solution as for the fast CANCEL (which gets to the server before the INVITE). What we do (in config), we check if there is an INVITE transaction for the CANCEL and if not we just drop the CANCEL (no reply). That will force the UA to do retransmissions, which eventually will come after the INVITE is received/processed. Does not work with TCP requests. The second idea would be to have a pending queue, keep the NOTIFY for a while there and when 200ok is coming, look in the queue if it is something for respective dialog. If no dialog is created after a while, request that are older in the queue will be just discarded. The NOTIFY is in an implicit 200 OK. So if there is an ongoing SUBSCRIBE transaction which matches the NOTIFY, the NOTIFY should trigger the same actions as the 200 OK. The later arriving 200 OK can then be ignored. regards klaus Cheers, Daniel On 8/10/11 6:19 PM, Andrew Miller wrote: Sorry Pete, That seems to make things better, but does not solve the issue for me. Most times this now clean when a client logs in, but about 1 in 10 I am still getting an error message. In one case I had 9 error messages on one log-in. Andy. On 10/08/2011 15:58, Peter Dunkley wrote: I've been playing around with this here and making presence and rls use TCP instead of UDP seems to help with this problem. Presumably this is because using TCP enforces in-order delivery of messages. To make presence and rls use TCP I: * Added a ;transport=tcp parameter to the SIP URI I had set for presence server_address * Added a ;transport=tcp parameter to the SIP URI I had set for rls server_address * Set the rls outbound_proxy parameter to "sip:127.0.0.1;transport=tcp" It's not a proper fix, but I think it works around the issue. Regards, Peter On Mon, 2011-08-01 at 13:40 +0200, Klaus Darilion wrote: Am 01.08.2011 12:28, schrieb Andrew Miller: I attempted to insert a dialog entry in the hash table on sending the SUBSCRIBE, unfortunately this did not cure the problem Has anyone any suggestions for the cleanest and easiest method to ensure that the 200 is handled before the NOTIFY? The cleanest solution would be to establish the dialog when the NOTIFY is received although the 200 OK is missing. The NOTIFY can be seen as an implicit 200 OK. regards Klaus-- Daniel-Constantin Mierla -- http://www.asipto.com Kamailio Advanced Training, Oct 10-13, Berlin: http://asipto.com/u/kat http://linkedin.com/in/miconda -- http://twitter.com/miconda
sr-dev mailing list sr-dev@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
sr-dev mailing list sr-dev@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
Hi Peter,
Indeed the update of tm function should be safe and the rest looks ok.
I was thinking that it may make sense to have a generic function to get the dialog, with a parameter to control if it looks for temporary or confirmed dialogs, then the other functions to get the dialog to be wrappers around this one. It will save one more iteration through the hash table slot. Considering that in this case most of the time the dialog is found, shouldnt be any relevant impact, anyhow.
You can merge from my point of view. Btw, I noticed two branches, puafix and pua_fix.
Cheers, Daniel
On Aug 11, 2011, at 6:47 PM, Peter Dunkley peter.dunkley@crocodile-rcs.com wrote:
Hello,
I have committed my fix to the pd/pua_fix branch (commit id: b93149c756d3e983c70608938f1142ed43ee1834).
I would appreciate it if some other on this list could look it over before I push it into master.
Thanks,
Peter
On Thu, 2011-08-11 at 15:25 +0100, Peter Dunkley wrote:
Hi,
I have a candidate code fix that I have been testing today. It looks good so far.
If the things continue to go well I will check it into a branch before the end of the day. I'd appreciate it if some others could look over it before I put it back into master.
Thanks,
Peter
On Thu, 2011-08-11 at 15:20 +0200, Daniel-Constantin Mierla wrote:
Hello,
... just few more thoughts since I was offline -- I kind of understood that the issue was over UDP, with TCP the UA should re-use the connection (kamailio does it if it is not configured to close the connection immediately), so the order should be ensured.
Meanwhile, the other soulution would have been to use the new async module, like:
- if the subscribe dialog does not exist, call async_route() with some sleep interval (1 sec) which should allow the 200ok to come and be processed
That as a workaround, nicer should be fixed in the code, if Peter did it, that is great, otherwise I will look over it in the next days -- either with creation of 'early' dialog on SUBSCRIBE, accept NOTIFY and confirmation on 200ok or a queue to keep a list of pending NOTIFYs for processing.
Cheers, Daniel
On Thu, Aug 11, 2011 at 9:51 AM, Andrew Miller andrew.miller@crocodile-rcs.com wrote: FYI, Just seen an internal e-mail from Peter saying he thinks he has fixed it. I will test this as soon as I get into the office this morning and we will report back
Didn't want anyone putting more time into this if Peter has fixed it.
Andy
On 11/08/2011 08:42, Andrew Miller wrote: Klaus,
Sorry we should have mentioned that we did investigate this option, however we do not think it will work.
I may have got the details below wrong, as Peter has been looking at this, however the reason is something like the following:
The main job of the 200 handler is to write a database entry that binds the incoming RLS subscription to the back-end presence subscription. A pointer to the RLS subscription is bound to the INVITE transaction, and is therefore available to the 200 call back function. The same information is not available to the NOTIFY handler - it expects to get this information FROM the database. Therefore, we cannot (unfortunately) handle the NOTIFY in exactly the same way as the 200.
Is that right Peter?
Andy
On 11/08/2011 08:30, Klaus Darilion wrote:
Am 10.08.2011 18:54, schrieb Daniel-Constantin Mierla: Hello,
I would like to look closer at the issue and figure out possible solution, but I am traveling for time being, so just quick thoughts.
One approach would the similar solution as for the fast CANCEL (which gets to the server before the INVITE). What we do (in config), we check if there is an INVITE transaction for the CANCEL and if not we just drop the CANCEL (no reply). That will force the UA to do retransmissions, which eventually will come after the INVITE is received/processed. Does not work with TCP requests.
The second idea would be to have a pending queue, keep the NOTIFY for a while there and when 200ok is coming, look in the queue if it is something for respective dialog. If no dialog is created after a while, request that are older in the queue will be just discarded. The NOTIFY is in an implicit 200 OK. So if there is an ongoing SUBSCRIBE transaction which matches the NOTIFY, the NOTIFY should trigger the same actions as the 200 OK. The later arriving 200 OK can then be ignored.
regards klaus
Cheers, Daniel
On 8/10/11 6:19 PM, Andrew Miller wrote: Sorry Pete,
That seems to make things better, but does not solve the issue for me.
Most times this now clean when a client logs in, but about 1 in 10 I am still getting an error message. In one case I had 9 error messages on one log-in.
Andy.
On 10/08/2011 15:58, Peter Dunkley wrote: I've been playing around with this here and making presence and rls use TCP instead of UDP seems to help with this problem. Presumably this is because using TCP enforces in-order delivery of messages.
To make presence and rls use TCP I:
- Added a ;transport=tcp parameter to the SIP URI I had set for presence server_address
- Added a ;transport=tcp parameter to the SIP URI I had set for rls server_address
- Set the rls outbound_proxy parameter to "sip:127.0.0.1;transport=tcp"
It's not a proper fix, but I think it works around the issue.
Regards,
Peter
On Mon, 2011-08-01 at 13:40 +0200, Klaus Darilion wrote: Am 01.08.2011 12:28, schrieb Andrew Miller: I attempted to insert a dialog entry in the hash table on sending the SUBSCRIBE, unfortunately this did not cure the problem
Has anyone any suggestions for the cleanest and easiest method to ensure that the 200 is handled before the NOTIFY? The cleanest solution would be to establish the dialog when the NOTIFY is received although the 200 OK is missing.
The NOTIFY can be seen as an implicit 200 OK.
regards Klaus
-- Daniel-Constantin Mierla -- http://www.asipto.com Kamailio Advanced Training, Oct 10-13, Berlin: http://asipto.com/u/kat http://linkedin.com/in/miconda -- http://twitter.com/miconda
sr-dev mailing list sr-dev@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
sr-dev mailing list sr-dev@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
-- 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 will merge back to master now.
There are two branches because I had some finger trouble. Sorry about that.
Thanks,
Peter
On Fri, 2011-08-12 at 17:55 +0200, Daniel-Constantine Mierla wrote:
Hi Peter,
Indeed the update of tm function should be safe and the rest looks ok.
I was thinking that it may make sense to have a generic function to get the dialog, with a parameter to control if it looks for temporary or confirmed dialogs, then the other functions to get the dialog to be wrappers around this one. It will save one more iteration through the hash table slot. Considering that in this case most of the time the dialog is found, shouldnt be any relevant impact, anyhow.
You can merge from my point of view. Btw, I noticed two branches, puafix and pua_fix.
Cheers, Daniel
On Aug 11, 2011, at 6:47 PM, Peter Dunkley peter.dunkley@crocodile-rcs.com wrote:
Hello,
I have committed my fix to the pd/pua_fix branch (commit id: b93149c756d3e983c70608938f1142ed43ee1834).
I would appreciate it if some other on this list could look it over before I push it into master.
Thanks,
Peter
On Thu, 2011-08-11 at 15:25 +0100, Peter Dunkley wrote:
Hi,
I have a candidate code fix that I have been testing today. It looks good so far.
If the things continue to go well I will check it into a branch before the end of the day. I'd appreciate it if some others could look over it before I put it back into master.
Thanks,
Peter
On Thu, 2011-08-11 at 15:20 +0200, Daniel-Constantin Mierla wrote:
Hello,
... just few more thoughts since I was offline -- I kind of understood that the issue was over UDP, with TCP the UA should re-use the connection (kamailio does it if it is not configured to close the connection immediately), so the order should be ensured.
Meanwhile, the other soulution would have been to use the new async module, like:
- if the subscribe dialog does not exist, call async_route()
with some sleep interval (1 sec) which should allow the 200ok to come and be processed
That as a workaround, nicer should be fixed in the code, if Peter did it, that is great, otherwise I will look over it in the next days -- either with creation of 'early' dialog on SUBSCRIBE, accept NOTIFY and confirmation on 200ok or a queue to keep a list of pending NOTIFYs for processing.
Cheers, Daniel
On Thu, Aug 11, 2011 at 9:51 AM, Andrew Miller andrew.miller@crocodile-rcs.com wrote:
FYI, Just seen an internal e-mail from Peter saying he thinks he has fixed it. I will test this as soon as I get into the office this morning and we will report back Didn't want anyone putting more time into this if Peter has fixed it. Andy On 11/08/2011 08:42, Andrew Miller wrote: Klaus, Sorry we should have mentioned that we did investigate this option, however we do not think it will work. I may have got the details below wrong, as Peter has been looking at this, however the reason is something like the following: The main job of the 200 handler is to write a database entry that binds the incoming RLS subscription to the back-end presence subscription. A pointer to the RLS subscription is bound to the INVITE transaction, and is therefore available to the 200 call back function. The same information is not available to the NOTIFY handler - it expects to get this information FROM the database. Therefore, we cannot (unfortunately) handle the NOTIFY in exactly the same way as the 200. Is that right Peter? Andy On 11/08/2011 08:30, Klaus Darilion wrote: Am 10.08.2011 18:54, schrieb Daniel-Constantin Mierla: Hello, I would like to look closer at the issue and figure out possible solution, but I am traveling for time being, so just quick thoughts. One approach would the similar solution as for the fast CANCEL (which gets to the server before the INVITE). What we do (in config), we check if there is an INVITE transaction for the CANCEL and if not we just drop the CANCEL (no reply). That will force the UA to do retransmissions, which eventually will come after the INVITE is received/processed. Does not work with TCP requests. The second idea would be to have a pending queue, keep the NOTIFY for a while there and when 200ok is coming, look in the queue if it is something for respective dialog. If no dialog is created after a while, request that are older in the queue will be just discarded. The NOTIFY is in an implicit 200 OK. So if there is an ongoing SUBSCRIBE transaction which matches the NOTIFY, the NOTIFY should trigger the same actions as the 200 OK. The later arriving 200 OK can then be ignored. regards klaus Cheers, Daniel On 8/10/11 6:19 PM, Andrew Miller wrote: Sorry Pete, That seems to make things better, but does not solve the issue for me. Most times this now clean when a client logs in, but about 1 in 10 I am still getting an error message. In one case I had 9 error messages on one log-in. Andy. On 10/08/2011 15:58, Peter Dunkley wrote: I've been playing around with this here and making presence and rls use TCP instead of UDP seems to help with this problem. Presumably this is because using TCP enforces in-order delivery of messages. To make presence and rls use TCP I: * Added a ;transport=tcp parameter to the SIP URI I had set for presence server_address * Added a ;transport=tcp parameter to the SIP URI I had set for rls server_address * Set the rls outbound_proxy parameter to "sip:127.0.0.1;transport=tcp" It's not a proper fix, but I think it works around the issue. Regards, Peter On Mon, 2011-08-01 at 13:40 +0200, Klaus Darilion wrote: Am 01.08.2011 12:28, schrieb Andrew Miller: I attempted to insert a dialog entry in the hash table on sending the SUBSCRIBE, unfortunately this did not cure the problem Has anyone any suggestions for the cleanest and easiest method to ensure that the 200 is handled before the NOTIFY? The cleanest solution would be to establish the dialog when the NOTIFY is received although the 200 OK is missing. The NOTIFY can be seen as an implicit 200 OK. regards Klaus-- Daniel-Constantin Mierla -- http://www.asipto.com Kamailio Advanced Training, Oct 10-13, Berlin: http://asipto.com/u/kat http://linkedin.com/in/miconda -- http://twitter.com/miconda
sr-dev mailing list sr-dev@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
sr-dev mailing list sr-dev@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
-- 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
sr-dev mailing list sr-dev@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
Am 11.08.2011 15:20, schrieb Daniel-Constantin Mierla:
Hello,
... just few more thoughts since I was offline -- I kind of understood that the issue was over UDP, with TCP the UA should re-use the connection (kamailio does it if it is not configured to close the connection immediately), so the order should be ensured.
TCP ensures only the order of the messages over the network. Even here it can happen that the seconds message is processed first (process scheduler)
regards klaus
it still may happen: 200 OK is received and handled over to TCP worker process A NOTIFY is received and handled over to TCP worker process B scheduler puts process A on hold and gives resources to B
so NOTIFY still may overtake 200 OK.
regards Klaus
Am 10.08.2011 16:58, schrieb Peter Dunkley:
I've been playing around with this here and making presence and rls use TCP instead of UDP seems to help with this problem. Presumably this is because using TCP enforces in-order delivery of messages.
To make presence and rls use TCP I:
- Added a ;transport=tcp parameter to the SIP URI I had set for presence server_address
- Added a ;transport=tcp parameter to the SIP URI I had set for rls server_address
- Set the rls outbound_proxy parameter to "sip:127.0.0.1;transport=tcp"
It's not a proper fix, but I think it works around the issue.
Regards,
Peter
On Mon, 2011-08-01 at 13:40 +0200, Klaus Darilion wrote:
Am 01.08.2011 12:28, schrieb Andrew Miller:
I attempted to insert a dialog entry in the hash table on sending the SUBSCRIBE, unfortunately this did not cure the problem
Has anyone any suggestions for the cleanest and easiest method to ensure that the 200 is handled before the NOTIFY?
The cleanest solution would be to establish the dialog when the NOTIFY is received although the 200 OK is missing.
The NOTIFY can be seen as an implicit 200 OK.
regards Klaus
sr-dev mailing list sr-dev@lists.sip-router.org mailto:sr-dev@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
-- 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
-
Andrew Miller -
Daniel-Constantin Mierla -
Daniel-Constantine Mierla
-
Klaus Darilion -
Peter Dunkley