<!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.3">
</HEAD>
<BODY>
On Thu, 2012-08-09 at 15:54 +0100, Peter Dunkley wrote:<BR>
<BLOCKQUOTE TYPE=CITE>
    On Thu, 2012-08-09 at 15:42 +0100, Peter Dunkley wrote:<BR>
    <BLOCKQUOTE TYPE=CITE>
        On Thu, 2012-08-09 at 16:03 +0200, Olle E. Johansson wrote: 
        <BLOCKQUOTE TYPE=CITE>
<PRE>
I am not in favour of a new module. Like GRUU, this is just optional behaviour based on the signalling....
</PRE>
        </BLOCKQUOTE>
        <BR>
        My concern is just the amount of complex Kamailio configuration required for something like Outbound.&nbsp; It's likely to be very messy and hard for people to use.&nbsp; But if you think it is practical, I don't have a problem trying it that way.<BR>
        <BR>
        There are going to be quite a number of (hopefully small) changes to the existing modules (path, registrar, rr, and usrloc at least) anyway. 
        <UL>
            <LI>The record_route() APIs need to be updated to make the userinfo settable from kamailio.cfg (at least you can already add parameters) 
            <LI>The add_path() APIs need to be updated to let parameters be added (for example &quot;;ob&quot; - at least you can already set the userinfo) 
            <LI>The logic to decide to use outbound for requests from clients should be manageable as a route 
            <LI>The logic to do the routing back to clients, sending the 430 etc, should be manageable as a route 
            <LI>Flow token generation/decode/validation is going to be tricky as new APIs will be needed for at least base64 encode, base64 decode, HMAC-SHA1-80 - and string manipulation in kamailio.cfg is a pain.&nbsp; Perhaps a set of flow-token specific APIs to wrapper all of these things (in one of the utils modules) would be better? 
            <LI>A new API will be required to determine whether a connection exists (based on input of IP address, port, and protocol) - unless trying to send the request and just catching/translating the error to a 430 is OK 
            <LI>I think the new lookup(), lookup_next_dest(), managing the AVPs for this and removing bindings from the location table all do need to be new functions in the registrar module 
        </UL>
        <BR>
        Have I missed anything in that list?<BR>
        <BR>
    </BLOCKQUOTE>
    Add to the list: 
    <UL>
        <LI>Advertised address support in Path module
    </UL>
</BLOCKQUOTE>
And:
<UL>
    <LI>Handle SIP/STUN/keepalive stuff (RFC5626 section 5.4 and section 8) - does Kamailio support anything like this already?
</UL>
<BR>
<TABLE CELLSPACING="0" CELLPADDING="0" WIDTH="100%">
<TR>
<TD>
<PRE>
-- 
Peter Dunkley
Technical Director
Crocodile RCS Ltd
</PRE>
</TD>
</TR>
</TABLE>
</BODY>
</HTML>