6 Dec
2012
6 Dec
'12
6:06 a.m.
On Thu, 2012-12-06 at 11:57 +0100, Olle E. Johansson wrote:
My point exactly. I have no experience with the registrar and usrloc
modules, and the outbound development breaks neatly into two parts:
* Edge server (rr, path, outbound)
* Proxy/registrar (registrar, usrloc)
I will eventually do all of it, but if it is needed sooner then getting
someone else to do the proxy/registrar part would help.
All of the checking/handling of the new response codes will be in
failure_routes. So I don't think there is really any work required
here.
One thing that would speed up the development of outbound is if
someone else (who knows about the internals of the registrar and
usrloc modules) took on the tasks relating to those. These are
basically:
* Handle multiple registrations with same instance ID but
difference reg-id (may already be supported)
It needs to be handled properly in parallell and serial forking, which
I have not seen. May have missed it though.
* Have
registrar populate an AVP array (specified as a
modparam), ordered by reg-id, when a lookup() is performed -
similar to dispatcher (but don't break parallel and serial
forking) - set $du to first contact in the AVP array.
Right.
* New API (lookup_next_dest()) in registrar
that allow you to
work through the set in order if a 430 is returned (API
needs to remove failed contacts from the location table) -
again, similar to dispatcher
And for being able to use outbound for NAT traversal on a single
server (so no Edge proxies):
* Make registrar able to detect that the top Path-URI for the
contact is actually an interface on the local server, and if
it has an ;ob parameter and a flow token, set $du based on
that.
This would allow me to focus on the Edge server behaviour, which
involves changes to path, rr, a new outbound module, and some
configuration examples (for edge and proxy/registrar).
And new response codes.
I do long for an eventroute for broken TCP connections
from clients.
Not sure how this would help with outbound as the proxy/registrar and
edge server (with the client connections) will be separate anyway?
I think that between checking the return code from t_relay() and a
failure_route on the edge proxy you will catch all of these problems and
be able to generate the 430 response.
Thanks for the feedback. I guess we have to visit
Berlin and feed an
unspecified group of developers with Bratwurst and Beer to get some
help here... :-)
If I had time to visit Berlin I'd have more time to spend on outbound in
the first place :-)
--
Peter Dunkley
Technical Director
Crocodile RCS Ltd
