Franck,
The dlr part is inherited from the "kannel" smsc format. In the actual
implementation there's no way to grab the remote message id from a
request, and it'd make a lot of sense to be able to do it.
I can try adding it, but don't refrain to do it so yourself if you
feel the urge (you'll learn a lot about the code in the process!).
Opinions?
--
Alejandro Guerrieri
aguerri...@kannel.org
On 09/06/2009, at 17:47, Franck LAMASUTA wrote:
Hi Alejandro ,
I work with Hervé who posted to this list the 25th of May (Claro
http communication).
It seems the patch you've done on the generic part could be very
useful for us to manage our communications with Claro. It could be
better than a specific implementation for Claro.
However, I don't understand how your patch manages a DLR:
In generic_receive_sms(), you call dlr_find() (line 1674 of the
patched source) to retrieve a previous record stored in the DLR
storage.
It seems fine except that dlr_add() is never called in
generic_parse_reply(), so I guess dlr_find() will always return NULL.
Am I wrong???
In fact, when we submit a MT SMS to Claro with this request
http://retail.mds.claro.com.br/MSE/api?profile=xxxx&pwd=xxxx&mode=assync-delivery&ANUM=3333&BNUM=1234567&TEXT=test
we get a HTTP code 200 with this body:
<?xml version="1.0" encoding="UTF-8" ?>
<mse-response>
<status-code>0</status-code>
<profile>profleID</profile>
<transaction-id>1020606201622668099</transaction-id>
</mse-response>
So I guess that the transaction-id should be used in
generic_parse_reply() to call dlr_add().
Unfortunately, the current implementation does not allow to manage
such an id, it only allows to search if the request was successful
or not through the regex.
If all my hypothesis are right... :-)
I could try to patch generic_parse_reply() to manage also the id
through another regex. It will be my first Kannel patch! ;-)
If you prefer to do it, no problem, just let me know.
If I'm wrong, please clarify how it works.
Regards,
Franck
