Feature #3507

allow shorter Connection Identifier 'I:'

Added by neels 9 months ago. Updated 8 months ago.

Target version:
Start date:
Due date:
% Done:



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.

Related issues

Related to OsmoMGW - Feature #3429: idea: auto-cleanup endpoints after long period of inactivity?Resolved2018-07-28


#1 Updated by neels 9 months ago

  • Related to Feature #3429: idea: auto-cleanup endpoints after long period of inactivity? added

#2 Updated by neels 9 months ago

RFC3435 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.

#3 Updated by neels 9 months ago

  • Description updated (diff)

#4 Updated by laforge 9 months ago

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.

#5 Updated by neels 9 months ago

  • Status changed from New to In Progress

#6 Updated by neels 9 months ago

  • % Done changed from 0 to 90

#7 Updated by neels 8 months ago

  • Status changed from In Progress to Resolved
  • % Done changed from 90 to 100

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)