Re: [asterisk-dev] Adding a Key/Value Store mechanism to Asterisk

2017-12-24 Thread Nir Simionovich 
@Alan,

  I've looked into both implementations - let's put it this way, both are
highly opinionated in terms of how things
need to be done. The func_redis implementation isn't bad, API wise, however
- the concept of having just
one possible Redis in the config is highly counter productive.

  I see it as being a "mysql type backend", where you can define multiple
Redis endpoints to work with.

  I believe the solution is somewhere in the middle - creating a Redis
resource that can connect to multiple
Redis database at the same time, then a layer that can work with that.



On Fri, Dec 22, 2017 at 8:07 PM Alan Graham  wrote:

> Regarding the func_redis module linked here - I contributed a couple of
> patches to it and I spoke to Sergio (the original author) and he is no
> longer associated with the IT Departament of the University of La Laguna
> Tenerife Spain, who currently owns this repository. He says that the
> current person in charge was tasked to push this upstream, and he'll send a
> message to direct them to this list.
>
> However, as he notes, this implementation opens a new connection to redis
> for each channel that uses it.
>
> You might want to also check out this project, which includes a res_redis,
> though also apparently abandoned, for some inspiration:
> https://github.com/dkgroot/ast_redis
>
> -Alan Graham
>
> On Fri, Dec 22, 2017 at 12:43 PM, Corey Farrell  wrote:
>
>> I hope we consider creating a res_redis first, then base everything off
>> that.  If a redis library can be used directly by any module that would
>> fine but I'd like to see us avoid following the example of curl where
>> everything uses a dialplan function to perform requests.  Dialplan
>> functions should be for dialplan, in general I think they should not be
>> used as internal API's.
>>
>> On 12/22/2017 12:23 PM, Nir Simionovich wrote:
>>
>> Well,
>>
>> We can start with that implementation as a base for learning, and go from
>> there. Looks like I have some homework for tonight.
>>
>> Nir
>>
>> On Fri, Dec 22, 2017, 18:44 Matt Fredrickson  wrote:
>>
>>> On Fri, Dec 22, 2017 at 10:23 AM, Ivan Poddubny >> > wrote:
>>>
 Hi,

 There is an out-of-tree implementation of func_redis:
 https://github.com/tic-ull/func_redis.
 I don't use it in production, but it worked fine for me on a test
 machine.
 With slight modifications it works with Asterisk 13+.
 Unfortunately, the project seems to be abandoned and the author did not
 try to merge the code upstream.

>>>
>>> Yeah, unless he submits it and goes through that process himself, we
>>> can't do a lot with it in the mainline Asterisk codebase.
>>>
>>> Matthew Fredrickson
>>>
>>>

 On 22 December 2017 at 16:54, Matt Fredrickson 
 wrote:

>
>
> On Fri, Dec 22, 2017 at 6:58 AM, Nir Simionovich <
> nir.simionov...@gmail.com> wrote:
>
>> Abhay,
>>
>> Migrating astsb from SQLlite to redis isn't the topic here. I'm
>> talking adding a new type of storage engine. For example, func_redis, 
>> that
>> will implement the relevant key/value operations that are commonly used 
>> by
>> people.
>>
>
> I think doing it as func_redis instead of a sorcery backend is a good
> idea.
>
> I'm guessing there are a lot of people that can use it.  It seems like
> having access to a redis like backend is a modern requirement for most big
> systems.
>
> Matthew Fredrickson
>
> Nir
>>
>> On Fri, Dec 22, 2017, 14:33 Abhay Gupta  wrote:
>>
>>> Hi All,
>>>
>>> I had a program where I have implemented a project using REDIS
>>> wherein the client is made using a socket library and no other third 
>>> party
>>> client library in C .
>>>
>>> This REDIS database has 400 million records and performs extremely
>>> well though the memory requirement for such a large dataset goes to 
>>> 48GB .
>>> So I strongly believe that for such key value pair REDIS will be the 
>>> right
>>> choice for ASTDB.
>>>
>>> Regards,
>>>
>>> Abhay
>>>
>>> On 22-Dec-2017, at 5:52 PM, Nir Simionovich <
>>> nir.simionov...@gmail.com> wrote:
>>>
>>> Hi All,
>>>
>>>   Following a discussion on JIRA [
>>> https://issues.asterisk.org/jira/browse/ASTERISK-27383], I truly
>>> believe that
>>> adding a scaleable, robust and most importantly - accepted key/value
>>> store mechanism to the Asterisk dialplan
>>> is a worthwhile effort.
>>>
>>>   Every, and I do mean every, Asterisk application requires a
>>> key/value store of some form. Most developers will
>>> basically butcher (would have used stronger words, but refraining
>>> from doing so) AstDB in the process, which will
>>> then result in a performance toll - specifically when dealing with a
>>> high capacity systems.
>>>
>>>   Initially, I was under the impression this s

Re: [asterisk-dev] Adding a Key/Value Store mechanism to Asterisk

2017-12-22 Thread Alan Graham 
Regarding the func_redis module linked here - I contributed a couple of
patches to it and I spoke to Sergio (the original author) and he is no
longer associated with the IT Departament of the University of La Laguna
Tenerife Spain, who currently owns this repository. He says that the
current person in charge was tasked to push this upstream, and he'll send a
message to direct them to this list.

However, as he notes, this implementation opens a new connection to redis
for each channel that uses it.

You might want to also check out this project, which includes a res_redis,
though also apparently abandoned, for some inspiration:
https://github.com/dkgroot/ast_redis

-Alan Graham

On Fri, Dec 22, 2017 at 12:43 PM, Corey Farrell  wrote:

> I hope we consider creating a res_redis first, then base everything off
> that.  If a redis library can be used directly by any module that would
> fine but I'd like to see us avoid following the example of curl where
> everything uses a dialplan function to perform requests.  Dialplan
> functions should be for dialplan, in general I think they should not be
> used as internal API's.
>
> On 12/22/2017 12:23 PM, Nir Simionovich wrote:
>
> Well,
>
> We can start with that implementation as a base for learning, and go from
> there. Looks like I have some homework for tonight.
>
> Nir
>
> On Fri, Dec 22, 2017, 18:44 Matt Fredrickson  wrote:
>
>> On Fri, Dec 22, 2017 at 10:23 AM, Ivan Poddubny 
>> wrote:
>>
>>> Hi,
>>>
>>> There is an out-of-tree implementation of func_redis: https://github.
>>> com/tic-ull/func_redis.
>>> I don't use it in production, but it worked fine for me on a test
>>> machine.
>>> With slight modifications it works with Asterisk 13+.
>>> Unfortunately, the project seems to be abandoned and the author did not
>>> try to merge the code upstream.
>>>
>>
>> Yeah, unless he submits it and goes through that process himself, we
>> can't do a lot with it in the mainline Asterisk codebase.
>>
>> Matthew Fredrickson
>>
>>
>>>
>>> On 22 December 2017 at 16:54, Matt Fredrickson 
>>> wrote:
>>>


 On Fri, Dec 22, 2017 at 6:58 AM, Nir Simionovich <
 nir.simionov...@gmail.com> wrote:

> Abhay,
>
> Migrating astsb from SQLlite to redis isn't the topic here. I'm
> talking adding a new type of storage engine. For example, func_redis, that
> will implement the relevant key/value operations that are commonly used by
> people.
>

 I think doing it as func_redis instead of a sorcery backend is a good
 idea.

 I'm guessing there are a lot of people that can use it.  It seems like
 having access to a redis like backend is a modern requirement for most big
 systems.

 Matthew Fredrickson

 Nir
>
> On Fri, Dec 22, 2017, 14:33 Abhay Gupta  wrote:
>
>> Hi All,
>>
>> I had a program where I have implemented a project using REDIS
>> wherein the client is made using a socket library and no other third 
>> party
>> client library in C .
>>
>> This REDIS database has 400 million records and performs extremely
>> well though the memory requirement for such a large dataset goes to 48GB 
>> .
>> So I strongly believe that for such key value pair REDIS will be the 
>> right
>> choice for ASTDB.
>>
>> Regards,
>>
>> Abhay
>>
>> On 22-Dec-2017, at 5:52 PM, Nir Simionovich <
>> nir.simionov...@gmail.com> wrote:
>>
>> Hi All,
>>
>>   Following a discussion on JIRA [https://issues.asterisk.org/
>> jira/browse/ASTERISK-27383], I truly believe that
>> adding a scaleable, robust and most importantly - accepted key/value
>> store mechanism to the Asterisk dialplan
>> is a worthwhile effort.
>>
>>   Every, and I do mean every, Asterisk application requires a
>> key/value store of some form. Most developers will
>> basically butcher (would have used stronger words, but refraining
>> from doing so) AstDB in the process, which will
>> then result in a performance toll - specifically when dealing with a
>> high capacity systems.
>>
>>   Initially, I was under the impression this should be done as a
>> sorcery module, but I'm not sure this is the
>> correct approach or the required use case.
>>
>>   I would like to hear if others believe this is a worth while
>> effort? if others believe it is, I'll be ecstatic to
>> work with others on this one (adding Redis support isn't as simple as
>> it sounds). However, before I start
>> working on something, I'd like to see if others believe this as
>> strongly as I do.
>>
>>   On the same note, I'll be in NYC second week of January - so if any
>> of you are around that area and would
>> like to combine forces to spear this - would love to do so.
>>
>>
>> --
>> Kind Regards,
>>   Nir Simionovich
>>   GreenfieldTech
>>   (schedule) http://ni

Re: [asterisk-dev] Adding a Key/Value Store mechanism to Asterisk

2017-12-22 Thread Corey Farrell 
I hope we consider creating a res_redis first, then base everything off 
that.  If a redis library can be used directly by any module that would 
fine but I'd like to see us avoid following the example of curl where 
everything uses a dialplan function to perform requests.  Dialplan 
functions should be for dialplan, in general I think they should not be 
used as internal API's.



On 12/22/2017 12:23 PM, Nir Simionovich wrote:


Well,

We can start with that implementation as a base for learning, and go 
from there. Looks like I have some homework for tonight.


Nir


On Fri, Dec 22, 2017, 18:44 Matt Fredrickson > wrote:


On Fri, Dec 22, 2017 at 10:23 AM, Ivan Poddubny
mailto:ivan.poddu...@gmail.com>> wrote:

Hi,

There is an out-of-tree implementation of func_redis:
https://github.com/tic-ull/func_redis.
I don't use it in production, but it worked fine for me on a
test machine.
With slight modifications it works with Asterisk 13+.
Unfortunately, the project seems to be abandoned and the
author did not try to merge the code upstream.


Yeah, unless he submits it and goes through that process himself,
we can't do a lot with it in the mainline Asterisk codebase.

Matthew Fredrickson


On 22 December 2017 at 16:54, Matt Fredrickson
mailto:cres...@digium.com>> wrote:



On Fri, Dec 22, 2017 at 6:58 AM, Nir Simionovich
mailto:nir.simionov...@gmail.com>> wrote:

Abhay,

Migrating astsb from SQLlite to redis isn't the topic
here. I'm talking adding a new type of storage engine.
For example, func_redis, that will implement the
relevant key/value operations that are commonly used
by people.


I think doing it as func_redis instead of a sorcery
backend is a good idea.

I'm guessing there are a lot of people that can use it. 
It seems like having access to a redis like backend is a
modern requirement for most big systems.

Matthew Fredrickson

Nir


On Fri, Dec 22, 2017, 14:33 Abhay Gupta
mailto:ab...@avissol.com>> wrote:

Hi All,

I had a program where I have implemented a project
using REDIS wherein the client is made using a
socket library and no other third party client
library in C .

This REDIS database has 400 million records and
performs extremely well though the memory
requirement for such a large dataset goes to 48GB
. So I strongly believe that for such key value
pair REDIS will be the right choice for ASTDB.

Regards,

Abhay


On 22-Dec-2017, at 5:52 PM, Nir Simionovich
mailto:nir.simionov...@gmail.com>> wrote:

Hi All,

Following a discussion on JIRA
[https://issues.asterisk.org/jira/browse/ASTERISK-27383],
I truly believe that
adding a scaleable, robust and most importantly -
accepted key/value store mechanism to the
Asterisk dialplan
is a worthwhile effort.

  Every, and I do mean every, Asterisk
application requires a key/value store of some
form. Most developers will
basically butcher (would have used stronger
words, but refraining from doing so) AstDB in the
process, which will
then result in a performance toll - specifically
when dealing with a high capacity systems.

Initially, I was under the impression this should
be done as a sorcery module, but I'm not sure
this is the
correct approach or the required use case.

  I would like to hear if others believe this is
a worth while effort? if others believe it is,
I'll be ecstatic to
work with others on this one (adding Redis
support isn't as simple as it sounds). However,
before I start
working on something, I'd like to see if others
believe this as strongly as I do.

  On the same note, I'll be in NYC second week of
January - so if any of you are around that area
and would
like to combine forces to spear this - would love
to do so.


--

Re: [asterisk-dev] Adding a Key/Value Store mechanism to Asterisk

2017-12-22 Thread Nir Simionovich 
Well,

We can start with that implementation as a base for learning, and go from
there. Looks like I have some homework for tonight.

Nir

On Fri, Dec 22, 2017, 18:44 Matt Fredrickson  wrote:

> On Fri, Dec 22, 2017 at 10:23 AM, Ivan Poddubny 
> wrote:
>
>> Hi,
>>
>> There is an out-of-tree implementation of func_redis:
>> https://github.com/tic-ull/func_redis.
>> I don't use it in production, but it worked fine for me on a test machine.
>> With slight modifications it works with Asterisk 13+.
>> Unfortunately, the project seems to be abandoned and the author did not
>> try to merge the code upstream.
>>
>
> Yeah, unless he submits it and goes through that process himself, we can't
> do a lot with it in the mainline Asterisk codebase.
>
> Matthew Fredrickson
>
>
>>
>> On 22 December 2017 at 16:54, Matt Fredrickson 
>> wrote:
>>
>>>
>>>
>>> On Fri, Dec 22, 2017 at 6:58 AM, Nir Simionovich <
>>> nir.simionov...@gmail.com> wrote:
>>>
 Abhay,

 Migrating astsb from SQLlite to redis isn't the topic here. I'm talking
 adding a new type of storage engine. For example, func_redis, that will
 implement the relevant key/value operations that are commonly used by
 people.

>>>
>>> I think doing it as func_redis instead of a sorcery backend is a good
>>> idea.
>>>
>>> I'm guessing there are a lot of people that can use it.  It seems like
>>> having access to a redis like backend is a modern requirement for most big
>>> systems.
>>>
>>> Matthew Fredrickson
>>>
>>> Nir

 On Fri, Dec 22, 2017, 14:33 Abhay Gupta  wrote:

> Hi All,
>
> I had a program where I have implemented a project using REDIS wherein
> the client is made using a socket library and no other third party client
> library in C .
>
> This REDIS database has 400 million records and performs extremely
> well though the memory requirement for such a large dataset goes to 48GB .
> So I strongly believe that for such key value pair REDIS will be the right
> choice for ASTDB.
>
> Regards,
>
> Abhay
>
> On 22-Dec-2017, at 5:52 PM, Nir Simionovich 
> wrote:
>
> Hi All,
>
>   Following a discussion on JIRA [
> https://issues.asterisk.org/jira/browse/ASTERISK-27383], I truly
> believe that
> adding a scaleable, robust and most importantly - accepted key/value
> store mechanism to the Asterisk dialplan
> is a worthwhile effort.
>
>   Every, and I do mean every, Asterisk application requires a
> key/value store of some form. Most developers will
> basically butcher (would have used stronger words, but refraining from
> doing so) AstDB in the process, which will
> then result in a performance toll - specifically when dealing with a
> high capacity systems.
>
>   Initially, I was under the impression this should be done as a
> sorcery module, but I'm not sure this is the
> correct approach or the required use case.
>
>   I would like to hear if others believe this is a worth while effort?
> if others believe it is, I'll be ecstatic to
> work with others on this one (adding Redis support isn't as simple as
> it sounds). However, before I start
> working on something, I'd like to see if others believe this as
> strongly as I do.
>
>   On the same note, I'll be in NYC second week of January - so if any
> of you are around that area and would
> like to combine forces to spear this - would love to do so.
>
>
> --
> Kind Regards,
>   Nir Simionovich
>   GreenfieldTech
>   (schedule) http://nirsimionovich.appointy.com/
>   (w) http://www.greenfieldtech.net
>   (p) +972-73-2557799 <+972%2073-255-7799>(MSN):
> n...@greenfieldtech.net
>   (m) +972-54-6982826 <+972%2054-698-2826>  (GTALK):
> nir.simionov...@gmail.com
>   (f) +972-73-2557202 <+972%2073-255-7202>  (SKYPE):
> greenfieldtech.nir
>
> --
>Zero Your Inbox 
>  | Cloud Servers 
> --
>
> *Disclaimer:*
> This e-mail is intended solely for the person to whom it is addressed
> and may contain confidential or legally privileged information. Access to
> this e-mail by anyone else is unauthorized. If an addressing or
> transmission error has misdirected this e-mail, please notify the author 
> by
> replying to this e-mail and destroy this e-mail and any attachments.
> E-mail may be susceptible to data corruption, interception,
> unauthorized amendment, viruses and delays or the consequences thereof. If
> you are not the intended recipient, be advised that you have received this
> email in error and that any use, dissemination, forwarding, printing or
>

Re: [asterisk-dev] Adding a Key/Value Store mechanism to Asterisk

2017-12-22 Thread Matt Fredrickson 
On Fri, Dec 22, 2017 at 10:23 AM, Ivan Poddubny 
wrote:

> Hi,
>
> There is an out-of-tree implementation of func_redis: https://github.
> com/tic-ull/func_redis.
> I don't use it in production, but it worked fine for me on a test machine.
> With slight modifications it works with Asterisk 13+.
> Unfortunately, the project seems to be abandoned and the author did not
> try to merge the code upstream.
>

Yeah, unless he submits it and goes through that process himself, we can't
do a lot with it in the mainline Asterisk codebase.

Matthew Fredrickson


>
> On 22 December 2017 at 16:54, Matt Fredrickson  wrote:
>
>>
>>
>> On Fri, Dec 22, 2017 at 6:58 AM, Nir Simionovich <
>> nir.simionov...@gmail.com> wrote:
>>
>>> Abhay,
>>>
>>> Migrating astsb from SQLlite to redis isn't the topic here. I'm talking
>>> adding a new type of storage engine. For example, func_redis, that will
>>> implement the relevant key/value operations that are commonly used by
>>> people.
>>>
>>
>> I think doing it as func_redis instead of a sorcery backend is a good
>> idea.
>>
>> I'm guessing there are a lot of people that can use it.  It seems like
>> having access to a redis like backend is a modern requirement for most big
>> systems.
>>
>> Matthew Fredrickson
>>
>> Nir
>>>
>>> On Fri, Dec 22, 2017, 14:33 Abhay Gupta  wrote:
>>>
 Hi All,

 I had a program where I have implemented a project using REDIS wherein
 the client is made using a socket library and no other third party client
 library in C .

 This REDIS database has 400 million records and performs extremely well
 though the memory requirement for such a large dataset goes to 48GB . So I
 strongly believe that for such key value pair REDIS will be the right
 choice for ASTDB.

 Regards,

 Abhay

 On 22-Dec-2017, at 5:52 PM, Nir Simionovich 
 wrote:

 Hi All,

   Following a discussion on JIRA [https://issues.asterisk.org/j
 ira/browse/ASTERISK-27383], I truly believe that
 adding a scaleable, robust and most importantly - accepted key/value
 store mechanism to the Asterisk dialplan
 is a worthwhile effort.

   Every, and I do mean every, Asterisk application requires a key/value
 store of some form. Most developers will
 basically butcher (would have used stronger words, but refraining from
 doing so) AstDB in the process, which will
 then result in a performance toll - specifically when dealing with a
 high capacity systems.

   Initially, I was under the impression this should be done as a
 sorcery module, but I'm not sure this is the
 correct approach or the required use case.

   I would like to hear if others believe this is a worth while effort?
 if others believe it is, I'll be ecstatic to
 work with others on this one (adding Redis support isn't as simple as
 it sounds). However, before I start
 working on something, I'd like to see if others believe this as
 strongly as I do.

   On the same note, I'll be in NYC second week of January - so if any
 of you are around that area and would
 like to combine forces to spear this - would love to do so.


 --
 Kind Regards,
   Nir Simionovich
   GreenfieldTech
   (schedule) http://nirsimionovich.appointy.com/
   (w) http://www.greenfieldtech.net
   (p) +972-73-2557799 <+972%2073-255-7799>(MSN):
 n...@greenfieldtech.net
   (m) +972-54-6982826 <+972%2054-698-2826>  (GTALK):
 nir.simionov...@gmail.com
   (f) +972-73-2557202 <+972%2073-255-7202>  (SKYPE):
 greenfieldtech.nir

 --
Zero Your Inbox  | 
 Cloud
 Servers 
 --

 *Disclaimer:*
 This e-mail is intended solely for the person to whom it is addressed
 and may contain confidential or legally privileged information. Access to
 this e-mail by anyone else is unauthorized. If an addressing or
 transmission error has misdirected this e-mail, please notify the author by
 replying to this e-mail and destroy this e-mail and any attachments.
 E-mail may be susceptible to data corruption, interception,
 unauthorized amendment, viruses and delays or the consequences thereof. If
 you are not the intended recipient, be advised that you have received this
 email in error and that any use, dissemination, forwarding, printing or
 copying of this email is strictly prohibited.

 --
 _
 -- Bandwidth and Colocation Provided by http://www.api-digital.com --

 asterisk-dev mailing list
 To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/

Re: [asterisk-dev] Adding a Key/Value Store mechanism to Asterisk

2017-12-22 Thread Ivan Poddubny 
Hi,

There is an out-of-tree implementation of func_redis:
https://github.com/tic-ull/func_redis.
I don't use it in production, but it worked fine for me on a test machine.
With slight modifications it works with Asterisk 13+.
Unfortunately, the project seems to be abandoned and the author did not try
to merge the code upstream.

On 22 December 2017 at 16:54, Matt Fredrickson  wrote:

>
>
> On Fri, Dec 22, 2017 at 6:58 AM, Nir Simionovich <
> nir.simionov...@gmail.com> wrote:
>
>> Abhay,
>>
>> Migrating astsb from SQLlite to redis isn't the topic here. I'm talking
>> adding a new type of storage engine. For example, func_redis, that will
>> implement the relevant key/value operations that are commonly used by
>> people.
>>
>
> I think doing it as func_redis instead of a sorcery backend is a good idea.
>
> I'm guessing there are a lot of people that can use it.  It seems like
> having access to a redis like backend is a modern requirement for most big
> systems.
>
> Matthew Fredrickson
>
> Nir
>>
>> On Fri, Dec 22, 2017, 14:33 Abhay Gupta  wrote:
>>
>>> Hi All,
>>>
>>> I had a program where I have implemented a project using REDIS wherein
>>> the client is made using a socket library and no other third party client
>>> library in C .
>>>
>>> This REDIS database has 400 million records and performs extremely well
>>> though the memory requirement for such a large dataset goes to 48GB . So I
>>> strongly believe that for such key value pair REDIS will be the right
>>> choice for ASTDB.
>>>
>>> Regards,
>>>
>>> Abhay
>>>
>>> On 22-Dec-2017, at 5:52 PM, Nir Simionovich 
>>> wrote:
>>>
>>> Hi All,
>>>
>>>   Following a discussion on JIRA [https://issues.asterisk.org/j
>>> ira/browse/ASTERISK-27383], I truly believe that
>>> adding a scaleable, robust and most importantly - accepted key/value
>>> store mechanism to the Asterisk dialplan
>>> is a worthwhile effort.
>>>
>>>   Every, and I do mean every, Asterisk application requires a key/value
>>> store of some form. Most developers will
>>> basically butcher (would have used stronger words, but refraining from
>>> doing so) AstDB in the process, which will
>>> then result in a performance toll - specifically when dealing with a
>>> high capacity systems.
>>>
>>>   Initially, I was under the impression this should be done as a sorcery
>>> module, but I'm not sure this is the
>>> correct approach or the required use case.
>>>
>>>   I would like to hear if others believe this is a worth while effort?
>>> if others believe it is, I'll be ecstatic to
>>> work with others on this one (adding Redis support isn't as simple as it
>>> sounds). However, before I start
>>> working on something, I'd like to see if others believe this as strongly
>>> as I do.
>>>
>>>   On the same note, I'll be in NYC second week of January - so if any of
>>> you are around that area and would
>>> like to combine forces to spear this - would love to do so.
>>>
>>>
>>> --
>>> Kind Regards,
>>>   Nir Simionovich
>>>   GreenfieldTech
>>>   (schedule) http://nirsimionovich.appointy.com/
>>>   (w) http://www.greenfieldtech.net
>>>   (p) +972-73-2557799 <+972%2073-255-7799>(MSN):
>>> n...@greenfieldtech.net
>>>   (m) +972-54-6982826 <+972%2054-698-2826>  (GTALK):
>>> nir.simionov...@gmail.com
>>>   (f) +972-73-2557202 <+972%2073-255-7202>  (SKYPE):
>>> greenfieldtech.nir
>>>
>>> --
>>>Zero Your Inbox  | Cloud
>>> Servers 
>>> --
>>>
>>> *Disclaimer:*
>>> This e-mail is intended solely for the person to whom it is addressed
>>> and may contain confidential or legally privileged information. Access to
>>> this e-mail by anyone else is unauthorized. If an addressing or
>>> transmission error has misdirected this e-mail, please notify the author by
>>> replying to this e-mail and destroy this e-mail and any attachments.
>>> E-mail may be susceptible to data corruption, interception, unauthorized
>>> amendment, viruses and delays or the consequences thereof. If you are not
>>> the intended recipient, be advised that you have received this email in
>>> error and that any use, dissemination, forwarding, printing or copying of
>>> this email is strictly prohibited.
>>>
>>> --
>>> _
>>> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
>>>
>>> asterisk-dev mailing list
>>> To UNSUBSCRIBE or update options visit:
>>>   http://lists.digium.com/mailman/listinfo/asterisk-dev
>>>
>>>
>>> --
>>> _
>>> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
>>>
>>> asterisk-dev mailing list
>>> To UNSUBSCRIBE or update options visit:
>>>http://lists.digium.com/mailman/listinfo/asterisk-dev
>>
>> --
>>
>> Kind Regard

Re: [asterisk-dev] Adding a Key/Value Store mechanism to Asterisk

2017-12-22 Thread Matt Fredrickson 
On Fri, Dec 22, 2017 at 6:58 AM, Nir Simionovich 
wrote:

> Abhay,
>
> Migrating astsb from SQLlite to redis isn't the topic here. I'm talking
> adding a new type of storage engine. For example, func_redis, that will
> implement the relevant key/value operations that are commonly used by
> people.
>

I think doing it as func_redis instead of a sorcery backend is a good idea.

I'm guessing there are a lot of people that can use it.  It seems like
having access to a redis like backend is a modern requirement for most big
systems.

Matthew Fredrickson

Nir
>
> On Fri, Dec 22, 2017, 14:33 Abhay Gupta  wrote:
>
>> Hi All,
>>
>> I had a program where I have implemented a project using REDIS wherein
>> the client is made using a socket library and no other third party client
>> library in C .
>>
>> This REDIS database has 400 million records and performs extremely well
>> though the memory requirement for such a large dataset goes to 48GB . So I
>> strongly believe that for such key value pair REDIS will be the right
>> choice for ASTDB.
>>
>> Regards,
>>
>> Abhay
>>
>> On 22-Dec-2017, at 5:52 PM, Nir Simionovich 
>> wrote:
>>
>> Hi All,
>>
>>   Following a discussion on JIRA [https://issues.asterisk.org/
>> jira/browse/ASTERISK-27383], I truly believe that
>> adding a scaleable, robust and most importantly - accepted key/value
>> store mechanism to the Asterisk dialplan
>> is a worthwhile effort.
>>
>>   Every, and I do mean every, Asterisk application requires a key/value
>> store of some form. Most developers will
>> basically butcher (would have used stronger words, but refraining from
>> doing so) AstDB in the process, which will
>> then result in a performance toll - specifically when dealing with a high
>> capacity systems.
>>
>>   Initially, I was under the impression this should be done as a sorcery
>> module, but I'm not sure this is the
>> correct approach or the required use case.
>>
>>   I would like to hear if others believe this is a worth while effort? if
>> others believe it is, I'll be ecstatic to
>> work with others on this one (adding Redis support isn't as simple as it
>> sounds). However, before I start
>> working on something, I'd like to see if others believe this as strongly
>> as I do.
>>
>>   On the same note, I'll be in NYC second week of January - so if any of
>> you are around that area and would
>> like to combine forces to spear this - would love to do so.
>>
>>
>> --
>> Kind Regards,
>>   Nir Simionovich
>>   GreenfieldTech
>>   (schedule) http://nirsimionovich.appointy.com/
>>   (w) http://www.greenfieldtech.net
>>   (p) +972-73-2557799(MSN): n...@greenfieldtech.net
>>   (m) +972-54-6982826  (GTALK): nir.simionov...@gmail.com
>>   (f) +972-73-2557202  (SKYPE): greenfieldtech.nir
>>
>> --
>>Zero Your Inbox  | Cloud
>> Servers 
>> --
>>
>> *Disclaimer:*
>> This e-mail is intended solely for the person to whom it is addressed and
>> may contain confidential or legally privileged information. Access to this
>> e-mail by anyone else is unauthorized. If an addressing or transmission
>> error has misdirected this e-mail, please notify the author by replying to
>> this e-mail and destroy this e-mail and any attachments.
>> E-mail may be susceptible to data corruption, interception, unauthorized
>> amendment, viruses and delays or the consequences thereof. If you are not
>> the intended recipient, be advised that you have received this email in
>> error and that any use, dissemination, forwarding, printing or copying of
>> this email is strictly prohibited.
>>
>> --
>> _
>> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
>>
>> asterisk-dev mailing list
>> To UNSUBSCRIBE or update options visit:
>>   http://lists.digium.com/mailman/listinfo/asterisk-dev
>>
>>
>> --
>> _
>> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
>>
>> asterisk-dev mailing list
>> To UNSUBSCRIBE or update options visit:
>>http://lists.digium.com/mailman/listinfo/asterisk-dev
>
> --
>
> Kind Regards,
>
>   Nir Simionovich
>
>   GreenfieldTech
>
>   (schedule) http://nirsimionovich.appointy.com/
>
>   (w) http://www.greenfieldtech.net
>
>   (p) +972-73-2557799(MSN): n...@greenfieldtech.net
>
>   (m) +972-54-6982826  (GTALK): nir.simionov...@gmail.com
>
>   (f) +972-73-2557202  (SKYPE): greenfieldtech.nir
>
>
> --
>
>Zero Your Inbox  | Cloud
> Servers 
>
> --
>
> *Disclaimer:*
>
>

Re: [asterisk-dev] Adding a Key/Value Store mechanism to Asterisk

2017-12-22 Thread Sean Bright 

Hi,

On 12/22/2017 7:22 AM, Nir Simionovich wrote:
  Every, and I do mean every, Asterisk application requires a 
key/value store of some form. Most developers will
basically butcher (would have used stronger words, but refraining from 
doing so) AstDB in the process, which will
then result in a performance toll - specifically when dealing with a 
high capacity systems.


If you are implementing high capacity systems and decided to use AstDB 
as your KV store, you're going to have a bad time. That is not the 
use-case for AstDB. AstDB is an 
always-there-does-not-require-configuration-general-purpose-data-store 
used primarily by internal Asterisk modules themselves. I would say any 
use of AstDB beyond that (whether it was with BDB in the old days or 
SQLite today) and expecting high throughput is ill advised.


  Initially, I was under the impression this should be done as a 
sorcery module, but I'm not sure this is the

correct approach or the required use case.


None of the Sorcery modules today implement data access themselves, they 
simply leverage one of Asterisk's existing data access providers (AstDB, 
config files, or Realtime). If you go down this path, I would suggest a 
res_redis module that provides user-facing functionality (dialplan 
functions, etc.) as well as an API for the rest of Asterisk. Then a 
res_sorcery_redis or res_sorcery_kv could be built to consume that API. 
Alternatively you could just build the Sorcery module and still provide 
the user-facing functionality from that. Either way, a Sorcery module 
should definitely be on the radar, as that is the future in terms of 
configuration.


Kind regards,
Sean

--
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
  http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [asterisk-dev] Adding a Key/Value Store mechanism to Asterisk

2017-12-22 Thread BJ Weschke 
I would have an immediate use case for something like func_redis. I think it 
would be very useful. 


On December 22, 2017 at 8:02:28 AM, Nir Simionovich (nir.simionov...@gmail.com) 
wrote:

Abhay,

Migrating astsb from SQLlite to redis isn't the topic here. I'm talking adding 
a new type of storage engine. For example, func_redis, that will implement the 
relevant key/value operations that are commonly used by people.

Nir


On Fri, Dec 22, 2017, 14:33 Abhay Gupta  wrote:
Hi All,

I had a program where I have implemented a project using REDIS wherein the 
client is made using a socket library and no other third party client library 
in C .

This REDIS database has 400 million records and performs extremely well though 
the memory requirement for such a large dataset goes to 48GB . So I strongly 
believe that for such key value pair REDIS will be the right choice for ASTDB.

Regards,

Abhay 

On 22-Dec-2017, at 5:52 PM, Nir Simionovich  wrote:

Hi All, 

  Following a discussion on JIRA 
[https://issues.asterisk.org/jira/browse/ASTERISK-27383], I truly believe that
adding a scaleable, robust and most importantly - accepted key/value store 
mechanism to the Asterisk dialplan
is a worthwhile effort. 

  Every, and I do mean every, Asterisk application requires a key/value store 
of some form. Most developers will
basically butcher (would have used stronger words, but refraining from doing 
so) AstDB in the process, which will
then result in a performance toll - specifically when dealing with a high 
capacity systems. 

  Initially, I was under the impression this should be done as a sorcery 
module, but I'm not sure this is the 
correct approach or the required use case. 

  I would like to hear if others believe this is a worth while effort? if 
others believe it is, I'll be ecstatic to 
work with others on this one (adding Redis support isn't as simple as it 
sounds). However, before I start
working on something, I'd like to see if others believe this as strongly as I 
do. 

  On the same note, I'll be in NYC second week of January - so if any of you 
are around that area and would 
like to combine forces to spear this - would love to do so.


--
Kind Regards,
  Nir Simionovich
  GreenfieldTech
  (schedule) http://nirsimionovich.appointy.com/
  (w) http://www.greenfieldtech.net 
  (p) +972-73-2557799(MSN): n...@greenfieldtech.net
  (m) +972-54-6982826  (GTALK): nir.simionov...@gmail.com
  (f) +972-73-2557202  (SKYPE): greenfieldtech.nir

--
               Zero Your Inbox | Cloud Servers
-- 

Disclaimer:
This e-mail is intended solely for the person to whom it is addressed and may 
contain confidential or legally privileged information. Access to this e-mail 
by anyone else is unauthorized. If an addressing or transmission error has 
misdirected this e-mail, please notify the author by replying to this e-mail 
and destroy this e-mail and any attachments. 
E-mail may be susceptible to data corruption, interception, unauthorized 
amendment, viruses and delays or the consequences thereof. If you are not the 
intended recipient, be advised that you have received this email in error and 
that any use, dissemination, forwarding, printing or copying of this email is 
strictly prohibited.
--
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
  http://lists.digium.com/mailman/listinfo/asterisk-dev

--
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev
--
Kind Regards,
  Nir Simionovich
  GreenfieldTech
  (schedule) http://nirsimionovich.appointy.com/
  (w) http://www.greenfieldtech.net 
  (p) +972-73-2557799(MSN): n...@greenfieldtech.net
  (m) +972-54-6982826  (GTALK): nir.simionov...@gmail.com
  (f) +972-73-2557202  (SKYPE): greenfieldtech.nir

--
               Zero Your Inbox | Cloud Servers
-- 
Disclaimer:
This e-mail is intended solely for the person to whom it is addressed and may 
contain confidential or legally privileged information. Access to this e-mail 
by anyone else is unauthorized. If an addressing or transmission error has 
misdirected this e-mail, please notify the author by replying to this e-mail 
and destroy this e-mail and any attachments. 
E-mail may be susceptible to data corruption, interception, unauthorized 
amendment, viruses and delays or the consequences thereof. If you are not the 
intended recipient, be advised that you have received this email in error and 
that any use,

Re: [asterisk-dev] Adding a Key/Value Store mechanism to Asterisk

2017-12-22 Thread George Joseph 
On Fri, Dec 22, 2017 at 5:22 AM, Nir Simionovich 
wrote:

> Hi All,
>
>   Following a discussion on JIRA [https://issues.asterisk.org/
> jira/browse/ASTERISK-27383], I truly believe that
> adding a scaleable, robust and most importantly - accepted key/value store
> mechanism to the Asterisk dialplan
> is a worthwhile effort.
>
>   Every, and I do mean every, Asterisk application requires a key/value
> store of some form. Most developers will
> basically butcher (would have used stronger words, but refraining from
> doing so) AstDB in the process, which will
> then result in a performance toll - specifically when dealing with a high
> capacity systems.
>
>   Initially, I was under the impression this should be done as a sorcery
> module, but I'm not sure this is the
> correct approach or the required use case.
>
>   I would like to hear if others believe this is a worth while effort? if
> others believe it is, I'll be ecstatic to
> work with others on this one (adding Redis support isn't as simple as it
> sounds). However, before I start
> working on something, I'd like to see if others believe this as strongly
> as I do.
>

I think it's a great idea!  If you start out doing it as a standalone
dialplan function or app, you have the freedom to experiment and tune the
approach without affecting the rest of Asterisk.  If it works well, then we
can talk about how to use what you've learned as part of a general
performance improvement.





>
>   On the same note, I'll be in NYC second week of January - so if any of
> you are around that area and would
> like to combine forces to spear this - would love to do so.
>
>
> --
>
> Kind Regards,
>
>   Nir Simionovich
>
>   GreenfieldTech
>
>   (schedule) http://nirsimionovich.appointy.com/
>
>   (w) http://www.greenfieldtech.net
>
>   (p) +972-73-2557799(MSN): n...@greenfieldtech.net
>
>   (m) +972-54-6982826  (GTALK): nir.simionov...@gmail.com
>
>   (f) +972-73-2557202  (SKYPE): greenfieldtech.nir
>
>
> --
>
>Zero Your Inbox  | Cloud
> Servers 
>
> --
>
> *Disclaimer:*
>
> This e-mail is intended solely for the person to whom it is addressed and
> may contain confidential or legally privileged information. Access to this
> e-mail by anyone else is unauthorized. If an addressing or transmission
> error has misdirected this e-mail, please notify the author by replying to
> this e-mail and destroy this e-mail and any attachments.
> E-mail may be susceptible to data corruption, interception, unauthorized
> amendment, viruses and delays or the consequences thereof. If you are not
> the intended recipient, be advised that you have received this email in
> error and that any use, dissemination, forwarding, printing or copying of
> this email is strictly prohibited.
>
> --
> _
> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
>
> asterisk-dev mailing list
> To UNSUBSCRIBE or update options visit:
>http://lists.digium.com/mailman/listinfo/asterisk-dev
>



-- 
George Joseph
Digium, Inc. | Software Developer
445 Jan Davis Drive NW - Huntsville, AL 35806 - US
Check us out at: www.digium.com & www.asterisk.org
-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

Re: [asterisk-dev] Adding a Key/Value Store mechanism to Asterisk

2017-12-22 Thread Nir Simionovich 
Abhay,

Migrating astsb from SQLlite to redis isn't the topic here. I'm talking
adding a new type of storage engine. For example, func_redis, that will
implement the relevant key/value operations that are commonly used by
people.

Nir

On Fri, Dec 22, 2017, 14:33 Abhay Gupta  wrote:

> Hi All,
>
> I had a program where I have implemented a project using REDIS wherein the
> client is made using a socket library and no other third party client
> library in C .
>
> This REDIS database has 400 million records and performs extremely well
> though the memory requirement for such a large dataset goes to 48GB . So I
> strongly believe that for such key value pair REDIS will be the right
> choice for ASTDB.
>
> Regards,
>
> Abhay
>
> On 22-Dec-2017, at 5:52 PM, Nir Simionovich 
> wrote:
>
> Hi All,
>
>   Following a discussion on JIRA [
> https://issues.asterisk.org/jira/browse/ASTERISK-27383], I truly believe
> that
> adding a scaleable, robust and most importantly - accepted key/value store
> mechanism to the Asterisk dialplan
> is a worthwhile effort.
>
>   Every, and I do mean every, Asterisk application requires a key/value
> store of some form. Most developers will
> basically butcher (would have used stronger words, but refraining from
> doing so) AstDB in the process, which will
> then result in a performance toll - specifically when dealing with a high
> capacity systems.
>
>   Initially, I was under the impression this should be done as a sorcery
> module, but I'm not sure this is the
> correct approach or the required use case.
>
>   I would like to hear if others believe this is a worth while effort? if
> others believe it is, I'll be ecstatic to
> work with others on this one (adding Redis support isn't as simple as it
> sounds). However, before I start
> working on something, I'd like to see if others believe this as strongly
> as I do.
>
>   On the same note, I'll be in NYC second week of January - so if any of
> you are around that area and would
> like to combine forces to spear this - would love to do so.
>
>
> --
> Kind Regards,
>   Nir Simionovich
>   GreenfieldTech
>   (schedule) http://nirsimionovich.appointy.com/
>   (w) http://www.greenfieldtech.net
>   (p) +972-73-2557799(MSN): n...@greenfieldtech.net
>   (m) +972-54-6982826  (GTALK): nir.simionov...@gmail.com
>   (f) +972-73-2557202  (SKYPE): greenfieldtech.nir
>
> --
>Zero Your Inbox  | Cloud
> Servers 
> --
>
> *Disclaimer:*
> This e-mail is intended solely for the person to whom it is addressed and
> may contain confidential or legally privileged information. Access to this
> e-mail by anyone else is unauthorized. If an addressing or transmission
> error has misdirected this e-mail, please notify the author by replying to
> this e-mail and destroy this e-mail and any attachments.
> E-mail may be susceptible to data corruption, interception, unauthorized
> amendment, viruses and delays or the consequences thereof. If you are not
> the intended recipient, be advised that you have received this email in
> error and that any use, dissemination, forwarding, printing or copying of
> this email is strictly prohibited.
>
> --
> _
> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
>
> asterisk-dev mailing list
> To UNSUBSCRIBE or update options visit:
>   http://lists.digium.com/mailman/listinfo/asterisk-dev
>
>
> --
> _
> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
>
> asterisk-dev mailing list
> To UNSUBSCRIBE or update options visit:
>http://lists.digium.com/mailman/listinfo/asterisk-dev

-- 

Kind Regards,

  Nir Simionovich

  GreenfieldTech

  (schedule) http://nirsimionovich.appointy.com/

  (w) http://www.greenfieldtech.net

  (p) +972-73-2557799(MSN): n...@greenfieldtech.net

  (m) +972-54-6982826  (GTALK): nir.simionov...@gmail.com

  (f) +972-73-2557202  (SKYPE): greenfieldtech.nir


--

   Zero Your Inbox  | Cloud
Servers 

--

*Disclaimer:*

This e-mail is intended solely for the person to whom it is addressed and
may contain confidential or legally privileged information. Access to this
e-mail by anyone else is unauthorized. If an addressing or transmission
error has misdirected this e-mail, please notify the author by replying to
this e-mail and destroy this e-mail and any attachments.
E-mail may be susceptible to data corruption, interception, unauthorized
amendment, viruses and delays or the

Re: [asterisk-dev] Adding a Key/Value Store mechanism to Asterisk

2017-12-22 Thread Abhay Gupta 
Hi All,

I had a program where I have implemented a project using REDIS wherein the 
client is made using a socket library and no other third party client library 
in C .

This REDIS database has 400 million records and performs extremely well though 
the memory requirement for such a large dataset goes to 48GB . So I strongly 
believe that for such key value pair REDIS will be the right choice for ASTDB.

Regards,

Abhay 

> On 22-Dec-2017, at 5:52 PM, Nir Simionovich  wrote:
> 
> Hi All, 
> 
>   Following a discussion on JIRA 
> [https://issues.asterisk.org/jira/browse/ASTERISK-27383 
> ], I truly believe 
> that
> adding a scaleable, robust and most importantly - accepted key/value store 
> mechanism to the Asterisk dialplan
> is a worthwhile effort. 
> 
>   Every, and I do mean every, Asterisk application requires a key/value store 
> of some form. Most developers will
> basically butcher (would have used stronger words, but refraining from doing 
> so) AstDB in the process, which will
> then result in a performance toll - specifically when dealing with a high 
> capacity systems. 
> 
>   Initially, I was under the impression this should be done as a sorcery 
> module, but I'm not sure this is the 
> correct approach or the required use case. 
> 
>   I would like to hear if others believe this is a worth while effort? if 
> others believe it is, I'll be ecstatic to 
> work with others on this one (adding Redis support isn't as simple as it 
> sounds). However, before I start
> working on something, I'd like to see if others believe this as strongly as I 
> do. 
> 
>   On the same note, I'll be in NYC second week of January - so if any of you 
> are around that area and would 
> like to combine forces to spear this - would love to do so.
> 
> 
> -- 
> Kind Regards,
>   Nir Simionovich
>   GreenfieldTech
>   (schedule) http://nirsimionovich.appointy.com/ 
> 
>   (w) http://www.greenfieldtech.net  
>   (p) +972-73-2557799(MSN): n...@greenfieldtech.net 
> 
>   (m) +972-54-6982826  (GTALK): nir.simionov...@gmail.com 
> 
>   (f) +972-73-2557202  (SKYPE): greenfieldtech.nir
> 
> --
>Zero Your Inbox  | Cloud 
> Servers 
> -- 
> 
> Disclaimer:
> This e-mail is intended solely for the person to whom it is addressed and may 
> contain confidential or legally privileged information. Access to this e-mail 
> by anyone else is unauthorized. If an addressing or transmission error has 
> misdirected this e-mail, please notify the author by replying to this e-mail 
> and destroy this e-mail and any attachments. 
> E-mail may be susceptible to data corruption, interception, unauthorized 
> amendment, viruses and delays or the consequences thereof. If you are not the 
> intended recipient, be advised that you have received this email in error and 
> that any use, dissemination, forwarding, printing or copying of this email is 
> strictly prohibited.
> -- 
> _
> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
> 
> asterisk-dev mailing list
> To UNSUBSCRIBE or update options visit:
>   http://lists.digium.com/mailman/listinfo/asterisk-dev

-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev

[asterisk-dev] Adding a Key/Value Store mechanism to Asterisk

2017-12-22 Thread Nir Simionovich 
Hi All,

  Following a discussion on JIRA [
https://issues.asterisk.org/jira/browse/ASTERISK-27383], I truly believe
that
adding a scaleable, robust and most importantly - accepted key/value store
mechanism to the Asterisk dialplan
is a worthwhile effort.

  Every, and I do mean every, Asterisk application requires a key/value
store of some form. Most developers will
basically butcher (would have used stronger words, but refraining from
doing so) AstDB in the process, which will
then result in a performance toll - specifically when dealing with a high
capacity systems.

  Initially, I was under the impression this should be done as a sorcery
module, but I'm not sure this is the
correct approach or the required use case.

  I would like to hear if others believe this is a worth while effort? if
others believe it is, I'll be ecstatic to
work with others on this one (adding Redis support isn't as simple as it
sounds). However, before I start
working on something, I'd like to see if others believe this as strongly as
I do.

  On the same note, I'll be in NYC second week of January - so if any of
you are around that area and would
like to combine forces to spear this - would love to do so.


-- 

Kind Regards,

  Nir Simionovich

  GreenfieldTech

  (schedule) http://nirsimionovich.appointy.com/

  (w) http://www.greenfieldtech.net

  (p) +972-73-2557799(MSN): n...@greenfieldtech.net

  (m) +972-54-6982826  (GTALK): nir.simionov...@gmail.com

  (f) +972-73-2557202  (SKYPE): greenfieldtech.nir


--

   Zero Your Inbox  | Cloud
Servers 

--

*Disclaimer:*

This e-mail is intended solely for the person to whom it is addressed and
may contain confidential or legally privileged information. Access to this
e-mail by anyone else is unauthorized. If an addressing or transmission
error has misdirected this e-mail, please notify the author by replying to
this e-mail and destroy this e-mail and any attachments.
E-mail may be susceptible to data corruption, interception, unauthorized
amendment, viruses and delays or the consequences thereof. If you are not
the intended recipient, be advised that you have received this email in
error and that any use, dissemination, forwarding, printing or copying of
this email is strictly prohibited.
-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   http://lists.digium.com/mailman/listinfo/asterisk-dev