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