Project

General

Profile

Actions

Feature #3507

closed

allow shorter Connection Identifier 'I:'

Added by neels over 5 years ago. Updated over 5 years ago.

Status:
Resolved
Priority:
High
Assignee:
Category:
-
Target version:
-
Start date:
08/28/2018
Due date:
% Done:

100%

Spec Reference:

Description

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?Resolvedosmith07/28/2018

Actions
Actions

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)