Am 28.01.2009 um 12:26 schrieb Stipe Tolj:
Alexander Malysh schrieb:
Hi,
AFAIK deliver_sm.registered_delivery may contain values: 4, 8, 12
only.
Also 1 and 2 are wrong in the patch.
The second thing is, that ESME/SME DLRs contains only ACKs.
??? we set 1 and 2 since we want to ensure that a re-routed MO, that
is then
morphed to a MT will match the corresponding SMSC DR flags.
deliver_sm.registered_delivery allow flags: 4 (SME ACK), 8 (User ACK),
12 (Both ACKs)
flags 1 and 2 not allowed there -> not spec conform.
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?
Short to say: as from the smpp spec perspective -1
can you explain this please? I don't see any spec illegal setting we
do?
see above
For the SMPP based re-routing I don't see any sense to forward DLR
flags
without a SMPP based DLR re-routing possibility, means submit_sm for
ESME/SME ACKs should be also implemented.
DLR re-routing is POSSIBLE within Kannel, we will morph the DLR (MO)
into a MT
(submit_sm). The only "problem" is interpretation at SMSC side. But
we could use
data_sm PDU to ensure we don't clash with direction semantics for
the DLR, as
submit_sm is always SMSC->ESME and that direction doesn't apply for
a SMSC DR
itself.
that's my point. SMPP based DLR rerouting is not implemented. And this
is not the problem of
SMSC interpretation. SMSC interpretation is already defined and this
is SMPP spec.
P.S. Saw anybody deliver_sm.registered_delivery set from real SMSC in
the wild? If so how submit_sm with ACK should look like?
yep, some vendors of CDMA components that allow internal routing to
"external"
networks (GSM) via MO (deliver_sm) on their SMPP links set the
deliver_sm.registered_delivery to indicate they expect a DR from the
associated
communication partner.
Do they also expect to see DLR_FAIL??
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
-------------------------------------------------------------------
