Re: [Couldnot parse DLR string sscanf way, fallback to old way. Please report!] -- problem with message id
]: got DLR but could not find message or was not interested in it id<> dst<79028710256>, type<2>* 22.08.2016 12:58, amal...@kannel.org пишет: Hi, please try SVN version. Looks like 1.4.4 has issue with TLVs… Alex Am 15.08.2016 um 06:43 schrieb Черепанов Алексей Владиславович <sw_cherepa...@motivtelecom.ru <mailto:sw_cherepa...@motivtelecom.ru>>: Here's the dump of packets. *Short Message Peer to Peer, Command: Submit_sm - resp, Status: "Ok", Seq: 684, Len: 25 *Length: 25 Operation: Submit_sm - resp (0x8004) Result: Ok (0x) Sequence #: 684 Message id.: 2D8B40B4 *Short Message Peer to Peer, Command: Deliver_sm, Seq: 674395051, Len: 95* Length: 95 Operation: Deliver_sm (0x0005) Sequence #: 674395051 Service type: (Default) Type of number (originator): International (0x01) Numbering plan indicator (originator): ISDN (E163/E164) (0x01) Originator address: 79028710256 Type of number (recipient): International (0x01) Numbering plan indicator (recipient): ISDN (E163/E164) (0x01) Recipient address: 343269 ..00 = Messaging mode: Default SMSC mode (0x00) ..00 01.. = Message type: Short message contains SMSC Delivery Receipt (0x01) 00.. = GSM features: No specific features selected (0x00) Protocol id.: 0x7f Priority level: GSM: None ANSI-136: Bulk IS-95: Normal (0x00) Scheduled delivery time: Immediate delivery Validity period: SMSC default validity period ..00 = Delivery receipt: No SMSC delivery receipt requested (0x00) 00.. = Message type: No recipient SME acknowledgement requested (0x00) ...0 = Intermediate notif: No intermediate notification requested (0x00) ...0 = Replace: Don't replace (0x00) Data coding: 0x00 SMPP Data Coding Scheme: SMSC default alphabet (0x00) GSM SMS Data Coding = DCS Coding Group for SMS: SMS DCS: General Data Coding indication - Uncompressed text, no message class (0x00) ..0. = DCS Text compression: Uncompressed text ...0 = DCS Class present: No message class 00.. = DCS Character set: GSM 7-bit default alphabet (0x00) GSM CBS Data Coding = DCS Coding Group for CBS: CBS DCS: Language using the GSM 7-bit default alphabet (0x00) ..00 = DCS CBS Message language: German (0x00) Predefined message: 0 Message length: 0 Optional parameters Optional parameter: message_state (0x0427) Tag: 0x0427 Length: 1 Message state: DELIVERED (2) Optional parameter: network_error_code (0x0423) Tag: 0x0423 Length: 3 Error type: GSM (3) Error code: 0x Optional parameter: receipted_message_id (0x001e) Tag: 0x001e Length: 9 SMSC identifier: 2D8B40B4 Optional parameter: source_subaddress (0x0202) Tag: 0x0202 Length: 12 Source Subaddress: a03739303238373130303939 14.08.2016 20:07, Rene Kluwen пишет: Even, the message appears in your log files. If you set the debug level high enough, you can just see it appear there. -Oorspronkelijk bericht- Van: devel [mailto:devel-boun...@kannel.org] Namens Milan P. Stanic Verzonden: zondag 14 augustus 2016 12:44 Aan:devel@kannel.org Onderwerp: Re: [Couldnot parse DLR string sscanf way,fallback to old way. Please report!] -- problem with message id On Fri, 2016-08-12 at 15:27, Черепанов Алексей Владиславович wrote: Hi, there. Having a problem with handling deliver_sm. Kannel couldn't parse message id: 2016-08-12 14:45:59 [2952] [6] DEBUG: SMPP[SMSC]: Couldnot parse DLR string sscanf way,fallback to old way. Please report! 2016-08-12 14:45:59 [2952] [6] ERROR: SMPP[SMSC]: got DLR but could not find message or was not interested in it id<> dst<79028710256>, type<2> 2016-08-12 14:45:59 [2952] [6] DEBUG: message_id: NULL Look like your provider (upstream SMPP server) does not send 'standard' DLR message. Actually there is no standard format for DLR message but most providers format it following sample in SMPP specification document. Could you check with your provider in what format their server send message to your kannel. Or, you can extract it with some network capture tools (tcpdump, tshark/wireshark) and see in what format messages are. -- С уважением, Черепанов Алексей -- С уважением, Черепанов Алексей -- С уважением, Черепанов Алексей
Re: [Couldnot parse DLR string sscanf way, fallback to old way. Please report!] -- problem with message id
[18226] [6] DEBUG: size: 4 > > 2016-08-22 16:14:53 [18226] [6] DEBUG: immutable: 0 > > 2016-08-22 16:14:53 [18226] [6] DEBUG: data: 03 00 00 > > ... > > 2016-08-22 16:14:53 [18226] [6] DEBUG:Octet string dump ends. > > 2016-08-22 16:14:53 [18226] [6] DEBUG: message_state: 2 = 0x0002 > > 2016-08-22 16:14:53 [18226] [6] DEBUG: receipted_message_id: "13F19886" > > 2016-08-22 16:14:53 [18226] [6] DEBUG: SMPP PDU dump ends. > > 2016-08-22 16:14:53 [18226] [6] DEBUG: SMPP[SMSC] handle_pdu, got DLR > > 2016-08-22 16:14:53 [18226] [6] DEBUG: SMPP[SMSC]: Could not parse DLR > > string sscanf way, fallback to old way. Please report! > > 2016-08-22 16:14:53 [18226] [6] ERROR: SMPP[SMSC]: got DLR but could not > > find message or was not interested in it id<> dst<79028710256>, type<2> > > > > > > > > > > 22.08.2016 12:58, amal...@kannel.org <mailto:amal...@kannel.org> пишет: > >> Hi, > >> > >> please try SVN version. Looks like 1.4.4 has issue with TLVs… > >> > >> Alex > >> > >> > >>> Am 15.08.2016 um 06:43 schrieb Черепанов Алексей Владиславович > >>> <sw_cherepa...@motivtelecom.ru <mailto:sw_cherepa...@motivtelecom.ru>>: > >>> > >>> Here's the dump of packets. > >>> > >>> > >>> Short Message Peer to Peer, Command: Submit_sm - resp, Status: "Ok", Seq: > >>> 684, Len: 25 > >>> Length: 25 > >>> Operation: Submit_sm - resp (0x8004) > >>> Result: Ok (0x) > >>> Sequence #: 684 > >>> Message id.: 2D8B40B4 > >>> > >>> Short Message Peer to Peer, Command: Deliver_sm, Seq: 674395051, Len: 95 > >>> Length: 95 > >>> Operation: Deliver_sm (0x0005) > >>> Sequence #: 674395051 > >>> Service type: (Default) > >>> Type of number (originator): International (0x01) > >>> Numbering plan indicator (originator): ISDN (E163/E164) (0x01) > >>> Originator address: 79028710256 > >>> Type of number (recipient): International (0x01) > >>> Numbering plan indicator (recipient): ISDN (E163/E164) (0x01) > >>> Recipient address: 343269 > >>> ..00 = Messaging mode: Default SMSC mode (0x00) > >>> ..00 01.. = Message type: Short message contains SMSC Delivery > >>> Receipt (0x01) > >>> 00.. = GSM features: No specific features selected (0x00) > >>> Protocol id.: 0x7f > >>> Priority level: GSM: None ANSI-136: Bulk IS-95: Normal > >>> (0x00) > >>> Scheduled delivery time: Immediate delivery > >>> Validity period: SMSC default validity period > >>> ..00 = Delivery receipt: No SMSC delivery receipt requested > >>> (0x00) > >>> 00.. = Message type: No recipient SME acknowledgement requested > >>> (0x00) > >>> ...0 = Intermediate notif: No intermediate notification > >>> requested (0x00) > >>> ...0 = Replace: Don't replace (0x00) > >>> Data coding: 0x00 > >>> SMPP Data Coding Scheme: SMSC default alphabet (0x00) > >>> GSM SMS Data Coding > >>> = DCS Coding Group for SMS: SMS DCS: General Data > >>> Coding indication - Uncompressed text, no message class (0x00) > >>> ..0. = DCS Text compression: Uncompressed text > >>> ...0 = DCS Class present: No message class > >>> 00.. = DCS Character set: GSM 7-bit default alphabet (0x00) > >>> GSM CBS Data Coding > >>> = DCS Coding Group for CBS: CBS DCS: Language using the > >>> GSM 7-bit default alphabet (0x00) > >>> ..00 0000 = DCS CBS Message language: German (0x00) > >>> Predefined message: 0 > >>> Message length: 0 > >>> Optional parameters > >>> Optional parameter: message_state (0x0427) > >>> Tag: 0x0427 > >>> Length: 1 > >>> Message state: DELIVERED (2) > >>> Optional parameter: network_error_code (0x0423) > >>> Tag: 0x0423 > >>> Length: 3 > >>> Error type: GSM (3) > >
Re: [Couldnot parse DLR string sscanf way, fallback to old way. Please report!] -- problem with message id
to old way. Please report! > 2016-08-22 16:14:53 [18226] [6] ERROR: SMPP[SMSC]: got DLR but could not find > message or was not interested in it id<> dst<79028710256>, type<2> > > > > > 22.08.2016 12:58, amal...@kannel.org <mailto:amal...@kannel.org> пишет: >> Hi, >> >> please try SVN version. Looks like 1.4.4 has issue with TLVs… >> >> Alex >> >> >>> Am 15.08.2016 um 06:43 schrieb Черепанов Алексей Владиславович >>> <sw_cherepa...@motivtelecom.ru <mailto:sw_cherepa...@motivtelecom.ru>>: >>> >>> Here's the dump of packets. >>> >>> >>> Short Message Peer to Peer, Command: Submit_sm - resp, Status: "Ok", Seq: >>> 684, Len: 25 >>> Length: 25 >>> Operation: Submit_sm - resp (0x8004) >>> Result: Ok (0x) >>> Sequence #: 684 >>> Message id.: 2D8B40B4 >>> >>> Short Message Peer to Peer, Command: Deliver_sm, Seq: 674395051, Len: 95 >>> Length: 95 >>> Operation: Deliver_sm (0x0005) >>> Sequence #: 674395051 >>> Service type: (Default) >>> Type of number (originator): International (0x01) >>> Numbering plan indicator (originator): ISDN (E163/E164) (0x01) >>> Originator address: 79028710256 >>> Type of number (recipient): International (0x01) >>> Numbering plan indicator (recipient): ISDN (E163/E164) (0x01) >>> Recipient address: 343269 >>> ..00 = Messaging mode: Default SMSC mode (0x00) >>> ..00 01.. = Message type: Short message contains SMSC Delivery Receipt >>> (0x01) >>> 00.. = GSM features: No specific features selected (0x00) >>> Protocol id.: 0x7f >>> Priority level: GSM: None ANSI-136: Bulk IS-95: Normal >>> (0x00) >>> Scheduled delivery time: Immediate delivery >>> Validity period: SMSC default validity period >>> ..00 = Delivery receipt: No SMSC delivery receipt requested (0x00) >>> 00.. = Message type: No recipient SME acknowledgement requested >>> (0x00) >>> ...0 = Intermediate notif: No intermediate notification requested >>> (0x00) >>> ...0 = Replace: Don't replace (0x00) >>> Data coding: 0x00 >>> SMPP Data Coding Scheme: SMSC default alphabet (0x00) >>> GSM SMS Data Coding >>> = DCS Coding Group for SMS: SMS DCS: General Data Coding >>> indication - Uncompressed text, no message class (0x00) >>> ..0. = DCS Text compression: Uncompressed text >>> ...0 = DCS Class present: No message class >>> 00.. = DCS Character set: GSM 7-bit default alphabet (0x00) >>> GSM CBS Data Coding >>> = DCS Coding Group for CBS: CBS DCS: Language using the >>> GSM 7-bit default alphabet (0x00) >>> ..00 = DCS CBS Message language: German (0x00) >>> Predefined message: 0 >>> Message length: 0 >>> Optional parameters >>> Optional parameter: message_state (0x0427) >>> Tag: 0x0427 >>> Length: 1 >>> Message state: DELIVERED (2) >>> Optional parameter: network_error_code (0x0423) >>> Tag: 0x0423 >>> Length: 3 >>> Error type: GSM (3) >>> Error code: 0x >>> Optional parameter: receipted_message_id (0x001e) >>> Tag: 0x001e >>> Length: 9 >>> SMSC identifier: 2D8B40B4 >>> Optional parameter: source_subaddress (0x0202) >>> Tag: 0x0202 >>> Length: 12 >>> Source Subaddress: a03739303238373130303939 >>> >>> >>> 14.08.2016 20:07, Rene Kluwen пишет: >>>> Even, the message appears in your log files. >>>> If you set the debug level high enough, you can just see it appear there. >>>> >>>> -Oorspronkelijk bericht- >>>> Van: devel [mailto:devel-boun...@kannel.org >>>> <mailto:devel-boun...@kannel.org>] Namens Milan P. Stanic >>>> Verzonden: zondag 14 augustus 2016 12:44 >>>> Aan: devel@kannel.org <mailto:devel@kannel.org> >>>> Onderwerp: Re: [Couldnot parse DLR string sscanf way,fallback to old way. >>>> Please report!] -- problem with message id >>>> >>>> On Fri, 2016-08-12 at 15:27, Черепанов Алексей Владиславович wrote: >>>>> Hi, there. Having a problem with handling deliver_sm. >>>>> Kannel couldn't parse message id: >>>>> >>>>> 2016-08-12 14:45:59 [2952] [6] DEBUG: SMPP[SMSC]: Couldnot parse DLR >>>>> string sscanf way,fallback to old way. Please report! >>>>> 2016-08-12 14:45:59 [2952] [6] ERROR: SMPP[SMSC]: got DLR but could >>>>> not find message or was not interested in it id<> dst<79028710256>, >>>>> type<2> >>>>> 2016-08-12 14:45:59 [2952] [6] DEBUG: message_id: NULL >>>> Look like your provider (upstream SMPP server) does not send 'standard' >>>> DLR message. >>>> Actually there is no standard format for DLR message but most providers >>>> format it following sample in SMPP specification document. >>>> >>>> Could you check with your provider in what format their server send >>>> message to your kannel. Or, you can extract it with some network capture >>>> tools (tcpdump, tshark/wireshark) and see in what format messages are. >>>> >>>> >>>> >>> >>> -- >>> С уважением, >>> Черепанов Алексей >> > > -- > С уважением, > Черепанов Алексей
Re: [Couldnot parse DLR string sscanf way, fallback to old way. Please report!] -- problem with message id
;Ok", Seq: 684, Len: 25 *Length: 25 Operation: Submit_sm - resp (0x8004) Result: Ok (0x) Sequence #: 684 Message id.: 2D8B40B4 *Short Message Peer to Peer, Command: Deliver_sm, Seq: 674395051, Len: 95* Length: 95 Operation: Deliver_sm (0x0005) Sequence #: 674395051 Service type: (Default) Type of number (originator): International (0x01) Numbering plan indicator (originator): ISDN (E163/E164) (0x01) Originator address: 79028710256 Type of number (recipient): International (0x01) Numbering plan indicator (recipient): ISDN (E163/E164) (0x01) Recipient address: 343269 ..00 = Messaging mode: Default SMSC mode (0x00) ..00 01.. = Message type: Short message contains SMSC Delivery Receipt (0x01) 00.. = GSM features: No specific features selected (0x00) Protocol id.: 0x7f Priority level: GSM: None ANSI-136: Bulk IS-95: Normal (0x00) Scheduled delivery time: Immediate delivery Validity period: SMSC default validity period ..00 = Delivery receipt: No SMSC delivery receipt requested (0x00) 00.. = Message type: No recipient SME acknowledgement requested (0x00) ...0 = Intermediate notif: No intermediate notification requested (0x00) ...0 = Replace: Don't replace (0x00) Data coding: 0x00 SMPP Data Coding Scheme: SMSC default alphabet (0x00) GSM SMS Data Coding = DCS Coding Group for SMS: SMS DCS: General Data Coding indication - Uncompressed text, no message class (0x00) ..0. = DCS Text compression: Uncompressed text ...0 = DCS Class present: No message class 00.. = DCS Character set: GSM 7-bit default alphabet (0x00) GSM CBS Data Coding = DCS Coding Group for CBS: CBS DCS: Language using the GSM 7-bit default alphabet (0x00) ..00 = DCS CBS Message language: German (0x00) Predefined message: 0 Message length: 0 Optional parameters Optional parameter: message_state (0x0427) Tag: 0x0427 Length: 1 Message state: DELIVERED (2) Optional parameter: network_error_code (0x0423) Tag: 0x0423 Length: 3 Error type: GSM (3) Error code: 0x Optional parameter: receipted_message_id (0x001e) Tag: 0x001e Length: 9 SMSC identifier: 2D8B40B4 Optional parameter: source_subaddress (0x0202) Tag: 0x0202 Length: 12 Source Subaddress: a03739303238373130303939 14.08.2016 20:07, Rene Kluwen пишет: Even, the message appears in your log files. If you set the debug level high enough, you can just see it appear there. -Oorspronkelijk bericht- Van: devel [mailto:devel-boun...@kannel.org] Namens Milan P. Stanic Verzonden: zondag 14 augustus 2016 12:44 Aan:devel@kannel.org Onderwerp: Re: [Couldnot parse DLR string sscanf way,fallback to old way. Please report!] -- problem with message id On Fri, 2016-08-12 at 15:27, Черепанов Алексей Владиславович wrote: Hi, there. Having a problem with handling deliver_sm. Kannel couldn't parse message id: 2016-08-12 14:45:59 [2952] [6] DEBUG: SMPP[SMSC]: Couldnot parse DLR string sscanf way,fallback to old way. Please report! 2016-08-12 14:45:59 [2952] [6] ERROR: SMPP[SMSC]: got DLR but could not find message or was not interested in it id<> dst<79028710256>, type<2> 2016-08-12 14:45:59 [2952] [6] DEBUG: message_id: NULL Look like your provider (upstream SMPP server) does not send 'standard' DLR message. Actually there is no standard format for DLR message but most providers format it following sample in SMPP specification document. Could you check with your provider in what format their server send message to your kannel. Or, you can extract it with some network capture tools (tcpdump, tshark/wireshark) and see in what format messages are. -- С уважением, Черепанов Алексей -- С уважением, Черепанов Алексей
Re: [Couldnot parse DLR string sscanf way, fallback to old way. Please report!] -- problem with message id
Hi, please try SVN version. Looks like 1.4.4 has issue with TLVs… Alex > Am 15.08.2016 um 06:43 schrieb Черепанов Алексей Владиславович > <sw_cherepa...@motivtelecom.ru>: > > Here's the dump of packets. > > > Short Message Peer to Peer, Command: Submit_sm - resp, Status: "Ok", Seq: > 684, Len: 25 > Length: 25 > Operation: Submit_sm - resp (0x8004) > Result: Ok (0x) > Sequence #: 684 > Message id.: 2D8B40B4 > > Short Message Peer to Peer, Command: Deliver_sm, Seq: 674395051, Len: 95 > Length: 95 > Operation: Deliver_sm (0x0005) > Sequence #: 674395051 > Service type: (Default) > Type of number (originator): International (0x01) > Numbering plan indicator (originator): ISDN (E163/E164) (0x01) > Originator address: 79028710256 > Type of number (recipient): International (0x01) > Numbering plan indicator (recipient): ISDN (E163/E164) (0x01) > Recipient address: 343269 > ..00 = Messaging mode: Default SMSC mode (0x00) > ..00 01.. = Message type: Short message contains SMSC Delivery Receipt > (0x01) > 00.. = GSM features: No specific features selected (0x00) > Protocol id.: 0x7f > Priority level: GSM: None ANSI-136: Bulk IS-95: Normal (0x00) > Scheduled delivery time: Immediate delivery > Validity period: SMSC default validity period > ..00 = Delivery receipt: No SMSC delivery receipt requested (0x00) > 00.. = Message type: No recipient SME acknowledgement requested > (0x00) > ...0 = Intermediate notif: No intermediate notification requested > (0x00) > ...0 = Replace: Don't replace (0x00) > Data coding: 0x00 > SMPP Data Coding Scheme: SMSC default alphabet (0x00) > GSM SMS Data Coding > = DCS Coding Group for SMS: SMS DCS: General Data Coding > indication - Uncompressed text, no message class (0x00) > ..0. = DCS Text compression: Uncompressed text > ...0 = DCS Class present: No message class > 00.. = DCS Character set: GSM 7-bit default alphabet (0x00) > GSM CBS Data Coding > = DCS Coding Group for CBS: CBS DCS: Language using the GSM > 7-bit default alphabet (0x00) > ..00 = DCS CBS Message language: German (0x00) > Predefined message: 0 > Message length: 0 > Optional parameters > Optional parameter: message_state (0x0427) > Tag: 0x0427 > Length: 1 > Message state: DELIVERED (2) > Optional parameter: network_error_code (0x0423) > Tag: 0x0423 > Length: 3 > Error type: GSM (3) > Error code: 0x > Optional parameter: receipted_message_id (0x001e) > Tag: 0x001e > Length: 9 > SMSC identifier: 2D8B40B4 > Optional parameter: source_subaddress (0x0202) > Tag: 0x0202 > Length: 12 > Source Subaddress: a03739303238373130303939 > > > 14.08.2016 20:07, Rene Kluwen пишет: >> Even, the message appears in your log files. >> If you set the debug level high enough, you can just see it appear there. >> >> -----Oorspronkelijk bericht----- >> Van: devel [mailto:devel-boun...@kannel.org >> <mailto:devel-boun...@kannel.org>] Namens Milan P. Stanic >> Verzonden: zondag 14 augustus 2016 12:44 >> Aan: devel@kannel.org <mailto:devel@kannel.org> >> Onderwerp: Re: [Couldnot parse DLR string sscanf way,fallback to old way. >> Please report!] -- problem with message id >> >> On Fri, 2016-08-12 at 15:27, Черепанов Алексей Владиславович wrote: >>> Hi, there. Having a problem with handling deliver_sm. >>> Kannel couldn't parse message id: >>> >>> 2016-08-12 14:45:59 [2952] [6] DEBUG: SMPP[SMSC]: Couldnot parse DLR >>> string sscanf way,fallback to old way. Please report! >>> 2016-08-12 14:45:59 [2952] [6] ERROR: SMPP[SMSC]: got DLR but could >>> not find message or was not interested in it id<> dst<79028710256>, >>> type<2> >>> 2016-08-12 14:45:59 [2952] [6] DEBUG: message_id: NULL >> Look like your provider (upstream SMPP server) does not send 'standard' >> DLR message. >> Actually there is no standard format for DLR message but most providers >> format it following sample in SMPP specification document. >> >> Could you check with your provider in what format their server send message >> to your kannel. Or, you can extract it with some network capture tools >> (tcpdump, tshark/wireshark) and see in what format messages are. >> >> >> > > -- > С уважением, > Черепанов Алексей
Re: [Couldnot parse DLR string sscanf way, fallback to old way. Please report!] -- problem with message id
Here's the dump of packets. *Short Message Peer to Peer, Command: Submit_sm - resp, Status: "Ok", Seq: 684, Len: 25 *Length: 25 Operation: Submit_sm - resp (0x8004) Result: Ok (0x) Sequence #: 684 Message id.: 2D8B40B4 *Short Message Peer to Peer, Command: Deliver_sm, Seq: 674395051, Len: 95* Length: 95 Operation: Deliver_sm (0x0005) Sequence #: 674395051 Service type: (Default) Type of number (originator): International (0x01) Numbering plan indicator (originator): ISDN (E163/E164) (0x01) Originator address: 79028710256 Type of number (recipient): International (0x01) Numbering plan indicator (recipient): ISDN (E163/E164) (0x01) Recipient address: 343269 ..00 = Messaging mode: Default SMSC mode (0x00) ..00 01.. = Message type: Short message contains SMSC Delivery Receipt (0x01) 00.. = GSM features: No specific features selected (0x00) Protocol id.: 0x7f Priority level: GSM: None ANSI-136: Bulk IS-95: Normal (0x00) Scheduled delivery time: Immediate delivery Validity period: SMSC default validity period ..00 = Delivery receipt: No SMSC delivery receipt requested (0x00) 00.. = Message type: No recipient SME acknowledgement requested (0x00) ...0 = Intermediate notif: No intermediate notification requested (0x00) ...0 = Replace: Don't replace (0x00) Data coding: 0x00 SMPP Data Coding Scheme: SMSC default alphabet (0x00) GSM SMS Data Coding = DCS Coding Group for SMS: SMS DCS: General Data Coding indication - Uncompressed text, no message class (0x00) ..0. = DCS Text compression: Uncompressed text ...0 = DCS Class present: No message class 00.. = DCS Character set: GSM 7-bit default alphabet (0x00) GSM CBS Data Coding = DCS Coding Group for CBS: CBS DCS: Language using the GSM 7-bit default alphabet (0x00) ..00 = DCS CBS Message language: German (0x00) Predefined message: 0 Message length: 0 Optional parameters Optional parameter: message_state (0x0427) Tag: 0x0427 Length: 1 Message state: DELIVERED (2) Optional parameter: network_error_code (0x0423) Tag: 0x0423 Length: 3 Error type: GSM (3) Error code: 0x Optional parameter: receipted_message_id (0x001e) Tag: 0x001e Length: 9 SMSC identifier: 2D8B40B4 Optional parameter: source_subaddress (0x0202) Tag: 0x0202 Length: 12 Source Subaddress: a03739303238373130303939 14.08.2016 20:07, Rene Kluwen пишет: Even, the message appears in your log files. If you set the debug level high enough, you can just see it appear there. -Oorspronkelijk bericht- Van: devel [mailto:devel-boun...@kannel.org] Namens Milan P. Stanic Verzonden: zondag 14 augustus 2016 12:44 Aan: devel@kannel.org Onderwerp: Re: [Couldnot parse DLR string sscanf way,fallback to old way. Please report!] -- problem with message id On Fri, 2016-08-12 at 15:27, Черепанов Алексей Владиславович wrote: Hi, there. Having a problem with handling deliver_sm. Kannel couldn't parse message id: 2016-08-12 14:45:59 [2952] [6] DEBUG: SMPP[SMSC]: Couldnot parse DLR string sscanf way,fallback to old way. Please report! 2016-08-12 14:45:59 [2952] [6] ERROR: SMPP[SMSC]: got DLR but could not find message or was not interested in it id<> dst<79028710256>, type<2> 2016-08-12 14:45:59 [2952] [6] DEBUG: message_id: NULL Look like your provider (upstream SMPP server) does not send 'standard' DLR message. Actually there is no standard format for DLR message but most providers format it following sample in SMPP specification document. Could you check with your provider in what format their server send message to your kannel. Or, you can extract it with some network capture tools (tcpdump, tshark/wireshark) and see in what format messages are. -- С уважением, Черепанов Алексей
RE: [Couldnot parse DLR string sscanf way, fallback to old way. Please report!] -- problem with message id
Even, the message appears in your log files. If you set the debug level high enough, you can just see it appear there. -Oorspronkelijk bericht- Van: devel [mailto:devel-boun...@kannel.org] Namens Milan P. Stanic Verzonden: zondag 14 augustus 2016 12:44 Aan: devel@kannel.org Onderwerp: Re: [Couldnot parse DLR string sscanf way,fallback to old way. Please report!] -- problem with message id On Fri, 2016-08-12 at 15:27, Черепанов Алексей Владиславович wrote: > Hi, there. Having a problem with handling deliver_sm. > Kannel couldn't parse message id: > > 2016-08-12 14:45:59 [2952] [6] DEBUG: SMPP[SMSC]: Couldnot parse DLR > string sscanf way,fallback to old way. Please report! > 2016-08-12 14:45:59 [2952] [6] ERROR: SMPP[SMSC]: got DLR but could > not find message or was not interested in it id<> dst<79028710256>, > type<2> > 2016-08-12 14:45:59 [2952] [6] DEBUG: message_id: NULL Look like your provider (upstream SMPP server) does not send 'standard' DLR message. Actually there is no standard format for DLR message but most providers format it following sample in SMPP specification document. Could you check with your provider in what format their server send message to your kannel. Or, you can extract it with some network capture tools (tcpdump, tshark/wireshark) and see in what format messages are.
Re: [Couldnot parse DLR string sscanf way,fallback to old way. Please report!] -- problem with message id
On Fri, 2016-08-12 at 15:27, Черепанов Алексей Владиславович wrote: > Hi, there. Having a problem with handling deliver_sm. > Kannel couldn't parse message id: > > 2016-08-12 14:45:59 [2952] [6] DEBUG: SMPP[SMSC]: Couldnot parse DLR string > sscanf way,fallback to old way. Please report! > 2016-08-12 14:45:59 [2952] [6] ERROR: SMPP[SMSC]: got DLR but could not find > message or was not interested in it id<> dst<79028710256>, type<2> > 2016-08-12 14:45:59 [2952] [6] DEBUG: message_id: NULL Look like your provider (upstream SMPP server) does not send 'standard' DLR message. Actually there is no standard format for DLR message but most providers format it following sample in SMPP specification document. Could you check with your provider in what format their server send message to your kannel. Or, you can extract it with some network capture tools (tcpdump, tshark/wireshark) and see in what format messages are.
[Couldnot parse DLR string sscanf way,fallback to old way. Please report!] -- problem with message id
Hi, there. Having a problem with handling deliver_sm. Kannel couldn't parse message id: 2016-08-12 14:45:59 [2952] [6] DEBUG: SMPP[SMSC]: Couldnot parse DLR string sscanf way,fallback to old way. Please report! 2016-08-12 14:45:59 [2952] [6] ERROR: SMPP[SMSC]: got DLR but could not find message or was not interested in it id<> dst<79028710256>, type<2> 2016-08-12 14:45:59 [2952] [6] DEBUG: message_id: NULL * * **Full log** 2016-08-12 14:45:53 [2952] [6] DEBUG: SMPP[SMSC]: Sending PDU: 2016-08-12 14:45:53 [2952] [6] DEBUG: SMPP PDU 0x7f42b00029c0 dump: 2016-08-12 14:45:53 [2952] [6] DEBUG: type_name: submit_sm 2016-08-12 14:45:53 [2952] [6] DEBUG: command_id: 4 = 0x0004 2016-08-12 14:45:53 [2952] [6] DEBUG: command_status: 0 = 0x 2016-08-12 14:45:53 [2952] [6] DEBUG: sequence_number: 4 = 0x0004 2016-08-12 14:45:53 [2952] [6] DEBUG: service_type: NULL 2016-08-12 14:45:53 [2952] [6] DEBUG: source_addr_ton: 1 = 0x0001 2016-08-12 14:45:53 [2952] [6] DEBUG: source_addr_npi: 1 = 0x0001 2016-08-12 14:45:53 [2952] [6] DEBUG: source_addr: "343269" 2016-08-12 14:45:53 [2952] [6] DEBUG: dest_addr_ton: 1 = 0x0001 2016-08-12 14:45:53 [2952] [6] DEBUG: dest_addr_npi: 1 = 0x0001 2016-08-12 14:45:53 [2952] [6] DEBUG: destination_addr: "79028710256" 2016-08-12 14:45:53 [2952] [6] DEBUG: esm_class: 67 = 0x0043 2016-08-12 14:45:53 [2952] [6] DEBUG: protocol_id: 127 = 0x007f 2016-08-12 14:45:53 [2952] [6] DEBUG: priority_flag: 0 = 0x 2016-08-12 14:45:53 [2952] [6] DEBUG: schedule_delivery_time: NULL 2016-08-12 14:45:53 [2952] [6] DEBUG: validity_period: NULL 2016-08-12 14:45:53 [2952] [6] DEBUG: registered_delivery: 1 = 0x0001 2016-08-12 14:45:53 [2952] [6] DEBUG: replace_if_present_flag: 0 = 0x 2016-08-12 14:45:53 [2952] [6] DEBUG: data_coding: 246 = 0x00f6 2016-08-12 14:45:53 [2952] [6] DEBUG: sm_default_msg_id: 0 = 0x 2016-08-12 14:45:53 [2952] [6] DEBUG: sm_length: 53 = 0x0035 2016-08-12 14:45:53 [2952] [6] DEBUG: short_message: 2016-08-12 14:45:53 [2952] [6] DEBUG: Octet string at 0x7f42bbe0: 2016-08-12 14:45:53 [2952] [6] DEBUG: len: 53 2016-08-12 14:45:53 [2952] [6] DEBUG: size: 1024 2016-08-12 14:45:53 [2952] [6] DEBUG: immutable: 0 2016-08-12 14:45:53 [2952] [6] DEBUG: data: 02 70 00 00 30 15 06 3a 19 19 b0 00 00 1f 7e 72 .p..0..:..~r 2016-08-12 14:45:53 [2952] [6] DEBUG: data: da 2c d1 5e 41 a3 4a 95 0e 20 e4 92 8e 4d fe d8 .,.^A.J.. ...M.. 2016-08-12 14:45:53 [2952] [6] DEBUG: data: cc 7a 3f 62 f5 ce 8d 25 70 65 47 db ad cf 3e 77 .z?b...%peG...>w 2016-08-12 14:45:53 [2952] [6] DEBUG: data: 4b 2a 57 09 1f K*W.. 2016-08-12 14:45:53 [2952] [6] DEBUG: Octet string dump ends. 2016-08-12 14:45:53 [2952] [6] DEBUG: SMPP PDU dump ends. 2016-08-12 14:45:53 [2952] [6] DEBUG: SMPP[SMSC]: Got PDU: 2016-08-12 14:45:53 [2952] [6] DEBUG: SMPP PDU 0x7f42b00029c0 dump: 2016-08-12 14:45:53 [2952] [6] DEBUG: type_name: submit_sm_resp 2016-08-12 14:45:53 [2952] [6] DEBUG: command_id: 2147483652 = 0x8004 2016-08-12 14:45:53 [2952] [6] DEBUG: command_status: 0 = 0x 2016-08-12 14:45:53 [2952] [6] DEBUG: sequence_number: 4 = 0x0004 **2016-08-12 14:45:53 [2952] [6] DEBUG: message_id: "6D7872F"** 2016-08-12 14:45:53 [2952] [6] DEBUG: SMPP PDU dump ends. 2016-08-12 14:45:53 [2952] [6] DEBUG: DLR[internal]: Adding DLR smsc=SMSC, ts=114788143, src=343269, dst=79028710256, mask=7, boxc=smsbox-web 2016-08-12 14:45:59 [2952] [6] DEBUG: Optional parameter tag (0x0427) 2016-08-12 14:45:59 [2952] [6] DEBUG: Optional parameter length read as 1 2016-08-12 14:45:59 [2952] [6] DEBUG: Optional parameter tag (0x0423) 2016-08-12 14:45:59 [2952] [6] DEBUG: Optional parameter length read as 3 2016-08-12 14:45:59 [2952] [6] DEBUG: Optional parameter tag (0x001e) 2016-08-12 14:45:59 [2952] [6] DEBUG: Optional parameter length read as 8 2016-08-12 14:45:59 [2952] [6] DEBUG: Optional parameter tag (0x0202) 2016-08-12 14:45:59 [2952] [6] DEBUG: Optional parameter length read as 12 2016-08-12 14:45:59 [2952] [6] DEBUG: SMPP[SMSC]: Got PDU: 2016-08-12 14:45:59 [2952] [6] DEBUG: SMPP PDU 0x7f42b0002d70 dump: 2016-08-12 14:45:59 [2952] [6] DEBUG: type_name: deliver_sm 2016-08-12 14:45:59 [2952] [6] DEBUG: command_id: 5 = 0x0005 2016-08-12 14:45:59 [2952] [6] DEBUG: command_status: 0 = 0x 2016-08-12 14:45:59 [2952] [6] DEBUG: sequence_number: 653984193 = 0x26fb01c1 2016-08-12 14:45:59 [2952] [6] DEBUG: service_type: NULL 2016-08-12 14:45:59 [2952] [6] DEBUG: source_addr_ton: 1 = 0x0001 2016-08-12 14:45:59 [2952] [6] DEBUG: source_addr_npi: 1 = 0x0001 2016-08-12 14:45:59 [2952] [6] DEBUG: source_addr: "79028710256" 2016-08-12 14:45:59 [2952] [6] DEBUG: dest_addr_ton: 1 = 0x0001 2016-08-12 14:45:59 [2952] [6] DEBUG: dest_addr_npi: 1 = 0x0001 2016-08-12 14:45:59 [2952] [6] DEBUG: destination_addr: "343269" 2016-08-12 14:45:59 [2952] [6] DEBUG: esm_class: 4 = 0x0004 2016-08-12 14:45:59 [2952] [6] DEBUG:
