Hi Nick, heh, I thought already that kannel 1.4.0 smpp is too strict ;) why kannel discard this message? that's pretty simple, ton/npi values are '0' (unknown/unknown) and source_addr/destination_addr are both with '+' in front but kannel allows nondigits addr _only_ if ton/npi values set appropriate. that's why kannel discard this mo message with error_code "invalid source addr".
what we can do: tyntec is already informed about this issue and maybe will change such behaviour... alternatively I will commit patch (next week) that will relax source/destination checks in kannel smpp. let's see who is faster ;) Nick Branson wrote: > Alex, > > As requested: > > 2004-12-23 14:27:47 [21212] [6] DEBUG: SMPP[tyntec]: Got PDU: > 2004-12-23 14:27:47 [21212] [6] DEBUG: SMPP PDU 0xa1226f8 dump: > 2004-12-23 14:27:47 [21212] [6] DEBUG: type_name: deliver_sm > 2004-12-23 14:27:47 [21212] [6] DEBUG: command_id: 5 = 0x00000005 > 2004-12-23 14:27:47 [21212] [6] DEBUG: command_status: 0 = 0x00000000 > 2004-12-23 14:27:47 [21212] [6] DEBUG: sequence_number: 161687 = > 0x00027797 > 2004-12-23 14:27:47 [21212] [6] DEBUG: service_type: NULL > 2004-12-23 14:27:47 [21212] [6] DEBUG: source_addr_ton: 0 = 0x00000000 > 2004-12-23 14:27:47 [21212] [6] DEBUG: source_addr_npi: 0 = 0x00000000 > 2004-12-23 14:27:47 [21212] [6] DEBUG: source_addr: "+440000000000" > 2004-12-23 14:27:47 [21212] [6] DEBUG: dest_addr_ton: 0 = 0x00000000 > 2004-12-23 14:27:47 [21212] [6] DEBUG: dest_addr_npi: 0 = 0x00000000 > 2004-12-23 14:27:47 [21212] [6] DEBUG: destination_addr: "+440000000000" > 2004-12-23 14:27:47 [21212] [6] DEBUG: esm_class: 0 = 0x00000000 > 2004-12-23 14:27:47 [21212] [6] DEBUG: protocol_id: 0 = 0x00000000 > 2004-12-23 14:27:47 [21212] [6] DEBUG: priority_flag: 0 = 0x00000000 > 2004-12-23 14:27:47 [21212] [6] DEBUG: schedule_delivery_time: NULL > 2004-12-23 14:27:47 [21212] [6] DEBUG: validity_period: NULL > 2004-12-23 14:27:47 [21212] [6] DEBUG: registered_delivery: 0 = > 0x00000000 > 2004-12-23 14:27:47 [21212] [6] DEBUG: replace_if_present_flag: 0 = > 0x00000000 > 2004-12-23 14:27:47 [21212] [6] DEBUG: data_coding: 0 = 0x00000000 > 2004-12-23 14:27:47 [21212] [6] DEBUG: sm_default_msg_id: 0 = 0x00000000 > 2004-12-23 14:27:47 [21212] [6] DEBUG: sm_length: 7 = 0x00000007 > 2004-12-23 14:27:47 [21212] [6] DEBUG: short_message: "Testinh" > 2004-12-23 14:27:47 [21212] [6] DEBUG: SMPP PDU dump ends. > 2004-12-23 14:27:47 [21212] [6] DEBUG: SMPP[tyntec]: Sending PDU: > 2004-12-23 14:27:47 [21212] [6] DEBUG: SMPP PDU 0xa122848 dump: > 2004-12-23 14:27:47 [21212] [6] DEBUG: type_name: deliver_sm_resp > 2004-12-23 14:27:47 [21212] [6] DEBUG: command_id: 2147483653 = > 0x80000005 > 2004-12-23 14:27:47 [21212] [6] DEBUG: command_status: 10 = 0x0000000a > 2004-12-23 14:27:47 [21212] [6] DEBUG: sequence_number: 161687 = > 0x00027797 > 2004-12-23 14:27:47 [21212] [6] DEBUG: message_id: NULL > 2004-12-23 14:27:47 [21212] [6] DEBUG: SMPP PDU dump ends. > > > Alexander Malysh <[EMAIL PROTECTED]> writes: > > hi, > > would you please post smpp pdu dump from bearerbox debug log for this > failed mo msg? > > Raymond wrote: > >> Nick Branson <nick <at> sign-up.to> writes: >> >>> >>> >>> Hey >>> users, >>> >>> >>> Having a >>> little problem with Kannel. I recently switched from using Kannel >>> 1.2.0 to a copy taken by CVS in early October. >>> >>> >>> It would >>> seem that when I receive an inbound MO message from my SMSC it's not >>> being passed to the�sms box. >>> >>> >>> I see the >>> message arrive in the bearerbox debugging. However, the smsbox >>> debugging >> remains >>> idle. My get-url for the service is not being called either. >>> >>> >> >> >> I am having the same problem... I could sent msg from SMPP emulator >> but the service could not be called... I looked in to "smsc_smpp.c" >> and couldnt really find out how they handle MO service kind of >> messages... for I do know MO for "smsc_http.c" is working... >> >> if anyone found a solution for it, kindly send me an email... thanks >> ya >> >> Regards, >> Ray > > -- > Thanks, > Alex -- Thanks, Alex
