Hello, I'm currently facing a similar issue using opensmppbox.
Does someone has been able to find a patch or any resolution of this issue ? Thanks in advance for your answer -----Message d'origine----- De : [email protected] [mailto:[email protected]] De la part de Nikos Balkanas Envoyé : lundi 1 août 2011 04:27 À : Mike Nelson; [email protected] Objet : Re: Responsibility for inversion of source and destination address for DLR Hi, Bb has assumed this responsibility since almost 10 years now. It inverts addresses to the original before submitting to the endpoint (smsbox). Since then a number of add-on boxes have been developed since (sqlbox, smppbox). It seems to me, that since they were created as add-ons to bb, they should abide by the bb communication API. That means that they should treat addresses as original and handle them according to their needs. If bb were to change, so would smsbox. Since both of these preexisted the other boxes, it seems to me that these boxes should align themselves to bb, not the other way around. If you decide to patch your bb, the code is in gw/dlr.c: 436 in dlr_find(). Bear in mind that if you do so, you will be branching off and future updates may need merging. BR, Nikos ----- Original Message ----- From: Mike Nelson To: [email protected] Sent: Sunday, July 31, 2011 11:43 PM Subject: Responsibility for inversion of source and destination address for DLR Hello All, I was wondering if anyone might be able to help explain to me what box has the responsibility of inverting source and destination addresses in DLRs. If possible, a pointer to where in the source code this is *supposed* to happen would also be helpful. I emphasize "supposed to" because it is my understanding from reading prior threads that there is an erroneous inversion of these fields in smsc_smpp.c's handle_pdu function. Here is some background on the motivation of this question. I am trying to troubleshoot a problem with a closed-source kannel smppbox. The issue is that the source and destination address of the deliver_sm (DLR) message is the same as the source and destination in the submit_sm message. My understanding is that this is not the proper default behavior -- that instead the source_addr of the DLR should be the destination_addr of the submit_sm and vice-versa. I wish to determine whether the problem is stemming from within this smppbox, or if the problem is in my bearerbox configuration. I am still new to kannel though, so I am not sure where one would normally expect to see the inversion of these two fields occur. By the way, the DLRs come downstream from an http smsc, but I don't think the configuration of this smsc could be the problem since the look-up in the DLR database is only being based on the dlr-mid and smsc-id -- the 'to' field seems to basically be ignored. I have been trying to trace my way through the kannel source code to determine where you would normally see the source_addr and destination_addr fields be swapped when constructing a DLR, but so far I have not been able to spot it. To me, it seems as though the source_addr always gets assigned as the source and the destination_addr always gets assigned as the destination when dropping this information into the DLR database and when pulling it out of the DLR database. It seems as though they continue to be uninverted as they are converted into 'msg'es, and these msg's are then sent to the smppbox for delivery to the ESME. Is this how it works though, or have the source_addr and destination_addr already been inverted at some point during the process of handing the message from smppbox to bearerbox to DLR database and back out? I have been staring at too much code lately, so I am hoping that someone can show me what I have missed. That is, can someone explain at what step the source_addr ("sender") of the submit_sm message should get placed into the role of destination_addr, or "receiver", for the DLR's deliver_sm PDU? Many thanks, Mike
