<html><head><meta http-equiv="Content-Type" content="text/html charset=iso-8859-1"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>10 jan 2013 kl. 11:50 skrev Richard Brady <<a href="mailto:rnbrady@gmail.com">rnbrady@gmail.com</a>>:</div><br class="Apple-interchange-newline"><blockquote type="cite">Also can a flow fail temporarily? <div><br></div><div>For example a broadband router with a NAT timeout of 60 seconds and a UA with a keep-alive interval of 120s. Would the flow succeed for the first 60 seconds after each keep-alive and then fail for 60 seconds until the next keepalive? </div></blockquote>Yes. That's a misconfigured ua, isn't it... The UA will have to make sure to manage connections properly so at least one of the two are always open and working...</div><div>Outbound is all about pushing responsiblity for the flows to the UA.</div><div><br><blockquote type="cite">
<div><br></div><div>And would this generate a 430 or would it generate a different response code?</div><div><br></div><div>On the other hand this quote from the RFC makes it sounds like 430 represents a permanent condition:</div>
<div><br></div><div> If the flow no longer exists, the proxy SHOULD</div><div> send a 430 (Flow Failed) response to the request.</div></blockquote><div><br></div>Well, Outbound is very focused on TCP. It's alive or dead. It doesn't behave like UDP.</div><div><br></div><div>/O<br><blockquote type="cite"><div><br></div><div>Richard</div><div><br></div><div><div class="gmail_quote">On 8 January 2013 09:55, Olle E Johanson <span dir="ltr"><<a href="mailto:olle@ozone.webway.se" target="_blank">olle@ozone.webway.se</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word"><br><div><div>8 jan 2013 kl. 10:43 skrev Peter Dunkley <<a href="mailto:peter.dunkley@crocodile-rcs.com" target="_blank">peter.dunkley@crocodile-rcs.com</a>>:</div>
<div class="im"><br><blockquote type="cite">
<div>
Hi Juha,<br>
<br>
A few months ago there was a discussion on IRC and the sr-dev list about what is needed for outbound. This requirement to remove broken contacts was presented then by someone as something that (although not explicit in the RFC) is needed.<br>
</div></blockquote><br></div></div><div>Just a clarification:</div><div><br></div><div>Section 9.3 says that </div><div>"<span style="font-size:1em">Bob's authoritative proxy first tries the flow to EP1,</span><pre style="font-size:1em;margin-top:0px;margin-bottom:0px"><span style="font-size:1em"> but EP1 no longer has a flow to Bob, so it responds with a 430 (Flow</span></pre><div class="im"><pre style="font-size:1em;margin-top:0px;margin-bottom:0px"> Failed) response. The proxy removes the stale registration and tries
the next binding for the same instance."</pre><div><br></div></div><div>But it is not mentioned in the server handling section of the Outbound RFC.</div><span class="HOEnZb"><font color="#888888"><div><br></div><div>
/O</div></font></span><div><div class="h5"><div><br></div><blockquote type="cite"><div>
<br>
If a flow is broken, particularly one over TCP where the connection is established from the UAC to the edge proxy, then it will never work again. As such it is extremely wasteful to continue to try and use that flow (in preference to one that will work) for each new dialog forming request. Further, as re-REGISTER times can be quite long, not removing broken contacts could lead to a significant/growing number of dead contacts (all of which will be tried for each new dialog forming request) in the location table.<br>
<br>
There is an unregister() function in the registrar module, there are also the reg_(fetch|free)_contacts() functions in the registrar module. None of these appear to do quite what is required.<br>
<br>
Peter<br>
<br>
<br>
On Tue, 2013-01-08 at 04:46 +0200, Juha Heinanen wrote:
<blockquote type="CITE">
<pre>Peter Dunkley writes:
> One requirement of an outbound capable registrar is that if a flow fails
> (edge proxy returns a 430) the registrar should realise that the flow is
> now dead and remove that contact binding from its database so it is not
> used again as well as trying the next contact. I can't see anything that
> will do this? Is this missing?
peter,
i didn't find in rfc5626 a requirement that registrar should remove 430
flow contact, but, if there is such a requirement, in my opinion removal
should be done from failure route in the script by a function that
removes the contact.
a similar thing was discussed a while back (see below).
-- juha
From: Juha Heinanen <<a href="mailto:jh@tutpro.com" target="_blank">jh@tutpro.com</a>>
Sender: <a href="mailto:sr-dev-bounces@lists.sip-router.org" target="_blank">sr-dev-bounces@lists.sip-router.org</a>
To: <a href="mailto:sr-dev@lists.sip-router.org" target="_blank">sr-dev@lists.sip-router.org</a>
Subject: [sr-dev] git:master: usrloc(k): keep time of the last keepalive for
natted UDP contacts
Date: Thu, 13 Sep 2012 17:08:51 +0300
Klaus wrote:
Why only UDP? Are TCP contacts removed when the TCP connections is closed?
IMO there should also be a mechanism to remove ALL expired unresponsive
contacts.
how about the following for tcp contacts:
- set_forward_no_connect();
- if t_relay() fails because tcp connection does not exist,
unregister the AoR/contact
what would be needed is a find out that t_relay() failed due to
non-existing connection and a script function to do un-registration of
an AoR/contact.
perhaps both of these two things already exist?
-- juha
_______________________________________________
sr-dev mailing list
<a href="mailto:sr-dev@lists.sip-router.org" target="_blank">sr-dev@lists.sip-router.org</a>
<a href="http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev" target="_blank">http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev</a>
</pre>
</blockquote>
<br>
<table cellspacing="0" cellpadding="0" width="100%">
<tbody><tr>
<td>
<pre>--
Peter Dunkley
Technical Director
Crocodile RCS Ltd
</pre>
</td>
</tr>
</tbody></table>
</div>
_______________________________________________<br>sr-dev mailing list<br><a href="mailto:sr-dev@lists.sip-router.org" target="_blank">sr-dev@lists.sip-router.org</a><br><a href="http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev" target="_blank">http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev</a><br>
</blockquote></div></div></div><br></div><br>_______________________________________________<br>
SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list<br>
<a href="mailto:sr-users@lists.sip-router.org">sr-users@lists.sip-router.org</a><br>
<a href="http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users" target="_blank">http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users</a><br>
<br></blockquote></div><br></div>
_______________________________________________<br>SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list<br><a href="mailto:sr-users@lists.sip-router.org">sr-users@lists.sip-router.org</a><br>http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users<br></blockquote></div><br></body></html>