Re: [asterisk-dev] linking/loading external library

[alexander merkulov]

On Tue, Nov 26, 2013 at 09:45:44AM +0200, alexander merkulov wrote:
> hi
> i am gooing to use libfftw3 library in asterisk application.
>
> compilation is ok, but when i am loading module i get error like this:
>
> dev*CLI> module load app_amdb.so
> Unable to load module app_amdb.so
> Command 'module load app_amdb.so' failed.
> [Nov 26 07:44:51] WARNING[17342]: loader.c:481 load_dynamic_module: Error
> loading module 'app_amdb.so': /usr/lib/asterisk/modules/app_
amdb.so:
> undefined symbol: fftw_plan_dft_1d
> [Nov 26 07:44:51] WARNING[17342]: loader.c:894 load_resource: Module
> 'app_amdb.so' could not be loaded.
> dev*CLI>

>What's the output of:
>
> ldd /usr/lib/asterisk/modules/app_amdb.so
>
>?

it not show linking to libfftw3.so.3

i found hack, if i add libfftw3 to LIB in Makefile, it worked, BUT that is
nto how it have be designed,no?
-- 
_
-- 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] [Code Review] 3034: Tests for PJSIP_ENDPOINT

[Matt Jordan]

---
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/3034/
---

Review request for Asterisk Developers.


Repository: testsuite


Description
---

Asterisk Testsuite tests for PJSIP_ENDPOINT. The code for this function can be 
found at https://reviewboard.asterisk.org/r/3035/.

This test covers:
* Extracting every endpoint parameter from an endpoint (alice)
* Extracting a single parameter from a different endpoint (bob) which has a 
different value than alice
* Verifying that the function doesn't blow up if supplied an invalid 
endpoint/field


Diffs
-

  /asterisk/trunk/tests/channels/pjsip/tests.yaml 4364 
  /asterisk/trunk/tests/channels/pjsip/dialplan_functions/tests.yaml 
PRE-CREATION 
  
/asterisk/trunk/tests/channels/pjsip/dialplan_functions/pjsip_endpoint/test-config.yaml
 PRE-CREATION 
  
/asterisk/trunk/tests/channels/pjsip/dialplan_functions/pjsip_endpoint/configs/ast1/pjsip.conf
 PRE-CREATION 
  
/asterisk/trunk/tests/channels/pjsip/dialplan_functions/pjsip_endpoint/configs/ast1/extensions.conf
 PRE-CREATION 

Diff: https://reviewboard.asterisk.org/r/3034/diff/


Testing
---


Thanks,

Matt Jordan

-- 
_
-- 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] [Code Review] 3035: Add a function PJSIP_ENDPOINT to retrieve endpoint configuration details from the dialplan

[Matt Jordan]

---
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/3035/
---

Review request for Asterisk Developers.


Repository: Asterisk


Description
---

The impetus for this function came from looking at the CHANNEL function for 
chan_sip, and starting to map out what properties should be applied to 
chan_pjsip.

While I was looking at it, I thought that - other than the name of the endpoint 
associated with the channel - endpoint details really shouldn't come from the 
CHANNEL function. They should come from something else. Hence, the 
PJSIP_ENDPOINT function.

This function lets you query any property configured on an endpoint, for any 
endpoint, from the dialplan. Assuming the CHANNEL function gets applied to 
chan_pjsip, this would let you extract information about a channel's endpoint - 
or whatever endpoint they're going to go talk to.

This has some obvious implications in knowing what's about to happen before you 
go Dial some endpoint.

As an aside, I think this patch also shows (to a small extent) the usefulness 
of both Sorcery as well as XML configuration information. More lines of code 
are spent on sanitizing input than anything else.


Diffs
-

  /branches/12/main/sorcery.c 403234 
  /branches/12/funcs/func_pjsip_endpoint.c PRE-CREATION 
  /branches/12/doc/snapshots.xslt 403234 
  /branches/12/doc/appdocsxml.xslt PRE-CREATION 
  /branches/12/doc/appdocsxml.dtd 403234 
  /branches/12/Makefile 403234 

Diff: https://reviewboard.asterisk.org/r/3035/diff/


Testing
---

Testsuite test written and available here:

https://reviewboard.asterisk.org/r/3034/


Thanks,

Matt Jordan

-- 
_
-- 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] [Code Review] 3028: ari: Add 'number', 'digits', and 'characters' URI scheme playback implementations

[Joshua Colp]

---
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/3028/
---

(Updated Nov. 27, 2013, 6:53 p.m.)


Status
--

This change has been marked as submitted.


Review request for Asterisk Developers.


Changes
---

Committed in revision 403209


Repository: Asterisk


Description
---

There is currently no way in ARI to easily say a number, digits, or a string of 
characters. You can do it manually but this is extremely cumbersome. The 
attached change implements this functionality using new URI schemes in the 
Playback operation.

number: will play the provided number
digits: will play the provided digits
characters: will play the provided characters

By using the existing playback operation these can be queued up just like any 
other sound file, allowing you to construct a complete sentence if you desire.


Diffs
-

  /branches/12/res/res_stasis_playback.c 403158 

Diff: https://reviewboard.asterisk.org/r/3028/diff/


Testing
---

Executed playback with the various URI schemes.


Thanks,

Joshua Colp

-- 
_
-- 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] [Code Review] 3007: ARI: Snoop tests

[Joshua Colp]

---
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/3007/
---

(Updated Nov. 27, 2013, 6:48 p.m.)


Status
--

This change has been marked as submitted.


Review request for Asterisk Developers.


Changes
---

Committed in revision 4383


Bugs: ASTERISK-22780
https://issues.asterisk.org/jira/browse/ASTERISK-22780


Repository: testsuite


Description
---

The attached patch adds testing for whispering and spying in ARI. It confirms 
that whispered or spied audio passes through the Snoop channel.


Diffs
-

  /asterisk/trunk/tests/rest_api/channels/tests.yaml 4328 
  /asterisk/trunk/tests/rest_api/channels/snoop_whisper/test-config.yaml 
PRE-CREATION 
  
/asterisk/trunk/tests/rest_api/channels/snoop_whisper/configs/ast1/extensions.conf
 PRE-CREATION 
  /asterisk/trunk/tests/rest_api/channels/snoop_whisper/channel_whisper.py 
PRE-CREATION 
  /asterisk/trunk/tests/rest_api/channels/snoop_spy/test-config.yaml 
PRE-CREATION 
  
/asterisk/trunk/tests/rest_api/channels/snoop_spy/configs/ast1/extensions.conf 
PRE-CREATION 
  /asterisk/trunk/tests/rest_api/channels/snoop_spy/channel_spy.py PRE-CREATION 

Diff: https://reviewboard.asterisk.org/r/3007/diff/


Testing
---

Ran tests, they passed.


Thanks,

Joshua Colp

-- 
_
-- 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] [Code Review] 2963: chan_pjsip: Extend redirect handling support

[Joshua Colp]

---
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/2963/
---

(Updated Nov. 27, 2013, 6:36 p.m.)


Status
--

This change has been marked as submitted.


Review request for Asterisk Developers.


Changes
---

Committed in revision 403207


Repository: Asterisk


Description
---

chan_pjsip currently supports only one method for handling redirects: It takes 
the user portion of the target and places it into the call forwarding target as 
a local extension. This is fine for calling end-user devices but is not 
suitable for some situations involving other SIP servers (*cough* Microsoft 
Lync *cough*). The attached patch makes the behavior configurable and adds two 
other options: "uri_dialplan" and "uri_pjsip".

The uri_dialplan option returns the URI as the call forwarding target and 
instructs the dial process to dial it using the original endpoint. This is the 
equivalent of the "promiscredir" option in chan_sip.

The uri_pjsip option handles the redirect completely within chan_pjsip itself. 
This allows multiple targets to be tried if need be, and also reduces the 
amount of work the core has to do (no channel teardown and dialing again, the 
same channel is used).

As all of these may be useful for people and implementing them is relatively 
easy I've done so.


Diffs
-

  /branches/12/res/res_pjsip_session.c 402863 
  /branches/12/res/res_pjsip/pjsip_configuration.c 402863 
  /branches/12/res/res_pjsip.c 402863 
  /branches/12/include/asterisk/res_pjsip.h 402863 

Diff: https://reviewboard.asterisk.org/r/2963/diff/


Testing
---

Placed calls to a target with each option, confirmed that they work as expected.


Thanks,

Joshua Colp

-- 
_
-- 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] [Code Review] 2851: chan_sip: Remove requirement for resolving host when outbound proxy in use

[Joshua Colp]

---
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/2851/
---

(Updated Nov. 28, 2013, 12:25 a.m.)


Status
--

This change has been discarded.


Review request for Asterisk Developers.


Bugs: ASTERISK-21231 and ASTERISK-21694
https://issues.asterisk.org/jira/browse/ASTERISK-21231
https://issues.asterisk.org/jira/browse/ASTERISK-21694


Repository: Asterisk


Description
---

During the development of 1.8 chan_sip was moved to using dnsmgr for host 
resolution. These changes introduced a regression where all hosts were looked 
up in DNS, including when an outbound proxy is in use. This is incorrect. The 
attached change removes this requirement.


Diffs
-

  /branches/1.8/channels/chan_sip.c 402874 
  /branches/1.8/CHANGES 402874 

Diff: https://reviewboard.asterisk.org/r/2851/diff/


Testing
---

Configured an outbound proxy at global and peer level, confirmed that no 
resolution occurs for the host and also that traffic goes to where it should. 
Removed outbound proxy and confirmed things returned to normal.


Thanks,

Joshua Colp

-- 
_
-- 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] SaySentence/SoundPack Proposal

[Steve Murphy]

My responses:


On Wed, Nov 27, 2013 at 10:14 AM, Tzafrir Cohen wrote:

> On Tue, Nov 26, 2013 at 10:04:58PM -0700, Steve Murphy wrote:
> > Hello--
> >
> > Boy, it's been a long time since I posted to the dev mailing list!
> >
> > I'd like to announce a proposal to the Asterisk Community, that I
> > introduced at Astridevcon last month. It is a new API for playing sound
> > files (mainly speech). A pdf describing the Proposal in some detail is
> at:
> >
> > http://www.gmvoices.com/downloads/steve/sayscripts.pdf
>
> My initial reaction to this is that it is a reimplementation of
> text-to-speech.
>

​It will make Asterisk capable of using larger sound file sets,
sounding more natural than even text to speech.

Someday text to speech packages (Ivona, for example, which are plain
AWESOME), will
be indistinguishable from natural speech. But they haven't quite
reached that status yet. Until they do, better quality sound sets
will be possible in Asterisk. Not only for special IVR's, but for
Asterisk itself.

But, that being said, this is far from being its sole purpose. Right
now, translations are very difficult to generate, within Asterisk,
and via IVR's. The SaySentence stuff will make all this much easier.


> It also removes some existing functionality (saying a date and such).
>

​Absolutely false! All the date pronouncing capabilities presented
by the Say stuff is all covered in the SaySentence spec. Check it out.
It may even cover all this better than the assembled existing say stuff.
​


>
> The proposal also ignores say.conf . When talking with Steve at the
> DevConf I made the mistake of assuming that as say.conf is only
> referenced in app_playback, it is only used by Playback(), which is not
> the case.
>

​Wrong again. I didn't IGNORE it. This proposal replaces it. I built
the whole spec around what already exists in the various "say" stuff.
If I missed anything, let me know. As far as I know, I added some cool
stuff to the mix, like special combinations that have a different
pronunciation than just the concatenation of the individual pieces, for
example...
​


>
> Languages in say.conf:
>
> $ grep '^\[' configs/say.conf.sample
> [general]
> [digit-base](!) ; base rule for digit strings
> [date-base](!)  ; base rules for dates and times
> [en-base](!)
> [en_GB](date-base,digit-base,en-base)
> [it](digit-base,date-base)
> [en](en-base,date-base,digit-base)
> [de](date-base,digit-base)
> [hu](digit-base,date-base)
> [fr](date-base,digit-base)
> [es](date-base,digit-base)
> [da](date-base,digit-base)
>
> Why isn't it more commonly used?
>

​Personally, after reviewing all the stuff in the say.conf package,
my first guess is that it is not very well documented, nor advertised.
It is not used in the Asterisk core, and does not help you with stuff
hard wired into the Asterisk source.

Not only that, it is still oriented around the "group by phrase" concept,
instead of "group by full sentence". In the end, while this stuff might
help with localizing some of the substructure, it isn't tied directly to
full sentences. How can you translate anything properly without knowing
the full context? Most of the complexity introduced with gender/topic
variations
in rendering dates, numbers, etc, and codified in C all fall away when you
step back and pronounce sentences in a single unit. The basics *are* all in
the Say and say.conf related stuff, but it lacks the unifying concepts. It
is
not algorithmic, and still depends on the C coded source in say.c, which to
add
to Asterisk, means months of work and waiting as new releases roll out.
Soundpacks,
on the other hand, completely encapsulate a new language. No code
submissions to
Asterisk. Just put the sound pack together, debug, and publish. If all goes
well,
you may be able to publish sound sets not only for Asterisk, but other
phone systems
as well, using the same methodology. But, that's for the future.
​


>
> (On a personal note: writing the language support is a nice janitorial
> task for a native speaker of the language with a moderate level of C, as
> it easy to test and has no inherent concurrency issues)
>

​The same applies to the SaySentence. Personally, I think the whole say.c
methodology is a sinking ship. ​It's good stuff, don't misunderstand me,
but needed a new base, a new philosophy, and some reorganization.

​And, yes, there is a lot of locale-specific stuff to glean from the various
language specific routines now in Asterisk (See say.c, app_voicemail.c,
etc).
It is a bit of work to do that, and even at that, a bit buggy on top of
that.
Whether to throw it away and start from scratch, or to glean, is up to those
willing to work on these issues. I can do some, but I will need help.​


> --
>Tzafrir Cohen
>
-- 

Steve Murphy
ParseTree Corporation
✉  murf
​ at ​
parsetree
​ dot ​
com 
☎ 307-899-5535
-- 
_
-- Bandwidth and Colocation Provided by http://www.

Re: [asterisk-dev] linking/loading external library

[Tzafrir Cohen]

On Tue, Nov 26, 2013 at 09:45:44AM +0200, alexander merkulov wrote:
> hi
> i am gooing to use libfftw3 library in asterisk application.
> 
> compilation is ok, but when i am loading module i get error like this:
> 
> dev*CLI> module load app_amdb.so
> Unable to load module app_amdb.so
> Command 'module load app_amdb.so' failed.
> [Nov 26 07:44:51] WARNING[17342]: loader.c:481 load_dynamic_module: Error
> loading module 'app_amdb.so': /usr/lib/asterisk/modules/app_amdb.so:
> undefined symbol: fftw_plan_dft_1d
> [Nov 26 07:44:51] WARNING[17342]: loader.c:894 load_resource: Module
> 'app_amdb.so' could not be loaded.
> dev*CLI>

What's the output of:

  ldd /usr/lib/asterisk/modules/app_amdb.so

?

-- 
   Tzafrir Cohen
icq#16849755  jabber:tzafrir.co...@xorcom.com
+972-50-7952406   mailto:tzafrir.co...@xorcom.com
http://www.xorcom.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

[asterisk-dev] performance of DONT_OPTIMIZE

[Tzafrir Cohen]

Hi

https://wiki.asterisk.org/wiki/display/AST/Getting+a+Backtrace reads:

| Running a production server with DONT_OPTIMIZE is generally safe. You'll
| notice the binary files may be a bit larger, but in terms of Asterisk
| performance, impact should be negligible.

The effect of DONT_OPTIMIZE is setting the optimization build flag to
-O0 (rather than -O6).


As a side note, recent versions of gcc (4.8) have -Og:
| Optimize debugging experience. -Og enables optimizations that do not
| interfere with debugging. It should be the optimization level of choice
| for the standard edit-compile-debug cycle, offering a reasonable level
| of optimization while maintaining fast compilation and a good debugging
| experience.

It would probably be better than -O0, if available (thanks ot Tim_Today
on #asterisk-dev).

Common wisdom is that optimization level does impact performance.
Consider the following (pathalogical, though) example:

$ cat /tmp/test.c
int main() {
int i;
for(i=1; i<1; i++)
;
return 0;
}
$ gcc -O0 /tmp/test.c -o /tmp/test; time /tmp/test

real0m0.214s
user0m0.212s
sys 0m0.000s
$ gcc -O2 /tmp/test.c -o /tmp/test; time /tmp/test

real0m0.001s
user0m0.000s
sys 0m0.000s


The unoptimized version would have indeed preserved the code. But I want
the compiler to provide me with better performance.

A simple artificial test shows a noticable (-40% or so) performance
penalty on the following loop:

exten => time,n,Set(i=10)
exten => time,n,While($[${i} > 0])
exten => time,n,Set(i=$[${i} - 1])
exten => time,n,EndWhile

So I wonder if Asterisk's performance is that much not CPU bound that
the effect of a similar penalty will be negligible. Any numbers?

-- 
   Tzafrir Cohen
icq#16849755  jabber:tzafrir.co...@xorcom.com
+972-50-7952406   mailto:tzafrir.co...@xorcom.com
http://www.xorcom.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

Re: [asterisk-dev] [Code Review] 2958: Testsuite - pjsip: AMI commands and events

[Matt Jordan]

---
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/2958/#review10293
---

Ship it!


Ship It!

- Matt Jordan


On Nov. 25, 2013, 6:31 p.m., Kevin Harwell wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/2958/
> ---
> 
> (Updated Nov. 25, 2013, 6:31 p.m.)
> 
> 
> Review request for Asterisk Developers.
> 
> 
> Bugs: ASTERISK-22609
> https://issues.asterisk.org/jira/browse/ASTERISK-22609
> 
> 
> Repository: testsuite
> 
> 
> Description
> ---
> 
> Tests the following AMI actions and their corresponding events for res_pjsip:
> 
> PJSIPShowEndpoint
> PJSIPShowEndpoints
> PJSIPShowRegistrationsInbound
> PJSIPShowRegistrationsOutbound
> PJSIPShowSubscriptions
> 
> See https://reviewboard.asterisk.org/r/2959/ for implementation review.
> 
> 
> Diffs
> -
> 
>   /asterisk/trunk/tests/channels/pjsip/tests.yaml 4366 
>   /asterisk/trunk/tests/channels/pjsip/ami/tests.yaml PRE-CREATION 
>   
> /asterisk/trunk/tests/channels/pjsip/ami/show_subscriptions/test-config.yaml 
> PRE-CREATION 
>   
> /asterisk/trunk/tests/channels/pjsip/ami/show_subscriptions/sipp/subscribe.xml
>  PRE-CREATION 
>   
> /asterisk/trunk/tests/channels/pjsip/ami/show_subscriptions/configs/ast1/voicemail.conf
>  PRE-CREATION 
>   
> /asterisk/trunk/tests/channels/pjsip/ami/show_subscriptions/configs/ast1/pjsip.conf
>  PRE-CREATION 
>   
> /asterisk/trunk/tests/channels/pjsip/ami/show_subscriptions/configs/ast1/extensions.conf
>  PRE-CREATION 
>   /asterisk/trunk/tests/channels/pjsip/ami/show_subscriptions/AMISendTest.py 
> PRE-CREATION 
>   
> /asterisk/trunk/tests/channels/pjsip/ami/show_registrations_outbound/test-config.yaml
>  PRE-CREATION 
>   
> /asterisk/trunk/tests/channels/pjsip/ami/show_registrations_outbound/configs/ast1/pjsip.conf
>  PRE-CREATION 
>   
> /asterisk/trunk/tests/channels/pjsip/ami/show_registrations_outbound/AMISendTest.py
>  PRE-CREATION 
>   
> /asterisk/trunk/tests/channels/pjsip/ami/show_registrations_inbound/test-config.yaml
>  PRE-CREATION 
>   
> /asterisk/trunk/tests/channels/pjsip/ami/show_registrations_inbound/configs/ast1/pjsip.conf
>  PRE-CREATION 
>   
> /asterisk/trunk/tests/channels/pjsip/ami/show_registrations_inbound/AMISendTest.py
>  PRE-CREATION 
>   /asterisk/trunk/tests/channels/pjsip/ami/show_endpoints/test-config.yaml 
> PRE-CREATION 
>   
> /asterisk/trunk/tests/channels/pjsip/ami/show_endpoints/configs/ast1/pjsip.conf
>  PRE-CREATION 
>   /asterisk/trunk/tests/channels/pjsip/ami/show_endpoints/AMISendTest.py 
> PRE-CREATION 
>   /asterisk/trunk/tests/channels/pjsip/ami/show_endpoint/test-config.yaml 
> PRE-CREATION 
>   
> /asterisk/trunk/tests/channels/pjsip/ami/show_endpoint/configs/ast1/pjsip.conf
>  PRE-CREATION 
>   /asterisk/trunk/tests/channels/pjsip/ami/show_endpoint/AMISendTest.py 
> PRE-CREATION 
> 
> Diff: https://reviewboard.asterisk.org/r/2958/diff/
> 
> 
> Testing
> ---
> 
> Ran tests and made sure they passed.
> 
> 
> Thanks,
> 
> Kevin Harwell
> 
>

-- 
_
-- 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] [Code Review] 3032: Testsuite: ARI device state

[Matt Jordan]

---
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/3032/#review10292
---



/asterisk/trunk/tests/rest_api/applications/subscribe-deviceState/subscribe_deviceState.py


What happens if these asserts fail?

Often, exceptions in twisted deferred callbacks have a tendency to get 
swallowed, particularly if there is no errback or an errback assigned that 
doesn't properly handle it. I'm curious if this actually triggers a test 
failure, or if you need to explicitly return False here.



/asterisk/trunk/tests/rest_api/applications/tests.yaml


Keeping with the other nomenclature, I'd rename this test to 
'subscribe-device-state'


- Matt Jordan


On Nov. 25, 2013, 6 p.m., Kevin Harwell wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/3032/
> ---
> 
> (Updated Nov. 25, 2013, 6 p.m.)
> 
> 
> Review request for Asterisk Developers.
> 
> 
> Bugs: ASTERISK-22838
> https://issues.asterisk.org/jira/browse/ASTERISK-22838
> 
> 
> Repository: testsuite
> 
> 
> Description
> ---
> 
> Tests to make sure a device state can be created, changed and deleted using 
> ARI.  Also tests to make make sure an application can [un]subscribe to device 
> state and receive change events.
> 
> 
> Diffs
> -
> 
>   /asterisk/trunk/tests/rest_api/tests.yaml 4366 
>   /asterisk/trunk/tests/rest_api/device_state/tests.yaml PRE-CREATION 
>   /asterisk/trunk/tests/rest_api/device_state/list/test-config.yaml 
> PRE-CREATION 
>   /asterisk/trunk/tests/rest_api/device_state/list/device_state.py 
> PRE-CREATION 
>   
> /asterisk/trunk/tests/rest_api/device_state/list/configs/ast1/extensions.conf 
> PRE-CREATION 
>   /asterisk/trunk/tests/rest_api/device_state/change/test-config.yaml 
> PRE-CREATION 
>   /asterisk/trunk/tests/rest_api/device_state/change/device_state.py 
> PRE-CREATION 
>   
> /asterisk/trunk/tests/rest_api/device_state/change/configs/ast1/extensions.conf
>  PRE-CREATION 
>   /asterisk/trunk/tests/rest_api/device_state/add_remove/test-config.yaml 
> PRE-CREATION 
>   /asterisk/trunk/tests/rest_api/device_state/add_remove/device_state.py 
> PRE-CREATION 
>   
> /asterisk/trunk/tests/rest_api/device_state/add_remove/configs/ast1/extensions.conf
>  PRE-CREATION 
>   /asterisk/trunk/tests/rest_api/device_state/add_invalid/test-config.yaml 
> PRE-CREATION 
>   /asterisk/trunk/tests/rest_api/device_state/add_invalid/device_state.py 
> PRE-CREATION 
>   
> /asterisk/trunk/tests/rest_api/device_state/add_invalid/configs/ast1/extensions.conf
>  PRE-CREATION 
>   /asterisk/trunk/tests/rest_api/applications/tests.yaml 4366 
>   
> /asterisk/trunk/tests/rest_api/applications/subscribe-deviceState/test-config.yaml
>  PRE-CREATION 
>   
> /asterisk/trunk/tests/rest_api/applications/subscribe-deviceState/subscribe_deviceState.py
>  PRE-CREATION 
>   
> /asterisk/trunk/tests/rest_api/applications/subscribe-deviceState/configs/ast1/extensions.conf
>  PRE-CREATION 
>   
> /asterisk/trunk/tests/rest_api/applications/subscribe-channel/subscribe_channel.py
>  4366 
>   
> /asterisk/trunk/tests/rest_api/applications/subscribe-bridge/test-config.yaml 
> 4366 
>   
> /asterisk/trunk/tests/rest_api/applications/subscribe-bridge/subscribe_bridge.py
>  4366 
>   /asterisk/trunk/lib/python/asterisk/ari.py 4366 
> 
> Diff: https://reviewboard.asterisk.org/r/3032/diff/
> 
> 
> Testing
> ---
> 
> Ran tests and made sure they passed.
> 
> 
> Thanks,
> 
> Kevin Harwell
> 
>

-- 
_
-- 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] SaySentence/SoundPack Proposal

[Tzafrir Cohen]

On Tue, Nov 26, 2013 at 10:04:58PM -0700, Steve Murphy wrote:
> Hello--
> 
> Boy, it's been a long time since I posted to the dev mailing list!
> 
> I'd like to announce a proposal to the Asterisk Community, that I
> introduced at Astridevcon last month. It is a new API for playing sound
> files (mainly speech). A pdf describing the Proposal in some detail is at:
> 
> http://www.gmvoices.com/downloads/steve/sayscripts.pdf

My initial reaction to this is that it is a reimplementation of
text-to-speech.

It also removes some existing functionality (saying a date and such).

The proposal also ignores say.conf . When talking with Steve at the
DevConf I made the mistake of assuming that as say.conf is only
referenced in app_playback, it is only used by Playback(), which is not
the case.

Languages in say.conf:

$ grep '^\[' configs/say.conf.sample
[general]
[digit-base](!) ; base rule for digit strings
[date-base](!)  ; base rules for dates and times
[en-base](!)
[en_GB](date-base,digit-base,en-base)
[it](digit-base,date-base)
[en](en-base,date-base,digit-base)
[de](date-base,digit-base)
[hu](digit-base,date-base)
[fr](date-base,digit-base)
[es](date-base,digit-base)
[da](date-base,digit-base)

Why isn't it more commonly used?

(On a personal note: writing the language support is a nice janitorial
task for a native speaker of the language with a moderate level of C, as
it easy to test and has no inherent concurrency issues)

-- 
   Tzafrir Cohen
icq#16849755  jabber:tzafrir.co...@xorcom.com
+972-50-7952406   mailto:tzafrir.co...@xorcom.com
http://www.xorcom.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

Re: [asterisk-dev] [Code Review] 2993: testsuite: Tests for form and JSON request bodies with ARI

[David Lee]

---
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/2993/
---

(Updated Nov. 27, 2013, 9:51 a.m.)


Status
--

This change has been marked as submitted.


Review request for Asterisk Developers.


Changes
---

Committed in revision 4379


Bugs: ASTERISK-22685 and ASTERISK-22743
https://issues.asterisk.org/jira/browse/ASTERISK-22685
https://issues.asterisk.org/jira/browse/ASTERISK-22743


Repository: testsuite


Description
---

This patch adds testsuite tests for form request bodies (content type
application/x-www-form-urlencoded) and JSON request bodies.

Since we're testing lower level ARI functionality, this is a test
using a simple Python script using requests to hit the API directly,
instead of our ARI test suite abstraction.


Diffs
-

  /asterisk/trunk/tests/rest_api/tests.yaml 4325 
  
/asterisk/team/dlee/ari-req-bodies/tests/rest_api/request-bodies/test-config.yaml
 PRE-CREATION 
  /asterisk/team/dlee/ari-req-bodies/tests/rest_api/request-bodies/run-test 
PRE-CREATION 

Diff: https://reviewboard.asterisk.org/r/2993/diff/


Testing
---

The test passes.

See https://reviewboard.asterisk.org/r/2994/ and
https://reviewboard.asterisk.org/r/2993/.


Thanks,

David Lee

-- 
_
-- 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] [Code Review] 2994: ari:Add application/json parameter support

[David Lee]

---
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/2994/
---

(Updated Nov. 27, 2013, 9:39 a.m.)


Status
--

This change has been marked as submitted.


Review request for Asterisk Developers and Paul Belanger.


Changes
---

Committed in revision 403175


Bugs: ASTERISK-22685
https://issues.asterisk.org/jira/browse/ASTERISK-22685


Repository: Asterisk


Description
---

The patch allows ARI to parse request parameters from an incoming JSON
request body, instead of requiring the request to come in as query
parameters (which is just weird for POST and DELETE) or form
parameters (which is okay, but a bit asymmetric given that all of our
responses are JSON).

For any operation that does _not_ have a parameter defined of type
body (i.e. "paramType": "body" in the API declaration), if a request
provides a request body with a Content type of "application/json", the
provided JSON document is parsed and searched for parameters.

The expected fields in the provided JSON document should match the
query parameters defined for the operation. If the parameter has
'allowMultiple' set, then the field in the JSON document may
optionally be an array of values.


Diffs
-

  /branches/12/tests/test_ari.c 402455 
  /branches/12/rest-api-templates/swagger_model.py 402455 
  /branches/12/rest-api-templates/res_ari_resource.c.mustache 402455 
  /branches/12/rest-api-templates/param_parsing.mustache 402455 
  /branches/12/rest-api-templates/asterisk_processor.py 402455 
  /branches/12/res/res_ari_sounds.c 402455 
  /branches/12/res/res_ari_recordings.c 402455 
  /branches/12/res/res_ari_playback.c 402455 
  /branches/12/res/res_ari_endpoints.c 402455 
  /branches/12/res/res_ari_channels.c 402455 
  /branches/12/res/res_ari_bridges.c 402455 
  /branches/12/res/res_ari_asterisk.c 402455 
  /branches/12/res/res_ari_applications.c 402455 
  /branches/12/res/res_ari.c 402455 
  /branches/12/main/http.c 402455 
  /branches/12/include/asterisk/http.h 402455 
  /branches/12/include/asterisk/ari.h 402455 

Diff: https://reviewboard.asterisk.org/r/2994/diff/


Testing
---

Testsuite test.

See https://reviewboard.asterisk.org/r/2993/


Thanks,

David Lee

-- 
_
-- 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] [Code Review] 2993: testsuite: Tests for form and JSON request bodies with ARI

[David Lee]

---
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/2993/
---

(Updated Nov. 27, 2013, 9:36 a.m.)


Status
--

This change has been marked as submitted.


Review request for Asterisk Developers.


Changes
---

Committed in revision 403175


Bugs: ASTERISK-22685 and ASTERISK-22743
https://issues.asterisk.org/jira/browse/ASTERISK-22685
https://issues.asterisk.org/jira/browse/ASTERISK-22743


Repository: testsuite


Description
---

This patch adds testsuite tests for form request bodies (content type
application/x-www-form-urlencoded) and JSON request bodies.

Since we're testing lower level ARI functionality, this is a test
using a simple Python script using requests to hit the API directly,
instead of our ARI test suite abstraction.


Diffs
-

  /asterisk/trunk/tests/rest_api/tests.yaml 4325 
  
/asterisk/team/dlee/ari-req-bodies/tests/rest_api/request-bodies/test-config.yaml
 PRE-CREATION 
  /asterisk/team/dlee/ari-req-bodies/tests/rest_api/request-bodies/run-test 
PRE-CREATION 

Diff: https://reviewboard.asterisk.org/r/2993/diff/


Testing
---

The test passes.

See https://reviewboard.asterisk.org/r/2994/ and
https://reviewboard.asterisk.org/r/2993/.


Thanks,

David Lee

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