29 Aug
2013
29 Aug
'13
7 p.m.
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(a)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:
--
Regards,
Alexander Chemeris.
CEO, Fairwaves LLC / ООО УмРадио
http://fairwaves.ru
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(a)gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)