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]
------------------------------------------------------------------


Reply via email to