<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 TRANSITIONAL//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; CHARSET=UTF-8">
<META NAME="GENERATOR" CONTENT="GtkHTML/4.4.4">
</HEAD>
<BODY>
On Thu, 2012-12-06 at 11:57 +0100, Olle E. Johansson wrote:<BR>
<BR>
<BLOCKQUOTE TYPE=CITE>
<BLOCKQUOTE TYPE=CITE>
<BR>
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:
<UL>
<LI>Handle multiple registrations with same instance ID but difference reg-id (may already be supported)
</UL>
</BLOCKQUOTE>
</BLOCKQUOTE>
<BLOCKQUOTE TYPE=CITE>
It needs to be handled properly in parallell and serial forking, which I have not seen. May have missed it though.
</BLOCKQUOTE>
<BLOCKQUOTE TYPE=CITE>
<BR>
</BLOCKQUOTE>
My point exactly. I have no experience with the registrar and usrloc modules, and the outbound development breaks neatly into two parts:
<UL>
<LI>Edge server (rr, path, outbound)
<LI>Proxy/registrar (registrar, usrloc)
</UL>
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.<BR>
<BR>
<BLOCKQUOTE TYPE=CITE>
<BLOCKQUOTE TYPE=CITE>
<UL>
<LI>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.
</UL>
</BLOCKQUOTE>
</BLOCKQUOTE>
<BLOCKQUOTE TYPE=CITE>
Right.
</BLOCKQUOTE>
<BLOCKQUOTE TYPE=CITE>
<BLOCKQUOTE TYPE=CITE>
<UL>
<LI>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
</UL>
And for being able to use outbound for NAT traversal on a single server (so no Edge proxies):
<UL>
<LI>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.
</UL>
<BR>
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).<BR>
<BR>
</BLOCKQUOTE>
</BLOCKQUOTE>
<BLOCKQUOTE TYPE=CITE>
And new response codes.
</BLOCKQUOTE>
<BLOCKQUOTE TYPE=CITE>
<BR>
</BLOCKQUOTE>
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.<BR>
<BR>
<BLOCKQUOTE TYPE=CITE>
I do long for an eventroute for broken TCP connections from clients.
</BLOCKQUOTE>
<BLOCKQUOTE TYPE=CITE>
<BR>
</BLOCKQUOTE>
Not sure how this would help with outbound as the proxy/registrar and edge server (with the client connections) will be separate anyway?<BR>
<BR>
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.<BR>
<BR>
<BLOCKQUOTE TYPE=CITE>
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... :-)
</BLOCKQUOTE>
<BLOCKQUOTE TYPE=CITE>
<BR>
</BLOCKQUOTE>
If I had time to visit Berlin I'd have more time to spend on outbound in the first place <IMG SRC="cid:1354791952.2387.23.camel@pd-notebook-linux.croc.internal" ALIGN="middle" ALT=":-)" BORDER="0">
<BR>
<TABLE CELLSPACING="0" CELLPADDING="0" WIDTH="100%">
<TR>
<TD>
<PRE>
--
Peter Dunkley
Technical Director
Crocodile RCS Ltd
</PRE>
</TD>
</TR>
</TABLE>
</BODY>
</HTML>