The access.log doesnt provide the smsc unique ID if i dont set the dlr-url

2009-03-17 07:43:26 Sent SMS [SMSC:D] [SVC:bulk1] [ACT:] [BINF:] [FID:]
[from:1001] [to:355672509006] [flags:-1:0:-1:-1:-1] [msg:11:helloworld!]
[udh:0:]
FID is empty!

With dlr-url set it is like that
2009-03-11 09:33:30 Sent SMS [SMSC:internal1] [SVC:a] [ACT:] [BINF:]
[FID:236981864111] [from:elton] [to:355672509006] [flags:-1:0:-1:-1:31]
[msg:11:helloworld!] [udh:0:]

2009/3/17 Nikos Balkanas <[email protected]>

>  Actually not. You get it in access logs.
>
> Nikos
>
> ----- Original Message -----
> *From:* Elton Hoxha <[email protected]>
> *To:* Falko Ziemann <[email protected]>
> *Cc:* Nikos Balkanas <[email protected]> ; kannel users<[email protected]>
> *Sent:* Tuesday, March 17, 2009 9:42 AM
> *Subject:* Re: Omitting the generation of delivery reports
>
> What about the message ID that comes from  SMSC??? If DLR-URL is not set
> I`m losing that value too.
>
> Regards
> Elton
>
> On Tue, Mar 17, 2009 at 8:35 AM, Falko Ziemann <[email protected]> wrote:
>
>> Simply not set the DLR-MASK and DLR-URL then kannel will not request any
>> DLR. That's the only chance.
>> Regards
>> Falko
>>
>>  Am 17.03.2009 um 08:29 schrieb Elton Hoxha:
>>
>> Hi,
>>
>> My issue doesnt concern kannel to ask SMSC for DLR. It is to tell SMSC not
>> to generate status report in the database. With DLR-MASK whatever its value
>> is, the SMSC will generate it, but KANNEL will decide whether will retrieve
>> it or not.
>> I`m using BULK SMS sending hundreed of thousands SMS and IT is exhausting
>> for SMSC to generate this amount of reports.
>>
>> Thanks
>> Elton
>>
>> 2009/3/17 Nikos Balkanas <[email protected]>
>>
>>>  Hi,
>>>
>>> Actually not. This is the part where kannel decides to ask SMSc for DLRs
>>> or not. It is not the part where it decides which DLRs to forward to the
>>> dlr_url, as suggested by Falco.
>>>
>>> BR,
>>> Nikos
>>>
>>> ----- Original Message -----
>>> *From:* Elton Hoxha <[email protected]>
>>> *To:* Falko Ziemann <[email protected]>
>>> *Cc:* kannel users <[email protected]>
>>> *Sent:* Monday, March 16, 2009 2:47 PM
>>> *Subject:* Re: Omitting the generation of delivery reports
>>>
>>> Hi,
>>>
>>> Did you mean this?
>>>
>>> if (DLR_IS_SUCCESS_OR_FAIL 
>>> <http://doxygen.kannel.org/d1/d5d/dlr_8h.html#a13>(msg->sms.dlr_mask))
>>>
>>> 00918         pdu 
>>> <http://doxygen.kannel.org/df/de6/wsp__session_8c.html#a182a79>->u 
>>> <http://doxygen.kannel.org/da/d81/structSMPP__PDU.html#o15>.submit_sm.registered_delivery
>>>  = 1;
>>>
>>>
>>> Inside the  SMPP_PDU<http://doxygen.kannel.org/da/d81/structSMPP__PDU.html>*
>>> msg_to_pdu <http://doxygen.kannel.org/de/dfe/smsc__smpp_8c.html#a23>function
>>>
>>> In we change this kannel should be recompiled again.....is there any
>>> other way?
>>>
>>> Regards
>>> Elton
>>>
>>>
>>>
>>> On Sun, Mar 15, 2009 at 7:55 PM, Falko Ziemann <[email protected]> wrote:
>>>
>>>> Hi,
>>>>
>>>> this is a protocol issue. SMPP for example has only the switch
>>>> "registered_delivery" where you can (de-)activate all DLRs. It is not
>>>> possible to activate on some kinds of DLR. Kannel has no control about 
>>>> this.
>>>> But kannel should not forward certain DLRs to the DLR-URL if you're not
>>>> interessted in them.
>>>>
>>>> Regards
>>>> Falko
>>>>
>>>> Am 15.03.2009 um 17:52 schrieb Elton Hoxha:
>>>>
>>>>
>>>> Hi all,
>>>>>
>>>>> I know this subject has been asked a lot, but my concern is something
>>>>> else. I have played with dlr-mask pretty much and it is working very well.
>>>>> In some cases I dont want to exhaust the database of SMSC creating useless
>>>>> delivery statuses for bulk SMS. Making my dlr-mask=10 didnt change 
>>>>> anything.
>>>>> It is supposed that this value concerns only to submit and failure. This 
>>>>> is
>>>>> what I need, only the acknowledment that sms has been submitted. But the
>>>>> SMSC is creating the delivery status as well, pending in the queue and
>>>>> making retries. Why the mask is behaving the same with different values?
>>>>>
>>>>> Thanks
>>>>> Elton
>>>>>
>>>>
>>>>
>>>
>>
>>
>

Reply via email to