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