allow shorter Connection Identifier 'I:'
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.
188.8.131.52 Names of Connections Connection identifiers are created by the gateway when it is requested to create a connection. They identify the connection within the context of an endpoint. Connection identifiers are treated in MGCP as hexadecimal strings. The gateway MUST make sure that a proper waiting period, at least 3 minutes, elapses between the end of a connection that used this identifier and its use in a new connection for the same endpoint (gateways MAY decide to use identifiers that are unique within the context of the gateway). The maximum length of a connection identifier is 32 characters.
The maximum length is 32 characters, and the identifier's scope is indeed merely limited by that one specific endpoint (one call between currently no more than two subscribers).
I think we're still on the safe side if we reduce osmo-mgw to a length of 8 hex characters.
On Tue, Aug 28, 2018 at 05:45:42PM +0000, neels [REDMINE] wrote:
So I would vote for us simply reducing the length to 4.
Fine with me. But please take the extra effort of putting together a proper bug
report for the MSC vendor referencing the exact RFC paragraph/quote that states
their implementation is broken.