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 <o...@ozone.webway.se> wrote: > > 8 jan 2013 kl. 10:43 skrev Peter Dunkley <peter.dunk...@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 <j...@tutpro.com> > Sender: sr-dev-boun...@lists.sip-router.org > To: sr-...@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-...@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-...@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@lists.sip-router.org > http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users > >
_______________________________________________ SIP Express Router (SER) and Kamailio (OpenSER) - sr-users mailing list sr-users@lists.sip-router.org http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-users
