User Tools

Site Tools


This is an old revision of the document!

This page contains some notes describing the work to fully complete outbound (RFC 5626) support on Kamailio. It is believed that the current Kamailio feature set is sufficient to provide separate Edge Proxy and Registrar servers supporting outbound.

Work required to complete registrar support

  • registrar module
    • New exported function allowing a specific contact to be removed (to be used when Edge Proxy returns 430 to the registrar)
    • Add a required header in mode 2 if the client supports outbound.
If outbound registration succeeded, as indicated by the presence of
   the outbound option-tag in the Require header field of a successful
   registration response, the UA begins sending keep-alives as described
   in Section 4.4.
  • Support for RFC 5626 section 6:
   When receiving a REGISTER request, the registrar MUST check from its
   Via header field if the registrar is the first hop or not.  If the
   registrar is not the first hop, it MUST examine the Path header of
   the request.  If the Path header field is missing or it exists but
   the first URI does not have an "ob" URI parameter, then outbound
   processing MUST NOT be applied to the registration.  In this case,
   the following processing applies: if the REGISTER request contains
   the reg-id and the outbound option tag in a Supported header field,
   then the registrar MUST respond to the REGISTER request with a 439
   (First Hop Lacks Outbound Support) response; otherwise, the registrar
   MUST ignore the "reg-id" parameter of the Contact header.

Single-server (combined edge proxy and registrar)

  • registrar module
    • Update lookup() so that (in single-server mode) Path: header from location table is added as a Record-Route:. If parallel forking is in use each branch must have a different Record-Route: added. lookup() must also set $du based on the flow-token from the Record-Route: header it adds for that branch.
  • tm module
    • Update t_*_contacts() functions so they will work with the new lookup() behaviour in single-server mode.
  • rr module
    • Update loose_route() to cope with the double-RR that the new lookup() behaviour causes. The first Record-Route: added to a dialog forming request will have been added when the request arrived on the server and contains a flow-token pointing to the originator of the request. The second Record-Route: added is the one created by lookup() and contains a flow-token pointing to the destination of the branch.
  • nathelper module
    • Move nat_uac_test() to another module (perhaps siputils?) enabling Kamailio users to choose between the two different NAT traversal mechanisms cleanly by loading either the nathelper module or the outbound module.

Other work to be considered

  • Within dialog flow fail-over
    • Is this even possible?
devel/completing_outbound.1361374529.txt.gz · Last modified: 2013/02/20 16:35 by oej