Re: users Digest, Vol 159, Issue 12

[Vijay Ramnarine]

unsubscribe
ᐧ

On Fri, Nov 22, 2019 at 6:01 AM  wrote:

> Send users mailing list submissions to
> users@kannel.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> http://www.kannel.org/mailman/listinfo/users
> or, via email, send a message with subject or body 'help' to
> users-requ...@kannel.org
>
> You can reach the person managing the list at
> users-ow...@kannel.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of users digest..."
>
>
> Today's Topics:
>
>1. Re: TLV Parameters (Alexander Malysh)
>
>
> --
>
> Message: 1
> Date: Thu, 21 Nov 2019 12:50:30 +0100
> From: Alexander Malysh 
> To: Robin C 
> Cc: users@kannel.org
> Subject: Re: TLV Parameters
> Message-ID: <049af407-9d71-43a9-a89e-6febd2678...@kannel.org>
> Content-Type: text/plain; charset="us-ascii"
>
> Hi,
>
> please start read userguide ;-)
>
>
> https://kannel.org/download/kannel-userguide-snapshot/userguide.html#AEN6481
> <
> https://kannel.org/download/kannel-userguide-snapshot/userguide.html#AEN6481
> >
>
> Alex
>
>
> > Am 21.11.2019 um 11:07 schrieb Robin C :
> >
> >
> > Hi all,
> >
> > How to add and where to add TLV parameters in Kannel ?
> > --
> >  Thanks & Regards,
> >
> >   Robin C
> >
> >
> >
> >
> >
> >
> >
> > Disclaimer:  This message contains confidential information and is
> intended only for the individual named.  If you are not the named addressee
> you should not disseminate, distribute or copy this e-mail.  Please notify
> the sender immediately by e-mail if you have received this e-mail by
> mistake and delete this e-mail from your system.  E-mail transmission
> cannot be guaranteed to be secure or error-free as information could be
> intercepted, corrupted, lost, destroyed, arrive late or incomplete, or
> contain viruses.  The sender therefore does not accept liability for any
> errors or omissions in the contents of this message, which arise as a
> result of e-mail transmission.  If verification is required please request
> a hard-copy version.
> >
> > 7 Switch off as you go |q Recycle always | P Print only if absolutely
> necessary
> >
>
> -- next part --
> An HTML attachment was scrubbed...
> URL: <
> http://www.kannel.org/pipermail/users/attachments/20191121/5e9d3b4b/attachment.htm
> >
>
> --
>
> Subject: Digest Footer
>
> ___
> users mailing list
> users@kannel.org
> http://www.kannel.org/mailman/listinfo/users
>
>
> --
>
> End of users Digest, Vol 159, Issue 12
> **
>

unsubscribe

[Vijay Ramnarine]

On Tue, Apr 10, 2018 at 6:00 AM,  wrote:

> Send users mailing list submissions to
> users@kannel.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> http://www.kannel.org/mailman/listinfo/users
> or, via email, send a message with subject or body 'help' to
> users-requ...@kannel.org
>
> You can reach the person managing the list at
> users-ow...@kannel.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of users digest..."
>
>
> Today's Topics:
>
>1. unsubscribe (??  ??)
>
>
> --
>
> Message: 1
> Date: Mon, 9 Apr 2018 10:42:24 +
> From: ??  ?? 
> To: "users@kannel.org" 
> Subject: unsubscribe
> Message-ID: 
> Content-Type: text/plain; charset="koi8-r"
>
> unsubscribe
> -- next part --
> An HTML attachment was scrubbed...
> URL:  20180409/ff451f61/attachment-0001.html>
>
> --
>
> Subject: Digest Footer
>
> ___
> users mailing list
> users@kannel.org
> http://www.kannel.org/mailman/listinfo/users
>
>
> --
>
> End of users Digest, Vol 140, Issue 12
> **
>

ᐧ

users-requ...@kannel.org

[Vijay Ramnarine]

please unsubscribe vjfro...@gmail.com

On Wed, Dec 20, 2017 at 6:00 AM,  wrote:

> Send users mailing list submissions to
> users@kannel.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> http://www.kannel.org/mailman/listinfo/users
> or, via email, send a message with subject or body 'help' to
> users-requ...@kannel.org
>
> You can reach the person managing the list at
> users-ow...@kannel.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of users digest..."
>
>
> Today's Topics:
>
>1. Multipart sms sending behaviour - Sending all the parts of a
>   multipart 1 after the other (Grant Saicom)
>2. Re: Multipart sms sending behaviour - Sending all the parts
>   of a multipart 1 after the other (amal...@kannel.org)
>3. Re: Multipart sms sending behaviour - Sending all the parts
>   of a multipart 1 after the other (Grant Saicom)
>
>
> --
>
> Message: 1
> Date: Tue, 19 Dec 2017 15:32:21 +0200
> From: Grant Saicom 
> To: Kannel Users 
> Subject: Multipart sms sending behaviour - Sending all the parts of a
> multipart 1 after the other
> Message-ID: <79071f95-f8a8-414b-94f6-1b705ac50...@gmail.com>
> Content-Type: text/plain;   charset=utf-8
>
> Hi Kannel Users
>
> I have an issue which I need to address with respect to how kannel(1.44)
> sends multipart messages to a SMSC.
>
> Let me explain the situation/limitations:
>
> -I have a server which manages and distributes smses to my modems.
> -I communicate to this server via smpp using bearerbox.
> -These modems are hosted on gateways at various locations linked via IP.
> -The server sends the messages to the gateways which then send to the
> modems via serial.
> -The server requires that it has the entire message (all multiparts)
> before it can send it to the gateway and ultimately the modem for sending
> via GSM.
> -I have a max pending sms limit of 40 on the server. This is the licensing
> model.
>
> Example Scenario of the issue:
> If I have 100 messages with 200 characters in them, kannel sends the first
> part of the first 40 messages i.e.
>
> message1 : 1 of 2
> message2 : 1 of 2
> message3 : 1 of 2
> message4 : 1 of 2
> ?
> message39 : 1 of 2
> message40 : 1 of 2
>
> The server acks these messages, but it starts rejecting any further
> messages because its max pending queue is now full. None of these messages
> will go out. The client side will eventually time-out these messages and
> fail them.
>
> How do I get bearerbox to send the messages like this:
>
> message1 : 1 of 2
> message1 : 1 of 2
> message2 : 1 of 2
> message2 : 2 of 2
> ?
>
> message39 : 1 of 2
> message39 : 2 of 2
> message40 : 1 of 2
> message40 : 2 of 2
>
> I have not found anything in the documentation that indicates how I could
> do this.
>
> Kind regards
> Grant
>
>
>
>
> --
>
> Message: 2
> Date: Tue, 19 Dec 2017 23:37:10 +0100
> From: amal...@kannel.org
> To: Grant Saicom 
> Cc: Kannel Users 
> Subject: Re: Multipart sms sending behaviour - Sending all the parts
> of a multipart 1 after the other
> Message-ID: <69476fbe-42e3-4ca3-9ecf-859c118a1...@kannel.org>
> Content-Type: text/plain;   charset=utf-8
>
> Hi,
>
> who is responsible for splitting long messages? you should let Kannel do
> it for you, then Kannel take care to send
> all parts via the same SMSC and in the right order.
>
> Thanks,
> Alex
>
>
> > Am 19.12.2017 um 14:32 schrieb Grant Saicom :
> >
> > Hi Kannel Users
> >
> > I have an issue which I need to address with respect to how kannel(1.44)
> sends multipart messages to a SMSC.
> >
> > Let me explain the situation/limitations:
> >
> > -I have a server which manages and distributes smses to my modems.
> > -I communicate to this server via smpp using bearerbox.
> > -These modems are hosted on gateways at various locations linked via IP.
> > -The server sends the messages to the gateways which then send to the
> modems via serial.
> > -The server requires that it has the entire message (all multiparts)
> before it can send it to the gateway and ultimately the modem for sending
> via GSM.
> > -I have a max pending sms limit of 40 on the server. This is the
> licensing model.
> >
> > Example Scenario of the issue:
> > If I have 100 messages with 200 characters in them, kannel sends the
> first part of the first 40 messages i.e.
> >
> > message1 : 1 of 2
> > message2 : 1 of 2
> > message3 : 1 of 2
> > message4 : 1 of 2
> > ?
> > message39 : 1 of 2
> > message40 : 1 of 2
> >
> > The server acks these messages, but it starts rejecting any further
> messages because its max pending queue is now full. None of these messages
> will go out. The client side will eventually time-out these messages and
> fail