Hi,
Wierd because I sent it as an attachment.
Kind Regards,
-Original Message-
From: Alexander Malysh [mailto:malys...@googlemail.com] On Behalf Of
Alexander Malysh
Sent: Tuesday, September 14, 2010 6:44 PM
To: Michael Zervakis
Cc: devel@kannel.org; aguerri...@kannel.org
Subject
Hi,
I moved smscconn_uuid to struct split_parts. Please check.
BR,
-Original Message-
From: Alexander Malysh [mailto:malys...@googlemail.com] On Behalf Of
Alexander Malysh
Sent: Tuesday, September 14, 2010 1:02 AM
To: Michael Zervakis
Cc: devel@kannel.org; aguerri...@kannel.org
: Alexander Malysh [mailto:malys...@googlemail.com] On Behalf Of
Alexander Malysh
Sent: Sunday, September 12, 2010 1:06 PM
To: Michael Zervakis
Cc: devel@kannel.org; pon...@appcell.net
Subject: Re: [PATCH] fix bug #529 (sms-resend-* ignored for concatenated
messages)
Hi,
as I already wrote
[mailto:aguerri...@kannel.org]
Sent: Monday, September 13, 2010 8:25 PM
To: Alexander Malysh
Cc: Michael Zervakis; malys...@googlemail.com; devel@kannel.org
Subject: Re: [PATCH] fix bug #529 (sms-resend-* ignored for concatenated
messages)
The uuid would be different each time you start the service
Hi Alex,
You mean that you prefer metadata=?smpp?pdu_type=data_sm over
this metadata=?smpp_data_sm? . In this case we'll have to change
meta_data.c-*meta_data_unpack(const Octstr *data) to omit
pdu_type=data_sm since this is not a TLV group.
Regards,
Michael Zervakis
-Original
*msg_to_sm_pdu() and
*msg_to_datasm_pdu() for submit_sm and data_sm() PDUs respectively and
handle_pdu() got a new case for incoming data_sm_resp PDU.
BR,
Michael Zervakis
-Original Message-
From: Alexander Malysh [mailto:malys...@googlemail.com] On Behalf Of
Alexander Malysh
Sent
Dear all,
Kannel implementation of OISD will discard empty mobile originated
sms. I think this is not acceptable in most cases. This simple patch
should fix this.
BR,
Michael Zervakis
Index: smsc_oisd.c
===
--- smsc_oisd.c
Dear Alex,
From my experience endless loops from temporary errors usually occur
before ever transmitting the first message part. It's a very rare
occurence to transmit first part and then enter in an endless loop with
left parts. A partial fix could be to keep two counters in split_parts
should be set at msec and not 1 sec. The attached patch maintains
the default 1 sec. sleep time and is introducing a new configuration
directive throttling-sleep-time which allows the user to define sleep
time in msec.
BR,
Michael Zervakis
Index: gw/smsc/smsc_smpp.c
Data_sm can be used as an alternate of submit_sm when transmitting
optional parameters (meta-data) and some carriers require the use of
data_sm for MT charging applications.
Since Kannel is not implementing this feature it's a good idea to start
a discussion on how this could be implemented.
necessary data will be included in meta-data=?smpp? ?
-Original Message-
From: Alejandro Guerrieri [mailto:aguerri...@kannel.org]
Sent: Friday, November 27, 2009 12:04 PM
To: Michael Zervakis
Cc: devel@kannel.org
Subject: Re: SMPP data_sm implementation for MT messages
What about
:32 PM
To: Michael Zervakis
Cc: devel@kannel.org; aguerri...@kannel.org
Subject: Re: SMPP data_sm implementation for MT messages
Hi,
why not just use metadata=?smpp?operation=data_sm... ?
then you can check in smsc_smpp whether submit_sm or data_sm should be used.
Whether you
-boun...@kannel.org [mailto:devel-boun...@kannel.org] On
Behalf Of Stipe Tolj
Sent: Wednesday, February 25, 2009 5:40 PM
Cc: devel@kannel.org
Subject: Re: Disable Nagle (enable TCP_NODELAY) ?
Michael Zervakis schrieb:
Hello,
Has anyone ever tried to disable Nagle at Kannel? I'm
To: Michael Zervakis
Cc: devel@kannel.org
Subject: Re: DLR parsing issue with SMPP
the delivery report is ill formatted:
2009-09-28 17:45:23 [9399] [14] DEBUG: data: 31 30 37 39 38 34 39 33 35
36 30 30 31 30 30 31 1079849356001001
2009-09-28 17:45:23 [9399] [14] DEBUG: data: 30 39 30 39 32 38
-outgoing_queue or pdata-received. I created a
simple patch to implement this so please comment.
Sincerely,
Michael Zervakis
? smsc_cimd2.c.patch
Index: gw/smsc/smsc_cimd2.c
===
RCS file: /home/cvs/gateway/gw/smsc/smsc_cimd2.c,v
retrieving
P...
Sincerely,
Michael Zervakis
part MTs staying in queue for a day or more).
BR,
Mike Zervakis
-Original Message-
From: devel-boun...@kannel.org [mailto:devel-boun...@kannel.org] On
Behalf Of Michael Zervakis
Sent: Wednesday, February 18, 2009 1:10 AM
To: devel@kannel.org
Subject: Re: sms-resend-retry, sms-resend
Hello,
Has anyone ever tried to disable Nagle at Kannel? I'm experiencing TCP
latency with some connections and I'm suspecting Nagle has to do with it.
Regards,
Mike Zervakis
Hello,
It seems that sms-resend-retry and sms-resend-freq parameters don't
apply when we deal with splitted MT. I noticed that splitted MT stay in
queue for ever when getting errors like 0x14 message queue full. Is this
the expected behavior?
BR,
Mike
Michael Zervakis wrote:
Hello,
It seems that sms-resend-retry and sms-resend-freq parameters don't
apply when we deal with splitted MT. I noticed that splitted MT stay
in queue for ever when getting errors like 0x14 message queue full. Is
this the expected behavior?
BR,
Mike
Hello,
I
Hi,
I noticed that SMPP transmitter will sleep for 15 seconds when
receiving a 0x58 (ESME_RTHROTTLED) response declaring that ESME has
exceeded allowed message limits per second. This setting is hardcoded
and I think 15 sec is a long time to wait, so I created this patch to
allow user to
.
Looks good. As C goes it's fine. I just hope it is useful enough to
justify
the configuration expansion.
+1
BR,
Nikos
- Original Message -
From: Michael Zervakis mich...@zervakis.com
To: devel@kannel.org
Sent: Wednesday, February 04, 2009 7:51 PM
Subject: Please have a look
Alex,
Michael Zervakis schrieb:
You're right. Thanks for the patch.
Michael, can you confirm that the issue is solved by Alex's patch.
(I'm almost certain it is, but I'd simply hear a yeah, that does it
from your side).
So we can commit it to the meta-data branch.
Stipe
I applied your
Dear all,
During testing of cvs-20081021 meta-data branch we found two issues:
1. The meta_data_pack() always appends an at the end of the
resulting string. As a result sms.meta_data always contains an at
the end, which produces queries like the following:
DEBUG: Query:
Alexander Malysh wrote:
Michael Zervakis schrieb:
Dear all,
During testing of cvs-20081021 meta-data branch we found two issues:
1. The meta_data_pack() always appends an at the end of the
resulting string. As a result sms.meta_data always contains an at
the end, which
Dear All,
I built the cvs-20081021 that includes meta-data code to test it.
In bearerbox configuration I included the following to receive MO TLV
0x0204 (defined optional parameter)
group = smpp-tlv
name = user_message_reference
tag = 0x0204
length = 2
type = integer
The deliver_sm PDU sent
Dear all,
We connect to a SMPP SMSC using kannel and we had problems reading
greek characters when data coding was set to 3. I attached the
modifications to gw/smsc/smsc_smpp.c that solved the problem.
Regards
Index: gw/smsc/smsc_smpp.c
Dear All
We noticed that CIMD2 send messages loop will never exit as long as
outgoing_queue has data. This means that if we have a constant queue of
at least 1 MT, Kannel will not process the buffer of received MOs. In
real world situations we noticed that Kannel halted the processing of
?
On 03.10.2008, at 11:23, Michael Zervakis wrote:
/ Dear all,
//
// We connect to a SMPP SMSC using kannel and we had problems reading
// greek characters when data coding was set to 3. I attached the
// modifications to gw/smsc/smsc_smpp.c that solved the problem.
//
// Regards
// Index: gw
Hello,
I noticed that when bearerbox receives multipart sms from a CIMD2
connection it won't route it to smsbox and it will keep multipart sms
queued indefinitely. However if bearerbox is restarted all previously
queued multipart sms are routed to smsbox.
Any help will be appreciated.
Dear all,
I ran into trouble with a carrier using Sema SMSC Version G8.1 OIS
v5.8. Actually this Sema SMSC is sending Deliver SM commands to Kannel
containing more than one SM. As a result Kannel rejects this command and
closes the connection to the SMSC
This is an example of a Deliver
Hi Frank,
Thanks for the reply. According to CIMD2 specification you can use
up to 128 different packet numbers when submitting MT's. The biggest
network operator in Greece uses CIMD2 configured to accept multiple
submit SM operations as long as you don't send duplicate packet numbers
Hi,
I tested kannel with a CIMD2 SMSC and found out that smsc_cimd2.c
logic is to use a single IO thread (io_thread) while writing
and reading from the connected socket. The issue that arises from this
approach is that when for example a 03 operation is submitted to the
SMSC no other
33 matches
Mail list logo
