[sr-dev] Outbound summary

[Martin Hoffmann]

Peter Dunkley wrote:
> 
> I thought I would try and produce a short summary (basically just bullet
> points) of what is required for Outbound just to make sure I haven't
> missed anything.

Thanks for that. The chatlogs sure were nice, but this makes discussions
a lot easier.

> EDGE server
> -----------
> * Path
>   - Existing Path module does (most of) what is required when called for
>     REGISTER requests
>   - 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:

I'd like to see the flow-token mechanism replace the current received
mechanism. Conceptionally, they are the same: a string representation of
the two endpoint addresses of a flow. Which also means you don't really
need to keep a mapping of connections and flow tokens. From any given
pair of local and remote address, you can simply calculate it on the
fly.

For the edge server, things are easy: Put the flow token into the user
part of Route, Record-Route, or Path headers. The all-in-one proxy would
store the flow token instead of the pair of received and socket in location
(or possibly as a fake Path? This would end up as a Route header in outgoing
requests, which should be okay, and would have the advantage of no need
to change the location table yet again.)

If I am not mistaken, this mechanism works independently of whether the
endpoint supports outbound or not. If it doesn't this is just like what
we do today except that we won't meddle with Contact URIs and other mean
things (there'd still be meddeling with SDP but that's a different
topic).

>   - 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)

Essentially, this would be changing the current proprietary 477 to a 430.
Probably easiest to add a config parameter and let the admin decide what
exactly they want.

Things are a bit more complicated with UDP. I think replacing the
current local 408 with a local 430 if the UAS side of the transaction
times out (fr_timer, I believe?) should do the trick. This is
nonewithstanding a 408 in case the whole transaction times out
(fr_inv_timer). Maybe we add optional event routes for these which would
be called instead of generating these local responses when set?

> 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?

Correct. The Path is basically just a route for out-of-dialog messages.
The route set for a dialog is generated by way of Record-Route headers
inserted during dialog creation.

> * 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?

Yes, but keepp in mind that the flow token is only good for a particular
flow between two particular endpoint addresses (this being transport, IP
address, and port tuples). So, if the edge receives an outgoing request
(meaning towards the endpoint) with a valid hostport in the Route URI but
a flow token for a local address it doesn't serve, it would have to fail.
For incoming requests, it could rewrite the route set with a new Route
URI for this particular flow.

Hence I am not sure if it makes sense at all to advertise anything other
than the actual listening address. In one direction, your dialog will be
broken if the flow fails, anyways.

> Proposed API
> ------------
> Right thing to do might be a new outbound module which provides both the
> EDGE server and registrar functions.

I'd prefer if we could do this through config and only enhance the C
APIs where needed. With the new include logics and whatnot, this can
come in the form of a config library.

Best regards,
Martin