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
diff --git a/openbsc/src/libmsc/gsm_04_11.c b/openbsc/src/libmsc/gsm_04_11.c
index a94b971..aa2030f 100644
--- a/openbsc/src/libmsc/gsm_04_11.c
+++ b/openbsc/src/libmsc/gsm_04_11.c
@@ -278,7 +278,7 @@
 }
 
 int sms_route_mt_sms(struct gsm_subscriber_connection *conn, struct msgb *msg,
-			struct gsm_sms *gsms, uint8_t sms_mti)
+		     struct gsm_sms *gsms, uint8_t sms_mti, bool *deferred)
 {
 	int rc;
 
@@ -292,7 +292,7 @@
 	 * delivery of the SMS.
 	 */
 	if (smpp_first) {
-		rc = smpp_try_deliver(gsms, conn);
+		rc = smpp_try_deliver(gsms, conn, deferred);
 		if (rc == GSM411_RP_CAUSE_MO_NUM_UNASSIGNED)
 			goto try_local;
 		if (rc < 0) {
@@ -320,7 +320,7 @@
 			return GSM411_RP_CAUSE_MO_NUM_UNASSIGNED;
 		}
 
-		rc = smpp_try_deliver(gsms, conn);
+		rc = smpp_try_deliver(gsms, conn, deferred);
 		if (rc == GSM411_RP_CAUSE_MO_NUM_UNASSIGNED) {
 			rate_ctr_inc(&conn->network->msc_ctrs->ctr[MSC_CTR_SMS_NO_RECEIVER]);
 		} else if (rc < 0) {
@@ -363,8 +363,10 @@
 
 /* process an incoming TPDU (called from RP-DATA)
  * return value > 0: RP CAUSE for ERROR; < 0: silent error; 0 = success */
-static int gsm340_rx_tpdu(struct gsm_subscriber_connection *conn, struct msgb *msg)
+static int gsm340_rx_tpdu(struct gsm_trans *trans, struct msgb *msg,
+			  uint32_t gsm411_msg_ref, bool *deferred)
 {
+	struct gsm_subscriber_connection *conn = trans->conn;
 	uint8_t *smsp = msgb_sms(msg);
 	struct gsm_sms *gsms;
 	unsigned int sms_alphabet;
@@ -395,6 +397,9 @@
 	smsp++;
 	gsms->msg_ref = *smsp++;
 
+	gsms->gsm411.transaction_id = trans->transaction_id;
+	gsms->gsm411.msg_ref = gsm411_msg_ref;
+
 	/* length in bytes of the destination address */
 	da_len_bytes = 2 + *smsp/2 + *smsp%2;
 	if (da_len_bytes > 12) {
@@ -481,9 +486,10 @@
 	/* FIXME: This looks very wrong */
 	send_signal(0, NULL, gsms, 0);
 
-	rc = sms_route_mt_sms(conn, msg, gsms, sms_mti);
+	rc = sms_route_mt_sms(conn, msg, gsms, sms_mti, deferred);
 out:
-	sms_free(gsms);
+	if (!deferred)
+		sms_free(gsms);
 
 	return rc;
 }
@@ -505,7 +511,7 @@
 	return gsm411_smr_send(inst, rl_msg_type, msg);
 }
 
-static int gsm411_send_rp_ack(struct gsm_trans *trans, uint8_t msg_ref)
+int gsm411_send_rp_ack(struct gsm_trans *trans, uint8_t msg_ref)
 {
 	struct msgb *msg = gsm411_msgb_alloc();
 
@@ -515,8 +521,8 @@
 		msg_ref, GSM411_SM_RL_REPORT_REQ);
 }
 
-static int gsm411_send_rp_error(struct gsm_trans *trans,
-				uint8_t msg_ref, uint8_t cause)
+int gsm411_send_rp_error(struct gsm_trans *trans, uint8_t msg_ref,
+			 uint8_t cause)
 {
 	struct msgb *msg = gsm411_msgb_alloc();
 
@@ -536,6 +542,7 @@
 			  uint8_t dst_len, uint8_t *dst,
 			  uint8_t tpdu_len, uint8_t *tpdu)
 {
+	bool deferred = false;
 	int rc = 0;
 
 	if (src_len && src)
@@ -552,8 +559,8 @@
 
 	DEBUGP(DLSMS, "DST(%u,%s)\n", dst_len, osmo_hexdump(dst, dst_len));
 
-	rc = gsm340_rx_tpdu(trans->conn, msg);
-	if (rc == 0)
+	rc = gsm340_rx_tpdu(trans, msg, rph->msg_ref, &deferred);
+	if (rc == 0 && !deferred)
 		return gsm411_send_rp_ack(trans, rph->msg_ref);
 	else if (rc > 0)
 		return gsm411_send_rp_error(trans, rph->msg_ref, rc);