Re: [PATCH] SMPP command_status as meta-data

What about the protocol on regular DLRs which are submitted by the remote
SMSC on a deliver_sm?

Wouldn't a new parameter %whatever be a good idea?
That way we could use it on both cases and avoid modifying the current
ACK/NACK formats

Juan

On Fri, Oct 26, 2012 at 8:32 AM, Alexander Malysh <[email protected]>wrote:

> Hi Alex,
>
> I'm relieved to hear that :-)
>
> Ok what we could do is the following:
>
> ACK/PROTO///
> NACK/PROTO/ERRCODE/ERR DESCR/
>
> With this format we easy split DLR message on / and we have all the infos.
> Meta-data hack would be too fragile for me...
>
> I'm not sure that we need error code for ACK but will not veto it.
>
> Alex
>
> Am 25.10.2012 um 21:00 schrieb Alejandro Guerrieri <
> [email protected]>:
>
> Alex,
>
> I didn't expect the patch to be accepted, it was more of a "conversation
> starter". Anyway, perhaps it could prove useful for some people or at least
> as a guide (even about how NOT to do things) ;)
>
> Passing the error code on ACK was more about consistency than anything
> else. The protocol, as Juan mentioned, is intended to allow multi-protocol
> load balancing. It's not really needed if you stay on a single protocol,
> otherwise you'd get different error codes for the same error depending on
> the protocol you're into.
>
> Regards,
>
> Alex
>
> On Thu, Oct 25, 2012 at 12:01 PM, Alexander Malysh <[email protected]>wrote:
>
>> Hi Alex,
>>
>> this patch is no go, because you put SMPP specific handling into abstract
>> bb_smscconn.
>>
>> As to the discussion itself. We use error codes in our apps as well and
>> we were never in the
>> situation that we have to know protocol from the meta-data or message
>> itself. We have mapping
>> of SMSC name and which protocol it uses BUT we this only as exception.
>>
>> We can put protocol into NACK with error code but it make no sense for me
>> to put protocol into ACK as well as put
>> error code into ACK. ACK means accepted and I don't see any sense to
>> forward protocol specific ack error code
>> to the application layer. Am I missing something then please clarify why
>> do you need numeric value for ACK?
>>
>> If we decide to put protocol into NACK message then we should implement
>> additional callback function (get_protocol) or
>> something like this and then write it out to application layer but not as
>> you did it with mixing SMSC abstract layer and implementation
>> specific things.
>>
>> Alex
>>
>> Am 25.10.2012 um 00:56 schrieb Alejandro Guerrieri <
>> [email protected]>:
>>
>> 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
>> <kannel-command-status.patch>
>>
>>
>>
>
>