I'm sure this can be patched to make it work. but its not really intentional to
have a field destination address.
the data is what the user types. As this is a session, this makes sense.
You can temporary comment out this section in gw/smsc/smsc_smpp.c (line 442-464
) to see if that works around the problem.
/*
* Follows SMPP spec. v3.4. issue 1.2
* it's not allowed to have destination_addr NULL
*/
if (pdu->u.deliver_sm.destination_addr == NULL) {
error(0, "SMPP[%s]: Malformed destination_addr `%s', may not be empty. "
"Discarding MO message.", octstr_get_cstr(smpp->conn->id),
octstr_get_cstr(pdu->u.deliver_sm.destination_addr));
*reason = SMPP_ESME_RINVDSTADR;
goto error;
}
On 14.01.2013, at 13:04, kayode tobi <kay4bl...@yahoo.co.uk> wrote:
> Hi Andreas,
>
> I am so grateful for your response.
>
> However, I have been to this supplier with this question, but they claim this
> is how they push requests to all connected clients via SMPP.
>
> Please look at this again:
>
> 2012-11-27 11:38:35 [6369] [6] DEBUG: SMPP[USSD]: throughput (0.00,0.00)
> 2012-11-27 11:38:35 [6369] [6] DEBUG: Optional parameter tag (0x001e)
> 2012-11-27 11:38:35 [6369] [6] DEBUG: Optional parameter length read as 33
> 2012-11-27 11:38:35 [6369] [6] DEBUG: Optional parameter tag (0x0202)
> 2012-11-27 11:38:35 [6369] [6] DEBUG: Optional parameter length read as 15
> 2012-11-27 11:38:35 [6369] [6] DEBUG: Optional parameter tag (0x0203)
> 2012-11-27 11:38:35 [6369] [6] DEBUG: Optional parameter length read as 13
> 2012-11-27 11:38:35 [6369] [6] DEBUG: Optional parameter tag (0x0501)
> 2012-11-27 11:38:35 [6369] [6] DEBUG: Optional parameter length read as 1
> 2012-11-27 11:38:35 [6369] [6] DEBUG: Found configured optional parameter
> `mydata'
> 2012-11-27 11:38:35 [6369] [6] DEBUG: Optional parameter tag (0x0424)
> 2012-11-27 11:38:35 [6369] [6] DEBUG: Optional parameter length read as 5
> 2012-11-27 11:38:35 [6369] [6] DEBUG: SMPP[USSD]: Got PDU:
> 2012-11-27 11:38:35 [6369] [6] DEBUG: SMPP PDU 0x7ff7c8001550 dump:
> 2012-11-27 11:38:35 [6369] [6] DEBUG: type_name: data_sm
> 2012-11-27 11:38:35 [6369] [6] DEBUG: command_id: 259 = 0x00000103
> 2012-11-27 11:38:35 [6369] [6] DEBUG: command_status: 0 = 0x00000000
> 2012-11-27 11:38:35 [6369] [6] DEBUG: sequence_number: 1 = 0x00000001
> 2012-11-27 11:38:35 [6369] [6] DEBUG: service_type: "USSD"
> 2012-11-27 11:38:35 [6369] [6] DEBUG: source_addr_ton: 1 = 0x00000001
> 2012-11-27 11:38:35 [6369] [6] DEBUG: source_addr_npi: 1 = 0x00000001
> 2012-11-27 11:38:35 [6369] [6] DEBUG: source_addr: "2347055932235"
> 2012-11-27 11:38:35 [6369] [6] DEBUG: dest_addr_ton: 0 = 0x00000000
> 2012-11-27 11:38:35 [6369] [6] DEBUG: dest_addr_npi: 0 = 0x00000000
> 2012-11-27 11:38:35 [6369] [6] DEBUG: destination_addr: NULL
> 2012-11-27 11:38:35 [6369] [6] DEBUG: esm_class: 1 = 0x00000001
> 2012-11-27 11:38:35 [6369] [6] DEBUG: registered_delivery: 0 = 0x00000000
> 2012-11-27 11:38:35 [6369] [6] DEBUG: data_coding: 0 = 0x00000000
> 2012-11-27 11:38:35 [6369] [6] DEBUG: message_payload:
> 2012-11-27 11:38:35 [6369] [6] DEBUG: Octet string at 0x7ff7c80018c0:
> 2012-11-27 11:38:35 [6369] [6] DEBUG: len: 5
> 2012-11-27 11:38:35 [6369] [6] DEBUG: size: 6
> 2012-11-27 11:38:35 [6369] [6] DEBUG: immutable: 0
> 2012-11-27 11:38:35 [6369] [6] DEBUG: data: aa 19 0c 36 02
> ...6.
> 2012-11-27 11:38:35 [6369] [6] DEBUG: Octet string dump ends.
> 2012-11-27 11:38:35 [6369] [6] DEBUG: receipted_message_id:
> "
> When the highlighted "data: aa 19 0c 36 02" was decripted, it revealed the
> code "*300#" which I presume should be the destination address.
>
> 1. Kindly enlighten me what this should be, because they claim my app
> (kannel) is what is not accepting the destination address.
>
> 2. Do you think I am missing anything in the kannel config? If yes, can u let
> me see a sample kannel USSD config?
>
> 3. Can I set configure kannel to accept NULL destination address?
>
> Thank you so much for your time.
>
>
> Best Regards,
> Kayode
>
>
>
>
>
>
>
>
>
> From: Andreas Fink <af...@list.fink.org>
> To: kayode tobi <kay4bl...@yahoo.co.uk>
> Cc: "devel@kannel.org" <devel@kannel.org>
> Sent: Monday, 14 January 2013, 9:20
> Subject: Re: USSD: Mallformed destination_addr `(null)', may not be empty.
> Discarding MO message
>
> there is your error in the log:
>
> 2012-11-27 11:38:35 [6369] [6] DEBUG: dest_addr_ton: 0 = 0x00000000
> 2012-11-27 11:38:35 [6369] [6] DEBUG: dest_addr_npi: 0 = 0x00000000
> 2012-11-27 11:38:35 [6369] [6] DEBUG: destination_addr: NULL
> 2012-11-27 11:38:35 [6369] [6] ERROR: SMPP[USSD]: Mallformed destination_addr
> `(null)', may not be empty. Discarding MO message.
>
> talk to your supplier and ask them why they send you no destination address.
>
> On 14.01.2013, at 09:11, kayode tobi <kay4bl...@yahoo.co.uk> wrote:
>
>>
>> Hi Team,
>>
>> I have been very successful in using kannel (with binds to SMSC) to deliver
>> MT messages to handsets.
>>
>> I have just been given a project that involves receiving MO messages from a
>> USSD gateway and I am getting the Error above.
>>
>> When I send *300# from the phone, I get "USSDC: Rejected by ESME" back on
>> the phone.
>>
>> Attached to this mail is the complete error from my log and my kannel config
>> (Kannel bearerbox version `svn-r4979M')
>>
>> Kindly assist to check where this error is coming from and if I am doing
>> something wrong.
>>
>> Thank you
>>
>> Best Regards,
>> Kayode
>>
>>
>>
>>
>>
>>
>>
>>
>> <COMPLETE ERROR><KANNEL CONF>
>
>
>
