date:20140722


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

Ship it!


Couple minor comment issues, otherwise looks good to go!


trunk/include/asterisk/xmldoc.h


Missing '*' at the beginning.



trunk/include/asterisk/xmldoc.h


Let's loose the '?'



trunk/include/asterisk/xmldoc.h


Same.


- Corey Farrell


On July 22, 2014, 10:42 p.m., opticron wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/3812/
> ---
> 
> (Updated July 22, 2014, 10:42 p.m.)
> 
> 
> Review request for Asterisk Developers.
> 
> 
> Repository: Asterisk
> 
> 
> Description
> ---
> 
> Allow for responses to AMI actions/commands to be documented properly in XML 
> and displayed via the CLI. Response events are documented exactly as standard 
> AMI events are documented.
> 
> 
> Diffs
> -
> 
>   trunk/main/xmldoc.c 419221 
>   trunk/main/manager_bridges.c 419221 
>   trunk/main/manager.c 419221 
>   trunk/main/config_options.c 419221 
>   trunk/include/asterisk/xmldoc.h 419221 
>   trunk/include/asterisk/manager.h 419221 
>   trunk/doc/appdocsxml.dtd 419221 
> 
> Diff: https://reviewboard.asterisk.org/r/3812/diff/
> 
> 
> Testing
> ---
> 
> The BridgeInfo AMI command was documented and tested as an example.
> 
> 
> Thanks,
> 
> opticron
> 
>

-- 
_
-- 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] 3812: AMI: Allow for response documentation


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

(Updated July 22, 2014, 9:42 p.m.)


Review request for Asterisk Developers.


Changes
---

Updated patch with listified ast_xml_doc_item.


Repository: Asterisk


Description
---

Allow for responses to AMI actions/commands to be documented properly in XML 
and displayed via the CLI. Response events are documented exactly as standard 
AMI events are documented.


Diffs (updated)
-

  trunk/main/xmldoc.c 419221 
  trunk/main/manager_bridges.c 419221 
  trunk/main/manager.c 419221 
  trunk/main/config_options.c 419221 
  trunk/include/asterisk/xmldoc.h 419221 
  trunk/include/asterisk/manager.h 419221 
  trunk/doc/appdocsxml.dtd 419221 

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


Testing
---

The BridgeInfo AMI command was documented and tested as an example.


Thanks,

opticron

-- 
_
-- 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] 3834: chan_sip: sip_subscribe_mwi_destroy should not call sip_destroy


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

Ship it!


Ship It!

- opticron


On July 21, 2014, 10:57 p.m., Corey Farrell wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/3834/
> ---
> 
> (Updated July 21, 2014, 10:57 p.m.)
> 
> 
> Review request for Asterisk Developers.
> 
> 
> Bugs: ASTERISK-24087
> https://issues.asterisk.org/jira/browse/ASTERISK-24087
> 
> 
> Repository: Asterisk
> 
> 
> Description
> ---
> 
> sip_subscribe_mwi_destroy calls sip_destroy on the reference counted 
> mwi->call.  This results in the fields of mwi->call being freed, but 
> mwi->call itself it leaked.  Also if other code is still using mwi->call it 
> can cause problems.  This change uses dialog_unref instead, to balance the 
> ref provided by sip_alloc().
> 
> 
> Diffs
> -
> 
>   /branches/1.8/channels/chan_sip.c 418992 
> 
> Diff: https://reviewboard.asterisk.org/r/3834/diff/
> 
> 
> Testing
> ---
> 
> None
> 
> 
> Thanks,
> 
> Corey Farrell
> 
>

-- 
_
-- 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] 3812: AMI: Allow for response documentation


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

Ship it!


Please see that the xml_doc_item list code be fixed to use standard list or 
vector macro's prior to release of 13.

- Corey Farrell


On July 22, 2014, 7:01 p.m., opticron wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/3812/
> ---
> 
> (Updated July 22, 2014, 7:01 p.m.)
> 
> 
> Review request for Asterisk Developers.
> 
> 
> Repository: Asterisk
> 
> 
> Description
> ---
> 
> Allow for responses to AMI actions/commands to be documented properly in XML 
> and displayed via the CLI. Response events are documented exactly as standard 
> AMI events are documented.
> 
> 
> Diffs
> -
> 
>   trunk/main/xmldoc.c 419221 
>   trunk/main/manager_bridges.c 419221 
>   trunk/main/manager.c 419221 
>   trunk/include/asterisk/xmldoc.h 419221 
>   trunk/include/asterisk/manager.h 419221 
>   trunk/doc/appdocsxml.dtd 419221 
> 
> Diff: https://reviewboard.asterisk.org/r/3812/diff/
> 
> 
> Testing
> ---
> 
> The BridgeInfo AMI command was documented and tested as an example.
> 
> 
> Thanks,
> 
> opticron
> 
>

-- 
_
-- 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] 3831: res_fax: unregister manager actions on unload


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

(Updated July 22, 2014, 8:29 p.m.)


Status
--

This change has been marked as submitted.


Review request for Asterisk Developers.


Changes
---

Committed in revision 419268


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


Repository: Asterisk


Description
---

Unregisters manager actions FAXSessions, FAXSession and FAXStats at shutdown.

Additionally make ast_manager_register2 use ao2_t_alloc with the action name 
for the tag, to make it easier to track leaks like this in the future.


Diffs
-

  /trunk/res/res_fax.c 419018 
  /trunk/main/manager.c 419018 

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


Testing
---

Verified that tests/manager/originate no longer produces REF_DEBUG leaks.


Thanks,

Corey Farrell

-- 
_
-- 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] 3832: testsuite: Accountcode propagation.


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

(Updated July 22, 2014, 8:13 p.m.)


Review request for Asterisk Developers.


Changes
---

Addressed review feedback including eliminating the Wait. :)


Bugs: AFS-65
https://issues.asterisk.org/jira/browse/AFS-65


Repository: testsuite


Description
---

New tests to check accountcode propagation with the new accouncode/peeracccount 
interaction.

* Made pluggable_modules.py Originator class and test_case.py
SimpleTestCase class call origination allow specifying the accountcode.

* Fix tests/cdr/sqlite3 to work with the new accountcode propagation rules.

* Add accountcode tag to existing tests doing something with accountcode.

Testsuite tests to go with https://reviewboard.asterisk.org/r/3601/


Diffs (updated)
-

  /asterisk/trunk/tests/pbx/tests.yaml 5295 
  /asterisk/trunk/tests/pbx/accountcode/tests.yaml PRE-CREATION 
  /asterisk/trunk/tests/pbx/accountcode/queue_peer_preserve/test-config.yaml 
PRE-CREATION 
  
/asterisk/trunk/tests/pbx/accountcode/queue_peer_preserve/configs/ast1/queues.conf
 PRE-CREATION 
  
/asterisk/trunk/tests/pbx/accountcode/queue_peer_preserve/configs/ast1/pjsip.conf
 PRE-CREATION 
  
/asterisk/trunk/tests/pbx/accountcode/queue_peer_preserve/configs/ast1/extensions.conf
 PRE-CREATION 
  /asterisk/trunk/tests/pbx/accountcode/queue_peer_none/test-config.yaml 
PRE-CREATION 
  
/asterisk/trunk/tests/pbx/accountcode/queue_peer_none/configs/ast1/queues.conf 
PRE-CREATION 
  /asterisk/trunk/tests/pbx/accountcode/queue_peer_none/configs/ast1/pjsip.conf 
PRE-CREATION 
  
/asterisk/trunk/tests/pbx/accountcode/queue_peer_none/configs/ast1/extensions.conf
 PRE-CREATION 
  /asterisk/trunk/tests/pbx/accountcode/queue_none/test-config.yaml 
PRE-CREATION 
  /asterisk/trunk/tests/pbx/accountcode/queue_none/configs/ast1/queues.conf 
PRE-CREATION 
  /asterisk/trunk/tests/pbx/accountcode/queue_none/configs/ast1/pjsip.conf 
PRE-CREATION 
  /asterisk/trunk/tests/pbx/accountcode/queue_none/configs/ast1/extensions.conf 
PRE-CREATION 
  /asterisk/trunk/tests/pbx/accountcode/local_originate/test-config.yaml 
PRE-CREATION 
  
/asterisk/trunk/tests/pbx/accountcode/local_originate/configs/ast1/extensions.conf
 PRE-CREATION 
  /asterisk/trunk/tests/pbx/accountcode/local_crossover_back/test-config.yaml 
PRE-CREATION 
  
/asterisk/trunk/tests/pbx/accountcode/local_crossover_back/configs/ast1/extensions.conf
 PRE-CREATION 
  /asterisk/trunk/tests/pbx/accountcode/local_crossover/test-config.yaml 
PRE-CREATION 
  
/asterisk/trunk/tests/pbx/accountcode/local_crossover/configs/ast1/extensions.conf
 PRE-CREATION 
  /asterisk/trunk/tests/pbx/accountcode/dial_straight_override/test-config.yaml 
PRE-CREATION 
  
/asterisk/trunk/tests/pbx/accountcode/dial_straight_override/configs/ast1/pjsip.conf
 PRE-CREATION 
  
/asterisk/trunk/tests/pbx/accountcode/dial_straight_override/configs/ast1/extensions.conf
 PRE-CREATION 
  /asterisk/trunk/tests/pbx/accountcode/dial_straight_none/test-config.yaml 
PRE-CREATION 
  
/asterisk/trunk/tests/pbx/accountcode/dial_straight_none/configs/ast1/pjsip.conf
 PRE-CREATION 
  
/asterisk/trunk/tests/pbx/accountcode/dial_straight_none/configs/ast1/extensions.conf
 PRE-CREATION 
  /asterisk/trunk/tests/pbx/accountcode/dial_predial/test-config.yaml 
PRE-CREATION 
  /asterisk/trunk/tests/pbx/accountcode/dial_predial/configs/ast1/pjsip.conf 
PRE-CREATION 
  
/asterisk/trunk/tests/pbx/accountcode/dial_predial/configs/ast1/extensions.conf 
PRE-CREATION 
  /asterisk/trunk/tests/pbx/accountcode/dial_peer_override/test-config.yaml 
PRE-CREATION 
  
/asterisk/trunk/tests/pbx/accountcode/dial_peer_override/configs/ast1/pjsip.conf
 PRE-CREATION 
  
/asterisk/trunk/tests/pbx/accountcode/dial_peer_override/configs/ast1/extensions.conf
 PRE-CREATION 
  /asterisk/trunk/tests/pbx/accountcode/dial_peer_none/test-config.yaml 
PRE-CREATION 
  /asterisk/trunk/tests/pbx/accountcode/dial_peer_none/configs/ast1/pjsip.conf 
PRE-CREATION 
  
/asterisk/trunk/tests/pbx/accountcode/dial_peer_none/configs/ast1/extensions.conf
 PRE-CREATION 
  /asterisk/trunk/tests/pbx/accountcode/dial_none/test-config.yaml PRE-CREATION 
  /asterisk/trunk/tests/pbx/accountcode/dial_none/configs/ast1/pjsip.conf 
PRE-CREATION 
  /asterisk/trunk/tests/pbx/accountcode/dial_none/configs/ast1/extensions.conf 
PRE-CREATION 
  /asterisk/trunk/tests/cdr/sqlite3/test-config.yaml 5295 
  /asterisk/trunk/tests/cdr/console_dial_sip_transfer/test-config.yaml 5295 
  /asterisk/trunk/tests/cdr/console_dial_sip_congestion/test-config.yaml 5295 
  /asterisk/trunk/tests/cdr/console_dial_sip_busy/test-config.yaml 5295 
  /asterisk/trunk/tests/cdr/console_dial_sip_answer/test-config.yaml 5295 
  /asterisk/trunk/tests/cdr/cdr_unanswered_yes/test-config.yaml 5295 
  /asterisk/trunk/tests/cdr/cdr_properties/cdr_accountcode/

Re: [asterisk-dev] [Code Review] 3759: chan_sip: upgrade registry and mwi object to ao2


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

(Updated July 22, 2014, 8:54 p.m.)


Review request for Asterisk Developers.


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


Repository: Asterisk


Description
---

Upgrade all ASTOBJ objects in chan_sip to ao2.


Diffs (updated)
-

  /trunk/channels/sip/include/sip.h 419127 
  /trunk/channels/chan_sip.c 419127 

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


Testing
---

Full testsuite run.


Thanks,

Corey Farrell

-- 
_
-- 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] 3759: chan_sip: upgrade registry and mwi object to ao2


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

Ship it!


Minor spacing nit.


/trunk/channels/chan_sip.c


While body appears indented too far.


- rmudgett


On July 22, 2014, 7:27 p.m., Corey Farrell wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/3759/
> ---
> 
> (Updated July 22, 2014, 7:27 p.m.)
> 
> 
> Review request for Asterisk Developers.
> 
> 
> Bugs: ASTERISK-24067
> https://issues.asterisk.org/jira/browse/ASTERISK-24067
> 
> 
> Repository: Asterisk
> 
> 
> Description
> ---
> 
> Upgrade all ASTOBJ objects in chan_sip to ao2.
> 
> 
> Diffs
> -
> 
>   /trunk/channels/sip/include/sip.h 419127 
>   /trunk/channels/chan_sip.c 419127 
> 
> Diff: https://reviewboard.asterisk.org/r/3759/diff/
> 
> 
> Testing
> ---
> 
> Full testsuite run.
> 
> 
> Thanks,
> 
> Corey Farrell
> 
>

-- 
_
-- 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] 3759: chan_sip: upgrade registry and mwi object to ao2


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

(Updated July 22, 2014, 8:27 p.m.)


Review request for Asterisk Developers.


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


Repository: Asterisk


Description
---

Upgrade all ASTOBJ objects in chan_sip to ao2.


Diffs (updated)
-

  /trunk/channels/sip/include/sip.h 419127 
  /trunk/channels/chan_sip.c 419127 

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


Testing
---

Full testsuite run.


Thanks,

Corey Farrell

-- 
_
-- 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] 3759: chan_sip: upgrade registry and mwi object to ao2


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



/trunk/channels/chan_sip.c


Try -1 instead :)


- rmudgett


On July 22, 2014, 5:01 p.m., Corey Farrell wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/3759/
> ---
> 
> (Updated July 22, 2014, 5:01 p.m.)
> 
> 
> Review request for Asterisk Developers.
> 
> 
> Bugs: ASTERISK-24067
> https://issues.asterisk.org/jira/browse/ASTERISK-24067
> 
> 
> Repository: Asterisk
> 
> 
> Description
> ---
> 
> Upgrade all ASTOBJ objects in chan_sip to ao2.
> 
> 
> Diffs
> -
> 
>   /trunk/channels/sip/include/sip.h 419127 
>   /trunk/channels/chan_sip.c 419127 
> 
> Diff: https://reviewboard.asterisk.org/r/3759/diff/
> 
> 
> Testing
> ---
> 
> Full testsuite run.
> 
> 
> Thanks,
> 
> Corey Farrell
> 
>

-- 
_
-- 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] 3812: AMI: Allow for response documentation


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

(Updated July 22, 2014, 6:01 p.m.)


Review request for Asterisk Developers.


Changes
---

Address Corey's comments.


Repository: Asterisk


Description
---

Allow for responses to AMI actions/commands to be documented properly in XML 
and displayed via the CLI. Response events are documented exactly as standard 
AMI events are documented.


Diffs (updated)
-

  trunk/main/xmldoc.c 419221 
  trunk/main/manager_bridges.c 419221 
  trunk/main/manager.c 419221 
  trunk/include/asterisk/xmldoc.h 419221 
  trunk/include/asterisk/manager.h 419221 
  trunk/doc/appdocsxml.dtd 419221 

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


Testing
---

The BridgeInfo AMI command was documented and tested as an example.


Thanks,

opticron

-- 
_
-- 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] 3812: AMI: Allow for response documentation



> On July 22, 2014, 5:29 p.m., Corey Farrell wrote:
> > trunk/main/xmldoc.c, lines 2182-2188
> > 
> >
> > This seems to break the guideline of not doing adhoc list code.  If 
> > this can be fixed without much trouble please do so.  I suspect this is due 
> > to the way that ast_xml_doc_item is written in which case you can ignore 
> > this comment.

This type of code is pretty prevalent in config_options.c. I'll see what I can 
do after I address the other issues and update the patch.


- opticron


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


On July 18, 2014, 2:57 p.m., opticron wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/3812/
> ---
> 
> (Updated July 18, 2014, 2:57 p.m.)
> 
> 
> Review request for Asterisk Developers.
> 
> 
> Repository: Asterisk
> 
> 
> Description
> ---
> 
> Allow for responses to AMI actions/commands to be documented properly in XML 
> and displayed via the CLI. Response events are documented exactly as standard 
> AMI events are documented.
> 
> 
> Diffs
> -
> 
>   trunk/main/xmldoc.c 418964 
>   trunk/main/manager_bridges.c 418964 
>   trunk/main/manager.c 418964 
>   trunk/include/asterisk/xmldoc.h 418964 
>   trunk/include/asterisk/manager.h 418964 
>   trunk/doc/appdocsxml.dtd 418964 
> 
> Diff: https://reviewboard.asterisk.org/r/3812/diff/
> 
> 
> Testing
> ---
> 
> The BridgeInfo AMI command was documented and tested as an example.
> 
> 
> Thanks,
> 
> opticron
> 
>

-- 
_
-- 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] 3673: RLS: Nominal list tests

2014-07-22 Thread Jonathan Rose


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



/asterisk/team/group/rls-tests/tests/channels/pjsip/subscriptions/rls/lists/nominal/presence/initial_notify/notify.py


Things get a little hairy here on shutdown.  After Asterisk starts shutting 
down, it sends out two additional notifies, each containing different data than 
what we sent out on the first notify (which mostly passes the validator as 
is... with some minor tweaking). This causes the test to fail after we already 
suggested it's finished, which is no fun.  Easy solution to that is to pull the 
callback (right now there isn't a clean way of doing that, but it's a fairly 
easy addition if you just want to remove all callbacks of a certain packet 
type) after it's finished or else have something in place to mark the callback 
for already being complete and to return early on subsequent calls.


- Jonathan Rose


On July 7, 2014, 10:43 a.m., Mark Michelson wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/3673/
> ---
> 
> (Updated July 7, 2014, 10:43 a.m.)
> 
> 
> Review request for Asterisk Developers.
> 
> 
> Bugs: ASTERISK-23870
> https://issues.asterisk.org/jira/browse/ASTERISK-23870
> 
> 
> Repository: testsuite
> 
> 
> Description
> ---
> 
> This changeset implements the nominal resource list tests outlined on this 
> page: 
> https://wiki.asterisk.org/wiki/display/AST/Resource+List+Subscription+Test+Plan
> 
> There are six tests:
> 1. Subscription Establishment: Simply ensures that Asterisk responds with a 
> 200 OK when we subscribe to a resource list and that the 200 OK has a 
> Require: eventlist header in it.
> 2. Initial NOTIFY: Validates the initial NOTIFY body that Asterisk sends when 
> subscribing to a resource list.
> 3. Full State: Establishes a subscription to a resource list and then changes 
> the state of a resource. Ensures that Asterisk sends a NOTIFY with full state 
> of the list.
> 4. Partial State: Establishes a subscription to a resource list and then 
> changes the state of a resource. Ensures that Asterisk sends a NOTIFY with 
> partial state, with only the state of the resource whose state was changed.
> 5. Resubscription Full State: Establishes a subscription and then 
> resubscribes. Ensures that even though partial state is configured, the 
> NOTIFY that Asterisk sends in response to the resubscription has full state 
> of the list.
> 6. Termination Full State: Establishes a subscription and then terminates the 
> subscription. Ensures that even though partial state is configured, the 
> NOTIFY that Asterisk sends in response to the termination has full state of 
> the list.
> 
> 
> Diffs
> -
> 
>   
> /asterisk/team/group/rls-tests/tests/channels/pjsip/subscriptions/tests.yaml 
> 5168 
>   
> /asterisk/team/group/rls-tests/tests/channels/pjsip/subscriptions/rls/tests.yaml
>  PRE-CREATION 
>   
> /asterisk/team/group/rls-tests/tests/channels/pjsip/subscriptions/rls/rls_integrity.py
>  PRE-CREATION 
>   
> /asterisk/team/group/rls-tests/tests/channels/pjsip/subscriptions/rls/lists/tests.yaml
>  PRE-CREATION 
>   
> /asterisk/team/group/rls-tests/tests/channels/pjsip/subscriptions/rls/lists/nominal/tests.yaml
>  PRE-CREATION 
>   
> /asterisk/team/group/rls-tests/tests/channels/pjsip/subscriptions/rls/lists/nominal/presence/termination_full_state/test-config.yaml
>  PRE-CREATION 
>   
> /asterisk/team/group/rls-tests/tests/channels/pjsip/subscriptions/rls/lists/nominal/presence/termination_full_state/termination.py
>  PRE-CREATION 
>   
> /asterisk/team/group/rls-tests/tests/channels/pjsip/subscriptions/rls/lists/nominal/presence/termination_full_state/sipp/termination.xml
>  PRE-CREATION 
>   
> /asterisk/team/group/rls-tests/tests/channels/pjsip/subscriptions/rls/lists/nominal/presence/termination_full_state/configs/ast1/pjsip.conf
>  PRE-CREATION 
>   
> /asterisk/team/group/rls-tests/tests/channels/pjsip/subscriptions/rls/lists/nominal/presence/termination_full_state/configs/ast1/extensions.conf
>  PRE-CREATION 
>   
> /asterisk/team/group/rls-tests/tests/channels/pjsip/subscriptions/rls/lists/nominal/presence/subscription_establishment/test-config.yaml
>  PRE-CREATION 
>   
> /asterisk/team/group/rls-tests/tests/channels/pjsip/subscriptions/rls/lists/nominal/presence/subscription_establishment/sipp/list_subscribe.xml
>  PRE-CREATION 
>   
> /asterisk/team/group/rls-tests/tests/channels/pjsip/subscriptions/rls/lists/nominal/presence/subscription_establishment/configs/ast1/pjsip.conf
>  PRE-CREATION 
>   
> /asterisk/team/group/rls-tests/tests/channels/pjsip/subscriptions/rls/lists/n

Re: [asterisk-dev] [Code Review] 3812: AMI: Allow for response documentation

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

trunk/include/asterisk/manager.h

I'd say remove 'Possible'.  There should always be a single final_response 
if the response is documented - unless I'm misreading this is enforced by XML 
schema.  Also s/events/event/.

trunk/main/xmldoc.c

Moving your new procedures later in the file can probably avoid this 
forward declaration.  If not it should be moved toward the top of the file.

trunk/main/xmldoc.c

Tab between param name and description?

trunk/main/xmldoc.c

_ast_ prefix is listed in main/asterisk.exports so it should not be used 
for static procedures.  I think xmldoc_build_list_responses would be good.

trunk/main/xmldoc.c

This seems to break the guideline of not doing adhoc list code.  If this 
can be fixed without much trouble please do so.  I suspect this is due to the 
way that ast_xml_doc_item is written in which case you can ignore this comment.

trunk/main/xmldoc.c

Tab between parameter name and description?

trunk/main/xmldoc.c

Please remove _ast_ prefix.

- Corey Farrell

On July 18, 2014, 3:57 p.m., opticron wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/3812/
> ---
> 
> (Updated July 18, 2014, 3:57 p.m.)
> 
> 
> Review request for Asterisk Developers.
> 
> 
> Repository: Asterisk
> 
> 
> Description
> ---
> 
> Allow for responses to AMI actions/commands to be documented properly in XML 
> and displayed via the CLI. Response events are documented exactly as standard 
> AMI events are documented.
> 
> 
> Diffs
> -
> 
>   trunk/main/xmldoc.c 418964 
>   trunk/main/manager_bridges.c 418964 
>   trunk/main/manager.c 418964 
>   trunk/include/asterisk/xmldoc.h 418964 
>   trunk/include/asterisk/manager.h 418964 
>   trunk/doc/appdocsxml.dtd 418964 
> 
> Diff: https://reviewboard.asterisk.org/r/3812/diff/
> 
> 
> Testing
> ---
> 
> The BridgeInfo AMI command was documented and tested as an example.
> 
> 
> Thanks,
> 
> opticron
> 
>

-- 
_
-- 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] 3759: chan_sip: upgrade registry and mwi object to ao2



> On July 22, 2014, 12:24 p.m., rmudgett wrote:
> > /trunk/channels/chan_sip.c, lines 15568-15571
> > 
> >
> > Something seems off here.  The ao2_t_ref() calls return ints and are 
> > parameters to AST_SCHED_REPLACE_UNREF().  Didn't registry_unref() return a 
> > pointer?
> >
> 
> opticron wrote:
> The scheduler macros don't actually use return values for any of these. 
> They exist only to ref or unref the given variable if the scheduler macro 
> deems it necessary.

I know it looks weird, but opticron is right.  These "parameters" are actually 
code injection, not values.


> On July 22, 2014, 12:24 p.m., rmudgett wrote:
> > /trunk/channels/chan_sip.c, line 8830
> > 
> >
> > Where are file, line, and func coming from?  They don't seem to be 
> > passed in to sip_alloc.

This was never meant to be submitted, was part of some debug code I was using 
in an attempt to find a memory leak (not caused by this change).


- Corey


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


On July 22, 2014, 6:01 p.m., Corey Farrell wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/3759/
> ---
> 
> (Updated July 22, 2014, 6:01 p.m.)
> 
> 
> Review request for Asterisk Developers.
> 
> 
> Bugs: ASTERISK-24067
> https://issues.asterisk.org/jira/browse/ASTERISK-24067
> 
> 
> Repository: Asterisk
> 
> 
> Description
> ---
> 
> Upgrade all ASTOBJ objects in chan_sip to ao2.
> 
> 
> Diffs
> -
> 
>   /trunk/channels/sip/include/sip.h 419127 
>   /trunk/channels/chan_sip.c 419127 
> 
> Diff: https://reviewboard.asterisk.org/r/3759/diff/
> 
> 
> Testing
> ---
> 
> Full testsuite run.
> 
> 
> Thanks,
> 
> Corey Farrell
> 
>

-- 
_
-- 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] 3759: chan_sip: upgrade registry and mwi object to ao2


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

(Updated July 22, 2014, 6:01 p.m.)


Review request for Asterisk Developers.


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


Repository: Asterisk


Description
---

Upgrade all ASTOBJ objects in chan_sip to ao2.


Diffs (updated)
-

  /trunk/channels/sip/include/sip.h 419127 
  /trunk/channels/chan_sip.c 419127 

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


Testing
---

Full testsuite run.


Thanks,

Corey Farrell

-- 
_
-- 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] 3839: Added a test to check the duration and energy_duration values of an ARI recording


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

(Updated July 22, 2014, 8:59 p.m.)


Review request for Asterisk Developers.


Changes
---

For some reason, the dependency was removed.


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


Repository: testsuite


Description
---

Test checks whether the duration and energy_duration of a recording created in 
ARI are both valid.  One local channel half in ARI plays back 2 seconds worth 
of sound (tt-somethingwrong), plays two seconds worth of silence (silence/2), 
and then plays the first sound again.  The other local channel half records 
these sounds as they are played.  The total duration of the recorded sound file 
should be 6 seconds, while the energy_duration should be 4 seconds.  When this 
gets verified, the SoundChecker pluggable module gets called and the sound 
file's size (should be around 96,000 bytes) gets verified, as well as the sound 
file's energy levels using BackgroundDetect.  Since the SoundChecker pluggable 
module hasn't received a Ship It! yet, a dependency has been added accordingly.


Diffs
-

  /asterisk/trunk/tests/rest_api/recording/tests.yaml 5249 
  /asterisk/trunk/tests/rest_api/recording/duration/test-config.yaml 
PRE-CREATION 
  
/asterisk/trunk/tests/rest_api/recording/duration/configs/ast1/extensions.conf 
PRE-CREATION 

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


Testing
---

Checked whether the recording object did return the correct values in the log 
files.  One bottleneck to finishing this test was the fact that you had to add 
maxSilenceSeconds in the recording request in order to make energy_detection 
work AT ALL.  Other than that, this test was pretty straightforward and easy to 
write.


Thanks,

Christopher Wolfe

-- 
_
-- 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] 3839: Added a test to check the duration and energy_duration values of an ARI recording


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

(Updated July 22, 2014, 8:57 p.m.)


Review request for Asterisk Developers.


Changes
---

Changed the variable name to match the current state made by the patch.


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


Repository: testsuite


Description
---

Test checks whether the duration and energy_duration of a recording created in 
ARI are both valid.  One local channel half in ARI plays back 2 seconds worth 
of sound (tt-somethingwrong), plays two seconds worth of silence (silence/2), 
and then plays the first sound again.  The other local channel half records 
these sounds as they are played.  The total duration of the recorded sound file 
should be 6 seconds, while the energy_duration should be 4 seconds.  When this 
gets verified, the SoundChecker pluggable module gets called and the sound 
file's size (should be around 96,000 bytes) gets verified, as well as the sound 
file's energy levels using BackgroundDetect.  Since the SoundChecker pluggable 
module hasn't received a Ship It! yet, a dependency has been added accordingly.


Diffs (updated)
-

  /asterisk/trunk/tests/rest_api/recording/tests.yaml 5249 
  /asterisk/trunk/tests/rest_api/recording/duration/test-config.yaml 
PRE-CREATION 
  
/asterisk/trunk/tests/rest_api/recording/duration/configs/ast1/extensions.conf 
PRE-CREATION 

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


Testing
---

Checked whether the recording object did return the correct values in the log 
files.  One bottleneck to finishing this test was the fact that you had to add 
maxSilenceSeconds in the recording request in order to make energy_detection 
work AT ALL.  Other than that, this test was pretty straightforward and easy to 
write.


Thanks,

Christopher Wolfe

-- 
_
-- 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] 3839: Added a test to check the duration and energy_duration values of an ARI recording

2014-07-22 Thread Samuel Galarneau


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



/asterisk/trunk/tests/rest_api/recording/duration/test-config.yaml


energy_duration was renamed to talking_duration in the latest patch to add 
duration information to RecordingFinished events. This should be renamed.



/asterisk/trunk/tests/rest_api/recording/duration/test-config.yaml


energy_duration was renamed to talking_duration in the latest patch to add 
duration information to RecordingFinished events. This should be renamed.


- Samuel Galarneau


On July 22, 2014, 7:40 p.m., Christopher Wolfe wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/3839/
> ---
> 
> (Updated July 22, 2014, 7:40 p.m.)
> 
> 
> Review request for Asterisk Developers.
> 
> 
> Bugs: ASTERISK-24037
> https://issues.asterisk.org/jira/browse/ASTERISK-24037
> 
> 
> Repository: testsuite
> 
> 
> Description
> ---
> 
> Test checks whether the duration and energy_duration of a recording created 
> in ARI are both valid.  One local channel half in ARI plays back 2 seconds 
> worth of sound (tt-somethingwrong), plays two seconds worth of silence 
> (silence/2), and then plays the first sound again.  The other local channel 
> half records these sounds as they are played.  The total duration of the 
> recorded sound file should be 6 seconds, while the energy_duration should be 
> 4 seconds.  When this gets verified, the SoundChecker pluggable module gets 
> called and the sound file's size (should be around 96,000 bytes) gets 
> verified, as well as the sound file's energy levels using BackgroundDetect.  
> Since the SoundChecker pluggable module hasn't received a Ship It! yet, a 
> dependency has been added accordingly.
> 
> 
> Diffs
> -
> 
>   /asterisk/trunk/tests/rest_api/recording/tests.yaml 5249 
>   /asterisk/trunk/tests/rest_api/recording/duration/test-config.yaml 
> PRE-CREATION 
>   
> /asterisk/trunk/tests/rest_api/recording/duration/configs/ast1/extensions.conf
>  PRE-CREATION 
> 
> Diff: https://reviewboard.asterisk.org/r/3839/diff/
> 
> 
> Testing
> ---
> 
> Checked whether the recording object did return the correct values in the log 
> files.  One bottleneck to finishing this test was the fact that you had to 
> add maxSilenceSeconds in the recording request in order to make 
> energy_detection work AT ALL.  Other than that, this test was pretty 
> straightforward and easy to write.
> 
> 
> Thanks,
> 
> Christopher Wolfe
> 
>

-- 
_
-- 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] 3832: testsuite: Accountcode propagation.



> On July 22, 2014, 12:41 p.m., Matt Jordan wrote:
> > /asterisk/trunk/tests/pbx/accountcode/dial_none/configs/ast1/extensions.conf,
> >  lines 7-10
> > 
> >
> > Having to wait 5 seconds for this test to end when it has essentially 
> > completed is usually something we avoid.
> > 
> > There is another route you can take, however:
> > (1) Drop the channel into Echo after answering it
> > (2) Use the channel hangup module to hangup the channel on the Newexten 
> > event:
> > 
> > modules:
> > -
> > config-section: hangup-channel
> > typename: 'pluggable_modules.AMIChannelHangup'
> > 
> > hangup-channel:
> > id: '1'
> > conditions:
> > match:
> > Event: 'Newexten'
> > Channel: 'PJSIP/bob-.*'
> > Application: Echo
> > count: '1'
> > 
> > This also supports a 'delay' parameter in case the hangup *does* need 
> > to wait a second or two.
> > 
> > This finding would extend to the other tests that use the same pattern.

How is the 'delay' parameter any different than the Wait?  The Wait is to allow 
the answer to percolate back up the chain and to allow the channels to enter 
the bridge before hanging up.  Otherwise, the channels may not enter the bridge 
at all.


> On July 22, 2014, 12:41 p.m., Matt Jordan wrote:
> > /asterisk/trunk/tests/pbx/accountcode/dial_none/test-config.yaml, line 61
> > 
> >
> > I don't think you need the dependency on func_channel for this test.

With so many tests it was getting difficult to keep those dependencies 
straight. :)


- rmudgett


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


On July 21, 2014, 4:49 p.m., rmudgett wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/3832/
> ---
> 
> (Updated July 21, 2014, 4:49 p.m.)
> 
> 
> Review request for Asterisk Developers.
> 
> 
> Bugs: AFS-65
> https://issues.asterisk.org/jira/browse/AFS-65
> 
> 
> Repository: testsuite
> 
> 
> Description
> ---
> 
> New tests to check accountcode propagation with the new 
> accouncode/peeracccount interaction.
> 
> * Made pluggable_modules.py Originator class and test_case.py
> SimpleTestCase class call origination allow specifying the accountcode.
> 
> * Fix tests/cdr/sqlite3 to work with the new accountcode propagation rules.
> 
> * Add accountcode tag to existing tests doing something with accountcode.
> 
> Testsuite tests to go with https://reviewboard.asterisk.org/r/3601/
> 
> 
> Diffs
> -
> 
>   /asterisk/trunk/tests/pbx/tests.yaml 5288 
>   /asterisk/trunk/tests/pbx/accountcode/tests.yaml PRE-CREATION 
>   /asterisk/trunk/tests/pbx/accountcode/queue_peer_preserve/test-config.yaml 
> PRE-CREATION 
>   
> /asterisk/trunk/tests/pbx/accountcode/queue_peer_preserve/configs/ast1/queues.conf
>  PRE-CREATION 
>   
> /asterisk/trunk/tests/pbx/accountcode/queue_peer_preserve/configs/ast1/pjsip.conf
>  PRE-CREATION 
>   
> /asterisk/trunk/tests/pbx/accountcode/queue_peer_preserve/configs/ast1/extensions.conf
>  PRE-CREATION 
>   /asterisk/trunk/tests/pbx/accountcode/queue_peer_none/test-config.yaml 
> PRE-CREATION 
>   
> /asterisk/trunk/tests/pbx/accountcode/queue_peer_none/configs/ast1/queues.conf
>  PRE-CREATION 
>   
> /asterisk/trunk/tests/pbx/accountcode/queue_peer_none/configs/ast1/pjsip.conf 
> PRE-CREATION 
>   
> /asterisk/trunk/tests/pbx/accountcode/queue_peer_none/configs/ast1/extensions.conf
>  PRE-CREATION 
>   /asterisk/trunk/tests/pbx/accountcode/queue_none/test-config.yaml 
> PRE-CREATION 
>   /asterisk/trunk/tests/pbx/accountcode/queue_none/configs/ast1/queues.conf 
> PRE-CREATION 
>   /asterisk/trunk/tests/pbx/accountcode/queue_none/configs/ast1/pjsip.conf 
> PRE-CREATION 
>   
> /asterisk/trunk/tests/pbx/accountcode/queue_none/configs/ast1/extensions.conf 
> PRE-CREATION 
>   /asterisk/trunk/tests/pbx/accountcode/local_originate/test-config.yaml 
> PRE-CREATION 
>   
> /asterisk/trunk/tests/pbx/accountcode/local_originate/configs/ast1/extensions.conf
>  PRE-CREATION 
>   /asterisk/trunk/tests/pbx/accountcode/local_crossover_back/test-config.yaml 
> PRE-CREATION 
>   
> /asterisk/trunk/tests/pbx/accountcode/local_crossover_back/configs/ast1/extensions.conf
>  PRE-CREATION 
>   /asterisk/trunk/tests/pbx/accountcode/local_crossover/test-config.yaml 
> PRE-CREATION 
>   
> /asterisk/trunk/tests/pbx/accountcode/local_crossover/configs/ast1/extensions.conf
>  PRE-CREATION 
>   
> /aste

Re: [asterisk-dev] [Code Review] 3819: Substitute Variables In Features Application Map Before Execution

2014-07-22 Thread Michael Young


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

(Updated July 22, 2014, 3:22 p.m.)


Status
--

This change has been marked as submitted.


Review request for Asterisk Developers.


Changes
---

Committed in revision 419252


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


Repository: Asterisk


Description
---

Say you wanted to include variables in an application map and have those 
variables substituted and passed along to the application being executed; 
currently this does not happen.
This patch adds this new feature.

This simple patch was originally written for 1.4 but I have been maintaining it 
all the way up to version 11.  It is time to see if anyone else sees any value 
in this and get it committed.


Diffs
-

  /trunk/main/bridge_channel.c 418910 
  /trunk/CHANGES 418910 

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


Testing
---

This has been in production since 1.4 and updated for trunk.  The trunk version 
of the patch was tested on dev machine.


Thanks,

Michael Young

-- 
_
-- 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] 3836: app_bridgewait: Remove race condition where bridge may be dissolved when trying to join


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



/branches/12/apps/app_bridgewait.c


Should check if the bridge in the wrapper is dissolved before returning the 
wrapper.  If it is dissolved, the wrapper needs to be unlinked and a new bridge 
created.

Some joker could CLI "bridge destroy " the BridgeWait holding bridge.  
This would prevent new channels from entering the BridgeWait holding bridge 
until all channels that entered the bridging system in that holding bridge 
hangup.  It could take awhile if a channel was moved to a normal bridge.


- rmudgett


On July 22, 2014, 10:14 a.m., Joshua Colp wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/3836/
> ---
> 
> (Updated July 22, 2014, 10:14 a.m.)
> 
> 
> Review request for Asterisk Developers.
> 
> 
> Bugs: ASTERISK-23987
> https://issues.asterisk.org/jira/browse/ASTERISK-23987
> 
> 
> Repository: Asterisk
> 
> 
> Description
> ---
> 
> The BridgeWait application currently creates bridges with the dissolve on 
> empty flag set. This causes the bridge to be dissolved when the last channel 
> leaves it. This introduces a race condition where another channel may be 
> trying to join during this, causing it to fail. Since the lifetime of the 
> bridge is already associated with the bridge wrapper the bridge does not need 
> the dissolve on empty flag set. When the last reference goes away the bridge 
> is destroyed. This ensures that as long as anything has a reference to the 
> bridge wrapper the bridge is valid and can be joined.
> 
> 
> Diffs
> -
> 
>   /branches/12/apps/app_bridgewait.c 418809 
> 
> Diff: https://reviewboard.asterisk.org/r/3836/diff/
> 
> 
> Testing
> ---
> 
> Ran tests and confirmed no regressions.
> 
> 
> 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] 3770: ARI: report duration values in LiveRecording objects

2014-07-22 Thread Samuel Galarneau



> On July 22, 2014, 8:17 p.m., Samuel Galarneau wrote:
> > Ship It!

Tested latest patch locally successfully.


- Samuel


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


On July 22, 2014, 3:59 p.m., Matt Jordan wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/3770/
> ---
> 
> (Updated July 22, 2014, 3:59 p.m.)
> 
> 
> Review request for Asterisk Developers and Samuel Galarneau.
> 
> 
> Bugs: ASTERISK-24037
> https://issues.asterisk.org/jira/browse/ASTERISK-24037
> 
> 
> Repository: Asterisk
> 
> 
> Description
> ---
> 
> This patch adds two new fields to the LiveRecording model, duration and 
> energy_duration. duration is the time, in seconds, of the entire recording as 
> reported by the Asterisk core; energy_duration is the time, in seconds, of 
> the recording minus any silence that was detected while recording took place.
> 
> This is particularly useful when you want to throw away short recordings or 
> recordings that are all silence.
> 
> Example RecordingFinished event:
> 
> {
>  "application":"testsuite",
>  "type":"RecordingFinished",
>  "recording":{"state":"done",
>   "format":"wav",
>   "name":"superfly",
>   "duration":5,
>   "target_uri":"channel:1405289721.1",
>   "energy_duration":4
>  }
> }
> 
> 
> Diffs
> -
> 
>   /branches/12/rest-api/api-docs/recordings.json 419180 
>   /branches/12/res/res_stasis_recording.c 419180 
>   /branches/12/res/ari/ari_model_validators.c 419180 
>   /branches/12/res/ari/ari_model_validators.h 419180 
> 
> Diff: https://reviewboard.asterisk.org/r/3770/diff/
> 
> 
> Testing
> ---
> 
> Testsuite tests will still need to be written for this feature. This will 
> review will be updated once a test has been written that verifies audio + 
> silence + audio along with expected durations.
> 
> 
> 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] 3770: ARI: report duration values in LiveRecording objects

2014-07-22 Thread Samuel Galarneau


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

Ship it!


Ship It!

- Samuel Galarneau


On July 22, 2014, 3:59 p.m., Matt Jordan wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/3770/
> ---
> 
> (Updated July 22, 2014, 3:59 p.m.)
> 
> 
> Review request for Asterisk Developers and Samuel Galarneau.
> 
> 
> Bugs: ASTERISK-24037
> https://issues.asterisk.org/jira/browse/ASTERISK-24037
> 
> 
> Repository: Asterisk
> 
> 
> Description
> ---
> 
> This patch adds two new fields to the LiveRecording model, duration and 
> energy_duration. duration is the time, in seconds, of the entire recording as 
> reported by the Asterisk core; energy_duration is the time, in seconds, of 
> the recording minus any silence that was detected while recording took place.
> 
> This is particularly useful when you want to throw away short recordings or 
> recordings that are all silence.
> 
> Example RecordingFinished event:
> 
> {
>  "application":"testsuite",
>  "type":"RecordingFinished",
>  "recording":{"state":"done",
>   "format":"wav",
>   "name":"superfly",
>   "duration":5,
>   "target_uri":"channel:1405289721.1",
>   "energy_duration":4
>  }
> }
> 
> 
> Diffs
> -
> 
>   /branches/12/rest-api/api-docs/recordings.json 419180 
>   /branches/12/res/res_stasis_recording.c 419180 
>   /branches/12/res/ari/ari_model_validators.c 419180 
>   /branches/12/res/ari/ari_model_validators.h 419180 
> 
> Diff: https://reviewboard.asterisk.org/r/3770/diff/
> 
> 
> Testing
> ---
> 
> Testsuite tests will still need to be written for this feature. This will 
> review will be updated once a test has been written that verifies audio + 
> silence + audio along with expected durations.
> 
> 
> 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] 3820: MixMonitor: Add Options To Play Beep At Start Or End

2014-07-22 Thread Michael Young


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

(Updated July 22, 2014, 3:01 p.m.)


Status
--

This change has been marked as submitted.


Review request for Asterisk Developers.


Changes
---

Committed in revision 419238


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


Repository: Asterisk


Description
---

While the new periodic beep feature is great for inserting beeps into a call 
being recorded, sometimes a user needs some sort of feedback (without the need 
to have periodic beeps during the recording) to let them know that MixMonitor 
started recording or ended the recording.

The use case where this is being used is when using Dynamic Features and 
starting/ending MixMonitor.

This patch adds an option to play a beep when MixMonitor starts and an option 
to play a beep when MixMonitor ends.


Diffs
-

  /trunk/apps/app_mixmonitor.c 418785 

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


Testing
---

This patch has been in use on an Asterisk 11 box for quite some time.


Thanks,

Michael Young

-- 
_
-- 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] 3673: RLS: Nominal list tests

2014-07-22 Thread Jonathan Rose


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



/asterisk/team/group/rls-tests/tests/channels/pjsip/subscriptions/rls/rls_integrity.py


pidf_part doesn't have a content_id set (not even to None) when entering 
validate_pidf. Looking at pcap.py made me think that only multipart type bodies 
have the content_id and that you probably need to pass it along to 
validate_pidf from there since you can't get it out of just pidf_part.


- Jonathan Rose


On July 7, 2014, 10:43 a.m., Mark Michelson wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/3673/
> ---
> 
> (Updated July 7, 2014, 10:43 a.m.)
> 
> 
> Review request for Asterisk Developers.
> 
> 
> Bugs: ASTERISK-23870
> https://issues.asterisk.org/jira/browse/ASTERISK-23870
> 
> 
> Repository: testsuite
> 
> 
> Description
> ---
> 
> This changeset implements the nominal resource list tests outlined on this 
> page: 
> https://wiki.asterisk.org/wiki/display/AST/Resource+List+Subscription+Test+Plan
> 
> There are six tests:
> 1. Subscription Establishment: Simply ensures that Asterisk responds with a 
> 200 OK when we subscribe to a resource list and that the 200 OK has a 
> Require: eventlist header in it.
> 2. Initial NOTIFY: Validates the initial NOTIFY body that Asterisk sends when 
> subscribing to a resource list.
> 3. Full State: Establishes a subscription to a resource list and then changes 
> the state of a resource. Ensures that Asterisk sends a NOTIFY with full state 
> of the list.
> 4. Partial State: Establishes a subscription to a resource list and then 
> changes the state of a resource. Ensures that Asterisk sends a NOTIFY with 
> partial state, with only the state of the resource whose state was changed.
> 5. Resubscription Full State: Establishes a subscription and then 
> resubscribes. Ensures that even though partial state is configured, the 
> NOTIFY that Asterisk sends in response to the resubscription has full state 
> of the list.
> 6. Termination Full State: Establishes a subscription and then terminates the 
> subscription. Ensures that even though partial state is configured, the 
> NOTIFY that Asterisk sends in response to the termination has full state of 
> the list.
> 
> 
> Diffs
> -
> 
>   
> /asterisk/team/group/rls-tests/tests/channels/pjsip/subscriptions/tests.yaml 
> 5168 
>   
> /asterisk/team/group/rls-tests/tests/channels/pjsip/subscriptions/rls/tests.yaml
>  PRE-CREATION 
>   
> /asterisk/team/group/rls-tests/tests/channels/pjsip/subscriptions/rls/rls_integrity.py
>  PRE-CREATION 
>   
> /asterisk/team/group/rls-tests/tests/channels/pjsip/subscriptions/rls/lists/tests.yaml
>  PRE-CREATION 
>   
> /asterisk/team/group/rls-tests/tests/channels/pjsip/subscriptions/rls/lists/nominal/tests.yaml
>  PRE-CREATION 
>   
> /asterisk/team/group/rls-tests/tests/channels/pjsip/subscriptions/rls/lists/nominal/presence/termination_full_state/test-config.yaml
>  PRE-CREATION 
>   
> /asterisk/team/group/rls-tests/tests/channels/pjsip/subscriptions/rls/lists/nominal/presence/termination_full_state/termination.py
>  PRE-CREATION 
>   
> /asterisk/team/group/rls-tests/tests/channels/pjsip/subscriptions/rls/lists/nominal/presence/termination_full_state/sipp/termination.xml
>  PRE-CREATION 
>   
> /asterisk/team/group/rls-tests/tests/channels/pjsip/subscriptions/rls/lists/nominal/presence/termination_full_state/configs/ast1/pjsip.conf
>  PRE-CREATION 
>   
> /asterisk/team/group/rls-tests/tests/channels/pjsip/subscriptions/rls/lists/nominal/presence/termination_full_state/configs/ast1/extensions.conf
>  PRE-CREATION 
>   
> /asterisk/team/group/rls-tests/tests/channels/pjsip/subscriptions/rls/lists/nominal/presence/subscription_establishment/test-config.yaml
>  PRE-CREATION 
>   
> /asterisk/team/group/rls-tests/tests/channels/pjsip/subscriptions/rls/lists/nominal/presence/subscription_establishment/sipp/list_subscribe.xml
>  PRE-CREATION 
>   
> /asterisk/team/group/rls-tests/tests/channels/pjsip/subscriptions/rls/lists/nominal/presence/subscription_establishment/configs/ast1/pjsip.conf
>  PRE-CREATION 
>   
> /asterisk/team/group/rls-tests/tests/channels/pjsip/subscriptions/rls/lists/nominal/presence/subscription_establishment/configs/ast1/extensions.conf
>  PRE-CREATION 
>   
> /asterisk/team/group/rls-tests/tests/channels/pjsip/subscriptions/rls/lists/nominal/presence/resubscribe_full_state/test-config.yaml
>  PRE-CREATION 
>   
> /asterisk/team/group/rls-tests/tests/channels/pjsip/subscriptions/rls/lists/nominal/presence/resubscribe_full_state/sipp/resubscribe.xml
>  PRE-CREATION 
>   
> /asterisk/team/group

Re: [asterisk-dev] [Code Review] 3795: Test for MixMonitor Recording Feature

2014-07-22 Thread Tyler Austin Cambron


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

(Updated July 22, 2014, 3:02 p.m.)


Review request for Asterisk Developers.


Changes
---

Updated the "Depends On" section to refer to the pluggable module that is 
currently in review.


Bugs: Asterisk-24028
https://issues.asterisk.org/jira/browse/Asterisk-24028


Repository: testsuite


Description
---

This is a test that verifies that the recording feature of MixMonitor is 
functioning properly. The test uses the SoundChecker pluggable module, which is 
currently still up for review, so the test could change depending on changes 
with the pluggable module. Assuming the pluggable module is working correctly, 
this test uses the pluggable module to verify that audio has been recorded from 
a local channel call and that the recording has correctly created a sound file 
that contains the full recording. The pluggable module will appear in the diff, 
specifically to show how the test uses the pluggable module. Please do not 
review the module on this thread, as it is being reviewed in another thread 
posted by cwolfe.


Diffs
-

  /asterisk/trunk/tests/apps/tests.yaml 5297 
  /asterisk/trunk/tests/apps/mixmonitor_record/test-config.yaml PRE-CREATION 
  /asterisk/trunk/tests/apps/mixmonitor_record/start_mix.py PRE-CREATION 
  /asterisk/trunk/tests/apps/mixmonitor_record/configs/ast1/extensions.conf 
PRE-CREATION 
  /asterisk/trunk/lib/python/asterisk/pluggable_modules.py 5297 

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


Testing
---

The test begins by executing dialplan, where MixMonitor is started and a 
playback of tt-monkeys begins. MixMonitor records this audio and stores it into 
a file called theRecording.wav. When the recording is finished, the dialplan 
executes a hangup, which triggers (through the yaml file) a size check and 
energy check on the newly created file, which is done using the SoundChecker 
pluggable module. The test logs confirm that a call is made, the audio starts 
and is recorded, the file is saved, and then the pluggable module verifies that 
the file has the correct size and energy, showing that there is actual audio in 
the file. I also went and found the file manually, and the recording fully 
played back tt-monkeys.


Thanks,

Tyler Austin Cambron

-- 
_
-- 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] 3795: Test for MixMonitor Recording Feature

2014-07-22 Thread Tyler Austin Cambron


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

(Updated July 22, 2014, 3:01 p.m.)


Review request for Asterisk Developers.


Changes
---

Corrected test to use the MixMonitor AMI command rather than call MixMonitor 
through the dialplan by adding a small bit of python code. The test-config.yaml 
has been updated to work with updates to the SoundChecker pluggable module. 
Also updated the size to check for in the test-config to be slightly more 
accurate.


Bugs: Asterisk-24028
https://issues.asterisk.org/jira/browse/Asterisk-24028


Repository: testsuite


Description
---

This is a test that verifies that the recording feature of MixMonitor is 
functioning properly. The test uses the SoundChecker pluggable module, which is 
currently still up for review, so the test could change depending on changes 
with the pluggable module. Assuming the pluggable module is working correctly, 
this test uses the pluggable module to verify that audio has been recorded from 
a local channel call and that the recording has correctly created a sound file 
that contains the full recording. The pluggable module will appear in the diff, 
specifically to show how the test uses the pluggable module. Please do not 
review the module on this thread, as it is being reviewed in another thread 
posted by cwolfe.


Diffs (updated)
-

  /asterisk/trunk/tests/apps/tests.yaml 5297 
  /asterisk/trunk/tests/apps/mixmonitor_record/test-config.yaml PRE-CREATION 
  /asterisk/trunk/tests/apps/mixmonitor_record/start_mix.py PRE-CREATION 
  /asterisk/trunk/tests/apps/mixmonitor_record/configs/ast1/extensions.conf 
PRE-CREATION 
  /asterisk/trunk/lib/python/asterisk/pluggable_modules.py 5297 

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


Testing
---

The test begins by executing dialplan, where MixMonitor is started and a 
playback of tt-monkeys begins. MixMonitor records this audio and stores it into 
a file called theRecording.wav. When the recording is finished, the dialplan 
executes a hangup, which triggers (through the yaml file) a size check and 
energy check on the newly created file, which is done using the SoundChecker 
pluggable module. The test logs confirm that a call is made, the audio starts 
and is recorded, the file is saved, and then the pluggable module verifies that 
the file has the correct size and energy, showing that there is actual audio in 
the file. I also went and found the file manually, and the recording fully 
played back tt-monkeys.


Thanks,

Tyler Austin Cambron

-- 
_
-- 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] 3839: Added a test to check the duration and energy_duration values of an ARI recording


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

Review request for Asterisk Developers.


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


Repository: testsuite


Description
---

Test checks whether the duration and energy_duration of a recording created in 
ARI are both valid.  One local channel half in ARI plays back 2 seconds worth 
of sound (tt-somethingwrong), plays two seconds worth of silence (silence/2), 
and then plays the first sound again.  The other local channel half records 
these sounds as they are played.  The total duration of the recorded sound file 
should be 6 seconds, while the energy_duration should be 4 seconds.  When this 
gets verified, the SoundChecker pluggable module gets called and the sound 
file's size (should be around 96,000 bytes) gets verified, as well as the sound 
file's energy levels using BackgroundDetect.  Since the SoundChecker pluggable 
module hasn't received a Ship It! yet, a dependency has been added accordingly.


Diffs
-

  /asterisk/trunk/tests/rest_api/recording/tests.yaml 5249 
  /asterisk/trunk/tests/rest_api/recording/duration/test-config.yaml 
PRE-CREATION 
  
/asterisk/trunk/tests/rest_api/recording/duration/configs/ast1/extensions.conf 
PRE-CREATION 

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


Testing
---

Checked whether the recording object did return the correct values in the log 
files.  One bottleneck to finishing this test was the fact that you had to add 
maxSilenceSeconds in the recording request in order to make energy_detection 
work AT ALL.  Other than that, this test was pretty straightforward and easy to 
write.


Thanks,

Christopher Wolfe

-- 
_
-- 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] 3815: Improve AstDb I/O When Updating Rows

2014-07-22 Thread Michael Young


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

(Updated July 22, 2014, 1:56 p.m.)


Status
--

This change has been marked as submitted.


Review request for Asterisk Developers.


Changes
---

Committed in revision 419222


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


Repository: Asterisk


Description
---

When updating a row, we are currently doing an INSERT OR REPLACE INTO.  The 
downside to this is that the row is deleted if it exists and then a new row is 
inserted.  So, we are hitting the disk twice.  One for the deletion and one for 
the insertion.

The proposed patch will attempt to do an INSERT INTO and if it fails because a 
row with that key exists, we will ignore that.  Then we will attempt to perform 
an UPDATE on the existing row.  If a record was INSERTED, the UPDATE statement 
will end up doing nothing.


Diffs
-

  /trunk/main/db.c 418608 
  /trunk/include/asterisk/astdb.h 418608 

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


Testing
---

Local pbx with a couple of peers.  Did see a slight I/O increase.

before patch
Re-Register  Avg. 404 ms
Register Avg. 442 ms

after patch
Re-Register  Avg. 361.5 ms
Register Avg. 419 ms


Thanks,

Michael Young

-- 
_
-- 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] 3673: RLS: Nominal list tests

2014-07-22 Thread Jonathan Rose


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



/asterisk/team/group/rls-tests/tests/channels/pjsip/subscriptions/rls/rls_integrity.py


self.resources[name]['state']

-- when I checked what resources was, it was a dict of names and their 
states... like so:

{'bob': 'active', 'alice': 'active'}


Trying to access ['state'] implies that the value of 'bob' should also be a 
dictionary, but it looks like it's just the string... which is the state.


- Jonathan Rose


On July 7, 2014, 10:43 a.m., Mark Michelson wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/3673/
> ---
> 
> (Updated July 7, 2014, 10:43 a.m.)
> 
> 
> Review request for Asterisk Developers.
> 
> 
> Bugs: ASTERISK-23870
> https://issues.asterisk.org/jira/browse/ASTERISK-23870
> 
> 
> Repository: testsuite
> 
> 
> Description
> ---
> 
> This changeset implements the nominal resource list tests outlined on this 
> page: 
> https://wiki.asterisk.org/wiki/display/AST/Resource+List+Subscription+Test+Plan
> 
> There are six tests:
> 1. Subscription Establishment: Simply ensures that Asterisk responds with a 
> 200 OK when we subscribe to a resource list and that the 200 OK has a 
> Require: eventlist header in it.
> 2. Initial NOTIFY: Validates the initial NOTIFY body that Asterisk sends when 
> subscribing to a resource list.
> 3. Full State: Establishes a subscription to a resource list and then changes 
> the state of a resource. Ensures that Asterisk sends a NOTIFY with full state 
> of the list.
> 4. Partial State: Establishes a subscription to a resource list and then 
> changes the state of a resource. Ensures that Asterisk sends a NOTIFY with 
> partial state, with only the state of the resource whose state was changed.
> 5. Resubscription Full State: Establishes a subscription and then 
> resubscribes. Ensures that even though partial state is configured, the 
> NOTIFY that Asterisk sends in response to the resubscription has full state 
> of the list.
> 6. Termination Full State: Establishes a subscription and then terminates the 
> subscription. Ensures that even though partial state is configured, the 
> NOTIFY that Asterisk sends in response to the termination has full state of 
> the list.
> 
> 
> Diffs
> -
> 
>   
> /asterisk/team/group/rls-tests/tests/channels/pjsip/subscriptions/tests.yaml 
> 5168 
>   
> /asterisk/team/group/rls-tests/tests/channels/pjsip/subscriptions/rls/tests.yaml
>  PRE-CREATION 
>   
> /asterisk/team/group/rls-tests/tests/channels/pjsip/subscriptions/rls/rls_integrity.py
>  PRE-CREATION 
>   
> /asterisk/team/group/rls-tests/tests/channels/pjsip/subscriptions/rls/lists/tests.yaml
>  PRE-CREATION 
>   
> /asterisk/team/group/rls-tests/tests/channels/pjsip/subscriptions/rls/lists/nominal/tests.yaml
>  PRE-CREATION 
>   
> /asterisk/team/group/rls-tests/tests/channels/pjsip/subscriptions/rls/lists/nominal/presence/termination_full_state/test-config.yaml
>  PRE-CREATION 
>   
> /asterisk/team/group/rls-tests/tests/channels/pjsip/subscriptions/rls/lists/nominal/presence/termination_full_state/termination.py
>  PRE-CREATION 
>   
> /asterisk/team/group/rls-tests/tests/channels/pjsip/subscriptions/rls/lists/nominal/presence/termination_full_state/sipp/termination.xml
>  PRE-CREATION 
>   
> /asterisk/team/group/rls-tests/tests/channels/pjsip/subscriptions/rls/lists/nominal/presence/termination_full_state/configs/ast1/pjsip.conf
>  PRE-CREATION 
>   
> /asterisk/team/group/rls-tests/tests/channels/pjsip/subscriptions/rls/lists/nominal/presence/termination_full_state/configs/ast1/extensions.conf
>  PRE-CREATION 
>   
> /asterisk/team/group/rls-tests/tests/channels/pjsip/subscriptions/rls/lists/nominal/presence/subscription_establishment/test-config.yaml
>  PRE-CREATION 
>   
> /asterisk/team/group/rls-tests/tests/channels/pjsip/subscriptions/rls/lists/nominal/presence/subscription_establishment/sipp/list_subscribe.xml
>  PRE-CREATION 
>   
> /asterisk/team/group/rls-tests/tests/channels/pjsip/subscriptions/rls/lists/nominal/presence/subscription_establishment/configs/ast1/pjsip.conf
>  PRE-CREATION 
>   
> /asterisk/team/group/rls-tests/tests/channels/pjsip/subscriptions/rls/lists/nominal/presence/subscription_establishment/configs/ast1/extensions.conf
>  PRE-CREATION 
>   
> /asterisk/team/group/rls-tests/tests/channels/pjsip/subscriptions/rls/lists/nominal/presence/resubscribe_full_state/test-config.yaml
>  PRE-CREATION 
>   
> /asterisk/team/group/rls-tests/tests/channels/pjsip/subscriptions/rls/lists/nominal/presence/resubscribe_full_state/sipp/resubscribe.x

Re: [asterisk-dev] [Code Review] 3733: Added a pluggable module for pluggable_modules.py that allows the user to test different attributes of a given sound file


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

(Updated July 22, 2014, 6:46 p.m.)


Review request for Asterisk Developers.


Changes
---

Never mind.  Now it's fixed.


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


Repository: testsuite


Description
---

Allows the user to test a recorded sound file in many different ways:
1) This test ALWAYS gets done- Checks whether the given sound file exists using 
a predefined path that can be created by either explicitly defining a filepath 
by declaring the filepath type as defined, or using a default path that is 
relative to the current test's var/spool/asterisk folder. From there, the user 
can add extensions to the file name to tack on relative folders 
(monitor/testaudio.wav being an example).
2) Optional- The sound file is checked whether it fits within a certain size 
criteria (measured in bytes).  A basis size and degree of size tolerance are 
determined by the user.  For example, if the size was 50 and the tolerance 
was set to 5, then the sound file's size would need to be somewhere between 
45 and 55 in order to pass that test.
3) Optional- The sound file's sound energy levels are checked.  This is done by 
creating a Local channel that should get sent to a dialplan extension that 
should contain a BackgroundDetect application that fits the user's 
specifications. The variable that will be used to pass the sound file must be 
called SOUNDFILE, and a UserEvent must give off the name soundcheck in order 
for the event to be picked up.  A sample extension:
[soundtest]
exten => audio,1,Answer()
same => n,Set(TALK_DETECTED=0)
same => n,BackgroundDetect(${SOUNDFILE},1,20,,2)
same => n,GoToIf($[${TALK_DETECTED}=0]?pass:fail)
same => n(fail),UserEvent(soundcheck, status: pass)
same => n,Hangup()

same => n(pass),UserEvent(soundcheck, status: fail)
same => n,Hangup()

A sound-file test only gets called when a specified trigger has gone off.  So 
far, this pluggable module only supports events as triggers.  The list of 
triggers matches to each instance of a sound-file test on a one-to-one basis 
(the first trigger starts the first test, and so on).
Only passes after all tests specified by the user have been passed and the 
correct triggers have been received.


Diffs (updated)
-

  /asterisk/trunk/sample-yaml/sound-check-config.yaml.sample PRE-CREATION 
  /asterisk/trunk/lib/python/asterisk/pluggable_modules.py 5249 

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


Testing
---

- Tried using the pluggable module by putting in incorrect input and 
purposefully leaving out input.  Picks those errors up.
- Not sure if I was supposed to allow the user to name their own dialplan 
variable and Userevent name, so I left it as was.
- Tested the different scenarios of setting the filepath- relative and defined.
- Made sure the various tests could fail if a certain sound file didn't meet 
the size criteria or silence threshold criteria.
- Made sure that more than one test could be run and that things could be run 
sequentially.


Thanks,

Christopher Wolfe

-- 
_
-- 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] 3729: Stasis: Allow prestart actions to be queued


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

(Updated July 22, 2014, 1:25 p.m.)


Review request for Asterisk Developers.


Changes
---

Roll back to counting loop iterations.


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


Repository: Asterisk


Description
---

This allows commands to be queued in a channel datastore to be executed upon a 
channel entering Stasis(). This functionality is only available from components 
of res_stasis.so. This functionality is required to get a redirected channel 
back into the bridge for which it was destined due to the attended transfer.


Diffs (updated)
-

  branches/12/res/stasis/control.c 418910 
  branches/12/res/stasis/control.h 418910 
  branches/12/res/stasis/command.c 418910 
  branches/12/res/stasis/command.h 418910 
  branches/12/res/res_stasis.c 418910 

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


Testing
---

Tested as part of the complete solution to ASTERISK-23941.


Thanks,

opticron

-- 
_
-- 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] 3733: Added a pluggable module for pluggable_modules.py that allows the user to test different attributes of a given sound file


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

(Updated July 22, 2014, 6:20 p.m.)


Review request for Asterisk Developers.


Changes
---

Due to a silly programming error, you actually had to specify the AMI id in the 
main sound_file part of the YAML.  This has now been fixed.  Also removed a 
print statement that was used mainly for self-testing.


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


Repository: testsuite


Description
---

Allows the user to test a recorded sound file in many different ways:
1) This test ALWAYS gets done- Checks whether the given sound file exists using 
a predefined path that can be created by either explicitly defining a filepath 
by declaring the filepath type as defined, or using a default path that is 
relative to the current test's var/spool/asterisk folder. From there, the user 
can add extensions to the file name to tack on relative folders 
(monitor/testaudio.wav being an example).
2) Optional- The sound file is checked whether it fits within a certain size 
criteria (measured in bytes).  A basis size and degree of size tolerance are 
determined by the user.  For example, if the size was 50 and the tolerance 
was set to 5, then the sound file's size would need to be somewhere between 
45 and 55 in order to pass that test.
3) Optional- The sound file's sound energy levels are checked.  This is done by 
creating a Local channel that should get sent to a dialplan extension that 
should contain a BackgroundDetect application that fits the user's 
specifications. The variable that will be used to pass the sound file must be 
called SOUNDFILE, and a UserEvent must give off the name soundcheck in order 
for the event to be picked up.  A sample extension:
[soundtest]
exten => audio,1,Answer()
same => n,Set(TALK_DETECTED=0)
same => n,BackgroundDetect(${SOUNDFILE},1,20,,2)
same => n,GoToIf($[${TALK_DETECTED}=0]?pass:fail)
same => n(fail),UserEvent(soundcheck, status: pass)
same => n,Hangup()

same => n(pass),UserEvent(soundcheck, status: fail)
same => n,Hangup()

A sound-file test only gets called when a specified trigger has gone off.  So 
far, this pluggable module only supports events as triggers.  The list of 
triggers matches to each instance of a sound-file test on a one-to-one basis 
(the first trigger starts the first test, and so on).
Only passes after all tests specified by the user have been passed and the 
correct triggers have been received.


Diffs (updated)
-

  /asterisk/trunk/sample-yaml/sound-check-config.yaml.sample PRE-CREATION 
  /asterisk/trunk/lib/python/asterisk/pluggable_modules.py 5249 

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


Testing
---

- Tried using the pluggable module by putting in incorrect input and 
purposefully leaving out input.  Picks those errors up.
- Not sure if I was supposed to allow the user to name their own dialplan 
variable and Userevent name, so I left it as was.
- Tested the different scenarios of setting the filepath- relative and defined.
- Made sure the various tests could fail if a certain sound file didn't meet 
the size criteria or silence threshold criteria.
- Made sure that more than one test could be run and that things could be run 
sequentially.


Thanks,

Christopher Wolfe

-- 
_
-- 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] 3832: testsuite: Accountcode propagation.


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



/asterisk/trunk/tests/cdr/sqlite3/test-config.yaml


This probably won't do what you want.

A maxversion of '12' is expanded to be a version of '12.0.0'. That means 
the minversion and the maxversion are the same, both of which are equivalent to 
the first release of Asterisk 12.

Instead, the maxversion here should be '13.0.0', that is, the first release 
of Asterisk 13 (which is less than any run of the 13 branch).

The code that checks whether or not a pluggable module can be run makes 
sure that the version is between these two points:

if (modminversion is not None and
AsteriskVersion(ast_version) < AsteriskVersion(modminversion)):
return False
if (modmaxversion is not None and
AsteriskVersion(ast_version) >= AsteriskVersion(modmaxversion)):
return False





/asterisk/trunk/tests/pbx/accountcode/dial_none/configs/ast1/extensions.conf


Having to wait 5 seconds for this test to end when it has essentially 
completed is usually something we avoid.

There is another route you can take, however:
(1) Drop the channel into Echo after answering it
(2) Use the channel hangup module to hangup the channel on the Newexten 
event:

modules:
-
config-section: hangup-channel
typename: 'pluggable_modules.AMIChannelHangup'

hangup-channel:
id: '1'
conditions:
match:
Event: 'Newexten'
Channel: 'PJSIP/bob-.*'
Application: Echo
count: '1'

This also supports a 'delay' parameter in case the hangup *does* need to 
wait a second or two.

This finding would extend to the other tests that use the same pattern.



/asterisk/trunk/tests/pbx/accountcode/dial_none/test-config.yaml


I don't think you need the dependency on func_channel for this test.


- Matt Jordan


On July 21, 2014, 4:49 p.m., rmudgett wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/3832/
> ---
> 
> (Updated July 21, 2014, 4:49 p.m.)
> 
> 
> Review request for Asterisk Developers.
> 
> 
> Bugs: AFS-65
> https://issues.asterisk.org/jira/browse/AFS-65
> 
> 
> Repository: testsuite
> 
> 
> Description
> ---
> 
> New tests to check accountcode propagation with the new 
> accouncode/peeracccount interaction.
> 
> * Made pluggable_modules.py Originator class and test_case.py
> SimpleTestCase class call origination allow specifying the accountcode.
> 
> * Fix tests/cdr/sqlite3 to work with the new accountcode propagation rules.
> 
> * Add accountcode tag to existing tests doing something with accountcode.
> 
> Testsuite tests to go with https://reviewboard.asterisk.org/r/3601/
> 
> 
> Diffs
> -
> 
>   /asterisk/trunk/tests/pbx/tests.yaml 5288 
>   /asterisk/trunk/tests/pbx/accountcode/tests.yaml PRE-CREATION 
>   /asterisk/trunk/tests/pbx/accountcode/queue_peer_preserve/test-config.yaml 
> PRE-CREATION 
>   
> /asterisk/trunk/tests/pbx/accountcode/queue_peer_preserve/configs/ast1/queues.conf
>  PRE-CREATION 
>   
> /asterisk/trunk/tests/pbx/accountcode/queue_peer_preserve/configs/ast1/pjsip.conf
>  PRE-CREATION 
>   
> /asterisk/trunk/tests/pbx/accountcode/queue_peer_preserve/configs/ast1/extensions.conf
>  PRE-CREATION 
>   /asterisk/trunk/tests/pbx/accountcode/queue_peer_none/test-config.yaml 
> PRE-CREATION 
>   
> /asterisk/trunk/tests/pbx/accountcode/queue_peer_none/configs/ast1/queues.conf
>  PRE-CREATION 
>   
> /asterisk/trunk/tests/pbx/accountcode/queue_peer_none/configs/ast1/pjsip.conf 
> PRE-CREATION 
>   
> /asterisk/trunk/tests/pbx/accountcode/queue_peer_none/configs/ast1/extensions.conf
>  PRE-CREATION 
>   /asterisk/trunk/tests/pbx/accountcode/queue_none/test-config.yaml 
> PRE-CREATION 
>   /asterisk/trunk/tests/pbx/accountcode/queue_none/configs/ast1/queues.conf 
> PRE-CREATION 
>   /asterisk/trunk/tests/pbx/accountcode/queue_none/configs/ast1/pjsip.conf 
> PRE-CREATION 
>   
> /asterisk/trunk/tests/pbx/accountcode/queue_none/configs/ast1/extensions.conf 
> PRE-CREATION 
>   /asterisk/trunk/tests/pbx/accountcode/local_originate/test-config.yaml 
> PRE-CREATION 
>   
> /asterisk/trunk/tests/pbx/accountcode/local_originate/configs/ast1/extensions.conf
>  PRE-CREATION 
>   /asterisk/trunk/tests/pbx/accountcode/local_crossover_back/test-config.yaml 
> PRE-CREATION 
>   
> /asterisk/tr

Re: [asterisk-dev] [Code Review] 3731: Stasis: Prevent non-stasis channels from entering stasis bridges


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

Ship it!


Ship It!

- rmudgett


On July 22, 2014, 1:08 p.m., opticron wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/3731/
> ---
> 
> (Updated July 22, 2014, 1:08 p.m.)
> 
> 
> Review request for Asterisk Developers.
> 
> 
> Bugs: ASTERISK-23941
> https://issues.asterisk.org/jira/browse/ASTERISK-23941
> 
> 
> Repository: Asterisk
> 
> 
> Description
> ---
> 
> This intercepts channels attempting to enter stasis-controlled bridges that 
> are not themselves controlled by stasis and routes them through Stasis() to 
> be controlled by the Stasis application that controls the channels they are 
> replacing.
> 
> 
> Diffs
> -
> 
>   trunk/rest-api/api-docs/events.json 419221 
>   trunk/res/stasis/stasis_bridge.c 419221 
>   trunk/res/stasis/control.c 419221 
>   trunk/res/stasis/control.h 419221 
>   trunk/res/stasis/app.c 419221 
>   trunk/res/stasis/app.h 419221 
>   trunk/res/res_stasis.c 419221 
>   trunk/res/ari/ari_model_validators.c 419221 
>   trunk/res/ari/ari_model_validators.h 419221 
> 
> Diff: https://reviewboard.asterisk.org/r/3731/diff/
> 
> 
> Testing
> ---
> 
> Tested against the updated ARI attended transfer test in 
> https://reviewboard.asterisk.org/r/3732/
> 
> 
> Thanks,
> 
> opticron
> 
>

-- 
_
-- 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] 3731: Stasis: Prevent non-stasis channels from entering stasis bridges


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

(Updated July 22, 2014, 1:08 p.m.)


Review request for Asterisk Developers.


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


Repository: Asterisk


Description
---

This intercepts channels attempting to enter stasis-controlled bridges that are 
not themselves controlled by stasis and routes them through Stasis() to be 
controlled by the Stasis application that controls the channels they are 
replacing.


Diffs
-

  trunk/rest-api/api-docs/events.json 419221 
  trunk/res/stasis/stasis_bridge.c 419221 
  trunk/res/stasis/control.c 419221 
  trunk/res/stasis/control.h 419221 
  trunk/res/stasis/app.c 419221 
  trunk/res/stasis/app.h 419221 
  trunk/res/res_stasis.c 419221 
  trunk/res/ari/ari_model_validators.c 419221 
  trunk/res/ari/ari_model_validators.h 419221 

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


Testing
---

Tested against the updated ARI attended transfer test in 
https://reviewboard.asterisk.org/r/3732/


Thanks,

opticron

-- 
_
-- 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] 3731: Stasis: Prevent non-stasis channels from entering stasis bridges


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

(Updated July 22, 2014, 1:07 p.m.)


Review request for Asterisk Developers.


Changes
---

Address Richard's comment.


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


Repository: Asterisk


Description
---

This intercepts channels attempting to enter stasis-controlled bridges that are 
not themselves controlled by stasis and routes them through Stasis() to be 
controlled by the Stasis application that controls the channels they are 
replacing.


Diffs (updated)
-

  trunk/rest-api/api-docs/events.json 419221 
  trunk/res/stasis/stasis_bridge.c 419221 
  trunk/res/stasis/control.c 419221 
  trunk/res/stasis/control.h 419221 
  trunk/res/stasis/app.c 419221 
  trunk/res/stasis/app.h 419221 
  trunk/res/res_stasis.c 419221 
  trunk/res/ari/ari_model_validators.c 419221 
  trunk/res/ari/ari_model_validators.h 419221 

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


Testing
---

Tested against the updated ARI attended transfer test in 
https://reviewboard.asterisk.org/r/3732/


File Attachments


Collation of thiis patch and dependency patches.
  
https://reviewboard.asterisk.org/media/uploaded/files/2014/07/10/3331f67f-8c7d-486f-bdcf-bf9a01aa288d__ari_atxfer.diff


Thanks,

opticron

-- 
_
-- 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] 3837: app_voicemail: use consistent generator string when updating voicemail.conf

2014-07-22 Thread Scott Griepentrog


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

Review request for Asterisk Developers.


Repository: Asterisk


Description
---

This is related to https://reviewboard.asterisk.org/r/3708/ - "inform config 
hook of configuration change when writing file".

The generator string that app_voicemail passes to ast_config_text_file_save() 
is not consistent with either it's actual name or other usage of ast_config_* 
functions.  This patch changes the generator argument "AppVoicemail" to 
"app_voicemail" when writing out a new copy of the voicemail.conf file when a 
pin code is changed, which enables a single configuration hook to catch both 
reads from and writes to voicemail.conf.

As a side effect, when the voicemail.conf file is written, the header comment 
line showing the Generator: is also updated (see below).  This is not expected 
to cause any problems, and is the only other usage of the generator parameter.

;!
;! Automatically generated configuration file
;! Filename: voicemail.conf (/etc/asterisk/voicemail.conf)
;! Generator: app_voicemail
;! Creation Date: Tue Jul 22 12:32:44 2014


Diffs
-

  /branches/11/apps/app_voicemail.c 419195 

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


Testing
---


Thanks,

Scott Griepentrog

-- 
_
-- 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] 3759: chan_sip: upgrade registry and mwi object to ao2



> On July 22, 2014, 11:24 a.m., rmudgett wrote:
> > /trunk/channels/chan_sip.c, lines 15568-15571
> > 
> >
> > Something seems off here.  The ao2_t_ref() calls return ints and are 
> > parameters to AST_SCHED_REPLACE_UNREF().  Didn't registry_unref() return a 
> > pointer?
> >

The scheduler macros don't actually use return values for any of these. They 
exist only to ref or unref the given variable if the scheduler macro deems it 
necessary.


- opticron


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


On July 21, 2014, 10:52 p.m., Corey Farrell wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/3759/
> ---
> 
> (Updated July 21, 2014, 10:52 p.m.)
> 
> 
> Review request for Asterisk Developers.
> 
> 
> Bugs: ASTERISK-24067
> https://issues.asterisk.org/jira/browse/ASTERISK-24067
> 
> 
> Repository: Asterisk
> 
> 
> Description
> ---
> 
> Upgrade all ASTOBJ objects in chan_sip to ao2.
> 
> 
> Diffs
> -
> 
>   /trunk/channels/sip/include/sip.h 419127 
>   /trunk/channels/chan_sip.c 419127 
> 
> Diff: https://reviewboard.asterisk.org/r/3759/diff/
> 
> 
> Testing
> ---
> 
> Full testsuite run.
> 
> 
> Thanks,
> 
> Corey Farrell
> 
>

-- 
_
-- 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] 3729: Stasis: Allow prestart actions to be queued


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

Ship it!



branches/12/res/stasis/control.c


The use of ao2_container_count() assumes nobody else can get access to the 
container to add more commands.  This isn't theoretically true since the 
container is still obtainable from the channel datastore.  It's a good thing 
nothing cares about this return value.  The way you had it counting each 
command executed before will always give you the number of commands actually 
executed.


- rmudgett


On July 21, 2014, 4:55 p.m., opticron wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/3729/
> ---
> 
> (Updated July 21, 2014, 4:55 p.m.)
> 
> 
> Review request for Asterisk Developers.
> 
> 
> Bugs: ASTERISK-23941
> https://issues.asterisk.org/jira/browse/ASTERISK-23941
> 
> 
> Repository: Asterisk
> 
> 
> Description
> ---
> 
> This allows commands to be queued in a channel datastore to be executed upon 
> a channel entering Stasis(). This functionality is only available from 
> components of res_stasis.so. This functionality is required to get a 
> redirected channel back into the bridge for which it was destined due to the 
> attended transfer.
> 
> 
> Diffs
> -
> 
>   branches/12/res/stasis/control.c 419109 
>   branches/12/res/stasis/control.h 419109 
>   branches/12/res/stasis/command.c 419109 
>   branches/12/res/stasis/command.h 419109 
>   branches/12/res/res_stasis.c 419109 
> 
> Diff: https://reviewboard.asterisk.org/r/3729/diff/
> 
> 
> Testing
> ---
> 
> Tested as part of the complete solution to ASTERISK-23941.
> 
> 
> Thanks,
> 
> opticron
> 
>

-- 
_
-- 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] 3731: Stasis: Prevent non-stasis channels from entering stasis bridges


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



team/rmudgett/stasis_linkedids/res/stasis/app.c


This is not NULL tollerant.
Use ast_channel_cleanup() instead.


- rmudgett


On July 18, 2014, 12:58 p.m., opticron wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/3731/
> ---
> 
> (Updated July 18, 2014, 12:58 p.m.)
> 
> 
> Review request for Asterisk Developers.
> 
> 
> Bugs: ASTERISK-23941
> https://issues.asterisk.org/jira/browse/ASTERISK-23941
> 
> 
> Repository: Asterisk
> 
> 
> Description
> ---
> 
> This intercepts channels attempting to enter stasis-controlled bridges that 
> are not themselves controlled by stasis and routes them through Stasis() to 
> be controlled by the Stasis application that controls the channels they are 
> replacing.
> 
> 
> Diffs
> -
> 
>   team/rmudgett/stasis_linkedids/rest-api/api-docs/events.json 418962 
>   team/rmudgett/stasis_linkedids/res/stasis/stasis_bridge.c 418962 
>   team/rmudgett/stasis_linkedids/res/stasis/control.c 418962 
>   team/rmudgett/stasis_linkedids/res/stasis/control.h 418962 
>   team/rmudgett/stasis_linkedids/res/stasis/app.c 418962 
>   team/rmudgett/stasis_linkedids/res/stasis/app.h 418962 
>   team/rmudgett/stasis_linkedids/res/res_stasis.c 418962 
>   team/rmudgett/stasis_linkedids/res/ari/ari_model_validators.c 418962 
>   team/rmudgett/stasis_linkedids/res/ari/ari_model_validators.h 418962 
> 
> Diff: https://reviewboard.asterisk.org/r/3731/diff/
> 
> 
> Testing
> ---
> 
> Tested against the updated ARI attended transfer test in 
> https://reviewboard.asterisk.org/r/3732/
> 
> 
> File Attachments
> 
> 
> Collation of thiis patch and dependency patches.
>   
> https://reviewboard.asterisk.org/media/uploaded/files/2014/07/10/3331f67f-8c7d-486f-bdcf-bf9a01aa288d__ari_atxfer.diff
> 
> 
> Thanks,
> 
> opticron
> 
>

-- 
_
-- 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] 3728: ARI: Add missing transfer information


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

Ship it!


Ship It!

- rmudgett


On July 18, 2014, 12:42 p.m., opticron wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/3728/
> ---
> 
> (Updated July 18, 2014, 12:42 p.m.)
> 
> 
> Review request for Asterisk Developers.
> 
> 
> Bugs: ASTERISK-23941
> https://issues.asterisk.org/jira/browse/ASTERISK-23941
> 
> 
> Repository: Asterisk
> 
> 
> Description
> ---
> 
> This adds a new field to the ast_attended_transfer_type() and a new subtype 
> AST_ATTENDED_TRANSFER_DEST_LOCAL_APP to describe attended transfers where a 
> local channel is used to connect a dialplan application to a bridge in cases 
> where a single remote party can not be moved directly into the application. 
> Previously, the local channel half being pushed into the bridge in place of a 
> transferer leg was not conveyed in the message.
> 
> 
> Diffs
> -
> 
>   branches/12/rest-api/api-docs/events.json 418910 
>   branches/12/res/ari/ari_model_validators.c 418910 
>   branches/12/res/ari/ari_model_validators.h 418910 
>   branches/12/main/stasis_bridges.c 418910 
>   branches/12/main/cel.c 418910 
>   branches/12/main/bridge.c 418910 
>   branches/12/include/asterisk/stasis_bridges.h 418910 
>   branches/12/apps/app_queue.c 418910 
> 
> Diff: https://reviewboard.asterisk.org/r/3728/diff/
> 
> 
> Testing
> ---
> 
> Tested as part of the complete solution to ASTERISK-23941.
> 
> 
> Thanks,
> 
> opticron
> 
>

-- 
_
-- 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] 3813: codec_speex: Fix trashing normal static frame for AST_FRAME_CNG.


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

(Updated July 22, 2014, 12:10 p.m.)


Status
--

This change has been marked as submitted.


Review request for Asterisk Developers.


Changes
---

Committed in revision 419206


Repository: Asterisk


Description
---

Made use a local static frame to generate the AST_FRAME_CNG frame when silence 
starts.

I don't think the handling of the AST_FRAME_CNG has ever really worked because 
there doesn't seem to be any consumers of it.


Diffs
-

  /team/group/media_formats-reviewed-trunk/codecs/codec_speex.c 418785 

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


Testing
---

It compiles.  I don't have anything that will consume/produce speex.


Thanks,

rmudgett

-- 
_
-- 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] 3726: ari: Add message technology agnostic out of call text messaging

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

(Updated July 22, 2014, 11:42 a.m.)

Review request for Asterisk Developers.

Changes
---

Updated patch with endpoint changes.

Bugs: ASTERISK-23692 and ASTERISK-23969
https://issues.asterisk.org/jira/browse/ASTERISK-23692
https://issues.asterisk.org/jira/browse/ASTERISK-23969

Repository: Asterisk

Description
---

This patch adds the ability to send and receive text messages from various
technology stacks in Asterisk through ARI. This includes chan_sip (sip),
res_pjsip_messaging (pjsip), and res_xmpp (xmpp).

The following would send the message "Hello there" to PJSIP endpoint alice with
a display URI of sip:aster...@mycooldomain.org:

ari/endpoints/sendMessage?to=pjsip:alice&from=sip:aster...@mycooldomain.org&body=Hello+There

This is equivalent to the following as well:

ari/endpoints/PJSIP/alice/sendMessage?from=sip:aster...@mycooldomain.org&body=Hello+There

Both forms are available for message technologies that allow for arbitrary
destinations, such as chan_sip.

Inbound messages can now be received over ARI. An ARI application that
subscribes to endpoints will receive messages from those endpoints:

{
"type": "TextMessageReceived",
"timestamp": "2014-07-12T22:53:13.494-0500",
"endpoint": {
"technology": "PJSIP",
"resource": "alice",
"state": "online",
"channel_ids": []
},
"message": {
"from": "\"alice\" ",
"to": "pjsip:asterisk@127.0.0.1",
"body": "Watson, come here.",
"variables": []
},
"application": "testsuite"
}

A few interesting things you could do with this:
(1) Build your own XMPP to SIP gateway (without ever touching dialplan)
(2) Make a conferencing application with built-in text messaging (speech to
text would be fun with this... probably should write that too)
(3) WebRTC! SIP stacks in the browser can send MESSAGE requests. Why limit
yourself to just making calls when you can send arbitrary messages to a
communications application? (Note: if you can't mention WebRTC in a release,
you're not trying very hard)

The above was made possible due to some rather major changes in the message
core. This includes (but is not limited to):
- Users of the message API can now register message handlers. A handler has two
callbacks: one to determine if the handler has a destination for the message,
and another to handle it.
- All dialplan functionality of handling a message was moved into a message
handler provided by the message API.
- Messages can now have the technology/endpoint associated with them. Various
other properties are also now more easily accessible.
- A number of ao2 containers that weren't really needed were replaced with
vectors. Iteration over ao2_containers is expensive and pointless when the
lifetime of things is well defined and the number of things is very small.

res_stasis now has a new file that makes up its structure, messaging. The
messaging functionality implements a message handler, and passes received
messages that match an interested endpoint over to the app for processing.

Other administrative notes:

This patch depends on r3760 for the endpoint enhancements. When that patch goes
in, this patch will get updated, which will reduce its size considerably.

Note that inadvertently while testing this, I reproduced ASTERISK-23969.
res_pjsip_messaging was incorrectly parsing out the 'to' field, such that
arbitrary SIP URIs mangled the endpoint lookup. This patch includes the fix for
that as well.

Diffs (updated)
-

/branches/12/tests/test_message.c PRE-CREATION
/branches/12/rest-api/api-docs/events.json 419205
/branches/12/rest-api/api-docs/endpoints.json 419205
/branches/12/res/stasis/app.c 419205
/branches/12/res/res_xmpp.c 419205
/branches/12/res/res_stasis.c 419205
/branches/12/res/res_pjsip_messaging.c 419205
/branches/12/res/res_ari_endpoints.c 419205
/branches/12/res/ari/resource_endpoints.c 419205
/branches/12/res/ari/resource_endpoints.h 419205
/branches/12/res/ari/resource_channels.c 419205
/branches/12/res/ari/ari_model_validators.c 419205
/branches/12/res/ari/ari_model_validators.h 419205
/branches/12/main/message.c 419205
/branches/12/main/json.c 419205
/branches/12/include/asterisk/vector.h 419205
/branches/12/include/asterisk/message.h 419205
/branches/12/include/asterisk/manager.h 419205
/branches/12/include/asterisk/json.h 419205
/branches/12/channels/chan_sip.c 419205

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

Testing
---

Unit tests were added for the message core to make sure dialplan still worked.

Testsuite tests are forthcoming, however, I wanted to make sure this got up on
review board. Feature freeze!

Thanks,

Matt Jordan

--
___

Re: [asterisk-dev] [Code Review] 3762: testsuite: Tests for endpoint subscription (nominal + basic off-nominal)


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

(Updated July 22, 2014, 11:26 a.m.)


Status
--

This change has been marked as submitted.


Review request for Asterisk Developers.


Changes
---

Committed in revision 5296


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


Repository: testsuite


Description
---

This patch adds four tests:
* applications/subscribe-endpoint/nominal/resource - subscribe to a resource 
and verify that expected endpoint/channel events are received. Also ensures 
that we don't get stray endpoint messages from things we didn't subscribe to.
* applications/subscribe-endpoint/nominal/tech - subscribe to a technology and 
verify that expected endpoint/channel events are received. Again, we also make 
sure that we don't get stray endpoint messages for things we didn't subscribe 
to.
* applications/subscribe-endpoint/off-nominal/unknown_resource - make sure we 
get a 422 if we subscribe to a valid technology but invalid resource
* applications/subscribe-endpoint/off-nominal/unknown_tech - make sure we get a 
422 if we subscribe to an invalid technology


Diffs
-

  /asterisk/trunk/tests/rest_api/applications/tests.yaml 5237 
  /asterisk/trunk/tests/rest_api/applications/subscribe-endpoint/tests.yaml 
PRE-CREATION 
  /asterisk/trunk/tests/rest_api/applications/subscribe-endpoint/subscriber.py 
PRE-CREATION 
  
/asterisk/trunk/tests/rest_api/applications/subscribe-endpoint/off-nominal/unknown_tech/test-config.yaml
 PRE-CREATION 
  
/asterisk/trunk/tests/rest_api/applications/subscribe-endpoint/off-nominal/unknown_tech/configs/ast1/pjsip.conf
 PRE-CREATION 
  
/asterisk/trunk/tests/rest_api/applications/subscribe-endpoint/off-nominal/unknown_resource/test-config.yaml
 PRE-CREATION 
  
/asterisk/trunk/tests/rest_api/applications/subscribe-endpoint/off-nominal/unknown_resource/configs/ast1/pjsip.conf
 PRE-CREATION 
  
/asterisk/trunk/tests/rest_api/applications/subscribe-endpoint/off-nominal/tests.yaml
 PRE-CREATION 
  
/asterisk/trunk/tests/rest_api/applications/subscribe-endpoint/nominal/tests.yaml
 PRE-CREATION 
  
/asterisk/trunk/tests/rest_api/applications/subscribe-endpoint/nominal/tech/test-config.yaml
 PRE-CREATION 
  
/asterisk/trunk/tests/rest_api/applications/subscribe-endpoint/nominal/tech/configs/ast2/pjsip.conf
 PRE-CREATION 
  
/asterisk/trunk/tests/rest_api/applications/subscribe-endpoint/nominal/tech/configs/ast2/iax.conf
 PRE-CREATION 
  
/asterisk/trunk/tests/rest_api/applications/subscribe-endpoint/nominal/tech/configs/ast2/http.conf
 PRE-CREATION 
  
/asterisk/trunk/tests/rest_api/applications/subscribe-endpoint/nominal/tech/configs/ast2/extensions.conf
 PRE-CREATION 
  
/asterisk/trunk/tests/rest_api/applications/subscribe-endpoint/nominal/tech/configs/ast1/pjsip.conf
 PRE-CREATION 
  
/asterisk/trunk/tests/rest_api/applications/subscribe-endpoint/nominal/tech/configs/ast1/iax.conf
 PRE-CREATION 
  
/asterisk/trunk/tests/rest_api/applications/subscribe-endpoint/nominal/tech/configs/ast1/extensions.conf
 PRE-CREATION 
  
/asterisk/trunk/tests/rest_api/applications/subscribe-endpoint/nominal/resource/test-config.yaml
 PRE-CREATION 
  
/asterisk/trunk/tests/rest_api/applications/subscribe-endpoint/nominal/resource/configs/ast2/pjsip.conf
 PRE-CREATION 
  
/asterisk/trunk/tests/rest_api/applications/subscribe-endpoint/nominal/resource/configs/ast2/iax.conf
 PRE-CREATION 
  
/asterisk/trunk/tests/rest_api/applications/subscribe-endpoint/nominal/resource/configs/ast2/http.conf
 PRE-CREATION 
  
/asterisk/trunk/tests/rest_api/applications/subscribe-endpoint/nominal/resource/configs/ast2/extensions.conf
 PRE-CREATION 
  
/asterisk/trunk/tests/rest_api/applications/subscribe-endpoint/nominal/resource/configs/ast1/pjsip.conf
 PRE-CREATION 
  
/asterisk/trunk/tests/rest_api/applications/subscribe-endpoint/nominal/resource/configs/ast1/iax.conf
 PRE-CREATION 
  
/asterisk/trunk/tests/rest_api/applications/subscribe-endpoint/nominal/resource/configs/ast1/extensions.conf
 PRE-CREATION 
  /asterisk/trunk/lib/python/asterisk/ari.py 5237 
  /asterisk/trunk/configs/ari.conf 5237 

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


Testing
---

Tests pass with changes on r3760


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] 3759: chan_sip: upgrade registry and mwi object to ao2


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



/trunk/channels/chan_sip.c


Where are file, line, and func coming from?  They don't seem to be passed 
in to sip_alloc.



/trunk/channels/chan_sip.c


Something seems off here.  The ao2_t_ref() calls return ints and are 
parameters to AST_SCHED_REPLACE_UNREF().  Didn't registry_unref() return a 
pointer?




/trunk/channels/chan_sip.c


Idem



/trunk/channels/chan_sip.c


Idem



/trunk/channels/chan_sip.c


You should get a iterator ref for ast_sched_add() before calling it and 
unref if it fails to be added.  Otherwise, you run the risk of iterator being 
stale when ast_sched_add succeeds.


- rmudgett


On July 21, 2014, 10:52 p.m., Corey Farrell wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/3759/
> ---
> 
> (Updated July 21, 2014, 10:52 p.m.)
> 
> 
> Review request for Asterisk Developers.
> 
> 
> Bugs: ASTERISK-24067
> https://issues.asterisk.org/jira/browse/ASTERISK-24067
> 
> 
> Repository: Asterisk
> 
> 
> Description
> ---
> 
> Upgrade all ASTOBJ objects in chan_sip to ao2.
> 
> 
> Diffs
> -
> 
>   /trunk/channels/sip/include/sip.h 419127 
>   /trunk/channels/chan_sip.c 419127 
> 
> Diff: https://reviewboard.asterisk.org/r/3759/diff/
> 
> 
> Testing
> ---
> 
> Full testsuite run.
> 
> 
> Thanks,
> 
> Corey Farrell
> 
>

-- 
_
-- 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] 3760: ARI: Fix endpoint/channel subscription issues; allow for subscriptions to endpoint technologies


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

(Updated July 22, 2014, 11:12 a.m.)


Status
--

This change has been marked as submitted.


Review request for Asterisk Developers.


Changes
---

Committed in revision 419196


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


Repository: Asterisk


Description
---

This is the preliminary work needed for ASTERISK-23692, which allows for 
sending/receiving arbitrary out of call text messages through ARI in a 
technology agnostic fashion.

The messaging functionality described on ASTERISK-23692 requires two things:
(1) The ability to send/receive messages associated with an endpoint. This is 
relatively straight forwards with the endpoint core in Asterisk now.
(2) The ability to send/receive messages associated with a technology and an 
arbitrary technology defined URI. This is less straight forward, as endpoints 
are formed from a tech + resource pair. We don't have a mechanism to note that 
a technology that *may* have endpoints exists.

This patch provides such a mechanism, and fixes a few bugs along the way.

The first major bug this patch fixes is the forwarding of channel messages to 
their respective endpoints. Prior to this patch, there were two problems:
(1) Channel caching messages weren't forwarded. Thus, the endpoints missed most 
of the interesting bits (such as channel creation, destruction, state changes, 
etc.)
(2) Channels weren't associated with their endpoint until after creation. This 
resulted in endpoints missing the channel creation message, which limited the 
usefulness of the subscription in the first place (a major use case being 'tell 
me when this endpoint has a channel'). Unfortunately, this meant another 
parameter to ast_channel_alloc. Since not all channel technologies support an 
ast_endpoint, this patch makes such a call optional and opts for a new 
function, ast_channel_alloc_with_endpoint.

When endpoints are created, they will implicitly create a technology endpoint 
for their technology (if one does not already exist). A technology endpoint is 
special in that it has no state, cannot have channels created for it, cannot be 
created explicitly, and cannot be destroyed except on shutdown. It does, 
however, have all messages from other endpoints in its technology forwarded to 
it.

Combined with the bug fixes, we now have Stasis messages being properly 
forwarded. Consider the following scenario: two PJSIP endpoints (foo and bar), 
where bar has a single channel associated with it and foo has two channels 
associated with it. The messages would be forwarded as follows:

ast_channel (PJSIP/foo-1) --
\
 --> ast_endpoint (PJSIP/foo) --
/   \
ast_channel (PJSIP/foo-2) -- \
   > 
ast_endpoint (PJSIP)
 /
ast_channel (PJSIP/bar-1) -> ast_endpoint (PJSIP/bar) --

ARI, through the applications resource, can:
 - subscribe to endpoint:PJSIP/foo and get notifications for channels 
PJSIP/foo-1,PJSIP/foo-2 and endpoint PJSIP/foo
 - subscribe to endpoint:PJSIP/bar and get notifications for channels 
PJSIP/bar-1 and endpoint PJSIP/bar
 - subscribe to endpoint:PJSIP and get notifications for channels 
PJSIP/foo-1,PJSIP/foo-2,PJSIP/bar-1 and endpoints PJSIP/foo,PJSIP/bar

Note that since endpoint PJSIP never changes, it never has events itself. It 
merely provides an aggregation point for all other endpoints in its technology 
(which in turn aggregate all channel messages associated with that endpoint).

This patch also adds endpoints to res_xmpp and chan_motif, because the actual 
messaging work will need it (messaging without XMPP is just sad)


Diffs
-

  /branches/12/rest-api/api-docs/applications.json 419075 
  /branches/12/res/res_xmpp.c 419075 
  /branches/12/res/ari/resource_endpoints.c 419075 
  /branches/12/res/ari/resource_applications.h 419075 
  /branches/12/main/endpoints.c 419075 
  /branches/12/main/channel_internal_api.c 419075 
  /branches/12/main/channel.c 419075 
  /branches/12/include/asterisk/xmpp.h 419075 
  /branches/12/include/asterisk/endpoints.h 419075 
  /branches/12/include/asterisk/channel.h 419075 
  /branches/12/channels/chan_sip.c 419075 
  /branches/12/channels/chan_pjsip.c 419075 
  /branches/12/channels/chan_motif.c 419075 
  /branches/12/channels/chan_iax2.c 419075 

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


Testing
---

Automated tests were written and are up on 
https://reviewboard.asterisk.org/r/3762

In addition, OpenFire was set up and HTTP requests manually made to verify the 
XMPP endpoint had th

Re: [asterisk-dev] [Code Review] 3770: ARI: report duration values in LiveRecording objects


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

(Updated July 22, 2014, 10:59 a.m.)


Review request for Asterisk Developers and Samuel Galarneau.


Changes
---

Addressed findings.


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


Repository: Asterisk


Description
---

This patch adds two new fields to the LiveRecording model, duration and 
energy_duration. duration is the time, in seconds, of the entire recording as 
reported by the Asterisk core; energy_duration is the time, in seconds, of the 
recording minus any silence that was detected while recording took place.

This is particularly useful when you want to throw away short recordings or 
recordings that are all silence.

Example RecordingFinished event:

{
 "application":"testsuite",
 "type":"RecordingFinished",
 "recording":{"state":"done",
  "format":"wav",
  "name":"superfly",
  "duration":5,
  "target_uri":"channel:1405289721.1",
  "energy_duration":4
 }
}


Diffs (updated)
-

  /branches/12/rest-api/api-docs/recordings.json 419180 
  /branches/12/res/res_stasis_recording.c 419180 
  /branches/12/res/ari/ari_model_validators.c 419180 
  /branches/12/res/ari/ari_model_validators.h 419180 

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


Testing
---

Testsuite tests will still need to be written for this feature. This will 
review will be updated once a test has been written that verifies audio + 
silence + audio along with expected durations.


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] 3836: app_bridgewait: Remove race condition where bridge may be dissolved when trying to join


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

Review request for Asterisk Developers.


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


Repository: Asterisk


Description
---

The BridgeWait application currently creates bridges with the dissolve on empty 
flag set. This causes the bridge to be dissolved when the last channel leaves 
it. This introduces a race condition where another channel may be trying to 
join during this, causing it to fail. Since the lifetime of the bridge is 
already associated with the bridge wrapper the bridge does not need the 
dissolve on empty flag set. When the last reference goes away the bridge is 
destroyed. This ensures that as long as anything has a reference to the bridge 
wrapper the bridge is valid and can be joined.


Diffs
-

  /branches/12/apps/app_bridgewait.c 418809 

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


Testing
---

Ran tests and confirmed no regressions.


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] 3759: chan_sip: upgrade registry and mwi object to ao2


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

Ship it!


Other than the two nitpicks below, this looks ready to go in! Great work!


/trunk/channels/chan_sip.c


Red blob.



/trunk/channels/chan_sip.c


Red blob.


- opticron


On July 21, 2014, 10:52 p.m., Corey Farrell wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/3759/
> ---
> 
> (Updated July 21, 2014, 10:52 p.m.)
> 
> 
> Review request for Asterisk Developers.
> 
> 
> Bugs: ASTERISK-24067
> https://issues.asterisk.org/jira/browse/ASTERISK-24067
> 
> 
> Repository: Asterisk
> 
> 
> Description
> ---
> 
> Upgrade all ASTOBJ objects in chan_sip to ao2.
> 
> 
> Diffs
> -
> 
>   /trunk/channels/sip/include/sip.h 419127 
>   /trunk/channels/chan_sip.c 419127 
> 
> Diff: https://reviewboard.asterisk.org/r/3759/diff/
> 
> 
> Testing
> ---
> 
> Full testsuite run.
> 
> 
> Thanks,
> 
> Corey Farrell
> 
>

-- 
_
-- 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] 3835: chan_iax2: Restore previous iax2_best_codec behavior


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

(Updated July 22, 2014, 9:36 a.m.)


Status
--

This change has been marked as submitted.


Review request for Asterisk Developers.


Changes
---

Committed in revision 419180


Repository: Asterisk


Description
---

During the media formats work the iax2_best_codec function in chan_iax2 was 
changed to turn the formats into a format capabilities structure and to grab 
the first format from it. This imposes an explicit preference depending on the 
order of how old bitfield based formats are mapped to new style formats. This 
preference differed from the old code. The acl_call test exposed this because 
it does not have any disallow or allow configuration. It uses the defaults 
provided by chan_iax2. This default includes g723, which is not a codec we can 
transcode. Due to the ordering g723 is the first format in the capabilities 
structure when doing the conversion causing it to get chosen as the format in 
use. As this test plays tones and we can't transcode g723... the test failed. 
The attached change restores the previous behavior of iax2_best_codec by using 
a specific hard coded preference list (which was taken from Asterisk 12).


Diffs
-

  /trunk/channels/chan_iax2.c 419127 

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


Testing
---

Ran acl_call test, it passes once again.


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] 3835: chan_iax2: Restore previous iax2_best_codec behavior


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

Ship it!


Ship It!

- opticron


On July 22, 2014, 8:18 a.m., Joshua Colp wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/3835/
> ---
> 
> (Updated July 22, 2014, 8:18 a.m.)
> 
> 
> Review request for Asterisk Developers.
> 
> 
> Repository: Asterisk
> 
> 
> Description
> ---
> 
> During the media formats work the iax2_best_codec function in chan_iax2 was 
> changed to turn the formats into a format capabilities structure and to grab 
> the first format from it. This imposes an explicit preference depending on 
> the order of how old bitfield based formats are mapped to new style formats. 
> This preference differed from the old code. The acl_call test exposed this 
> because it does not have any disallow or allow configuration. It uses the 
> defaults provided by chan_iax2. This default includes g723, which is not a 
> codec we can transcode. Due to the ordering g723 is the first format in the 
> capabilities structure when doing the conversion causing it to get chosen as 
> the format in use. As this test plays tones and we can't transcode g723... 
> the test failed. The attached change restores the previous behavior of 
> iax2_best_codec by using a specific hard coded preference list (which was 
> taken from Asterisk 12).
> 
> 
> Diffs
> -
> 
>   /trunk/channels/chan_iax2.c 419127 
> 
> Diff: https://reviewboard.asterisk.org/r/3835/diff/
> 
> 
> Testing
> ---
> 
> Ran acl_call test, it passes once again.
> 
> 
> 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

[asterisk-dev] [Code Review] 3835: chan_iax2: Restore previous iax2_best_codec behavior


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

Review request for Asterisk Developers.


Repository: Asterisk


Description
---

During the media formats work the iax2_best_codec function in chan_iax2 was 
changed to turn the formats into a format capabilities structure and to grab 
the first format from it. This imposes an explicit preference depending on the 
order of how old bitfield based formats are mapped to new style formats. This 
preference differed from the old code. The acl_call test exposed this because 
it does not have any disallow or allow configuration. It uses the defaults 
provided by chan_iax2. This default includes g723, which is not a codec we can 
transcode. Due to the ordering g723 is the first format in the capabilities 
structure when doing the conversion causing it to get chosen as the format in 
use. As this test plays tones and we can't transcode g723... the test failed. 
The attached change restores the previous behavior of iax2_best_codec by using 
a specific hard coded preference list (which was taken from Asterisk 12).


Diffs
-

  /trunk/channels/chan_iax2.c 419127 

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


Testing
---

Ran acl_call test, it passes once again.


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] 3723: RLS: NOTIFY generation + structural refactor


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



/team/group/rls/res/res_pjsip_exten_state.c


Naming nitpick: typically, allocation routines are named {object}_alloc or 
something similar:

static struct ast_sip_exten_state_data *exten_state_data_alloc(...)



/team/group/rls/res/res_pjsip_exten_state.c


This function can return -1 on failure. Check for the return and fail 
allocation if that occurs.



/team/group/rls/res/res_pjsip_pubsub.c


Given the number of off nominal paths, I'd wrap this up in a RAII_VAR


- Matt Jordan


On July 8, 2014, 7:47 p.m., Mark Michelson wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/3723/
> ---
> 
> (Updated July 8, 2014, 7:47 p.m.)
> 
> 
> Review request for Asterisk Developers.
> 
> 
> Bugs: ASTERISK-23869
> https://issues.asterisk.org/jira/browse/ASTERISK-23869
> 
> 
> Repository: Asterisk
> 
> 
> Description
> ---
> 
> This adds NOTIFY support for resource list subscriptions. The way this works 
> is as follows:
> 
> When an initial SUBSCRIBE arrives and the subscription tree is built, all 
> leaf nodes are called into in order to generate their initial NOTIFY bodies 
> and store these on their respective subscription nodes.
> 
> Sending a NOTIFY requires traversing the tree. List subscriptions will 
> generate a multipart/related body with an RLMI part and parts corresponding 
> to the leaves of the list (at least they will eventually. ASTERISK-23867 
> involves doing this part). Single-resource subscriptions read the stored body 
> on the subscription and uses that to populate the NOTIFY body.
> 
> Leaf nodes in the subscription tree, when they have a state change occur, 
> call ast_sip_subscription_notify(), as they previously did. 
> ast_sip_subscription_notify() creates the NOTIFY body for the subscription 
> and stores that on the subscription in the body_text ast_str field. The 
> subscription tree is then told to send a NOTIFY if no batching is enabled or 
> to start a batched NOTIFY if batching is enabled.
> 
> When a resource resubscribes or terminates their subscription, a NOTIFY is 
> now automatically generated by the pubsub core instead of calling into 
> subscription handlers. The NOTIFY is built the same way as previously, using 
> stored NOTIFY bodies on the subscription. This NOTIFY can also cause batched 
> notification, when the timer fires, not to actually send their batch since it 
> would be redundant.
> 
> You'll notice the code has been refactored slightly, and a new struct, 
> sip_subscription_tree, has invaded res_pjsip_pubsub. This is because, as I 
> was separating the "real" and "virtual" parts of ast_sip_subscriptions out, I 
> realized that I essentially had two distinct structures. Thus, I separated 
> the real/meta/base elements of a subscription into the sip_subscription_tree, 
> and the resource-specific parts into the ast_sip_subscription struct. 
> sip_subscription_tree is used more heavily in the pubsub core now, whereas 
> ast_sip_subscription acts as a handle for subscription handlers to use plus a 
> repository for resource-specific data.
> 
> 
> Diffs
> -
> 
>   /team/group/rls/res/res_pjsip_pubsub.c 418167 
>   /team/group/rls/res/res_pjsip_mwi.c 418167 
>   /team/group/rls/res/res_pjsip_exten_state.c 418167 
>   /team/group/rls/include/asterisk/res_pjsip_pubsub.h 418167 
> 
> Diff: https://reviewboard.asterisk.org/r/3723/diff/
> 
> 
> Testing
> ---
> 
> With this set of changes, I'm still not able to perform RLS-specific tests 
> since there is still no method of generating multipart/related or RLMI 
> bodies. However, with these changes, I did run the gamut of subscription 
> tests in the testsuite and they all pass. This at least means that there are 
> no detectable regressions at this point.
> 
> 
> Thanks,
> 
> Mark Michelson
> 
>

-- 
_
-- 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] 3780: res_pjsip_outbound_publish / res_pjsip_publish_asterisk: Add outbound PUBLISH support with 'asterisk' event type.