This is merely a historical archive of years 2008-2021, before the migration to mailman3.
A maintained and still updated list archive can be found at https://lists.osmocom.org/hyperkitty/list/osmocom-commitlog@lists.osmocom.org/.
gitosis at osmocom.org gitosis at osmocom.orgThis is an automated email from the git hooks/post-receive script. It was generated because a ref change was pushed to the repository containing the project "The OpenBSC GSM Base Station Controller (+MSC/HLR/SGSN)". The branch, master has been updated via 93ffbd0029d1200dfa51a0e68b4c11743f1cc0e8 (commit) from 638ad068e8597af81dc985d3d256ccc26e82373b (commit) Those revisions listed above that are new to this repository have not appeared on any other notification email; so we list those revisions in full, below. - Log ----------------------------------------------------------------- http://cgit.osmocom.org/openbsc/commit/?id=93ffbd0029d1200dfa51a0e68b4c11743f1cc0e8 commit 93ffbd0029d1200dfa51a0e68b4c11743f1cc0e8 Author: Pablo Neira Ayuso <pablo at gnumonks.org> Date: Thu May 4 18:44:22 2017 +0200 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 ----------------------------------------------------------------------- Summary of changes: openbsc/include/openbsc/gsm_04_11.h | 5 ++ openbsc/include/openbsc/gsm_data.h | 5 ++ openbsc/src/libmsc/gsm_04_11.c | 29 ++++---- openbsc/src/libmsc/smpp_openbsc.c | 127 ++++++++++++++++++++++++++++++++++-- openbsc/src/libmsc/smpp_smsc.c | 17 +++++ openbsc/src/libmsc/smpp_smsc.h | 18 ++++- 6 files changed, 184 insertions(+), 17 deletions(-) hooks/post-receive -- The OpenBSC GSM Base Station Controller (+MSC/HLR/SGSN)