Something that I was thinking after that discussion we had today, is the following:
It sounds good idea to me to add the protocol on the ACK/NACK DLRs text for the mentioned reason. Now, on regular DLRs we might be missing a similar approach... This is a sample DLR log: 2012-10-24 22:18:17 Receive DLR [SMSC:mySmsc] [SVC:xxx] [ACT:zzz] [BINF:] [FID:116615773569] [META:?smpp?dlr_err=000&message_id=116615773569&] [from:12345] [to:+11234567890] [flags:-1:-1:-1:-1:1] [msg:105:id:116615773569 sub:001 dlvrd:001 submit date:1210250418 done date:1210250418 stat:DELIVRD err:000 text:] [udh:0:] How would you tell what the protocol is there? The only 2 ways I see of knowing the protocol on that case are: 1) Parse the DLRs text and depending on its format "detect" the protocol => hacky 2) Send the meta-data on the dlr-url by usage of %D, and we'll find the protocol in there (e.g. "?smpp?") ACK/NACK DLRs don't include the protocol on meta-data, here are some examples: 2012-10-24 22:18:03 Receive DLR [SMSC:mySmsc] [SVC:xxx] [ACT:] [BINF:] [FID:116615765921] [META:] [from:12345] [to:+11234567890] [flags:-1:-1:-1:-1:8] [msg:4:ACK/] [udh:0:] 2012-10-24 22:24:09 Receive DLR [SMSC:mySmsc] [SVC:xxx] [ACT:] [BINF:] [FID:] [META:] [from:foobar] [to:+11234567890] [flags:-1:-1:-1:-1:16] [msg:42:NACK/0x00000048/Invalid Source address TON] [udh:0:] Wouldn't it be better to add it to meta-data on ACK/NACK DLRs, so that we have the protocol in there too, just like we do have it on MOs and regular DLRs? That way we can always infer it from meta-data, making all the DLR cases behave the same, therefore obtaining the protocol the same way on all cases. The same examples I just pasted would look something like this: 2012-10-24 22:18:03 Receive DLR [SMSC:mySmsc] [SVC:xxx] [ACT:] [BINF:] [FID:116615765921] [META:?smpp?] [from:12345] [to:+11234567890] [flags:-1:-1:-1:-1:8] [msg:4:ACK/] [udh:0:] 2012-10-24 22:24:09 Receive DLR [SMSC:mySmsc] [SVC:xxx] [ACT:] [BINF:] [FID:] [META:?smpp?] [from:foobar] [to:+11234567890] [flags:-1:-1:-1:-1:16] [msg:42:NACK/0x00000048/Invalid Source address TON] [udh:0:] In that case, so as to have the same behavior everywhere, maybe it should be added on MTs too? Today on MTs it's only added if you include a TLV. Another approach instead of using the protocal from meta-data, could be to just add another parameter that tells what the protocol is... (%whatever) Regards, Juan On Wed, Oct 24, 2012 at 8:56 PM, Alejandro Guerrieri < [email protected]> wrote: > Hi, > > Attached is a patch that allows passing the command_status on SMPP as > meta-data, on the smpp_error_code parameter, so on the logs (and dlr-url) > you'd get something like: > > *[META:?smpp?smpp_error_code=72&]* > * > * > This would be command status value (which is 0 for accepted messages and a > positive integer for any other outcome). > > This is based on some code Donald Jackson wrote for us time ago, and while > this might prove useful for some people, after speaking with Stipe he > mentioned that we can achieve similar results by parsing the %A parameter > on the dlr-url. In that case, the possible outcomes right now are: > > *ACK/* > *NACK/0xXXXXXXXX/Error text* > > In this case, for an accepted message, no numeric code is given. > For a rejected message, 0xXXXXXXXX contains the hex value of the > command_status > > After discussing for a little bit, Stipe pretty much talked us out of the > idea of our patch because it's non-generic (only works for SMPP). > > However, %A is far from perfect as well: > > 1. It's inconsistent. No numeric value is provided on ACK's. > 2. You cannot tell the protocol, so if you're load-balancing binds with > different protocols you'd get different error codes with no way to > correlate them by protocol. > 3. It's not documented either. > > After a very healthy debate, we thought of the following approach, keeping > the %A method: > > *ACK/SMPP:0x00000000/OK* > *NACK/SMPP:0x00000048/Invalid Source address TON* > > This slightly breaks compatibility if you were already parsing the error > code on the NACK's or doing an exact match on "ACK/" but imho is not a big > deal. > > Thoughts? Ideas? Is it something other people would be interested into? > > Regards, > > Alex >
