Talk to them and make sure that this is what they want from their side. Using dlr-mask = 31, the only thing you are requesting extra, is "SMSc buffered" report, which means the SMS is not delivered immediately, but with a delay. No intermediates are requested. Are you sure they can't handle that? If they can't, you can only patch the code, or change SMSc.
BR, Nikos On Wed, Sep 14, 2011 at 12:02 AM, Mario Noboa <[email protected]> wrote: > Yes Nikos, Alejandro is right. Change the code a thorn in the side. I don't > want to do it. But they wait that value, dlr does not work. > > What can i do? > > Mario > > 2011/9/13 Alejandro Guerrieri <[email protected]> > >> 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 >>> >>> >
