Re: Malformed addr for Incoming short code

Hi,

Arne K. Haaje schrieb:
> Stipe Tolj wrote:
>> Amol Patwardhan wrote:
>>
>>> Hi Stipe/Alex,
>>>
>>> Please take a look at the SMPP PDU dump: Kannel bearerbox II version 
>>> cvs-20060110
>>>
>>> 2006-01-29 15:51:41 [12663] [6] DEBUG: SMPP[XXX]: Got PDU:
>>> 2006-01-29 15:51:41 [12663] [6] DEBUG: SMPP PDU 0x8a0c5e8 dump:
>>> 2006-01-29 15:51:41 [12663] [6] DEBUG:   type_name: deliver_sm
>>> 2006-01-29 15:51:41 [12663] [6] DEBUG:   command_id: 5 = 0x00000005
>>> 2006-01-29 15:51:41 [12663] [6] DEBUG:   command_status: 0 = 0x00000000
>>> 2006-01-29 15:51:41 [12663] [6] DEBUG:   sequence_number: 2 = 0x00000002
>>> 2006-01-29 15:51:41 [12663] [6] DEBUG:   service_type: NULL
>>> 2006-01-29 15:51:41 [12663] [6] DEBUG:   source_addr_ton: 1 = 0x00000001
>>> 2006-01-29 15:51:41 [12663] [6] DEBUG:   source_addr_npi: 1 = 0x00000001
>>> 2006-01-29 15:51:41 [12663] [6] DEBUG:   source_addr: "97339405477"
>>> 2006-01-29 15:51:41 [12663] [6] DEBUG:   dest_addr_ton: 1 = 0x00000001
>>> 2006-01-29 15:51:41 [12663] [6] DEBUG:   dest_addr_npi: 1 = 0x00000001
>>> 2006-01-29 15:51:41 [12663] [6] DEBUG:   destination_addr: "4900"
>>> 2006-01-29 15:51:41 [12663] [6] DEBUG:   esm_class: 0 = 0x00000000
>>> 2006-01-29 15:51:41 [12663] [6] DEBUG:   protocol_id: 0 = 0x00000000
>>> 2006-01-29 15:51:41 [12663] [6] DEBUG:   priority_flag: 0 = 0x00000000
>>> 2006-01-29 15:51:41 [12663] [6] DEBUG:   schedule_delivery_time: NULL
>>> 2006-01-29 15:51:41 [12663] [6] DEBUG:   validity_period: NULL
>>> 2006-01-29 15:51:41 [12663] [6] DEBUG:   registered_delivery: 0 = 
>>> 0x00000000
>>> 2006-01-29 15:51:41 [12663] [6] DEBUG:   replace_if_present_flag: 0 = 
>>> 0x00000000
>>> 2006-01-29 15:51:41 [12663] [6] DEBUG:   data_coding: 0 = 0x00000000
>>> 2006-01-29 15:51:41 [12663] [6] DEBUG:   sm_default_msg_id: 0 = 
>>> 0x00000000
>>> 2006-01-29 15:51:41 [12663] [6] DEBUG:   sm_length: 23 = 0x00000017
>>> 2006-01-29 15:51:41 [12663] [6] DEBUG:   short_message:
>>> 2006-01-29 15:51:41 [12663] [6] DEBUG:    Octet string at 0x8a0ca50:
>>> 2006-01-29 15:51:41 [12663] [6] DEBUG:      len:  23
>>> 2006-01-29 15:51:41 [12663] [6] DEBUG:      size: 24
>>> 2006-01-29 15:51:41 [12663] [6] DEBUG:      immutable: 0
>>> 2006-01-29 15:51:41 [12663] [6] DEBUG:      data: 0F 0F 0F 0F 0F 0F 
>>> 0F 02 05 00 02 02 0b 01 0c 0a   XXXXXXXBE XXXXXX
>>> 2006-01-29 15:51:41 [12663] [6] DEBUG:      data: 0c 02 02 0b 09 30 
>>> 03                              ,XXXXXX
>>> 2006-01-29 15:51:41 [12663] [6] DEBUG:    Octet string dump ends.
>>> 2006-01-29 15:51:41 [12663] [6] DEBUG: SMPP PDU dump ends.
>>> 2006-01-29 15:51:41 [12663] [6] ERROR: SMPP[MAR]: Mallformed addr 
>>> `4900', expected at least 7 digits.
>>>

[snip]

>>
>> yep, the following commit added the "checking":
>>
>> http://www.kannel.org/cgi-bin/viewcvs.cgi/gateway/gw/smsc/smsc_smpp.c.diff?r1=1.80&r2=1.81 
>>
>>
>> Unfortunatly the checking itself is correct, speaking in semantics of 
>> the SMPP protocoll. Which means the SMSC is mis-behaving.
>>
>> @Alex: is it enough to set 'dest-addr-ton', 'dest-addr-npi' inside 
>> smsc group to get rid of this. Or is the checking done before that and 
>> hence we baild out?
> 
> Yes, if we could set it ourself that would help a lot. I am seeing this 
> now on connections to two different operators with the latest snapshots. 
> Running an old snapshot (before the data_sm patch I think) make the 
> problem go away
> 

that could be added as a workaround for BUGGY SMSCs but there not too 
much of those nowadays.

>> @Amol: you should contact your SMSC provider and let them now that 
>> their desination-ton for the shortcode is not right, they should send 
>> the appropriate TON value for network internal numbers (shortcode).
> 
> I contacted on of the operators above regarding this, but they insisted 
> values were correct.  Thus, they were unwilling to change anything and I 
> had to downgrade to an older version
> 
> 

It's a bullshit what SMSC operator say. Ton=1/Npi=1 is international 
ISDN number planning. That mean that you should be able at least call 
this number from Landphone. Can you? I know the answer: no. Therefore 
is's a SMSC bug! SMSC should send with 0/0 (unknown/unknown) or at least 
1/2 (isdn/national)  or private/private.

Thanks,
Alex