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
