Re: [asterisk-dev] [Code Review] 3888: Manager: Add documentation for PJSIPShowEndpoint[s] responses

2014-08-01 Thread opticron 

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

(Updated Aug. 1, 2014, 10:37 p.m.)


Status
--

This change has been marked as submitted.


Review request for Asterisk Developers and Mark Michelson.


Changes
---

Committed in revision 419914


Repository: Asterisk


Description
---

This adds a large swath of response documentation for PJSIPShowEndpoint and 
PJSIPShowEndpoints AMI commands. It relies heavily on the existing text in the 
configInfo documentation via xi:include tags to avoid documentation duplication.


Diffs
-

  trunk/res/res_pjsip.c 419873 

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


Testing
---

Made sure the commands displayed properly on the CLI.


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] 3873: Testsuite: RLS tests - nominal presence lists

2014-08-01 Thread Jonathan Rose 


> On Aug. 1, 2014, 4:23 p.m., Jonathan Rose wrote:
> > /asterisk/trunk/tests/channels/pjsip/subscriptions/rls/lists/nominal/presence/full_state/full_state.py,
> >  lines 37-38
> > 
> >
> > Alright, this right here turns out to introduce an occasional timing 
> > based problem where state changes prior to the subscription actually being 
> > able to react to this.  I've managed to fix this using reactor.callLater, 
> > so I'll be adding that to all of the tests that currently rely on this 
> > construct.

Ok, so suffice to say the change here is the same as the others... but I'm not 
updating this particular review since it's exactly the same otherwise and I 
don't want to deal with the hassle of pulling everything else out of my working 
folder so that I can make a diff without all the other tests not included here. 
Just pretend that I use reactor.callLater to queue up the AMI actions in this 
case instead of calling them immediately if you review this.


- Jonathan


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


On July 31, 2014, 12:02 p.m., Jonathan Rose wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/3873/
> ---
> 
> (Updated July 31, 2014, 12:02 p.m.)
> 
> 
> Review request for Asterisk Developers and Mark Michelson.
> 
> 
> Bugs: ASTERISK-23870 and ASTERISK-23872
> https://issues.asterisk.org/jira/browse/ASTERISK-23870
> https://issues.asterisk.org/jira/browse/ASTERISK-23872
> 
> 
> Repository: testsuite
> 
> 
> Description
> ---
> 
> Continued from: https://reviewboard.asterisk.org/r/3673/
> 
> > 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.
> 
> Since that review was posted, I've also added support for lists of lists and 
> MWI bodies to the RLSIntegrity and pcap libraries.
> 
> 
> Diffs
> -
> 
>   /asterisk/trunk/tests/channels/pjsip/subscriptions/tests.yaml 5316 
>   /asterisk/trunk/tests/channels/pjsip/subscriptions/rls/tests.yaml 
> PRE-CREATION 
>   /asterisk/trunk/tests/channels/pjsip/subscriptions/rls/rls_integrity.py 
> PRE-CREATION 
>   /asterisk/trunk/tests/channels/pjsip/subscriptions/rls/lists/tests.yaml 
> PRE-CREATION 
>   
> /asterisk/trunk/tests/channels/pjsip/subscriptions/rls/lists/nominal/tests.yaml
>  PRE-CREATION 
>   
> /asterisk/trunk/tests/channels/pjsip/subscriptions/rls/lists/nominal/presence/termination_full_state/test-config.yaml
>  PRE-CREATION 
>   
> /asterisk/trunk/tests/channels/pjsip/subscriptions/rls/lists/nominal/presence/termination_full_state/termination.py
>  PRE-CREATION 
>   
> /asterisk/trunk/tests/channels/pjsip/subscriptions/rls/lists/nominal/presence/termination_full_state/sipp/termination.xml
>  PRE-CREATION 
>   
> /asterisk/trunk/tests/channels/pjsip/subscriptions/rls/lists/nominal/presence/termination_full_state/configs/ast1/pjsip.conf
>  PRE-CREATION 
>   
> /asterisk/trunk/tests/channels/pjsip/subscriptions/rls/lists/nominal/presence/termination_full_state/configs/ast1/extensions.conf
>  PRE-CREATION 
>   
> /asterisk/trunk/tests/channels/pjsip/subscriptions/rls/lists/nominal/presence/subscription_establishment/test-config.yaml
>  PRE-CREATION 
>   
> /asterisk/trunk/tests/channels/pjsip/subscriptions/rls/l

Re: [asterisk-dev] [Code Review] 3875: Testsuite: RLS tests - nominal MWI lists

2014-08-01 Thread Jonathan Rose 

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

(Updated Aug. 1, 2014, 5:51 p.m.)


Review request for Asterisk Developers and Mark Michelson.


Changes
---

Use reactor.callLater to queue up changes to mailboxes. That's it this time.  
No weird things where I accidentally swapped two tests or used the filename 
meant for one test in another... I'm pretty sure.


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


Repository: testsuite


Description
---

Same as https://reviewboard.asterisk.org/r/3873/, only for MWI tests.  Uses the 
MWI additions for the rlsvalidator and pcap libraries to match against MWI type 
message bodies.


Diffs (updated)
-

  
/asterisk/trunk/tests/channels/pjsip/subscriptions/rls/lists/nominal/mwi/tests.yaml
 PRE-CREATION 
  
/asterisk/trunk/tests/channels/pjsip/subscriptions/rls/lists/nominal/mwi/termination_full_state/test-config.yaml
 PRE-CREATION 
  
/asterisk/trunk/tests/channels/pjsip/subscriptions/rls/lists/nominal/mwi/termination_full_state/termination.py
 PRE-CREATION 
  
/asterisk/trunk/tests/channels/pjsip/subscriptions/rls/lists/nominal/mwi/termination_full_state/sipp/termination.xml
 PRE-CREATION 
  
/asterisk/trunk/tests/channels/pjsip/subscriptions/rls/lists/nominal/mwi/termination_full_state/configs/ast1/pjsip.conf
 PRE-CREATION 
  
/asterisk/trunk/tests/channels/pjsip/subscriptions/rls/lists/nominal/mwi/termination_full_state/configs/ast1/extensions.conf
 PRE-CREATION 
  
/asterisk/trunk/tests/channels/pjsip/subscriptions/rls/lists/nominal/mwi/subscription_establishment/test-config.yaml
 PRE-CREATION 
  
/asterisk/trunk/tests/channels/pjsip/subscriptions/rls/lists/nominal/mwi/subscription_establishment/sipp/list_subscribe.xml
 PRE-CREATION 
  
/asterisk/trunk/tests/channels/pjsip/subscriptions/rls/lists/nominal/mwi/subscription_establishment/configs/ast1/pjsip.conf
 PRE-CREATION 
  
/asterisk/trunk/tests/channels/pjsip/subscriptions/rls/lists/nominal/mwi/resubscribe_full_state/test-config.yaml
 PRE-CREATION 
  
/asterisk/trunk/tests/channels/pjsip/subscriptions/rls/lists/nominal/mwi/resubscribe_full_state/sipp/resubscribe.xml
 PRE-CREATION 
  
/asterisk/trunk/tests/channels/pjsip/subscriptions/rls/lists/nominal/mwi/resubscribe_full_state/resubscribe.py
 PRE-CREATION 
  
/asterisk/trunk/tests/channels/pjsip/subscriptions/rls/lists/nominal/mwi/resubscribe_full_state/configs/ast1/pjsip.conf
 PRE-CREATION 
  
/asterisk/trunk/tests/channels/pjsip/subscriptions/rls/lists/nominal/mwi/partial_state/test-config.yaml
 PRE-CREATION 
  
/asterisk/trunk/tests/channels/pjsip/subscriptions/rls/lists/nominal/mwi/partial_state/sipp/list_subscribe.xml
 PRE-CREATION 
  
/asterisk/trunk/tests/channels/pjsip/subscriptions/rls/lists/nominal/mwi/partial_state/partial_state.py
 PRE-CREATION 
  
/asterisk/trunk/tests/channels/pjsip/subscriptions/rls/lists/nominal/mwi/partial_state/configs/ast1/pjsip.conf
 PRE-CREATION 
  
/asterisk/trunk/tests/channels/pjsip/subscriptions/rls/lists/nominal/mwi/initial_notify/test-config.yaml
 PRE-CREATION 
  
/asterisk/trunk/tests/channels/pjsip/subscriptions/rls/lists/nominal/mwi/initial_notify/sipp/list_subscribe.xml
 PRE-CREATION 
  
/asterisk/trunk/tests/channels/pjsip/subscriptions/rls/lists/nominal/mwi/initial_notify/notify.py
 PRE-CREATION 
  
/asterisk/trunk/tests/channels/pjsip/subscriptions/rls/lists/nominal/mwi/initial_notify/configs/ast1/pjsip.conf
 PRE-CREATION 
  
/asterisk/trunk/tests/channels/pjsip/subscriptions/rls/lists/nominal/mwi/full_state/test-config.yaml
 PRE-CREATION 
  
/asterisk/trunk/tests/channels/pjsip/subscriptions/rls/lists/nominal/mwi/full_state/sipp/list_subscribe.xml
 PRE-CREATION 
  
/asterisk/trunk/tests/channels/pjsip/subscriptions/rls/lists/nominal/mwi/full_state/full_state.py
 PRE-CREATION 
  
/asterisk/trunk/tests/channels/pjsip/subscriptions/rls/lists/nominal/mwi/full_state/configs/ast1/pjsip.conf
 PRE-CREATION 

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


Testing
---

Varied expectations of things like which mailboxes to expect and their contents 
from results and got failures. Still running against mmichelson's rls-rlmi 
branch.


Thanks,

Jonathan Rose

-- 
_
-- 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] 3881: Testsuite: RLS tests - Lists containing lists tests for presence

2014-08-01 Thread Jonathan Rose 

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

(Updated Aug. 1, 2014, 5:49 p.m.)


Review request for Asterisk Developers and Mark Michelson.


Changes
---

Use reactor.callLater to queue up device state changes.  Also I accidentally 
named the test classes for the full state tests for this set 'partial_state.py' 
in the previous version.


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


Repository: testsuite


Description
---

Similar to the presence tests in https://reviewboard.asterisk.org/r/3873/

The main set of tests follows operations against the following list setup:

subscription to pres_list
pres_list: carol (presence), pres_sublist (list)
pres_sublist: alice (presence), bob (presence)

This setup is tested against the following:

subscription_establishment: Uses sipp to check that a subscription can 
successfully be established (only evaluates SIP traffic to and from Asterisk, 
not concerned with NOTIFY contents)

initial_notify: Verifies that a NOTIFY is received after subscribing and that 
it contains all of the expected elements

full_state_alice: After receiving the initial notify, Alice's state is changed. 
The following NOTIFY is checked to confirm that it contains full state for all 
items in pres_list (which includes state information for pres_sublist items as 
well)

full_state_carol: As with full_state_alice, only Carol's state is changed 
instead.

partial_state_alice: As with full_state_alice, only since full state 
information isn't set for the lists, we only want changed entries. In this 
case, the notify should only include pres_sublist and pres_sublist should only 
include alice.

partial_state_carol: As with full_state_carol, only since full state 
information isn't set for the lists, we only want changed entries. In this 
case, the notify should only include carol and not the pres_sublist.

resubscribe_full_state: After the initial notify, The sipp client resubscribes 
to the list. We expect to receive full state information even though the 
individual lists are set to give partial state information on updates.

termation_full_state: After the initial notify, the sipp client terminates the 
subscription. We expect to receive full state information even though the 
individual lists are set to give partial state information on updates and also 
we expect the state of each list entry to be terminated since we are 
unsubscribing.


In addition, I've added one additional test here which tests for an additional 
tier of nested lists. Right now this test crashes the rls-rlmi branch, but this 
is more due to the sheer size of the message than because it messes up when 
creating the actual list:

pres_list: carol (presence), pres_sublist (list)
pres_sublist: pres_sublist_sublist (list), alice (presence), bob (presence)
pres_sublist_sublist: dave (presence)

listception_initial_notify: This is the same as the initial notify test, only 
it tests for a list that goes three levels deep instead of two.


Diffs (updated)
-

  
/asterisk/trunk/tests/channels/pjsip/subscriptions/rls/lists_of_lists/nominal/presence/tests.yaml
 PRE-CREATION 
  
/asterisk/trunk/tests/channels/pjsip/subscriptions/rls/lists_of_lists/nominal/presence/termination_full_state/test-config.yaml
 PRE-CREATION 
  
/asterisk/trunk/tests/channels/pjsip/subscriptions/rls/lists_of_lists/nominal/presence/termination_full_state/termination.py
 PRE-CREATION 
  
/asterisk/trunk/tests/channels/pjsip/subscriptions/rls/lists_of_lists/nominal/presence/termination_full_state/sipp/termination.xml
 PRE-CREATION 
  
/asterisk/trunk/tests/channels/pjsip/subscriptions/rls/lists_of_lists/nominal/presence/termination_full_state/configs/ast1/pjsip.conf
 PRE-CREATION 
  
/asterisk/trunk/tests/channels/pjsip/subscriptions/rls/lists_of_lists/nominal/presence/termination_full_state/configs/ast1/extensions.conf
 PRE-CREATION 
  
/asterisk/trunk/tests/channels/pjsip/subscriptions/rls/lists_of_lists/nominal/presence/subscription_establishment/test-config.yaml
 PRE-CREATION 
  
/asterisk/trunk/tests/channels/pjsip/subscriptions/rls/lists_of_lists/nominal/presence/subscription_establishment/sipp/list_subscribe.xml
 PRE-CREATION 
  
/asterisk/trunk/tests/channels/pjsip/subscriptions/rls/lists_of_lists/nominal/presence/subscription_establishment/configs/ast1/pjsip.conf
 PRE-CREATION 
  
/asterisk/trunk/tests/channels/pjsip/subscriptions/rls/lists_of_lists/nominal/presence/subscription_establishment/configs/ast1/extensions.conf
 PRE-CREATION 
  
/asterisk/trunk/tests/channels/pjsip/subscriptions/rls/lists_of_lists/nominal/presence/resubscribe_full_state/test-config.yaml
 PRE-CREATION 
  
/asterisk/trunk/tests/channels/pjsip/subscriptions/rls/lists_of_lists/nominal/presence/resubscribe_full_state/sipp/resubscribe.xml
 PRE-CREATION 
  
/ast

[asterisk-dev] managerEvent XML documentation

2014-08-01 Thread Corey Farrell 
Hello everyone,

As part of r3811 I'm fixing build_tools/get_documentation so it picks
up every /*** DOCUMENTATION ***/ block, instead of just the first from
each file.  As a side-effect this picked up some validation error's
that were previously unnoticed.  One of them is in main/logger.c, the
LogChannel event documentation.  This event has two variations -
"Enable: yes", and "Enable: no\nReason: %d - %s".  Personally I feel
it would be better if we had separate LogChannelStart and
LogChannelStop events, but I suspect it's too late for that.  Assuming
we keep the single event with two variations, how should it be
documented?

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

Note: although the fix to build_tools/get_documentation could apply to
11/12, this caused the build to fail due to many documentation
validation errors.  I'm not against eventually back-porting the fix,
but for now I'm proposing it for trunk only as I don't have time to
audit/fix/test the documentation in those versions.

-- 
_
-- 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] 3883: Testsuite: RLS tests - Lists containing lists tests for MWI

2014-08-01 Thread Jonathan Rose 

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

(Updated Aug. 1, 2014, 5:46 p.m.)


Review request for Asterisk Developers and Mark Michelson.


Changes
---

Use reactor.callLater to schedule mailbox changes. Also I think I had one of 
the alice/carol tests backwards in terms of expectations in the last version.


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


Repository: testsuite


Description
---

Similar to the MWI tests in https://reviewboard.asterisk.org/r/3875/

The main set of tests follows operations against the following list setup:

subscription to mail_list
mail_list: carol (MWI), mail_sublist (list)
mail_sublist: alice (MWI), bob (MWI)

This setup is tested against the following:

subscription_establishment: Uses sipp to check that a subscription can 
successfully be established (only evaluates SIP traffic to and from Asterisk, 
not concerned with NOTIFY contents)

initial_notify: Verifies that a NOTIFY is received after subscribing and that 
it contains all of the expected elements

full_state_alice: After receiving the initial notify, Alice's mailbox state is 
changed. The following NOTIFY is checked to confirm that it contains full state 
for all items in mail_list (which includes state information for mail_sublist 
items as well)

full_state_carol: As with full_state_alice, only Carol's mailbox state is 
changed instead.

partial_state_alice: As with full_state_alice, only since full state 
information isn't set for the lists, we only want changed entries. In this 
case, the notify should only include mail_sublist and mail_sublist should only 
include alice.

partial_state_carol: As with full_state_carol, only since full state 
information isn't set for the lists, we only want changed entries. In this 
case, the notify should only include carol and not the mail_sublist.

resubscribe_full_state: After the initial notify, The sipp client resubscribes 
to the list. We expect to receive full state information even though the 
individual lists are set to give partial state information on updates.

termation_full_state: After the initial notify, the sipp client terminates the 
subscription. We expect to receive full state information even though the 
individual lists are set to give partial state information on updates and also 
we expect the state of each list entry to be terminated since we are 
unsubscribing.


Diffs (updated)
-

  
/asterisk/trunk/tests/channels/pjsip/subscriptions/rls/lists_of_lists/nominal/mwi/tests.yaml
 PRE-CREATION 
  
/asterisk/trunk/tests/channels/pjsip/subscriptions/rls/lists_of_lists/nominal/mwi/termination_full_state/test-config.yaml
 PRE-CREATION 
  
/asterisk/trunk/tests/channels/pjsip/subscriptions/rls/lists_of_lists/nominal/mwi/termination_full_state/termination.py
 PRE-CREATION 
  
/asterisk/trunk/tests/channels/pjsip/subscriptions/rls/lists_of_lists/nominal/mwi/termination_full_state/sipp/termination.xml
 PRE-CREATION 
  
/asterisk/trunk/tests/channels/pjsip/subscriptions/rls/lists_of_lists/nominal/mwi/termination_full_state/configs/ast1/pjsip.conf
 PRE-CREATION 
  
/asterisk/trunk/tests/channels/pjsip/subscriptions/rls/lists_of_lists/nominal/mwi/termination_full_state/configs/ast1/extensions.conf
 PRE-CREATION 
  
/asterisk/trunk/tests/channels/pjsip/subscriptions/rls/lists_of_lists/nominal/mwi/subscription_establishment/test-config.yaml
 PRE-CREATION 
  
/asterisk/trunk/tests/channels/pjsip/subscriptions/rls/lists_of_lists/nominal/mwi/subscription_establishment/sipp/list_subscribe.xml
 PRE-CREATION 
  
/asterisk/trunk/tests/channels/pjsip/subscriptions/rls/lists_of_lists/nominal/mwi/subscription_establishment/configs/ast1/pjsip.conf
 PRE-CREATION 
  
/asterisk/trunk/tests/channels/pjsip/subscriptions/rls/lists_of_lists/nominal/mwi/resubscribe_full_state/test-config.yaml
 PRE-CREATION 
  
/asterisk/trunk/tests/channels/pjsip/subscriptions/rls/lists_of_lists/nominal/mwi/resubscribe_full_state/sipp/resubscribe.xml
 PRE-CREATION 
  
/asterisk/trunk/tests/channels/pjsip/subscriptions/rls/lists_of_lists/nominal/mwi/resubscribe_full_state/resubscribe.py
 PRE-CREATION 
  
/asterisk/trunk/tests/channels/pjsip/subscriptions/rls/lists_of_lists/nominal/mwi/resubscribe_full_state/configs/ast1/pjsip.conf
 PRE-CREATION 
  
/asterisk/trunk/tests/channels/pjsip/subscriptions/rls/lists_of_lists/nominal/mwi/partial_state_carol/test-config.yaml
 PRE-CREATION 
  
/asterisk/trunk/tests/channels/pjsip/subscriptions/rls/lists_of_lists/nominal/mwi/partial_state_carol/sipp/list_subscribe.xml
 PRE-CREATION 
  
/asterisk/trunk/tests/channels/pjsip/subscriptions/rls/lists_of_lists/nominal/mwi/partial_state_carol/partial_state.py
 PRE-CREATION 
  
/asterisk/trunk/tests/channels/pjsip/subscriptions/rls/lists_of_lists/nominal/mwi/partial_state_carol/configs/ast1/pjsip.co

Re: [asterisk-dev] [Code Review] 3811: Move main/manager_*.c to loadable modules

2014-08-01 Thread Corey Farrell 

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



/trunk/main/logger.c


Is it appropriate / acceptable to document "LogChannel" in two places?  Or 
do the two documentation sections need to be combined?

OTOH it feels like these events really should have been called 
LoggerChannelStart and LoggerChannelStop.



/trunk/res/res_manager_bridges.c


These events are mutually exclusive, so this handler should be moved back 
to stasis_bridges.c once converted to a .to_ami callback.



/trunk/res/res_manager_channels.c


channel_state_change has a comment stating that Newchannel, Newstate and 
Hangup events are mutually exclusive.  I think this may also apply to Newexten, 
NewCallerID and NewAccountcode.  If so this should be moved back to 
stasis_channels.c as a .to_ami callback.


- Corey Farrell


On Aug. 1, 2014, 6:22 p.m., Corey Farrell wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/3811/
> ---
> 
> (Updated Aug. 1, 2014, 6:22 p.m.)
> 
> 
> Review request for Asterisk Developers.
> 
> 
> Bugs: ASTERISK-24068
> https://issues.asterisk.org/jira/browse/ASTERISK-24068
> 
> 
> Repository: Asterisk
> 
> 
> Description
> ---
> 
> This change moves main/manager_*.c to loadable modules, allowing those events 
> to be disabled by not loading the modules.  This can be accomplished by 
> eventfilter, but eventfilter has a couple issues.  It actually adds more 
> overhead to asterisk since the outbound events must be parsed for each AMI 
> user.  Additionally it causes skips in SequenceNumber, preventing use of that 
> tag to determine if any events were missed during a reconnect.
> 
> Besides converting from built-in units to modules, changes are made to 
> VarSet, ChannelTalkingStart and ChannelTalkingStop.  They no longer use 
> .to_ami callbacks, but instead subscribe to the stasis events like the rest 
> of the res_manager_channels events.  A couple functions were also moved from 
> manager_bridging.c and manager_channels.c to manager.c since they are still 
> needed even if these modules are noload'ed.
> 
> AST_MODULE_INFO_STANDARD for all modules will be updated once r3802 is 
> committed.  This or r3812 will need to be updated depending on which is 
> committed first.
> 
> 
> Diffs
> -
> 
>   /trunk/res/res_manager_system.c PRE-CREATION 
>   /trunk/res/res_manager_mwi.c PRE-CREATION 
>   /trunk/res/res_manager_endpoints.c PRE-CREATION 
>   /trunk/res/res_manager_channels.c PRE-CREATION 
>   /trunk/res/res_manager_bridges.c PRE-CREATION 
>   /trunk/main/stasis_channels.c 419804 
>   /trunk/main/stasis_bridges.c 419804 
>   /trunk/main/manager_system.c 419804 
>   /trunk/main/manager_mwi.c 419804 
>   /trunk/main/manager_endpoints.c 419804 
>   /trunk/main/manager_channels.c 419804 
>   /trunk/main/manager_bridges.c 419804 
>   /trunk/main/manager.c 419804 
>   /trunk/main/logger.c 419804 
>   /trunk/main/channel.c 419804 
>   /trunk/include/asterisk/manager.h 419804 
>   /trunk/build_tools/get_documentation 419804 
> 
> Diff: https://reviewboard.asterisk.org/r/3811/diff/
> 
> 
> Testing
> ---
> 
> Ran some testsuite's to verify some of the events were still being sent to 
> AMI:
> tests/manager/originate
> tests/apps/channel_redirect
> tests/bridge/connected_line_update
> tests/feature_call_pickup
> tests/apps/dial/dial_answer
> tests/apps/chanspy/chanspy_barge
> tests/funcs/func_push
> 
> This did not provide complete coverage for all effected events, but does 
> verify many events from res_manager_channels.c.  Events from other files were 
> not tested, though res_manager_channels.c was the most likely to cause 
> problems.
> 
> 
> 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] 3811: Move main/manager_*.c to loadable modules

2014-08-01 Thread Corey Farrell 

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

(Updated Aug. 1, 2014, 6:22 p.m.)


Review request for Asterisk Developers.


Changes
---

* Fix build_tools/get_documentation so it picks up all DOCUMENTATION blocks 
from each file
* Use .to_ami callbacks for most events
* Reorder stasis_channels.c / stasis_bridges.c so that callbacks are 
immediately preceding the STASIS_MESSAGE_TYPE_DEFN declaration.
* Scatter DOCUMENATION blocks to be next to the code that they are documenting. 
 This will make it easier to see discrepancies between documentation and code.
* Add missing  tags throughout code, as well as "class" attribute 
missing from managerEventInstance.  This was needed to deal with the fact that 
doc/core-en_US.xml now contains documentation that was previously missed.


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


Repository: Asterisk


Description
---

This change moves main/manager_*.c to loadable modules, allowing those events 
to be disabled by not loading the modules.  This can be accomplished by 
eventfilter, but eventfilter has a couple issues.  It actually adds more 
overhead to asterisk since the outbound events must be parsed for each AMI 
user.  Additionally it causes skips in SequenceNumber, preventing use of that 
tag to determine if any events were missed during a reconnect.

Besides converting from built-in units to modules, changes are made to VarSet, 
ChannelTalkingStart and ChannelTalkingStop.  They no longer use .to_ami 
callbacks, but instead subscribe to the stasis events like the rest of the 
res_manager_channels events.  A couple functions were also moved from 
manager_bridging.c and manager_channels.c to manager.c since they are still 
needed even if these modules are noload'ed.

AST_MODULE_INFO_STANDARD for all modules will be updated once r3802 is 
committed.  This or r3812 will need to be updated depending on which is 
committed first.


Diffs (updated)
-

  /trunk/res/res_manager_system.c PRE-CREATION 
  /trunk/res/res_manager_mwi.c PRE-CREATION 
  /trunk/res/res_manager_endpoints.c PRE-CREATION 
  /trunk/res/res_manager_channels.c PRE-CREATION 
  /trunk/res/res_manager_bridges.c PRE-CREATION 
  /trunk/main/stasis_channels.c 419804 
  /trunk/main/stasis_bridges.c 419804 
  /trunk/main/manager_system.c 419804 
  /trunk/main/manager_mwi.c 419804 
  /trunk/main/manager_endpoints.c 419804 
  /trunk/main/manager_channels.c 419804 
  /trunk/main/manager_bridges.c 419804 
  /trunk/main/manager.c 419804 
  /trunk/main/logger.c 419804 
  /trunk/main/channel.c 419804 
  /trunk/include/asterisk/manager.h 419804 
  /trunk/build_tools/get_documentation 419804 

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


Testing
---

Ran some testsuite's to verify some of the events were still being sent to AMI:
tests/manager/originate
tests/apps/channel_redirect
tests/bridge/connected_line_update
tests/feature_call_pickup
tests/apps/dial/dial_answer
tests/apps/chanspy/chanspy_barge
tests/funcs/func_push

This did not provide complete coverage for all effected events, but does verify 
many events from res_manager_channels.c.  Events from other files were not 
tested, though res_manager_channels.c was the most likely to cause problems.


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] 3873: Testsuite: RLS tests - nominal presence lists

2014-08-01 Thread Jonathan Rose 

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



/asterisk/trunk/tests/channels/pjsip/subscriptions/rls/lists/nominal/presence/full_state/full_state.py


Alright, this right here turns out to introduce an occasional timing based 
problem where state changes prior to the subscription actually being able to 
react to this.  I've managed to fix this using reactor.callLater, so I'll be 
adding that to all of the tests that currently rely on this construct.


- Jonathan Rose


On July 31, 2014, 12:02 p.m., Jonathan Rose wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/3873/
> ---
> 
> (Updated July 31, 2014, 12:02 p.m.)
> 
> 
> Review request for Asterisk Developers and Mark Michelson.
> 
> 
> Bugs: ASTERISK-23870 and ASTERISK-23872
> https://issues.asterisk.org/jira/browse/ASTERISK-23870
> https://issues.asterisk.org/jira/browse/ASTERISK-23872
> 
> 
> Repository: testsuite
> 
> 
> Description
> ---
> 
> Continued from: https://reviewboard.asterisk.org/r/3673/
> 
> > 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.
> 
> Since that review was posted, I've also added support for lists of lists and 
> MWI bodies to the RLSIntegrity and pcap libraries.
> 
> 
> Diffs
> -
> 
>   /asterisk/trunk/tests/channels/pjsip/subscriptions/tests.yaml 5316 
>   /asterisk/trunk/tests/channels/pjsip/subscriptions/rls/tests.yaml 
> PRE-CREATION 
>   /asterisk/trunk/tests/channels/pjsip/subscriptions/rls/rls_integrity.py 
> PRE-CREATION 
>   /asterisk/trunk/tests/channels/pjsip/subscriptions/rls/lists/tests.yaml 
> PRE-CREATION 
>   
> /asterisk/trunk/tests/channels/pjsip/subscriptions/rls/lists/nominal/tests.yaml
>  PRE-CREATION 
>   
> /asterisk/trunk/tests/channels/pjsip/subscriptions/rls/lists/nominal/presence/termination_full_state/test-config.yaml
>  PRE-CREATION 
>   
> /asterisk/trunk/tests/channels/pjsip/subscriptions/rls/lists/nominal/presence/termination_full_state/termination.py
>  PRE-CREATION 
>   
> /asterisk/trunk/tests/channels/pjsip/subscriptions/rls/lists/nominal/presence/termination_full_state/sipp/termination.xml
>  PRE-CREATION 
>   
> /asterisk/trunk/tests/channels/pjsip/subscriptions/rls/lists/nominal/presence/termination_full_state/configs/ast1/pjsip.conf
>  PRE-CREATION 
>   
> /asterisk/trunk/tests/channels/pjsip/subscriptions/rls/lists/nominal/presence/termination_full_state/configs/ast1/extensions.conf
>  PRE-CREATION 
>   
> /asterisk/trunk/tests/channels/pjsip/subscriptions/rls/lists/nominal/presence/subscription_establishment/test-config.yaml
>  PRE-CREATION 
>   
> /asterisk/trunk/tests/channels/pjsip/subscriptions/rls/lists/nominal/presence/subscription_establishment/sipp/list_subscribe.xml
>  PRE-CREATION 
>   
> /asterisk/trunk/tests/channels/pjsip/subscriptions/rls/lists/nominal/presence/subscription_establishment/configs/ast1/pjsip.conf
>  PRE-CREATION 
>   
> /asterisk/trunk/tests/channels/pjsip/subscriptions/rls/lists/nominal/presence/subscription_establishment/configs/ast1/extensions.conf
>  PRE-CREATION 
>   
> /asterisk/trunk/tests/channels/pjsip/subscriptions/rls/lists/nominal/presence/resubscribe_full_state/test-config.yaml
>  PRE-CREATION 
>   
> /asterisk/trunk/tests/chann

Re: [asterisk-dev] [Code Review] 3885: chan_iax2: Fix a crash caused by trying to allow all codecs on a chan_iax2 peer

2014-08-01 Thread Mark Michelson 

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

Ship it!


- Mark Michelson


On July 31, 2014, 9:40 p.m., Jonathan Rose wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/3885/
> ---
> 
> (Updated July 31, 2014, 9:40 p.m.)
> 
> 
> Review request for Asterisk Developers.
> 
> 
> Bugs: ASTERISK-24107
> https://issues.asterisk.org/jira/browse/ASTERISK-24107
> 
> 
> Repository: Asterisk
> 
> 
> Description
> ---
> 
> When using an IAX2 peer configured with:
> allow=all
> 
> Asterisk will segfault when building the peer while loading chan_iax2.so
> 
> This is caused by ast_format_cmp trying to compare two ast_format structs 
> using the codec opus format interface defined in res_format_attr_opus. This 
> format interface doesn't define a format comparison function, so when we try 
> to use this undefined function, boom.
> 
> The fix for this was to treat an interface without a comparison function in 
> the same manner as we treat comparison with formats that don't have 
> interfaces.
> 
> 
> Diffs
> -
> 
>   /trunk/main/format.c 419870 
> 
> Diff: https://reviewboard.asterisk.org/r/3885/diff/
> 
> 
> Testing
> ---
> 
> It doesn't crash anymore. That's a start.  I also checked the output for the 
> CLI command 'iax2 show peer' for the peer I was using to define all the 
> codecs and that appeared to work alright. Also made a call with just opus and 
> ulaw set as codecs (opus should have been the preferred).  Opus ended up not 
> being included in the list of preferred codecs (although output for just 
> Codecs still includes it for some reason) and when making a call the endpoint 
> would choose ulaw.
> 
> *CLI> iax2 show peer lappy
> 
> 
>   * Name   : lappy
>   Description  : 
>   Secret   : 
>   Context  : default
>   Parking lot  : 
>   Mailbox  : 
>   Dynamic  : Yes
>   Callnum limit: 0
>   Calltoken req: No
>   Trunk: No
>   Encryption   : No
>   Callerid : "" <>
>   Expire   : 4
>   ACL  : No
>   Addr->IP : 10.24.16.82 Port 4569
>   Defaddr->IP  : (null) Port (null)
>   Username : lappy
>   Codecs   : (ulaw|opus)
>   Codec Order  : (ulaw)
>   Status   : OK (38 ms)
>   Qualify  : every 6ms when OK, every 1ms when UNREACHABLE 
> (sample smoothing Off)
> 
> *CLI> 
> *CLI> 
> *CLI> 
> *CLI> -- Accepting AUTHENTICATED call from 10.24.16.82:4569:
> --> requested format = ulaw,
> --> requested prefs = (),
> --> actual format = ulaw,
> --> host prefs = (ulaw),
> --> priority = mine
> 
> 
> It gets slightly weirder right now when more stuff is specified after opus...
> 
> [deskbox]
> disallow=all
> allow=opus
> allow=ulaw
> allow=alaw
> 
> results:
> 
> *CLI> iax2 show peer deskbox 
> 
> 
>   * Name   : deskbox
>   Description  : 
>   Secret   : 
>   Context  : default
>   Parking lot  : 
>   Mailbox  : 
>   Dynamic  : Yes
>   Callnum limit: 0
>   Calltoken req: No
>   Trunk: No
>   Encryption   : No
>   Callerid : "" <>
>   Expire   : -1
>   ACL  : No
>   Addr->IP : (null) Port (null)
>   Defaddr->IP  : (null) Port (null)
>   Username : deskbox
>   Codecs   : (ulaw|alaw)
>   Codec Order  : (ulaw|alaw)
>   Status   : UNKNOWN
>   Qualify  : every 6ms when OK, every 1ms when UNREACHABLE 
> (sample smoothing Off)
> 
> 
> This is due to a quirk with how we are currently building the codec 
> preferences list and may get resolved by some stuff rmudgett is working on, 
> so this patch just focuses on resolving the crash.
> 
> 
> Thanks,
> 
> Jonathan Rose
> 
>

-- 
_
-- 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] 3854: manager.c - Improve documentation for manager command Getvar, Setvar

2014-08-01 Thread Mark Michelson 

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

Ship it!


Ship It!

- Mark Michelson


On Aug. 1, 2014, 6:17 p.m., rnewton wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/3854/
> ---
> 
> (Updated Aug. 1, 2014, 6:17 p.m.)
> 
> 
> Review request for Asterisk Developers.
> 
> 
> Bugs: ASTERISK-21178
> https://issues.asterisk.org/jira/browse/ASTERISK-21178
> 
> 
> Repository: Asterisk
> 
> 
> Description
> ---
> 
> The documentation wasn't clear that AMI Getvar and Setvar could accept 
> function calls.
> 
> This is a slight modification to improve clarity.
> 
> 
> Diffs
> -
> 
>   /branches/1.8/main/manager.c 419821 
> 
> Diff: https://reviewboard.asterisk.org/r/3854/diff/
> 
> 
> Testing
> ---
> 
> Once finalized I'll build in dev-mode with it to make sure I didn't screw up 
> any tags.
> 
> 7/30/14 @ 5:52PM CDT - Builds with no issues in dev-mode.
> 
> 
> Thanks,
> 
> rnewton
> 
>

-- 
_
-- 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] 3888: Manager: Add documentation for PJSIPShowEndpoint[s] responses

2014-08-01 Thread Mark Michelson 

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

Ship it!


Ship It!

- Mark Michelson


On Aug. 1, 2014, 12:54 p.m., opticron wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/3888/
> ---
> 
> (Updated Aug. 1, 2014, 12:54 p.m.)
> 
> 
> Review request for Asterisk Developers and Mark Michelson.
> 
> 
> Repository: Asterisk
> 
> 
> Description
> ---
> 
> This adds a large swath of response documentation for PJSIPShowEndpoint and 
> PJSIPShowEndpoints AMI commands. It relies heavily on the existing text in 
> the configInfo documentation via xi:include tags to avoid documentation 
> duplication.
> 
> 
> Diffs
> -
> 
>   trunk/res/res_pjsip.c 419873 
> 
> Diff: https://reviewboard.asterisk.org/r/3888/diff/
> 
> 
> Testing
> ---
> 
> Made sure the commands displayed properly on the CLI.
> 
> 
> 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] 3872: Tests the various ARI channel muting applications (the both, in, and out directions)

2014-08-01 Thread Jonathan Rose 

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


This test unfortunately doesn't work on my box and after discussing it with 
cwolfe, I think it'll be bouncy on Panda. We probably need to re-evaluate our 
approach to this.

- Jonathan Rose


On Aug. 1, 2014, 11:24 a.m., Christopher Wolfe wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/3872/
> ---
> 
> (Updated Aug. 1, 2014, 11:24 a.m.)
> 
> 
> Review request for Asterisk Developers.
> 
> 
> Bugs: ASTERISK-24094
> https://issues.asterisk.org/jira/browse/ASTERISK-24094
> 
> 
> Repository: testsuite
> 
> 
> Description
> ---
> 
> Shows what happens when a Local channel's first half is muted (in the both, 
> in, and out directions) and playback occurs in one of 4 ways:
> 1) Both channel halves play back a sound.
> 2) The first (muted) half plays back a sound only.
> 3) The second (unmuted) half plays back a sound only
> 4) Both channel halves play back a sound, the first channel half gets unmuted 
> and then both channels play back again (shows that unmuting works).
> Uses a TALK_DETECT hook to check whether muting has occurred or not.
> Because muting was more powerful than expected, the conditions listed in the 
> issue do not match what actually is being checked in the test.
> 
> 
> Diffs
> -
> 
>   /asterisk/trunk/tests/rest_api/channels/tests.yaml 5316 
>   /asterisk/trunk/tests/rest_api/channels/mute/tests.yaml PRE-CREATION 
>   /asterisk/trunk/tests/rest_api/channels/mute/out_only/test-config.yaml 
> PRE-CREATION 
>   
> /asterisk/trunk/tests/rest_api/channels/mute/out_only/configs/ast1/extensions.conf
>  PRE-CREATION 
>   /asterisk/trunk/tests/rest_api/channels/mute/in_only/test-config.yaml 
> PRE-CREATION 
>   
> /asterisk/trunk/tests/rest_api/channels/mute/in_only/configs/ast1/extensions.conf
>  PRE-CREATION 
>   /asterisk/trunk/tests/rest_api/channels/mute/both/test-config.yaml 
> PRE-CREATION 
>   
> /asterisk/trunk/tests/rest_api/channels/mute/both/configs/ast1/extensions.conf
>  PRE-CREATION 
> 
> Diff: https://reviewboard.asterisk.org/r/3872/diff/
> 
> 
> Testing
> ---
> 
> Verified that TalkingEvents happened inside the log files.
> For some reason, the ChannelTalkingStart events of AMI didn't accurately show 
> whether talking had occurred on a channel, so those event checkers were 
> scrapped. The ARI ChannelTalkingStarted events were more accurate.
> Made sure that channels have both entered Stasis before starting a test.  
> Only deletes a channel after playback is done. This is so that the results 
> aren't fudged.
> It was discovered during testing that muting is overzealous, so the test just 
> shows what happens in certain muting events.
> 
> 
> 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] 3872: Tests the various ARI channel muting applications (the both, in, and out directions)

2014-08-01 Thread opticron 


> On Aug. 1, 2014, 9:34 a.m., opticron wrote:
> > /asterisk/trunk/tests/rest_api/channels/mute/in_only/test-config.yaml, line 
> > 371
> > 
> >
> > It seems odd that this is not 3. Can this be attributed to the fact 
> > that the audio restarts so quickly that Asterisk never perceives talking to 
> > have stopped?
> > 
> > If that's the case, a short duration of silence may be required for 
> > this test to operate properly on slow machines.
> 
> Christopher Wolfe wrote:
> Adding a delay does not change the results.  Playing back a silence of a 
> short duration adds another ChannelTalkingDetected event.

Please upload a diff with the silence played between the two other prompts. I 
questioned the ChannelTalkingDetected count of 2 because previous tests had 
received 2 of these events for a playback of only the first prompt and here 
you're expecting 2 of these events for a playback of the first prompt AND a 
playback of the second prompt.


- opticron


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


On Aug. 1, 2014, 11:24 a.m., Christopher Wolfe wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/3872/
> ---
> 
> (Updated Aug. 1, 2014, 11:24 a.m.)
> 
> 
> Review request for Asterisk Developers.
> 
> 
> Bugs: ASTERISK-24094
> https://issues.asterisk.org/jira/browse/ASTERISK-24094
> 
> 
> Repository: testsuite
> 
> 
> Description
> ---
> 
> Shows what happens when a Local channel's first half is muted (in the both, 
> in, and out directions) and playback occurs in one of 4 ways:
> 1) Both channel halves play back a sound.
> 2) The first (muted) half plays back a sound only.
> 3) The second (unmuted) half plays back a sound only
> 4) Both channel halves play back a sound, the first channel half gets unmuted 
> and then both channels play back again (shows that unmuting works).
> Uses a TALK_DETECT hook to check whether muting has occurred or not.
> Because muting was more powerful than expected, the conditions listed in the 
> issue do not match what actually is being checked in the test.
> 
> 
> Diffs
> -
> 
>   /asterisk/trunk/tests/rest_api/channels/tests.yaml 5316 
>   /asterisk/trunk/tests/rest_api/channels/mute/tests.yaml PRE-CREATION 
>   /asterisk/trunk/tests/rest_api/channels/mute/out_only/test-config.yaml 
> PRE-CREATION 
>   
> /asterisk/trunk/tests/rest_api/channels/mute/out_only/configs/ast1/extensions.conf
>  PRE-CREATION 
>   /asterisk/trunk/tests/rest_api/channels/mute/in_only/test-config.yaml 
> PRE-CREATION 
>   
> /asterisk/trunk/tests/rest_api/channels/mute/in_only/configs/ast1/extensions.conf
>  PRE-CREATION 
>   /asterisk/trunk/tests/rest_api/channels/mute/both/test-config.yaml 
> PRE-CREATION 
>   
> /asterisk/trunk/tests/rest_api/channels/mute/both/configs/ast1/extensions.conf
>  PRE-CREATION 
> 
> Diff: https://reviewboard.asterisk.org/r/3872/diff/
> 
> 
> Testing
> ---
> 
> Verified that TalkingEvents happened inside the log files.
> For some reason, the ChannelTalkingStart events of AMI didn't accurately show 
> whether talking had occurred on a channel, so those event checkers were 
> scrapped. The ARI ChannelTalkingStarted events were more accurate.
> Made sure that channels have both entered Stasis before starting a test.  
> Only deletes a channel after playback is done. This is so that the results 
> aren't fudged.
> It was discovered during testing that muting is overzealous, so the test just 
> shows what happens in certain muting events.
> 
> 
> 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] 3854: manager.c - Improve documentation for manager command Getvar, Setvar

2014-08-01 Thread rnewton 

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

(Updated Aug. 1, 2014, 6:17 p.m.)


Review request for Asterisk Developers.


Changes
---

In regards to a conversation with M.Jordan, I removed text about variable 
inheritance as there is no need to be overly explicit even if the Set 
application help text already is. Variable inheritance is more general and is 
documented on the wiki already.


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


Repository: Asterisk


Description
---

The documentation wasn't clear that AMI Getvar and Setvar could accept function 
calls.

This is a slight modification to improve clarity.


Diffs (updated)
-

  /branches/1.8/main/manager.c 419821 

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


Testing
---

Once finalized I'll build in dev-mode with it to make sure I didn't screw up 
any tags.

7/30/14 @ 5:52PM CDT - Builds with no issues in dev-mode.


Thanks,

rnewton

-- 
_
-- 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] 3872: Tests the various ARI channel muting applications (the both, in, and out directions)

2014-08-01 Thread Christopher Wolfe 

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

(Updated Aug. 1, 2014, 4:24 p.m.)


Review request for Asterisk Developers.


Changes
---

Fixed naming and syntax.  Couldn't find anything wrong with my results for how 
many ChannelTalkingEvents I got, but I could be wrong.


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


Repository: testsuite


Description
---

Shows what happens when a Local channel's first half is muted (in the both, in, 
and out directions) and playback occurs in one of 4 ways:
1) Both channel halves play back a sound.
2) The first (muted) half plays back a sound only.
3) The second (unmuted) half plays back a sound only
4) Both channel halves play back a sound, the first channel half gets unmuted 
and then both channels play back again (shows that unmuting works).
Uses a TALK_DETECT hook to check whether muting has occurred or not.
Because muting was more powerful than expected, the conditions listed in the 
issue do not match what actually is being checked in the test.


Diffs (updated)
-

  /asterisk/trunk/tests/rest_api/channels/tests.yaml 5316 
  /asterisk/trunk/tests/rest_api/channels/mute/tests.yaml PRE-CREATION 
  /asterisk/trunk/tests/rest_api/channels/mute/out_only/test-config.yaml 
PRE-CREATION 
  
/asterisk/trunk/tests/rest_api/channels/mute/out_only/configs/ast1/extensions.conf
 PRE-CREATION 
  /asterisk/trunk/tests/rest_api/channels/mute/in_only/test-config.yaml 
PRE-CREATION 
  
/asterisk/trunk/tests/rest_api/channels/mute/in_only/configs/ast1/extensions.conf
 PRE-CREATION 
  /asterisk/trunk/tests/rest_api/channels/mute/both/test-config.yaml 
PRE-CREATION 
  
/asterisk/trunk/tests/rest_api/channels/mute/both/configs/ast1/extensions.conf 
PRE-CREATION 

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


Testing
---

Verified that TalkingEvents happened inside the log files.
For some reason, the ChannelTalkingStart events of AMI didn't accurately show 
whether talking had occurred on a channel, so those event checkers were 
scrapped. The ARI ChannelTalkingStarted events were more accurate.
Made sure that channels have both entered Stasis before starting a test.  Only 
deletes a channel after playback is done. This is so that the results aren't 
fudged.
It was discovered during testing that muting is overzealous, so the test just 
shows what happens in certain muting events.


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] 3872: Tests the various ARI channel muting applications (the both, in, and out directions)

2014-08-01 Thread Christopher Wolfe 


> On Aug. 1, 2014, 2:34 p.m., opticron wrote:
> > /asterisk/trunk/tests/rest_api/channels/mute/in_only/test-config.yaml, line 
> > 371
> > 
> >
> > It seems odd that this is not 3. Can this be attributed to the fact 
> > that the audio restarts so quickly that Asterisk never perceives talking to 
> > have stopped?
> > 
> > If that's the case, a short duration of silence may be required for 
> > this test to operate properly on slow machines.

Adding a delay does not change the results.  Playing back a silence of a short 
duration adds another ChannelTalkingDetected event.


> On Aug. 1, 2014, 2:34 p.m., opticron wrote:
> > /asterisk/trunk/tests/rest_api/channels/mute/out_only/test-config.yaml, 
> > line 364
> > 
> >
> > The same comment about silence applies here.

Same comment above.


- Christopher


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


On July 30, 2014, 4:21 p.m., Christopher Wolfe wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/3872/
> ---
> 
> (Updated July 30, 2014, 4:21 p.m.)
> 
> 
> Review request for Asterisk Developers.
> 
> 
> Bugs: ASTERISK-24094
> https://issues.asterisk.org/jira/browse/ASTERISK-24094
> 
> 
> Repository: testsuite
> 
> 
> Description
> ---
> 
> Shows what happens when a Local channel's first half is muted (in the both, 
> in, and out directions) and playback occurs in one of 4 ways:
> 1) Both channel halves play back a sound.
> 2) The first (muted) half plays back a sound only.
> 3) The second (unmuted) half plays back a sound only
> 4) Both channel halves play back a sound, the first channel half gets unmuted 
> and then both channels play back again (shows that unmuting works).
> Uses a TALK_DETECT hook to check whether muting has occurred or not.
> Because muting was more powerful than expected, the conditions listed in the 
> issue do not match what actually is being checked in the test.
> 
> 
> Diffs
> -
> 
>   /asterisk/trunk/tests/rest_api/channels/tests.yaml 5316 
>   /asterisk/trunk/tests/rest_api/channels/mute/tests.yaml PRE-CREATION 
>   /asterisk/trunk/tests/rest_api/channels/mute/out_only/test-config.yaml 
> PRE-CREATION 
>   
> /asterisk/trunk/tests/rest_api/channels/mute/out_only/configs/ast1/extensions.conf
>  PRE-CREATION 
>   /asterisk/trunk/tests/rest_api/channels/mute/in_only/test-config.yaml 
> PRE-CREATION 
>   
> /asterisk/trunk/tests/rest_api/channels/mute/in_only/configs/ast1/extensions.conf
>  PRE-CREATION 
>   /asterisk/trunk/tests/rest_api/channels/mute/both/test-config.yaml 
> PRE-CREATION 
>   
> /asterisk/trunk/tests/rest_api/channels/mute/both/configs/ast1/extensions.conf
>  PRE-CREATION 
>   /asterisk/trunk/sample-yaml/sound-check-config.yaml.sample PRE-CREATION 
> 
> Diff: https://reviewboard.asterisk.org/r/3872/diff/
> 
> 
> Testing
> ---
> 
> Verified that TalkingEvents happened inside the log files.
> For some reason, the ChannelTalkingStart events of AMI didn't accurately show 
> whether talking had occurred on a channel, so those event checkers were 
> scrapped. The ARI ChannelTalkingStarted events were more accurate.
> Made sure that channels have both entered Stasis before starting a test.  
> Only deletes a channel after playback is done. This is so that the results 
> aren't fudged.
> It was discovered during testing that muting is overzealous, so the test just 
> shows what happens in certain muting events.
> 
> 
> 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] 3795: Test for MixMonitor Recording Feature

2014-08-01 Thread opticron 

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

Ship it!


Ship It!

- opticron


On July 25, 2014, 2:51 p.m., Tyler Austin Cambron wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/3795/
> ---
> 
> (Updated July 25, 2014, 2:51 p.m.)
> 
> 
> Review request for Asterisk Developers.
> 
> 
> 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 5315 
>   /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 5315 
> 
> 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] 3797: PJSIP: Add ContactStatusDetail to PJSIPShowEndpoint AMI command output

2014-08-01 Thread Mark Michelson 

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

(Updated Aug. 1, 2014, 9:48 a.m.)


Status
--

This change has been marked as submitted.


Review request for Asterisk Developers.


Changes
---

Committed in revision 419888


Repository: Asterisk


Description
---

This adds additional contact-specific output to PJSIPShowEndpoint output. For 
each contact bound to an AOR, we print the AOR name, the contact URI, whether 
the contact is reachable (or "Untracked" if not qualifying), and the roundtrip 
time for qualification attempts.


Diffs
-

  /trunk/res/res_pjsip/pjsip_options.c 419589 

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


Testing
---

I have created both tracked and untracked contacts and ensured that the output 
looked correct for each.


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] 3797: PJSIP: Add ContactStatusDetail to PJSIPShowEndpoint AMI command output

2014-08-01 Thread opticron 


> On July 31, 2014, 2:09 p.m., opticron wrote:
> > Go ahead and commit this as the code looks good to go. I'll take care of 
> > the documentation for it since PJSIPShowEndpoint is lacking enough in 
> > reponse documentation so as to be out of the scope of this review.

The documentation for this command can be found here: 
https://reviewboard.asterisk.org/r/3888/


- opticron


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


On Aug. 1, 2014, 9:48 a.m., Mark Michelson wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/3797/
> ---
> 
> (Updated Aug. 1, 2014, 9:48 a.m.)
> 
> 
> Review request for Asterisk Developers.
> 
> 
> Repository: Asterisk
> 
> 
> Description
> ---
> 
> This adds additional contact-specific output to PJSIPShowEndpoint output. For 
> each contact bound to an AOR, we print the AOR name, the contact URI, whether 
> the contact is reachable (or "Untracked" if not qualifying), and the 
> roundtrip time for qualification attempts.
> 
> 
> Diffs
> -
> 
>   /trunk/res/res_pjsip/pjsip_options.c 419589 
> 
> Diff: https://reviewboard.asterisk.org/r/3797/diff/
> 
> 
> Testing
> ---
> 
> I have created both tracked and untracked contacts and ensured that the 
> output looked correct for each.
> 
> 
> 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] 3872: Tests the various ARI channel muting applications (the both, in, and out directions)

2014-08-01 Thread opticron 

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



/asterisk/trunk/tests/rest_api/channels/mute/both/test-config.yaml


s/app/API call/



/asterisk/trunk/tests/rest_api/channels/mute/both/test-config.yaml


put "both" in quotes since this sentence seems a bit off otherwise.



/asterisk/trunk/tests/rest_api/channels/mute/both/test-config.yaml


Red blob.



/asterisk/trunk/tests/rest_api/channels/mute/both/test-config.yaml


Red blob.



/asterisk/trunk/tests/rest_api/channels/mute/in_only/test-config.yaml


s/application/API call/

Add quotes to "in".



/asterisk/trunk/tests/rest_api/channels/mute/in_only/test-config.yaml


It seems odd that this is not 3. Can this be attributed to the fact that 
the audio restarts so quickly that Asterisk never perceives talking to have 
stopped?

If that's the case, a short duration of silence may be required for this 
test to operate properly on slow machines.



/asterisk/trunk/tests/rest_api/channels/mute/out_only/test-config.yaml


s/application/API call/



/asterisk/trunk/tests/rest_api/channels/mute/out_only/test-config.yaml


The same comment about silence applies here.


- opticron


On July 30, 2014, 11:21 a.m., Christopher Wolfe wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/3872/
> ---
> 
> (Updated July 30, 2014, 11:21 a.m.)
> 
> 
> Review request for Asterisk Developers.
> 
> 
> Bugs: ASTERISK-24094
> https://issues.asterisk.org/jira/browse/ASTERISK-24094
> 
> 
> Repository: testsuite
> 
> 
> Description
> ---
> 
> Shows what happens when a Local channel's first half is muted (in the both, 
> in, and out directions) and playback occurs in one of 4 ways:
> 1) Both channel halves play back a sound.
> 2) The first (muted) half plays back a sound only.
> 3) The second (unmuted) half plays back a sound only
> 4) Both channel halves play back a sound, the first channel half gets unmuted 
> and then both channels play back again (shows that unmuting works).
> Uses a TALK_DETECT hook to check whether muting has occurred or not.
> Because muting was more powerful than expected, the conditions listed in the 
> issue do not match what actually is being checked in the test.
> 
> 
> Diffs
> -
> 
>   /asterisk/trunk/tests/rest_api/channels/tests.yaml 5316 
>   /asterisk/trunk/tests/rest_api/channels/mute/tests.yaml PRE-CREATION 
>   /asterisk/trunk/tests/rest_api/channels/mute/out_only/test-config.yaml 
> PRE-CREATION 
>   
> /asterisk/trunk/tests/rest_api/channels/mute/out_only/configs/ast1/extensions.conf
>  PRE-CREATION 
>   /asterisk/trunk/tests/rest_api/channels/mute/in_only/test-config.yaml 
> PRE-CREATION 
>   
> /asterisk/trunk/tests/rest_api/channels/mute/in_only/configs/ast1/extensions.conf
>  PRE-CREATION 
>   /asterisk/trunk/tests/rest_api/channels/mute/both/test-config.yaml 
> PRE-CREATION 
>   
> /asterisk/trunk/tests/rest_api/channels/mute/both/configs/ast1/extensions.conf
>  PRE-CREATION 
>   /asterisk/trunk/sample-yaml/sound-check-config.yaml.sample PRE-CREATION 
> 
> Diff: https://reviewboard.asterisk.org/r/3872/diff/
> 
> 
> Testing
> ---
> 
> Verified that TalkingEvents happened inside the log files.
> For some reason, the ChannelTalkingStart events of AMI didn't accurately show 
> whether talking had occurred on a channel, so those event checkers were 
> scrapped. The ARI ChannelTalkingStarted events were more accurate.
> Made sure that channels have both entered Stasis before starting a test.  
> Only deletes a channel after playback is done. This is so that the results 
> aren't fudged.
> It was discovered during testing that muting is overzealous, so the test just 
> shows what happens in certain muting events.
> 
> 
> 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

[asterisk-dev] [Code Review] 3888: Manager: Add documentation for PJSIPShowEndpoint[s] responses

2014-08-01 Thread opticron 

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

Review request for Asterisk Developers and Mark Michelson.


Repository: Asterisk


Description
---

This adds a large swath of response documentation for PJSIPShowEndpoint and 
PJSIPShowEndpoints AMI commands. It relies heavily on the existing text in the 
configInfo documentation via xi:include tags to avoid documentation duplication.


Diffs
-

  trunk/res/res_pjsip.c 419873 

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


Testing
---

Made sure the commands displayed properly on the CLI.


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] 3797: PJSIP: Add ContactStatusDetail to PJSIPShowEndpoint AMI command output

2014-08-01 Thread opticron 

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



/trunk/res/res_pjsip/pjsip_options.c


Actually, before committing this, ContactStatusDetail needs to have an 
EndpointName key/value pair as well to match the other *Detail events emitted 
as part of this command.


- opticron


On July 29, 2014, 3:05 p.m., Mark Michelson wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/3797/
> ---
> 
> (Updated July 29, 2014, 3:05 p.m.)
> 
> 
> Review request for Asterisk Developers.
> 
> 
> Repository: Asterisk
> 
> 
> Description
> ---
> 
> This adds additional contact-specific output to PJSIPShowEndpoint output. For 
> each contact bound to an AOR, we print the AOR name, the contact URI, whether 
> the contact is reachable (or "Untracked" if not qualifying), and the 
> roundtrip time for qualification attempts.
> 
> 
> Diffs
> -
> 
>   /trunk/res/res_pjsip/pjsip_options.c 419589 
> 
> Diff: https://reviewboard.asterisk.org/r/3797/diff/
> 
> 
> Testing
> ---
> 
> I have created both tracked and untracked contacts and ensured that the 
> output looked correct for each.
> 
> 
> 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

[asterisk-dev] Read dtmf after ast_bridge_call

2014-08-01 Thread vassilux . 
Hi,

I try to read DTMF digits from a channel after calling ast_bridge_call.
There are a lot of errors about  : "called with no recorded file
descriptor" from
static struct ast_frame *__ast_read(struct ast_channel *chan, int
dropaudio) function.

I can read DTMF digits before execute ast_bridge_call.

I made something wrong but I don't know :-) thank to help me

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