<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    Hello,<br>
    <br>
    <div class="moz-cite-prefix">On 8/9/12 4:42 PM, Peter Dunkley wrote:<br>
    </div>
    <blockquote
      cite="mid:1344523377.9830.4.camel@pd-notebook-linux.croc.internal"
      type="cite">
      <meta http-equiv="Content-Type" content="text/html;
        charset=ISO-8859-1">
      <meta name="GENERATOR" content="GtkHTML/4.4.3">
      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>
    </blockquote>
    <br>
    there is no final design yet, I assume, but if there is a need for
    [persistent] storage, I would not like to get rr or path dependent
    of db or other type of external storage. If the flow value carries
    the information needed for routing in the SIP message, then rr/path
    can be extended. Otherwise I think a new module to take care of
    storage overhead is recommended, either using internally rr/path or
    the other modules using it.<br>
    <br>
    The fact is that these modules are used heavily, even in embedded
    devices, but at the moment outbound is not implemented at large in
    clients side (ie, few phones sending sip.instance and reg-id). So
    the 'classic' usage is still the most important for some time.<br>
    <br>
    Cheers,<br>
    Daniel<br>
    <br>
    <br>
    <blockquote
      cite="mid:1344523377.9830.4.camel@pd-notebook-linux.croc.internal"
      type="cite">
      <blockquote type="CITE">
        <pre>
</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>
        <li>The add_path() APIs need to be updated to let parameters be
          added (for example ";ob" - at least you can already set the
          userinfo) </li>
        <li>The logic to decide to use outbound for requests from
          clients should be manageable as a route </li>
        <li>The logic to do the routing back to clients, sending the 430
          etc, should be manageable as a route </li>
        <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>
        <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>
        <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
        </li>
      </ul>
      <br>
      Have I missed anything in that list?<br>
      <br>
      <table cellpadding="0" cellspacing="0" width="100%">
        <tbody>
          <tr>
            <td>
              <pre>-- 
Peter Dunkley
Technical Director
Crocodile RCS Ltd
</pre>
            </td>
          </tr>
        </tbody>
      </table>
      <br>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <br>
      <pre wrap="">_______________________________________________
sr-dev mailing list
<a class="moz-txt-link-abbreviated" href="mailto:sr-dev@lists.sip-router.org">sr-dev@lists.sip-router.org</a>
<a class="moz-txt-link-freetext" href="http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev">http://lists.sip-router.org/cgi-bin/mailman/listinfo/sr-dev</a>
</pre>
    </blockquote>
    <br>
    <pre class="moz-signature" cols="72">-- 
Daniel-Constantin Mierla - <a class="moz-txt-link-freetext" href="http://www.asipto.com">http://www.asipto.com</a>
<a class="moz-txt-link-freetext" href="http://twitter.com/#!/miconda">http://twitter.com/#!/miconda</a> - <a class="moz-txt-link-freetext" href="http://www.linkedin.com/in/miconda">http://www.linkedin.com/in/miconda</a>
Kamailio Advanced Training, Seattle, USA, Sep 23-26, 2012 - <a class="moz-txt-link-freetext" href="http://asipto.com/u/katu">http://asipto.com/u/katu</a>
Kamailio Practical Workshop, Netherlands, Sep 10-12, 2012 - <a class="moz-txt-link-freetext" href="http://asipto.com/u/kpw">http://asipto.com/u/kpw</a></pre>
  </body>
</html>