Re: [asterisk-dev] [Code Review] 4578: res_pjsip_phoneprov_provider: Fix leaked OBJ_MULTIPLE iterator.

[Corey Farrell]

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

(Updated April 5, 2015, 7:54 a.m.)


Status
--

This change has been marked as submitted.


Review request for Asterisk Developers.


Changes
---

Committed in revision 433996


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


Repository: Asterisk


Description
---

res_pjsip_phoneprov_provider was using ao2_callback with OBJ_MULTIPLE, then 
ignoring the return.  This resulted in a reference leak.  Added OBJ_NODATA flag.


Diffs
-

  /branches/13/res/res_pjsip_phoneprov_provider.c 433966 

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


Testing
---

Started and stopped Asterisk, REF_DEBUG now showing no leaks.


Thanks,

Corey Farrell

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

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

Re: [asterisk-dev] [Code Review] 4573: trunk: Can't touch this

[Matt Jordan]

> On April 2, 2015, 1:49 a.m., Olle E Johansson wrote:
> > So typical US-centric. The rest of the world has moved to Unicode-art. 
> > ◼️🔲⚫️🔲◼️
> > 
> > 🔁 Please add this to the agenda of the Asterisk-internationalization 
> > meeting in Stockholm next month. We also need to discuss the babel-fish 
> > module.

A! Unicode :-(


- Matt


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


On April 1, 2015, 2:59 p.m., Matt Jordan wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/4573/
> ---
> 
> (Updated April 1, 2015, 2:59 p.m.)
> 
> 
> Review request for Asterisk Developers.
> 
> 
> Repository: Asterisk
> 
> 
> Description
> ---
> 
> This adds a much needed feature: glorious ASCII art of MC Hammer doing his 
> thing in full 1990's apparel.
> 
> As a bonus, this will start a 'hammer time' on the channels in Asterisk.
> 
> 
> Diffs
> -
> 
>   /trunk/res/res_clihammertime.c PRE-CREATION 
> 
> Diff: https://reviewboard.asterisk.org/r/4573/diff/
> 
> 
> Testing
> ---
> 
> https://www.youtube.com/watch?v=otCpCn0l4Wo
> 
> 
> 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] 4573: trunk: Can't touch this

[Matt Jordan]

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

(Updated April 5, 2015, 8:29 p.m.)


Status
--

This change has been discarded.


Review request for Asterisk Developers.


Repository: Asterisk


Description
---

This adds a much needed feature: glorious ASCII art of MC Hammer doing his 
thing in full 1990's apparel.

As a bonus, this will start a 'hammer time' on the channels in Asterisk.


Diffs
-

  /trunk/res/res_clihammertime.c PRE-CREATION 

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


Testing
---

https://www.youtube.com/watch?v=otCpCn0l4Wo


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] 4490: astdb: Allow clustering of the Asterisk Database between multiple Asterisk servers

[Matt Jordan]

> On April 2, 2015, 2:41 p.m., Mark Michelson wrote:
> > /trunk/main/db.c, lines 958-977
> > 
> >
> > The dialplan function allows an omitted type to automatically be 
> > interpreted as "global" but the CLI command requires that the type is 
> > present.
> > 
> > I'm not a fan of the inconsistency. My preference would be that the 
> > dialplan function is changed to require an explicit type.

Works for me.


> On April 2, 2015, 2:41 p.m., Mark Michelson wrote:
> > /trunk/main/db.c, lines 419-441
> > 
> >
> > There is potential for deadlock due to lock inversion.
> > 
> > When ast_db_put_shared() is called, it locks the shared_families 
> > container and then calls into db_put_common(), which locks the dblock.
> > 
> > When ast_db_put() is called, it first calls into db_put_common(), which 
> > locks the dblock. Since ast_db_put() sets the "shared" parameter to 1 when 
> > calling db_put_common(), db_put_common() will call into 
> > db_entry_put_shared(), which will then try to lock the shared_families lock.
> > 
> > Probably the easiest way to go here would be to unlock shared_families 
> > before calling db_put_common(), establishing a locking order of dblock and 
> > then shared_families.

Thanks for catching this! I think that locking order would be fine - and 
there's no real danger in unlocking the shared_families container after you've 
put the family in the container but before updating the key. Even if something 
else sneaks in and removes the shared family, we've already committed to 
changing the value.


> On April 2, 2015, 2:41 p.m., Mark Michelson wrote:
> > /trunk/main/db.c, lines 1674-1677
> > 
> >
> > family can't be NULL here since whatever strchr returns has 1 added to 
> > it.

This really should be:

family = strchr(cur->key + 1, '/');
if (!family) {
continue;
}
family++;


> On April 2, 2015, 2:41 p.m., Mark Michelson wrote:
> > /trunk/tests/test_db.c, lines 62-63
> > 
> >
> > Any reason you went with a manually-resized array instead of an 
> > AST_VECTOR?

The code to synchronize and handle Stasis messages already had a template for 
it in another set of unit tests, so this was just adapted from that.


> On April 2, 2015, 2:41 p.m., Mark Michelson wrote:
> > /trunk/tests/test_db.c, lines 427-446
> > 
> >
> > If any of these calls to ast_test_validate() fails the 
> > GLOBAL_SHARED_FAMILY and UNIQUE_SHARED_FAMILY will not be cleaned up.
> > 
> > Actually, this pattern is common throughout the test code and should be 
> > addressed.

RAII_VAR to the rescue.


- Matt


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


On March 29, 2015, 8:46 p.m., Matt Jordan wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/4490/
> ---
> 
> (Updated March 29, 2015, 8:46 p.m.)
> 
> 
> Review request for Asterisk Developers.
> 
> 
> Bugs: ASTERISK-24909
> https://issues.asterisk.org/jira/browse/ASTERISK-24909
> 
> 
> Repository: Asterisk
> 
> 
> Description
> ---
> 
> As described on the asterisk-dev mailing list [1], I got some inspiration 
> from seeing Kamailio's htable implementation, and thought a similar mechanism 
> would work for the Asterisk Database. This patch is the result.
> 
> This patch provides a mechanism to mark families within the AstDB as 
> "shared." The marking of a family as shared is independent of the existance 
> of the family, and is independent of the updates already made to the family. 
> Shared families are subject to distribution with other Asterisk instances, as 
> well as subject to updates from other Asterisk instances. Two strategies for 
> sharing are implemented:
> 
> * Global: A 'global' shared family shares the family/key space with all other 
> Asterisk instances. Say we have shared family 'foo', and we have two Asterisk 
> instances. Say the first Asterisk instance (ast1) updates a key in family 
> 'foo' to the following:
> 
>   ast1
> /foo/key = bar
> 
> The second Asterisk instance (ast2) would then receive an update in its AstDB:
> 
>   ast2
> /foo/key = bar
> 
> If ast2 later updates the same key in its local AstDB to 'foobar', ast1 will 
> receive a notification to update the same key in its AstDB:
> 
>   ast2
> /foo/key = foobar
>   ast1
> 

[asterisk-dev] Change in testsuite[master]: channels/pjsip/publish/asterisk_event_db: Add AstDB clusteri...

[Matt Jordan (Code Review)]

Matt Jordan has uploaded a new patch set (#2).

Change subject: channels/pjsip/publish/asterisk_event_db: Add AstDB clustering 
tests
..

channels/pjsip/publish/asterisk_event_db: Add AstDB clustering tests

This test verifies that Asterisk can share AstDB information with other
Asterisk instances using the PJSIP stack. The test does the following:

Two Asterisk instances are started. Both are configured to PUBLISH to
each other as well as handle inbound PUBLISH requests from each other
for event type "asterisk-db". Both instances of Asterisk create two global
shared families, "global_shared" and "filtered_shared", as well as a single
unique shared family, "unique_shared". Values are set for keys in each family.
Each Asterisk instance then verifies that:
  - The "filtered_shared" family is not updated, due to being filtered out by
a regex in the PJSIP configuration
  - The "global_shared" family has keys from both instances
  - Each Asterisk instance has the "unique_shared" key/value from the other
Asterisk instance stored in a family corresponding to that instance's EID.

Additionally, this patch allows for the asterisk.conf settings to be
manipulated on an individual Asterisk instance basis. Prior to this, the
same settings were passed to all Asterisk instances. As a result, the
rest_api/danger/dangerous test was updated with the new YAML schema.

ASTERISK-24909

Change-Id: Ibb2928065eb015363d0b3c081f9b324639fc6357
---
M lib/python/asterisk/test_case.py
A tests/channels/pjsip/publish/asterisk_event_db/configs/ast1/pjsip.conf
A tests/channels/pjsip/publish/asterisk_event_db/configs/ast2/extensions.conf
A tests/channels/pjsip/publish/asterisk_event_db/configs/ast2/pjsip.conf
A tests/channels/pjsip/publish/asterisk_event_db/run-test
A tests/channels/pjsip/publish/asterisk_event_db/test-config.yaml
M tests/channels/pjsip/publish/tests.yaml
M tests/rest_api/danger/dangerous/test-config.yaml
8 files changed, 265 insertions(+), 3 deletions(-)


  git pull ssh://gerrit.asterisk.org:29418/testsuite refs/changes/09/9/2
-- 
To view, visit https://gerrit.asterisk.org/9
To unsubscribe, visit https://gerrit.asterisk.org/settings

Gerrit-MessageType: newpatchset
Gerrit-Change-Id: Ibb2928065eb015363d0b3c081f9b324639fc6357
Gerrit-PatchSet: 2
Gerrit-Project: testsuite
Gerrit-Branch: master
Gerrit-Owner: Matt Jordan 
Gerrit-Reviewer: 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] 4490: astdb: Allow clustering of the Asterisk Database between multiple Asterisk servers

[Matt Jordan]

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

(Updated April 5, 2015, 9:22 p.m.)


Review request for Asterisk Developers.


Changes
---

Resolved Mark's findings.


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


Repository: Asterisk


Description
---

As described on the asterisk-dev mailing list [1], I got some inspiration from 
seeing Kamailio's htable implementation, and thought a similar mechanism would 
work for the Asterisk Database. This patch is the result.

This patch provides a mechanism to mark families within the AstDB as "shared." 
The marking of a family as shared is independent of the existance of the 
family, and is independent of the updates already made to the family. Shared 
families are subject to distribution with other Asterisk instances, as well as 
subject to updates from other Asterisk instances. Two strategies for sharing 
are implemented:

* Global: A 'global' shared family shares the family/key space with all other 
Asterisk instances. Say we have shared family 'foo', and we have two Asterisk 
instances. Say the first Asterisk instance (ast1) updates a key in family 'foo' 
to the following:

  ast1
/foo/key = bar

The second Asterisk instance (ast2) would then receive an update in its AstDB:

  ast2
/foo/key = bar

If ast2 later updates the same key in its local AstDB to 'foobar', ast1 will 
receive a notification to update the same key in its AstDB:

  ast2
/foo/key = foobar
  ast1
/foo/key = foobar

* Unique: A 'unique' shared family shares its values with other Asterisk 
instances, however, updates from other Asterisk instances are placed in unique 
families in the local AstDB for each Asterisk instance. Again, say we have 
shared family 'foo', and we have two Asterisk instances - ast1 and ast2. ast1 
has an EID of 11:11:11:11:11:11, while ast2 has an EID of ff:ff:ff:ff:ff:ff. 
Say ast1 updates a key in family 'foo':

  ast1
/foo/key = bar

ast2 would receive the update for family 'foo', but instead of updating its 
local copy, it would instead store the value in a new family for ast1 
corresponding to its EID:

  ast2
/11:11:11:11:11:11/foo/key = bar

If ast2 later updates the same ky in its local AstDB to 'foobar', the received 
value from ast1 will not be updated. However, ast1 will receive the update, and 
store the value in a new family for ast2 corresponding to its EID:

  ast2
/foo/key = foobar
/11:11:11:11:11:11/foo/key = bar
  ast1
/foo/key = bar
/ff:ff:ff:ff:ff:ff/foo/key = foobar

In order to manipulate shared families, two new dialplan functions have been 
added, DB_SHARED and DB_SHARED_EXISTS. DB_SHARED allows for creation of a 
shared family, as well as deletion, while DB_SHARED_EXISTS returns whether or 
not a family is shared:
  same => n,Set(DB_SHARED(put,global)=foo)  ; share family 'foo' globally
  same => n,Set(DB_SHARED(put,unique)=foobar)   ; share family 'foobar' uniquely
  same => n,NoOp(${DB_SHARED_EXISTS(foo)})  ; returns '1'
  same => n,Set(DB_SHARED(delete)=foo)  ; remove shared family status 
for 'foo'

CLI commands were also added to create/delete shared families, and the output 
of 'database show|showkey' updated to show the shared status of a 
family/key/value tuple.

Finally, a mechanism for sharing AstDB information was added to the PJSIP 
stack's res_pjsip_publish_asterisk. This includes a new event type, 
'asterisk-db', which contains the values being created/deleted. Necessary 
configuration parameters were added to the existing configuration objects that 
support inbound/outbound PUBLISH support. An example of a PUBLISH request with 
the new event type is shown below:

PUBLISH sip:ast1@127.0.0.1:5061 SIP/2.0
Via: SIP/2.0/UDP 
127.0.0.1:5060;rport;branch=z9hG4bKPj1eb182a7-a0aa-4d73-995d-d2ad4b096db2
From: ;tag=7b294642-06ae-4ecf-8637-db8ba2dc4397
To: 
Call-ID: b9463adc-e364-440d-8ce1-842372813b08
CSeq: 48111 PUBLISH
Event: asterisk-db
Expires: 3600
Max-Forwards: 70
User-Agent: Asterisk PBX SVN-mjordan-trunk-astdb-cluster-URL:-r432916M-/trunk
Content-Type: application/json
Content-Length:   156

{"type":"dbstate","eid":"11:11:11:11:11:11","dbstate":{"verb":"put","family":"global_shared","share_type":"global","entries":[{"data":"foo","key":"key1"}]}}


As a note on the power of the frameworks in Asterisk 13 - in this case, both 
Stasis and PJSIP - the vast bulk of this was written on two plane flights, plus 
a weekend or so of test writing and cleanup.

[1] http://lists.digium.com/pipermail/asterisk-dev/2015-March/073192.html


Diffs (updated)
-

  /trunk/tests/test_db.c 434016 
  /trunk/res/res_pjsip_pubsub.c 434016 
  /trunk/res/res_pjsip_publish_asterisk.c 434016 
  /trunk/res/res_pjsip_outbound_publish.c 434016 
  /trunk/main/utils.c 434016 
  /trunk/main/db.c 4

Re: [asterisk-dev] [Code Review] 4549: ARI: Add the ability to intercept hold and raise an event

[Matt Jordan]

> On March 31, 2015, 8:21 a.m., Joshua Colp wrote:
> > /branches/13/res/stasis/control.c, lines 609-622
> > 
> >
> > This is substantially changing the behavior.
> > 
> > ast_indicate will tell the channel to go on hold or off hold.
> > ast_queue_hold/ast_queue_unhold will queue a frame as if the channel 
> > has said it is on hold or off hold.

This really shouldn't have been done. I was hoping to make use of ARI to test 
'standard' hold in addition to the hold interception here; as it is, that's 
actually much harder, since we don't get an ARI event when using POST 
/channels/hold.

It's also ancillary to this change.

As it is, I'm going to just revert this change, and restructure the tests 
accordingly.


- Matt


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


On March 27, 2015, 10:19 p.m., Matt Jordan wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/4549/
> ---
> 
> (Updated March 27, 2015, 10:19 p.m.)
> 
> 
> Review request for Asterisk Developers and Joshua Colp.
> 
> 
> Bugs: ASTERISK-24922
> https://issues.asterisk.org/jira/browse/ASTERISK-24922
> 
> 
> Repository: Asterisk
> 
> 
> Description
> ---
> 
> For some applications - such as SLA - a phone pressing hold should not behave 
> in the fashion that the Asterisk core would like it to. Instead, the hold 
> action has some application specific behaviour associated with it - such as 
> disconnecting the channel that initiated the hold; only playing MoH to 
> channels in the bridge if the channels are of a particular type, etc.
> 
> One way of accomplishing this is to use a framehook to intercept the 
> hold/unhold frames, raise an event, and eat the frame. Tasty. The patch 
> attached to this issue accomplished that as a new dialplan function, 
> HOLD_INTERCEPT.
> 
> In addition:
> * ARI now queues hold/unhold frames instead of indicating frames directly. 
> This allows for the Stasis hold/unhold messages to be raised.
> * Some general cleanup of raising hold/unhold Stasis messages was done, 
> including removing some RAII_VAR usage.
> 
> 
> Diffs
> -
> 
>   /branches/13/rest-api/api-docs/events.json 433677 
>   /branches/13/res/stasis/control.c 433677 
>   /branches/13/res/stasis/app.c 433677 
>   /branches/13/res/ari/ari_model_validators.c 433677 
>   /branches/13/res/ari/ari_model_validators.h 433677 
>   /branches/13/main/stasis_channels.c 433677 
>   /branches/13/main/manager_channels.c 433677 
>   /branches/13/main/channel.c 433677 
>   /branches/13/main/bridge_channel.c 433677 
>   /branches/13/funcs/func_holdintercept.c PRE-CREATION 
>   /branches/13/CHANGES 433677 
> 
> Diff: https://reviewboard.asterisk.org/r/4549/diff/
> 
> 
> Testing
> ---
> 
> See Gerrit reviews:
> 
> https://gerrit.asterisk.org/#/c/16
> https://gerrit.asterisk.org/#/c/17
> 
> 
> 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] 4549: ARI: Add the ability to intercept hold and raise an event

[Matt Jordan]

> On March 31, 2015, 12:23 p.m., Mark Michelson wrote:
> > One thing to take into consideration here is that there are some places 
> > within Asterisk where we will send an AST_CONTROL_UNHOLD frame on a 
> > channel, even though it may not currently be on hold. This means you may 
> > send some unhold ARI events that don't match up with a previous hold event. 
> > This is probably worth documenting somewhere so that ARI application 
> > writers know what they might have to deal with.
> 
> Matt Jordan wrote:
> In what circumstances do we do that?
> 
> Mark Michelson wrote:
> I was thinking of transfer code in particular. The transfer code does not 
> know whether the channel being transferred is on hold or not, but it will 
> send an unhold frame anyway.

Hm. That might actually be a slight issue in the transfer code. The channel 
structure has a property on it that is ostensibly supposed to track if a 
channel is on hold or not, ast_channel_hold_state. This maps to the hold_state 
property on the channel:

int hold_state; /*!< 
Current Hold/Unhold state */

We should be able to look at that to see if the channel is currently on hold 
before queuing up an unhold frame.

bridge_channel does do this when a channel leaves the bridge:

/* Complete any active hold before exiting the bridge. */
if (ast_channel_hold_state(bridge_channel->chan) == AST_CONTROL_HOLD) {
ast_debug(1, "Channel %s simulating UNHOLD for bridge end.\n",
ast_channel_name(bridge_channel->chan));
ast_indicate(bridge_channel->chan, AST_CONTROL_UNHOLD);
}

While there are places where the bridging framework sends an unhold to the 
channel, they appear to all be matched with a hold frame. Which particular 
place are you thinking of?


- Matt


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


On March 27, 2015, 10:19 p.m., Matt Jordan wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/4549/
> ---
> 
> (Updated March 27, 2015, 10:19 p.m.)
> 
> 
> Review request for Asterisk Developers and Joshua Colp.
> 
> 
> Bugs: ASTERISK-24922
> https://issues.asterisk.org/jira/browse/ASTERISK-24922
> 
> 
> Repository: Asterisk
> 
> 
> Description
> ---
> 
> For some applications - such as SLA - a phone pressing hold should not behave 
> in the fashion that the Asterisk core would like it to. Instead, the hold 
> action has some application specific behaviour associated with it - such as 
> disconnecting the channel that initiated the hold; only playing MoH to 
> channels in the bridge if the channels are of a particular type, etc.
> 
> One way of accomplishing this is to use a framehook to intercept the 
> hold/unhold frames, raise an event, and eat the frame. Tasty. The patch 
> attached to this issue accomplished that as a new dialplan function, 
> HOLD_INTERCEPT.
> 
> In addition:
> * ARI now queues hold/unhold frames instead of indicating frames directly. 
> This allows for the Stasis hold/unhold messages to be raised.
> * Some general cleanup of raising hold/unhold Stasis messages was done, 
> including removing some RAII_VAR usage.
> 
> 
> Diffs
> -
> 
>   /branches/13/rest-api/api-docs/events.json 433677 
>   /branches/13/res/stasis/control.c 433677 
>   /branches/13/res/stasis/app.c 433677 
>   /branches/13/res/ari/ari_model_validators.c 433677 
>   /branches/13/res/ari/ari_model_validators.h 433677 
>   /branches/13/main/stasis_channels.c 433677 
>   /branches/13/main/manager_channels.c 433677 
>   /branches/13/main/channel.c 433677 
>   /branches/13/main/bridge_channel.c 433677 
>   /branches/13/funcs/func_holdintercept.c PRE-CREATION 
>   /branches/13/CHANGES 433677 
> 
> Diff: https://reviewboard.asterisk.org/r/4549/diff/
> 
> 
> Testing
> ---
> 
> See Gerrit reviews:
> 
> https://gerrit.asterisk.org/#/c/16
> https://gerrit.asterisk.org/#/c/17
> 
> 
> 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] 4549: ARI: Add the ability to intercept hold and raise an event

[Matt Jordan]

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

(Updated April 5, 2015, 9:39 p.m.)


Review request for Asterisk Developers and Joshua Colp.


Changes
---

Addressed Josh's findings.


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


Repository: Asterisk


Description
---

For some applications - such as SLA - a phone pressing hold should not behave 
in the fashion that the Asterisk core would like it to. Instead, the hold 
action has some application specific behaviour associated with it - such as 
disconnecting the channel that initiated the hold; only playing MoH to channels 
in the bridge if the channels are of a particular type, etc.

One way of accomplishing this is to use a framehook to intercept the 
hold/unhold frames, raise an event, and eat the frame. Tasty. The patch 
attached to this issue accomplished that as a new dialplan function, 
HOLD_INTERCEPT.

In addition:
* ARI now queues hold/unhold frames instead of indicating frames directly. This 
allows for the Stasis hold/unhold messages to be raised.
* Some general cleanup of raising hold/unhold Stasis messages was done, 
including removing some RAII_VAR usage.


Diffs (updated)
-

  /branches/13/rest-api/api-docs/events.json 433677 
  /branches/13/res/ari/ari_model_validators.c 433677 
  /branches/13/res/ari/ari_model_validators.h 433677 
  /branches/13/main/stasis_channels.c 433677 
  /branches/13/main/manager_channels.c 433677 
  /branches/13/main/channel.c 433677 
  /branches/13/main/bridge_channel.c 433677 
  /branches/13/funcs/func_holdintercept.c PRE-CREATION 
  /branches/13/CHANGES 433677 

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


Testing
---

See Gerrit reviews:

https://gerrit.asterisk.org/#/c/16
https://gerrit.asterisk.org/#/c/17


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] Change in testsuite[master]: tests/rest_api/channels/hold: Add a default Hold action test

[Matt Jordan (Code Review)]

Matt Jordan has abandoned this change.

Change subject: tests/rest_api/channels/hold: Add a default Hold action test
..


Abandoned

-- 
To view, visit https://gerrit.asterisk.org/17
To unsubscribe, visit https://gerrit.asterisk.org/settings

Gerrit-MessageType: abandon
Gerrit-Change-Id: I9786cb0829e39b33a8dbc130e53fd15a1b5e0d68
Gerrit-PatchSet: 1
Gerrit-Project: testsuite
Gerrit-Branch: master
Gerrit-Owner: Matt Jordan 
Gerrit-Reviewer: Ashley Sanders 

-- 
_
-- 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] Change in testsuite[master]: tests/rest_api/channels: Add a channel hold intercept test

[Matt Jordan (Code Review)]

Matt Jordan has uploaded a new patch set (#3).

Change subject: tests/rest_api/channels: Add a channel hold intercept test
..

tests/rest_api/channels: Add a channel hold intercept test

This test verifies that a channel that initiates a call hold with the
HOLD_INTERCEPT function enabled on it will have the hold frame intercepte
and turned into an event for ARI clients.

A Local channel enters the Stasis application, and the HOLD_INTERCEPT function
is placed on the channel. A POST /hold operation is then used to simulate a
call hold on the channel. The test verifies that a ChannelHold event is raised
with the channel initating the hold. A DELETE /hold operation is then used, and
a ChannelUnhold event is raised with the channel initiating the unhold.

ASTERISK-24922
Reported by: Matt Jordan

Change-Id: If8bdbc74e0789d0c13ffbc5cb0c852f5f3a04012
---
A tests/rest_api/channels/hold/hold_intercept/configs/ast1/extensions.conf
A tests/rest_api/channels/hold/hold_intercept/hold_intercept.py
A tests/rest_api/channels/hold/hold_intercept/test-config.yaml
A tests/rest_api/channels/hold/tests.yaml
M tests/rest_api/channels/tests.yaml
5 files changed, 124 insertions(+), 0 deletions(-)


  git pull ssh://gerrit.asterisk.org:29418/testsuite refs/changes/16/16/3
-- 
To view, visit https://gerrit.asterisk.org/16
To unsubscribe, visit https://gerrit.asterisk.org/settings

Gerrit-MessageType: newpatchset
Gerrit-Change-Id: If8bdbc74e0789d0c13ffbc5cb0c852f5f3a04012
Gerrit-PatchSet: 3
Gerrit-Project: testsuite
Gerrit-Branch: master
Gerrit-Owner: 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] Change in testsuite[master]: tests/rest_api/channels: Add a channel hold intercept test

[Matt Jordan (Code Review)]

Matt Jordan has uploaded a new patch set (#3).

Change subject: tests/rest_api/channels: Add a channel hold intercept test
..

tests/rest_api/channels: Add a channel hold intercept test

This test verifies that a channel that initiates a call hold with the
HOLD_INTERCEPT function enabled on it will have the hold frame intercepte
and turned into an event for ARI clients.

A Local channel enters the Stasis application, and the HOLD_INTERCEPT function
is placed on the channel. A POST /hold operation is then used to simulate a
call hold on the channel. The test verifies that a ChannelHold event is raised
with the channel initating the hold. A DELETE /hold operation is then used, and
a ChannelUnhold event is raised with the channel initiating the unhold.

ASTERISK-24922
Reported by: Matt Jordan

Change-Id: If8bdbc74e0789d0c13ffbc5cb0c852f5f3a04012
---
A tests/rest_api/channels/hold/hold_intercept/configs/ast1/extensions.conf
A tests/rest_api/channels/hold/hold_intercept/hold_intercept.py
A tests/rest_api/channels/hold/hold_intercept/test-config.yaml
A tests/rest_api/channels/hold/tests.yaml
M tests/rest_api/channels/tests.yaml
5 files changed, 124 insertions(+), 0 deletions(-)


  git pull ssh://gerrit.asterisk.org:29418/testsuite refs/changes/16/16/3
-- 
To view, visit https://gerrit.asterisk.org/16
To unsubscribe, visit https://gerrit.asterisk.org/settings

Gerrit-MessageType: newpatchset
Gerrit-Change-Id: If8bdbc74e0789d0c13ffbc5cb0c852f5f3a04012
Gerrit-PatchSet: 3
Gerrit-Project: testsuite
Gerrit-Branch: master
Gerrit-Owner: 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] [BOUNTY] ASTERISK-24795 Park/Pickup CLID Issue

[Derek Bolichowski]

Please review https://issues.asterisk.org/jira/browse/ASTERISK-24795

We're offering a bounty for anyone who is willing to work directly with us to 
resolve this issue.

We have a custom developed asterisk cluster that has an issue where when an 
external call is made, parked, then picked up, the CLID shows sw__sip. 
Everything is written in AEL.

Only looking for serious interest. This may not be an asterisk bug, and may be 
a programming issue.


Derek Bolichowski
Technician / VoIP Specialist
Empire Communications Inc.
T.F.  888-618-8847
P.  519-737-6668
F.  866-394-1864
E.  serv...@empire-team.com

Sent from my iPhone using Office365
-- 
_
-- 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