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 #1

Updated by neels over 5 years ago

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

Updated by neels over 5 years ago

RFC3435

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

Actions #3

Updated by neels over 5 years ago

  • Description updated (diff)
Actions #4

Updated by laforge over 5 years 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.

Actions #5

Updated by neels over 5 years ago

  • Status changed from New to In Progress
Actions #6

Updated by neels over 5 years ago

  • % Done changed from 0 to 90
Actions #7

Updated by neels over 5 years ago

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

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)