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