Project

General

Profile

Bug #3294

transaction: refactor callref allocation

Added by fixeria about 1 year ago. Updated 5 months ago.

Status:
Stalled
Priority:
High
Assignee:
Category:
-
Target version:
-
Start date:
05/26/2018
Due date:
% Done:

0%

Resolution:

Description

Each transaction has a field called 'callref', that should contain an unique identifier. This identifier is being assigned either by OsmoMSC itself, either by an external application (e.g. LCR), and is used to distinguish between multiple allocated transactions.

In case of a new callref generation on the MSC side, there are the following sources for that:

$ git grep "static uint32_t new_callref" 

src/libmsc/gsm_04_08.c:static uint32_t new_callref = 0x80000001;
src/libmsc/gsm_04_11.c:static uint32_t new_callref = 0x40000001;
src/libmsc/mncc_builtin.c:static uint32_t new_callref = 0x00000001;

So, we have a few ranges for different types of communication:

- from 0x00000001 to 0x40000000 - Call Control, internal MNCC;
- from 0x40000001 to 0x80000000 - SMS messages;
- from 0x80000001 to 0xffffffff - Call Control, external MNCC;

And this is how a new 'callref' value is generated:

new_callref++

I see the following problems:

1) Imagine that we have a network, which is running for some long time. What if the amount of calls ever made would reach 0x40000000? The next values will be 0x40000001, 0x40000002, 0x40000003, etc. At some point, this may result into collisions, e.g. two transactions with same 'callref' value.

Possible solution: instead of doing `new_callref++` manually, create a function (e.g. trans_gen_ref), which would prevent overlaps between ranges, and flush the source to initial value.

2) The trans_alloc(), which is used to allocate a new transactions, doesn't check if passed 'callref' value is not used. In other words, it is possible to allocate a few transactions with not unique 'callref'. In this case the trans_find_by_callref() would work incorrectly.

Possible solution: before allocation, check if given 'callref' is already used.

3) The 'callref' as a field name itself looks/sounds like something call related, while this feature will be also used as soon as we implement SMS and SS/USSD over GSUP. It would be better to rename it to something more generic, e.g. just 'ref'.

4) Both sides, i.e. MSC and an external application, are involved in 'callref' generation. There is no master-slave relation... This may result in a situation, when an external application asks to allocate a new transaction with 'callref', which is already used.

Possible solution: inspire by GSM TS 04.07, section 11.2.3 "Transaction identifier" and introduce the direction bit. Probably, this can be a bit simplified, e.g. '0' means allocated by the MSC itself, '1' - by an external application.


Related issues

Related to OsmoNITB - Feature #1667: Handle callref betterNew03/22/2016

Related to OsmoMSC - Feature #2487: MSC side of LCLS (local call local switching) as per the 3GPP specsStalled09/03/2017

History

#1 Updated by laforge 12 months ago

  • Assignee set to stsp

#2 Updated by fixeria 11 months ago

  • Category set to SS/USSD
  • Status changed from New to Stalled
  • Priority changed from Normal to High

#3 Updated by fixeria 11 months ago

  • Category deleted (SS/USSD)

#4 Updated by fixeria 9 months ago

#5 Updated by msuraev 5 months ago

  • Related to Feature #2487: MSC side of LCLS (local call local switching) as per the 3GPP specs added

#6 Updated by msuraev 5 months ago

On a related note: CallRef is sent as part of LCLS-related config to BSC where it's used to match related call legs. Current allocation scheme makes it hard because of the different prefixes used by CC and MNCC code. I've worked around this by dropping prefix byte and using remainder for LCLS but it's a race-prone hack. When fixing this we should definitely take LCLS into consideration.

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)