[sr-dev] Status of outbound support

[Peter Dunkley]

On Thu, 2012-12-06 at 11:57 +0100, Olle E. Johansson wrote:

> > 
> > 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.
> 

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.

> >       * 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. 
> 

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.

> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sip-router.org/pipermail/sr-dev/attachments/20121206/a16b35f3/attachment.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: face-smile.png
Type: image/png
Size: 1057 bytes
Desc: not available
URL: <http://lists.sip-router.org/pipermail/sr-dev/attachments/20121206/a16b35f3/attachment.png>