Thanks guys! I figured that. I going to patch the code.
That should be some like this?
/* ask for the delivery reports if needed */
if (DLR_IS_SUCCESS_OR_FAIL(msg->sms.dlr_mask))
pdu->u.submit_sm.registered_delivery = 1;
else if (DLR_IS_FAIL(msg->sms.dlr_mask) &&
!DLR_IS_SUCCESS(msg->sms.dlr_mask))
pdu->u.submit_sm.registered_delivery = 2;
else if (DLR_IS_NOT_FINAL(msg->sms.dlr_mask) )
pdu->u.submit_sm.registered_delivery = 5;
Regards,
Mario
2011/9/13 Alejandro Guerrieri <[email protected]>
> SMPP's registered_delivery and the dlr-mask parameters are not correlated
> at all. Setting 5 in dlr-mask won't send a 5 to the carrier, but a 1.
>
> Keep in mind that Kannel's parameters are usually an abstraction on top of
> many different protocols and not just an SMPP gateway alone.
>
> Also, dlr-mask handles different scenarios that are not directly related to
> getting a deliver_sm DLR message (for example, a submit_sm_resp would
> trigger a DLR on Kannel side).
>
> Right now, Kannel only supports value 1/2 (for final success and failure
> respectively) and 17/18 (for intermediate dlr's support, it'd add 16 to the
> parameter).
>
> There's no way to send a "5" without patching the code. If you want to do
> it, you should start looking at gw/smsc/smsc_smpp.c around this lines:
>
> /* ask for the delivery reports if needed */
> if (DLR_IS_SUCCESS_OR_FAIL(msg->sms.dlr_mask))
> pdu->u.submit_sm.registered_delivery = 1;
> else if (DLR_IS_FAIL(msg->sms.dlr_mask) &&
> !DLR_IS_SUCCESS(msg->sms.dlr_mask))
> pdu->u.submit_sm.registered_delivery = 2;
>
> if (DLR_IS_INTERMEDIATE(msg->sms.dlr_mask))
> pdu->u.submit_sm.registered_delivery += 16;
>
> Hope it helps,
>
> Alex
>
> On Tuesday, September 13, 2011, Nikos Balkanas wrote:
>
>> I don't think so. Either dlr-mask doesn't correspond to bits set directly,
>> or bits requested are contradicting text description. For example dlr-mask =
>> 5 reports delivery success and smsc buffered, but no delivery failure, which
>> is requested. One could argue if SMSc buffered is asked or rather SMSc ACK
>> (and I assume NACK). Obviously the latter. In either case, Mario can always
>> try both values, and see what works.
>>
>> BR,
>> Nikos
>>
>> On Tue, Sep 13, 2011 at 9:08 PM, Milan P. Stanic <[email protected]> wrote:
>>
>>> On Tue, 2011-09-13 at 20:45, Nikos Balkanas wrote:
>>> > Sorry, for that dlr-mask should be 27...
>>>
>>> If the OP must set dlr-mask to binary 00101 that is 5 in decimal. So
>>> your previous post was correct.
>>>
>>> > On Tue, Sep 13, 2011 at 8:41 PM, Nikos Balkanas <[email protected]>
>>> wrote:
>>> >
>>> > > Hi,
>>> > >
>>> > > Have you tried setting dlr-mask to 5?
>>> > >
>>> > > BR,
>>> > > Nikos
>>> > >
>>> > > On Tue, Sep 13, 2011 at 7:32 PM, Mario Noboa <[email protected]>
>>> wrote:
>>> > >
>>> > >> hi list,
>>> > >>
>>> > >> I glad to write you. The operator ask me send the submit_sm with
>>> > >> register_deliver parameter in this way:
>>> > >>
>>> > >> .... ..01 = Delivery receipt : Delivery receipt requested (for
>>> success or
>>> > >> failure) (0x01)
>>> > >> .... 01.. = Message type : SME delivery acknowledgement
>>> requested
>>> > >> (0x01)
>>> > >> ...0 .... = Intermediate notif: No intermediate notification
>>> requested
>>> > >> (0x00)
>>> > >>
>>> > >> Thats mean to this parameter must be 5 (hexa) equivalent 0000 0101.
>>> > >>
>>> > >> In my logs always register_deliver is in 1 (sendsms with dlr-mask
>>> and
>>> > >> dlr-url of course)
>>> > >>
>>> > >> there are any way to do it without modify the code?
>>> > >>
>>> > >> Thanks for your help!
>>> > >>
>>> > >> Mario
>>> > >>
>>> > >>
>>> > >
>>>
>>> --
>>> Kind regards, Milan
>>> --------------------------------------------------
>>> Arvanta, IT Security http://www.arvanta.net
>>> Please do not send me e-mail containing HTML code.
>>>
>>>
>>