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

Reply via email to