This is an incompatible database schema change. Store the type of
the address in the database for both the sender and the receiver.
Currently it is possible to use SMPP to store a SMS and the NPI
and TON will be lost on the delivery of the SMS. The schema is
changed to make the delivery always use the right NPI/TON. This
patch is not ready for the master branch as there is no upgrade
path for the HLR yet.
As can clearly be seen from SMPP Spec v3.4 Chapter 5.2.19,
a SUBMIT-SM with data_coding == 0x08 is UCS2, not with 0x80.
Thanks to ciaby@rhizomatica.org for reporting the bug.
There's a VTY option by which for every ESME the user can specify if the
E.212 or E.164 number should be used in DELIVER-SM. The ALERT
notifications generate by subscriber LU have so far always contained the
E.212 (IMSI) rather than E.164 (MSISDN) which is a bit inconsistent.
Rather than copying code, we create a new function that implements
ALERTing all ESMEs.
If the MS memory for SMS is exceeded and we get an RP-layer error, we
need to report that back to the (transaction-mode) ESME. Otherwise the
ESME will wait forever after sending a SUBMIT-SM without ever receiving
a response to it.
Thanks to Holger for catching this.
Make sure to not ever have issues with this code again, move the
utility code to a new file and create a basic testcase. The method
currently has 100% line and branch coverage. My initial patched
missed the smpp_utils.c file and I re-did the copying (and verifying
the branch coverage)
The esme->acl is treated like it can be NULL in other places
of the code. Assume it can be NULL during this check as well.
Dereference after null check (FORWARD_NULL)
9. var_deref_op: Dereferencing null pointer "esme->acl".
Fixes: Coverity CID 1042374
As Holger pointed out, they contained a GPLv2+ disclaimer rather than
the AGPLv3+ which we use for OpenBSC. This is not an incompaibility,
but was done unintentionally. The code was always mean to be under
AGPLv3+.
Nevertheless, anyone using those two files in a version up to this
commit have the right to use it under GPLv2+ as well. This is not
applicable for any versions after this commit.
If an ESME has the dcs_transparent config flag, then the TP-DCS
of MO-SMS is transparently passed to SMPP and not converted to SMPP
specific data_coding values.
This is needed in cases where ESMEs actually care about the exact
TP-DCS, as the conversion from TP-DCS to SMPP data_coding is not
bijective.
There are multiple ways how the TS 03.38 TP-DCS can indicate 8bit or
7bit messages. SMPP has it's own data coding specification, which is
different from TS 03.38.
However, some SMPP ESMEs want to be able to have fine-grained control
over the TP-DCS indicated in the TPDU header. If such values like 0xF6
are used in SMPP, we now transparently pass them on to the GSM side.
An ESME can now be configured in the VTY to enable osmocom-extensions,
which will add vendor-specific SMPP TLVs for RxLev/RxQual/ARFCN/IMEI and
transmit power to the SMPP DELIVER-SM message type.
As bsc_gsmnet is NULL at the time we call smpp_openbsc_init(),
we later run into segfaults with subscribers that don't have a
subscr->net set.
However, we cannot delay smpp_openbsc_init() until after
bsc_bootstrap_network(), as we then fail to parse the SMPP specific
VTY/config file options...