Re: dlr mask question...

On Mittwoch, September 24, 2003, at 11:20  Uhr, Alan McNatty wrote:

> On Wed, 2003-09-24 at 23:21, Alexander Malysh wrote:
>>>
>>> I'm voting -1 for this mix feature
>>
>> I'm -0 for removing it. It's a nice mix ;) Some smsc's are soo broken 
>> , that
>> msgs are rejected even when msg is correct... Ok I know , you would 
>> say: use
>> DLR_SMSC_FAIL ;)
>
> If you know the SMSC is broken why not ensure you ask for all DLR's you
> need. I'm with Bruno on this on I'm only interested in getting what I
> ask for. Also -1 for this mix feature.
>
> Just my NZD0.02
>
> Cheers,
> Alan
>

This is not a question of SMSC being broken or not.

 From a user's perspective you ask for a delivery report. You want to 
know success or failure which are the two things you are interested in. 
Those are the two most important ones to know. The end user doesn't 
want to know exactly where it fails or why but he for sure want to know 
that it failed. Now the "final" failure can be while submitting the SMS 
to the SMSC (for example: invalid number) or during the final delivery 
attempt (expired, number not in service) etc. Some errors like invalid 
number can be created at delivery to SMSC or later. For example if I 
submit a SMS to "00001234", the SMSC will immediately know that 
something's wrong and reject the message right away but with a number 
of "010123456" he might only notice when he tries to attempt for the 
first time. So in my eyes it makes sense to take a failure at submittal 
and present it to the end user as final failure as thats what it really 
is.

This would mean at time we generate DLR_SMSC_FAIL, we also create 
DLR_FAIL automatically. In my eyes, DLR_SMSC_FAIL and DLR_SMSC_SUCCESS 
are statuses you only look into when you are debugging stuff. In the 
original design they where not implemented.

So in my eyes we could remove DLR_SMSC_FAIL as status totally because 
DLR_FAIL is as good as DLR_SMSC_FAIL. And DLR_BUFFERED comes almost to 
the same to DLR_SMSC_SUCCESS. In EMI/UCP Buffered is being reported by 
the SMSC after the first attempt has been made to deliver the message. 
On SMPP SMSC's you don't have this status and DLR_SMSC_SUCCESS is as 
good as DLR_BUFFERED in that respect.


so my proposal would be to:

a) drop DLR_SMSC_FAIL and replace it with DLR_FAIL. If a message can 
not be delivered it failed. And there's nothing we can do about it but 
report it. But not reporting it at all depending on where it failed is 
not user friendly. It would result in everyone having to add 
DLR_SMSC_FAIL specifically which means every end user has to take a 
closer look at the nitty gritty of the SMSC statuses.

b) in non EMI/UCP drivers, generate DLR_BUFFERED in addition to 
DLR_SMSC_SUCCESS.

So we will end up with 
DLR_SUCCESS,DLR_FAIL,DLR_SMSC_SUCCESS,DLR_BUFFERED in status values.

Andreas Fink
Global Networks Switzerland AG

------------------------------------------------------------------
Tel: +41-61-6666333  Fax: +41-61-6666334   Mobile: +41-79-2457333
Global Networks, Inc. Clarastrasse 3, 4058 Basel, Switzerland
Web: http://www.global-networks.ch/      [email protected]
------------------------------------------------------------------