Wireless Profiled TCP
Hi all, Has the standardization for the Wireless Profiled TCP completed? James
Re: WAP Specifications
James, the MMS architecture is based to be build on WAP 1.2.1. Stipe mailto:[EMAIL PROTECTED] --- Wapme Systems AG Münsterstr. 248 40470 Düsseldorf, NRW, Germany phone: +49.211.74845.0 fax: +49.211.74845.299 mailto:[EMAIL PROTECTED] http://www.wapme-systems.de/ --- -BEGIN PGP PUBLIC KEY BLOCK- Version: GnuPG v1.2.2 (Cygwin) mIsEP6mcYwEEAMDnUiUwrbb+xwTFWN6TxF2+XZu7/alwJMeCwMBRvXtPZqfjpPhS OkBpU0F4TrVuugz1HINTSaJTYq10AzDQXp5NkyWgckqW79nPAWuOX0dicbJk+cN2 nM2TI4KaxUDe6u8hghNEnH/i2lXsUu9apnP/iixzV81VC2je3uc9hZpnAAYptEVT dGlwZSBUb2xqIChUZWNobm9sb2d5IENlbnRlciAmIFJlc2VhcmNoIExhYikgPHRv bGpAd2FwbWUtc3lzdGVtcy5kZT6ItAQTAQIAHgUCP6mcYwIbAwYLCQgHAwIDFQID AxYCAQIeAQIXgAAKCRABV0w1BqPYRuSqA/wPzsQxao2YePENCtgRTrO86U6zg3sl OcS6CJFI4FZP5h/xD3GRsNH1+MPSvZlomDdpFnr547DGz/Kq9MXuQwVvlVig5yWZ K5dtKp1r5YLhxJQBhfirZbRFFnYmf19f18J8OoS28tuFVftDl1AIwJS3HLyBTv6H g2HyLAEKQIp30Q== =aYCI -END PGP PUBLIC KEY BLOCK-
Re: gwlib/gw_uuid_types.h missing
Rene, Rene Kluwen wrote: > > This is what I get compiling latest CVS version. > Is there some file missing in the repository? > > gcc -D_REENTRANT=1 -I. -Igw -g -O2 -DBROKEN_PTHREADS=1 -I/usr/include/libxml > 2/libxml -I/usr/include/libxml2 -I/usr/include -I'/usr/include/mysql' -I/usr > /include/mysql -o gwlib/gw_uuid.o -c gwlib/gw_uuid.c > gwlib/gw_uuid.c:51:33: gwlib/gw_uuid_types.h: No such file or directory > make: *** [gwlib/gw_uuid.o] Error 1 it's correct that it is missing. Because it is auto-generated from configure, see the .in file in cvs: http://www.kannel.org/cgi-bin/viewcvs.cgi/gateway/gwlib/gw_uuid_types.h.in I guess that you have updated your local cvs tree but did not re-run configure (so the header file could not be generated). Simply re-run configure and you should be fine. Stipe mailto:[EMAIL PROTECTED] --- Wapme Systems AG Münsterstr. 248 40470 Düsseldorf, NRW, Germany phone: +49.211.74845.0 fax: +49.211.74845.299 mailto:[EMAIL PROTECTED] http://www.wapme-systems.de/ --- -BEGIN PGP PUBLIC KEY BLOCK- Version: GnuPG v1.2.2 (Cygwin) mIsEP6mcYwEEAMDnUiUwrbb+xwTFWN6TxF2+XZu7/alwJMeCwMBRvXtPZqfjpPhS OkBpU0F4TrVuugz1HINTSaJTYq10AzDQXp5NkyWgckqW79nPAWuOX0dicbJk+cN2 nM2TI4KaxUDe6u8hghNEnH/i2lXsUu9apnP/iixzV81VC2je3uc9hZpnAAYptEVT dGlwZSBUb2xqIChUZWNobm9sb2d5IENlbnRlciAmIFJlc2VhcmNoIExhYikgPHRv bGpAd2FwbWUtc3lzdGVtcy5kZT6ItAQTAQIAHgUCP6mcYwIbAwYLCQgHAwIDFQID AxYCAQIeAQIXgAAKCRABV0w1BqPYRuSqA/wPzsQxao2YePENCtgRTrO86U6zg3sl OcS6CJFI4FZP5h/xD3GRsNH1+MPSvZlomDdpFnr547DGz/Kq9MXuQwVvlVig5yWZ K5dtKp1r5YLhxJQBhfirZbRFFnYmf19f18J8OoS28tuFVftDl1AIwJS3HLyBTv6H g2HyLAEKQIp30Q== =aYCI -END PGP PUBLIC KEY BLOCK-
DLR sql select problem with message id containing space
Hi, Just hooked up another SMPP connection, and they use rather large message ids. For example: 00047274 20031223170148.364 Kannel is inserting this whole value (including characters after the space) into the ts field on the dlr table. However, when it comes to receiving the delivery report, it's truncating the message id after the first space, so it does: DLR[mysql]: Looking for DLR smsc=, ts=00047274, dst=44xx, type=1 Which of course it won't find, as it's lost the rest of the message id. My C coding skills aren't up to much, but I would imagine it requires something that tests the first character after the space to see if it's numeric. Alex
RE: DLR sql select problem with message id containing space
Fix would be not too hard to implement... BUT... In the SMPP specs that I have (note: I am talking about v3.3) it says: Message ID, var max. 9. So taking off the terminating NUL this means that message ids can be 8 characters at most. I noticed this 'quirk' (message ids of more than 8 chars) also with a certain upstream provider that I have. Question: Has this changed in successive SMPP versions? Or is it just plainly against specifications? Regards, Rene Kluwen Chimit -Original Message-From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]On Behalf Of Alex KinchSent: dinsdag 23 december 2003 18:47To: [EMAIL PROTECTED]Subject: DLR sql select problem with message id containing space Hi, Just hooked up another SMPP connection, and they use rather large message ids. For example: 00047274 20031223170148.364 Kannel is inserting this whole value (including characters after the space) into the ts field on the dlr table. However, when it comes to receiving the delivery report, it's truncating the message id after the first space, so it does: DLR[mysql]: Looking for DLR smsc=, ts=00047274, dst=44xx, type=1 Which of course it won't find, as it's lost the rest of the message id. My C coding skills aren't up to much, but I would imagine it requires something that tests the first character after the space to see if it's numeric. Alex
Merry Christmas and a happy New Year!!!
to all Kannel Group members and those who participate in the development of Kannel, to all readers and contributors of the devel mailing list, to all people "behind the scenes", ie. the good people of Trigenix for hosting etc, to all companies that do use Kannel for commercial purposes and claim to be proud of it ;), to all family members of the developers for their paitience in leaving their loved ones so long in front of this stupid box called computer, to all visitors of Kannel's web site, may your browsers return to us in the next year too, to all of us, *** Merry merry Christmas and a happy New Year 2004 !!! *** Stipe mailto:[EMAIL PROTECTED] --- Wapme Systems AG Münsterstr. 248 40470 Düsseldorf, NRW, Germany phone: +49.211.74845.0 fax: +49.211.74845.299 mailto:[EMAIL PROTECTED] http://www.wapme-systems.de/ --- -BEGIN PGP PUBLIC KEY BLOCK- Version: GnuPG v1.2.2 (Cygwin) mIsEP6mcYwEEAMDnUiUwrbb+xwTFWN6TxF2+XZu7/alwJMeCwMBRvXtPZqfjpPhS OkBpU0F4TrVuugz1HINTSaJTYq10AzDQXp5NkyWgckqW79nPAWuOX0dicbJk+cN2 nM2TI4KaxUDe6u8hghNEnH/i2lXsUu9apnP/iixzV81VC2je3uc9hZpnAAYptEVT dGlwZSBUb2xqIChUZWNobm9sb2d5IENlbnRlciAmIFJlc2VhcmNoIExhYikgPHRv bGpAd2FwbWUtc3lzdGVtcy5kZT6ItAQTAQIAHgUCP6mcYwIbAwYLCQgHAwIDFQID AxYCAQIeAQIXgAAKCRABV0w1BqPYRuSqA/wPzsQxao2YePENCtgRTrO86U6zg3sl OcS6CJFI4FZP5h/xD3GRsNH1+MPSvZlomDdpFnr547DGz/Kq9MXuQwVvlVig5yWZ K5dtKp1r5YLhxJQBhfirZbRFFnYmf19f18J8OoS28tuFVftDl1AIwJS3HLyBTv6H g2HyLAEKQIp30Q== =aYCI -END PGP PUBLIC KEY BLOCK-
Re: DLR sql select problem with message id containing space
Hi Rene In the SMPP v3.4 issue 1.2 (12th October 1999) docs that I have, it's been up'd from 9 to 33, and then to 65 octets. I guess this is to accomodate for the increasing use of GUID-style message ids? It seems that Kannel handles the SUBMIT_SM_RESP ok with these long ids, but doesn't do it in the DELIVER_SM for the DLR. Alex - Original Message - From: Rene Kluwen To: Alex Kinch ; [EMAIL PROTECTED] Sent: Tuesday, December 23, 2003 9:24 PM Subject: RE: DLR sql select problem with message id containing space Fix would be not too hard to implement... BUT... In the SMPP specs that I have (note: I am talking about v3.3) it says: Message ID, var max. 9. So taking off the terminating NUL this means that message ids can be 8 characters at most. I noticed this 'quirk' (message ids of more than 8 chars) also with a certain upstream provider that I have. Question: Has this changed in successive SMPP versions? Or is it just plainly against specifications? Regards, Rene Kluwen Chimit -Original Message-From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]On Behalf Of Alex KinchSent: dinsdag 23 december 2003 18:47To: [EMAIL PROTECTED]Subject: DLR sql select problem with message id containing space Hi, Just hooked up another SMPP connection, and they use rather large message ids. For example: 00047274 20031223170148.364 Kannel is inserting this whole value (including characters after the space) into the ts field on the dlr table. However, when it comes to receiving the delivery report, it's truncating the message id after the first space, so it does: DLR[mysql]: Looking for DLR smsc=, ts=00047274, dst=44xx, type=1 Which of course it won't find, as it's lost the rest of the message id. My C coding skills aren't up to much, but I would imagine it requires something that tests the first character after the space to see if it's numeric. Alex
