On Thu, 2012-08-09 at 16:03 +0200, Olle E.
Johansson wrote:
I am not in favour of a new module. Like GRUU,
this is just optional behaviour based on the signalling....
My concern is just the amount of complex Kamailio configuration
required for something like Outbound. It's likely to be very messy
and hard for people to use. But if you think it is practical, I
don't have a problem trying it that way.
There are going to be quite a number of (hopefully small) changes to
the existing modules (path, registrar, rr, and usrloc at least)
anyway.
* The record_route() APIs need to be updated to make the
userinfo settable from kamailio.cfg (at least you can
already add parameters)
* The add_path() APIs need to be updated to let parameters be
added (for example ";ob" - at least you can already set the
userinfo)
* The logic to decide to use outbound for requests from
clients should be manageable as a route
* The logic to do the routing back to clients, sending the 430
etc, should be manageable as a route
* 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. Perhaps a set of
flow-token specific APIs to wrapper all of these things (in
one of the utils modules) would be better?
* 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
* 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
Have I missed anything in that list?