Alexander Malysh schrieb:
>
> deliver_sm.registered_delivery allow flags: 4 (SME ACK), 8 (User ACK),
> 12 (Both ACKs)
correct, that's bit 2 and 3.
> flags 1 and 2 not allowed there -> not spec conform.
that's NOT true. Literally they are NOT defined, and NOT NOT allowed. In the
semantics of a protocol there is a difference between the semantics of DEFINED
and ALLOWED. :p
But I agree, let's assume we want only the bit 2,3, hence values {4,8,12} to be
seeing in a deliver_sm for that field.
> DLR_FAILED flag -> not spec conform (allowed only DLR_SUCCESS)
> how would you signal DLR_FAILED in submit_sm.esm_class???
> Here how esm_class defined for submit_sm:
> Message Type (bits 5-2)
> x x 0 0 0 0 x x Default message Type (i.e. normal message)
> x x 0 0 1 0 x x Short Message contains ESME Delivery Acknowledgement
> x x 0 1 0 0 x x Short Message contains ESME Manual/User Acknowledgement
>
> Do you see DLR_FAILED here?
yes, th SME Delivery Acknowledgment CAN contain both, a positive, hence
DLR_SUCCESS, but also a negative, hence DLR_FAILED acknowledgment. There is
nothing defined that a SME Delivery Ack is ONLY positive.
So what do we have?
We get a deliver_sm from smsc-id A, with registered_delivery = 0x04, as you
above said. Then we set the "want positive, and negative" in the re-routed MT
submit_sm.registered_delivery = 0x01 to smsc-id B.
We get a DLR back from B with deliver_sm.esm_class mask xx0001xx set. Which also
does not imply if it's positive nor negative. And we then re-route this DLR with
submit_sm.esm_class mask xx0010xx to smsc-id A again.
Voila. There is no need to indicate success or failed here at all. Only the
"type of message", that it is a SME Ack. The "contents" indicates the state.
> Do they also expect to see DLR_FAIL??
yes, as it ONLY defines "which content do I expect", and NOT "give me a DLR at
all".
Stipe
--
-------------------------------------------------------------------
Kölner Landstrasse 419
40589 Düsseldorf, NRW, Germany
tolj.org system architecture Kannel Software Foundation (KSF)
http://www.tolj.org/ http://www.kannel.org/
mailto:st_{at}_tolj.org mailto:stolj_{at}_kannel.org
-------------------------------------------------------------------