RE: [ANNOUNCE] Kannel 1.4.0 stable release available

2004-11-29 Thread Hillel Bilman
Dear Kannel Devel,

Well done on the latest Kannel stable release.

I have a few questions on the release:
1) In the article below you have said: "bruNET upgrading response parsing to
comply with more recent interface version (v2.0+) where bruNET delivers
'MessageId' in the HTTP response
 body."

Does this mean there is a new DLR escape code that allows one to get the
MessageId from the SMSC before the SMS has been delivered to the phone and
before the final dlr? If this is not the case, what does "bruNET delivers
'MessageId' in the HTTP response" mean? This is a function that the
devel team is looking into it?

2)I've been continually updating to the latest cvs and found it stable. Now
that the 1.4.0 release is
available is this a snapshot of the 1.3.2 development CVS? and if I keep
getting the CVS every few weeks, will it be an improvement to the 1.4.0
stable version?

Thanks


-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
Behalf Of Stipe Tolj
Sent: Thursday, November 25, 2004 5:40 AM
To: [EMAIL PROTECTED]; Kannel Development list; Kannel Users;
[EMAIL PROTECTED]
Subject: [ANNOUNCE] Kannel 1.4.0 stable release available


The Kannel Group is pleased to announce the availability
of the Kannel 1.4.0 stable release via the project web site

   http://www.kannel.org/

--

NEWS about Kannel: Open Source WAP and SMS Gateway version 1.4.0

This is a STABLE version. It should be usable for production systems.
Please do report problems to the Kannel bug tracking system available at
http://bugs.kannel.org/ or send a mail to <[EMAIL PROTECTED]> (the
development
mailing list).


Changes since version 1.3.2:

Compatibility breakers:

   * fakesmsc switching from -p to -r for port, since -p is used for
pid-file
 creation. This broke fakesmsc to use an other port then the default
1
 to connect to the smsc_fake module of bearerbox.

New features:

   * Added ability to start/stop/restart of all smscconn's that have equal
 smsc-id's instead of only one.

   * Implemented very simple priority queue ala Robert Sedgewick for gwlib.

   * Implemented concatenation of large sms inside bearerbox and does care
of
 sending all message parts over one smsc link. Now we have a problem
with
 concatenated large sms that bearerbox will try to load balance those
over
 different smsc links and such messages arrive as junk (all parts of
 concatenated large sms must go through the same smsc).

   * SMPP added ESME dlr bit to DLR processing, added setting of sms
priority
 flag in smsbox and smpp module.

   * bruNET upgrading response parsing to comply with more recent interface
 version (v2.0+) where bruNET delivers 'MessageId' in the HTTP response
 body.

   * AT, EMI usage of the of priority queue and priority flag.

   * URLTranslation added '%o' as escape code for MO msgs representing the
 msg->sms.account field. Which is interpreted as the operator ID for
 aggregator specific MO messages. ie. Xidris HTTP SMSC module.

   * test_ppg added support for X-WAP-Initiator-URI, use -I option.

Bugfixes:

   * SMPP fixed panic on NULLed source_addr/destination_addr, for
nulterminated
 string length checking of PDU elements, bug that dlr lookup was made
with
 source instead of destination address (in dlr source and destination
 switched), fixed incorrect handling of GSM_ADDR_TON_ALPHANUMERIC for
 destination address,

   * AT fixed segfault when modemtype is set to 'auto' or 'autodetect',
 fixed '+CPIN', some modem needs '"'.

   * HTTP fixed a binary MT bug (when DC_8BIT has been set) and various
 improvements for passing parameters to the HTTP request, fixing 3united
 (formerly Xidris) HTTP interface for  binary MT messages. We passed
 URL-encoded binary string, but server side  expected HEX encoded (2
char
 per byte) version.

   * WSP string coding bug fixed.

   * WML compiler fixed panic for certain DOCTYPE definitions, memory leak
fixed.

   * XMLRPC fixed memory leak.

   * Fixed ISO date handling.

   * Fixed double encoding in smsbox when trans coding from UCS2 to UTF-8 or
 ISO-8859-1.

   * Improved pthread reader/writer-locks.

   * Fixed usage of native semaphores on MacOS X to avoid a "not
implemented"
 error.

   * Fixed pthread lib settings for FreeBSD 5.2.1.

   * Added check for 'sem_init' in librt. This needs on Solaris & HP-UX.

   * Fixed Linux version of gw_gethostbyname when gethostbyname_r failed.
 Also free buffer on error.

   * Fixed daemon mode (make sure stdin/stdout/sdterr are opened and do
 chdir("/")) and change user code (set supplementary group id's and
 don't destroy passwd struct).

   * Bug work-around causing segfault on cygwin while using uninited
 rwlock functions.

   * Various memory leak and double free fixes.




Re: [ANNOUNCE] Kannel 1.4.0 stable release available

2004-12-02 Thread Stipe Tolj
Hillel Bilman wrote:
Dear Kannel Devel,
Well done on the latest Kannel stable release.
thanks a lot. I have to add my thanks to all developers who made improvements 
into Kannel possible and to the numerious people using the software and 
reporting bugs... this is what open source is all about... contribution to the 
community ;)

I have a few questions on the release:
1) In the article below you have said: "bruNET upgrading response parsing to
comply with more recent interface version (v2.0+) where bruNET delivers
'MessageId' in the HTTP response
 body."
Does this mean there is a new DLR escape code that allows one to get the
MessageId from the SMSC before the SMS has been delivered to the phone and
before the final dlr? If this is not the case, what does "bruNET delivers
'MessageId' in the HTTP response" mean? This is a function that the
devel team is looking into it?
speaking in Kannel internals, this means the MessageId response parameter is 
passed into the 'binfo' field of the Msg structure. Hence, yes, there is a 
generic URL trans escape code for getting the binfo field from specific SMSC 
implementations. bruNET uses this MessageId for further transactions to 
distinguish billing information... (don't want to go into details here).

So, there is _no_ new field or escape code for it.
2)I've been continually updating to the latest cvs and found it stable. Now
that the 1.4.0 release is
available is this a snapshot of the 1.3.2 development CVS? and if I keep
getting the CVS every few weeks, will it be an improvement to the 1.4.0
stable version?
yes, 1.4.0 is actually a snapshot of the CVS HEAD tree from the specific release 
date.

We're now tending to seperate things again. There are a lot of new (huge) 
patches waiting. They will make their way into CVS HEAD. The 1.4 stable branch 
will contain only bugfixes to the current 1.4.0. So you can illustrate it via this:

  1.4.0 ---> 1.4 stable branch (bugfixes only, no new logic)
---> cvs head, all new and also "experimental" code
So you should be reviewing the cvs commits, via devel-reports@ mailing list. As 
soon as we commit huge changes/patches, you're obviously not anymore on the 
"safe side", you should then switch to the 1.4 branch.

Stipe
mailto:stolj_{at}_wapme.de
---
Wapme Systems AG
Vogelsanger Weg 80
40470 Düsseldorf, NRW, Germany
phone: +49.211.74845.0
fax: +49.211.74845.299
mailto:info_{at}_wapme-systems.de
http://www.wapme-systems.de/
---