SMPP Submit_SM sender address

historical

Yes, I figured that transaction mode should work, but we have to use
async mode here, unfortunately.

Regarding DB schema - Holger's patch looks sane to me. I would do it
the same way if I implemented it. I hope it'll lend to master when we
amend it with the DB update procedure.

On Thu, Aug 29, 2013 at 11:52 AM, Harald Welte <laforge at gnumonks.org> wrote:
> 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)

-- 
Regards,
Alexander Chemeris.
CEO, Fairwaves LLC / ООО УмРадио
http://fairwaves.ru