Re: Internal rerouting issues

Hi,

Dziugas Baltrunas schrieb:
> Hi, Alex,
> 
> thanks for the reply.
> 
>> > 2. I expect reroute-smsc-id variable to explicitly reroute messages to
>> > the smsc connection having specified smsc-id. However, this is not
>> > true - my tests showed that sometimes messages are even "rerouted" to
>> > the SMSC which the message has originated (i.e. the one having
>> > reroute-smsc-id set). Looks like current workaround is to set
>> > denied-smsc-id to ID of the smsc messages should be routed to. Since
>> > I'm using store file, I'm guessing whether reason isn't due to we have
>> > store_save(msg) called _before_ msg->sms.smsc_id is set in in
>> > gw/bb_smscconn.c:route_incoming_to_smsc.
>>
>> this is intentionally and it's how bearerbox routing works also for
>> messages coming from smsbox. Here you should use 
>> [allowed|denied]-smsx-id.
> 
> I tend to disagree here. What's the purporse of the reroute-smsc-id
> parameter then and how it is different from reroute field? I will do a
> quote from user guide:
> 
> "reroute-smsc-id string Similar to 'reroute'. Defines the explicit
> smsc-id the MO message should be passed to for MT traffic. Hence all
> messages coming from the the configuration group smsc are passed to
> the outbound queue of the specified smsc-id. This allows direct
> proxying of messages between 2 smsc connections without injecting them
> to the general routing procedure in bearerbox."
> 
> So either we should change description in the user guide or make it
> function as written (that is, explicitly put messages to the queue of
> specified smsc).

Only the description should be changed. As I already said this behavior 
is intentional...

Please provide more appropriate description because I don't know how it 
should be described better (I'm not a native English speaker).


> 
> Moreover, I noticed one more minor issue with rerouting. One would
> expect that both source and destination TON/NPI would remain the same
> in submit_sm as they were in deliver_sm, however, they are not. What
> is more, even if, say, destination address has TON = 1, Kannel will
> not treat it as an international number since there are no "+" in the
> beginning and as a result it will set TON to 2 (national number).
> Again, having dest-addr-ton = 1 in the smsc group makes a "workaround"
> for international numbers.
>

That could be caused by receiver SMSC module if sending SMSC doesn't set 
ton/npi values to international. It's not a kannel fault but sending SMSC.

> Thanks,
> Dziugas
> 
>