Did anyone get this message? I've received a couple of returns for
invalid attachment, but assumed it was from an individual user, not
the list, but maybe it wasn't?
Regards,
--
Alejandro Guerrieri
[email protected]
On 17/11/2009, at 20:40, Alejandro Guerrieri wrote:
Please find a zip with the full folder attached.
It's almost a full code rewrite, with lots of changes on the code
structure and UI as well, apart from support for the dlr fields.
I'm working on a completely new, "ajaxified" version as well, stay
tuned ;)
Regards,
--
Alejandro Guerrieri
[email protected]
<kannel-monitor.zip>
On 15/11/2009, at 15:44, Alexander Malysh wrote:
Hi,
@Alex: any news about kannel-monitor patch?
Thanks,
Alexander Malysh
Am 11.11.2009 um 19:47 schrieb Alejandro Guerrieri:
Working on it already, it'll be ready for tomorrow probably.
Regards,
--
Alejandro Guerrieri
[email protected]
On 11/11/2009, at 19:35, Alvaro Cornejo wrote:
Hi
Just don't forget the patch for the kannel-monitor
Thanks / Good work
Alvaro
|
-----------------------------------------------------------------------------------------------------------------|
Envíe y Reciba Datos y mensajes de Texto (SMS) hacia y desde
cualquier
celular y Nextel
en el Perú, México y en mas de 180 paises. Use aplicaciones 2
vias via
SMS y GPRS online
Visitenos en www.perusms.NET www.smsglobal.com.mx y
www.pravcom.com
On Wed, Nov 11, 2009 at 11:51 AM, Alexander Malysh <[email protected]
> wrote:
commited to cvs...
Am 11.11.2009 um 17:21 schrieb Alexander Malysh:
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
-------------------------------------------------------------------
