PPG - CIMD2 - DLR

Andrikopoulos Dimitrios dandrikop at cosmote.gr
Thu Dec 7 15:36:49 CET 2006


Dear Stipe,

  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
follow.

  Please note that the second WAP Push message starts from the line 87:

		2006-12-07 15:50:08 [4852] [17] 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?

BR,
Dimitris



-----Original Message-----
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 
from SMSC.

>   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
>         status=8.
>  
>         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 
> message.

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.

Stipe

-------------------------------------------------------------------
Kölner Landstrasse 419
40589 Düsseldorf, NRW, Germany

tolj.org system architecture      Kannel Software Foundation (KSF)
http://www.tolj.org/              http://www.kannel.org/

mailto:st_{at}_tolj.org           mailto:stolj_{at}_kannel.org
-------------------------------------------------------------------
-------------- next part --------------
A non-text attachment was scrubbed...
Name: bearerbox.log
Type: application/octet-stream
Size: 12893 bytes
Desc: bearerbox.log
Url : http://www.kannel.org/pipermail/devel/attachments/20061207/d58b8b19/attachment-0001.obj 


More information about the devel mailing list