<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 TRANSITIONAL//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; CHARSET=UTF-8">
<META NAME="GENERATOR" CONTENT="GtkHTML/4.0.1">
</HEAD>
<BODY TEXT="#000000" BGCOLOR="#ffffff">
Hi Daniel,<BR>
<BR>
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.<BR>
<BR>
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.<BR>
<BR>
Thanks,<BR>
<BR>
Peter<BR>
<BR>
On Wed, 2011-08-10 at 18:54 +0200, Daniel-Constantin Mierla wrote:<BR>
<BLOCKQUOTE TYPE=CITE>
Hello,<BR>
<BR>
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.<BR>
<BR>
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.<BR>
<BR>
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.<BR>
<BR>
Cheers,<BR>
Daniel<BR>
<BR>
On 8/10/11 6:19 PM, Andrew Miller wrote: <BR>
<BLOCKQUOTE TYPE=CITE>
Sorry Pete,<BR>
<BR>
That seems to make things better, but does not solve the issue for me.<BR>
<BR>
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.<BR>
<BR>
Andy.<BR>
<BR>
On 10/08/2011 15:58, Peter Dunkley wrote: <BR>
<BLOCKQUOTE TYPE=CITE>
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.<BR>
<BR>
To make presence and rls use TCP I:
<UL>
<LI>Added a ;transport=tcp parameter to the SIP URI I had set for presence server_address
<LI>Added a ;transport=tcp parameter to the SIP URI I had set for rls server_address
<LI>Set the rls outbound_proxy parameter to <A HREF="sip:127.0.0.1;transport=tcp">"sip:127.0.0.1;transport=tcp"</A>
</UL>
<BR>
It's not a proper fix, but I think it works around the issue.<BR>
<BR>
Regards,<BR>
<BR>
Peter<BR>
<BR>
On Mon, 2011-08-01 at 13:40 +0200, Klaus Darilion wrote:
<BLOCKQUOTE TYPE=CITE>
<PRE>
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
<A HREF="mailto:sr-dev@lists.sip-router.org">sr-dev@lists.sip-router.org</A>
<A HREF="http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev">http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev</A>
</PRE>
</BLOCKQUOTE>
<BR>
<TABLE>
<TR>
<TD>
<PRE>
--
Peter Dunkley
Technical Director
Crocodile RCS Ltd
</PRE>
</TD>
</TR>
</TABLE>
<BR>
<BR>
<PRE>
_______________________________________________
sr-dev mailing list
<A HREF="mailto:sr-dev@lists.sip-router.org">sr-dev@lists.sip-router.org</A>
<A HREF="http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev">http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev</A>
</PRE>
</BLOCKQUOTE>
<BR>
<BR>
<BR>
<PRE>
_______________________________________________
sr-dev mailing list
<A HREF="mailto:sr-dev@lists.sip-router.org">sr-dev@lists.sip-router.org</A>
<A HREF="http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev">http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev</A>
</PRE>
</BLOCKQUOTE>
<BR>
<PRE>
--
Daniel-Constantin Mierla -- <A HREF="http://www.asipto.com">http://www.asipto.com</A>
Kamailio Advanced Training, Oct 10-13, Berlin: <A HREF="http://asipto.com/u/kat">http://asipto.com/u/kat</A>
<A HREF="http://linkedin.com/in/miconda">http://linkedin.com/in/miconda</A> -- <A HREF="http://twitter.com/miconda">http://twitter.com/miconda</A>
_______________________________________________
sr-dev mailing list
<A HREF="mailto:sr-dev@lists.sip-router.org">sr-dev@lists.sip-router.org</A>
<A HREF="http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev">http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev</A>
</PRE>
</BLOCKQUOTE>
<BR>
<TABLE CELLSPACING="0" CELLPADDING="0" WIDTH="100%">
<TR>
<TD>
<PRE>
--
Peter Dunkley
Technical Director
Crocodile RCS Ltd
</PRE>
</TD>
</TR>
</TABLE>
</BODY>
</HTML>