I will commit it shortly...

Am 11.11.2009 um 16:54 schrieb Alejandro Guerrieri:

> Yes you're right, now that we have MO and MT dlr info, it makes more sense to 
> have that on the "dlr" section instead of having it along the SMS data.
> 
> Also on the smsc's, having the <received> and <sent> nodes is more clear.
> 
> I'm +1 on this new format.
> 
> Do you want me to commit it myself or will you do it?
> 
> Regards,
> --
> Alejandro Guerrieri
> [email protected]
> 
> On 11/11/2009, at 16:46, Alexander Malysh wrote:
> 
>> Hi Alex,
>> 
>> I changed your patch a bit. I hope that it would me more clear for users 
>> what the all counters means.
>> 
>> New patch attached...
>> Please let me know what you think?
>> 
>> <dlr_status.diff>
>> 
>> Here examples:
>> 
>>      TXT:
>> Status: running, uptime 0d 0h 0m 9s
>> 
>> WDP: received 0 (0 queued), sent 0 (0 queued)
>> 
>> SMS: received 0 (0 queued), sent 0 (0 queued), store size -1
>> SMS: inbound (0.00,0.00,0.00) msg/sec, outbound (0.00,0.00,0.00) msg/sec
>> 
>> DLR: received 0, sent 0
>> DLR: inbound (0.00,0.00,0.00) msg/sec, outbound (0.00,0.00,0.00) msg/sec
>> DLR: 0 queued, using internal storage
>> 
>> No boxes connected
>> 
>> SMSC connections:
>>   FAKE[FAKE]    FAKE:20000 (connecting, rcvd: sms 0 / dlr 0, sent: sms 0 / 
>> dlr 0, failed 0, queued 0 msgs)
>> 
>>      XML:
>> <?xml version="1.0"?>
>> <gateway>
>> <status>running, uptime 0d 0h 0m 35s</status>
>>      <wdp>
>>              <received><total>0</total><queued>0</queued></received>
>>              <sent><total>0</total><queued>0</queued></sent>
>>      </wdp>
>>      <sms>
>>              <received><total>0</total><queued>0</queued></received>
>>              <sent><total>0</total><queued>0</queued></sent>
>>              <storesize>-1</storesize>
>>              <inbound>0.00,0.00,0.00</inbound>
>>              <outbound>0.00,0.00,0.00</outbound>
>>              </sms>
>>      <dlr>
>>              <received><total>0</total></received>
>>              <sent><total>0</total></sent>
>>              <inbound>0.00,0.00,0.00</inbound>
>>              <outbound>0.00,0.00,0.00</outbound>
>>              <queued>0</queued>
>>              <storage>internal</storage>
>>      </dlr>
>> <boxes>
>>      </boxes>
>> <smscs><count>1</count>
>>      <smsc>
>>              <name>FAKE:20000</name>
>>              <admin-id>FAKE</admin-id>
>>              <id>FAKE</id>
>>              <status>connecting</status>
>>              <received><sms>0</sms><dlr>0</dlr></received>
>>              <sent><sms>0</sms><dlr>0</dlr></sent>
>>              <failed>0</failed>
>>              <queued>0</queued>
>>      </smsc>
>> </smscs>
>> </gateway>
>> 
>> 
>> Am 11.11.2009 um 14:27 schrieb Alejandro Guerrieri:
>> 
>>> Please see attached. I'm adding the patch for the kannel-monitor later.
>>> 
>>> Regards,
>>> --
>>> Alejandro Guerrieri
>>> [email protected]
>>> 
>>> 
>>> <kannel-dlr-status-v2.diff.zip>
>>> 
>>> On 11/11/2009, at 12:33, Alexander Malysh wrote:
>>> 
>>>> 
>>>> Am 11.11.2009 um 12:09 schrieb Alejandro Guerrieri:
>>>> 
>>>>> Ok, so you'd like the patch to transparently handle the concept of 
>>>>> "outgoing" dlrs?
>>>> 
>>>> yes that would be great... This is 5 minutes patch :)
>>>> 
>>>>> 
>>>>> It would be useless on many drivers where Kannel's acting as a "client" 
>>>>> only (SMPP for instance) but yes, on HTTP and derivatives would make 
>>>>> sense.
>>>>> 
>>>>> Regards,
>>>>> --
>>>>> Alejandro Guerrieri
>>>>> [email protected]
>>>>> 
>>>>> 
>>>>> 
>>>>> On 11/11/2009, at 11:42, Alexander Malysh wrote:
>>>>> 
>>>>>> 
>>>>>> Am 11.11.2009 um 11:38 schrieb Alejandro Guerrieri:
>>>>>> 
>>>>>>> Alex,
>>>>>>> 
>>>>>>> Outgoing DLR's? At least on SMPP, there's not such a thing: when you 
>>>>>>> submit an MT with dlr-mask/dlr-url set, the submit_sm PDU has the 
>>>>>>> delivery receipt flag set. When the message is accepted (the SMSC sends 
>>>>>>> a submit_sm_resp), kannel creates a first incoming DLR and later on the 
>>>>>>> SMSC sends one incoming (deliver_sm) DLR (or more, if intermediate 
>>>>>>> DLR's are enabled) with the message status(es).
>>>>>>> 
>>>>>>> What do you mean with "outgoing DLR's" ?
>>>>>> 
>>>>>> at least for HTTP smsc we can implement DLR forwarding...
>>>>>> 
>>>>>>> 
>>>>>>> Regards,
>>>>>>> --
>>>>>>> Alejandro Guerrieri
>>>>>>> [email protected]
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> On 11/11/2009, at 9:36, Alexander Malysh wrote:
>>>>>>> 
>>>>>>>> Hi Alex,
>>>>>>>> 
>>>>>>>> I think we have to expand this patch to handle incoming and outgoing 
>>>>>>>> DLRs.
>>>>>>>> Now we don't differentiate DLRs from SMS traffic and therefore this is 
>>>>>>>> not a issue.
>>>>>>>> But if we start to differentiate DLRs from SMS we need to split it to 
>>>>>>>> incoming/outgoing
>>>>>>>> the same as for SMS traffic.
>>>>>>>> 
>>>>>>>> Thanks,
>>>>>>>> Alexander Malysh
>>>>>>>> 
>>>>>>>> Am 11.11.2009 um 08:13 schrieb Alejandro Guerrieri:
>>>>>>>> 
>>>>>>>>> Any objections? Can I commit?
>>>>>>>>> 
>>>>>>>>> Regards,
>>>>>>>>> --
>>>>>>>>> Alejandro Guerrieri
>>>>>>>>> [email protected]
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> On 10/11/2009, at 15:46, Stipe Tolj wrote:
>>>>>>>>> 
>>>>>>>>>> Alejandro Guerrieri schrieb:
>>>>>>>>>>> This patch adds separate dlr counters on the status page. This is 
>>>>>>>>>>> much
>>>>>>>>>>> clearer than now imho, where we have dlr's and mo's mixed on the 
>>>>>>>>>>> same
>>>>>>>>>>> counter.
>>>>>>>>>>> 
>>>>>>>>>>> For example:
>>>>>>>>>>> 
>>>>>>>>>>> ...
>>>>>>>>>>> 
>>>>>>>>>>> SMS: inbound (0.00,0.00,0.00) msg/sec, *dlr (0.23,0.12,0.12) 
>>>>>>>>>>> msg/sec*,
>>>>>>>>>>> outbound (0.12,0.06,0.06) msg/sec
>>>>>>>>>>> 
>>>>>>>>>>> ...
>>>>>>>>>>> 
>>>>>>>>>>> SMSC connections:
>>>>>>>>>>> 
>>>>>>>>>>> *fake*[fake]    FAKE:10000 (online 109s, rcvd 0, *dlr 14*, sent 7,
>>>>>>>>>>> failed 0, queued 0 msgs)
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> http://www.blogalex.com/archives/222
>>>>>>>>>> 
>>>>>>>>>> yep, I'm in... +0 from my side.
>>>>>>>>>> 
>>>>>>>>>> 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
>>>>>>>>>> -------------------------------------------------------------------
>>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>> 
>>>>>>> 
>>>>>> 
>>>>> 
>>>> 
>>> 
>> 
> 


Reply via email to