Support #4333


GSUP binary compatibility: add GSUP protocol version IE?

Added by neels about 4 years ago.

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


Spec Reference:


I think it would be good to discuss binary compat in GSUP in general.
We're currently putting more and more functionality and weight on GSUP,
especially with D-GSM connecting several otherwise independent sites.
If we ever need to enhance parts of the protocol, it would be good to do
it in a way that allows in-band knowledge about what the coding should be.

  • introduce ToN/NPI to MSISDN coding; this applies to the plain MSISDN IE,
    as well as the SMS-over-GSUP OA and DA IEs.
  • I am tweaking the Routing Error coding, where originally it sent the Source Name and Destination Name back unchanged
    -- which does not make sense when proxy routing comes into the picture.
    The Source/Destination Name must be swapped so that the error message reaches the originator of the request.

One way would be to add new IEs for each change, either to supplement or replace previous IEs.
But to, for example, add ToN/NPI to MSISDN encoding, should be add new IEs for all of
MSISDN, SMS-OA and SMS-DA MSISDNs? Rather not. Should we add a new Routing Error message type? no.

It seems to me that the generally cleanest way to tweak the GSUP protocol
coding would be to introduce a protocol version IE.
Then we could allow clients to encode in both old and new formats...

To not send a new coding to an old client, osmo-hlr would also
need to keep track of which GSUP site speaks which protocol version.

Another way would be to add explicit new IEs for every binary incompatibility,
either supplementing current IEs, or replacing them (and using a new IE discriminator).

One idea is a protocol version communicated during IPA handshake,
where the client also sends the IPA unit name.
A problem here is that a GSUP proxy may have recent protocol capability, while it forwards for older clients.
If an older client is proxied, the final destination may still assume a newer client only because
the proxy in-between is.

Another idea is a Version IE (osmo_gsup_message.version), that can be sent for every GSUP message.
Absence of the version tag would imply version == 0. It would in fact only be strictly required to be included
if any encoded IE has an encoding that is not identical to version 0.

The gsup.c encoding/decoding could then switch() on the protocol version and encode/decode differently.

Does it make sense to implement such, for example to fix the MSISDN coding in SMS-over-GSUP and the plain MSISDN IE at the same time,
and to indicate that the Routing Error response contains the original requestor as Destination Name?

Related issues

Related to OsmoMSC - Bug #4324: SMS-over-GSUP: inconsistent SM-RP DA/OA codingResolvedfixeria12/13/2019

Related to OsmoMSC - Bug #2883: GSUP encoding of MSISDN is wrongNew01/26/2018

Related to OsmoMSC - Bug #3294: transaction: refactor callref allocationStalledneels05/26/2018

Actions #1

Updated by neels about 4 years ago

  • Related to Bug #4324: SMS-over-GSUP: inconsistent SM-RP DA/OA coding added
Actions #2

Updated by neels about 4 years ago

  • Related to Bug #2883: GSUP encoding of MSISDN is wrong added
Actions #3

Updated by neels about 4 years ago

  • Related to Bug #3294: transaction: refactor callref allocation added

Also available in: Atom PDF

Add picture from clipboard (Maximum size: 48.8 MB)