[asterisk-dev] 12.5.0 cache_entry_compute_hash/app_meeme crash

2014-08-29 Thread Jared Mauch 

I have a crash here:

(gdb) bt
#0  ast_hashtab_hash_string (obj=0x144) at hashtab.c:166
#1  0x005937d2 in cache_entry_compute_hash (cache=0x2b70870, 
type=, id=0x144 ) at 
stasis_cache.c:180
#2  cache_find (cache=0x2b70870, type=, id=0x144 ) at stasis_cache.c:362
#3  stasis_cache_get_by_eid (cache=0x2b70870, type=, 
id=0x144 ) at stasis_cache.c:627
#4  stasis_cache_get (cache=0x2b70870, type=, id=0x144 
) at stasis_cache.c:641
#5  0x00597350 in ast_channel_snapshot_get_latest (channel_id=0x144 
, type=0x34595a8, blob=0x7f4b78002058) at 
stasis_channels.c:516
#6  ast_channel_blob_create_from_cache (channel_id=0x144 , type=0x34595a8, blob=0x7f4b78002058) at stasis_channels.c:407
#7  0x7f4d1e5036fe in meetme_stasis_generate_msg (meetme_conference=, chan=0x0, user=0x0, message_type=0x34595a8, extras=)
at app_meetme.c:1382
#8  0x7f4d1e5037c1 in conf_free (conf=0x7f4b78002a20) at app_meetme.c:2326
#9  0x7f4d1e515db3 in dispose_conf (chan=0x7f4b480eab78, data=) at app_meetme.c:2503
#10 conf_exec (chan=0x7f4b480eab78, data=) at 
app_meetme.c:5143
#11 0x0054a915 in pbx_exec (c=0x7f4b480eab78, app=0x345b100, 
data=0x7f4a499f5690 "4006,cdsT") at pbx.c:1606
#12 0x00554b9e in pbx_extension_helper (c=0x7f4b480eab78, con=0x0, 
context=0x7f4b480ebc18 "macro-stdconf", exten=0x7f4b480ebc68 "s", priority=11, 
label=0x0, 
callerid=0x7f4b48062a80 "1005", action=E_SPAWN, found=0x7f4a499f857c, 
combined_find_spawn=1) at pbx.c:4878
#13 0x00555020 in ast_spawn_extension (c=, 
context=, exten=, priority=, 
callerid=, found=, 
combined_find_spawn=1) at pbx.c:5893
#14 0x7f4d17de7c78 in _macro_exec (chan=0x7f4b78002358, data=, exclusive=0) at app_macro.c:412
#15 0x0054a915 in pbx_exec (c=0x7f4b480eab78, app=0x330ac70, 
data=0x7f4a499f86e0 "stdconf,4006,,0,Shawn Morris,0,1006,0,0,0,0") at 
pbx.c:1606
#16 0x00554b9e in pbx_extension_helper (c=0x7f4b480eab78, con=0x0, 
context=0x7f4b480ebc18 "macro-stdconf", exten=0x7f4b480ebc68 "s", priority=1, 
label=0x0, 
callerid=0x7f4b48062a80 "1005", action=E_SPAWN, found=0x7f4a499facbc, 
combined_find_spawn=1) at pbx.c:4878
#17 0x0055b515 in ast_spawn_extension (c=0x7f4b480eab78, args=0x0) at 
pbx.c:5893
#18 __ast_pbx_run (c=0x7f4b480eab78, args=0x0) at pbx.c:6310
---Type  to continue, or q  to quit---down
#19 0x0055cbfb in pbx_thread (data=) at pbx.c:6635
#20 0x005b197b in dummy_start (data=) at 
utils.c:1170
#21 0x00380dc079d1 in start_thread () from /lib64/libpthread.so.0
#22 0x00380d8e8b5d in clone () from /lib64/libc.so.6


It appears to be triggered when taking the meetme_statis_generate_msg of
chan=NULL and passing it downstream to ast_channel_blob_create_from_cache

#7  0x7f4d1e5036fe in meetme_stasis_generate_msg (meetme_conference=, chan=0x0, user=0x0, message_type=0x34595a8, extras=)
at app_meetme.c:1382
1382msg = 
ast_channel_blob_create_from_cache(ast_channel_uniqueid(chan), message_type, 
json_object);

seems there should be a check here in app_meetme.c for this.  I also saw
either this or something similar in asterisk-13.0.0-beta1.

I'm working on converting everything to confbridge vs meetme but
not quite there yet as some meetme features we are using are missing
and not available via ari/ami.  (I will be submitting patches for this
soon).

This occurs when someone is hanging up on a meetme room and I can easily
replicate it on demand.

This patch seems to correct the issue as it doesn't reference a null via
ast_channel_unique()

diff -ur asterisk-12.5.0-dist/apps/app_meetme.c 
asterisk-12.5.0/apps/app_meetme.c
--- asterisk-12.5.0-dist/apps/app_meetme.c  2014-07-22 14:13:14.0 
+
+++ asterisk-12.5.0/apps/app_meetme.c   2014-08-30 03:00:37.281344307 +
@@ -1379,6 +1379,9 @@
}
}
 
+   if (chan == NULL) {
+   return;
+   }
msg = ast_channel_blob_create_from_cache(ast_channel_uniqueid(chan), 
message_type, json_object);
 
if (!msg) {


- Jared

-- 
Jared Mauch  | pgp key available via finger from ja...@puck.nether.net
clue++;  | http://puck.nether.net/~jared/  My statements are only mine.

-- 
_
-- 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] 3963: testsuite: Add a test that verifies CDRs with a Dial embedded in a subroutine/macro

2014-08-29 Thread Matt Jordan 

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

Review request for Asterisk Developers.


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


Repository: testsuite


Description
---

This patch is the test for r3962. It verifies CDRs have the correct fields 
(including extension/context) in the following scenarios:
* Dialling 'normally'
* Dialling in a GoSub subroutine
* Dialling in a Macro
* Dialling in a GoSub called from a Macro called from a GoSub

This patch also adds the CDR tag to hangup handlers, as they cover 
endbeforehexten logic.


Diffs
-

  /asterisk/trunk/tests/hangup/handlers_endbeforehexten/test-config.yaml 5469 
  /asterisk/trunk/tests/hangup/handlers/test-config.yaml 5469 
  /asterisk/trunk/tests/cdr/tests.yaml 5469 
  /asterisk/trunk/tests/cdr/cdr_dial_subroutines/test-config.yaml PRE-CREATION 
  /asterisk/trunk/tests/cdr/cdr_dial_subroutines/configs/ast1/extensions.conf 
PRE-CREATION 

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


Testing
---


Thanks,

Matt Jordan

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

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

[asterisk-dev] [Code Review] 3962: CDRs: preserve context/extension when executing a Macro or GoSub

2014-08-29 Thread Matt Jordan 

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

Review request for Asterisk Developers.


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


Repository: Asterisk


Description
---

The context/extension in a CDR is generally considered the destination of a 
call. When looking at a 2-party call CDR, users will typically be presented 
with the following:

contextexten  channel dest_channel app  data
default1000   SIP/8675309 SIP/1000 Dial SIP/1000,,20

However, if the Dial actually takes place in a Macro, the current behaviour in 
12 will result in the following CDR:

contextexten  channel dest_channel app  data
macro-dial s  SIP/8675309 SIP/1000 Dial SIP/1000,,20

The same is true of a GoSub:

contextexten  channel dest_channel app  data
subs   dial_stuff SIP/8675309 SIP/1000 Dial SIP/1000,,20

This generally makes the context/exten fields less than useful.

It isn't hard to preserve these values in the CDR state machine; however, we 
need to have something that informs us when a channel is executing a 
subroutine. Today, there isn't anything that does this.

This patch solves this problem by adding a new channel flag, 
AST_FLAG_SUBROUTINE_EXEC. This flag is set on a channel when it executes a 
Macro or a GoSub. The CDR engine looks for this value when updating a Party A 
snapshot; if the flag is present, we don't override the context/exten on the 
main CDR object. In a funny quirk, executing a hangup handler must *not* abide 
by this logic, as the endbeforehexten logic assumes that the user wants to see 
data that occurs in hangup logic, which includes those subroutines. Since those 
execute outside of a typical Dial operation (and will typically have their own 
dedicated CDR anyway), this is unlikely to cause any heartburn.


Diffs
-

  /branches/12/main/cdr.c 422438 
  /branches/12/include/asterisk/channel.h 422438 
  /branches/12/apps/app_stack.c 422438 
  /branches/12/apps/app_macro.c 422438 

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


Testing
---

All existing CDR tests and the hangup handler tests pass.

In addition, a new test has been added on review 3963. This test performs 
several Dials within a Macro/GoSub, with at least one nested GoSub/Macro/GoSub 
wrapping a Dial. The CDR entry is verified to have the expected fields.


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] 3929: ARI: Holding bridge issues with bridge Music on Hold, playback operations, and default channel roles

2014-08-29 Thread Matt Jordan 


> On Aug. 29, 2014, 3:52 p.m., rmudgett wrote:
> > /branches/12/res/stasis/stasis_bridge.c, line 140
> > 
> >
> > Optional nit: Extra blank line :)
> 
> Matt Jordan wrote:
> Well, that extra blank line was there to prevent the conditional clauses 
> in the if statement from lining up to closely with the code inside the if 
> statement. I can remove the tabs for the conditional clauses and use spaces 
> instead, but I'm not sure how much it will improve readability.
> 
> rmudgett wrote:
> I don't think simply removing the blank line alters the readability 
> because the guidelines make it that way.  Though mixing tabs and spaces tends 
> to make people see red. :)

True, true. I can remove the spaces if desired. Formatting long if statements: 
blech.


- Matt


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


On Aug. 29, 2014, 7:31 p.m., Matt Jordan wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/3929/
> ---
> 
> (Updated Aug. 29, 2014, 7:31 p.m.)
> 
> 
> Review request for Asterisk Developers.
> 
> 
> Bugs: ASTERISK-24264
> https://issues.asterisk.org/jira/browse/ASTERISK-24264
> 
> 
> Repository: Asterisk
> 
> 
> Description
> ---
> 
> When ARI manipulates a bridge, it generally doesn't care what the mixing 
> technology is. Operations should initiate on the bridge regardless of its 
> mixing technology - and while that mixing technology may determine the 
> experience channels within the bridge have, the actual operations themselves 
> should be the same.
> 
> This isn't the case with holding bridges. Currently, the following issues 
> exist:
>  * Music on Hold is played into a bridge using an Announcer channel. There 
> are two issues with it currently:
>(1) The Music on Hold channel is also not marked as being allowed within a 
> Stasis bridge, so it generally never makes it into the bridge (of any type).
>(2) Even if it did, because it does not have a bridge role of "announcer", 
> it joins the holding bridge as a participant. Additionally, the holding 
> bridge starts MoH on the Announcer channel (which is ironic, but not super 
> useful).
>  * Playback channels do not join as an announcer. Playing back announcements 
> using the /play operation would not be heard by participants.
>  * Participants join without a role. As such, MoH is started for the channels 
> automatically; however, subsequent bridge operations that would stop MoH 
> would fail (as there is no Announcer channel playing MoH to the bridge). From 
> the perspective of ARI users, this is counter-intuitive - I would not expect 
> MoH to be started for me. The mixing technology determines how media is 
> shared between participants, not the application experience.
> 
> This patch does the following:
>  * The Stasis bridge class now inspects channels as they are going into a 
> bridge. If the bridge has a holding capability, and the channel has no roles, 
> we give it a participant role and mark the default behaviour to have no 
> entertainment. This allows addChannel operations to continue to set a 
> participant role with an entertainment option if it felt like it (or could do 
> it).
>  * The playback channel now gets a role of announcer, as does the music on 
> hold channel. For mixing technologies this is a NoOp; for holding bridges it 
> means the channels should have the expected behaviour.
>  * The music on hold channel is now Stasis approved (tm)
>  * Finally, a small bug in 'core show channel' was observed, in that we 
> attempted to calculate CDR variables for internal channels. That generates an 
> annoying warning; internal channels now no longer attempt to access CDR data.
> 
> 
> Diffs
> -
> 
>   /branches/12/res/stasis/stasis_bridge.c 422438 
>   /branches/12/res/res_stasis.c 422438 
>   /branches/12/main/cli.c 422438 
> 
> Diff: https://reviewboard.asterisk.org/r/3929/diff/
> 
> 
> Testing
> ---
> 
> The bridge-infinite-wait examples on the wiki (that Sam and I are working on) 
> now ... work.
> 
> 
> 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] 3929: ARI: Holding bridge issues with bridge Music on Hold, playback operations, and default channel roles

2014-08-29 Thread rmudgett 

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

Ship it!


Don't have anything else to say about the patch.

- rmudgett


On Aug. 29, 2014, 7:31 p.m., Matt Jordan wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/3929/
> ---
> 
> (Updated Aug. 29, 2014, 7:31 p.m.)
> 
> 
> Review request for Asterisk Developers.
> 
> 
> Bugs: ASTERISK-24264
> https://issues.asterisk.org/jira/browse/ASTERISK-24264
> 
> 
> Repository: Asterisk
> 
> 
> Description
> ---
> 
> When ARI manipulates a bridge, it generally doesn't care what the mixing 
> technology is. Operations should initiate on the bridge regardless of its 
> mixing technology - and while that mixing technology may determine the 
> experience channels within the bridge have, the actual operations themselves 
> should be the same.
> 
> This isn't the case with holding bridges. Currently, the following issues 
> exist:
>  * Music on Hold is played into a bridge using an Announcer channel. There 
> are two issues with it currently:
>(1) The Music on Hold channel is also not marked as being allowed within a 
> Stasis bridge, so it generally never makes it into the bridge (of any type).
>(2) Even if it did, because it does not have a bridge role of "announcer", 
> it joins the holding bridge as a participant. Additionally, the holding 
> bridge starts MoH on the Announcer channel (which is ironic, but not super 
> useful).
>  * Playback channels do not join as an announcer. Playing back announcements 
> using the /play operation would not be heard by participants.
>  * Participants join without a role. As such, MoH is started for the channels 
> automatically; however, subsequent bridge operations that would stop MoH 
> would fail (as there is no Announcer channel playing MoH to the bridge). From 
> the perspective of ARI users, this is counter-intuitive - I would not expect 
> MoH to be started for me. The mixing technology determines how media is 
> shared between participants, not the application experience.
> 
> This patch does the following:
>  * The Stasis bridge class now inspects channels as they are going into a 
> bridge. If the bridge has a holding capability, and the channel has no roles, 
> we give it a participant role and mark the default behaviour to have no 
> entertainment. This allows addChannel operations to continue to set a 
> participant role with an entertainment option if it felt like it (or could do 
> it).
>  * The playback channel now gets a role of announcer, as does the music on 
> hold channel. For mixing technologies this is a NoOp; for holding bridges it 
> means the channels should have the expected behaviour.
>  * The music on hold channel is now Stasis approved (tm)
>  * Finally, a small bug in 'core show channel' was observed, in that we 
> attempted to calculate CDR variables for internal channels. That generates an 
> annoying warning; internal channels now no longer attempt to access CDR data.
> 
> 
> Diffs
> -
> 
>   /branches/12/res/stasis/stasis_bridge.c 422438 
>   /branches/12/res/res_stasis.c 422438 
>   /branches/12/main/cli.c 422438 
> 
> Diff: https://reviewboard.asterisk.org/r/3929/diff/
> 
> 
> Testing
> ---
> 
> The bridge-infinite-wait examples on the wiki (that Sam and I are working on) 
> now ... work.
> 
> 
> 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] 3929: ARI: Holding bridge issues with bridge Music on Hold, playback operations, and default channel roles

2014-08-29 Thread rmudgett 


> On Aug. 29, 2014, 3:52 p.m., rmudgett wrote:
> > /branches/12/res/stasis/stasis_bridge.c, line 140
> > 
> >
> > Optional nit: Extra blank line :)
> 
> Matt Jordan wrote:
> Well, that extra blank line was there to prevent the conditional clauses 
> in the if statement from lining up to closely with the code inside the if 
> statement. I can remove the tabs for the conditional clauses and use spaces 
> instead, but I'm not sure how much it will improve readability.

I don't think simply removing the blank line alters the readability because the 
guidelines make it that way.  Though mixing tabs and spaces tends to make 
people see red. :)


- rmudgett


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


On Aug. 29, 2014, 7:31 p.m., Matt Jordan wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/3929/
> ---
> 
> (Updated Aug. 29, 2014, 7:31 p.m.)
> 
> 
> Review request for Asterisk Developers.
> 
> 
> Bugs: ASTERISK-24264
> https://issues.asterisk.org/jira/browse/ASTERISK-24264
> 
> 
> Repository: Asterisk
> 
> 
> Description
> ---
> 
> When ARI manipulates a bridge, it generally doesn't care what the mixing 
> technology is. Operations should initiate on the bridge regardless of its 
> mixing technology - and while that mixing technology may determine the 
> experience channels within the bridge have, the actual operations themselves 
> should be the same.
> 
> This isn't the case with holding bridges. Currently, the following issues 
> exist:
>  * Music on Hold is played into a bridge using an Announcer channel. There 
> are two issues with it currently:
>(1) The Music on Hold channel is also not marked as being allowed within a 
> Stasis bridge, so it generally never makes it into the bridge (of any type).
>(2) Even if it did, because it does not have a bridge role of "announcer", 
> it joins the holding bridge as a participant. Additionally, the holding 
> bridge starts MoH on the Announcer channel (which is ironic, but not super 
> useful).
>  * Playback channels do not join as an announcer. Playing back announcements 
> using the /play operation would not be heard by participants.
>  * Participants join without a role. As such, MoH is started for the channels 
> automatically; however, subsequent bridge operations that would stop MoH 
> would fail (as there is no Announcer channel playing MoH to the bridge). From 
> the perspective of ARI users, this is counter-intuitive - I would not expect 
> MoH to be started for me. The mixing technology determines how media is 
> shared between participants, not the application experience.
> 
> This patch does the following:
>  * The Stasis bridge class now inspects channels as they are going into a 
> bridge. If the bridge has a holding capability, and the channel has no roles, 
> we give it a participant role and mark the default behaviour to have no 
> entertainment. This allows addChannel operations to continue to set a 
> participant role with an entertainment option if it felt like it (or could do 
> it).
>  * The playback channel now gets a role of announcer, as does the music on 
> hold channel. For mixing technologies this is a NoOp; for holding bridges it 
> means the channels should have the expected behaviour.
>  * The music on hold channel is now Stasis approved (tm)
>  * Finally, a small bug in 'core show channel' was observed, in that we 
> attempted to calculate CDR variables for internal channels. That generates an 
> annoying warning; internal channels now no longer attempt to access CDR data.
> 
> 
> Diffs
> -
> 
>   /branches/12/res/stasis/stasis_bridge.c 422438 
>   /branches/12/res/res_stasis.c 422438 
>   /branches/12/main/cli.c 422438 
> 
> Diff: https://reviewboard.asterisk.org/r/3929/diff/
> 
> 
> Testing
> ---
> 
> The bridge-infinite-wait examples on the wiki (that Sam and I are working on) 
> now ... work.
> 
> 
> 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] 3929: ARI: Holding bridge issues with bridge Music on Hold, playback operations, and default channel roles

2014-08-29 Thread Matt Jordan 


> On Aug. 29, 2014, 3:52 p.m., rmudgett wrote:
> > /branches/12/res/stasis/stasis_bridge.c, line 140
> > 
> >
> > Optional nit: Extra blank line :)

Well, that extra blank line was there to prevent the conditional clauses in the 
if statement from lining up to closely with the code inside the if statement. I 
can remove the tabs for the conditional clauses and use spaces instead, but I'm 
not sure how much it will improve readability.


- Matt


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


On Aug. 29, 2014, 3:15 p.m., Matt Jordan wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/3929/
> ---
> 
> (Updated Aug. 29, 2014, 3:15 p.m.)
> 
> 
> Review request for Asterisk Developers.
> 
> 
> Bugs: ASTERISK-24264
> https://issues.asterisk.org/jira/browse/ASTERISK-24264
> 
> 
> Repository: Asterisk
> 
> 
> Description
> ---
> 
> When ARI manipulates a bridge, it generally doesn't care what the mixing 
> technology is. Operations should initiate on the bridge regardless of its 
> mixing technology - and while that mixing technology may determine the 
> experience channels within the bridge have, the actual operations themselves 
> should be the same.
> 
> This isn't the case with holding bridges. Currently, the following issues 
> exist:
>  * Music on Hold is played into a bridge using an Announcer channel. There 
> are two issues with it currently:
>(1) The Music on Hold channel is also not marked as being allowed within a 
> Stasis bridge, so it generally never makes it into the bridge (of any type).
>(2) Even if it did, because it does not have a bridge role of "announcer", 
> it joins the holding bridge as a participant. Additionally, the holding 
> bridge starts MoH on the Announcer channel (which is ironic, but not super 
> useful).
>  * Playback channels do not join as an announcer. Playing back announcements 
> using the /play operation would not be heard by participants.
>  * Participants join without a role. As such, MoH is started for the channels 
> automatically; however, subsequent bridge operations that would stop MoH 
> would fail (as there is no Announcer channel playing MoH to the bridge). From 
> the perspective of ARI users, this is counter-intuitive - I would not expect 
> MoH to be started for me. The mixing technology determines how media is 
> shared between participants, not the application experience.
> 
> This patch does the following:
>  * The Stasis bridge class now inspects channels as they are going into a 
> bridge. If the bridge has a holding capability, and the channel has no roles, 
> we give it a participant role and mark the default behaviour to have no 
> entertainment. This allows addChannel operations to continue to set a 
> participant role with an entertainment option if it felt like it (or could do 
> it).
>  * The playback channel now gets a role of announcer, as does the music on 
> hold channel. For mixing technologies this is a NoOp; for holding bridges it 
> means the channels should have the expected behaviour.
>  * The music on hold channel is now Stasis approved (tm)
>  * Finally, a small bug in 'core show channel' was observed, in that we 
> attempted to calculate CDR variables for internal channels. That generates an 
> annoying warning; internal channels now no longer attempt to access CDR data.
> 
> 
> Diffs
> -
> 
>   /branches/12/res/stasis/stasis_bridge.c 422380 
>   /branches/12/res/res_stasis.c 422380 
>   /branches/12/res/ari/resource_bridges.c 422380 
>   /branches/12/main/cli.c 422380 
> 
> Diff: https://reviewboard.asterisk.org/r/3929/diff/
> 
> 
> Testing
> ---
> 
> The bridge-infinite-wait examples on the wiki (that Sam and I are working on) 
> now ... work.
> 
> 
> 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] 3929: ARI: Holding bridge issues with bridge Music on Hold, playback operations, and default channel roles

2014-08-29 Thread Matt Jordan 

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

(Updated Aug. 29, 2014, 7:31 p.m.)


Review request for Asterisk Developers.


Changes
---

Addressed Richard's second round.


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


Repository: Asterisk


Description
---

When ARI manipulates a bridge, it generally doesn't care what the mixing 
technology is. Operations should initiate on the bridge regardless of its 
mixing technology - and while that mixing technology may determine the 
experience channels within the bridge have, the actual operations themselves 
should be the same.

This isn't the case with holding bridges. Currently, the following issues exist:
 * Music on Hold is played into a bridge using an Announcer channel. There are 
two issues with it currently:
   (1) The Music on Hold channel is also not marked as being allowed within a 
Stasis bridge, so it generally never makes it into the bridge (of any type).
   (2) Even if it did, because it does not have a bridge role of "announcer", 
it joins the holding bridge as a participant. Additionally, the holding bridge 
starts MoH on the Announcer channel (which is ironic, but not super useful).
 * Playback channels do not join as an announcer. Playing back announcements 
using the /play operation would not be heard by participants.
 * Participants join without a role. As such, MoH is started for the channels 
automatically; however, subsequent bridge operations that would stop MoH would 
fail (as there is no Announcer channel playing MoH to the bridge). From the 
perspective of ARI users, this is counter-intuitive - I would not expect MoH to 
be started for me. The mixing technology determines how media is shared between 
participants, not the application experience.

This patch does the following:
 * The Stasis bridge class now inspects channels as they are going into a 
bridge. If the bridge has a holding capability, and the channel has no roles, 
we give it a participant role and mark the default behaviour to have no 
entertainment. This allows addChannel operations to continue to set a 
participant role with an entertainment option if it felt like it (or could do 
it).
 * The playback channel now gets a role of announcer, as does the music on hold 
channel. For mixing technologies this is a NoOp; for holding bridges it means 
the channels should have the expected behaviour.
 * The music on hold channel is now Stasis approved (tm)
 * Finally, a small bug in 'core show channel' was observed, in that we 
attempted to calculate CDR variables for internal channels. That generates an 
annoying warning; internal channels now no longer attempt to access CDR data.


Diffs (updated)
-

  /branches/12/res/stasis/stasis_bridge.c 422438 
  /branches/12/res/res_stasis.c 422438 
  /branches/12/main/cli.c 422438 

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


Testing
---

The bridge-infinite-wait examples on the wiki (that Sam and I are working on) 
now ... work.


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] 3929: ARI: Holding bridge issues with bridge Music on Hold, playback operations, and default channel roles

2014-08-29 Thread Matt Jordan 


> On Aug. 29, 2014, 3:52 p.m., rmudgett wrote:
> > /branches/12/res/stasis/stasis_bridge.c, lines 137-139
> > 
> >
> > Since ARI can set a channel's role as holding_participant but currently 
> > cannot set options on a role, the holding technology will play MOH as a 
> > default.  You probably want to check that the idle_mode option is set as 
> > well.

I'm not sure why I would check that. If the channel has any role currently set, 
then I should just not bother setting anything, as someone else has set the 
role. Whether or not the idle mode is set is immaterial: if someone has set a 
role that the holding bridge would recognize, I shouldn't override that.


> On Aug. 29, 2014, 3:52 p.m., rmudgett wrote:
> > /branches/12/res/stasis/stasis_bridge.c, line 146
> > 
> >
> > Would silence be a better thing to send than nothing while a channel is 
> > in a holding bridge without an announcer?
> > 
> > Optionally it could be "none" or "silence" depending on the 
> > asterisk.conf:transmit_silence option.

No. Inferring actions in ARI is bad. Users can start a silence generator on a 
channel already; if they want silence, they can start it.

Guessing what users want is how we got here in the first place :-)


- Matt


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


On Aug. 29, 2014, 3:15 p.m., Matt Jordan wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/3929/
> ---
> 
> (Updated Aug. 29, 2014, 3:15 p.m.)
> 
> 
> Review request for Asterisk Developers.
> 
> 
> Bugs: ASTERISK-24264
> https://issues.asterisk.org/jira/browse/ASTERISK-24264
> 
> 
> Repository: Asterisk
> 
> 
> Description
> ---
> 
> When ARI manipulates a bridge, it generally doesn't care what the mixing 
> technology is. Operations should initiate on the bridge regardless of its 
> mixing technology - and while that mixing technology may determine the 
> experience channels within the bridge have, the actual operations themselves 
> should be the same.
> 
> This isn't the case with holding bridges. Currently, the following issues 
> exist:
>  * Music on Hold is played into a bridge using an Announcer channel. There 
> are two issues with it currently:
>(1) The Music on Hold channel is also not marked as being allowed within a 
> Stasis bridge, so it generally never makes it into the bridge (of any type).
>(2) Even if it did, because it does not have a bridge role of "announcer", 
> it joins the holding bridge as a participant. Additionally, the holding 
> bridge starts MoH on the Announcer channel (which is ironic, but not super 
> useful).
>  * Playback channels do not join as an announcer. Playing back announcements 
> using the /play operation would not be heard by participants.
>  * Participants join without a role. As such, MoH is started for the channels 
> automatically; however, subsequent bridge operations that would stop MoH 
> would fail (as there is no Announcer channel playing MoH to the bridge). From 
> the perspective of ARI users, this is counter-intuitive - I would not expect 
> MoH to be started for me. The mixing technology determines how media is 
> shared between participants, not the application experience.
> 
> This patch does the following:
>  * The Stasis bridge class now inspects channels as they are going into a 
> bridge. If the bridge has a holding capability, and the channel has no roles, 
> we give it a participant role and mark the default behaviour to have no 
> entertainment. This allows addChannel operations to continue to set a 
> participant role with an entertainment option if it felt like it (or could do 
> it).
>  * The playback channel now gets a role of announcer, as does the music on 
> hold channel. For mixing technologies this is a NoOp; for holding bridges it 
> means the channels should have the expected behaviour.
>  * The music on hold channel is now Stasis approved (tm)
>  * Finally, a small bug in 'core show channel' was observed, in that we 
> attempted to calculate CDR variables for internal channels. That generates an 
> annoying warning; internal channels now no longer attempt to access CDR data.
> 
> 
> Diffs
> -
> 
>   /branches/12/res/stasis/stasis_bridge.c 422380 
>   /branches/12/res/res_stasis.c 422380 
>   /branches/12/res/ari/resource_bridges.c 422380 
>   /branches/12/main/cli.c 422380 
> 
> Diff: https://reviewboard.asterisk.org/r/3929/diff/
> 
> 
> Testing
> ---
> 
> The bridge-infinite-wait examples on the wiki (that Sam and I are w

Re: [asterisk-dev] [Code Review] 3948: Asterisk does not respect outbound proxy when sending qualify requests

2014-08-29 Thread Damian Ivereigh 

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


Thanks for all that info Matt. In answer to the question "how should 
outboundproxy behave", perhaps it might be useful to detail my setup. I have a 
number of Asterisk servers on an internal network with a kamailio server and a 
media proxy facing the internet. My goal was to harden the kamailio server and 
allow the asterisk servers to be less secure and allow each asterisk to define 
it's own peers. I want as close as possible for each Asterisk server to appear 
to the outside world as if they are externally connected (no NAT stuff), yet 
actually put everything through kamailio and the media proxy.

So the obvious solution was to use outboundproxy to get asterisk to send its 
outgoing invites and registrations through the kamailio server which would 
mangle them so that everything appeared to come from the external server. 
However things fell apart when asterisk tried to send qualify requests direct 
(which the firewall blocked). Hence this fix. I really cannot see a situation 
where one would use an outboundproxy and then want to send the qualify requests 
directly. 

- Damian Ivereigh


On Aug. 25, 2014, 10:04 p.m., Damian Ivereigh wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/3948/
> ---
> 
> (Updated Aug. 25, 2014, 10:04 p.m.)
> 
> 
> Review request for Asterisk Developers.
> 
> 
> Bugs: ASTERISK-24063
> https://issues.asterisk.org/jira/browse/ASTERISK-24063
> 
> 
> Repository: Asterisk
> 
> 
> Description
> ---
> 
> The outboundproxy setting is ignored when sending the qualify packets 
> (OPTIONS). This means that if an asterisk server is unable to send the packet 
> directly to a peer, it is unable to qualify any non inbound registered peer 
> (e.g. a peer SIP Trunk). This problem is found on asterisk-11.6-cert4 (and 
> many others)
> 
> It has been pointed out (thanks Walter Doekes), that the p->outboundproxy may 
> not be freed at the end which would create a memory leak.   
> 
> 
> Diffs
> -
> 
>   certified/tags/11.6-cert4/channels/chan_sip.c 422052 
> 
> Diff: https://reviewboard.asterisk.org/r/3948/diff/
> 
> 
> Testing
> ---
> 
> Have run this change in production for many months, however the possible 
> memory leak issue needs to be verified.
> 
> 
> Thanks,
> 
> Damian Ivereigh
> 
>

-- 
_
-- 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] 3955: confbridge: Add Duration to ConfbridgeList event

2014-08-29 Thread rmudgett 

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

Ship it!


Ship It!

- rmudgett


On Aug. 29, 2014, 5:27 p.m., George Joseph wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/3955/
> ---
> 
> (Updated Aug. 29, 2014, 5:27 p.m.)
> 
> 
> Review request for Asterisk Developers and rmudgett.
> 
> 
> Repository: Asterisk
> 
> 
> Description
> ---
> 
> The ConfbridgeList event doesn't include how long the user has been a member 
> of the conference.  This patch adds Duration (seconds) which is based on 
> user->chan->answertime.
> 
> 
> Diffs
> -
> 
>   branches/12/apps/app_confbridge.c 422257 
> 
> Diff: https://reviewboard.asterisk.org/r/3955/diff/
> 
> 
> Testing
> ---
> 
> Looked at the output of a ConfbridgeList event to make sure Duration was 
> being set correctly and no other fields were affected.
> 
> 
> Thanks,
> 
> George Joseph
> 
>

-- 
_
-- 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] 3958: manager: Make WaitEvent action respect eventfilters

2014-08-29 Thread rmudgett 

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

Ship it!


This applies to v1.8+

- rmudgett


On Aug. 28, 2014, 4:11 p.m., George Joseph wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/3958/
> ---
> 
> (Updated Aug. 28, 2014, 4:11 p.m.)
> 
> 
> Review request for Asterisk Developers.
> 
> 
> Repository: Asterisk
> 
> 
> Description
> ---
> 
> A WaitEvent issued via an http session isn't respecting eventfilters defined 
> for the user. I just added a match_filter to the predicate that controls 
> astman_append.
> 
> 
> Diffs
> -
> 
>   branches/12/main/manager.c 422277 
> 
> Diff: https://reviewboard.asterisk.org/r/3958/diff/
> 
> 
> Testing
> ---
> 
> Verified that events to be filtered are indeed filtered and that events not 
> supposed to be filtered aren't.
> 
> I ran the manager TestSuite but 4 of 9 tests failed BEFORE my change.  The 
> same 4 failed after my change.
> 
> 
> Thanks,
> 
> George Joseph
> 
>

-- 
_
-- 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] 3955: confbridge: Add Duration to ConfbridgeList event

2014-08-29 Thread George Joseph 

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

(Updated Aug. 29, 2014, 4:27 p.m.)


Review request for Asterisk Developers and rmudgett.


Changes
---

Updated name from Duration to AnsweredTime.


Repository: Asterisk


Description
---

The ConfbridgeList event doesn't include how long the user has been a member of 
the conference.  This patch adds Duration (seconds) which is based on 
user->chan->answertime.


Diffs (updated)
-

  branches/12/apps/app_confbridge.c 422257 

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


Testing
---

Looked at the output of a ConfbridgeList event to make sure Duration was being 
set correctly and no other fields were affected.


Thanks,

George Joseph

-- 
_
-- 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] 3955: confbridge: Add Duration to ConfbridgeList event

2014-08-29 Thread rmudgett 

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



branches/12/apps/app_confbridge.c


This header name is misleading.  How about AnswerTime instead.


- rmudgett


On Aug. 28, 2014, 1:06 p.m., George Joseph wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/3955/
> ---
> 
> (Updated Aug. 28, 2014, 1:06 p.m.)
> 
> 
> Review request for Asterisk Developers and rmudgett.
> 
> 
> Repository: Asterisk
> 
> 
> Description
> ---
> 
> The ConfbridgeList event doesn't include how long the user has been a member 
> of the conference.  This patch adds Duration (seconds) which is based on 
> user->chan->answertime.
> 
> 
> Diffs
> -
> 
>   branches/12/apps/app_confbridge.c 422257 
> 
> Diff: https://reviewboard.asterisk.org/r/3955/diff/
> 
> 
> Testing
> ---
> 
> Looked at the output of a ConfbridgeList event to make sure Duration was 
> being set correctly and no other fields were affected.
> 
> 
> Thanks,
> 
> George Joseph
> 
>

-- 
_
-- 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] 3929: ARI: Holding bridge issues with bridge Music on Hold, playback operations, and default channel roles

2014-08-29 Thread rmudgett 

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



/branches/12/res/ari/resource_bridges.c


Did you mean to remove this when you reverted adding the announcer role?



/branches/12/res/stasis/stasis_bridge.c


Since ARI can set a channel's role as holding_participant but currently 
cannot set options on a role, the holding technology will play MOH as a 
default.  You probably want to check that the idle_mode option is set as well.



/branches/12/res/stasis/stasis_bridge.c


Optional nit: Extra blank line :)



/branches/12/res/stasis/stasis_bridge.c


Would silence be a better thing to send than nothing while a channel is in 
a holding bridge without an announcer?

Optionally it could be "none" or "silence" depending on the 
asterisk.conf:transmit_silence option.


- rmudgett


On Aug. 29, 2014, 3:15 p.m., Matt Jordan wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/3929/
> ---
> 
> (Updated Aug. 29, 2014, 3:15 p.m.)
> 
> 
> Review request for Asterisk Developers.
> 
> 
> Bugs: ASTERISK-24264
> https://issues.asterisk.org/jira/browse/ASTERISK-24264
> 
> 
> Repository: Asterisk
> 
> 
> Description
> ---
> 
> When ARI manipulates a bridge, it generally doesn't care what the mixing 
> technology is. Operations should initiate on the bridge regardless of its 
> mixing technology - and while that mixing technology may determine the 
> experience channels within the bridge have, the actual operations themselves 
> should be the same.
> 
> This isn't the case with holding bridges. Currently, the following issues 
> exist:
>  * Music on Hold is played into a bridge using an Announcer channel. There 
> are two issues with it currently:
>(1) The Music on Hold channel is also not marked as being allowed within a 
> Stasis bridge, so it generally never makes it into the bridge (of any type).
>(2) Even if it did, because it does not have a bridge role of "announcer", 
> it joins the holding bridge as a participant. Additionally, the holding 
> bridge starts MoH on the Announcer channel (which is ironic, but not super 
> useful).
>  * Playback channels do not join as an announcer. Playing back announcements 
> using the /play operation would not be heard by participants.
>  * Participants join without a role. As such, MoH is started for the channels 
> automatically; however, subsequent bridge operations that would stop MoH 
> would fail (as there is no Announcer channel playing MoH to the bridge). From 
> the perspective of ARI users, this is counter-intuitive - I would not expect 
> MoH to be started for me. The mixing technology determines how media is 
> shared between participants, not the application experience.
> 
> This patch does the following:
>  * The Stasis bridge class now inspects channels as they are going into a 
> bridge. If the bridge has a holding capability, and the channel has no roles, 
> we give it a participant role and mark the default behaviour to have no 
> entertainment. This allows addChannel operations to continue to set a 
> participant role with an entertainment option if it felt like it (or could do 
> it).
>  * The playback channel now gets a role of announcer, as does the music on 
> hold channel. For mixing technologies this is a NoOp; for holding bridges it 
> means the channels should have the expected behaviour.
>  * The music on hold channel is now Stasis approved (tm)
>  * Finally, a small bug in 'core show channel' was observed, in that we 
> attempted to calculate CDR variables for internal channels. That generates an 
> annoying warning; internal channels now no longer attempt to access CDR data.
> 
> 
> Diffs
> -
> 
>   /branches/12/res/stasis/stasis_bridge.c 422380 
>   /branches/12/res/res_stasis.c 422380 
>   /branches/12/res/ari/resource_bridges.c 422380 
>   /branches/12/main/cli.c 422380 
> 
> Diff: https://reviewboard.asterisk.org/r/3929/diff/
> 
> 
> Testing
> ---
> 
> The bridge-infinite-wait examples on the wiki (that Sam and I are working on) 
> now ... work.
> 
> 
> 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] 3929: ARI: Holding bridge issues with bridge Music on Hold, playback operations, and default channel roles

2014-08-29 Thread Matt Jordan 

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

(Updated Aug. 29, 2014, 3:15 p.m.)


Review request for Asterisk Developers.


Changes
---

Addressed Richard's findings


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


Repository: Asterisk


Description
---

When ARI manipulates a bridge, it generally doesn't care what the mixing 
technology is. Operations should initiate on the bridge regardless of its 
mixing technology - and while that mixing technology may determine the 
experience channels within the bridge have, the actual operations themselves 
should be the same.

This isn't the case with holding bridges. Currently, the following issues exist:
 * Music on Hold is played into a bridge using an Announcer channel. There are 
two issues with it currently:
   (1) The Music on Hold channel is also not marked as being allowed within a 
Stasis bridge, so it generally never makes it into the bridge (of any type).
   (2) Even if it did, because it does not have a bridge role of "announcer", 
it joins the holding bridge as a participant. Additionally, the holding bridge 
starts MoH on the Announcer channel (which is ironic, but not super useful).
 * Playback channels do not join as an announcer. Playing back announcements 
using the /play operation would not be heard by participants.
 * Participants join without a role. As such, MoH is started for the channels 
automatically; however, subsequent bridge operations that would stop MoH would 
fail (as there is no Announcer channel playing MoH to the bridge). From the 
perspective of ARI users, this is counter-intuitive - I would not expect MoH to 
be started for me. The mixing technology determines how media is shared between 
participants, not the application experience.

This patch does the following:
 * The Stasis bridge class now inspects channels as they are going into a 
bridge. If the bridge has a holding capability, and the channel has no roles, 
we give it a participant role and mark the default behaviour to have no 
entertainment. This allows addChannel operations to continue to set a 
participant role with an entertainment option if it felt like it (or could do 
it).
 * The playback channel now gets a role of announcer, as does the music on hold 
channel. For mixing technologies this is a NoOp; for holding bridges it means 
the channels should have the expected behaviour.
 * The music on hold channel is now Stasis approved (tm)
 * Finally, a small bug in 'core show channel' was observed, in that we 
attempted to calculate CDR variables for internal channels. That generates an 
annoying warning; internal channels now no longer attempt to access CDR data.


Diffs (updated)
-

  /branches/12/res/stasis/stasis_bridge.c 422380 
  /branches/12/res/res_stasis.c 422380 
  /branches/12/res/ari/resource_bridges.c 422380 
  /branches/12/main/cli.c 422380 

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


Testing
---

The bridge-infinite-wait examples on the wiki (that Sam and I are working on) 
now ... work.


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] 3929: ARI: Holding bridge issues with bridge Music on Hold, playback operations, and default channel roles

2014-08-29 Thread Matt Jordan 


> On Aug. 25, 2014, 2:43 p.m., rmudgett wrote:
> > /branches/12/res/ari/resource_bridges.c, lines 425-431
> > 
> >
> > Remove.  This is redundant and too late anyway.  The announcer role is 
> > already added to the ;2 channel as part of the setup by the Announcer 
> > channel technology in chan_bridge_media.c.

Nuts, I misread what happens in my CLI output:

-- Started music on hold, class 'default', on channel 
'Announcer/ARI_MOH-0001;1'
-- Channel Announcer/ARI_MOH-0001;2 joined 'holding_bridge' 
stasis-bridge <1ee2638f-f22a-4599-9bce-31b0447d94a2>

Since the MoH start happens with the joined participant channel just prior to 
that, I glanced at that and thought MoH was getting started on the Announcer 
channel as a function of them joining the holding bridge (and not the fact that 
they're a MoH channel). Doh!


> On Aug. 25, 2014, 2:43 p.m., rmudgett wrote:
> > /branches/12/res/stasis/stasis_bridge.c, lines 208-210
> > 
> >
> > Why is this being done?  For MOH or playback channels they are 
> > immovable and can only be hungup when they leave the bridge.
> > 
> > If anything, this should be done when the channel is moved out of 
> > stasis to a non-stasis controlled bridge as part of the move hook.

This isn't being done for MOH or playback channels, but rather for channels 
that join a bridge with a role specified in the POST call:

POST /bridges/1234/addChannel?channel=foo&role=announcer

Say 1234 is a holding bridge. foo joins as an announcer - yay.

Now, however, if we leave the bridge, we don't actually clear the roles. So if 
I do this:

POST /bridges/1234/removeChannel?channel=foo
POST /bridges/5678/addChannel?channel=foo

Channel foo will join 5678 as an announcer, as the bridge_channel for the 
channel never had its roles removed when the channel was removed from the 
bridge.

This concept doesn't feel like it applies to moving between Stasis and 
non-Stasis bridges, as it is a problem contained solely within the realm of 
Stasis bridges.


- Matt


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


On Aug. 22, 2014, 11:13 p.m., Matt Jordan wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/3929/
> ---
> 
> (Updated Aug. 22, 2014, 11:13 p.m.)
> 
> 
> Review request for Asterisk Developers.
> 
> 
> Bugs: ASTERISK-24264
> https://issues.asterisk.org/jira/browse/ASTERISK-24264
> 
> 
> Repository: Asterisk
> 
> 
> Description
> ---
> 
> When ARI manipulates a bridge, it generally doesn't care what the mixing 
> technology is. Operations should initiate on the bridge regardless of its 
> mixing technology - and while that mixing technology may determine the 
> experience channels within the bridge have, the actual operations themselves 
> should be the same.
> 
> This isn't the case with holding bridges. Currently, the following issues 
> exist:
>  * Music on Hold is played into a bridge using an Announcer channel. There 
> are two issues with it currently:
>(1) The Music on Hold channel is also not marked as being allowed within a 
> Stasis bridge, so it generally never makes it into the bridge (of any type).
>(2) Even if it did, because it does not have a bridge role of "announcer", 
> it joins the holding bridge as a participant. Additionally, the holding 
> bridge starts MoH on the Announcer channel (which is ironic, but not super 
> useful).
>  * Playback channels do not join as an announcer. Playing back announcements 
> using the /play operation would not be heard by participants.
>  * Participants join without a role. As such, MoH is started for the channels 
> automatically; however, subsequent bridge operations that would stop MoH 
> would fail (as there is no Announcer channel playing MoH to the bridge). From 
> the perspective of ARI users, this is counter-intuitive - I would not expect 
> MoH to be started for me. The mixing technology determines how media is 
> shared between participants, not the application experience.
> 
> This patch does the following:
>  * The Stasis bridge class now inspects channels as they are going into a 
> bridge. If the bridge has a holding capability, and the channel has no roles, 
> we give it a participant role and mark the default behaviour to have no 
> entertainment. This allows addChannel operations to continue to set a 
> participant role with an entertainment option if it felt like it (or could do 
> it).
>  * The playback channel now gets a role of announcer, as does the music on 
> hold chan

Re: [asterisk-dev] [Code Review] 3948: Asterisk does not respect outbound proxy when sending qualify requests

2014-08-29 Thread Matt Jordan 

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


I think it is kind of hard to review this patch knowing there are potential 
issues. I'd say that it'd be worthwhile to investigate Walter's potential 
memory leak before continuing the peer review of this patch.

Beyond that, however, outboundproxy is a mine field. No one has really come to 
an agreement on what the defined behaviour should be when an outboundproxy is 
set on a peer - and while dealing with outboundproxy and OPTIONS 
requests/qualify is slightly less fraught than, say, registration or other 
scenarios, it bothers me that we're fixing bugs in something that doesn't have 
a definition of how it is supposed to work.

For reference:

Josh fixing outboundproxy (and breaking other things): 
https://reviewboard.asterisk.org/r/2851/
Josh asking for clarification on behaviour on the asterisk-dev list (and not 
getting much discussion): 
http://lists.digium.com/pipermail/asterisk-dev/2013-October/063312.html

I'd really like to get some consensus on how users of outboundproxy expect it 
to behave in the scenarios uncovered by 
ttps://reviewboard.asterisk.org/r/2851/. Otherwise, it feels like we're chasing 
a moving target here, and that's not fun for anyone. 

- Matt Jordan


On Aug. 25, 2014, 5:04 p.m., Damian Ivereigh wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/3948/
> ---
> 
> (Updated Aug. 25, 2014, 5:04 p.m.)
> 
> 
> Review request for Asterisk Developers.
> 
> 
> Bugs: ASTERISK-24063
> https://issues.asterisk.org/jira/browse/ASTERISK-24063
> 
> 
> Repository: Asterisk
> 
> 
> Description
> ---
> 
> The outboundproxy setting is ignored when sending the qualify packets 
> (OPTIONS). This means that if an asterisk server is unable to send the packet 
> directly to a peer, it is unable to qualify any non inbound registered peer 
> (e.g. a peer SIP Trunk). This problem is found on asterisk-11.6-cert4 (and 
> many others)
> 
> It has been pointed out (thanks Walter Doekes), that the p->outboundproxy may 
> not be freed at the end which would create a memory leak.   
> 
> 
> Diffs
> -
> 
>   certified/tags/11.6-cert4/channels/chan_sip.c 422052 
> 
> Diff: https://reviewboard.asterisk.org/r/3948/diff/
> 
> 
> Testing
> ---
> 
> Have run this change in production for many months, however the possible 
> memory leak issue needs to be verified.
> 
> 
> Thanks,
> 
> Damian Ivereigh
> 
>

-- 
_
-- 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] 3895: Add a manpage for the smsq application

2014-08-29 Thread Jeremy Lainé 

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

(Updated Aug. 29, 2014, 2:38 p.m.)


Status
--

This change has been marked as submitted.


Review request for Asterisk Developers.


Changes
---

Committed in revision 422376


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


Repository: Asterisk


Description
---

This patch adds a manpage for the smsq application. The options were 
automatically extracted using help2man.


Diffs
-

  /trunk/doc/smsq.8 PRE-CREATION 

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


Testing
---


Thanks,

Jeremy Lainé

-- 
_
-- 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] 3896: Add a manpage for the aelparse utility

2014-08-29 Thread Jeremy Lainé 

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

(Updated Aug. 29, 2014, 2:31 p.m.)


Status
--

This change has been marked as submitted.


Review request for Asterisk Developers.


Changes
---

Committed in revision 422371


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


Repository: Asterisk


Description
---

This patch adds a manpage for the aelparse utility.


Diffs
-

  /trunk/doc/aelparse.8 PRE-CREATION 

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


Testing
---


Thanks,

Jeremy Lainé

-- 
_
-- 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-29 Thread Christopher Wolfe 

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

(Updated Aug. 29, 2014, 2:25 p.m.)


Status
--

This change has been discarded.


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] 3858: Tests for verifying StopMixMonitor/MuteMixMonitor AMI action

2014-08-29 Thread Tyler Austin Cambron 

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

(Updated Aug. 29, 2014, 2:24 p.m.)


Status
--

This change has been discarded.


Review request for Asterisk Developers.


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


Repository: testsuite


Description
---

This is a directory of two tests that verify the StopMixMonitor and 
MuteMixMonitor actions.

The StopMixMonitor Test creates a Local channel that starts a playback of 
tt-monkeys. When the playback begins, MixMonitor is triggered to begin 
recording through a headermatch. The same headermatch is used to trigger the 
StopMixMonitor, but the action is delayed for 4 seconds before sending the stop 
message to ensure that the file actually began recording to begin with and 
therefore StopMixMonitor actually had something to stop. When the playback is 
finished and the channel playing the audio hangs up, the hangup event is used 
to trigger the SoundChecker pluggable module to check and ensure the file has 
the correct size and energy.

The MuteMixMonitor Test also creates a Local channel that starts a playback of 
tt-monkyes. When the event for answering of the channel to play tt-monkeys 
occurs, a headermatch triggers both a message for MixMonitor and MuteMixMonitor 
to occur. This will mute the audio stream but continue the recording. When the 
Local channel is hung up, then a headermatch will trigger the SoundChecker 
pluggable module to check the file and ensure that the file has the correct 
size but does not have energy. This will show that the mute feature worked 
properly.

The SoundChecker module is included in the diff file because it has not been 
committed yet and I want to clarify how the pluggable module interacts with the 
test.


Diffs
-

  /asterisk/trunk/tests/apps/mixmonitor_interrupt/tests.yaml PRE-CREATION 
  
/asterisk/trunk/tests/apps/mixmonitor_interrupt/mixmonitor_stop/test-config.yaml
 PRE-CREATION 
  /asterisk/trunk/tests/apps/mixmonitor_interrupt/mixmonitor_stop/stop_mix.py 
PRE-CREATION 
  
/asterisk/trunk/tests/apps/mixmonitor_interrupt/mixmonitor_stop/configs/ast1/extensions.conf
 PRE-CREATION 
  
/asterisk/trunk/tests/apps/mixmonitor_interrupt/mixmonitor_mute/test-config.yaml
 PRE-CREATION 
  /asterisk/trunk/tests/apps/mixmonitor_interrupt/mixmonitor_mute/mix_mute.py 
PRE-CREATION 
  
/asterisk/trunk/tests/apps/mixmonitor_interrupt/mixmonitor_mute/configs/ast1/extensions.conf
 PRE-CREATION 
  /asterisk/trunk/lib/python/asterisk/pluggable_modules.py 5315 

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


Testing
---

Both tests show the correct AMI messages being sent and the actions 
registering. I also manually went to check where the sound files would be and 
each file contained the correct amount of sound and energy as specified in the 
Test.

There may be a better way to shorten the recording for the MuteMixMonitor test 
rather than use StopMixMonitor, but I needed the test to complete before 30 
seconds so that I would not get a reactor timeout. The recording is still 10 
seconds long, which I figured would be ample time to ensure that MuteMixMonitor 
had properly muted the recording. The test finishes in 28 seconds.


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] 3953: chan_sip: change assert to return for mwi_event_cb

2014-08-29 Thread Scott Griepentrog 

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

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


Status
--

This change has been marked as submitted.


Review request for Asterisk Developers.


Changes
---

Committed in revision 422358


Repository: Asterisk


Description
---

The assertion that peer was not found on final event
message was being triggered on configuration reload.

This patch changes that to just return.

Note: this patch was missed in merge from media formats to trunk: 
http://origsvn.digium.com/svn-view/asterisk/team/group/media_formats-reviewed-trunk/channels/chan_sip.c?r1=418779&r2=418785


Diffs
-

  /trunk/channels/chan_sip.c 422196 

Diff: https://reviewboard.asterisk.org/r/3953/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

[asterisk-dev] Thoughts on the future of phoneprov.

2014-08-29 Thread George Joseph 
The last hurdle for me to adopt pjsip has been what to do with phoneprov
and now that chan_sip has been moved to extended support, this has come to
the front burner.   I've been thinking of ways to make the existing
res_phoneprov configurable to use either the existing users.conf/sip.conf
infrastructure or pjsip.  Maybe create a new res_pjsip_provisioning module
that provides a new pjsip provisioning object which would be associated to
an endpoint.   It would contain mac address, profile, line keys, etc.  Then
res_phoneprov could be modified to use alternate config back-ends leaving
the existing users.conf/sip.conf mechanism as the default (for now).
Actually, with this approach, you could use multiple config back-ends at
the same time.

Thoughts?  Other ideas?
-- 
_
-- 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] PJSIP insecure fonctionality

2014-08-29 Thread Joshua Colp 

Yuriy Gorlichenko wrote:

Hello. I use PJSIP as channel for my clients and CHAN_SIP as channel for
my proiders.
I user chan_sip because I can not find any analog of insecure option at
PJSIP. Does IT have this analog of this function.


Kia ora,

Yes, but it is not grouped with endpoints. It is a separate 
configuration item that allows you to match IP addresses (or ranges) to 
an endpoint. When traffic comes in it is then associated.


You can see an example of configuration for connecting to a VoIP 
provider here[1] and the specific part which does the IP address 
matching is the "type=identify" section.


In the future for this type of help the asterisk-users mailing list 
would be more appropriate.


[1] https://wiki.asterisk.org/wiki/display/AST/Configuring+res_pjsip

Cheers,

--
Joshua Colp
Digium, Inc. | Senior Software Developer
445 Jan Davis Drive NW - Huntsville, AL 35806 - US
Check us out at: www.digium.com & www.asterisk.org

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

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

Re: [asterisk-dev] [svn-commits] mjordan: branch 11 r422294 - in /branches/11: ./ LICENSE

2014-08-29 Thread Olle E. Johansson 

On 28 Aug 2014, at 23:53, SVN commits to the Digium repositories 
 wrote:

> This patch updates the LICENSE text to allow users to link Asterisk with
> UniMRCP and distribute the resulting binaries.

Thank you! Good decision.

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

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

[asterisk-dev] PJSIP insecure fonctionality

2014-08-29 Thread Yuriy Gorlichenko 
Hello. I use PJSIP as channel for my clients and CHAN_SIP as channel for my
proiders.
I user chan_sip because I can not find any analog of insecure option at
PJSIP. Does IT have this analog of this function. This is critical question
because CNAH_SIP have a memory leak that crushes my system:
https://issues.asterisk.org/jira/browse/ASTERISK-24152

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