cellular-infrastructure
/
osmo-msc
mirror of https://gerrit.osmocom.org/osmo-msc
9
0
Fork 0
Code Issues Releases Wiki Activity
osmo-msc/openbsc
History
Pablo Neira Ayuso 93ffbd0029 libmsc: send RP-ACK to MS after ESME sends SMPP DELIVER-SM-RESP 
Hold on with the GSM 04.11 RP-ACK/RP-ERROR that we send to the MS until
we get a confirmation from the ESME, via SMPP DELIVER-SM-RESP, that we
can route this sms somewhere we can reach indeed.

After this change, the conversation looks like this:

    MS    GSM 03.40      SMSC   SMPP 3.4   ESME
     |                    |                 |
     |   SMS-SUBMIT       |                 |
     |------------------->|                 |
     |                    |    DELIVER-SM   |
     |                    |---------------->|
     |                    |                 |
     |                    | DELIVER-SM-RESP |
     |                    |<----------------|
     |  GSM 04.11 RP-ACK  |                 |
     |<-------------------|                 |
     |                    |                 |

Before this patch, the RP-ACK was sent back straight forward to the MS,
no matter if the sms can be route by the ESME or not. Thus, the user
ends up getting a misleading "message delivered" in their phone screen,
when the message may just be unroutable by the ESME hence silently
dropped.

If we get no reply from the ESME, there is a hardcoded timer that will
expire to send back an RP-ERROR to the MS indicating that network is
out-of-order. Currently this timer is arbitrarily set to 5 seconds. I
found no specific good default value on the SMPP 3.4 specs, section 7.2,
where the response_timer is described. There must be a place that
describes a better default value for this. We could also expose this
timer through VTY for configurability reasons, to be done later.

Given all this needs to happen asyncronously, ie. block the SMSC, this
patch extends the gsm_sms structure with two new fields to annotate
useful information to send the RP-ACK/RP-ERROR back to the MS of origin.
These new fields are:

* the GSM 04.07 transaction id, to look up for the gsm_trans object.

* the GSM 04.11 message reference so the MS of origin can correlate this
  response to its original request.

Tested here using python-libsmpp script that replies with
DELIVER_SM_RESP and status code 0x0b (Invalid Destination). I can see
here on my motorola C155 that message cannot be delivered. I have tested
with the success status code in the SMPP DELIVER_SM_RESP too.

Change-Id: I0d5bd5693fed6d4f4bd2951711c7888712507bfd
 		2017-05-08 17:15:12 +02:00
..
contrib gbproxy: add example .service 2017-04-26 16:21:43 +02:00
doc examples: remove logging level * everything 2017-03-15 13:01:12 +00:00
include libmsc: send RP-ACK to MS after ESME sends SMPP DELIVER-SM-RESP 2017-05-08 17:15:12 +02:00
m4 Remove dependency to autoconf-archive 2017-01-31 19:54:58 +01:00
src libmsc: send RP-ACK to MS after ESME sends SMPP DELIVER-SM-RESP 2017-05-08 17:15:12 +02:00
tests Use libosmocore for SW Description parsing 2017-05-08 11:49:40 +00:00
tools hlrstat: Print numeric MCC/MNC in case no name is available 2010-01-01 15:08:38 +01:00
.gitignore add struct bsc_subscr, separating libbsc from gsm_subscriber 2017-03-08 01:01:43 +01:00
AUTHORS AUTHORS: Add Jacob and Neels 2015-12-05 23:04:11 +01:00
COPYING License change: We are now AGPLv3+ instead of GPLv2+ 2011-01-01 15:39:34 +01:00
Makefile.am Attempt to fix nightly builds 2017-02-07 00:40:02 +00:00
README cosmetic: gsm_data.h, README: rename CSCN to MSC 2017-02-24 21:01:55 +01:00
README.vty-tests Add README.vty-tests 2016-01-28 13:36:07 +01:00
configure.ac Make pcap dependency optional 2017-05-02 13:43:06 +02:00
git-version-gen automatically include program version and print it from vty and --version 2010-03-23 00:09:32 +08:00
openbsc.pc.in Remove libs from openbsc.pc 2017-04-26 12:07:08 +02:00
osmoappdesc.py gtphub: Fix the VTY prompt to make the tests move forward 2015-12-14 15:24:50 +01:00

README 

About OpenBSC
=============

OpenBSC started as a minimalistic all-in-one implementation of the GSM Network,
with particular emphasis on the functionality typically provided by the BSC,
MSC, HLR, VLR and SMSC.  Today it is a growing suite of libraries and programs,
implementing protocol stacks and functional elements, including

 * OsmoBSC - a pure GSM BSC, speaking Abis/IP to the BTS and A/IP to the MSC
 * OsmoBSC-MGCP - MGCP helper to the OsmoBSC software
 * OsmoNITB - a BSC+MSC+VLR+HLR+SMSC "Network in the box".
 * OsmoMSC - a voice CN with A/IP and IuCS/IP towards the BSC and/or HNB-GW
 * OsmoSGSN - a GPRS SGSN with Gb/IP and IuPS/IP towards the PCU and/or HNB-GW
 * Osmo-GbProxy - a Proxy to aggregate many Gb links as one Gb link to the SGSN
 * OsmoBSCNAT - a gateway aggregating many A links as one A link to the MSC
 * OsmoGTPHUB - a hub aggregating many GTP links (between SGSN and GGSN)
 * ipaccess-utils - some tools to discover + configure ip.access nanoBTS
 * bs11_config - a tool to configure the Siemens BS-11 microBTS

Various interfaces towards the BTS are supported, among which are:

 * Classic A-bis over E1 using a mISDN based E1 interface. In other
   words, you can connect existing GSM Base Transceiver Station (BTS)
   through E1 to OpenBSC.  So far, we have made it work with the Siemens BS-11,
   various Ericsson RBS2xxx BTS models and the Nokia MetroSite.

 * A-bis over IP as used by the ip.access nanoBTS product family as well as
   the Open Source OsmoBTS software (by the same authors as OpenBSC).  OsmoBTS
   in turn supports various transceiver hardware, including the sysmoBTS
   product family, as well as SDR transceivers supported by OsmoTRX, such as
   the UmTRX or USRP boardss.

 * IuCS and IuPS over IP towards an HNB-GW (see osmo-iuh) for UMTS (3G)
   voice and data links.

Find OpenBSC online at
http://openbsc.osmocom.org/

	Harald Welte <laforge@gnumonks.org>