On Thu, Feb 13, 2020 at 10:59:47AM +0000, Mark Boyce wrote:
That’s exactly where we ended up. We’ve just added code to assign a uuid to each new dialog as it’s created. Which when logged via acc gives us the extra unique reference.
The trouble with that is it requires you to do a lot of gymnastics to keep extra state. Using Call-ID as a key allows you to operate on calls in a way that makes use solely of information contained in the SIP message itself.
In an essentially thermodynamic sense, more state means more complexity, and more fragility due to the inevitable bugs and corner cases that any moving part and synchronisation effort brings.
Call-IDs are required to be adequate GUIDs by the standard, and are sufficiently unique that the chance of a malicious collision is infinitesimal. Even short, bad GUIDs tend to be quite mathematically unique, unless they're just so comically short as to make a mockery of the GUID requirement.
I would carefully weigh the economic and technical trade-offs of assigning calls UUIDs on your side and maintaining that mapping. A more pragmatic policy might be to reject requests with a Call-ID that is below a certain string length.
-- Alex