from:"Nir Simionovich"

Re: [asterisk-dev] AstriCon 2024: February 15th, 2024 - Fort Lauderdale, Florida

2023-09-14 Thread Nir Simionovich

What you mean is seeing only 80% of me.  :-)


On Wed, Sep 13, 2023 at 1:10 PM Joshua C. Colp  wrote:

> Glad to hear it, and look forward to seeing you there!
>
> On Wed, Sep 13, 2023 at 7:04 AM Nir Simionovich 
> wrote:
>
>> Hi All,
>>
>> After a relatively long hiatus and a very brief visit last year, Eric and
>> I are going to be back at ITExpo in full force.
>> Looking forward to meeting everybody.
>>
>> On Tue, Sep 5, 2023 at 7:37 PM Joshua C. Colp  wrote:
>>
>>> On Tue, Sep 5, 2023 at 12:41 PM Fred Posner  wrote:
>>>
>>>> +1 regarding valentine’s day…
>>>>
>>>> Also, is AstriCon just one day this year?
>>>>
>>>
>>> Yes, AstriCon is a single day this year. We're focusing on a solid base
>>> of a single day schedule. If all goes well then we'll look at expanding it
>>> to more days in the future yet again.
>>>
>>> --
>>> Joshua C. Colp
>>> Asterisk Project Lead
>>> Sangoma Technologies
>>> Check us out at www.sangoma.com and 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
>>
>> --
>> _
>> -- 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
>
>
>
> --
> Joshua C. Colp
> Asterisk Project Lead
> Sangoma Technologies
> Check us out at www.sangoma.com and 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
-- 
_
-- 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] AstriCon 2024: February 15th, 2024 - Fort Lauderdale, Florida

2023-09-13 Thread Nir Simionovich

Hi All,

After a relatively long hiatus and a very brief visit last year, Eric and I
are going to be back at ITExpo in full force.
Looking forward to meeting everybody.

On Tue, Sep 5, 2023 at 7:37 PM Joshua C. Colp  wrote:

> On Tue, Sep 5, 2023 at 12:41 PM Fred Posner  wrote:
>
>> +1 regarding valentine’s day…
>>
>> Also, is AstriCon just one day this year?
>>
>
> Yes, AstriCon is a single day this year. We're focusing on a solid base of
> a single day schedule. If all goes well then we'll look at expanding it to
> more days in the future yet again.
>
> --
> Joshua C. Colp
> Asterisk Project Lead
> Sangoma Technologies
> Check us out at www.sangoma.com and 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
-- 
_
-- 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] Support for amr codec?

2020-08-20 Thread Nir Simionovich

The usage of AMR codecs is mostly in the LTE space - which means that
you're probably aiming to run a slightly higher scale than a single
Asterisk server.
Why not simply install Kamailio+rtpengine as your signalling media
front-end and then relay everything back to Asterisk using a low-footprint
codec, like alaw?

To me, that would sound like the proper solution in this case. Indeed,
there is a minor technical up-hill - but it's worth the effort. Asterisk is
a great codec linguistic,
but when it comes to "pure transcoding" - Kamailio+rtpengine are far more
capable.

On Tue, Aug 18, 2020 at 2:31 PM Carsten Bock  wrote:

> The comfort noise topic was not an issue, until someone got a Samsung S20
> in one of our VoLTE deployments ;-)
> There are different types of comfort noise in AMR/AMR-WB and only newer
> phones use the full scale of comfort noise there is.
>
> Thanks,
> Carsten
> --
> Carsten Bock I CTO & Founder
>
> ng-voice GmbH
>
> Trostbrücke 1 I 20457 Hamburg I Germany
> T +49 40 524 75 93-40 | M +49 179 2021244 I www.ng-voice.com
>
> Registry Office at Local Court Hamburg, HRB 120189
> Managing Directors: Dr. David Bachmann, Carsten Bock
>
>
> Am Di., 18. Aug. 2020 um 11:48 Uhr schrieb Michael Maier <
> m1278...@mailbox.org>:
>
>> On 18.08.20 at 10:49 Carsten Bock wrote:
>> > Hi,
>> >
>> > one of the big issues with AMR/AMR-WB and Asterisk is that usually
>> devices
>> > speaking AMR/AMR-WB do use quite a lot of comfort noise, which is not
>> > supported by Asterisk as far as I know. Even if you use the patch from
>> the
>> > above link, you might end up with some distorted noise.
>>
>> Well, during my tests I in fact noticed some more or less silent
>> distortions which may be caused by comfort noise generated by the mobile(?)
>> (it's only from mobile -> local phone -
>> not vice versa). For me it sounds like a pretty silent steam engine.
>>
>> I tested with amr and amr-wb in conjunction with transcoding (as I'm
>> having no local phone supporting amr. Transcoding was between g722 or
>> g711). Therefore I can't say for sure if
>> this distortion is a result of transcoding or not. I could here it with
>> two different mobiles (iPhone and Huawei). After muting of the iPhone, the
>> distortion mostly went away (no
>> change with the Huawei mobile).
>>
>>
>> Thanks
>> Michael
>>
>> --
>> _
>> -- 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
-- 
_
-- 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] [BOUNTY] ASTERISK-27545

2018-01-10 Thread Nir Simionovich

HI All,

I would like to offer a bounty to fix ASTERISK-27545
<https://issues.asterisk.org/jira/browse/ASTERISK-27545>

I am offering $500 for fixing the above mentioned issue and RFC
in-compliance.
Resolution should be made available as a patch for Asterisk 13, 14 and 15.

Regards,
Nir S


-- 

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 <https://mailstrom.co/referral/ARZJE> | Cloud
Servers <https://www.digitalocean.com/?refcode=97eeea09917a>

--

*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

Re: [asterisk-dev] Suspected chan_sip regression bug, when re-invite occurs from IPv4 to IPv6 (IPv6 is da-shit! giving us the da-shit!)

2018-01-04 Thread Nir Simionovich

Issue reported as ASTERISK-27545.

On Thu, Jan 4, 2018 at 8:36 AM Nir Simionovich <nir.simionov...@gmail.com>
wrote:

> Hi All,
>
>   We've recently encountered an interesting bug with Asterisk 13 (the
> version we are testing with), but I believe
> as this is a fairly crazy (although reasonable) test scenario - the issue
> may still be there.
>
>   The scenario is the following:
>
> UAC A  IPv4 + SIP + RTP > Asterisk --- IPv4 + SIP + RTP ---> UA B
>
>   When the following happens, we all know that this is working correctly,
> no problem there. However, during the
> call, the network condition changes, namely in our case: Transit from UAC
> A to Asterisk changes from IPv4 to
> IPv6, thus the following happens:
>
> UAC A  IPv6 + SIP + RTP > Asterisk --- IPv4 + SIP + RTP ---> UA B
>
>   The SDP response in the 200 OK coming back from Asterisk is malformed,
> and contains IPv4 addresses in the
> SDP, although it shouldn't. For example (pay attention to the bolded
> section):
>
> INVITE sip:4015@[2a03:b0c0:1:d0::176b:1001]:5090 SIP/2.0
> Via: SIP/2.0/UDP
> [2001:470:1f06:404:8562:7dba:63c9:3986]:5090;rport;branch=z9hG4bKPj.gYD2Pm-L3SCeUUj8Ne69O7AjM27TNq1
>
> Max-Forwards: 70
> From: 
> sip:4...@xx.dev.greenfieldtech.net;tag=7lAWRIh6cVthKG-XFN-bCRvGnlBRG6Gq
>
> To: sip:6...@xx.dev.greenfieldtech.net;tag=as4b993656
> Contact: <sip:4015@[2001:470:1f06:404:8562:7dba:63c9:3986]:5090;ob>
> Call-ID: RqxyicrI6s6vrih1XJMU-GvHFeo9x3IE
> CSeq: 18030 INVITE
> Allow: PRACK, INVITE, ACK, BYE, CANCEL, UPDATE, INFO, SUBSCRIBE, NOTIFY,
> REFER, MESSAGE, OPTIONS
> Supported: replaces, 100rel, timer, norefersub
> Session-Expires: 1800;refresher=uas
> Min-SE: 90
> Content-Type: application/sdp
> Content-Length: 584
>
> v=0
> o=- 3723897380 3723897382 IN IP4 100.101.10.126
> s=pjmedia
> b=AS:117
> t=0 0
> a=X-nat:0
> m=audio 4002 RTP/AVP 98 97 99 104 3 0 8 9 120 96
> c=IN IP6 2001:470:1f06:404:8562:7dba:63c9:3986
> b=TIAS:96000
> a=rtcp:4003 IN IP6 2001:470:1f06:404:8562:7dba:63c9:3986
> a=sendrecv
> a=rtpmap:98 speex/16000
> a=rtpmap:97 speex/8000
> a=rtpmap:99 speex/32000
> a=rtpmap:104 iLBC/8000
> a=fmtp:104 mode=30
> a=rtpmap:3 GSM/8000
> a=rtpmap:0 PCMU/8000
> a=rtpmap:8 PCMA/8000
> a=rtpmap:9 G722/8000
> a=rtpmap:120 opus/48000/2
> a=fmtp:120 useinbandfec=1
> a=rtpmap:96 telephone-event/8000
> a=fmtp:96 0-16
>
> INVITE sip:4015@[2a03:b0c0:1:d0::176b:1001]:5090 SIP/2.0
> Via: SIP/2.0/UDP
> [2001:470:1f06:404:8562:7dba:63c9:3986]:5090;rport;branch=z9hG4bKPj.gYD2Pm-L3SCeUUj8Ne69O7AjM27TNq1
>
> Max-Forwards: 70
> From: 
> sip:4...@xx.dev.greenfieldtech.net;tag=7lAWRIh6cVthKG-XFN-bCRvGnlBRG6Gq
>
> To: sip:6...@xx.dev.greenfieldtech.net;tag=as4b993656
> Contact: <sip:4015@[2001:470:1f06:404:8562:7dba:63c9:3986]:5090;ob>
> Call-ID: RqxyicrI6s6vrih1XJMU-GvHFeo9x3IE
> CSeq: 18030 INVITE
> Allow: PRACK, INVITE, ACK, BYE, CANCEL, UPDATE, INFO, SUBSCRIBE, NOTIFY,
> REFER, MESSAGE, OPTIONS
> Supported: replaces, 100rel, timer, norefersub
> Session-Expires: 1800;refresher=uas
> Min-SE: 90
> Content-Type: application/sdp
> Content-Length: 584
>
> v=0
> o=- 3723897380 3723897382 IN IP4 100.101.10.126
> s=pjmedia
> b=AS:117
> t=0 0
> a=X-nat:0
> m=audio 4002 RTP/AVP 98 97 99 104 3 0 8 9 120 96
> c=IN IP6 2001:470:1f06:404:8562:7dba:63c9:3986
> b=TIAS:96000
> a=rtcp:4003 IN IP6 2001:470:1f06:404:8562:7dba:63c9:3986
> a=sendrecv
> a=rtpmap:98 speex/16000
> a=rtpmap:97 speex/8000
> a=rtpmap:99 speex/32000
> a=rtpmap:104 iLBC/8000
> a=fmtp:104 mode=30
> a=rtpmap:3 GSM/8000
> a=rtpmap:0 PCMU/8000
> a=rtpmap:8 PCMA/8000
> a=rtpmap:9 G722/8000
> a=rtpmap:120 opus/48000/2
> a=fmtp:120 useinbandfec=1
> a=rtpmap:96 telephone-event/8000
> a=fmtp:96 0-16
>
> SIP/2.0 100 Trying
> Via: SIP/2.0/UDP
> [2001:470:1f06:404:8562:7dba:63c9:3986]:5090;branch=z9hG4bKPj.gYD2Pm-L3SCeUUj8Ne69O7AjM27TNq1;received=2001:470:1f06:404:8562:7dba:63c9:3986;rport=5090
>
> From: 
> sip:4...@xx.dev.greenfieldtech.net;tag=7lAWRIh6cVthKG-XFN-bCRvGnlBRG6Gq
>
> To: sip:6...@xx.dev.greenfieldtech.net;tag=as4b993656
> Call-ID: RqxyicrI6s6vrih1XJMU-GvHFeo9x3IE
> CSeq: 18030 INVITE
> Server: Asterisk PBX 14.7.0-rc2
> Allow: INVITE, ACK, CANCEL, OPTIONS, BYE, REFER, SUBSCRIBE, NOTIFY, INFO,
> PUBLISH, MESSAGE
> Supported: replaces, timer
> Session-Expires: 1800;refresher=uas
> Contact: <sip:6...@178.yyy.zzz.231:5090>
> Content-Length: 0
>
>
>
> *SIP/2.0 200 OK Via: SIP/2.0/UDP
> [2001:470:1f06:404:8562:7dba:63c9:3986]:5090;branch=z9hG4bKPj.gYD2Pm-L3SCeUUj8Ne69O7AjM27TNq1;received=2001:470:1f06:404:8562:7d

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 <a...@zerohalo.com> 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 <g...@cfware.com> 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 <cres...@digium.com> wrote:
>>
>>> On Fri, Dec 22, 2017 at 10:23 AM, Ivan Poddubny <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 <cres...@digium.com>
>>>> 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 <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 .
>>>>>>&

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 <cres...@digium.com> wrote:

> On Fri, Dec 22, 2017 at 10:23 AM, Ivan Poddubny <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 <cres...@digium.com>
>> 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 <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 <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://nirs

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 <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 <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://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 <https://mailstrom.co/referral/ARZJE> | Cloud
> Servers <https://www.digitalocean.com/?refcode=97eeea09917a>
> --
>
> *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 <https://mailstrom.co/referral/ARZJE> | Cloud
Servers <https://www.digitalocean.com/?refcode=97eeea09917a>

--

*Disclaimer:*

This e-mail is intended solely for the person to whom it is addressed and
may contain confidenti

[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 <https://mailstrom.co/referral/ARZJE> | Cloud
Servers <https://www.digitalocean.com/?refcode=97eeea09917a>

--

*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

Re: [asterisk-dev] Can someone please review something

2017-11-28 Thread Nir Simionovich

well, that was exactly my feeling.

On Mon, Nov 27, 2017 at 3:10 PM Joshua Colp <jc...@digium.com> wrote:

> On Mon, Nov 27, 2017, at 08:55 AM, Nir Simionovich wrote:
> > @corey,
> >
> >   I've been looking into res_sorcery_astdb, but I think I'm missing
> > something in here.
> > If I would create a a redis backend for sorcery, the functionality is
> > fairly limited in the scope
> > of Redis usage. Mainly due to the fact that sorcery is meant as a CRUD
> > interface.
> >
> >   Have I got it correct?
>
> It ultimately depends on the use case and what exactly is trying to be
> achieved. As with any general interface (like sorcery) the result is
> that you are somewhat limited to what the interface provides, but the
> benefit being it can be used by anything that uses the interface. Is it
> worth it? Could be as Corey mentioned.
>
> If your goal, however, is to provide all the knobs and possibilities
> that redis can do - then it obviously wouldn't be a good fit.
>
> --
> Joshua Colp
> Digium, Inc. | Senior 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
>
-- 

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 <https://mailstrom.co/referral/ARZJE> | Cloud
Servers <https://www.digitalocean.com/?refcode=97eeea09917a>

--

*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

Re: [asterisk-dev] Can someone please review something

2017-11-27 Thread Nir Simionovich

@corey,

  I've been looking into res_sorcery_astdb, but I think I'm missing
something in here.
If I would create a a redis backend for sorcery, the functionality is
fairly limited in the scope
of Redis usage. Mainly due to the fact that sorcery is meant as a CRUD
interface.

  Have I got it correct?



On Thu, Nov 23, 2017 at 2:03 AM Nir Simionovich <nir.simionov...@gmail.com>
wrote:

> Actually, I was more thinking about Redis as a PubSub mechanism, not as a
> static storage backend.
>
> Here is my take on things, developers need tools. Some developers prefer
> Redis, other may prefer beanstalk,
> and other may prefer log files. Each one has its merits and its issues,
> but the overall ability to choose is important.
> I believe that adding modern backends improves our appeal to "modern
> developers" who are accustomed to these
> tools.
>
>
>
> On Thu, Nov 23, 2017 at 1:52 AM Corey Farrell <g...@cfware.com> wrote:
>
>> From your configure.ac:
>> > AST_EXT_LIB_CHECK([REDIS], [redis], [redisReaderCreate],
>> [hiredis/hiredis.h])
>>
>> This tries linking with '-lredis', but it needs to use '-lhiredis':
>>
>> AST_EXT_LIB_CHECK([REDIS], [hiredis], [redisReaderCreate],
>> [hiredis/hiredis.h])
>>
>> In addition instead of using variable prefix "REDIS" (the first argument)
>> I suggest switching to "HIREDIS" (don't forget makeopts.in and
>> build_tools/menuselect-deps.in).  There are multiple C redis libraries
>> so you want the variable name to identify which one you are using.  This
>> will also make it match "hiredis" in cdr_redis.c so
>> menuselect will enable the module.
>>
>> Since redis is in-memory I'm not really sure about using it for CDR?  I
>> could see res_sorcery_redis being useful assuming it could be used as an
>> alternative to res_sorcery_astdb or res_sorcery_memory.
>>
>> On 11/22/2017 06:01 PM, Nir Simionovich wrote:
>>
>> Hi All,
>>
>>   I've started a new branch at team/nirs/cdr-redis-support
>>
>>   I'm having some issues integrating the hiredis library into the
>> automake. It seems to be configured correctly,
>> however, for some odd reason it will not become available in the
>> 'menuselect' tool.
>>
>>   Would highly appreciate it if someone can take a look for a minute and
>> see if I missed anything major in there.
>>
>>
>> --
>>
>> Kind Regards,
>>
>>   Nir Simionovich
>>
>>   GreenfieldTech
>>
>>   (schedule) http://nirsimionovich.appointy.com/
>>
>>   (w) http://www.greenfieldtech.net
>>
>>   (p) +972-73-2557799 <073-255-7799>(MSN):
>> n...@greenfieldtech.net
>>
>>   (m) +972-54-6982826 <054-698-2826>  (GTALK):
>> nir.simionov...@gmail.com
>>
>>   (f) +972-73-2557202 <073-255-7202>  (SKYPE): greenfieldtech.nir
>>
>>
>> --
>>
>>Zero Your Inbox <https://mailstrom.co/referral/ARZJE> | Cloud
>> Servers <https://www.digitalocean.com/?refcode=97eeea09917a>
>>
>> --
>>
>>
>> *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.
>>
>>
>>
>> --
>
> Kind Regards,
>
>   Nir Simionovich
>
>   GreenfieldTech
>
>   (schedule) http://nirsimionovich.appointy.com/
>
>   (w) http://www.greenfieldtech.net
>
>   (p) +972-73-2557799 <073-255-7799>(MSN): n...@greenfieldtech.net
>
>   (m) +972-54-6982826 <054-698-2826>  (GTALK):
> nir.simionov...@gmail.com
>
>   (f) +972-73-2557202 <073-255-7202>  (SKYPE): greenfieldtech.nir
>
>
> --
>
>Zero Your Inbox <https://mailstrom.co/referral/ARZJE> | Cloud
> Servers <https://www.d

Re: [asterisk-dev] Can someone please review something

2017-11-22 Thread Nir Simionovich

Actually, I was more thinking about Redis as a PubSub mechanism, not as a
static storage backend.

Here is my take on things, developers need tools. Some developers prefer
Redis, other may prefer beanstalk,
and other may prefer log files. Each one has its merits and its issues, but
the overall ability to choose is important.
I believe that adding modern backends improves our appeal to "modern
developers" who are accustomed to these
tools.



On Thu, Nov 23, 2017 at 1:52 AM Corey Farrell <g...@cfware.com> wrote:

> From your configure.ac:
> > AST_EXT_LIB_CHECK([REDIS], [redis], [redisReaderCreate],
> [hiredis/hiredis.h])
>
> This tries linking with '-lredis', but it needs to use '-lhiredis':
>
> AST_EXT_LIB_CHECK([REDIS], [hiredis], [redisReaderCreate],
> [hiredis/hiredis.h])
>
> In addition instead of using variable prefix "REDIS" (the first argument)
> I suggest switching to "HIREDIS" (don't forget makeopts.in and
> build_tools/menuselect-deps.in).  There are multiple C redis libraries so
> you want the variable name to identify which one you are using.  This will
> also make it match "hiredis" in cdr_redis.c so menuselect
> will enable the module.
>
> Since redis is in-memory I'm not really sure about using it for CDR?  I
> could see res_sorcery_redis being useful assuming it could be used as an
> alternative to res_sorcery_astdb or res_sorcery_memory.
>
> On 11/22/2017 06:01 PM, Nir Simionovich wrote:
>
> Hi All,
>
>   I've started a new branch at team/nirs/cdr-redis-support
>
>   I'm having some issues integrating the hiredis library into the
> automake. It seems to be configured correctly,
> however, for some odd reason it will not become available in the
> 'menuselect' tool.
>
>   Would highly appreciate it if someone can take a look for a minute and
> see if I missed anything major in there.
>
>
> --
>
> Kind Regards,
>
>   Nir Simionovich
>
>   GreenfieldTech
>
>   (schedule) http://nirsimionovich.appointy.com/
>
>   (w) http://www.greenfieldtech.net
>
>   (p) +972-73-2557799 <073-255-7799>(MSN): n...@greenfieldtech.net
>
>   (m) +972-54-6982826 <054-698-2826>  (GTALK):
> nir.simionov...@gmail.com
>
>   (f) +972-73-2557202 <073-255-7202>  (SKYPE): greenfieldtech.nir
>
>
> --
>
>Zero Your Inbox <https://mailstrom.co/referral/ARZJE> | Cloud
> Servers <https://www.digitalocean.com/?refcode=97eeea09917a>
>
> --
>
>
> *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.
>
>
>
> --

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 <https://mailstrom.co/referral/ARZJE> | Cloud
Servers <https://www.digitalocean.com/?refcode=97eeea09917a>

--

*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

Re: [asterisk-dev] Can someone please review something

2017-11-22 Thread Nir Simionovich

it's on gerrit - it's inside asterisk-team



On Thu, Nov 23, 2017 at 1:11 AM Corey Farrell <g...@cfware.com> wrote:

> Where did you push this branch?  I'm not seeing it on gerrit or github.
>
> On 11/22/2017 06:01 PM, Nir Simionovich wrote:
>
> Hi All,
>
>   I've started a new branch at team/nirs/cdr-redis-support
>
>   I'm having some issues integrating the hiredis library into the
> automake. It seems to be configured correctly,
> however, for some odd reason it will not become available in the
> 'menuselect' tool.
>
>   Would highly appreciate it if someone can take a look for a minute and
> see if I missed anything major in there.
>
>
> --
>
> Kind Regards,
>
>   Nir Simionovich
>
>   GreenfieldTech
>
>   (schedule) http://nirsimionovich.appointy.com/
>
>   (w) http://www.greenfieldtech.net
>
>   (p) +972-73-2557799 <073-255-7799>(MSN): n...@greenfieldtech.net
>
>   (m) +972-54-6982826 <054-698-2826>  (GTALK):
> nir.simionov...@gmail.com
>
>   (f) +972-73-2557202 <073-255-7202>  (SKYPE): greenfieldtech.nir
>
>
> --
>
>Zero Your Inbox <https://mailstrom.co/referral/ARZJE> | Cloud
> Servers <https://www.digitalocean.com/?refcode=97eeea09917a>
>
> --
>
>
> *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

-- 

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 <https://mailstrom.co/referral/ARZJE> | Cloud
Servers <https://www.digitalocean.com/?refcode=97eeea09917a>

--

*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

[asterisk-dev] Can someone please review something

2017-11-22 Thread Nir Simionovich

Hi All,

  I've started a new branch at team/nirs/cdr-redis-support

  I'm having some issues integrating the hiredis library into the automake.
It seems to be configured correctly,
however, for some odd reason it will not become available in the
'menuselect' tool.

  Would highly appreciate it if someone can take a look for a minute and
see if I missed anything major in there.


-- 

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 <https://mailstrom.co/referral/ARZJE> | Cloud
Servers <https://www.digitalocean.com/?refcode=97eeea09917a>

--

*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

[asterisk-dev] Processing .conf files

2017-11-19 Thread Nir Simionovich

Hi All,

  Ok, this email may be totally pointless to some, but I'm having some
conceptual difficulties with the methodology of processing .conf files.

  Allow me to explain my current issues in ramping up on this one. As part
of the
beanstalk work I've done, I would like to create either an app_beanstalk or
func_beanstalk or to be better, a res_beanstalk.

  In my mind, I see a configuration file works something like the following:

;
; Beanstalk job queue resourcing application
;

[general]
ttr = 60; an integer number of seconds to allow a worker to run
a job
delay = 0   ; an integer number of seconds to wait before marking a
job as ready.
; A job will be set as "delayed" in this period of time


[tube1]
enabled = no
;host = 127.0.0.1; Specify the remote IP address of the Beanstalkd
server
;port = 11300; Specify the remote PORT of the the Beanstalkd server
;tube = asterisk-cdr ; Specify the default job queue to use
;priority = 99   ; Specify the default job priority for the queue. The
lower the number,
 ; the higher the priority.


[tube2]
enabled = no
;host = 127.0.0.1; Specify the remote IP address of the Beanstalkd
server
;port = 11300; Specify the remote PORT of the the Beanstalkd server
;tube = asterisk-cdr ; Specify the default job queue to
;priority = 99   ; Specify the default job priority for the queue. The
lower the number,
 ; the higher the priority.

  Now, I've trying to figure out how the configuration parser works with
"free form" data. I've tried looking
into app_voicemail.c, as that uses a fairly similar concept, however, that
didn't provide much help.

  From what I gathered, there are two main functions that I need to
understand how they work:
ast_category_browse and ast_variable_browse. Now, the basic methodology of
the various Asterisk
config files is fairly static, namely, a configuration for a singular
function - very much like cdr_beanstalkd.conf.
However, for my new tool to work, I need to be able to create dynamically
allocated "tube contexts". I couldn't find
any specific sample that would describe this kind of methodology of
operation in a coherent manner.

  Another option I was thinking of doing is going with the following route:

;
; Beanstalk job queue resourcing application
;

[general]
ttr = 60; an integer number of seconds to allow a worker to run
a job
delay = 0   ; an integer number of seconds to wait before marking a
job as ready.
; A job will be set as "delayed" in this period of time

tube => tube1,beanstalk://127.0.0.1:11300/asterisk-tube1,99
tube => tube2,beanstalk://127.0.0.1:11300/asterisk-tube2,99

  In general, this seems like a simpler configuration parsing mechanism,
but, it doesn't really comply with
how the rest of the Asterisk configuration is built, and thus, seems fairly
alien to the configuration construct.

  Any assistance would be appreciated.

P.S.
  Already looked into app_skel, didn't really provide me the information I
was looking for.




-- 

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 <https://mailstrom.co/referral/ARZJE> | Cloud
Servers <https://www.digitalocean.com/?refcode=97eeea09917a>

--

*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

Re: [asterisk-dev] RPM Repository for Asterisk/Kamailio

2017-11-19 Thread Nir Simionovich

Hi Olle,

  Well, as I'm maintaining these packages mainly for our own deployments, I
don't mind making them
available for the community - actually, we'll be happy to.

  Currently, the packages I have are for 4.4.6, and I'll see if I can
create the same for kamailio 5.1.X.

  From a naming convention point of view, would you believe building two
packages named kamailio4 and
kamailio5 be beneficial?



On Sun, Nov 19, 2017 at 12:56 PM Olle E. Johansson <o...@edvina.net> wrote:

>
> On 16 Nov 2017, at 22:18, Nir Simionovich <nir.simionov...@gmail.com>
> wrote:
>
> and that the RPM repo for Kamailio is - how shall we put it, not providing
> all the possible modules.
>
> You are very welcome to contribute updates directly to the Kamailio
> project. We’ve been looking
> for maintainers of the RPM specs for a long time - I am happy to see that
> you are interested.
>
> We have active maintainers of the Debian specs, so working in tandem
> should not be hard.
>
> Cheers,
> /O
> --
> _
> -- 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 <https://mailstrom.co/referral/ARZJE> | Cloud
Servers <https://www.digitalocean.com/?refcode=97eeea09917a>

--

*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

Re: [asterisk-dev] RPM Repository for Asterisk/Kamailio

2017-11-17 Thread Nir Simionovich

https://gitlab.com/osvoipdoc-project

On Sat, Nov 18, 2017 at 6:45 AM Nasir Iqbal <na...@ictinnovations.com>
wrote:

> Hi Nir,
>
> Pardon my ignorance!
>
> Can you please share the link to "Open Source documentation project" i.e
> where I can find that spec file.
>
> Thanks
>
> Nasir Iqbal
>
> ICTBroadcast - an Auto Dialer software for ITSP
> <https://www.ictbroadcast.com/how-become-internet-telephony-service-provider-itsp-using-ictbroadcast-sp-edition>
> SMS, Fax and Voice broadcasting & Inbound / Outbound Campaigns
> http://www.ictbroadcast.com/
>
> On Fri, Nov 17, 2017 at 9:06 PM, Nir Simionovich <
> nir.simionov...@gmail.com> wrote:
>
>> Hi Guys,
>>
>>   I've uploaded the SPEC file to the Open Source documentation project
>> repo, under asterisk/useful-scripts/RPM_spec_files.
>> I'm confident that Jared can add some new stuff in there, as I mostly
>> disabled Dahdi and shit like that.
>>
>>   Another thing, to make this work, you will need traud's Asterisk Opus
>> repo, for Asterisk 13.7 as a tar.gz file. I'm confident
>> you'll be able to understand it from the code. I think the best would be
>> for me to upload the SRPM in there as well, so people
>> can use that as well at ease.
>>
>>
>>
>> On Fri, Nov 17, 2017 at 5:43 PM Nir Simionovich <
>> nir.simionov...@gmail.com> wrote:
>>
>>> oh, the repos also have an SRPM repo in there, so you can also install
>>> from there as well to see the SPEC file.
>>>
>>> At least, before I go ahead and start the public repo. Maybe I should
>>> add it to the "Documentation project" repo?
>>>
>>>
>>> On Fri, Nov 17, 2017 at 5:41 PM Nir Simionovich <
>>> nir.simionov...@gmail.com> wrote:
>>>
>>>> No problem guys - I'll create respective repos on github later today.
>>>>
>>>> On Fri, Nov 17, 2017 at 4:40 PM Jared Smith <jaredsm...@jaredsmith.net>
>>>> wrote:
>>>>
>>>>> On Thu, Nov 16, 2017 at 4:18 PM, Nir Simionovich <
>>>>> nir.simionov...@gmail.com> wrote:
>>>>>
>>>>>>   As part of our work, we've noticed that Asterisk doesn't have an
>>>>>> updated RPM repo, and that the RPM repo for Kamailio is - how shall we 
>>>>>> put
>>>>>> it, not providing all the possible modules.
>>>>>>
>>>>>
>>>>> As one of the maintainers of the Asterisk and dahdi-tools packages in
>>>>> Fedora and EPEL and a long time RPM packaging fanatic, I'd really like to
>>>>> collaborate together on the spec files you're using.
>>>>>
>>>>> --
>>>>> Jared Smith
>>>>> --
>>>>> _
>>>>> -- 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 <073-255-7799>(MSN):
>>>> n...@greenfieldtech.net
>>>>
>>>>   (m) +972-54-6982826 <054-698-2826>  (GTALK):
>>>> nir.simionov...@gmail.com
>>>>
>>>>   (f) +972-73-2557202 <073-255-7202>  (SKYPE): greenfieldtech.nir
>>>>
>>>>
>>>> --
>>>>
>>>>Zero Your Inbox <https://mailstrom.co/referral/ARZJE> | 
>>>> Cloud
>>>> Servers <https://www.digitalocean.com/?refcode=97eeea09917a>
>>>>
>>>> --
>>>>
>>>> *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

Re: [asterisk-dev] RPM Repository for Asterisk/Kamailio

2017-11-17 Thread Nir Simionovich

Hi Guys,

  I've uploaded the SPEC file to the Open Source documentation project
repo, under asterisk/useful-scripts/RPM_spec_files.
I'm confident that Jared can add some new stuff in there, as I mostly
disabled Dahdi and shit like that.

  Another thing, to make this work, you will need traud's Asterisk Opus
repo, for Asterisk 13.7 as a tar.gz file. I'm confident
you'll be able to understand it from the code. I think the best would be
for me to upload the SRPM in there as well, so people
can use that as well at ease.



On Fri, Nov 17, 2017 at 5:43 PM Nir Simionovich <nir.simionov...@gmail.com>
wrote:

> oh, the repos also have an SRPM repo in there, so you can also install
> from there as well to see the SPEC file.
>
> At least, before I go ahead and start the public repo. Maybe I should add
> it to the "Documentation project" repo?
>
>
> On Fri, Nov 17, 2017 at 5:41 PM Nir Simionovich <nir.simionov...@gmail.com>
> wrote:
>
>> No problem guys - I'll create respective repos on github later today.
>>
>> On Fri, Nov 17, 2017 at 4:40 PM Jared Smith <jaredsm...@jaredsmith.net>
>> wrote:
>>
>>> On Thu, Nov 16, 2017 at 4:18 PM, Nir Simionovich <
>>> nir.simionov...@gmail.com> wrote:
>>>
>>>>   As part of our work, we've noticed that Asterisk doesn't have an
>>>> updated RPM repo, and that the RPM repo for Kamailio is - how shall we put
>>>> it, not providing all the possible modules.
>>>>
>>>
>>> As one of the maintainers of the Asterisk and dahdi-tools packages in
>>> Fedora and EPEL and a long time RPM packaging fanatic, I'd really like to
>>> collaborate together on the spec files you're using.
>>>
>>> --
>>> Jared Smith
>>> --
>>> _
>>> -- 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 <073-255-7799>(MSN):
>> n...@greenfieldtech.net
>>
>>   (m) +972-54-6982826 <054-698-2826>  (GTALK):
>> nir.simionov...@gmail.com
>>
>>   (f) +972-73-2557202 <073-255-7202>  (SKYPE): greenfieldtech.nir
>>
>>
>> --
>>
>>Zero Your Inbox <https://mailstrom.co/referral/ARZJE> | Cloud
>> Servers <https://www.digitalocean.com/?refcode=97eeea09917a>
>>
>> --
>>
>> *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.
>>
> --
>
> Kind Regards,
>
>   Nir Simionovich
>
>   GreenfieldTech
>
>   (schedule) http://nirsimionovich.appointy.com/
>
>   (w) http://www.greenfieldtech.net
>
>   (p) +972-73-2557799 <073-255-7799>(MSN): n...@greenfieldtech.net
>
>   (m) +972-54-6982826 <054-698-2826>  (GTALK):
> nir.simionov...@gmail.com
>
>   (f) +972-73-2557202 <073-255-7202>  (SKYPE): greenfieldtech.nir
>
>
> --
>
>Zero Your Inbox <https://mailstrom.co/referral/ARZJE> | Cloud
> Servers <https://www.digitalocean.com/?refcode=97eeea09917a>
>
> --
>
> *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

Re: [asterisk-dev] RPM Repository for Asterisk/Kamailio

2017-11-17 Thread Nir Simionovich

oh, the repos also have an SRPM repo in there, so you can also install from
there as well to see the SPEC file.

At least, before I go ahead and start the public repo. Maybe I should add
it to the "Documentation project" repo?


On Fri, Nov 17, 2017 at 5:41 PM Nir Simionovich <nir.simionov...@gmail.com>
wrote:

> No problem guys - I'll create respective repos on github later today.
>
> On Fri, Nov 17, 2017 at 4:40 PM Jared Smith <jaredsm...@jaredsmith.net>
> wrote:
>
>> On Thu, Nov 16, 2017 at 4:18 PM, Nir Simionovich <
>> nir.simionov...@gmail.com> wrote:
>>
>>>   As part of our work, we've noticed that Asterisk doesn't have an
>>> updated RPM repo, and that the RPM repo for Kamailio is - how shall we put
>>> it, not providing all the possible modules.
>>>
>>
>> As one of the maintainers of the Asterisk and dahdi-tools packages in
>> Fedora and EPEL and a long time RPM packaging fanatic, I'd really like to
>> collaborate together on the spec files you're using.
>>
>> --
>> Jared Smith
>> --
>> _
>> -- 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 <073-255-7799>(MSN): n...@greenfieldtech.net
>
>   (m) +972-54-6982826 <054-698-2826>  (GTALK):
> nir.simionov...@gmail.com
>
>   (f) +972-73-2557202 <073-255-7202>  (SKYPE): greenfieldtech.nir
>
>
> --
>
>Zero Your Inbox <https://mailstrom.co/referral/ARZJE> | Cloud
> Servers <https://www.digitalocean.com/?refcode=97eeea09917a>
>
> --
>
> *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.
>
-- 

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 <https://mailstrom.co/referral/ARZJE> | Cloud
Servers <https://www.digitalocean.com/?refcode=97eeea09917a>

--

*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

Re: [asterisk-dev] RPM Repository for Asterisk/Kamailio

2017-11-17 Thread Nir Simionovich

No problem guys - I'll create respective repos on github later today.

On Fri, Nov 17, 2017 at 4:40 PM Jared Smith <jaredsm...@jaredsmith.net>
wrote:

> On Thu, Nov 16, 2017 at 4:18 PM, Nir Simionovich <
> nir.simionov...@gmail.com> wrote:
>
>>   As part of our work, we've noticed that Asterisk doesn't have an
>> updated RPM repo, and that the RPM repo for Kamailio is - how shall we put
>> it, not providing all the possible modules.
>>
>
> As one of the maintainers of the Asterisk and dahdi-tools packages in
> Fedora and EPEL and a long time RPM packaging fanatic, I'd really like to
> collaborate together on the spec files you're using.
>
> --
> Jared Smith
> --
> _
> -- 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 <https://mailstrom.co/referral/ARZJE> | Cloud
Servers <https://www.digitalocean.com/?refcode=97eeea09917a>

--

*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

[asterisk-dev] RPM Repository for Asterisk/Kamailio

2017-11-16 Thread Nir Simionovich

Hi All,

  As part of our work, we've noticed that Asterisk doesn't have an updated
RPM repo, and that the RPM repo for Kamailio is - how shall we put it, not
providing all the possible modules.

  As part of our commitment, we've created a simple repository that we are
maintaining, which includes both. Please note that the Asterisk RPM
includes the patches for the Open Source Opus codec.

  You may add the following to your repos, to make your life easier:

[cloudonix_opensource_noarch]
gpgcheck = 0
enabled = 1
baseurl = https://cloudonix-dist.s3.amazonaws.com/repository/noarch/

[cloudonix_opensource_x86_64]
gpgcheck = 0
enabled = 1
baseurl = https://cloudonix-dist.s3.amazonaws.com/repository/$basearch/

  The version of Asterisk in there is Asterisk 14.7.2 and Kamailio 4.4.6 -
which is currently our production environment. I will start working on the
Asterisk 15 and Kamailio 5.X packaging in the near future - once I get
around to finalizing my current work path.

  Would appreciate some feedback and ideas.


-- 

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 <https://mailstrom.co/referral/ARZJE> | Cloud
Servers <https://www.digitalocean.com/?refcode=97eeea09917a>

--

*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

Re: [asterisk-dev] Open Invitation - Open Source VoIP Documentation Project

2017-11-07 Thread Nir Simionovich

Well,

As long as the wiki entry indicates the original source and retains the
CC license, I have no
problem with "Cross publication".



On Tue, Nov 7, 2017 at 12:59 AM Matt Fredrickson <cres...@digium.com> wrote:

> On Sat, Nov 4, 2017 at 2:53 PM, Nir Simionovich <nir.simionov...@gmail.com
> > wrote:
>
>> Hi All,
>>
>>   Following Astricon 2017, and my own personal interest in providing the
>> community with more detailed documentation sources and specifically - best
>> of practice and how-to documents, I've opened a public gitlab project,
>> specifically for this object.
>>
>>   The project is located at https://gitlab.com/osvoipdoc-project - and
>> people are welcome to ask for access to contribute documentation. I've
>> already started working on the first how-to, which is an Asterisk+Opus
>> installation guide. It's geared toward installing Asterisk on cloud
>> instances, with Alexander Traud's Opus patches - which work really well.
>>
>>   The project is split into several sub-projects, mainly - asterisk,
>> kamailio and cloudformation. Cloudformation is something I've received an
>> interest from AWS, in regards to providing the community with a solid set
>> of cloudformation and cloud-init templates to use for deploying Asterisk,
>> Kamailio and other open source VoIP tools into Amazon AWS.
>>
>>   Currently, the project includes both myself and Lenz Emitrely, who
>> showed a keen interest in assisting with this project. Others had showed
>> similar interest during Astricon, so please logon to gitlab and join the
>> project.
>>
>>   For the time being, I will serve as both writer and curator - till
>> other people step in and provide additional assistance.
>>
>> Regards,
>>   Nir Simionovich
>>
>
> Hey Nir,
>
> First off, thanks for taking on the great challenge of documenting the
> cross project open source telephony world :-) (that was a mouthful to say).
>
> I noticed one or two documents that might be interesting to have included
> in some kind of Asterisk documentation, like your  "How to add a library to
> the build process" - that might be some kind of Asterisk source code
> included document, as well as your document on "Dial plan best practices" -
> that might fit on the wiki.  What does everybody else think?
>
> Just a few thoughts, but so far, it looks like a good start!
>
> --
> Matthew Fredrickson
> Digium, Inc. | Engineering Manager
> 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
> --
> _________
> -- 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 <https://mailstrom.co/referral/ARZJE> | Cloud
Servers <https://www.digitalocean.com/?refcode=97eeea09917a>

--

*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

[asterisk-dev] Open Invitation - Open Source VoIP Documentation Project

2017-11-04 Thread Nir Simionovich

Hi All,

  Following Astricon 2017, and my own personal interest in providing the
community with more detailed documentation sources and specifically - best
of practice and how-to documents, I've opened a public gitlab project,
specifically for this object.

  The project is located at https://gitlab.com/osvoipdoc-project - and
people are welcome to ask for access to contribute documentation. I've
already started working on the first how-to, which is an Asterisk+Opus
installation guide. It's geared toward installing Asterisk on cloud
instances, with Alexander Traud's Opus patches - which work really well.

  The project is split into several sub-projects, mainly - asterisk,
kamailio and cloudformation. Cloudformation is something I've received an
interest from AWS, in regards to providing the community with a solid set
of cloudformation and cloud-init templates to use for deploying Asterisk,
Kamailio and other open source VoIP tools into Amazon AWS.

  Currently, the project includes both myself and Lenz Emitrely, who showed
a keen interest in assisting with this project. Others had showed similar
interest during Astricon, so please logon to gitlab and join the project.

  For the time being, I will serve as both writer and curator - till other
people step in and provide additional assistance.

Regards,
  Nir Simionovich


-- 

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 <https://mailstrom.co/referral/ARZJE> | Cloud
Servers <https://www.digitalocean.com/?refcode=97eeea09917a>

--

*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

Re: [asterisk-dev] autoconf version requirement increase

2017-11-01 Thread Nir Simionovich

Hi Corey,

  Our production environment is based on CentOS 6.9 and we're slowly
migrating to 7.X
I would be happy to check out your patches inside our testing facility.


On Tue, Oct 31, 2017 at 10:52 PM Corey Farrell <g...@cfware.com> wrote:

> Hello all,
>
> autoconf is required to run ./bootstrap.sh after changing configure.ac
> or *.m4 in any folder of the Asterisk source tree (including menuselect
> and third-party folders).  Currently we require 2.60, I'm working on a
> patch that will require 2.64.  Note autoconf is not required to run
> './configure', it is only needed to run ./bootstrap.sh.
>
> Does anyone work on these files from a distribution which cannot install
> autoconf-2.69?  Although the changes I'm working on only require
> autoconf 2.64 I see no reason to hold back at this point. Version 2.69
> is from 2012 and is the latest version.  As far as I know CentOS 6 is
> the only major currently supported distribution which has autoconf <
> 2.64, all others provide 2.69.  Requiring 2.69 would be one less thing
> to worry about when working on configure scripts, especially since I
> don't have access to test any lower version.
>
> -Corey
>
>
> --
> _
> -- 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 <https://mailstrom.co/referral/ARZJE> | Cloud
Servers <https://www.digitalocean.com/?refcode=97eeea09917a>

--

*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

Re: [asterisk-dev] AstDB mySQL implementation

2017-10-31 Thread Nir Simionovich

Yes, that's not a bad start - but I believe that are dozens other functions
that should be used - instead of other functions.
For example, I remember that a while back atoi and itoa were said to be
unsafe and that there is a better "asteriskian" way
of using those.

For example, the Wiki says:

2.15. String conversions

When converting from strings to integers or floats, use the sscanf function
in preference to the atoi and atof family of functions, as sscanf detects
errors. Always check the return value of sscanf to verify that your numeric
variables successfully scanned before using them. Also, to avoid a
potential libc bug, always specify a maximum width for each conversion
specifier, including integers and floats. A good length for both integers
and floats is 30, as this is more than generous, even if you're using
doubles or long integers.

However, without a proper "best practice" example in the Wiki, people will
do as they see fit, which in turn will
turn into a "review board" ping-pong, which can be avoided by a simple
sample in there.

On Mon, Oct 30, 2017 at 9:22 PM Kevin Harwell <kharw...@digium.com> wrote:

> On Mon, Oct 30, 2017 at 1:19 PM, Nir Simionovich <
> nir.simionov...@gmail.com> wrote:
>
>> Definite +1 on the Documentation side - for sure. Here is a stupid
>> question, is there a "Best Practices" coding document somewhere?
>> I remember that many years ago there was something really basic, but much
>> has changed since then.
>>
>
> Are you referring to the coding guidelines? If so those can be found on
> the wiki[1].
>
> [1] https://wiki.asterisk.org/wiki/display/AST/Coding+Guidelines
>
> --
>
> Kevin Harwell
> Digium, Inc. | Software Developer
> 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
> Check us out at: http://digium.com & http://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

-- 

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 <https://mailstrom.co/referral/ARZJE> | Cloud
Servers <https://www.digitalocean.com/?refcode=97eeea09917a>

--

*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

Re: [asterisk-dev] AstDB mySQL implementation

2017-10-30 Thread Nir Simionovich

Definite +1 on the Documentation side - for sure. Here is a stupid
question, is there a "Best Practices" coding document somewhere?
I remember that many years ago there was something really basic, but much
has changed since then.

On Mon, Oct 30, 2017 at 6:53 PM Corey Farrell <g...@cfware.com> wrote:

> I think astdb itself is an inappropriate place to deal with this.  astdb
> is initialized well before module preloads so it would be nearly impossible
> for modules to provide the astdb implementation.  In my opinion astdb is a
> database "implementation", not a connector (and that shouldn't change).
> For higher level connectors with configurable backends we have realtime and
> sorcery.  If someone were to write a redis or memcached connector for
> Asterisk I would expect it to be a realtime or sorcery driver.  If
> func_sorcery can be expanded to perform writes/deletes maybe it could be
> used in place of func_db?  I suspect that dialplan use of astdb is a bigger
> problem than the ways that Asterisk uses astdb directly on it's own.
>
> Documentation: Maybe we need to add a warning to xmldoc for the astdb
> app/func/AMI/AGI that all astdb operations are serialized (dblock global
> mutex) and thus performance could suffer if used too much from too many
> threads?  Do we have any guides/sample files showing how to replace astdb
> operations with alternatives (func_odbc for example)?
>
> On 10/29/2017 10:17 AM, Nir Simionovich wrote:
>
> Seems like I have under estimated the task at hand, as this part of
> Asterisk requires some
> more intricate familiarity with how AstDB truly works. It would be one
> thing to "change the backend"
> it would a far more complex task to "make two backends selectable".
>
> Conclusion - not sure this is worth the effort at this point in time,
> maybe in a later stage. :-(
>
>
>
> On Thu, Oct 26, 2017 at 6:01 PM Nir Simionovich <nir.simionov...@gmail.com>
> wrote:
>
>> Correction, seems like this requires a bit more architecture than I
>> anticipated.
>>
>> Basically, we need to separate this into several files and turn the
>> entire AstDB concept
>> into a pluggable module type module.
>>
>> But, as AstDB is a mandatory module for Asterisk, can we create a
>> situation where
>> a pluggable module is a mandatory requirement for Asterisk to launch
>> correctly?
>>
>> Is there anything like that in Asterisk? can someone point me in some
>> proper example
>> or preferably, something that I can look at and learn from?
>>
>>
>>
>> On Thu, Oct 26, 2017 at 4:47 PM Nir Simionovich <
>> nir.simionov...@gmail.com> wrote:
>>
>>> I'll have a look at it.
>>>
>>> If I read the code correctly, the AstDB is invoked from the asterisk.c
>>> file, when asterisk is launched.
>>> I think the best would be to add a configuration file like astdb.conf,
>>> which will look something like this:
>>>
>>> [general]
>>> engine=builtin ; values can be either builtin, redis or memcache (or
>>> others in the future)
>>>
>>> ;[redis]
>>> ;server = 127.0.0.1
>>> ;port = 6379
>>> ;database = 15 ; By default AstDB will use Redis database number 15
>>>
>>> ;[memcache]
>>> ;server = 127.0.0.1
>>> ;port = 11211
>>> ;prefix = asterisk
>>>
>>> Then, inside the db.c file add the proper statements and backend to
>>> support each of these. I'm confident
>>> that from a design perspective, this is not optimal, but it would serve
>>> as a nice PoC to indicate if the task
>>> is feasible or not.
>>>
>>> For example, the following:
>>>
>>> DEFINE_SQL_STATEMENT(put_stmt, "INSERT OR REPLACE INTO astdb (key,
>>> value) VALUES (?, ?)")
>>> DEFINE_SQL_STATEMENT(get_stmt, "SELECT value FROM astdb WHERE key=?")
>>> DEFINE_SQL_STATEMENT(del_stmt, "DELETE FROM astdb WHERE key=?")
>>> DEFINE_SQL_STATEMENT(deltree_stmt, "DELETE FROM astdb WHERE key || '/'
>>> LIKE ? || '/' || '%'")
>>> DEFINE_SQL_STATEMENT(deltree_all_stmt, "DELETE FROM astdb")
>>> DEFINE_SQL_STATEMENT(gettree_stmt, "SELECT key, value FROM astdb WHERE
>>> key || '/' LIKE ? || '/' || '%' ORDER BY key")
>>> DEFINE_SQL_STATEMENT(gettree_all_stmt, "SELECT key, value FROM astdb
>>> ORDER BY key")
>>> DEFINE_SQL_STATEMENT(showkey_stmt, "SELECT key, value FROM astdb WHERE
>>> key LIKE '%' || '/' || ? ORDER BY key")
>>> DEFINE_SQL_STATEME

Re: [asterisk-dev] AstDB mySQL implementation

2017-10-29 Thread Nir Simionovich

Seems like I have under estimated the task at hand, as this part of
Asterisk requires some
more intricate familiarity with how AstDB truly works. It would be one
thing to "change the backend"
it would a far more complex task to "make two backends selectable".

Conclusion - not sure this is worth the effort at this point in time, maybe
in a later stage. :-(



On Thu, Oct 26, 2017 at 6:01 PM Nir Simionovich <nir.simionov...@gmail.com>
wrote:

> Correction, seems like this requires a bit more architecture than I
> anticipated.
>
> Basically, we need to separate this into several files and turn the entire
> AstDB concept
> into a pluggable module type module.
>
> But, as AstDB is a mandatory module for Asterisk, can we create a
> situation where
> a pluggable module is a mandatory requirement for Asterisk to launch
> correctly?
>
> Is there anything like that in Asterisk? can someone point me in some
> proper example
> or preferably, something that I can look at and learn from?
>
>
>
> On Thu, Oct 26, 2017 at 4:47 PM Nir Simionovich <nir.simionov...@gmail.com>
> wrote:
>
>> I'll have a look at it.
>>
>> If I read the code correctly, the AstDB is invoked from the asterisk.c
>> file, when asterisk is launched.
>> I think the best would be to add a configuration file like astdb.conf,
>> which will look something like this:
>>
>> [general]
>> engine=builtin ; values can be either builtin, redis or memcache (or
>> others in the future)
>>
>> ;[redis]
>> ;server = 127.0.0.1
>> ;port = 6379
>> ;database = 15 ; By default AstDB will use Redis database number 15
>>
>> ;[memcache]
>> ;server = 127.0.0.1
>> ;port = 11211
>> ;prefix = asterisk
>>
>> Then, inside the db.c file add the proper statements and backend to
>> support each of these. I'm confident
>> that from a design perspective, this is not optimal, but it would serve
>> as a nice PoC to indicate if the task
>> is feasible or not.
>>
>> For example, the following:
>>
>> DEFINE_SQL_STATEMENT(put_stmt, "INSERT OR REPLACE INTO astdb (key, value)
>> VALUES (?, ?)")
>> DEFINE_SQL_STATEMENT(get_stmt, "SELECT value FROM astdb WHERE key=?")
>> DEFINE_SQL_STATEMENT(del_stmt, "DELETE FROM astdb WHERE key=?")
>> DEFINE_SQL_STATEMENT(deltree_stmt, "DELETE FROM astdb WHERE key || '/'
>> LIKE ? || '/' || '%'")
>> DEFINE_SQL_STATEMENT(deltree_all_stmt, "DELETE FROM astdb")
>> DEFINE_SQL_STATEMENT(gettree_stmt, "SELECT key, value FROM astdb WHERE
>> key || '/' LIKE ? || '/' || '%' ORDER BY key")
>> DEFINE_SQL_STATEMENT(gettree_all_stmt, "SELECT key, value FROM astdb
>> ORDER BY key")
>> DEFINE_SQL_STATEMENT(showkey_stmt, "SELECT key, value FROM astdb WHERE
>> key LIKE '%' || '/' || ? ORDER BY key")
>> DEFINE_SQL_STATEMENT(create_astdb_stmt, "CREATE TABLE IF NOT EXISTS
>> astdb(key VARCHAR(256), value VARCHAR(256), PRIMARY KEY(key))")
>>
>> Can be augmented with something like the following:
>>
>> DEFINE_REDIS_STATEMENT(put_redis_stmt, "");
>> DEFINE_REDIS_STATEMENT(get_redis_stmt, "");
>> DEFINE_REDIS_STATEMENT(del_redis_stmt, "");
>>
>> Following this, we can simply point to the proper statements following
>> the engine selection.
>>
>> What do you think, sounds reasonable?
>>
>>
>> On Thu, Oct 26, 2017 at 4:30 PM Olle E. Johansson <o...@edvina.net> wrote:
>>
>>> On 26 Oct 2017, at 15:25, Nir Simionovich <nir.simionov...@gmail.com>
>>> wrote:
>>>
>>> I suspect the original code didn't change the overall mechanism
>>> dramatically, it's mainly a new implementation.
>>> This thing is this - replacing the implementation seems straight forward
>>> enough, making it configurable, seems
>>> like a pain in the butt.
>>>
>>> Look for the “appleraisin” branch if you want to see code :-)
>>>
>>> /O
>>>
>>>
>>>
>>>
>>> On Thu, Oct 26, 2017 at 4:23 PM Olle E. Johansson <o...@edvina.net>
>>> wrote:
>>>
>>>> On 26 Oct 2017, at 15:20, Nir Simionovich <nir.simionov...@gmail.com>
>>>> wrote:
>>>>
>>>> Just looked into the code, this is not a simple task to put a new
>>>> backend for astdb. The code isn't even designed
>>>> for something like that. Judging from what I can tell, and tell me if
>>>> I'm wrong - turning this into a configurable thing
>>&g

Re: [asterisk-dev] AstDB mySQL implementation

2017-10-26 Thread Nir Simionovich

Correction, seems like this requires a bit more architecture than I
anticipated.

Basically, we need to separate this into several files and turn the entire
AstDB concept
into a pluggable module type module.

But, as AstDB is a mandatory module for Asterisk, can we create a situation
where
a pluggable module is a mandatory requirement for Asterisk to launch
correctly?

Is there anything like that in Asterisk? can someone point me in some
proper example
or preferably, something that I can look at and learn from?



On Thu, Oct 26, 2017 at 4:47 PM Nir Simionovich <nir.simionov...@gmail.com>
wrote:

> I'll have a look at it.
>
> If I read the code correctly, the AstDB is invoked from the asterisk.c
> file, when asterisk is launched.
> I think the best would be to add a configuration file like astdb.conf,
> which will look something like this:
>
> [general]
> engine=builtin ; values can be either builtin, redis or memcache (or
> others in the future)
>
> ;[redis]
> ;server = 127.0.0.1
> ;port = 6379
> ;database = 15 ; By default AstDB will use Redis database number 15
>
> ;[memcache]
> ;server = 127.0.0.1
> ;port = 11211
> ;prefix = asterisk
>
> Then, inside the db.c file add the proper statements and backend to
> support each of these. I'm confident
> that from a design perspective, this is not optimal, but it would serve as
> a nice PoC to indicate if the task
> is feasible or not.
>
> For example, the following:
>
> DEFINE_SQL_STATEMENT(put_stmt, "INSERT OR REPLACE INTO astdb (key, value)
> VALUES (?, ?)")
> DEFINE_SQL_STATEMENT(get_stmt, "SELECT value FROM astdb WHERE key=?")
> DEFINE_SQL_STATEMENT(del_stmt, "DELETE FROM astdb WHERE key=?")
> DEFINE_SQL_STATEMENT(deltree_stmt, "DELETE FROM astdb WHERE key || '/'
> LIKE ? || '/' || '%'")
> DEFINE_SQL_STATEMENT(deltree_all_stmt, "DELETE FROM astdb")
> DEFINE_SQL_STATEMENT(gettree_stmt, "SELECT key, value FROM astdb WHERE key
> || '/' LIKE ? || '/' || '%' ORDER BY key")
> DEFINE_SQL_STATEMENT(gettree_all_stmt, "SELECT key, value FROM astdb ORDER
> BY key")
> DEFINE_SQL_STATEMENT(showkey_stmt, "SELECT key, value FROM astdb WHERE key
> LIKE '%' || '/' || ? ORDER BY key")
> DEFINE_SQL_STATEMENT(create_astdb_stmt, "CREATE TABLE IF NOT EXISTS
> astdb(key VARCHAR(256), value VARCHAR(256), PRIMARY KEY(key))")
>
> Can be augmented with something like the following:
>
> DEFINE_REDIS_STATEMENT(put_redis_stmt, "");
> DEFINE_REDIS_STATEMENT(get_redis_stmt, "");
> DEFINE_REDIS_STATEMENT(del_redis_stmt, "");
>
> Following this, we can simply point to the proper statements following the
> engine selection.
>
> What do you think, sounds reasonable?
>
>
> On Thu, Oct 26, 2017 at 4:30 PM Olle E. Johansson <o...@edvina.net> wrote:
>
>> On 26 Oct 2017, at 15:25, Nir Simionovich <nir.simionov...@gmail.com>
>> wrote:
>>
>> I suspect the original code didn't change the overall mechanism
>> dramatically, it's mainly a new implementation.
>> This thing is this - replacing the implementation seems straight forward
>> enough, making it configurable, seems
>> like a pain in the butt.
>>
>> Look for the “appleraisin” branch if you want to see code :-)
>>
>> /O
>>
>>
>>
>>
>> On Thu, Oct 26, 2017 at 4:23 PM Olle E. Johansson <o...@edvina.net> wrote:
>>
>>> On 26 Oct 2017, at 15:20, Nir Simionovich <nir.simionov...@gmail.com>
>>> wrote:
>>>
>>> Just looked into the code, this is not a simple task to put a new
>>> backend for astdb. The code isn't even designed
>>> for something like that. Judging from what I can tell, and tell me if
>>> I'm wrong - turning this into a configurable thing
>>> would be more or less an open-heart surgery.
>>>
>>> My patch wasn’t that bad, but it was before sqlite.
>>>
>>> /O
>>>
>>>
>>>
>>>
>>> On Thu, Oct 26, 2017 at 4:16 PM Olle E. Johansson <o...@edvina.net>
>>> wrote:
>>>
>>>> Somewhere in Asterisk space, there’s an old patch where I added ASTDB
>>>> over realtime, meaning you can use
>>>> any realtime storage. If I remember correctly there was a bit of
>>>> chicken-and-egg problem with some astdb
>>>> calls happening before realtime got launched, but otherwise it worked
>>>> just fine in production for a long time.
>>>>
>>>> /O
>>>>
>>>> On 26 Oct 2017, at 15:13, Nir Simionovich <nir.simionov...@gmail.com>
>&g

Re: [asterisk-dev] AstDB mySQL implementation

2017-10-26 Thread Nir Simionovich

I'll have a look at it.

If I read the code correctly, the AstDB is invoked from the asterisk.c
file, when asterisk is launched.
I think the best would be to add a configuration file like astdb.conf,
which will look something like this:

[general]
engine=builtin ; values can be either builtin, redis or memcache (or others
in the future)

;[redis]
;server = 127.0.0.1
;port = 6379
;database = 15 ; By default AstDB will use Redis database number 15

;[memcache]
;server = 127.0.0.1
;port = 11211
;prefix = asterisk

Then, inside the db.c file add the proper statements and backend to support
each of these. I'm confident
that from a design perspective, this is not optimal, but it would serve as
a nice PoC to indicate if the task
is feasible or not.

For example, the following:

DEFINE_SQL_STATEMENT(put_stmt, "INSERT OR REPLACE INTO astdb (key, value)
VALUES (?, ?)")
DEFINE_SQL_STATEMENT(get_stmt, "SELECT value FROM astdb WHERE key=?")
DEFINE_SQL_STATEMENT(del_stmt, "DELETE FROM astdb WHERE key=?")
DEFINE_SQL_STATEMENT(deltree_stmt, "DELETE FROM astdb WHERE key || '/' LIKE
? || '/' || '%'")
DEFINE_SQL_STATEMENT(deltree_all_stmt, "DELETE FROM astdb")
DEFINE_SQL_STATEMENT(gettree_stmt, "SELECT key, value FROM astdb WHERE key
|| '/' LIKE ? || '/' || '%' ORDER BY key")
DEFINE_SQL_STATEMENT(gettree_all_stmt, "SELECT key, value FROM astdb ORDER
BY key")
DEFINE_SQL_STATEMENT(showkey_stmt, "SELECT key, value FROM astdb WHERE key
LIKE '%' || '/' || ? ORDER BY key")
DEFINE_SQL_STATEMENT(create_astdb_stmt, "CREATE TABLE IF NOT EXISTS
astdb(key VARCHAR(256), value VARCHAR(256), PRIMARY KEY(key))")

Can be augmented with something like the following:

DEFINE_REDIS_STATEMENT(put_redis_stmt, "");
DEFINE_REDIS_STATEMENT(get_redis_stmt, "");
DEFINE_REDIS_STATEMENT(del_redis_stmt, "");

Following this, we can simply point to the proper statements following the
engine selection.

What do you think, sounds reasonable?

On Thu, Oct 26, 2017 at 4:30 PM Olle E. Johansson <o...@edvina.net> wrote:

> On 26 Oct 2017, at 15:25, Nir Simionovich <nir.simionov...@gmail.com>
> wrote:
>
> I suspect the original code didn't change the overall mechanism
> dramatically, it's mainly a new implementation.
> This thing is this - replacing the implementation seems straight forward
> enough, making it configurable, seems
> like a pain in the butt.
>
> Look for the “appleraisin” branch if you want to see code :-)
>
> /O
>
>
>
>
> On Thu, Oct 26, 2017 at 4:23 PM Olle E. Johansson <o...@edvina.net> wrote:
>
>> On 26 Oct 2017, at 15:20, Nir Simionovich <nir.simionov...@gmail.com>
>> wrote:
>>
>> Just looked into the code, this is not a simple task to put a new backend
>> for astdb. The code isn't even designed
>> for something like that. Judging from what I can tell, and tell me if I'm
>> wrong - turning this into a configurable thing
>> would be more or less an open-heart surgery.
>>
>> My patch wasn’t that bad, but it was before sqlite.
>>
>> /O
>>
>>
>>
>>
>> On Thu, Oct 26, 2017 at 4:16 PM Olle E. Johansson <o...@edvina.net> wrote:
>>
>>> Somewhere in Asterisk space, there’s an old patch where I added ASTDB
>>> over realtime, meaning you can use
>>> any realtime storage. If I remember correctly there was a bit of
>>> chicken-and-egg problem with some astdb
>>> calls happening before realtime got launched, but otherwise it worked
>>> just fine in production for a long time.
>>>
>>> /O
>>>
>>> On 26 Oct 2017, at 15:13, Nir Simionovich <nir.simionov...@gmail.com>
>>> wrote:
>>>
>>> I'd like to +1 on that idea.
>>>
>>> While I'm somewhat reluctant to using mySQL as the base of such a
>>> change, as mySQL is an overkill for AstDB,
>>> having a proper AstDB configurable backend is an interesting thing.
>>> Personally speaking, I would actually prefer
>>> something like Memcache or preferably Redis. Both are similar in
>>> function and usability to AstDB, both are fairly
>>> scalable (Redis specifically) and both are fairly simplistic in nature.
>>>
>>> I do admit that this got me intrigued...
>>>
>>>
>>>
>>> On Tue, Sep 26, 2017 at 12:45 AM Matt Fredrickson <cres...@digium.com>
>>> wrote:
>>>
>>>> On Fri, Sep 22, 2017 at 12:12 PM, Ryan Wagoner <rswago...@gmail.com>
>>>> wrote:
>>>>
>>>>> I've been scaling out FreePBX horizontally with Kamailio and custom
>>>>> FreePBX modules mainly to handle call center o

Re: [asterisk-dev] AstDB mySQL implementation

2017-10-26 Thread Nir Simionovich

I suspect the original code didn't change the overall mechanism
dramatically, it's mainly a new implementation.
This thing is this - replacing the implementation seems straight forward
enough, making it configurable, seems
like a pain in the butt.



On Thu, Oct 26, 2017 at 4:23 PM Olle E. Johansson <o...@edvina.net> wrote:

> On 26 Oct 2017, at 15:20, Nir Simionovich <nir.simionov...@gmail.com>
> wrote:
>
> Just looked into the code, this is not a simple task to put a new backend
> for astdb. The code isn't even designed
> for something like that. Judging from what I can tell, and tell me if I'm
> wrong - turning this into a configurable thing
> would be more or less an open-heart surgery.
>
> My patch wasn’t that bad, but it was before sqlite.
>
> /O
>
>
>
>
> On Thu, Oct 26, 2017 at 4:16 PM Olle E. Johansson <o...@edvina.net> wrote:
>
>> Somewhere in Asterisk space, there’s an old patch where I added ASTDB
>> over realtime, meaning you can use
>> any realtime storage. If I remember correctly there was a bit of
>> chicken-and-egg problem with some astdb
>> calls happening before realtime got launched, but otherwise it worked
>> just fine in production for a long time.
>>
>> /O
>>
>> On 26 Oct 2017, at 15:13, Nir Simionovich <nir.simionov...@gmail.com>
>> wrote:
>>
>> I'd like to +1 on that idea.
>>
>> While I'm somewhat reluctant to using mySQL as the base of such a change,
>> as mySQL is an overkill for AstDB,
>> having a proper AstDB configurable backend is an interesting thing.
>> Personally speaking, I would actually prefer
>> something like Memcache or preferably Redis. Both are similar in function
>> and usability to AstDB, both are fairly
>> scalable (Redis specifically) and both are fairly simplistic in nature.
>>
>> I do admit that this got me intrigued...
>>
>>
>>
>> On Tue, Sep 26, 2017 at 12:45 AM Matt Fredrickson <cres...@digium.com>
>> wrote:
>>
>>> On Fri, Sep 22, 2017 at 12:12 PM, Ryan Wagoner <rswago...@gmail.com>
>>> wrote:
>>>
>>>> I've been scaling out FreePBX horizontally with Kamailio and custom
>>>> FreePBX modules mainly to handle call center outbound dialing (around 20k
>>>> calls per day). One of the issues I ran into was FreePBX uses the AstDB
>>>> extensively and will write changes to it from the dialplan or the FreePBX
>>>> user control panel.
>>>>
>>>> To overcome this I either needed to scrap FreePBX and build a new GUI
>>>> using Asterisk realtime, heavily modify FreePBX (not an option), or rewrite
>>>> AstDB to use a database like mySQL. I choose the last option and have had
>>>> the code in production for just over a month. I'm backing it with a two
>>>> node MariaDB Galera cluster with HAProxy providing failover for the client
>>>> DB connections.
>>>>
>>>> I realize that SQLite was chosen for AstDB for performance reasons.
>>>> However mySQL seems to perform just fine in the above scenario. Right now I
>>>> have a db.c file that just has the mySQL code. Does anybody else have any
>>>> interest in using mySQL for the AstDB backend? I'm debating if it would
>>>> make sense to have the option to select your AstDB backend.
>>>>
>>>
>>> Hey Ryan,
>>>
>>> First off, thanks for letting us know about the fun project you embarked
>>> upon.  I think Josh already answered some of your questions, but with
>>> regards to the work you did - I believe that in the past there have been
>>> others who have wanted an ODBC AstDB driver as well.  If your code can be
>>> made configurable, it may be a good contribution.
>>>
>>> Anyways, hope you are doing well, and perhaps we'll see your code up on
>>> gerrit at some time in the future. :-)
>>>
>>> --
>>> Matthew Fredrickson
>>> Digium, Inc. | Engineering Manager
>>> 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
>>> --
>>> _
>>> -- 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-7

Re: [asterisk-dev] AstDB mySQL implementation

2017-10-26 Thread Nir Simionovich

Just looked into the code, this is not a simple task to put a new backend
for astdb. The code isn't even designed
for something like that. Judging from what I can tell, and tell me if I'm
wrong - turning this into a configurable thing
would be more or less an open-heart surgery.



On Thu, Oct 26, 2017 at 4:16 PM Olle E. Johansson <o...@edvina.net> wrote:

> Somewhere in Asterisk space, there’s an old patch where I added ASTDB over
> realtime, meaning you can use
> any realtime storage. If I remember correctly there was a bit of
> chicken-and-egg problem with some astdb
> calls happening before realtime got launched, but otherwise it worked just
> fine in production for a long time.
>
> /O
>
> On 26 Oct 2017, at 15:13, Nir Simionovich <nir.simionov...@gmail.com>
> wrote:
>
> I'd like to +1 on that idea.
>
> While I'm somewhat reluctant to using mySQL as the base of such a change,
> as mySQL is an overkill for AstDB,
> having a proper AstDB configurable backend is an interesting thing.
> Personally speaking, I would actually prefer
> something like Memcache or preferably Redis. Both are similar in function
> and usability to AstDB, both are fairly
> scalable (Redis specifically) and both are fairly simplistic in nature.
>
> I do admit that this got me intrigued...
>
>
>
> On Tue, Sep 26, 2017 at 12:45 AM Matt Fredrickson <cres...@digium.com>
> wrote:
>
>> On Fri, Sep 22, 2017 at 12:12 PM, Ryan Wagoner <rswago...@gmail.com>
>> wrote:
>>
>>> I've been scaling out FreePBX horizontally with Kamailio and custom
>>> FreePBX modules mainly to handle call center outbound dialing (around 20k
>>> calls per day). One of the issues I ran into was FreePBX uses the AstDB
>>> extensively and will write changes to it from the dialplan or the FreePBX
>>> user control panel.
>>>
>>> To overcome this I either needed to scrap FreePBX and build a new GUI
>>> using Asterisk realtime, heavily modify FreePBX (not an option), or rewrite
>>> AstDB to use a database like mySQL. I choose the last option and have had
>>> the code in production for just over a month. I'm backing it with a two
>>> node MariaDB Galera cluster with HAProxy providing failover for the client
>>> DB connections.
>>>
>>> I realize that SQLite was chosen for AstDB for performance reasons.
>>> However mySQL seems to perform just fine in the above scenario. Right now I
>>> have a db.c file that just has the mySQL code. Does anybody else have any
>>> interest in using mySQL for the AstDB backend? I'm debating if it would
>>> make sense to have the option to select your AstDB backend.
>>>
>>
>> Hey Ryan,
>>
>> First off, thanks for letting us know about the fun project you embarked
>> upon.  I think Josh already answered some of your questions, but with
>> regards to the work you did - I believe that in the past there have been
>> others who have wanted an ODBC AstDB driver as well.  If your code can be
>> made configurable, it may be a good contribution.
>>
>> Anyways, hope you are doing well, and perhaps we'll see your code up on
>> gerrit at some time in the future. :-)
>>
>> --
>> Matthew Fredrickson
>> Digium, Inc. | Engineering Manager
>> 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
>> --
>> _
>> -- 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 <073-255-7799>(MSN): n...@greenfieldtech.net
>   (m) +972-54-6982826 <054-698-2826>  (GTALK):
> nir.simionov...@gmail.com
>   (f) +972-73-2557202 <073-255-7202>  (SKYPE): greenfieldtech.nir
>
> --
>Zero Your Inbox <https://mailstrom.co/referral/ARZJE> | Cloud
> Servers <https://www.digitalocean.com/?refcode=97eeea09917a>
> --
>
> *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
> thi

Re: [asterisk-dev] AstDB mySQL implementation

2017-10-26 Thread Nir Simionovich

I'd like to +1 on that idea.

While I'm somewhat reluctant to using mySQL as the base of such a change,
as mySQL is an overkill for AstDB,
having a proper AstDB configurable backend is an interesting thing.
Personally speaking, I would actually prefer
something like Memcache or preferably Redis. Both are similar in function
and usability to AstDB, both are fairly
scalable (Redis specifically) and both are fairly simplistic in nature.

I do admit that this got me intrigued...



On Tue, Sep 26, 2017 at 12:45 AM Matt Fredrickson <cres...@digium.com>
wrote:

> On Fri, Sep 22, 2017 at 12:12 PM, Ryan Wagoner <rswago...@gmail.com>
> wrote:
>
>> I've been scaling out FreePBX horizontally with Kamailio and custom
>> FreePBX modules mainly to handle call center outbound dialing (around 20k
>> calls per day). One of the issues I ran into was FreePBX uses the AstDB
>> extensively and will write changes to it from the dialplan or the FreePBX
>> user control panel.
>>
>> To overcome this I either needed to scrap FreePBX and build a new GUI
>> using Asterisk realtime, heavily modify FreePBX (not an option), or rewrite
>> AstDB to use a database like mySQL. I choose the last option and have had
>> the code in production for just over a month. I'm backing it with a two
>> node MariaDB Galera cluster with HAProxy providing failover for the client
>> DB connections.
>>
>> I realize that SQLite was chosen for AstDB for performance reasons.
>> However mySQL seems to perform just fine in the above scenario. Right now I
>> have a db.c file that just has the mySQL code. Does anybody else have any
>> interest in using mySQL for the AstDB backend? I'm debating if it would
>> make sense to have the option to select your AstDB backend.
>>
>
> Hey Ryan,
>
> First off, thanks for letting us know about the fun project you embarked
> upon.  I think Josh already answered some of your questions, but with
> regards to the work you did - I believe that in the past there have been
> others who have wanted an ODBC AstDB driver as well.  If your code can be
> made configurable, it may be a good contribution.
>
> Anyways, hope you are doing well, and perhaps we'll see your code up on
> gerrit at some time in the future. :-)
>
> --
> Matthew Fredrickson
> Digium, Inc. | Engineering Manager
> 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
> --
> _
> -- 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 <https://mailstrom.co/referral/ARZJE> | Cloud
Servers <https://www.digitalocean.com/?refcode=97eeea09917a>

--

*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

Re: [asterisk-dev] Asterisk 11 EOL Announcement

2017-10-26 Thread Nir Simionovich

▓██▓██░─
░███░░███░──
──█▒──█─
─▓█▓███░──░▒▓█─▒
──▓███─██▓███───
─▓██──░███──
▓█──░░████▓██▓▒─
█▒─░
█░───▓██▓███
█░───░██
█░───▒█▒
███▓▓██▓███─
───▒█▓█─▒█──▓─▒░─██─
───████─░█░──░█▓──▒▓█▓█─▒██─
───▓▓▓█▓▓───░▒█▓──░██─▒█───▓▓█▓░███─
───█▓───░───░▓█───░▓█─▒█───▒██──██▒─
───█───░─██░█░▒─░██───░─██─█▓█░─
───█─██─▓▓░▒▓██▓█──█▓▒──▓█──
──██───░▒▒▒█▓▒▒─██──
──▓▒─░──██──
──█▒█▓──
──█──Asterisk 11───▓█░──
──████▒██───
──███───
──█▓─▒─██───
─░███░─██───
─██─█───░▒▒█▓───
─█░──▒███▒██
─███▓███
─█──░─█▓▓███
─▓─▒▓─█░
─█▒█░──▒─░█░░██▓
░▓▓▓──█▒─▒█──██░
░██▒─██░─██──██░
─██▒▓█▒──█─▒███░
─█──▒█▒█▓███░▒░─
██▒▒██▓█▓─░▒██░▒▓█▓██░░─
───░█▓█▓██░▒░▒░░░──███░█▓▓▓─
─██▓██▓▓██──
─▓███───

On Wed, Oct 25, 2017 at 5:45 PM Matt Fredrickson <cres...@digium.com> wrote:

> Dearly Beloved,
>
> We have gathered here today to mourn the passing of a deeply regarded
> branch of Asterisk - Asterisk 11.  As of today, it has officially
> reached its end of life.  It was a good branch, having served 5 years
> faithfully in the service of its users.  As far as history goes,
> 11.0.0 was born on November 28th 2012.  It had 1458 commits in its 5
> year life, and some will try to use it even after its useful end of
> life.  Now, mostly due to the fact that it is no longer with us,
> Asterisk 11 will become one of the “great” releases of Asterisk,
> joining the ranks of all the other “great” branches such as 1.0, 1.2,
> 1.4, 1.6, 1.8, and 10.  Please join with me now for a moment of
> silence for it, as it passes to the great beyond.
>
> In all seriousness, if you didn’t get the humor in the above message,
> today is the day that Asterisk 11 officially goes end of life.  For
> the last year, Asterisk 11 has been in security fix only mode, meaning
> it stopped receive regular bug fixes a year ago, and has only received
> security related fixes.  Today that all ends and not even security
> fixes will going into that branch.  If you haven’t gotten off of it
> yet, there is no better time than the present.
>
> If you’re curious about the dates and times associated with life
> cycles transitions on Asterisk branches, you can read more at
> https://wiki.asterisk.org/wiki/display/AST/Asterisk+Versions
>
> Last of all, thanks to all of you who contribute to the Asterisk
> project, whether it be bug reports, bug fixes, new feature
> development, or helping other users by answering questions on the
> mailing lists, forums, and other venues.  At the end of the day, it’s
> the quality of the user and development community that make Asterisk
> such a great project.
>
> Best wishes.
>
> --
> Matthew Fredrickson
> Digium, Inc. | Engineering Manager
> 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
> <https://maps.google.com/?q=445+Jan+Davis+Drive+NW+-+Huntsville,+AL+35806+-+USA=gmail=g>
>
> --
> _
> -- 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 <https://mailstrom.co/referral/ARZJE> | Cloud
Servers <https://www.digitalocean.com/?refcode=97eeea09917a>

--

*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

Re: [asterisk-dev] Adding a new module to Asterisk

2017-10-19 Thread Nir Simionovich

Hi All,

  Following cdr_beanstalk, I've added a beanstalk backend to CEL as well.
I'll be uploading
that to geritt review under a new review issue.



On Mon, Oct 16, 2017 at 6:35 PM Nir Simionovich <nir.simionov...@gmail.com>
wrote:

> Hi All,
>
>   So, my new cdr_beanstalkd module is available at
> team/nirs/beanstalkd-support
> <https://gerrit.asterisk.org/#/q/topic:team/nirs/beanstalkd-support+(status:open+OR+status:merged)>
> .
> I'm not sure I've opened the review correctly, so would appreciate if
> someone can
> lend a hand on this one :-)
>
>
>
> On Mon, Oct 16, 2017 at 5:02 PM Nir Simionovich <nir.simionov...@gmail.com>
> wrote:
>
>> Thanks. The module is now finished - and also tested. I want to generate
>> some tests and make sure
>> it holds up, but in general - it's working as I expected it to work.
>>
>>
>>
>> On Mon, Oct 16, 2017 at 4:06 PM Joshua Colp <jc...@digium.com> wrote:
>>
>>> On Mon, Oct 16, 2017, at 10:03 AM, Nir Simionovich wrote:
>>> > ok, managed to pass that hurdle - I'm basically using a fairly old
>>> piece
>>> > of
>>> > code to base my module on - namely, cdr_manager.c,
>>> > so the configuration parser in there is slightly different.
>>> >
>>> > Minor question, is there a "safe" asterisk method of doing a "sprintf"?
>>>
>>> There is no Asterisk wrapper for it, but snprintf should be used instead
>>> generally.
>>>
>>> --
>>> Joshua Colp
>>> Digium, Inc. | Senior 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
>>>
>> --
>>
>> Kind Regards,
>>
>>   Nir Simionovich
>>
>>   GreenfieldTech
>>
>>   (schedule) http://nirsimionovich.appointy.com/
>>
>>   (w) http://www.greenfieldtech.net
>>
>>   (p) +972-73-2557799 <073-255-7799>(MSN):
>> n...@greenfieldtech.net
>>
>>   (m) +972-54-6982826 <054-698-2826>  (GTALK):
>> nir.simionov...@gmail.com
>>
>>   (f) +972-73-2557202 <073-255-7202>  (SKYPE): greenfieldtech.nir
>>
>>
>> --
>>
>>Zero Your Inbox <https://mailstrom.co/referral/ARZJE> | Cloud
>> Servers <https://www.digitalocean.com/?refcode=97eeea09917a>
>>
>> --
>>
>> *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.
>>
> --
>
> Kind Regards,
>
>   Nir Simionovich
>
>   GreenfieldTech
>
>   (schedule) http://nirsimionovich.appointy.com/
>
>   (w) http://www.greenfieldtech.net
>
>   (p) +972-73-2557799 <073-255-7799>(MSN): n...@greenfieldtech.net
>
>   (m) +972-54-6982826 <054-698-2826>  (GTALK):
> nir.simionov...@gmail.com
>
>   (f) +972-73-2557202 <073-255-7202>  (SKYPE): greenfieldtech.nir
>
>
> --
>
>Zero Your Inbox <https://mailstrom.co/referral/ARZJE> | Cloud
> Servers <https://www.digitalocean.com/?refcode=97eeea09917a>
>
> ----------
>
> *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
>

Re: [asterisk-dev] Adding a new module to Asterisk

2017-10-16 Thread Nir Simionovich

Hi All,

  So, my new cdr_beanstalkd module is available at
team/nirs/beanstalkd-support
<https://gerrit.asterisk.org/#/q/topic:team/nirs/beanstalkd-support+(status:open+OR+status:merged)>
.
I'm not sure I've opened the review correctly, so would appreciate if
someone can
lend a hand on this one :-)



On Mon, Oct 16, 2017 at 5:02 PM Nir Simionovich <nir.simionov...@gmail.com>
wrote:

> Thanks. The module is now finished - and also tested. I want to generate
> some tests and make sure
> it holds up, but in general - it's working as I expected it to work.
>
>
>
> On Mon, Oct 16, 2017 at 4:06 PM Joshua Colp <jc...@digium.com> wrote:
>
>> On Mon, Oct 16, 2017, at 10:03 AM, Nir Simionovich wrote:
>> > ok, managed to pass that hurdle - I'm basically using a fairly old piece
>> > of
>> > code to base my module on - namely, cdr_manager.c,
>> > so the configuration parser in there is slightly different.
>> >
>> > Minor question, is there a "safe" asterisk method of doing a "sprintf"?
>>
>> There is no Asterisk wrapper for it, but snprintf should be used instead
>> generally.
>>
>> --
>> Joshua Colp
>> Digium, Inc. | Senior 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
>>
> --
>
> Kind Regards,
>
>   Nir Simionovich
>
>   GreenfieldTech
>
>   (schedule) http://nirsimionovich.appointy.com/
>
>   (w) http://www.greenfieldtech.net
>
>   (p) +972-73-2557799 <073-255-7799>(MSN): n...@greenfieldtech.net
>
>   (m) +972-54-6982826 <054-698-2826>  (GTALK):
> nir.simionov...@gmail.com
>
>   (f) +972-73-2557202 <073-255-7202>  (SKYPE): greenfieldtech.nir
>
>
> --
>
>Zero Your Inbox <https://mailstrom.co/referral/ARZJE> | Cloud
> Servers <https://www.digitalocean.com/?refcode=97eeea09917a>
>
> --
>
> *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.
>
-- 

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 <https://mailstrom.co/referral/ARZJE> | Cloud
Servers <https://www.digitalocean.com/?refcode=97eeea09917a>

--

*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

Re: [asterisk-dev] Adding a new module to Asterisk

2017-10-16 Thread Nir Simionovich

Thanks. The module is now finished - and also tested. I want to generate
some tests and make sure
it holds up, but in general - it's working as I expected it to work.



On Mon, Oct 16, 2017 at 4:06 PM Joshua Colp <jc...@digium.com> wrote:

> On Mon, Oct 16, 2017, at 10:03 AM, Nir Simionovich wrote:
> > ok, managed to pass that hurdle - I'm basically using a fairly old piece
> > of
> > code to base my module on - namely, cdr_manager.c,
> > so the configuration parser in there is slightly different.
> >
> > Minor question, is there a "safe" asterisk method of doing a "sprintf"?
>
> There is no Asterisk wrapper for it, but snprintf should be used instead
> generally.
>
> --
> Joshua Colp
> Digium, Inc. | Senior 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
>
-- 

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 <https://mailstrom.co/referral/ARZJE> | Cloud
Servers <https://www.digitalocean.com/?refcode=97eeea09917a>

--

*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

Re: [asterisk-dev] Adding a new module to Asterisk

2017-10-16 Thread Nir Simionovich

ok, managed to pass that hurdle - I'm basically using a fairly old piece of
code to base my module on - namely, cdr_manager.c,
so the configuration parser in there is slightly different.

Minor question, is there a "safe" asterisk method of doing a "sprintf"?

On Mon, Oct 16, 2017 at 1:16 PM Joshua Colp <jc...@digium.com> wrote:

> On Mon, Oct 16, 2017, at 06:45 AM, Nir Simionovich wrote:
> > Ok, that helped - looks like I'm linking correctly now.
> >
> > Different question, I remember their used to be a "safe string copy"
> > function that I'm supposed to use,
> > instead of using strcpy. Mainly, I want to parse my configuration file
> > correctly, but I can't find any
> > specific methodology for doing this in a uniform asteriskish manner.
>
> From a configuration perspective there's two APIs:
>
> If only .conf files are needed then there is the Asterisk Config Options
> API, include/asterisk/config_options.h, which is used by the skeleton
> application apps/app_skel.c for configuration parsing, storing, and
> usage.
>
> If realtime is needed then there is the Asterisk Sorcery API,
> include/asterisk/sorcery.h, which is used by PJSIP and other things -
> with the simplest being res/res_mwi_external.c
>
> It's highly recommended to use one of them instead of rolling your own
> configuration parsing. They take care of things (such as safe atomic
> reloads).
>
> The "safe string copy" you are thinking of is probably ast_copy_string.
>
> --
> Joshua Colp
> Digium, Inc. | Senior 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
>
-- 

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 <https://mailstrom.co/referral/ARZJE> | Cloud
Servers <https://www.digitalocean.com/?refcode=97eeea09917a>

--

*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

Re: [asterisk-dev] Adding a new module to Asterisk

2017-10-16 Thread Nir Simionovich

Ok, that helped - looks like I'm linking correctly now.

Different question, I remember their used to be a "safe string copy"
function that I'm supposed to use,
instead of using strcpy. Mainly, I want to parse my configuration file
correctly, but I can't find any
specific methodology for doing this in a uniform asteriskish manner.



On Wed, Oct 11, 2017 at 10:37 AM Alexander Traud <pabstr...@compuserve.com>
wrote:

> > The new [module] relies on a library that I need to introduce to the
> > linker, however, I've tried to figure out how the autotools work in
> > there
>
> Took me a while to understand as well. Have a look at audio-codec modules
> like the one for Codec 2: <http://github.com/traud/asterisk-codec2>.
>
> The required patches for the autotools are in "build_codec2.patch". Then,
> in your actual module, you add a MODULEINFO at the start, like shown in
> "codecs/codec_codec2.c". At the end, you have to call "./bootstrap.sh" once
> before you start "./configure". Then, make should be happy.
>
> If that did not help either, please, explain in more detail, for example
> the error message you are facing or which library you try to link. Are you
> able to compile against its header files already? Furthermore, in which
> directory of the Asterisk project are your added source files?
>
>
>
> --
> _
> -- 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 <https://mailstrom.co/referral/ARZJE> | Cloud
Servers <https://www.digitalocean.com/?refcode=97eeea09917a>

--

*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

[asterisk-dev] Adding a new module to Asterisk

2017-10-10 Thread Nir Simionovich

Hi All,

  I'm in the process of adding a new module to Asterisk, in this case, a
new CDR backend.
The new backend relies on a library that I need to introduce to the linker,
however, I've tried
to figure out how the autotools work in there - and had failed miserably.

  I would appreciate if someone can shed a little light on the process - if
possible.

Regards,
  Nir S
-- 
_
-- 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] Deadlock in chan_sip

2016-04-05 Thread Nir Simionovich

Hey Ryan,

  Well, I'm not using Realtime hear and the setup is much simpler - but the
overall deadlock pathology is very similar.
Currently, I've managed to mitigate the issue on my systems by doing the
following:

1. Migration of my inbound SIP channel from chan_sip to chan_pjsip
2. Forcing Asterisk to "transcode" between ulaw to alaw and back, so that
re-invites don't work on the problematic path.

  I've tested with version running as back as 13.0 and 12.4 - all
manifested the same scenario.

  This is not version specific or setup specific, this is something a bit
more lower level then it looks.

On Mon, Apr 4, 2016 at 7:11 PM, Ryan Rittgarn <rrittg...@techpro.com> wrote:

> Nir, is your bug possibly related to:
> https://issues.asterisk.org/jira/browse/ASTERISK-25468
>
> I've been experiencing the bug referenced and have had to roll back to
> 13.4 as the issue seems to have been introduced going into 13.5
>
>
> -Original Message-
> From: asterisk-dev-boun...@lists.digium.com [mailto:
> asterisk-dev-boun...@lists.digium.com] On Behalf Of
> asterisk-dev-requ...@lists.digium.com
> Sent: Sunday, April 03, 2016 12:00 PM
> To: asterisk-dev@lists.digium.com
> Subject: asterisk-dev Digest, Vol 141, Issue 4
>
> Send asterisk-dev mailing list submissions to
> asterisk-dev@lists.digium.com
>
> To subscribe or unsubscribe via the World Wide Web, visit
> http://lists.digium.com/mailman/listinfo/asterisk-dev
> or, via email, send a message with subject or body 'help' to
> asterisk-dev-requ...@lists.digium.com
>
> You can reach the person managing the list at
> asterisk-dev-ow...@lists.digium.com
>
> When replying, please edit your Subject line so it is more specific than
> "Re: Contents of asterisk-dev digest..."
>
>
> Today's Topics:
>
>1. Deadlock in chan_sip, caused by weird media re-invite from
>   remote side (Nir Simionovich)
>
>
> ------
>
> Message: 1
> Date: Sun, 3 Apr 2016 12:03:19 +0300
> From: Nir Simionovich <nir.simionov...@gmail.com>
> To: Asterisk Developers Mailing List <asterisk-dev@lists.digium.com>
> Subject: [asterisk-dev] Deadlock in chan_sip,   caused by weird media
> re-invite from remote side
> Message-ID:
> <
> cae+pvdpzbzj0b4aq3kyedgbcgzpxev2zqrdhrhqqya4stze...@mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> Hi All,
>
>   We have several systems, some running Asterisk 13 some 12. We have
> recently discovered a possible dead-lock scenario in chan_sip. The
> dead-lock seems to manifest as the below:
>
> LCR-AMS-01*CLI> core show locks
>
> ===
> === 12.8.2
> === Currently Held Locks
> ===
> ===
> ===  <lock#> (): name>  (times locked)
> ===
> === Thread ID: 0x7f922f88b700 (do_monitor   started at [29073]
> chan_sip.c restart_monitor())
> === ---> Lock #0 (astobj2_container.c): MUTEX 333 internal_ao2_traverse
> self 0x36a9880 (1)
> /usr/sbin/asterisk(__ast_bt_get_addresses+0x1d) [0x46556d]
> /usr/sbin/asterisk(__ast_pthread_mutex_lock+0xc9) [0x5317d5]
> /usr/sbin/asterisk(__ao2_lock+0x96) [0x45a21f]
> /usr/sbin/asterisk() [0x45b9b1]
> /usr/sbin/asterisk(__ao2_callback+0x5f) [0x45bd83]
> /usr/lib/asterisk/modules/chan_sip.so(+0x96a7d) [0x7f9249c2fa7d]
> /usr/sbin/asterisk() [0x5edbd1]
> /lib64/libpthread.so.0(+0x7a51) [0x7f92da37aa51]
> /lib64/libc.so.6(clone+0x6d) [0x7f92dbf8d93d] ===
> ---
> ===
> ===
>
>   Now, the funny bit is how it happens. This is the scenario:
>
> Soft Phone -> Asterisk A -> Asterisk B -> Carrier
>
>   Soft phone is behind a NAT. Asterisk servers are not, same as the
> carrier.
>
>   We've noticed that the carrier tries to run a media re-invite, after the
> call had basically dropped from Asterisk B, and tries to do it over and
> over again, without stopping. Eventually, that would dead-lock chan_sip
> completely, requiring a full blown asterisk restart.
>
>   Any of you ever encountered anything like this?
>
>   I've mitigated the issue by forcing two different codecs on the two
> sides of Asterisk B, basically, preventing the media re-invite - but it
> isn't the proper solution.
> -- next part --
> An HTML attachment was scrubbed...
> URL: <
> http://lists.digium.com/pi

[asterisk-dev] Deadlock in chan_sip, caused by weird media re-invite from remote side

2016-04-03 Thread Nir Simionovich

Hi All,

  We have several systems, some running Asterisk 13 some 12. We have
recently discovered a
possible dead-lock scenario in chan_sip. The dead-lock seems to manifest as
the below:

LCR-AMS-01*CLI> core show locks

===
=== 12.8.2
=== Currently Held Locks
===
===
===   ():  (times locked)
===
=== Thread ID: 0x7f922f88b700 (do_monitor   started at [29073]
chan_sip.c restart_monitor())
=== ---> Lock #0 (astobj2_container.c): MUTEX 333 internal_ao2_traverse
self 0x36a9880 (1)
/usr/sbin/asterisk(__ast_bt_get_addresses+0x1d) [0x46556d]
/usr/sbin/asterisk(__ast_pthread_mutex_lock+0xc9) [0x5317d5]
/usr/sbin/asterisk(__ao2_lock+0x96) [0x45a21f]
/usr/sbin/asterisk() [0x45b9b1]
/usr/sbin/asterisk(__ao2_callback+0x5f) [0x45bd83]
/usr/lib/asterisk/modules/chan_sip.so(+0x96a7d) [0x7f9249c2fa7d]
/usr/sbin/asterisk() [0x5edbd1]
/lib64/libpthread.so.0(+0x7a51) [0x7f92da37aa51]
/lib64/libc.so.6(clone+0x6d) [0x7f92dbf8d93d]
=== ---
===
===

  Now, the funny bit is how it happens. This is the scenario:

Soft Phone -> Asterisk A -> Asterisk B -> Carrier

  Soft phone is behind a NAT. Asterisk servers are not, same as the carrier.

  We've noticed that the carrier tries to run a media re-invite, after the
call had basically
dropped from Asterisk B, and tries to do it over and over again, without
stopping. Eventually,
that would dead-lock chan_sip completely, requiring a full blown asterisk
restart.

  Any of you ever encountered anything like this?

  I've mitigated the issue by forcing two different codecs on the two sides
of Asterisk B, basically,
preventing the media re-invite - but it isn't the proper solution.
-- 
_
-- 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] ARI - Add Support for custom SIP Headers with Originate

2015-03-09 Thread Nir Simionovich

Cool, too bad it isn't documented. I'll add it into PHPARI as well.
On Mar 8, 2015 6:18 PM, Matthew Jordan mjor...@digium.com wrote:


 On Sun, Mar 8, 2015 at 10:51 AM, Nir Simionovich 
 nir.simionov...@gmail.com wrote:

 Ok, I'll have a look into that one.

 On Sun, Mar 8, 2015 at 1:03 PM, Olle E. Johansson o...@edvina.net wrote:


 On 08 Mar 2015, at 09:52, Nir Simionovich nir.simionov...@gmail.com
 wrote:

  Hi All,
 
So, I've been banging my head against an issue with ARI. While
 Channel Originate enables
  you to originate channels, you can't really do a SIPAddHeader type
 functionality in there.
 
Originally, I was under impression that endpoints/message should be
 able to give me the functionality I wanted, but it didn't.
 
So, I realized that the functionality I'm looking for doesn't really
 exist.
 
Question, are we missing a feature here? or is there an alternative
 method of achieving the
  same functionality?
 If you can add channel variables, you can add SIP headers.
 Look at a dump of the channel after you executed SIPaddheader to figure
 out how it works.
 Add two headers, and run dumpchan().


 You should be able to do it with just the channel variable SIPADDHEADER,
 that is:

 SIPADDHEADER=X-CustomHeader-1: foo
 SIPADDHEADER=X-CustomHeader-2: bar

 These can be specified in the /channels operation's JSON body.

 WIth chan_pjsip, headers are manipulated using a dialplan function, so
 there shouldn't be any issue there.

 --
 Matthew Jordan
 Digium, Inc. | Director of Technology
 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
 Check us out at: http://digium.com  http://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

-- 
_
-- 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] ARI - Add Support for custom SIP Headers with Originate

2015-03-08 Thread Nir Simionovich

Hi All,

  So, I've been banging my head against an issue with ARI. While Channel
Originate enables
you to originate channels, you can't really do a SIPAddHeader type
functionality in there.

  Originally, I was under impression that endpoints/message should be able
to give me the functionality I wanted, but it didn't.

  So, I realized that the functionality I'm looking for doesn't really
exist.

  Question, are we missing a feature here? or is there an alternative
method of achieving the
same functionality?

Regards,
  Nir S
-- 
_
-- 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] ARI - Add Support for custom SIP Headers with Originate

2015-03-08 Thread Nir Simionovich

Ok, I'll have a look into that one.

On Sun, Mar 8, 2015 at 1:03 PM, Olle E. Johansson o...@edvina.net wrote:


 On 08 Mar 2015, at 09:52, Nir Simionovich nir.simionov...@gmail.com
 wrote:

  Hi All,
 
So, I've been banging my head against an issue with ARI. While Channel
 Originate enables
  you to originate channels, you can't really do a SIPAddHeader type
 functionality in there.
 
Originally, I was under impression that endpoints/message should be
 able to give me the functionality I wanted, but it didn't.
 
So, I realized that the functionality I'm looking for doesn't really
 exist.
 
Question, are we missing a feature here? or is there an alternative
 method of achieving the
  same functionality?
 If you can add channel variables, you can add SIP headers.
 Look at a dump of the channel after you executed SIPaddheader to figure
 out how it works.
 Add two headers, and run dumpchan().

 /O


 --
 _
 -- 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] PHPARI app_dial re-implementation

2015-02-05 Thread Nir Simionovich

Hi All,

  I've managed to re-implement the basic functionality of app_dial using
ARI and PHPARI.
I've tested it and it supports handling of multiple calls at the same time.
Having said that,
I would highly appreciate some feedback in regards to the methodology, or
if anybody
can see something I can't.

  You can find the information here:

http://www.phpari.org/documentation/app_dial-re-implemented-using-phpari/

  And soon to be added to the 0.3 release of phpari.

Regards,
  Nir S
-- 
_
-- 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] OFF TOPIC: GitHub vs. BitBucket vs. GitLab

2015-01-18 Thread Nir Simionovich

Hi all,

  This is somewhat of an off topic discussion, however, I'm putting it here
- as most of your have more experience than me when it comes to using git.

  So, we've been using GitHub for a year now as our Git repository and are
fairly happy with it. At the same time, we're using BitBucket for some of
our projects, specifically those who are not of Open Source nature.

  Recently, I've become frustrated with both platforms - specifically when
it comes to managing code within teams - specifically when code reviews are
required from multiple entry points - code review becomes longer than
actual coding.

  So, I was wondering what you guys are using and working with? You are
welcome to answer this off-list, but I do believe that some of us may
benefit from the discussion.

Nir
-- 
_
-- 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] ARI Stasis Application Examples and Tutorials

2014-12-22 Thread Nir Simionovich

Hi All,

  I'm not sure if the dev list is the proper list of this, however, due to
the fact that the issue at hand
revolves around documentation and proper usage, I think bringing it up here
is a good place.

  So, during the past few days, I've been trying to implement the Dial
application using ARI. So,
I'm aware I'm not the only one, but I'm the one trying to do it using
PHPARI - naturally.

  In any case, I managed to write the functionality - reaching an issue
where if I disconnect the
first bridge handled by the stasis app, it will kill all the other bridges
as well. I was wondering why
that happens. I then realized that part of the my stasis loop
implementation is just wrong, and it's
not because PHPARI is wrong, or ARI is wrong - it's wrong because it is a
WebSocket client.

  A stasis application, at least as I understand it - is a websocket client
- or consumer in that
respect. However, our consumer application is required to be able to handle
multiple sessions,
so, it now needs to be stateful on one hand, and 'multi-threaded' on the
other. The result is that
our 'client' application is actually a server in disguise.

  This is something that the ARI documentation and general usage concepts
is missing - I think
that we need to make ARI more accessible by explaining the basic concepts
better.

  Another thing, yesterday Scott and I were going through Matt's example of
the bridge_dial ARI
application. The fact that the ari-py is autogenerated makes it really hard
for a none-python (yours
truly) guy to follow along. Even Scott, who is fluent in Python had a bit
of trouble looking through the
logic of the app, specifically when seeing that a certain event overloads
an existing one - and some
other stuff that ari-py does.

  In other words, if we want to deprecate AGI/AMI at some point - or for a
better term, get people to
use ARI extensively - we need better examples. I'm working on adding
additional examples to PHPARI
for this, but we need simple, to the point, usage examples for ARI. For
example, examples that don't
go about and do something funky in the background, so that people can truly
learn from it.

  When I started with AGI and AMI, the one thing I liked was that I could
use BASH. ARI isn't such a thing,
and a WebSocket library is mandatory. But giving some basic concepts using
only that, would be
awesome.

  What do you think?

Nir
-- 
_
-- 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] git migration update

2014-12-22 Thread Nir Simionovich

+1 from me as well.

We use the methodology of using personalized repos for projects and it
works really well. We use either GitHub
or BitBucket, depending on the project - but both work equally well.

I'm confident that Atlassian will be happy to show their support by
contributing a Stash license to the project,
and you'll get the same functionality of BitBucket on a dedicated server -
if you don't want to host the project
publicly.



On Tue, Dec 23, 2014 at 1:34 AM, Russell Bryant russ...@russellbryant.net
wrote:

 On Mon, Dec 22, 2014 at 3:08 PM, George Joseph 
 george.jos...@fairview5.com wrote:

 On Mon, Dec 22, 2014 at 12:03 PM, Samuel Galarneau sgalarn...@digium.com
  wrote:

 2 - we have a few options as far as team branches go. We could configure
 user branches using refs/heads/team/${username}/* permissions in Gerrit to
 allow users to create branches. This would prohibit other users from
 pushing to a user branch, but they would still be visible. This would most
 likely involve reproducing some sort of automerge/autorebase process. The
 other option is to use github as another remote for team branches, with a
 remote pointing to Gerrit for code reviews. Is there a preference between
 these two approaches, or perhaps a better setup we could follow?


 I don't think there's any need for you to host users' repos any more.
 It may have made sense for SVN but I don't think it does for GIT.  Let
 users make their own arrangements be it GitHub or in my case, my own GIT
 infrastructure.


 +1.  I don't think it makes sense with git.  github or whatever should
 work just fine for that purpose.

 --
 Russell Bryant

 --
 _
 -- 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

Re: [asterisk-dev] ARI Extending Existing Feature: bridge control

2014-12-18 Thread Nir Simionovich

Sorry, previous sample was wrong, here is a more accurate sample:

T 178.62.127.227:44972 - 178.62.127.227:8088 [AP]
POST /ari/channels/participant HTTP/1.1.
Authorization: Basic dGVzdDp0ZXN0.
Host: 178.62.127.227:8088.
Content-Length: 31.
Accept: application/json.
Content-Type: application/json.
.
{endpoint:Local\/1000@demo}

T 178.62.127.227:8088 - 178.62.127.227:44972 [AP]
HTTP/1.1 400 Bad Request.
Server: Asterisk/SVN-trunk-r429683M.
Date: Thu, 18 Dec 2014 07:59:34 GMT.
Cache-Control: no-cache, no-store.
Content-type: application/json.
Content-Length: 61.
.


T 178.62.127.227:8088 - 178.62.127.227:44972 [AP]
{
  message: Application or extension must be specified
}


On Thu, Dec 18, 2014 at 9:48 AM, Nir Simionovich nir.simionov...@gmail.com
wrote:

 One more thing - per your recommendations, I'm trying to re-implement
 app_dial using ARI.

 Now, if I read you all right, the process should be:

 1. Get a call into Asterisk from an external phone
 2. Create a new bridge
 3. Put the call into the newly created bridge
 4. Originate a new call
 5. Put the new call into the existing bridge

 So, 1,2,3 work just fine - then you get to 4. According to the docs, I can
 originate a channel with only the endpoint defined.
 However, that doesn't seem to work:

 T 178.62.127.227:44938 - 178.62.127.227:8088 [AP]
 POST /ari/channels HTTP/1.1.
 Authorization: Basic dGVzdDp0ZXN0.
 Host: 178.62.127.227:8088.
 Content-Length: 85.
 Accept: application/json.
 Content-Type: application/json.
 .
 {endpoint:Local\/1000@demo
 ,channelId:participant,variables:{var1:var1}}

 T 178.62.127.227:8088 - 178.62.127.227:44938 [AP]
 HTTP/1.1 400 Bad Request.
 Server: Asterisk/SVN-trunk-r429683M.
 Date: Thu, 18 Dec 2014 07:41:59 GMT.
 Cache-Control: no-cache, no-store.
 Content-type: application/json.
 Content-Length: 61.
 .


 T 178.62.127.227:8088 - 178.62.127.227:44938 [AP]
 {
   message: Application or extension must be specified
 }

 Am I missing something here? or is this a bug?



 On Thu, Dec 18, 2014 at 8:59 AM, Nir Simionovich 
 nir.simionov...@gmail.com wrote:

 I see your point now - that makes more sense. It was fairly clear to me
 that ast_bridge_config is somewhat of a legacy data structure,
 but I was assuming that in some respect it was used in ARI as well. What
 your actually saying is that ARI bypasses all of the legacy
 stuff and interacts directly with the bridge core, and that's why it
 doesn't support that data structure. So technically, accessing bridge
 configuration for a Legacy (Dial, Queue, FollowMe) is a fairly complex
 task, as they don't see the same information space.

 This now raises a slightly off-topic discussion - wouldn't it beneficial
 to provide some form of ARI access to some of the legacy stuff
 as well? On one hand, we don't really want to do that - as we're trying
 to push people into proper usage of ARI and Asterisk, however,
 my heart goes out to the legacy stuff, that if we don't cater to, will
 become a caveat.

 I will explain. About 6 years I've built a large scale Asterisk based
 dialer for a customer. When I say large scale, I meant humongous
 in 2008 terms - 2500 concurrent calls. Now, that dialer relied heavily on
 AMI (of course) and AGI. It was originally built on Asterisk 1.6.
 Recently, the customer came back to me, asking me to upgrade their system
 to Asterisk 11, specifically for security reasons. I then
 looked at the code, realizing that the customer had wrote some stuff
 using MeetMe and some of the deprecated app_queue stuff.
 I indicated to them that their legacy code should be migrated as well.
 Customer looked at it, realized that apart from upgrading Asterisk,
 they will have about 6 months worth of coding to migrate their stuff to
 the new constructs - the entire project caved. We just upgraded
 to latest version of the 1.6 branch, and the customer is now evaluating
 1.8 - in other words, not supporting the legacy stuff in some
 respect will at some point bite us in the ass.

 I realize this is very much a leadership question, not a technical nor
 operational.

 New question: Do we want to enable legacy features inside ARI?

 Nir

 On Thu, Dec 18, 2014 at 1:26 AM, Mark Michelson mmichel...@digium.com
 wrote:

  On 12/17/2014 05:01 PM, Nir Simionovich wrote:

 snip

  Let's try to stick to the tech for now and answer the first two
 questions:

1. Is there a way to obtain the information in ast_bridge_config for
 each of the iterated bridges?


 ast_bridge_config is not used at all for Stasis bridges.
 ast_bridge_config describes bridge features that basic bridges use based on
 Dial(), Queue(), and FollowMe() features. For instance, when Dial is called
 with the 't' and 'T' options, the ast_bridge_config indicates that the
 caller and callee can perform DTMF transfers based on features.conf
 settings.

 For Stasis bridges, the idea of using ast_bridge_config does not make
 sense for several reasons

 1) Stasis applications are intended to be fully in control

Re: [asterisk-dev] ARI Extending Existing Feature: bridge control

2014-12-18 Thread Nir Simionovich

In deed, that is interesting - but truly stirs away from ARI - not
something that I'm trying to do.

On Thu, Dec 18, 2014 at 1:00 PM, Kaloyan Kovachev kkovac...@varna.net
wrote:

 Hi,

 On 2014-12-18 01:01, Nir Simionovich wrote:

  Let's try to stick to the tech for now and answer the first two questions:

 1. Is there a way to obtain the information in ast_bridge_config for each
 of the iterated bridges?
 2. Is there a way to manipulate the configuration of the bridge, via
 modifying the associated bridge configuration in real time?

 Nir


 You may take a look at my old RTCC patch for Dial() [1]:
 In the last version [2] I have ended with adding the bridge_config and
 both channels to a data store, which is accessed from a scheduled callback
 and modifies the call limit.
 Once you have the data store attached to the channel it is easy to access
 it from a hook or another thread/app

 [1] https://issues.asterisk.org/jira/browse/ASTERISK-6175
 [2] https://issues.asterisk.org/jira/secure/attachment/40666/
 rtcc_trunk_327742.diff


 --
 _
 -- 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

Re: [asterisk-dev] ARI Extending Existing Feature: bridge control

2014-12-18 Thread Nir Simionovich

Ahh...

On Thu, Dec 18, 2014 at 1:32 PM, Kaloyan Kovachev kkovac...@varna.net
wrote:

 I meant that for accessing bridge configuration for a Legacy (Dial,
 Queue, FollowMe) from your other email

 On 2014-12-18 13:26, Nir Simionovich wrote:

  In deed, that is interesting - but truly stirs away from ARI - not
 something that I'm trying to do.

 On Thu, Dec 18, 2014 at 1:00 PM, Kaloyan Kovachev kkovac...@varna.netwrote:
 Hi,

 On 2014-12-18 01:01, Nir Simionovich wrote:

 Let's try to stick to the tech for now and answer the first two questions:

 1. Is there a way to obtain the information in ast_bridge_config for each
 of the iterated bridges?
 2. Is there a way to manipulate the configuration of the bridge, via
 modifying the associated bridge configuration in real time?

 Nir You may take a look at my old RTCC patch for Dial() [1]:
 In the last version [2] I have ended with adding the bridge_config and
 both channels to a data store, which is accessed from a scheduled callback
 and modifies the call limit.
 Once you have the data store attached to the channel it is easy to access
 it from a hook or another thread/app

 [1] https://issues.asterisk.org/jira/browse/ASTERISK-6175 [1]
 [2] https://issues.asterisk.org/jira/secure/attachment/40666/
 rtcc_trunk_327742.diff [2]

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

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




 Links:
 --
 [1] https://issues.asterisk.org/jira/browse/ASTERISK-6175
 [2] https://issues.asterisk.org/jira/secure/attachment/40666/
 rtcc_trunk_327742.diff
 [3] http://www.api-digital.com
 [4] 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

-- 
_
-- 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] ARI Extending Existing Feature: bridge control

2014-12-18 Thread Nir Simionovich

Now, this is why I love Open Source - opinions, thoughts and most
importantly, acceptance.

I can totally see where the general idea is going here, and that is what we
all agreed during AstriDevCon this year.


On Thu, Dec 18, 2014 at 6:31 PM, Leif Madsen lmad...@thinkingphones.com
wrote:

 On 18 December 2014 at 11:07, Paul Belanger paul.belan...@polybeacon.com
 wrote:

 On Thu, Dec 18, 2014 at 1:59 AM, Nir Simionovich
 nir.simionov...@gmail.com wrote:
  New question: Do we want to enable legacy features inside ARI?
 
 New answer: I don't believe so.

 I think this issue / question is the hardest thing to understand about
 ARI.  There really isn't any sort of link to existing Asterisk
 application or features; not yet any ways.  Somebody has to build it
 again a top of ARI.

 When I first dreamed of using ARI I was looking at it from a
 configuration management tool mindset.  Oh, I could create a new peer
 in chan_sip over HTTP or let me reconfigure features.conf using ARI.
 However, as I started playing with it more I found that was not what
 it did.  And, changing it to do something like that doesn't feel like
 the right approach.

 Now, that being said. Creating some sort of interface to control
 sorcery objects, now that would be cool.  Having sorcery connect to
 redis and change key / values directly in redis for sip peers would be
 hotness.  However, I'm not sure I would want to have Asterisk serve up
 that interface directly.  Feels more like an external application
 would serve up the REST interface into redis, allowing the user to
 change key/pairs.

 I also believe, until there are some standard ARI libraries /
 application (for example app_dial replacement). It will feel like a
 large task to build anything in ARI, because some of the core
 application basically need to be written from scratch.  And I think
 this is the main reason people are slow to move to ARI or fearful from
 dropping the dialplan.  Because doing:

 exten = s,1,NoOp()
 same = n,Dial(SIP/f...@example.org)

 is a lot easier then origination a channel over ARI, creating bridges
 and playing any tones needed using ARI.  Easier might not be the right
 work, more steps required is.


 I also agree that we do not want to start making ARI start talking to
 legacy applications.

 As discussed at AstriDevCon, the push is really to start making Asterisk a
 media communications platform. The way to do that is to move away from the
 dialplan centric driven applications and to move to a decentralized model
 of applications and business logic being separated from Asterisk, and
 essentially making Asterisk much dumber in terms of the actual business
 logic and routing logic, and making it a lean mean media communications
 machine. The way forward sometimes is to stop looking back.

 Currently both AMI and AGI are still happily co-existant in Asterisk, and
 should be considered the defacto interface to traditional methods of
 writing Asterisk business logic (dialplan, etc). When flipping to ARI, it
 is a different mind set that does take some time to get around. Much like
 Paul I had my own preconceived notions about what ARI was and was initially
 disappointed it didn't match what I thought it should have been. However
 over the last few months of watching what Paul has been doing along with
 some small side POC stuff to better understand what ARI is intended for, it
 definitely has become a lot clearer.

 At the most basic levels, ARI to me is a bridge control interface that
 allows you to hook channels together while not worrying about transcoding,
 media characteristics etc. You have two or more channels that may or may
 not speak the same language, and your external applications stick them
 together, and Asterisk acts as the universal translator for those channels.
 By writing all your business logic and controls outside of Asterisk, it
 makes the API much simpler to interoperate with, and allows great scaling
 possibilities.

 Admittedly I'm still a bit naive on a lot of the ARI front, but one thing
 my gut tells me, is it is a new interface, and should not be confused as a
 replacement to the legacy (term used loosely) methods of building Asterisk
 systems. This is one of those situations that I feel avoiding legacy and
 backwards compatibility with the traditional methods is going to really
 open up a better realm of possibilities with ARI. If someone truly just
 needs an HTTP based interface for controlling dialplan and such, I feel a
 translation application (library) should just be written for AMI and AGI
 that permits that and has that goal. Overloading what ARI is supposed to be
 doing is a step backwards in my opinion.

 --
 Leif The Dialplan Is Dead Madsen

 --
 _
 -- 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

Re: [asterisk-dev] ARI Extending Existing Feature: bridge control

2014-12-18 Thread Nir Simionovich

Matt,

  I think your entire email should be put on the wiki, maybe not in its
current format, but the contents are imperative
for the future. This is actually the first ever detailed explanation I've
ever read as to why ARI shouldn't do all sorts
of things - which from an external (none core developer) point of view -
would seem reasonable.



On Thu, Dec 18, 2014 at 8:38 PM, Matthew Jordan mjor...@digium.com wrote:



 On Thu, Dec 18, 2014 at 10:31 AM, Leif Madsen lmad...@thinkingphones.com
 wrote:
  On 18 December 2014 at 11:07, Paul Belanger 
 paul.belan...@polybeacon.com
  wrote:
 
  On Thu, Dec 18, 2014 at 1:59 AM, Nir Simionovich
  nir.simionov...@gmail.com wrote:
   New question: Do we want to enable legacy features inside ARI?
  
  New answer: I don't believe so.
 
  I think this issue / question is the hardest thing to understand about
  ARI.  There really isn't any sort of link to existing Asterisk
  application or features; not yet any ways.  Somebody has to build it
  again a top of ARI.
 
  When I first dreamed of using ARI I was looking at it from a
  configuration management tool mindset.  Oh, I could create a new peer
  in chan_sip over HTTP or let me reconfigure features.conf using ARI.
  However, as I started playing with it more I found that was not what
  it did.  And, changing it to do something like that doesn't feel like
  the right approach.
 
  Now, that being said. Creating some sort of interface to control
  sorcery objects, now that would be cool.  Having sorcery connect to
  redis and change key / values directly in redis for sip peers would be
  hotness.  However, I'm not sure I would want to have Asterisk serve up
  that interface directly.  Feels more like an external application
  would serve up the REST interface into redis, allowing the user to
  change key/pairs.
 
  I also believe, until there are some standard ARI libraries /
  application (for example app_dial replacement). It will feel like a
  large task to build anything in ARI, because some of the core
  application basically need to be written from scratch.  And I think
  this is the main reason people are slow to move to ARI or fearful from
  dropping the dialplan.  Because doing:
 
  exten = s,1,NoOp()
  same = n,Dial(SIP/f...@example.org)
 
  is a lot easier then origination a channel over ARI, creating bridges
  and playing any tones needed using ARI.  Easier might not be the right
  work, more steps required is.
 
 
  I also agree that we do not want to start making ARI start talking to
 legacy
  applications.
 
  As discussed at AstriDevCon, the push is really to start making Asterisk
 a
  media communications platform. The way to do that is to move away from
 the
  dialplan centric driven applications and to move to a decentralized
 model of
  applications and business logic being separated from Asterisk, and
  essentially making Asterisk much dumber in terms of the actual business
  logic and routing logic, and making it a lean mean media communications
  machine. The way forward sometimes is to stop looking back.
 
  Currently both AMI and AGI are still happily co-existant in Asterisk, and
  should be considered the defacto interface to traditional methods of
 writing
  Asterisk business logic (dialplan, etc). When flipping to ARI, it is a
  different mind set that does take some time to get around. Much like
 Paul I
  had my own preconceived notions about what ARI was and was initially
  disappointed it didn't match what I thought it should have been. However
  over the last few months of watching what Paul has been doing along with
  some small side POC stuff to better understand what ARI is intended for,
 it
  definitely has become a lot clearer.
 
  At the most basic levels, ARI to me is a bridge control interface that
  allows you to hook channels together while not worrying about
 transcoding,
  media characteristics etc. You have two or more channels that may or may
 not
  speak the same language, and your external applications stick them
 together,
  and Asterisk acts as the universal translator for those channels. By
 writing
  all your business logic and controls outside of Asterisk, it makes the
 API
  much simpler to interoperate with, and allows great scaling
 possibilities.
 
  Admittedly I'm still a bit naive on a lot of the ARI front, but one
 thing my
  gut tells me, is it is a new interface, and should not be confused as a
  replacement to the legacy (term used loosely) methods of building
 Asterisk
  systems. This is one of those situations that I feel avoiding legacy and
  backwards compatibility with the traditional methods is going to really
 open
  up a better realm of possibilities with ARI. If someone truly just needs
 an
  HTTP based interface for controlling dialplan and such, I feel a
 translation
  application (library) should just be written for AMI and AGI that permits
  that and has that goal. Overloading what ARI is supposed to be doing is a
  step backwards in my

[asterisk-dev] ARI Extending Existing Feature: bridge control

2014-12-17 Thread Nir Simionovich

Hi All,

After shipping out my first patch to ARI, I became hungry :-)

So, now I've set up a slightly higher goal, adding a much required
feature for ARI. I'll describe the problem first, then
I have some questions.

The Asterisk dial application enables us to limit the duration of the
call and play a warning sound. Once this had been
set, as far as I know, you can't modify these values externally. When the
feature was originally introduced, over 10 years
ago, the goal was simple: enable a calling card system to limit the call
according to a credit line.

As time went by, people realized that this feature is useful, however
limited. In today's mobile application era, when a
VoIP phone can actually purchase credit while on the actual call, we need a
way to control this from an external source.

Now, I've started digging into the code, and I've managed to understand
that following (feel free to bash me if I'm wrong):

1. The time limits are maintained at the bridge structure, not at the
channel - using the ast_bridge_config data structure
2. The ARI bridges GET method only retrieves a list of bridges and their
associated channels, not their configurations

So, assuming that I'm reading the ast_ari_bridges_list
http://doxygen.asterisk.org/trunk/db/d0b/resource__bridges_8c.html#f456b35967dc37f869de264ee800f2b8
function
from resouce_bridges.c correctly, we retrieve
a snapshot of all active bridges via the snapshots variable (if you can
call it that). The output is built by iterating through it.

Now, my questions:

1. Is there a way to obtain the information in ast_bridge_config for each
of the iterated bridges, then output it via the JSON response?
2. Is there a way to manipulate the configuration of the bridge, via
modifying the associated bridge configuration?

The floor is now open :-)

Nir S
--
_
-- 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] ARI Extending Existing Feature: bridge control

2014-12-17 Thread Nir Simionovich

Well,

  In simple words yes. To be more specific, I'd like to do something like
this:

1. Have a simple dialplan that will dialout using the L parameter in Dial
application
2. Have ARI bridge list function retrieve not only the list of active
bridges, but also their allocated duration timers - if assigned
3. Provide a means via ARI to manipulate the duration timers

Nir

On Wed, Dec 17, 2014 at 10:37 PM, Paul Belanger 
paul.belan...@polybeacon.com wrote:

 On Wed, Dec 17, 2014 at 3:16 PM, Nir Simionovich
 nir.simionov...@gmail.com wrote:
  Hi All,
 
After shipping out my first patch to ARI, I became hungry :-)
 
So, now I've set up a slightly higher goal, adding a much required
 feature
  for ARI. I'll describe the problem first, then
  I have some questions.
 
The Asterisk dial application enables us to limit the duration of the
 call
  and play a warning sound. Once this had been
  set, as far as I know, you can't modify these values externally. When the
  feature was originally introduced, over 10 years
  ago, the goal was simple: enable a calling card system to limit the call
  according to a credit line.
 
As time went by, people realized that this feature is useful, however
  limited. In today's mobile application era, when a
  VoIP phone can actually purchase credit while on the actual call, we
 need a
  way to control this from an external source.
 
Now, I've started digging into the code, and I've managed to understand
  that following (feel free to bash me if I'm wrong):
 
1. The time limits are maintained at the bridge structure, not at the
  channel - using the ast_bridge_config data structure
2. The ARI bridges GET method only retrieves a list of bridges and
 their
  associated channels, not their configurations
 
So, assuming that I'm reading the ast_ari_bridges_list function from
  resouce_bridges.c correctly, we retrieve
  a snapshot of all active bridges via the snapshots variable (if you can
 call
  it that). The output is built by iterating through it.
 
Now, my questions:
 
1. Is there a way to obtain the information in ast_bridge_config for
 each
  of the iterated bridges, then output it via the JSON response?
2. Is there a way to manipulate the configuration of the bridge, via
  modifying the associated bridge configuration?
 
The floor is now open :-)
 
 I am a little confused what you are asking.  You want to add some sort
 of lifetime support to bridge within asterisk, using ARI?

 --
 Paul Belanger | PolyBeacon, Inc.
 Jabber: paul.belan...@polybeacon.com | IRC: pabelanger (Freenode)
 Github: https://github.com/pabelanger | Twitter:
 https://twitter.com/pabelanger

 --
 _
 -- 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

Re: [asterisk-dev] ARI Extending Existing Feature: bridge control

2014-12-17 Thread Nir Simionovich

Ok, I'll start with this - I agree with the both of you, ARI is the right
way to go.

However, when I look at ARI, I see somewhat of a Hybrid. When I say hybrid
I mean, a tool that enables me to do stuff,
both inside and outside of the Stasis construct. Example, ARI provides a
channels API, enabling you to originate a call.
If ARI was only about stasis, why did we enable the classic
application/extension, we could have easily just said: oh,
originate the call and dump it into a Stasis app - but that didn't happen.
Instead, you put the call into a dialplan or an application,
which in turn, will call the Stasis app (if truly required).

My point is this, if the ability exists and can be added, why not? It
doesn't break anything that's already in there, it adds much
needed functionality and it makes ARI richer in comparison to its
predecessor AMI, which people still have a hard time figuring
out why they should move to ARI.

This kind of feature can be a tipping point.

My 2c on the matter.



On Wed, Dec 17, 2014 at 11:04 PM, Phil Mickelson p...@cbasoftware.com
wrote:

 I agree with Paul 100%.  Given my experience with ARI over the last year
 and how easy it is to create these apps I would think you could avoid the
 dialplan completely and easily create a routine to do exactly what you want.

 1.  You would know when the call started and was connected.
 2.  You can easily play a sound, any sound, to either end of the
 connection or to both.
 3.  You can disconnect the call when you want.
 4.  I'm not sure given your requirements but you could even allow the
 caller (or callee) to put funds in their account to allow for more time.

 ARI is the way to go!  IMHO.

 Phil M


 On Wed, Dec 17, 2014 at 3:58 PM, Paul Belanger 
 paul.belan...@polybeacon.com wrote:

 On Wed, Dec 17, 2014 at 3:46 PM, Nir Simionovich
 nir.simionov...@gmail.com wrote:
  Well,
 
In simple words yes. To be more specific, I'd like to do something
 like
  this:
 
  1. Have a simple dialplan that will dialout using the L parameter in
 Dial
  application
  2. Have ARI bridge list function retrieve not only the list of active
  bridges, but also their allocated duration timers - if assigned
  3. Provide a means via ARI to manipulate the duration timers
 
 Correct me if I am wrong, but I don't think this will work.  Any
 bridge or channel from your dialplan would not be controlled by
 stasis.  And since it is not in stasis, ARI cannot modify it. I think
 the general idea was to build a new app_dial atop of ARI, then your
 application would provide that functionality to control the L
 parameter.

 --
 Paul Belanger | PolyBeacon, Inc.
 Jabber: paul.belan...@polybeacon.com | IRC: pabelanger (Freenode)
 Github: https://github.com/pabelanger | Twitter:
 https://twitter.com/pabelanger

 --
 _
 -- 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

-- 
_
-- 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] ARI Extending Existing Feature: bridge control

2014-12-17 Thread Nir Simionovich

Phil,

  It is one thing to say: I'm interested in advancement, it is completely
a different thing to say: I don't give a damn about backward
compatibility.

  Asterisk is a huge community around the world, shifting the community
from one methodology of thought to another takes time. During that time
of transition, we must think about the fact that some (if not many) will
still stick to the old ways.

  For example, it took over 3 years to deprecate app_meetme - do you
honestly believe it will take the same time to deprecate app_dial? I
suspect
that the answer will be - app_dial will always be there. We may not like
it, but still, it is the simplest way of getting a call out of Asterisk.
Like it or not,
the dialplan will still be here, even 5 years or 10 years from now - it's
the most basic form. In the mean time, we must provide functionality and
robustness - if we don't, we'll become irrelevant.



On Wed, Dec 17, 2014 at 11:16 PM, Phil Mickelson p...@cbasoftware.com
wrote:

 Nir, I agree with you about wondering why does the call go through the
 dialplan.  Perhaps someone could answer that?  Or, perhaps give us some
 idea if this will change?

 In my case, the connection to the dialplan is literally three lines.  The
 minimum required.  I never return.

 Phil M


 On Wed, Dec 17, 2014 at 4:12 PM, Nir Simionovich 
 nir.simionov...@gmail.com wrote:

 Ok, I'll start with this - I agree with the both of you, ARI is the right
 way to go.

 However, when I look at ARI, I see somewhat of a Hybrid. When I say
 hybrid I mean, a tool that enables me to do stuff,
 both inside and outside of the Stasis construct. Example, ARI provides a
 channels API, enabling you to originate a call.
 If ARI was only about stasis, why did we enable the classic
 application/extension, we could have easily just said: oh,
 originate the call and dump it into a Stasis app - but that didn't
 happen. Instead, you put the call into a dialplan or an application,
 which in turn, will call the Stasis app (if truly required).

 My point is this, if the ability exists and can be added, why not? It
 doesn't break anything that's already in there, it adds much
 needed functionality and it makes ARI richer in comparison to its
 predecessor AMI, which people still have a hard time figuring
 out why they should move to ARI.

 This kind of feature can be a tipping point.

 My 2c on the matter.



 On Wed, Dec 17, 2014 at 11:04 PM, Phil Mickelson p...@cbasoftware.com
 wrote:

 I agree with Paul 100%.  Given my experience with ARI over the last year
 and how easy it is to create these apps I would think you could avoid the
 dialplan completely and easily create a routine to do exactly what you want.

 1.  You would know when the call started and was connected.
 2.  You can easily play a sound, any sound, to either end of the
 connection or to both.
 3.  You can disconnect the call when you want.
 4.  I'm not sure given your requirements but you could even allow the
 caller (or callee) to put funds in their account to allow for more time.

 ARI is the way to go!  IMHO.

 Phil M


 On Wed, Dec 17, 2014 at 3:58 PM, Paul Belanger 
 paul.belan...@polybeacon.com wrote:

 On Wed, Dec 17, 2014 at 3:46 PM, Nir Simionovich
 nir.simionov...@gmail.com wrote:
  Well,
 
In simple words yes. To be more specific, I'd like to do something
 like
  this:
 
  1. Have a simple dialplan that will dialout using the L parameter in
 Dial
  application
  2. Have ARI bridge list function retrieve not only the list of active
  bridges, but also their allocated duration timers - if assigned
  3. Provide a means via ARI to manipulate the duration timers
 
 Correct me if I am wrong, but I don't think this will work.  Any
 bridge or channel from your dialplan would not be controlled by
 stasis.  And since it is not in stasis, ARI cannot modify it. I think
 the general idea was to build a new app_dial atop of ARI, then your
 application would provide that functionality to control the L
 parameter.

 --
 Paul Belanger | PolyBeacon, Inc.
 Jabber: paul.belan...@polybeacon.com | IRC: pabelanger (Freenode)
 Github: https://github.com/pabelanger | Twitter:
 https://twitter.com/pabelanger

 --
 _
 -- 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


 --
 _
 -- 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

Re: [asterisk-dev] ARI Extending Existing Feature: bridge control

2014-12-17 Thread Nir Simionovich

While I agree with the both of you - I still don't see a reason why not to
do it.

I'll tell you how I see it - I'm looking at this kind of feature from a
cost/performance/benefit ratio.

Does this kind of feature enable a new benefit that didn't exist previously
- yes.
Does it impact the overall performance of Asterisk - probably not.
Is it a low hanging fruit to develop? - I can't answer that yet
Would it take a longer time to develop a bridge manager externally, or
develop the feature? - I can't answer that yet

Currently, I'm trying to evaluate the task - from a
technical/operational/financial reasoning. If Tech/Ops make sense,
but Finance doesn't - it ain't worth doing.

Let's try and discuss for a minute what it would actually take in order to
do this, instead of debating
if we should or shouldn't.

Yes, maybe you'll say - in order to do this, you'll need to do 1, 2, 3, 4
 - and maybe I'll: cool, I'll have a go
at it, and maybe it will go in, and maybe it will not - but that's open
source. Open Source means, we work collaboratively,
we explore things and keep our minds open to ideas and suggestions.

When Leonid and I created PHPARI about 4 months ago, we created it out of a
need for a proper wrapper that
will fit nicely into our projects. I'm currently aware of 10 different
people using it in production - and some of them
already contributed code and structural changes to it. One of the things
people asked us for an OAuth based
ARI proxy, because they like using tokens. Does ARI truly need something
like that - not really. Does ARI
need better security - for sure. Will we shot down the idea down? not at
this point. We first examine what it will
take to do it, technically, then financially - then we decide.

Damn, this is turning into another theological discussion - not really to
be part of this list.

Let's try to stick to the tech for now and answer the first two questions:

  1. Is there a way to obtain the information in ast_bridge_config for each
of the iterated bridges?
  2. Is there a way to manipulate the configuration of the bridge, via
modifying the associated bridge configuration in real time?

Nir

On Thu, Dec 18, 2014 at 12:33 AM, Phil Mickelson p...@cbasoftware.com
wrote:

 Nir,

 I don't disagree with you at all.  All I'd like is another way.  The
 current methods don't have to disappear.  It's not either or.  However,
 there's also no reason not to explore new methods, is there?

 Phil M

 On Wed, Dec 17, 2014 at 5:29 PM, Nir Simionovich 
 nir.simionov...@gmail.com wrote:

 Phil,

   It is one thing to say: I'm interested in advancement, it is
 completely a different thing to say: I don't give a damn about backward
 compatibility.

   Asterisk is a huge community around the world, shifting the community
 from one methodology of thought to another takes time. During that time
 of transition, we must think about the fact that some (if not many) will
 still stick to the old ways.

   For example, it took over 3 years to deprecate app_meetme - do you
 honestly believe it will take the same time to deprecate app_dial? I
 suspect
 that the answer will be - app_dial will always be there. We may not like
 it, but still, it is the simplest way of getting a call out of Asterisk.
 Like it or not,
 the dialplan will still be here, even 5 years or 10 years from now - it's
 the most basic form. In the mean time, we must provide functionality and
 robustness - if we don't, we'll become irrelevant.



 On Wed, Dec 17, 2014 at 11:16 PM, Phil Mickelson p...@cbasoftware.com
 wrote:

 Nir, I agree with you about wondering why does the call go through the
 dialplan.  Perhaps someone could answer that?  Or, perhaps give us some
 idea if this will change?

 In my case, the connection to the dialplan is literally three lines.
 The minimum required.  I never return.

 Phil M


 On Wed, Dec 17, 2014 at 4:12 PM, Nir Simionovich 
 nir.simionov...@gmail.com wrote:

 Ok, I'll start with this - I agree with the both of you, ARI is the
 right way to go.

 However, when I look at ARI, I see somewhat of a Hybrid. When I say
 hybrid I mean, a tool that enables me to do stuff,
 both inside and outside of the Stasis construct. Example, ARI provides
 a channels API, enabling you to originate a call.
 If ARI was only about stasis, why did we enable the classic
 application/extension, we could have easily just said: oh,
 originate the call and dump it into a Stasis app - but that didn't
 happen. Instead, you put the call into a dialplan or an application,
 which in turn, will call the Stasis app (if truly required).

 My point is this, if the ability exists and can be added, why not? It
 doesn't break anything that's already in there, it adds much
 needed functionality and it makes ARI richer in comparison to its
 predecessor AMI, which people still have a hard time figuring
 out why they should move to ARI.

 This kind of feature can be a tipping point.

 My 2c on the matter.



 On Wed, Dec 17, 2014 at 11:04 PM

Re: [asterisk-dev] ARI Extending Existing Feature: bridge control

2014-12-17 Thread Nir Simionovich

I see your point now - that makes more sense. It was fairly clear to me
that ast_bridge_config is somewhat of a legacy data structure,
but I was assuming that in some respect it was used in ARI as well. What
your actually saying is that ARI bypasses all of the legacy
stuff and interacts directly with the bridge core, and that's why it
doesn't support that data structure. So technically, accessing bridge
configuration for a Legacy (Dial, Queue, FollowMe) is a fairly complex
task, as they don't see the same information space.

This now raises a slightly off-topic discussion - wouldn't it beneficial to
provide some form of ARI access to some of the legacy stuff
as well? On one hand, we don't really want to do that - as we're trying to
push people into proper usage of ARI and Asterisk, however,
my heart goes out to the legacy stuff, that if we don't cater to, will
become a caveat.

I will explain. About 6 years I've built a large scale Asterisk based
dialer for a customer. When I say large scale, I meant humongous
in 2008 terms - 2500 concurrent calls. Now, that dialer relied heavily on
AMI (of course) and AGI. It was originally built on Asterisk 1.6.
Recently, the customer came back to me, asking me to upgrade their system
to Asterisk 11, specifically for security reasons. I then
looked at the code, realizing that the customer had wrote some stuff using
MeetMe and some of the deprecated app_queue stuff.
I indicated to them that their legacy code should be migrated as well.
Customer looked at it, realized that apart from upgrading Asterisk,
they will have about 6 months worth of coding to migrate their stuff to the
new constructs - the entire project caved. We just upgraded
to latest version of the 1.6 branch, and the customer is now evaluating 1.8
- in other words, not supporting the legacy stuff in some
respect will at some point bite us in the ass.

I realize this is very much a leadership question, not a technical nor
operational.

New question: Do we want to enable legacy features inside ARI?

Nir

On Thu, Dec 18, 2014 at 1:26 AM, Mark Michelson mmichel...@digium.com
wrote:

  On 12/17/2014 05:01 PM, Nir Simionovich wrote:

 snip

  Let's try to stick to the tech for now and answer the first two
 questions:

1. Is there a way to obtain the information in ast_bridge_config for
 each of the iterated bridges?


 ast_bridge_config is not used at all for Stasis bridges. ast_bridge_config
 describes bridge features that basic bridges use based on Dial(), Queue(),
 and FollowMe() features. For instance, when Dial is called with the 't' and
 'T' options, the ast_bridge_config indicates that the caller and callee can
 perform DTMF transfers based on features.conf settings.

 For Stasis bridges, the idea of using ast_bridge_config does not make
 sense for several reasons

 1) Stasis applications are intended to be fully in control of everything
 that happens in the bridge. There should be nothing that the participants
 should be able to do independently of the Stasis application to change the
 bridge.
 2) ast_bridge_config relies heavily on the concept that a bridge contains
 exactly two participants. For basic bridges, this assumption holds. Stasis
 bridges can have any number of participants, though, so this structure
 doesn't work well.

 2. Is there a way to manipulate the configuration of the bridge, via
 modifying the associated bridge configuration in real time?


 The configuration of a Stasis bridge is defined by the Stasis application
 that creates and manipulates the bridge. It is up to the Stasis application
 to determine properties of the bridge and manipulate the bridge based on
 those properties. Whether you can manipulate this in real time is based on
 the programming language and runtime model of the ARI library you use.


  Nir



 --
 _
 -- 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

Re: [asterisk-dev] ARI Extending Existing Feature: bridge control

2014-12-17 Thread Nir Simionovich

One more thing - per your recommendations, I'm trying to re-implement
app_dial using ARI.

Now, if I read you all right, the process should be:

1. Get a call into Asterisk from an external phone
2. Create a new bridge
3. Put the call into the newly created bridge
4. Originate a new call
5. Put the new call into the existing bridge

So, 1,2,3 work just fine - then you get to 4. According to the docs, I can
originate a channel with only the endpoint defined.
However, that doesn't seem to work:

T 178.62.127.227:44938 - 178.62.127.227:8088 [AP]
POST /ari/channels HTTP/1.1.
Authorization: Basic dGVzdDp0ZXN0.
Host: 178.62.127.227:8088.
Content-Length: 85.
Accept: application/json.
Content-Type: application/json.
.
{endpoint:Local\/1000@demo
,channelId:participant,variables:{var1:var1}}

T 178.62.127.227:8088 - 178.62.127.227:44938 [AP]
HTTP/1.1 400 Bad Request.
Server: Asterisk/SVN-trunk-r429683M.
Date: Thu, 18 Dec 2014 07:41:59 GMT.
Cache-Control: no-cache, no-store.
Content-type: application/json.
Content-Length: 61.
.


T 178.62.127.227:8088 - 178.62.127.227:44938 [AP]
{
  message: Application or extension must be specified
}

Am I missing something here? or is this a bug?



On Thu, Dec 18, 2014 at 8:59 AM, Nir Simionovich nir.simionov...@gmail.com
wrote:

 I see your point now - that makes more sense. It was fairly clear to me
 that ast_bridge_config is somewhat of a legacy data structure,
 but I was assuming that in some respect it was used in ARI as well. What
 your actually saying is that ARI bypasses all of the legacy
 stuff and interacts directly with the bridge core, and that's why it
 doesn't support that data structure. So technically, accessing bridge
 configuration for a Legacy (Dial, Queue, FollowMe) is a fairly complex
 task, as they don't see the same information space.

 This now raises a slightly off-topic discussion - wouldn't it beneficial
 to provide some form of ARI access to some of the legacy stuff
 as well? On one hand, we don't really want to do that - as we're trying to
 push people into proper usage of ARI and Asterisk, however,
 my heart goes out to the legacy stuff, that if we don't cater to, will
 become a caveat.

 I will explain. About 6 years I've built a large scale Asterisk based
 dialer for a customer. When I say large scale, I meant humongous
 in 2008 terms - 2500 concurrent calls. Now, that dialer relied heavily on
 AMI (of course) and AGI. It was originally built on Asterisk 1.6.
 Recently, the customer came back to me, asking me to upgrade their system
 to Asterisk 11, specifically for security reasons. I then
 looked at the code, realizing that the customer had wrote some stuff using
 MeetMe and some of the deprecated app_queue stuff.
 I indicated to them that their legacy code should be migrated as well.
 Customer looked at it, realized that apart from upgrading Asterisk,
 they will have about 6 months worth of coding to migrate their stuff to
 the new constructs - the entire project caved. We just upgraded
 to latest version of the 1.6 branch, and the customer is now evaluating
 1.8 - in other words, not supporting the legacy stuff in some
 respect will at some point bite us in the ass.

 I realize this is very much a leadership question, not a technical nor
 operational.

 New question: Do we want to enable legacy features inside ARI?

 Nir

 On Thu, Dec 18, 2014 at 1:26 AM, Mark Michelson mmichel...@digium.com
 wrote:

  On 12/17/2014 05:01 PM, Nir Simionovich wrote:

 snip

  Let's try to stick to the tech for now and answer the first two
 questions:

1. Is there a way to obtain the information in ast_bridge_config for
 each of the iterated bridges?


 ast_bridge_config is not used at all for Stasis bridges.
 ast_bridge_config describes bridge features that basic bridges use based on
 Dial(), Queue(), and FollowMe() features. For instance, when Dial is called
 with the 't' and 'T' options, the ast_bridge_config indicates that the
 caller and callee can perform DTMF transfers based on features.conf
 settings.

 For Stasis bridges, the idea of using ast_bridge_config does not make
 sense for several reasons

 1) Stasis applications are intended to be fully in control of everything
 that happens in the bridge. There should be nothing that the participants
 should be able to do independently of the Stasis application to change the
 bridge.
 2) ast_bridge_config relies heavily on the concept that a bridge contains
 exactly two participants. For basic bridges, this assumption holds. Stasis
 bridges can have any number of participants, though, so this structure
 doesn't work well.

 2. Is there a way to manipulate the configuration of the bridge, via
 modifying the associated bridge configuration in real time?


 The configuration of a Stasis bridge is defined by the Stasis application
 that creates and manipulates the bridge. It is up to the Stasis application
 to determine properties of the bridge and manipulate the bridge based on
 those properties. Whether

[asterisk-dev] Asterisk MoS and RTCP data [pardon the directness and language :-)]

2014-11-06 Thread Nir Simionovich

Hi All,

So, if there is one thing I really like about PJSIP and WebRTC
(specifically with mobile) is the ability to produce meaningful MoS scoring
for calls in real time. Now, Asterisk doesn't have that capability, at
least, not during the actual call - but only after.

In itself, not an issue - it's good enough.

If you were to look up the calculation for how to get your MoS, the
following is the most common
algorithm that I've found:

effectiveLatency = rttMs + averageJitterMs * 2 + 10
R = 93.2 - (effectiveLatency/40)
R = R - (fractionLost * 2.5)
MOS = 1 + (0.035)*R+(0.07)*R*(R-60)*(100-R)

My primary question is this: I can't find what rttMs in Asterisk
terminology is. There is an rtt value,
but its value is several orders of magnitude than I would expect. So, I
thought it may be in microSec, not miliSec - but that doesn't make much
sense either.

So, on one hand I have a shit load of information, on the other hand, it is
formatted in a very hard way to manage.

Any idea how we can make this better? On another notion, I think that
adding RTCP reading capabilities to the channels module in ARI may probe
extremely useful.

Nir S
-- 
_
-- 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] Queue discussion at Astricon

2014-10-19 Thread Nir Simionovich

I'm in.
On Oct 17, 2014 10:08 PM, Leif Madsen lmad...@thinkingphones.com wrote:

 Your encouragement is noted and discarded. See you all at AstriCon! :)

 On 17 October 2014 16:00, Billy Chia bc...@digium.com wrote:

 There will actually be an opportunity to grab a beer at the Hackathon
 Reception in the same room as AstriDevCon immediately following AstriDevCon
 on Tuesday (Cherry Lounge 5PM - 7PM)
 (and as always we encourage people to partake responsibly during
 opportunities where beers will be offered at AstriCon)

 More info: http://astriconhackathon.challengepost.com/



 --
 _
 -- 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

Re: [asterisk-dev] Asterisk ARI improper usage pattern for channels REST API

2014-10-13 Thread Nir Simionovich

Ok, I'm now looking into implementing a similar thing with the continue
request.
The main issue that I'm seeing is this - the ast_findlabel_extension
function,
requires a channel and a callerid.

I've tried ascertaining how i can obtain that information from within the
ast_ari_channels_continue_in_dialplan function, but had failed to do so.

Any pointers?

Nir S

On Mon, Oct 13, 2014 at 1:52 AM, Nir Simionovich nir.simionov...@gmail.com
wrote:

 Ok,

   I've opened an issue on JIRA (
 https://issues.asterisk.org/jira/browse/ASTERISK-24412) with a small
 patch submission
 that will correct the issue at hand - for the originate requests at this
 point.

   Basically, before moving forward, I'd like to make sure I'm not off base
 with the implementation - and that I've done it right.
 It's the first time I'm touching that side of the code, so I would
 appreciate the assistance and feedback.

 Cheers,
 Nir S

 On Sun, Oct 12, 2014 at 12:46 AM, Nir Simionovich 
 nir.simionov...@gmail.com wrote:

 So, here's what I thought - instead of modifying the existing JSON,
 changing from int to string in priority, I think the better
 way would be to add a new variable - label. If defined, it will
 supersede the priority. Judging from what I see in the code,
 the arguments from the JSON POST are contained in the *args buffer, so
 I should now have an args-label in there.

 So, if I'm not mistaken, the following should translate from the label to
 the priority:ast_find_label_extension.

 So, I would need to add a label argument to
 ari_channels_handle_originate_with_id. However, and correct me if I'm wrong,
 it would seem to me that the actual channel origination is performed
 using 'ast_pbx_outgoing_exten', and that would
 return back the 'ast_channel' structure back to *chan in
 ari_channels_handle_originate_with_id.

 Makes the entire thing kind'a tricky - no?



 On Fri, Oct 10, 2014 at 9:48 PM, Scott Griepentrog 
 sgriepent...@digium.com wrote:

 Yes, that's the function that converts a label to a priority.  You
 should be able to use that to enable label lookup from the rest api.

 On Fri, Oct 10, 2014 at 1:38 PM, Nir Simionovich 
 nir.simionov...@gmail.com wrote:

 Well,

   Can I assume you are referring to the following section in the code
 (pbx.c):

 12371if (sscanf(pri, %30d, ipri) != 1) {12372   ipri = 
 ast_findlabel_extension 
 http://doxygen.asterisk.org/trunk/db/de0/pbx_8h.html#0be9518646cf9aca4878b313cc02e901(chan,
  context ? context : ast_channel_context 
 http://doxygen.asterisk.org/trunk/d5/d7b/channel_8h.html#582dee4d5ea9b2ff6f309f0c5239f6bd(chan),12373
   exten ? exten : ast_channel_exten 
 http://doxygen.asterisk.org/trunk/d5/d7b/channel_8h.html#a8b52fbc8168e939bc5553502367d46a(chan),
  pri,12374  S_COR 
 http://doxygen.asterisk.org/trunk/d6/d90/strings_8h.html#38a896048b2ca84076864505f0aa8f01(ast_channel_caller
  
 http://doxygen.asterisk.org/trunk/d5/d7b/channel_8h.html#c2dc872b606534943c98304aed841b34(chan)-id.number
  http://doxygen.asterisk.org/trunk/d6/d49/structnumber.html.valid, 
 ast_channel_caller 
 http://doxygen.asterisk.org/trunk/d5/d7b/channel_8h.html#c2dc872b606534943c98304aed841b34(chan)-id.number
  http://doxygen.asterisk.org/trunk/d6/d49/structnumber.html.str, NULL 
 http://doxygen.asterisk.org/trunk/dc/d7f/resample_8c.html#070d2ce7b6bb7e5c05602aa8c308d0c4));12375
if (ipri  1) {12376  ast_log 
 http://doxygen.asterisk.org/trunk/d1/d8c/logger_8h.html#cb8ee436a0c80c66dfcdec6b6bcc6196(LOG_WARNING
  
 http://doxygen.asterisk.org/trunk/d1/d8c/logger_8h.html#df4476a6a4ea6c74231c826e899d7189,
  Priority '%s' must be a number  0, or valid label\n, pri);12377
   return -1;12378   } else12379  mode = 0;12380}


   If I read it correctly, line 12372 will translate a label to a
 priority number.

   Am I on the right track?

 Nir


 On Thu, Oct 9, 2014 at 6:39 PM, Scott Griepentrog 
 sgriepent...@digium.com wrote:

 If you want to add the label option, my first thought would be to
 recommend you look at the implementation of app GoTo() for the api to
 lookup/specify a label.  Then you would need to modify the channels.json 
 in
 rest_api/api-docs to specify the new/different parameters to the rest
 methods, do a make ari-stubs to rebuild the rest handlers, and finally 
 make
 the change to the method implementation in res/ari/resource_channels.c.

 On Thu, Oct 9, 2014 at 4:56 AM, Nir Simionovich 
 nir.simionov...@gmail.com wrote:

 Forgive me father for I have sinned, it has been over 25 years since
 I've used GWBasic/Basica - please spare thy humble servant from doom, as 
 I
 repent my sins and go back in time 25 years :-)

 Now seriously, this may work nicely for classic dialplan, but for AEL
 that's a no go - don't even want to think about LUA at this point.

 Any prospects in regards to this development? I've hadn't ever dug
 into this part of the code, but, how does Asterisk keep the dialplan in
 memory? is it a simple data

Re: [asterisk-dev] Asterisk ARI improper usage pattern for channels REST API

2014-10-12 Thread Nir Simionovich

Ok,

  I've opened an issue on JIRA (
https://issues.asterisk.org/jira/browse/ASTERISK-24412) with a small patch
submission
that will correct the issue at hand - for the originate requests at this
point.

  Basically, before moving forward, I'd like to make sure I'm not off base
with the implementation - and that I've done it right.
It's the first time I'm touching that side of the code, so I would
appreciate the assistance and feedback.

Cheers,
Nir S

On Sun, Oct 12, 2014 at 12:46 AM, Nir Simionovich nir.simionov...@gmail.com
 wrote:

 So, here's what I thought - instead of modifying the existing JSON,
 changing from int to string in priority, I think the better
 way would be to add a new variable - label. If defined, it will
 supersede the priority. Judging from what I see in the code,
 the arguments from the JSON POST are contained in the *args buffer, so I
 should now have an args-label in there.

 So, if I'm not mistaken, the following should translate from the label to
 the priority:ast_find_label_extension.

 So, I would need to add a label argument to
 ari_channels_handle_originate_with_id. However, and correct me if I'm wrong,
 it would seem to me that the actual channel origination is performed using
 'ast_pbx_outgoing_exten', and that would
 return back the 'ast_channel' structure back to *chan in
 ari_channels_handle_originate_with_id.

 Makes the entire thing kind'a tricky - no?



 On Fri, Oct 10, 2014 at 9:48 PM, Scott Griepentrog 
 sgriepent...@digium.com wrote:

 Yes, that's the function that converts a label to a priority.  You should
 be able to use that to enable label lookup from the rest api.

 On Fri, Oct 10, 2014 at 1:38 PM, Nir Simionovich 
 nir.simionov...@gmail.com wrote:

 Well,

   Can I assume you are referring to the following section in the code
 (pbx.c):

 12371if (sscanf(pri, %30d, ipri) != 1) {12372   ipri = 
 ast_findlabel_extension 
 http://doxygen.asterisk.org/trunk/db/de0/pbx_8h.html#0be9518646cf9aca4878b313cc02e901(chan,
  context ? context : ast_channel_context 
 http://doxygen.asterisk.org/trunk/d5/d7b/channel_8h.html#582dee4d5ea9b2ff6f309f0c5239f6bd(chan),12373
   exten ? exten : ast_channel_exten 
 http://doxygen.asterisk.org/trunk/d5/d7b/channel_8h.html#a8b52fbc8168e939bc5553502367d46a(chan),
  pri,12374  S_COR 
 http://doxygen.asterisk.org/trunk/d6/d90/strings_8h.html#38a896048b2ca84076864505f0aa8f01(ast_channel_caller
  
 http://doxygen.asterisk.org/trunk/d5/d7b/channel_8h.html#c2dc872b606534943c98304aed841b34(chan)-id.number
  http://doxygen.asterisk.org/trunk/d6/d49/structnumber.html.valid, 
 ast_channel_caller 
 http://doxygen.asterisk.org/trunk/d5/d7b/channel_8h.html#c2dc872b606534943c98304aed841b34(chan)-id.number
  http://doxygen.asterisk.org/trunk/d6/d49/structnumber.html.str, NULL 
 http://doxygen.asterisk.org/trunk/dc/d7f/resample_8c.html#070d2ce7b6bb7e5c05602aa8c308d0c4));12375
if (ipri  1) {12376  ast_log 
 http://doxygen.asterisk.org/trunk/d1/d8c/logger_8h.html#cb8ee436a0c80c66dfcdec6b6bcc6196(LOG_WARNING
  
 http://doxygen.asterisk.org/trunk/d1/d8c/logger_8h.html#df4476a6a4ea6c74231c826e899d7189,
  Priority '%s' must be a number  0, or valid label\n, pri);12377 
  return -1;12378   } else12379  mode = 0;12380}


   If I read it correctly, line 12372 will translate a label to a
 priority number.

   Am I on the right track?

 Nir


 On Thu, Oct 9, 2014 at 6:39 PM, Scott Griepentrog 
 sgriepent...@digium.com wrote:

 If you want to add the label option, my first thought would be to
 recommend you look at the implementation of app GoTo() for the api to
 lookup/specify a label.  Then you would need to modify the channels.json in
 rest_api/api-docs to specify the new/different parameters to the rest
 methods, do a make ari-stubs to rebuild the rest handlers, and finally make
 the change to the method implementation in res/ari/resource_channels.c.

 On Thu, Oct 9, 2014 at 4:56 AM, Nir Simionovich 
 nir.simionov...@gmail.com wrote:

 Forgive me father for I have sinned, it has been over 25 years since
 I've used GWBasic/Basica - please spare thy humble servant from doom, as I
 repent my sins and go back in time 25 years :-)

 Now seriously, this may work nicely for classic dialplan, but for AEL
 that's a no go - don't even want to think about LUA at this point.

 Any prospects in regards to this development? I've hadn't ever dug
 into this part of the code, but, how does Asterisk keep the dialplan in
 memory? is it a simple data structure? how do labels are manifested in 
 that
 data structure?

 Point me in the right direction for the information (apart from the
 code itself) - and I'll have a look at it.

 Nir S

 On Wed, Oct 8, 2014 at 9:01 PM, Scott Griepentrog 
 sgriepent...@digium.com wrote:

 The only two ARI methods I'm seeing where a priority is used are:

 1) Channel origination (optionally sending channel to dialplan
 instead of into a Stasis app)

 2) Channel continue (jump

Re: [asterisk-dev] Asterisk ARI improper usage pattern for channels REST API

2014-10-11 Thread Nir Simionovich

So, here's what I thought - instead of modifying the existing JSON,
changing from int to string in priority, I think the better
way would be to add a new variable - label. If defined, it will supersede
the priority. Judging from what I see in the code,
the arguments from the JSON POST are contained in the *args buffer, so I
should now have an args-label in there.

So, if I'm not mistaken, the following should translate from the label to
the priority:ast_find_label_extension.

So, I would need to add a label argument to
ari_channels_handle_originate_with_id. However, and correct me if I'm wrong,
it would seem to me that the actual channel origination is performed using
'ast_pbx_outgoing_exten', and that would
return back the 'ast_channel' structure back to *chan in
ari_channels_handle_originate_with_id.

Makes the entire thing kind'a tricky - no?



On Fri, Oct 10, 2014 at 9:48 PM, Scott Griepentrog sgriepent...@digium.com
wrote:

 Yes, that's the function that converts a label to a priority.  You should
 be able to use that to enable label lookup from the rest api.

 On Fri, Oct 10, 2014 at 1:38 PM, Nir Simionovich 
 nir.simionov...@gmail.com wrote:

 Well,

   Can I assume you are referring to the following section in the code
 (pbx.c):

 12371if (sscanf(pri, %30d, ipri) != 1) {12372   ipri = 
 ast_findlabel_extension 
 http://doxygen.asterisk.org/trunk/db/de0/pbx_8h.html#0be9518646cf9aca4878b313cc02e901(chan,
  context ? context : ast_channel_context 
 http://doxygen.asterisk.org/trunk/d5/d7b/channel_8h.html#582dee4d5ea9b2ff6f309f0c5239f6bd(chan),12373
   exten ? exten : ast_channel_exten 
 http://doxygen.asterisk.org/trunk/d5/d7b/channel_8h.html#a8b52fbc8168e939bc5553502367d46a(chan),
  pri,12374  S_COR 
 http://doxygen.asterisk.org/trunk/d6/d90/strings_8h.html#38a896048b2ca84076864505f0aa8f01(ast_channel_caller
  
 http://doxygen.asterisk.org/trunk/d5/d7b/channel_8h.html#c2dc872b606534943c98304aed841b34(chan)-id.number
  http://doxygen.asterisk.org/trunk/d6/d49/structnumber.html.valid, 
 ast_channel_caller 
 http://doxygen.asterisk.org/trunk/d5/d7b/channel_8h.html#c2dc872b606534943c98304aed841b34(chan)-id.number
  http://doxygen.asterisk.org/trunk/d6/d49/structnumber.html.str, NULL 
 http://doxygen.asterisk.org/trunk/dc/d7f/resample_8c.html#070d2ce7b6bb7e5c05602aa8c308d0c4));12375
if (ipri  1) {12376  ast_log 
 http://doxygen.asterisk.org/trunk/d1/d8c/logger_8h.html#cb8ee436a0c80c66dfcdec6b6bcc6196(LOG_WARNING
  
 http://doxygen.asterisk.org/trunk/d1/d8c/logger_8h.html#df4476a6a4ea6c74231c826e899d7189,
  Priority '%s' must be a number  0, or valid label\n, pri);12377  
 return -1;12378   } else12379  mode = 0;12380}


   If I read it correctly, line 12372 will translate a label to a priority
 number.

   Am I on the right track?

 Nir


 On Thu, Oct 9, 2014 at 6:39 PM, Scott Griepentrog 
 sgriepent...@digium.com wrote:

 If you want to add the label option, my first thought would be to
 recommend you look at the implementation of app GoTo() for the api to
 lookup/specify a label.  Then you would need to modify the channels.json in
 rest_api/api-docs to specify the new/different parameters to the rest
 methods, do a make ari-stubs to rebuild the rest handlers, and finally make
 the change to the method implementation in res/ari/resource_channels.c.

 On Thu, Oct 9, 2014 at 4:56 AM, Nir Simionovich 
 nir.simionov...@gmail.com wrote:

 Forgive me father for I have sinned, it has been over 25 years since
 I've used GWBasic/Basica - please spare thy humble servant from doom, as I
 repent my sins and go back in time 25 years :-)

 Now seriously, this may work nicely for classic dialplan, but for AEL
 that's a no go - don't even want to think about LUA at this point.

 Any prospects in regards to this development? I've hadn't ever dug into
 this part of the code, but, how does Asterisk keep the dialplan in memory?
 is it a simple data structure? how do labels are manifested in that data
 structure?

 Point me in the right direction for the information (apart from the
 code itself) - and I'll have a look at it.

 Nir S

 On Wed, Oct 8, 2014 at 9:01 PM, Scott Griepentrog 
 sgriepent...@digium.com wrote:

 The only two ARI methods I'm seeing where a priority is used are:

 1) Channel origination (optionally sending channel to dialplan instead
 of into a Stasis app)

 2) Channel continue (jump out of application into a specific point in
 dialplan)

 And yes, you are correct in pointing out that the continue is using an
 int rather than a long, which is clearly a consistency mistake in the API.

 In both cases, the priority is given as a part of typical
 context/extension/priority method of addressing where exactly in the
 dialplan you want to send the channel to.  The most common scenario is to
 have a priority 1 as the starting point.  The other numbers (using same =
 n) are then sequential but arbitrary, and it is generally not necessary to
 know

Re: [asterisk-dev] Asterisk ARI improper usage pattern for channels REST API

2014-10-10 Thread Nir Simionovich

Well,

  Can I assume you are referring to the following section in the code
(pbx.c):

12371if (sscanf(pri, %30d, ipri) != 1) {12372   ipri =
ast_findlabel_extension
http://doxygen.asterisk.org/trunk/db/de0/pbx_8h.html#0be9518646cf9aca4878b313cc02e901(chan,
context ? context : ast_channel_context
http://doxygen.asterisk.org/trunk/d5/d7b/channel_8h.html#582dee4d5ea9b2ff6f309f0c5239f6bd(chan),12373
 exten ? exten : ast_channel_exten
http://doxygen.asterisk.org/trunk/d5/d7b/channel_8h.html#a8b52fbc8168e939bc5553502367d46a(chan),
pri,12374  S_COR
http://doxygen.asterisk.org/trunk/d6/d90/strings_8h.html#38a896048b2ca84076864505f0aa8f01(ast_channel_caller
http://doxygen.asterisk.org/trunk/d5/d7b/channel_8h.html#c2dc872b606534943c98304aed841b34(chan)-id.number
http://doxygen.asterisk.org/trunk/d6/d49/structnumber.html.valid,
ast_channel_caller
http://doxygen.asterisk.org/trunk/d5/d7b/channel_8h.html#c2dc872b606534943c98304aed841b34(chan)-id.number
http://doxygen.asterisk.org/trunk/d6/d49/structnumber.html.str, NULL
http://doxygen.asterisk.org/trunk/dc/d7f/resample_8c.html#070d2ce7b6bb7e5c05602aa8c308d0c4));12375
  if (ipri  1) {12376  ast_log
http://doxygen.asterisk.org/trunk/d1/d8c/logger_8h.html#cb8ee436a0c80c66dfcdec6b6bcc6196(LOG_WARNING
http://doxygen.asterisk.org/trunk/d1/d8c/logger_8h.html#df4476a6a4ea6c74231c826e899d7189,
Priority '%s' must be a number  0, or valid label\n, pri);12377
 return -1;12378   } else12379  mode = 0;12380}


  If I read it correctly, line 12372 will translate a label to a priority
number.

  Am I on the right track?

Nir


On Thu, Oct 9, 2014 at 6:39 PM, Scott Griepentrog sgriepent...@digium.com
wrote:

 If you want to add the label option, my first thought would be to
 recommend you look at the implementation of app GoTo() for the api to
 lookup/specify a label.  Then you would need to modify the channels.json in
 rest_api/api-docs to specify the new/different parameters to the rest
 methods, do a make ari-stubs to rebuild the rest handlers, and finally make
 the change to the method implementation in res/ari/resource_channels.c.

 On Thu, Oct 9, 2014 at 4:56 AM, Nir Simionovich nir.simionov...@gmail.com
  wrote:

 Forgive me father for I have sinned, it has been over 25 years since
 I've used GWBasic/Basica - please spare thy humble servant from doom, as I
 repent my sins and go back in time 25 years :-)

 Now seriously, this may work nicely for classic dialplan, but for AEL
 that's a no go - don't even want to think about LUA at this point.

 Any prospects in regards to this development? I've hadn't ever dug into
 this part of the code, but, how does Asterisk keep the dialplan in memory?
 is it a simple data structure? how do labels are manifested in that data
 structure?

 Point me in the right direction for the information (apart from the code
 itself) - and I'll have a look at it.

 Nir S

 On Wed, Oct 8, 2014 at 9:01 PM, Scott Griepentrog 
 sgriepent...@digium.com wrote:

 The only two ARI methods I'm seeing where a priority is used are:

 1) Channel origination (optionally sending channel to dialplan instead
 of into a Stasis app)

 2) Channel continue (jump out of application into a specific point in
 dialplan)

 And yes, you are correct in pointing out that the continue is using an
 int rather than a long, which is clearly a consistency mistake in the API.

 In both cases, the priority is given as a part of typical
 context/extension/priority method of addressing where exactly in the
 dialplan you want to send the channel to.  The most common scenario is to
 have a priority 1 as the starting point.  The other numbers (using same =
 n) are then sequential but arbitrary, and it is generally not necessary to
 know what they actually are to jump to them directly.

 As you point out, labels in dialplan are a convenient way of allowing
 dialplan execution to jump or goto a specific point without needing to know
 the actual priority number.  Unfortunately, the implementation in ARI does
 not (currently) allow for a label to be specified.  This is a limitation
 that should probably be fixed - possibly a topic of discussion for
 Astridevcon.

 For a workaround, I would suggest using arbitrarily large priorities to
 jump to the correct label where this functionality is needed.

 For example:

 exten = _x.,1,Answer()
same = n,GoToIf($[${GOTTAGONOW} = 1]?louie)
same = n,Playback(tt-monkeys)
same = n,Hangup()
same = n(louie),Playback(lyrics-louie-louie)
same = n,Hangup()

 exten = _x.,10001,GoTo(louie)

 On Wed, Oct 8, 2014 at 8:33 AM, Nir Simionovich 
 nir.simionov...@gmail.com wrote:

 Hi Guys,

   While working on PHPARI, I've come to a realization that the channels
 REST API
 has a slight issue - primarily, its usage of the priority member in
 the REST API.

   Currently, the specification states that priority is either int
 or long (depending
 on the request).

   The problem with that is for someone

Re: [asterisk-dev] Asterisk ARI improper usage pattern for channels REST API

2014-10-09 Thread Nir Simionovich

Forgive me father for I have sinned, it has been over 25 years since I've
used GWBasic/Basica - please spare thy humble servant from doom, as I
repent my sins and go back in time 25 years :-)

Now seriously, this may work nicely for classic dialplan, but for AEL
that's a no go - don't even want to think about LUA at this point.

Any prospects in regards to this development? I've hadn't ever dug into
this part of the code, but, how does Asterisk keep the dialplan in memory?
is it a simple data structure? how do labels are manifested in that data
structure?

Point me in the right direction for the information (apart from the code
itself) - and I'll have a look at it.

Nir S

On Wed, Oct 8, 2014 at 9:01 PM, Scott Griepentrog sgriepent...@digium.com
wrote:

 The only two ARI methods I'm seeing where a priority is used are:

 1) Channel origination (optionally sending channel to dialplan instead of
 into a Stasis app)

 2) Channel continue (jump out of application into a specific point in
 dialplan)

 And yes, you are correct in pointing out that the continue is using an int
 rather than a long, which is clearly a consistency mistake in the API.

 In both cases, the priority is given as a part of typical
 context/extension/priority method of addressing where exactly in the
 dialplan you want to send the channel to.  The most common scenario is to
 have a priority 1 as the starting point.  The other numbers (using same =
 n) are then sequential but arbitrary, and it is generally not necessary to
 know what they actually are to jump to them directly.

 As you point out, labels in dialplan are a convenient way of allowing
 dialplan execution to jump or goto a specific point without needing to know
 the actual priority number.  Unfortunately, the implementation in ARI does
 not (currently) allow for a label to be specified.  This is a limitation
 that should probably be fixed - possibly a topic of discussion for
 Astridevcon.

 For a workaround, I would suggest using arbitrarily large priorities to
 jump to the correct label where this functionality is needed.

 For example:

 exten = _x.,1,Answer()
same = n,GoToIf($[${GOTTAGONOW} = 1]?louie)
same = n,Playback(tt-monkeys)
same = n,Hangup()
same = n(louie),Playback(lyrics-louie-louie)
same = n,Hangup()

 exten = _x.,10001,GoTo(louie)

 On Wed, Oct 8, 2014 at 8:33 AM, Nir Simionovich nir.simionov...@gmail.com
  wrote:

 Hi Guys,

   While working on PHPARI, I've come to a realization that the channels
 REST API
 has a slight issue - primarily, its usage of the priority member in the
 REST API.

   Currently, the specification states that priority is either int or
 long (depending
 on the request).

   The problem with that is for someone like myself, who codes dialplan in
 AEL or
 using the same = n, or the exten = _X.,n, methodology - we have no
 visibility
 of priority numbers - we use labels.

   I'm not that familiar with the ARI part of the Asterisk code yet, as
 I'm focused on how
 to actually work with it, but this is somewhat of a show stopper in my
 book, as all my
 existing code relies heavily on label usage.

   Btw, I tried pushing a label into the REST interface, got a 500 error -
 which means
 it's designed to work with numbers and not labels.

 Regards,
   Nir S



 --
 _
 -- 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




 --
 [image: Digium logo]
 Scott Griepentrog
 Digium, Inc · Software Developer
 445 Jan Davis Drive NW · Huntsville, AL 35806 · US
 direct/fax: +1 256 428 6239 · mobile: +1 256 580 6090
 Check us out at: http://digium.com · http://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

-- 
_
-- 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] Asterisk ARI improper usage pattern for channels REST API

2014-10-08 Thread Nir Simionovich

Hi Guys,

  While working on PHPARI, I've come to a realization that the channels
REST API
has a slight issue - primarily, its usage of the priority member in the
REST API.

  Currently, the specification states that priority is either int or
long (depending
on the request).

  The problem with that is for someone like myself, who codes dialplan in
AEL or
using the same = n, or the exten = _X.,n, methodology - we have no
visibility
of priority numbers - we use labels.

  I'm not that familiar with the ARI part of the Asterisk code yet, as I'm
focused on how
to actually work with it, but this is somewhat of a show stopper in my
book, as all my
existing code relies heavily on label usage.

  Btw, I tried pushing a label into the REST interface, got a 500 error -
which means
it's designed to work with numbers and not labels.

Regards,
  Nir S
-- 
_
-- 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] Feature Bounty - Pitch Control for MeetMe

2006-08-11 Thread Nir Simionovich

Title: RE: [asterisk-dev] Feature Bounty - Pitch Control for MeetMe






Hi John,


 Interesting application, although, it's not stable yet and not ready for production

use. However, I'll try using it.


Nir Simionovich


-Original Message-

From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of John Lange

Sent: Friday, August 11, 2006 5:14 PM

To: asterisk-dev@lists.digium.com

Subject: Re: [asterisk-dev] Feature Bounty - Pitch Control for MeetMe


This exists already though not specifically for meetme.


http://www.lobstertech.com/code/voicechanger/


John


On Fri, 2006-08-11 at 13:58 +0300, Nir Simionovich wrote:

 Hi All,

 

 We require a new feature for app_meetme to be added, a pitch control.

 The idea is to enable pitch changes of the talking participent by pressing

 the * or # buttons (activating this feature will disable the regular * function).

 

 The bounty that we've set for this feature is $500, to be paid to the person

 who delivers a properly working application running on latest stable version of

 Asterisk (1.2.10). 

 

 If you would like to work on this bounty, please contact me directly via e-Mail

 or phone at +972-54-4482826.

 


___

--Bandwidth and Colocation provided by Easynews.com --


asterisk-dev mailing list

To UNSUBSCRIBE or update options visit:

 http://lists.digium.com/mailman/listinfo/asterisk-dev



___
--Bandwidth and Colocation provided by Easynews.com --

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

RE: [asterisk-dev] Feature Bounty - Pitch Control for MeetMe

2006-08-11 Thread Nir Simionovich

Title: RE: [asterisk-dev] Feature Bounty - Pitch Control for MeetMe






Hi John,


 On another side of things, it's not dynamic. It changes the pitch before the dialing,

then connects over. That means that you can't change the pitch during the actual call.


Nir S


-Original Message-

From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of John Lange

Sent: Friday, August 11, 2006 5:14 PM

To: asterisk-dev@lists.digium.com

Subject: Re: [asterisk-dev] Feature Bounty - Pitch Control for MeetMe


This exists already though not specifically for meetme.


http://www.lobstertech.com/code/voicechanger/


John


On Fri, 2006-08-11 at 13:58 +0300, Nir Simionovich wrote:

 Hi All,

 

 We require a new feature for app_meetme to be added, a pitch control.

 The idea is to enable pitch changes of the talking participent by pressing

 the * or # buttons (activating this feature will disable the regular * function).

 

 The bounty that we've set for this feature is $500, to be paid to the person

 who delivers a properly working application running on latest stable version of

 Asterisk (1.2.10). 

 

 If you would like to work on this bounty, please contact me directly via e-Mail

 or phone at +972-54-4482826.

 


___

--Bandwidth and Colocation provided by Easynews.com --


asterisk-dev mailing list

To UNSUBSCRIBE or update options visit:

 http://lists.digium.com/mailman/listinfo/asterisk-dev



___
--Bandwidth and Colocation provided by Easynews.com --

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

[Asterisk-Dev] Asterisk Feature Request: app_bridgeme

2005-12-13 Thread Nir Simionovich - CTO

Hi all,

  I'm currently involved in a project where the meetme application is used 
extensively forbridging calls between an operator and 2 or more parties. One
of the features that we require is the ability to pass DTMF signals from any
party in the bridge to a pre-specified bridge connected channel.

  I will explain this using the following scenario:

1. User A calls the Asterisk box and is put into the bridge
2. An operator is notified that a user is waiting in the bridge and connects to 
   the bridge.
3. Now, the operator originates 1 or more calls that would be connected to the 
   bridge. One of these calls is designated with an environment variable saying
   ${OUTBOUND_BRIDGE}.
4. Any channel connected to the bridge, when pressing a DTMF key would then have
   that DTMF signal transmitter to the ${OUTBOUND_BRIDGE} channel, resulting in 
   the ability to bridge several users into a single outbound channel and to 
   proxy DTMF's to it.
 
  I'm aware that is a fairly funky usage for an application, but if someone has 
a better way of doing this, I'm willing to learn. Oh, btw, one small remark, if 
you were about to say: use queues and call park, my answer would be: I 
can't, I have no control over the extensions. I basically interconnect via a 
PRI to an external Avaya CTI system, thus, I have no way of implementing queues 
in the system - due to constraints by the Avaya CTI system.

Regards,
  Nir Simionovich

___
--Bandwidth and Colocation provided by Easynews.com --

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

[Asterisk-Dev] Very Weird problem with MeetMe, SIP, Zap and the combo of the three

2005-12-01 Thread Nir Simionovich - CTO

Hi All,

  I have a really funky problem, which I can't seem to pin point.I have a 
setup that looks something like this:

SS7 Networks --SS7-- Veraz IGate4000 --SIP-- Asterisk 

Now, Asterisk has a second connection, that looks like this:

Asterisk --PRI-- Avaya CTI

  Now, I'll describe several sceanrios that I'm testing, with some really
Weird results:

Scenario 1:

A. User calls in from the SS7 network, via SIP to Asterisk.
B. Asterisk originates a call to Avaya CTI via PRI
C. Both users are now put into a MeetMe room
D. Avaya user talks, SS7 user hears. SS7 user talks, Avaya heards nothing.

Scenario 2:

A. User calls in from the SS7 network, via SIP to Asterisk
B. Asterisk dials out via the PRI to the Avaya to a specified location.
C. Avaya picks up the call, then generates an outgoing call.
D. The call is picked up.
E. User at the avaya end speaks, SS7 user hears. User at SS7 speaks, avaya
   user doesn't hear.

Scenario 3: 
A. User calls in from the SS7 network, via SIP to Asterisk
B. Asterisk dials out via the SIP connection to a specified location.
C. The call is being picked at the remote end and we have 2 way audio.

Scenario 4:
A. User 1 calls in from the SS7 network, and is put into MeetMe room 1000.
B. User 2 calls in from the SS7 network, and is put into MeetMe room 1000.
C. Users 1 and 2 talk, but can't hear a thing.

Ok, now, I'll go through the conclusions I've reached:

1. There is no network blockage, which is proved by Scenario 3.
2. A test system, working with the same Asterisk version (1.2.0-stable) is 
   working fine in a different location, with a slightly different setup.
3. Scenario 3 negates issues of SIP interoperability between Veraz and 
   Asterisk, on the following tested codecs: g711, IPP-g723.1, IPP-g729 and 
   Digium-g729
4. All MeetMe application entries ares started with: MqAx options.
5. Scenario 4 and the options defined in section 4 indicate the MOH should 
   have been heared, but it wasn't.
6. Now, if I wouldn't have tested scenario 4, I would have said that the PRI 
   is causing issues, however, scenario 4 indicates that something else is 
   wrong. 

So, anyone has an idea of what's going on here? Or better yet, a proposed 
course of Action?

Regards,
  Nir Simionovich


___
--Bandwidth and Colocation provided by Easynews.com --

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

RE: [Asterisk-Dev] startup

2005-09-13 Thread Nir Simionovich - CTO

Well,

  I would and use something external, like the mon utility from the linux-ha
project. Monitoring if asterisk is alive, from the internal has its
advantages, however, monitoring as a concept is always performed from a 3rd
party process or server.

Nir S

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Klaus Darilion
Sent: Tuesday, September 13, 2005 10:04 AM
To: Asterisk Developers Mailing List
Subject: Re: [Asterisk-Dev] startup

Hi!

Take a look at the briStuff from junghanns.net. This patch includes 
res_watchdog.c, which sends keep alive to an ISDN failover switch (via 
serial connection). This sounds similar to the application you need.

klaus

himanshoo kumar saxena wrote:
 Hi all,
 
 I am new to asterisk and am looking for following information, any help
will
 be greatly appreciated.
 When my asterisk starts, I want it to connect it to another server and
then
 continuously keep pinging that server by sending heartbeat messages. So in
 asterisk, is there some way of specifying an app or some thing can be
 started by asterisk at start up time and then this app can be on it's own,
 having it's own logic?
 Any ideas ?
 
 -himanshoo
 
 ___
 Asterisk-Dev mailing list
 Asterisk-Dev@lists.digium.com
 http://lists.digium.com/mailman/listinfo/asterisk-dev
 To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-dev
 
 

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


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

73 matches

Mail list logo