PPG - CIMD2 - DLR
dandrikop at cosmote.gr
Thu Dec 7 15:36:49 CET 2006
Please find attached the "bearerbox.log" file containing two WAP Push messages, which I received
successfully on my handset.
As you can notice from the log, after sending the 1st CIMD2 message of the 1st WAP Push message,
Kannel inserted a record in the database, used for storing DLRs. Soon after, it made the appropriate HTTP
request to the DLR-URL (status=8). Finally, the two final CIMD2 messages of the 1st WAP Push message
Please note that the second WAP Push message starts from the line 87:
2006-12-07 15:50:08   DEBUG: boxc_receiver: got sms from wapbox
After my Push Initiator sent the 2nd WAP Push message, Kannel followed the very same procedure as
above (until line 108). At line 109 it seemed that SMS-C sent something (probably its DLR) to Kannel which
didn't before, and as result, Kannel queried the database for the newly inserted DLR record, made an HTTP
request to the DLR-URL (status=1) and finally removed the associated database entry.
The above procedure is repeated for PAP-message by PAP-message! What I cannot understand, in the
first place, is:
1. I've set the header X-Kannel-DLR-Mask=31, so the INSERT SQL statement set mask=31.
However, the tag "056" in each 1st CIMD2 message is set to 14. Note that according to
the CIMD2 specification, the tag "056" means "Status report request".
2. I expected to have everything about DLR directly stored in the database. However, it seemed
that I have to use the DLR-URL to update the database.
3. Why did Kannel remove database entries, but for not successive WAP Push messages?
From: Stipe Tolj [mailto:st at tolj.org]
Sent: Wednesday, December 06, 2006 7:35 PM
To: Andrikopoulos Dimitrios
Subject: Re: PPG - CIMD2 - DLR
Andrikopoulos Dimitrios wrote:
> Hello Stipe,
> I eventually managed to configure Kannel as a Push Proxy Gateway
> (PPG), interconnect it with a NOKIA SMS-C (which understands CIMD2),
> and a MySQL database for storing the SMS
> level delivery reports (DLR). Please find attached the configuration
> file and a PAP/HTTP request.
> Note that if you define the "default-dlr-url" attribute of the group
> "ppg" in the Kannel's configuration file, there is no need to define
> the "X-Kannel-DLR-Url" header in the PAP/HTTP
> request. However, if you neither define a "X-Kannel-DLR-Url" header, nor
> the "default-dlr-url"
> attribute, Kannel will not request a DLR from SMS-C. You should also
> note the value of the header
> "X-Kannel-DLR-Mask": I've only got DLR for specific values of that
> header. However, I didn't deal
> with what the reason was: either Kannel didn't request DLR, or the SMS-C
> didn't send DLR.
definetly a) Kannel didn't request DLR. Since Kannel will *ONLY* request DLR if
both values dlr-url and dlr-mask are given. That has semantical reasons. A mask
only would imply Kannel to receive the DLR, but there would be no "way" to pass
that DLR information (since missing DLR-URL), so Kannel treats this condition
like unwanted in other worst "without value" and therefore does not request DLR
> Finally, I have two issues:
> 1. I send Unicode messages, so Kannel sends 3 CIMD2 messages to
> SMS-C for each PAP
> message. When I send a PAP message to Kannel, Kannel inserts a
> record in database,
> as soon as it sends the first CIMD2 message. On the other
> hand, I receive at the DLR-URL
> (defined with either "X-Kannel-DLR-Url", or "default-dlr-url")
> a HTTP request with
> When I send another PAP message, Kannel does the same, but now
> I receive an additional
> HTTP request at the DLR-URL with status=1, and the
> corresponding record in the database
> is removed. This procedure is repeated for PAP message by PAP
ok, the status 8 means semantically: SMSC accepted the message for processing.
The status 1 is a final state meaning: termianted on target device.
But the issue here seems to be with the concatenation of the MT chunks and the
DLR signaling, right?
Can you forward me a dump of bearerbox.log in debug log-level where I can trace
that sending of MT chunks towards SMSC and the receive of the DLRs?!
I need to see that happening in the logs to see actually the logic taking place.
But(!) you need to take care that you make the DLR signaling to your application
that receives the DLR-URL HTTP GET call is unique.
Aaaaaa, ok, I see. PPG does the chunk splitting, so you can unique the chunks on
your own via putting some dedicated DLR-URL parameters inside.
Please forward the bearerbox.log. In addition it would be good if you file a bug
report to http://bugs.kannel.org/ describing the issue as detailed as possible,
so we keep track of the issue.
> 2. Does anyone know what is the maximum number of recipients that
> Kannel supports in case
> of a PAP message destined to multiple recipients?
good question. We'd need to clarify this from the code itself. Please post this
question to the devel@ mailing list, so others can pick it up also.
Kölner Landstrasse 419
40589 Düsseldorf, NRW, Germany
tolj.org system architecture Kannel Software Foundation (KSF)
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 12893 bytes
Url : http://www.kannel.org/pipermail/devel/attachments/20061207/d58b8b19/attachment-0001.obj
More information about the devel