Cellular Network Infrastructure » Core Network (CN) » OsmoMSC

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.

neels, please review and determine if it is still valid and high priority. if yes, feel free to discuss with osmith if he can help with the implementation

This issue is still valid and I guess possible transaction collisions qualify as high prio.

fixeria wrote:

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.

Let's first clarify the distinction between the TI and the "callref":

• The transaction ID is typically a 4bit identifier communicated between MS and MSC, where the highest bit indicates the origin and values 0-6 can be used for concurrent message flows.
  There may be an "Extended" TI indicated by value 7, and followed by a full octet (with another EXT flag as highest bit and 7 bits for TI values).
  This part is well specified and fine. I'm not sure whether we are able to handle extended TI, but there is no ID collision issue here.

• The "callref" is an Osmocom invention. It is used for:
  • MNCC protocol callref. AFAICT this is entirely for identification between osmo-msc and MNCC peer;
    In osmo-sip-connector, the callref is used as internal call->id, but does not end up in SIP.
    For MSC-initiated MNCC, it simply takes the callref received from MNCC (also used for call->id).
    For sipcon-initiated MNCC, it has a last_call_id in src/call.c, assigned to call->id = ++last_call_id, which is copied 1:1 to mncc via leg->callref = call->id and then mncc.callref = leg->callref.
    MSC starts assigning callrefs from 0x80000001, while sipcon starts at 5001.
    It is practically not very likely to collision, but a collision could happen after a sufficient number of calls, possibly causing things like inadvertent call drops or even connecting the wrong call legs to each other (talking to the wrong person).
  • USSD handling: GSUP session_id towards osmo-hlr.
    The libosmocore gsup.h in the session_id API doc says "Unique session identifier and origination flag.",
    but the GSUP specs fail to specify a origination / direction flag for Supplementary Services.
    see e.g. osmo-msc user manual 18.6.20 "Process Supplementary Service Request", 18.8 "Session (transaction) management"
    AFAICT osmo-hlr does not avoid collisions here yet, all I can see is "ss = ss_session_alloc(hlr, gsup->imsi, gsup->session_id);" -- fixeria ?

I guess a first sane step would be to separate the different IDs, i.e. instead of overloading trans->callref, have distinct trans->cc.callref and trans->ss.session_id values.
Then we can resolve ID collision issues for each realm independently.

I agree that the sanest way would be to include an origin/direction flag, so that each side can use the same number space without collisions.
We need to clarify:

• Can we expect all MNCC client programs to adhere?
  • Implementation: modify (for starters) osmo-sip-connector to heed a direction flag.
  • Specification: does adding the flag constitue a backwards incompatibility?

• osmo-hlr <--GSUP-SS--> osmo-msc:
  • Impl: Does Supplementary Services via GSUP already employ an origin/direction flag? (not AFAICT)
  • Spec: we need to enhance the GSUP spec in the user manuals to properly specify a direction flag.

Any opinions on this?

Hi Neels,

The libosmocore gsup.h in the session_id API doc says "Unique session identifier and origination flag.", but the GSUP specs fail to specify a origination / direction flag for Supplementary Services. [...]
AFAICT osmo-hlr does not avoid collisions here yet, all I can see is "ss = ss_session_alloc(hlr, gsup->imsi, gsup->session_id);" -- fixeria ?

Oh, wow. Most likely, I was planning to implement this flag at that time, but never had time to start working on it. Of course, neither OsmoMSC nor OsmoHLR implement this flag, so collisions are possible. Moreover, we have not negotiated the coding of that flag so far.

I guess a first sane step would be to separate the different IDs, i.e. instead of overloading trans->callref, have distinct trans->cc.callref and trans->ss.session_id values. Then we can resolve ID collision issues for each realm independently.

Sounds good to me. The current approach of having different value ranges for different transaction types is really odd and problem prone, since we never had all the ranges defined together in a single header file.

• Can we expect all MNCC client programs to adhere?
  • Specification: does adding the flag constitue a backwards incompatibility?

We could use one LSB/MSB bit as a flag, and set it for all MSC-originated transactions / sessions. Therefore if it's set to zero, than a transaction is considered as 'foreign'. But since we already use quite big values like 0x80000001 (both LSB and MSB bits are set), this approach will not work.

Also, AFAIR jolly's LCR (Linux Call Router) does check if callref is within some range, and rejects a transaction otherwise. Not sure if anybody is still using it though.

Any opinions on this?

Now it's a good question: how do we introduce this flag and keep backwards compatibility at the same time...

A problem I see with a single bit origin flag: at most two entities can be involved.
As soon as osmo-hlr forwards to another handler, or maybe at some point handling happens distributed across servers or whatnot, the single bit will be inadequate.
It works well on a 1:1 link like RSL, where lower layers sort out sender and receiver and there are exactly two sides involved. But in GSUP there may be more entities on the wire.

I thought about somehow implicitly figuring out the initiator of a session, and store it internally, but I'm pretty sure that wouldn't work.

A solution that I see is to add a Session Originator IE: define that a session id is always owned by the initiator of a session.
An example:

• osmo-msc identified on IPA as "FOO" starts a USSD session, creates session_id = 1, sends GSUP session_originator = "FOO", session_id = 1.
• osmo-hlr receives the message, forwards to an EUSE
• EUSE "BAR" remembers that this session has ID FOO-1.
• When "BAR" replies to this session, it again sends session_originator = "FOO", session_id = 1 back to osmo-msc.
• At some point "BAR" initiates a session. It can also create session_id = 1 and send to osmo-msc session_originator = "BAR", session_id = 1.
• osmo-msc receives id BAR-1 and is able to distinguish from the unrelated FOO-1 from before.

This solution is "backwards compatible" in the way that older implementations could techincally ignore the unknown Session Originator IE and still run into collisions as before.
But I think we usually error out on unknown IEs?
Anyway, adding explicit "session id namespaces" currently seems to me to be the clearest and most future proof solution, even if it involves an incompatibility.

(BTW, we already have Source Name and Destination Name IEs for inter-MSC HO, but we can't re-use that as session originator,
because these are designed as routing targets in the way that if a request had source=A dest=B, the response will have source=B dest=A,
so this isn't able to indicate which side created a session_id.)

We could also write the session ID originator in an extension of the IE, so that the IE is uint32_t, and the originator follows after that.
The IE length can reflect that. Related: #4333