Re: [PATCH] SMPP trivial
On Thu, Feb 20, 2003 at 06:55:21PM +0100, Alexander Malysh wrote: here is trivial SMPP generic_nack fix. generic_nack command id is 0x8000 instead of 0x Please apply ... Thanks, you are right. I checked the SMPP spec and I've committed that patch to CVS. Cheers, Dave -- :: David Holland :: Systems Manager :: 3G Lab :: +44 01223 478900 :: The biggest crime of all that [Microsoft] commits is getting people accustomed to huge, slow, unstable software as the norm. -- Jay Maynard
RE: DCS and PID handling in Kannel
This isn't Kannel's decision to make; this is data set by the end user's telephone, which may have requirements neither you nor I are (or could be) aware of. The analogy to a case-insensitive filesystem namespace is quite fitting if you think about it carefully. I did look at alt-dcs, and I consider it a kludge. Sorry. You're absolutely right. I've had an explicit DCS value in the SMS Msg struct for ages. It's required because there are just too many SMSCs, MARs, front-ends and some devices that don't implement DCS according to the specs. The Kannel code for DCS is correct; its just inadequete in the face of so many other broken implementations - for example I have an SMSC link to an operator that will only accept an MT DCS value of 0 regardless of any other message characteristics and this is an SMPP protocol link. Go figure.
RE : SMPP 3.3 trouble
Thanks, I just applied it and I have the following log (see below). I have 2 questions: - Why is there 2 enquire link, is there one for the transmitter and one for the receiver? - The sequence number of the generic_nack seems to refer to the bind transmitter and bind_receiver. Is it the case? If it is, why does the SMSC wait for the enquire_link to send the generic_nack. If it is not the case, what could explain it? (SMSC trouble? ). Regards. 2003-02-21 11:28:18 [0] INFO: Kannel bearerbox II version 1.3.1 starting 2003-02-21 11:28:18 [0] INFO: MAIN: Start-up done, entering mainloop 2003-02-21 11:28:18 [7] DEBUG: sms_router: time to sleep 2003-02-21 11:28:18 [7] DEBUG: sms_router: list_len = 0 2003-02-21 11:28:18 [5] DEBUG: SMPP[opsmsc]: Sending PDU: 2003-02-21 11:28:18 [5] DEBUG: SMPP PDU 0x80f3b48 dump: 2003-02-21 11:28:18 [5] DEBUG: type_name: bind_transmitter 2003-02-21 11:28:18 [5] DEBUG: command_id: 2 = 0x0002 2003-02-21 11:28:18 [5] DEBUG: command_status: 0 = 0x 2003-02-21 11:28:18 [5] DEBUG: sequence_number: 0 = 0x 2003-02-21 11:28:18 [5] DEBUG: system_id: *** 2003-02-21 11:28:18 [5] DEBUG: password: *** 2003-02-21 11:28:18 [5] DEBUG: system_type: VMA 2003-02-21 11:28:18 [5] DEBUG: interface_version: 51 = 0x0033 2003-02-21 11:28:18 [5] DEBUG: addr_ton: 0 = 0x 2003-02-21 11:28:18 [5] DEBUG: addr_npi: 0 = 0x 2003-02-21 11:28:18 [5] DEBUG: address_range: 2003-02-21 11:28:18 [5] DEBUG: SMPP PDU dump ends. 2003-02-21 11:28:18 [6] DEBUG: SMPP[opsmsc]: Sending PDU: 2003-02-21 11:28:18 [6] DEBUG: SMPP PDU 0x80f3c78 dump: 2003-02-21 11:28:18 [6] DEBUG: type_name: bind_receiver 2003-02-21 11:28:18 [6] DEBUG: command_id: 1 = 0x0001 2003-02-21 11:28:18 [6] DEBUG: command_status: 0 = 0x 2003-02-21 11:28:18 [6] DEBUG: sequence_number: 1 = 0x0001 2003-02-21 11:28:18 [6] DEBUG: system_id: *** 2003-02-21 11:28:18 [6] DEBUG: password: *** 2003-02-21 11:28:18 [6] DEBUG: system_type: VMA 2003-02-21 11:28:18 [6] DEBUG: interface_version: 51 = 0x0033 2003-02-21 11:28:18 [6] DEBUG: addr_ton: 0 = 0x 2003-02-21 11:28:18 [6] DEBUG: addr_npi: 0 = 0x 2003-02-21 11:28:18 [6] DEBUG: address_range: 2003-02-21 11:28:18 [6] DEBUG: SMPP PDU dump ends. 2003-02-21 11:28:48 [5] DEBUG: SMPP[opsmsc]: Sending enquire link: 2003-02-21 11:28:48 [5] DEBUG: SMPP PDU 0x80f3c78 dump: 2003-02-21 11:28:48 [5] DEBUG: type_name: enquire_link 2003-02-21 11:28:48 [5] DEBUG: command_id: 21 = 0x0015 2003-02-21 11:28:48 [5] DEBUG: command_status: 0 = 0x 2003-02-21 11:28:48 [5] DEBUG: sequence_number: 2 = 0x0002 2003-02-21 11:28:48 [5] DEBUG: SMPP PDU dump ends. 2003-02-21 11:28:48 [6] DEBUG: SMPP[opsmsc]: Sending enquire link: 2003-02-21 11:28:48 [6] DEBUG: SMPP PDU 0x80f3c78 dump: 2003-02-21 11:28:48 [6] DEBUG: type_name: enquire_link 2003-02-21 11:28:48 [6] DEBUG: command_id: 21 = 0x0015 2003-02-21 11:28:48 [6] DEBUG: command_status: 0 = 0x 2003-02-21 11:28:48 [6] DEBUG: sequence_number: 3 = 0x0003 2003-02-21 11:28:48 [6] DEBUG: SMPP PDU dump ends. 2003-02-21 11:28:48 [5] DEBUG: SMPP[opsmsc]: Got PDU: 2003-02-21 11:28:48 [5] DEBUG: SMPP PDU 0x80f3cc0 dump: 2003-02-21 11:28:48 [5] DEBUG: type_name: generic_nack 2003-02-21 11:28:48 [5] DEBUG: command_id: 2147483648 = 0x8000 2003-02-21 11:28:48 [5] DEBUG: command_status: 4 = 0x0004 2003-02-21 11:28:48 [5] DEBUG: sequence_number: 0 = 0x 2003-02-21 11:28:48 [5] DEBUG: SMPP PDU dump ends. 2003-02-21 11:28:48 [5] WARNING: SMPP[opsmsc]: SMSC sent generic_nack with wrong sequence number 0x 2003-02-21 11:28:48 [5] ERROR: SMPP[opsmsc]: I/O error or other error. Re-connecting. 2003-02-21 11:28:49 [6] DEBUG: SMPP[opsmsc]: Got PDU: 2003-02-21 11:28:49 [6] DEBUG: SMPP PDU 0x80f3c50 dump: 2003-02-21 11:28:49 [6] DEBUG: type_name: generic_nack 2003-02-21 11:28:49 [6] DEBUG: command_id: 2147483648 = 0x8000 2003-02-21 11:28:49 [6] DEBUG: command_status: 4 = 0x0004 2003-02-21 11:28:49 [6] DEBUG: sequence_number: 1 = 0x0001 2003-02-21 11:28:49 [6] DEBUG: SMPP PDU dump ends. 2003-02-21 11:28:49 [6] WARNING: SMPP[opsmsc]: SMSC sent generic_nack with wrong sequence number 0x0001 2003-02-21 11:28:49 [6] ERROR: SMPP[opsmsc]: I/O error or other error. Re-connecting. 2003-02-21 11:28:49 [5] DEBUG: SMPP[opsmsc]: Sending PDU: 2003-02-21 11:28:49 [5] DEBUG: SMPP PDU 0x80f3b48 dump: 2003-02-21 11:28:49 [5] DEBUG: type_name: bind_transmitter
Re: SMPP 3.3 trouble
Raphael Bellec [EMAIL PROTECTED] wrote: 2003-02-21 11:28:48 [5] DEBUG: command_id: 2147483648 = 0x8000 2003-02-21 11:28:48 [5] DEBUG: command_status: 4 = 0x0004 A generic nack with a status of 4 = Incorrect bind status for the given command. It would appear that the SMSC hasn't accepted your connection properly, so sends a generic nack in response to your enquire_link. However, the nack it sends has the wrong sequence number on it causes Kannel to hang up. Of course, it should only send a generic nack when it doesn't recognise your command. In this case, an enquire_link_resp would have been sufficient. Seems the SMSC is broken. -- Ian Cass
[PATCH] Re: RE : SMPP 3.3 trouble
Hi, please apply attached patch and try again... For all: SMPP v3.4 spec allow sequence number in the range from 0x0001 to 0x7FFF And we send 0x0 , that is wrong and SMSC do right job! I have sent similar patch for a while but . Am Freitag, 21. Februar 2003 13:29 schrieb Raphael Bellec: Thanks, I just applied it and I have the following log (see below). I have 2 questions: - Why is there 2 enquire link, is there one for the transmitter and one for the receiver? - The sequence number of the generic_nack seems to refer to the bind transmitter and bind_receiver. Is it the case? If it is, why does the SMSC wait for the enquire_link to send the generic_nack. If it is not the case, what could explain it? (SMSC trouble? ). Regards. 2003-02-21 11:28:18 [0] INFO: Kannel bearerbox II version 1.3.1 starting 2003-02-21 11:28:18 [0] INFO: MAIN: Start-up done, entering mainloop 2003-02-21 11:28:18 [7] DEBUG: sms_router: time to sleep 2003-02-21 11:28:18 [7] DEBUG: sms_router: list_len = 0 2003-02-21 11:28:18 [5] DEBUG: SMPP[opsmsc]: Sending PDU: 2003-02-21 11:28:18 [5] DEBUG: SMPP PDU 0x80f3b48 dump: 2003-02-21 11:28:18 [5] DEBUG: type_name: bind_transmitter 2003-02-21 11:28:18 [5] DEBUG: command_id: 2 = 0x0002 2003-02-21 11:28:18 [5] DEBUG: command_status: 0 = 0x 2003-02-21 11:28:18 [5] DEBUG: sequence_number: 0 = 0x 2003-02-21 11:28:18 [5] DEBUG: system_id: *** 2003-02-21 11:28:18 [5] DEBUG: password: *** 2003-02-21 11:28:18 [5] DEBUG: system_type: VMA 2003-02-21 11:28:18 [5] DEBUG: interface_version: 51 = 0x0033 2003-02-21 11:28:18 [5] DEBUG: addr_ton: 0 = 0x 2003-02-21 11:28:18 [5] DEBUG: addr_npi: 0 = 0x 2003-02-21 11:28:18 [5] DEBUG: address_range: 2003-02-21 11:28:18 [5] DEBUG: SMPP PDU dump ends. 2003-02-21 11:28:18 [6] DEBUG: SMPP[opsmsc]: Sending PDU: 2003-02-21 11:28:18 [6] DEBUG: SMPP PDU 0x80f3c78 dump: 2003-02-21 11:28:18 [6] DEBUG: type_name: bind_receiver 2003-02-21 11:28:18 [6] DEBUG: command_id: 1 = 0x0001 2003-02-21 11:28:18 [6] DEBUG: command_status: 0 = 0x 2003-02-21 11:28:18 [6] DEBUG: sequence_number: 1 = 0x0001 2003-02-21 11:28:18 [6] DEBUG: system_id: *** 2003-02-21 11:28:18 [6] DEBUG: password: *** 2003-02-21 11:28:18 [6] DEBUG: system_type: VMA 2003-02-21 11:28:18 [6] DEBUG: interface_version: 51 = 0x0033 2003-02-21 11:28:18 [6] DEBUG: addr_ton: 0 = 0x 2003-02-21 11:28:18 [6] DEBUG: addr_npi: 0 = 0x 2003-02-21 11:28:18 [6] DEBUG: address_range: 2003-02-21 11:28:18 [6] DEBUG: SMPP PDU dump ends. 2003-02-21 11:28:48 [5] DEBUG: SMPP[opsmsc]: Sending enquire link: 2003-02-21 11:28:48 [5] DEBUG: SMPP PDU 0x80f3c78 dump: 2003-02-21 11:28:48 [5] DEBUG: type_name: enquire_link 2003-02-21 11:28:48 [5] DEBUG: command_id: 21 = 0x0015 2003-02-21 11:28:48 [5] DEBUG: command_status: 0 = 0x 2003-02-21 11:28:48 [5] DEBUG: sequence_number: 2 = 0x0002 2003-02-21 11:28:48 [5] DEBUG: SMPP PDU dump ends. 2003-02-21 11:28:48 [6] DEBUG: SMPP[opsmsc]: Sending enquire link: 2003-02-21 11:28:48 [6] DEBUG: SMPP PDU 0x80f3c78 dump: 2003-02-21 11:28:48 [6] DEBUG: type_name: enquire_link 2003-02-21 11:28:48 [6] DEBUG: command_id: 21 = 0x0015 2003-02-21 11:28:48 [6] DEBUG: command_status: 0 = 0x 2003-02-21 11:28:48 [6] DEBUG: sequence_number: 3 = 0x0003 2003-02-21 11:28:48 [6] DEBUG: SMPP PDU dump ends. 2003-02-21 11:28:48 [5] DEBUG: SMPP[opsmsc]: Got PDU: 2003-02-21 11:28:48 [5] DEBUG: SMPP PDU 0x80f3cc0 dump: 2003-02-21 11:28:48 [5] DEBUG: type_name: generic_nack 2003-02-21 11:28:48 [5] DEBUG: command_id: 2147483648 = 0x8000 2003-02-21 11:28:48 [5] DEBUG: command_status: 4 = 0x0004 2003-02-21 11:28:48 [5] DEBUG: sequence_number: 0 = 0x 2003-02-21 11:28:48 [5] DEBUG: SMPP PDU dump ends. 2003-02-21 11:28:48 [5] WARNING: SMPP[opsmsc]: SMSC sent generic_nack with wrong sequence number 0x 2003-02-21 11:28:48 [5] ERROR: SMPP[opsmsc]: I/O error or other error. Re-connecting. 2003-02-21 11:28:49 [6] DEBUG: SMPP[opsmsc]: Got PDU: 2003-02-21 11:28:49 [6] DEBUG: SMPP PDU 0x80f3c50 dump: 2003-02-21 11:28:49 [6] DEBUG: type_name: generic_nack 2003-02-21 11:28:49 [6] DEBUG: command_id: 2147483648 = 0x8000 2003-02-21 11:28:49 [6] DEBUG: command_status: 4 = 0x0004 2003-02-21 11:28:49 [6] DEBUG: sequence_number: 1 = 0x0001 2003-02-21 11:28:49 [6] DEBUG: SMPP PDU dump ends. 2003-02-21 11:28:49 [6] WARNING: SMPP[opsmsc]: SMSC sent generic_nack with wrong sequence number 0x0001 2003-02-21 11:28:49 [6] ERROR: SMPP[opsmsc]: I/O error or other error. Re-connecting. 2003-02-21 11:28:49 [5] DEBUG: SMPP[opsmsc]: Sending PDU: 2003-02-21 11:28:49 [5] DEBUG: SMPP PDU 0x80f3b48 dump: 2003-02-21 11:28:49 [5] DEBUG: type_name: bind_transmitter -- Best regards / Mit besten Grüßen aus Köln Dipl.-Ing. Alexander Malysh
Re: [PATCH] Re: RE : SMPP 3.3 trouble
On Fri, Feb 21, 2003 at 02:06:12PM +0100, Alexander Malysh wrote: For all: SMPP v3.4 spec allow sequence number in the range from 0x0001 to 0x7FFF And we send 0x0 , that is wrong and SMSC do right job! Looks plausible to me... +1 I guess most other SMSC's are lax about accepting a zero sequence number or this problem would have been fixed by now. Dave -- :: David Holland :: Systems Manager :: 3G Lab :: +44 01223 478900 :: Disney does mediated experiences better than anyone. If they understood what OSes are ... they could crush Microsoft in a year or two. -- NS
RE : [PATCH] Re: RE : SMPP 3.3 trouble
I applied it and the first sequence number is '1'... but I still have the same error. I will contact Comverse with these informations, I keep you informed. Thanks. Raphaël. -Message d'origine- De : [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] De la part de Alexander Malysh Envoyé : vendredi 21 février 2003 14:06 À : Raphael Bellec; [EMAIL PROTECTED] Objet : [PATCH] Re: RE : SMPP 3.3 trouble Hi, please apply attached patch and try again... For all: SMPP v3.4 spec allow sequence number in the range from 0x0001 to 0x7FFF And we send 0x0 , that is wrong and SMSC do right job! I have sent similar patch for a while but .
RE: [PATCH] Re: RE : SMPP 3.3 trouble
Yep of course +1, this is something I already submitted on Sep 06 2002, and was accepted. See http://www.kannel.3glab.org/cgi-bin/viewcvs.cgi/gateway/gw/smsc/smsc_smpp.c. diff?r1=1.9r2=1.10 http://www.kannel.3glab.org/cgi-bin/viewcvs.cgi/gateway/ChangeLog.diff?r1=1. 1950r2=1.1951 It seems someone rolled it back :-( Angel Fradejas Mediafusion Espana, S.A. [EMAIL PROTECTED] www.mediafusion.es Tel. +34 91 252 32 00 Fax +34 91 572 27 08 -Mensaje original- De: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]En nombre de David Holland Enviado el: viernes 21 de febrero de 2003 14:19 Para: Alexander Malysh CC: Raphael Bellec; [EMAIL PROTECTED] Asunto: Re: [PATCH] Re: RE : SMPP 3.3 trouble On Fri, Feb 21, 2003 at 02:06:12PM +0100, Alexander Malysh wrote: For all: SMPP v3.4 spec allow sequence number in the range from 0x0001 to 0x7FFF And we send 0x0 , that is wrong and SMSC do right job! Looks plausible to me... +1 I guess most other SMSC's are lax about accepting a zero sequence number or this problem would have been fixed by now. Dave -- :: David Holland :: Systems Manager :: 3G Lab :: +44 01223 478900 :: Disney does mediated experiences better than anyone. If they understood what OSes are ... they could crush Microsoft in a year or two. -- NS
Re: [PATCH] Re: RE : SMPP 3.3 trouble
On Fri, Feb 21, 2003 at 04:45:53PM +0100, Angel Fradejas wrote: It seems someone rolled it back :-( Oops. I think Stipe took it out in revision 1.12... Stipe, was that deliberate? Dave -- :: David Holland :: Systems Manager :: 3G Lab :: +44 01223 478900 ::
DLR and SiemensTC35
Hi All, has anybody configuration kannel in order to use DLR with Siemens TC35 like SMSC? Angelo signature.asc Description: PGP signature
Re: Chinese character
On Freitag, Februar 21, 2003, at 07:07 Uhr, Andy Elacion, Jr. wrote: Is it possible for kannel to accept and reply in chinese? If your can you give me a hint on how to do it or point me to a readme/howto on how am I going to implement it. Thank you very much in advance, Andy for chinese you simply have to use unicode. the pattern matching however most probably has a problem with unicode so you should only use the default smsc service and then match it in your application and you're fine. Andreas Fink Global Networks Switzerland AG -- Tel: +41-61-333 Fax: +41-61-334 Mobile: +41-79-2457333 Global Networks, Inc. Clarastrasse 3, 4058 Basel, Switzerland Web: http://www.global-networks.ch/ [EMAIL PROTECTED] -- Member of the GSM Association
RE: DCS and PID handling in Kannel
Citando Paul Keogh [EMAIL PROTECTED]: This isn't Kannel's decision to make; this is data set by the end user's telephone, which may have requirements neither you nor I are (or could be) aware of. The analogy to a case-insensitive filesystem namespace is quite fitting if you think about it carefully. I did look at alt-dcs, and I consider it a kludge. Sorry. You're absolutely right. I've had an explicit DCS value in the SMS Msg struct for ages. It's required because there are just too many SMSCs, MARs, front-ends and some devices that don't implement DCS according to the specs. The Kannel code for DCS is correct; its just inadequete in the face of so many other broken implementations - for example I have an SMSC link to an operator that will only accept an MT DCS value of 0 regardless of any other message characteristics and this is an SMPP protocol link. Go figure. About having dcs from smsc-kannel-appl, it's ok. We already have text with (possibly) processed text, and binary with raw UD. We can also have mclass/etc and raw dcs. I just object of a dcs going in. Sorry if I was rude about that. -- Davi / Bruno.RodriguesatLitux.Org Litux.org: 01:23:08 up 91 days, 2:38, 7 users, load average: 0.04, 0.10, 0.05 'Make it idiot-proof, and someone will breed a better idiot. -- Oliver Elphick'
