Am 29.01.2009 um 12:05 schrieb Stipe Tolj:
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.
Ok, this will work... But please kill flags 1 and 2 in
deliver_sm.registered_delivery because we don't want trigger undefined
behavior ;) and implement SMPP based DLR rerouting in smsc_smpp...
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
-------------------------------------------------------------------
