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