Re: USSD: Mallformed destination_addr `(null)', may not be empty. Discarding MO message
kayode tobi <[email protected]>
| Newsgroups | gmane.comp.mobile.kannel.devel |
|---|---|
| Message-ID | <[email protected]> |
Hi Andreas, Thank you for this. I will do this and revert with outcome. Thank you for your time. Best Regards, Kayode ________________________________ From: Andreas Fink <[email protected]> To: kayode tobi <[email protected]> Cc: devel Devel <[email protected]> Sent: Monday, 14 January 2013, 13:16 Subject: Re: USSD: Mallformed destination_addr `(null)', may not be empty. Discarding MO message 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 <[email protected]> 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 <[email protected]> >To: kayode tobi <[email protected]> >Cc: "[email protected]" <[email protected]> >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 <[email protected]> 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> > > >