Feature #3507
Updated by neels over 5 years ago
When responding to a CRCX, osmo-mgw passes back a randomized connection ID in the "I: " header, to identify one connection of the given endpoint. So far, this ID is 32 characters hex, i.e. 16 bytes or 128bit long. When testing against a specific SCCPlite MSC, which sets up the MSC side of an MGW endpoint itself, I notice that it cannot store this size of ID. At the end of a call, the MSC sends a DLCX for the connection it set up earlier, and with the long IDs given by osmo-mgw, it actually always passes back "ffffffff" -- that's 4 bytes, UINT32_MAX. When patching osmo-mgw to produce only 4 bytes of connection ID instead of 16, this same MSC does infact DLCX with the same ID that it was given in the CRCX response. So, to accomodate this specific MSC, we must not issue Connection Identifiers of more than 8 hex digits, or it will always return ffffffff. * either we make the conn id length a configurable option, * or we simply globally reduce the conn id to a fixed length of 4 bytes everywhere. The conn ID actually only needs to be unique per endpoint, meaning that currently, where we don't support conference calls, there are exactly two connection IDs per endpoint that should avoid collision. Using a 32bit randomized ID for that seems more than sufficient by far. So I would vote for us simply reducing the length to 4 bytes or 8 hex characters. 4.
