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
