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

Hi,

I'm for the second idea, regex rocks ;)

Thanks,
Alex

Am 10.06.2009 um 12:37 schrieb Franck LAMASUTA:

> It's not so urgent but I could try, it could be interesting...
>
> I have 2 ideas so far...
>
>
> First idea
> ==========
>
> I could add 2 new config parameters to define 2 regex:
> - the first one, to find the start of the foreign id.
> - the second one, to find the end of the foreign id.
>
> For Claro, they could be defined like this:
> foreign-id-regex-begin = "<transaction-id>"
> foreign-id-regex-end = "</transaction-id>"
>
> For Clickatell, they could be defined like this:
> foreign-id-regex-begin = "ID: "
> foreign-id-regex-end = " "
>
> For Brunet, they could be defined like this:
> foreign-id-regex-begin = "MessageId="
> foreign-id-regex-end = " "
>
> In generic_parse_reply(), only in case of success, regex-begin will  
> be used to find the beginning of the id. Starting from there, regex- 
> end will be used to find the end of the id. If regex-end can't find  
> a match, the id will be read until the end of text (body) and an  
> ending CRLF will be removed.
> Then, the id will be used to call dlr_add() (like done in  
> clickatell_parse_reply()).
>
>
> Second idea
> ===========
>
> It's basically the same idea except that only one regex will be used.
>
> For Claro, it could be defined like this:
> foreign-id-regex = "<transaction-id>(.*)</transaction-id>"
>
> For Clickatell, it could be defined like this (if an id contains  
> only digits):
> foreign-id-regex = "ID: ([0-9]+)"
>
> The offsets given by gw_regex_exec() in pmatch[1] could be used to  
> extract the id.
> However, it could be more difficult to understand for people who are  
> not regex experts...
>
>
> Any comment, opinion, suggestion or better idea? :)
>
> Franck
>
>
>
>
>> From: Alexander Malysh
>> Sent: Tuesday, June 09, 2009 6:05 PM
>>
>>
>> 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&m
> ode=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
>>>>
>>>>
>>>
>>>
>>
>>
>
>