e 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;
; Sent: Tuesday, September 14, 2010 1:02 AM
> To: Michael Zervakis
> Cc: devel@kannel.org; aguerri...@kannel.org
> Subject: Re: [PATCH] fix bug #529 (sms-resend-* ignored for concatenated
> messages)
>
>
> Hi Michael,
>
>
> you don't have to alter Msg struc
ael Zervakis
Cc: devel@kannel.org
Subject: Re: [PATCH] fix bug #529 (sms-resend-* ignored for concatenated
messages)
Send it compressed, Kannel's mail server sends text attachments as part of
the body.
Regards,
--
Alejandro Guerrieri
aguerri...@kannel.org
On 15/09/2010, at 10:06, Michael Z
On Wed, 2010-09-15 at 10:52, Alejandro Guerrieri wrote:
> Send it compressed, Kannel's mail server sends text attachments as part of
> the body.
Maybe your mail client does not interpret it properly because I have got
patch as attachment.
--
Kind regards, Milan
: Re: [PATCH] fix bug #529 (sms-resend-* ignored for concatenated
messages)
could you please send your patch as attachment ?
Thanks,
Alexander Malysh
Am 14.09.2010 um 16:09 schrieb Michael Zervakis:
>
> Hi,
>
> I moved smscconn_uuid to struct split_parts. Please che
t; -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
> Subject: Re: [PATCH] fix bug #529 (sms-resend-* ignore
lto: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
> Subject: Re: [PATCH] fix bug #529 (sms-resend-* ignored for concatenated
> messages)
>
>
>
Subject: Re: [PATCH] fix bug #529 (sms-resend-* ignored for concatenated
messages)
Hi Michael,
you don't have to alter Msg struct. Just add smscconn_uuid to struct
split_parts in gw/msg.h.
Thanks,
Alexander Malysh
Am 13.09.2010 um 21:31 schrieb Michael Zervakis:
>
>
&g
y, 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 right
uerrieri [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
till
>>> active)
>>>
>>>
>>> -----Original Message-----
>>> From: Alexander Malysh [mailto:malys...@googlemail.com] On Behalf Of
>>> Alexander Malysh
>>> Sent: Sunday, September 12, 2010 1:06 PM
>>> To: Michael Zervakis
&g
part via same connection (if still
>> active)
>>
>>
>> -Original Message-
>> From: Alexander Malysh [mailto:malys...@googlemail.com] On Behalf Of
>> Alexander Malysh
>> Sent: Sunday, September 12, 2010 1:06 PM
>> To: Michael Zervakis
>> Cc: deve
[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)
>
>
-Original Message-
From: 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)
; active)
>
>
> Regards,
>
>
> From: devel-boun...@kannel.org [mailto:devel-boun...@kannel.org] On Behalf Of
> Konstantin Vayner
> Sent: Thursday, December 17, 2009 12:28 PM
> To: Alexander Malysh
> Cc: devel@kannel.org
> Subject: Re: [PATCH] fix bug #529 (sms-resend-*
.org
Subject: Re: [PATCH] fix bug #529 (sms-resend-* ignored for concatenated
messages)
why remembering smsc-id in sms.smsc_id is not enough?
how does smsbox remember routing when i submit a message with predefined
smsc id from http (sendsms) ?
On Thu, Dec 17, 2009 at 12:10 PM, Alexande
this will not help to solve our resend issue.
The steps I think of to fix it:
1) We have to remember pointer to SMSC via we sent other parts.
2) By restart of bearerbox we need to resend all parts because we don't
remember in store which part was already sent and via which SMSC.
Thanks,
Alexande
I kind of agree into making smsc-admin-id mandatory and unique, though it would
probably mean breaking many people's configuration files.
Note: If you don't specify an smsc-admin-id, it gets loaded with the smsc-id
value, so you'd only need to specify it if you're using duplicated smsc-id's.
Th
Ok, so in this case we may as well just remember the admin-smsc-id , and not
the current pointer, that would be still precise (if of course the
admin-smsc-id will be obligatory).
And thanks for the tip about the DLRs, i was banging my head against the
wall trying to find out why the dlrs keep fail
Yes, that also! :)
That's why we added the smsc-admin-id parameter to be able to manage the binds
independently from the administration interface: to avoid having to sacrifice
the non-uniqueness of smsc-id.
Regards,
Alex
--
Alejandro Guerrieri
aguerri...@kannel.org
On 19/03/2010, at 13:11,
You're using separate MO/MT binds, so yes, that's possible. But on some
scenarios, you might need the binds to appear as a single bind to your
application.
e.g., if you're using transceiver binds (or single TX/RX binds for MO/MT) and
your application can't handle different smsc names for the sa
Am 19.03.2010 um 13:05 schrieb Konstantin Vayner:
> hm.. thats weird
>
> i have several smscs in my config named smsc_carriername_mt1 ,
> smsc_carriername_mt2 , ...
> and i put allowed-smsc-id=smsc_carriername_mt in their config, then submit
> messages with smsc=smsc_carriername_mt (without nu
hm.. thats weird
i have several smscs in my config named smsc_carriername_mt1 ,
smsc_carriername_mt2 , ...
and i put allowed-smsc-id=smsc_carriername_mt in their config, then submit
messages with smsc=smsc_carriername_mt (without numbers) and kannel does
load balance between them... or at least so
smsc-id's can't be unique. That would ruin load-balancing for example.
smsc-admin-id's could be unique though... (imho, they _should_ be unique,
otherwise it's pointless to use it).
Regards,
Alex
--
Alejandro Guerrieri
aguerri...@kannel.org
On 19/03/2010, at 12:51, Konstantin Vayner wrote:
Actually, now that i'm rereading this conversation again...
> You have to remember SMSC pointer not only SMSC-name/id and then teach all
routing parts
> to respect it...
What if kannel gets shut down and then starts up again?
Obviousely, smsc pointers are different...
I say lets make smsc-id's a
Hi,
the possibility for endless loop is equal for each part. So this will not
help... We need real fix...
Thanks,
Alexander Malysh
Am 17.03.2010 um 18:04 schrieb Michael Zervakis:
> Dear Alex,
>
> From my experience endless loops from temporary errors usually occur before
> ever transmitti
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
s
Am 17.12.2009 um 11:28 schrieb Konstantin Vayner:
> why remembering smsc-id in sms.smsc_id is not enough?
due to accepted-smsc in smsc config group and because SMSCs may have the same
names (or even no names defines)...
> how does smsbox remember routing when i submit a message with predefined
why remembering smsc-id in sms.smsc_id is not enough?
how does smsbox remember routing when i submit a message with predefined
smsc id from http (sendsms) ?
On Thu, Dec 17, 2009 at 12:10 PM, Alexander Malysh wrote:
>
> Am 17.12.2009 um 10:43 schrieb Konstantin Vayner:
>
> so the best option would
Am 17.12.2009 um 10:43 schrieb Konstantin Vayner:
> so the best option would be to requeue the part via same smsc, right ?
yes, but it's not easy todo. You have to remember SMSC pointer not only
SMSC-name/id and then teach all routing parts
to respect it...
> cause requeueing all parts may als
so the best option would be to requeue the part via same smsc, right ?
cause requeueing all parts may also get extra messages to the handset
despite it not being able to reconstruct (not to mention the extra money ;)
)
On Thu, Dec 17, 2009 at 11:33 AM, Alexander Malysh wrote:
> Hi,
>
> unfortunat
Hi,
unfortunately this will not work as expected (the rule is: _all_ parts if
multipart message have to be send via the same SMSC)...
example:
SMSC-A -> splits (2 parts) -> 1 part sent OK -> 2 part get temp. error
-> you put it into global queue for resend -> 2 part sent via SMSC-B ->
Bug report: http://redmine.kannel.org/issues/show/529
Quote from gw/bb_smscconn.c :
static void handle_split(SMSCConn *conn, Msg *msg, long reason)
{
struct split_parts *split = msg->sms.split_parts;
/*
* If temporarely failed, try again immediately but only if connection
active.
33 matches
Mail list logo
