Yep, userguide is correct. The userguide doesn't specify anything about what values does it send over SMPP (because Kannel abstracts all that complexity from the end user as much as possible and it makes sense imho).
However, if the carrier _really_ asks for setting the bit 2, I don't see any option other than patching and branching. If he uses SVN to keep the code updated shouldn't be a big deal, though yes of course not patching is even easier. Regards, Alex On Tuesday, September 13, 2011, Nikos Balkanas wrote: > I would suggest against it. If you change the code, you are branching off, > and afterwards any updates may need manual merging. I suspect that you > didn't understand correctly your SMSc. Maybe he is just asking not to > request intermediates. Have you tried with dlr-mask = 31 and failed? Anyway, > any SMSc that doesn't support a particular type of DLR (I.e. buffered) > should simply ignore that type, not err all DLRs. > > BTW userguide is absolutely correct on dlr-mask. > > BR, > Nikos > > On Tue, Sep 13, 2011 at 11:08 PM, Mario Noboa <[email protected]> wrote: > > > 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 intermedi > >
