Re: [PATCH] custom MO Parameters for smsc-http

Am 09.06.2009 um 17:55 schrieb Alejandro Guerrieri:

> 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!).

yep, Alex is right here :) and we need more contributors :)

>
> Opinions?
> --
> Alejandro Guerrieri
> [email protected]
>
>
>
> 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
>>
>>
>
>