[SR-Users] [sr-dev] Testing SIP Outbound / RFC5626 (Was: Freezing for next major release)

[Richard Brady]

Also can a flow fail temporarily?

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?

And would this generate a 430 or would it generate a different response
code?

On the other hand this quote from the RFC makes it sounds like 430
represents a permanent condition:

  If the flow no longer exists, the proxy SHOULD
   send a 430 (Flow Failed) response to the request.

Richard

On 8 January 2013 09:55, Olle E Johanson <olle at ozone.webway.se> wrote:

>
> 8 jan 2013 kl. 10:43 skrev Peter Dunkley <peter.dunkley at crocodile-rcs.com
> >:
>
>  Hi Juha,
>
> 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.
>
>
> Just a clarification:
>
> Section 9.3 says that
> "Bob's authoritative proxy first tries the flow to EP1,
>
>    but EP1 no longer has a flow to Bob, so it responds with a 430 (Flow
>
>    Failed) response.  The proxy removes the stale registration and tries
>    the next binding for the same instance."
>
>
> But it is not mentioned in the server handling section of the Outbound RFC.
>
> /O
>
>
> 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.
>
> 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.
>
> Peter
>
>
> On Tue, 2013-01-08 at 04:46 +0200, Juha Heinanen wrote:
>
> 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 <jh at tutpro.com>
> Sender: sr-dev-bounces at lists.sip-router.org
> To: sr-dev at lists.sip-router.org
> 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 listsr-dev at lists.sip-router.orghttp://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
>
>
>   --
> Peter Dunkley
> Technical Director
> Crocodile RCS Ltd
>
>   _______________________________________________
> sr-dev mailing list
> sr-dev at lists.sip-router.org
> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev
>
>
>
> _______________________________________________
> SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list
> sr-users at lists.sip-router.org
> http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-users/attachments/20130110/bb25b78e/attachment.htm>