[sr-dev] Outbound summary

[Iñaki Baz Castillo]

Hi, sorry for the very late response, please let me some comments inline:







> EDGE server
> -----------
> * Path
>   - Existing Path module does (most of) what is required when called for
> REGISTER requests

It MUST add ;ob param to the Path URI.


>   - Received parameters are not needed on Path: headers because we will
> use Outbound flow tokens now

> * Outbound
>   - Need to generate/add flow token and ;ob parameter to the
> Path/Record-Route headers when:
>     # It's an initial request (out-of-dialog INVITE, REGISTER, SUBSCRIBE,
> or REFER), with
>     # A single Via:, and
>     # Top Route: points to us and has ;ob parameter or Contact: has ;ob
> parameter or it's a REGISTER with ;+sip.instance, or
>     # force_outbound() API has been called

My fault: it is not the ;+sip.instance parameter but ;reg-id parameter
in the Contact header.

BTW: The EDGE proxy must not add ;ob to the top Route since it should
determine that a future incoming in-dialog request must be routed
through an Outbound connection if such a top Route (or second Route if
there is double RR) has a URI username which identifies the Outbound
flow token.



>   - Need to maintain mapping of flow tokens to connections (flow token
> to/from source address and port)

>   - Need an Outbound routing API (related to loose_route()) that sets $du
> correctly based on flow token in Route: header (R-URI no longer used)

>   - If the flow token doesn't match a connection send 430 response
> (response sending in kamailio.cfg, but Outbound routing API needs to
> return an appropriate error to support this)




> Registrar
> ---------
> * Path
>   - Path already supported in usrloc
> * Outbound
>   - instance and reg IDs already stored in usrloc
>   - multiple registrations with the same instance ID but different reg IDs
> must be supported (may be already)
>   - Parallel and serial forking behaviour must be preserved, when forking
> branch to each unique instance ID not reg ID.
>   - Need a new/improved lookup() API that returns the location for the
> best reg ID and populates an AVP with the other instance IDs in order
> they should be tried
>   - On receipt of 430 response to a request the failed location should be
> removed from the usrloc table and the next location (from the AVP)
> tried.  Similar to the way dispatcher works.




> Single server
> -------------
> * Path
>   - Use this to add single (local) Path header - just needed to get the
> Outbound flow token into the usrloc table
>   - Received parameters are not needed on Path: headers because we will
> use Outbound flow tokens now
> * Outbound
>   - Similar to the combined behaviour of EDGE server and Registrar, but
> because the mapping of flow token to connection is local there is no
> need for the 430 response stuff - can just loop through the list of
> matching connections locally until a good one is found.

... and remove any registration binding if the request could not be
sent (503, 408...).



> Note: Double-Path and advertised address...
> *  Talking to one of my colleagues he thought that double-Path headers
> wouldn't be required.  Double-RR is used to make sure the route-set is
> good in both directions when there are transport/network changes.  Because
> Path is just used in the one direction this shouldn't be required.  Does
> this make sense?

Right. In this case the EDGE proxy would add a single Path header
whose URI points to the interface in which it wants to receive future
requests from the registrar, and such a Path URI should, of course,
contain the outbound flow token (URI username) and the URI ;ob param.



> * Because the Path header needs to show the address of the outbound
> interface it should use the advertised address for that interface, not the
> listening address of the interface.  Is this correct?

mmm, the interface in which it wants to receive future requests from
the registrar, right?



-- 
Iñaki Baz Castillo
<ibc at aliax.net>