SMPP Submit_SM sender address

[Harald Welte]

One more comment in addition to Holgers response:

The problem you are describing only exists in store-and-forward mode, it
doesn' exist when you select SMPP transaction mode.  In the latter case,
the SMS is not queued but immediately delivered to the MS, and an error
returned if the MS is not reachable.

And yes, the DB schema has to change, definitely.  It was wrong to put
the subscriber IDs in the SMS table in the first place.

Regards,
	Harald

On Wed, Aug 28, 2013 at 11:17:37PM +0400, Alexander Chemeris wrote:
> Hi Harald,
> 
> We're trying out SMPP interconnection and found that for Submit_SM
> (aka MT-SMS) sender is always set to an extension of subscriber ID 1.
> 
> Looking into the code, this happens because we set "sms->sender" to
> point to subscriber ID 1 in submit_to_sms() function in SMPP code:
> 
> /* fill in the source address */
> sms->sender = subscr_get_by_id(net, 1);
> sms->src.ton = submit->source_addr_ton;
> sms->src.npi = submit->source_addr_npi;
> strncpy(sms->src.addr, (char *)submit->source_addr, sizeof(sms->src.addr)-1);
> 
> And then src.addr/ton/npi are ignored when we store to the SMS DB and
> only subscriber ID is stored:
> 
> /* FIXME: correct validity period */
> result = dbi_conn_queryf(conn,
>     "INSERT INTO SMS "
>     "(created, sender_id, receiver_id, valid_until, "
>     "reply_path_req, status_rep_req, protocol_id, "
>     "data_coding_scheme, ud_hdr_ind, dest_addr, "
>     "user_data, text) VALUES "
>     "(datetime('now'), %llu, %llu, %u, "
>     "%u, %u, %u, %u, %u, %s, %s, %s)",
>     sms->sender->id,
>     sms->receiver ? sms->receiver->id : 0, validity_timestamp,
>     sms->reply_path_req, sms->status_rep_req, sms->protocol_id,
>     sms->data_coding_scheme, sms->ud_hdr_ind,
>     q_daddr, q_udata, q_text);
> 
> So when we read SMS back from the DB, sender address is taken from
> that subscriber.
> 
> It seems that a solution is to store actual ton/npi/addr in the SMS DB
> instead of storing ID. Then we could set sms->sender to NULL and just
> ignore it.
> 
> Is there anything wrong with this approach? Otherwise we'll work on a
> patch to implement that.
> 
> PS What is the current policy about changing DB layouts - just
> increase SCHEMA_REVISION?
> 
> -- 
> Regards,
> Alexander Chemeris.
> CEO, Fairwaves LLC / ООО УмРадио
> http://fairwaves.ru

-- 
- Harald Welte <laforge at gnumonks.org>           http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
                                                  (ETSI EN 300 175-7 Ch. A6)