[asterisk-dev] Numbered placeholders in dialplan's SPRINTF function
Hello,
If I'm not mistaken, numbered placeholders are not supported by
dialplan's SPRINTF function.
Though this is strictly not blocking, having them would allow concise
expressions such as:
Dial(${SPRINTF(${PJSIPFORMAT},mytrunk,123456789)})
with :
Set(PJSIPFORMAT=PJSIP/%2$s@%1$s)
Set(SIPFORMAT=SIP/%2$s@%1$s)
or
Set(DAHDIFORMAT=DAHDI/%1$s/%2$s)
What do you think of this ?
Regards
--
_
-- 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] 2964: res_pjsip_outbound_registration: Add virtual line support for automatic inbound matching
--- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/2964/ --- (Updated Nov. 4, 2014, 6:03 a.m.) Status -- This change has been marked as submitted. Review request for Asterisk Developers. Changes --- Committed in revision 427165 Repository: Asterisk Description --- This patch adds virtual line support to the res_pjsip_outbound_registration module. This is an optional feature and simply adds a line URI parameter to the Contact we place in the outbound registration. If this line parameter is present on incoming requests we use it to establish a relationship to the outbound registration and match it to a user configured endpoint. This has the benefit that when registering to another server where it is supported you no longer have to do IP based matching for all of their potential servers. The downside (and why this is optional) is that if a third party got the line parameter they could send you calls as if they were the legit remote server. Diffs - /trunk/res/res_pjsip_outbound_registration.c 425156 /trunk/configs/samples/pjsip.conf.sample 425156 Diff: https://reviewboard.asterisk.org/r/2964/diff/ Testing --- Registered to an ITSP, placed an inbound call from them, confirmed matched using line parameter. Registered to a chan_sip instance, placed an inbound call from it, confirmed matched using line parameter. Thanks, Joshua Colp -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] [Code Review] 4099: Optimistic SRTP Tests.
On Oct. 29, 2014, 6:26 p.m., opticron wrote: /asterisk/trunk/tests/channels/pjsip/optimistic_srtp/optimistic_with_optimistic_offer/sipp/offer.xml, line 45 https://reviewboard.asterisk.org/r/4099/diff/2/?file=68484#file68484line45 The other three new tests should have this type of check in the 200 response as well. They... do? - Joshua --- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/4099/#review13621 --- On Oct. 21, 2014, 1:49 p.m., Joshua Colp wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/4099/ --- (Updated Oct. 21, 2014, 1:49 p.m.) Review request for Asterisk Developers. Repository: testsuite Description --- This change removes 1 SIPP scenario from the old SRTP negotiation tests which would fail (because optimistic is now supported) and adds 4 new tests to cover the new optimistic support. These test do: 1. Asterisk is configured with mandatory encryption and receives an offer with optimistic, it accepts the offer. 2. Asterisk is configured with optimistic encryption and receives an offer with optimistic, it accepts the offer. 3. Asterisk is configured with optimistic encryption and receives an offer with mandatory, it accepts the offer. 4. Asterisk is configured with optimistic encryption and receives an offer without any crypto, it accepts the offer. The other SRTP negotiation tests cover the mandatory situations and other assorted crypto stuff. Diffs - /asterisk/trunk/tests/channels/pjsip/tests.yaml 5766 /asterisk/trunk/tests/channels/pjsip/srtp_negotiation/test-config.yaml 5766 /asterisk/trunk/tests/channels/pjsip/srtp_negotiation/sipp/decline_not_enabled.xml 5766 /asterisk/trunk/tests/channels/pjsip/optimistic_srtp/tests.yaml PRE-CREATION /asterisk/trunk/tests/channels/pjsip/optimistic_srtp/optimistic_with_optimistic_offer/test-config.yaml PRE-CREATION /asterisk/trunk/tests/channels/pjsip/optimistic_srtp/optimistic_with_optimistic_offer/sipp/offer.xml PRE-CREATION /asterisk/trunk/tests/channels/pjsip/optimistic_srtp/optimistic_with_optimistic_offer/configs/ast1/pjsip.conf PRE-CREATION /asterisk/trunk/tests/channels/pjsip/optimistic_srtp/optimistic_with_optimistic_offer/configs/ast1/extensions.conf PRE-CREATION /asterisk/trunk/tests/channels/pjsip/optimistic_srtp/optimistic_with_no_crypto/test-config.yaml PRE-CREATION /asterisk/trunk/tests/channels/pjsip/optimistic_srtp/optimistic_with_no_crypto/sipp/offer.xml PRE-CREATION /asterisk/trunk/tests/channels/pjsip/optimistic_srtp/optimistic_with_no_crypto/configs/ast1/pjsip.conf PRE-CREATION /asterisk/trunk/tests/channels/pjsip/optimistic_srtp/optimistic_with_no_crypto/configs/ast1/extensions.conf PRE-CREATION /asterisk/trunk/tests/channels/pjsip/optimistic_srtp/optimistic_with_mandatory_offer/test-config.yaml PRE-CREATION /asterisk/trunk/tests/channels/pjsip/optimistic_srtp/optimistic_with_mandatory_offer/sipp/offer.xml PRE-CREATION /asterisk/trunk/tests/channels/pjsip/optimistic_srtp/optimistic_with_mandatory_offer/configs/ast1/pjsip.conf PRE-CREATION /asterisk/trunk/tests/channels/pjsip/optimistic_srtp/optimistic_with_mandatory_offer/configs/ast1/extensions.conf PRE-CREATION /asterisk/trunk/tests/channels/pjsip/optimistic_srtp/mandatory_with_optimistic_offer/test-config.yaml PRE-CREATION /asterisk/trunk/tests/channels/pjsip/optimistic_srtp/mandatory_with_optimistic_offer/sipp/offer.xml PRE-CREATION /asterisk/trunk/tests/channels/pjsip/optimistic_srtp/mandatory_with_optimistic_offer/configs/ast1/pjsip.conf PRE-CREATION /asterisk/trunk/tests/channels/pjsip/optimistic_srtp/mandatory_with_optimistic_offer/configs/ast1/extensions.conf PRE-CREATION Diff: https://reviewboard.asterisk.org/r/4099/diff/ Testing --- Ran tests, confirmed happy. Thanks, Joshua Colp -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] [Code Review] 4099: Optimistic SRTP Tests.
On Oct. 29, 2014, 1:26 p.m., opticron wrote: /asterisk/trunk/tests/channels/pjsip/optimistic_srtp/optimistic_with_optimistic_offer/sipp/offer.xml, line 45 https://reviewboard.asterisk.org/r/4099/diff/2/?file=68484#file68484line45 The other three new tests should have this type of check in the 200 response as well. Joshua Colp wrote: They... do? optimistic_with_no_crypto/sipp/offer.xml is missing a test verifying lack of crypto. - opticron --- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/4099/#review13621 --- On Oct. 21, 2014, 8:49 a.m., Joshua Colp wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/4099/ --- (Updated Oct. 21, 2014, 8:49 a.m.) Review request for Asterisk Developers. Repository: testsuite Description --- This change removes 1 SIPP scenario from the old SRTP negotiation tests which would fail (because optimistic is now supported) and adds 4 new tests to cover the new optimistic support. These test do: 1. Asterisk is configured with mandatory encryption and receives an offer with optimistic, it accepts the offer. 2. Asterisk is configured with optimistic encryption and receives an offer with optimistic, it accepts the offer. 3. Asterisk is configured with optimistic encryption and receives an offer with mandatory, it accepts the offer. 4. Asterisk is configured with optimistic encryption and receives an offer without any crypto, it accepts the offer. The other SRTP negotiation tests cover the mandatory situations and other assorted crypto stuff. Diffs - /asterisk/trunk/tests/channels/pjsip/tests.yaml 5766 /asterisk/trunk/tests/channels/pjsip/srtp_negotiation/test-config.yaml 5766 /asterisk/trunk/tests/channels/pjsip/srtp_negotiation/sipp/decline_not_enabled.xml 5766 /asterisk/trunk/tests/channels/pjsip/optimistic_srtp/tests.yaml PRE-CREATION /asterisk/trunk/tests/channels/pjsip/optimistic_srtp/optimistic_with_optimistic_offer/test-config.yaml PRE-CREATION /asterisk/trunk/tests/channels/pjsip/optimistic_srtp/optimistic_with_optimistic_offer/sipp/offer.xml PRE-CREATION /asterisk/trunk/tests/channels/pjsip/optimistic_srtp/optimistic_with_optimistic_offer/configs/ast1/pjsip.conf PRE-CREATION /asterisk/trunk/tests/channels/pjsip/optimistic_srtp/optimistic_with_optimistic_offer/configs/ast1/extensions.conf PRE-CREATION /asterisk/trunk/tests/channels/pjsip/optimistic_srtp/optimistic_with_no_crypto/test-config.yaml PRE-CREATION /asterisk/trunk/tests/channels/pjsip/optimistic_srtp/optimistic_with_no_crypto/sipp/offer.xml PRE-CREATION /asterisk/trunk/tests/channels/pjsip/optimistic_srtp/optimistic_with_no_crypto/configs/ast1/pjsip.conf PRE-CREATION /asterisk/trunk/tests/channels/pjsip/optimistic_srtp/optimistic_with_no_crypto/configs/ast1/extensions.conf PRE-CREATION /asterisk/trunk/tests/channels/pjsip/optimistic_srtp/optimistic_with_mandatory_offer/test-config.yaml PRE-CREATION /asterisk/trunk/tests/channels/pjsip/optimistic_srtp/optimistic_with_mandatory_offer/sipp/offer.xml PRE-CREATION /asterisk/trunk/tests/channels/pjsip/optimistic_srtp/optimistic_with_mandatory_offer/configs/ast1/pjsip.conf PRE-CREATION /asterisk/trunk/tests/channels/pjsip/optimistic_srtp/optimistic_with_mandatory_offer/configs/ast1/extensions.conf PRE-CREATION /asterisk/trunk/tests/channels/pjsip/optimistic_srtp/mandatory_with_optimistic_offer/test-config.yaml PRE-CREATION /asterisk/trunk/tests/channels/pjsip/optimistic_srtp/mandatory_with_optimistic_offer/sipp/offer.xml PRE-CREATION /asterisk/trunk/tests/channels/pjsip/optimistic_srtp/mandatory_with_optimistic_offer/configs/ast1/pjsip.conf PRE-CREATION /asterisk/trunk/tests/channels/pjsip/optimistic_srtp/mandatory_with_optimistic_offer/configs/ast1/extensions.conf PRE-CREATION Diff: https://reviewboard.asterisk.org/r/4099/diff/ Testing --- Ran tests, confirmed happy. Thanks, Joshua Colp -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
[asterisk-dev] [Code Review] 4147: config: BUG: Restore ability for non-templates to be used as base objects in config.
--- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/4147/ --- Review request for Asterisk Developers and Scott Griepentrog. Bugs: ASTERISK-24487 https://issues.asterisk.org/jira/browse/ASTERISK-24487 Repository: Asterisk Description --- My recent refactor of config.c accidentally removed the capability for a object to inherit from a non-template object. The following was no longer valid and should have been: [mybase] something=else [myobj](mybase) This patch restores the capability to inherit from both template and non-template objects. Diffs - branches/12/main/config.c 427199 Diff: https://reviewboard.asterisk.org/r/4147/diff/ Testing --- Testsuite manager/config tests still pass. main/config unit tests still pass. Eyeball test using AMI/GetConfig passed. 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] 4147: config: BUG: Restore ability for non-templates to be used as base objects in config.
--- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/4147/#review13667 --- Ship it! Ship It! - Scott Griepentrog On Nov. 4, 2014, 11:06 a.m., George Joseph wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/4147/ --- (Updated Nov. 4, 2014, 11:06 a.m.) Review request for Asterisk Developers and Scott Griepentrog. Bugs: ASTERISK-24487 https://issues.asterisk.org/jira/browse/ASTERISK-24487 Repository: Asterisk Description --- My recent refactor of config.c accidentally removed the capability for a object to inherit from a non-template object. The following was no longer valid and should have been: [mybase] something=else [myobj](mybase) This patch restores the capability to inherit from both template and non-template objects. Diffs - branches/12/main/config.c 427199 Diff: https://reviewboard.asterisk.org/r/4147/diff/ Testing --- Testsuite manager/config tests still pass. main/config unit tests still pass. Eyeball test using AMI/GetConfig passed. 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
[asterisk-dev] [Code Review] 4148: res_pjsip_multihomed: Provide logging during startup for an indication of what is going on
--- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/4148/ --- Review request for Asterisk Developers. Bugs: ASTERISK-24438 https://issues.asterisk.org/jira/browse/ASTERISK-24438 Repository: Asterisk Description --- On systems that are having DNS problems res_pjsip_multihomed may hang for awhile as it tries to figure out the local IPv4 and IPv6 address. This change adds logging so you know this is happening and also once done tells you what IP addresses it has used. Diffs - /branches/12/res/res_pjsip_multihomed.c 427199 Diff: https://reviewboard.asterisk.org/r/4148/diff/ Testing --- Ran and confirmed messages output. Thanks, Joshua Colp -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
[asterisk-dev] Asterisk 14 - Remote URI Playback
Hey everyone - One of the action items on the list from AstriDevCon was to flesh out some of the ARI feature proposals that had been made for Asterisk 13. I've just finished putting together a draft of the first one for Remote URI Playback. You can find the proposal page here: https://wiki.asterisk.org/wiki/display/AST/Asterisk+14+Project+-+URI+Media+Playback Ben Langfeld has already given some excellent feedback on the proposed approach; I'd encourage everyone to chime in on the page as there are some interesting edge cases that have to be considered for the feature. If you'd like to participate in the development and/or testing, please let me know either by replying to this e-mail or by commenting on the wiki page. Thanks! Matt -- Matthew Jordan Digium, Inc. | Engineering Manager 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA Check us out at: http://digium.com http://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] Asterisk 14 - Remote URI Playback
Matt - This is a pretty neat idea, indeed, but I've got some questions/thoughts on implementation. :-) Apologies if all of this was already considered/accounted for already.. 1) Does the entire file need to be downloaded and in place on the HTTP Media Cache before you can call an ast_openstream on it? This could cause some problems with larger files not sitting on a fat pipe local to the Asterisk instance. 2) What kind of locking is in place on the design to prevent HTTP Media Cache from trying to update an expired resource that's already in the middle of being streamed to a channel? 3) I think you need to also introduce a PUT method on HTTP Media Cache because I can think of a bunch of scenarios where having a write operation on func_curl may be lacking in the file needing to be retrieved (eg - trying to pull ACL'd media from an S3 volume where you need custom HTTP request headers, etc). We shouldn't try to architect/design for all of these scenarios in Asterisk via a write operation on func_curl and a PUT to HTTP Media Cache seems like a reasonable approach to handle that. Thanks! BJ On 11/4/14, 1:09 PM, Matthew Jordan wrote: Hey everyone - One of the action items on the list from AstriDevCon was to flesh out some of the ARI feature proposals that had been made for Asterisk 13. I've just finished putting together a draft of the first one for Remote URI Playback. You can find the proposal page here: https://wiki.asterisk.org/wiki/display/AST/Asterisk+14+Project+-+URI+Media+Playback Ben Langfeld has already given some excellent feedback on the proposed approach; I'd encourage everyone to chime in on the page as there are some interesting edge cases that have to be considered for the feature. If you'd like to participate in the development and/or testing, please let me know either by replying to this e-mail or by commenting on the wiki page. Thanks! Matt -- _ -- 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] 4140: res_http_websockets: Module reference decrease below zero
--- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/4140/ --- (Updated Nov. 4, 2014, 1:30 p.m.) Status -- This change has been marked as submitted. Review request for Asterisk Developers. Changes --- Committed in revision 427200 Bugs: ASTERISK-24480 https://issues.asterisk.org/jira/browse/ASTERISK-24480 Repository: Asterisk Description --- In Asterisk 12+ websocket_add_protocol_internal is used to add the echo protocol, but ast_websocket_remove_protocol is used to remove it. This causes an extra call to ast_module_unref. Diffs - /branches/12/res/res_http_websocket.c 426831 Diff: https://reviewboard.asterisk.org/r/4140/diff/ Testing --- Found/tested with r4141. 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] Asterisk 14 - Remote URI Playback
On Tue, Nov 4, 2014 at 12:57 PM, BJ Weschke bwesc...@btwtech.com wrote:
Matt -
This is a pretty neat idea, indeed, but I've got some questions/thoughts on
implementation. :-) Apologies if all of this was already
considered/accounted for already..
1) Does the entire file need to be downloaded and in place on the HTTP
Media Cache before you can call an ast_openstream on it? This could cause
some problems with larger files not sitting on a fat pipe local to the
Asterisk instance.
It does need to be completely on the local file system, which would be
a problem for extremely large files and/or slow network connections.
The ability to do an 'asynchronous' version of this is not really
present. The filestream code in the core of Asterisk doesn't have
anything present that would allow it to buffer the file partially
before playing back with some expected max size. If we went down that
road, it'd almost be a completely separate filestream concept from
what we have today, which is pretty non-trivial.
I don't think I have a good solution for really large files just yet.
There's some ways to do this using cURL (where we get back a chunk of
binary data, buffer it, and immediately start turning it into frames
for a channel) - but that feels like it would need a lot of work,
since we'd be essentially creating a new remote filestream type.
2) What kind of locking is in place on the design to prevent HTTP Media
Cache from trying to update an expired resource that's already in the middle
of being streamed to a channel?
Items in the cache are reference counted, so if something is using an
item in the cache while the cache is being purged, that is safely
handled. The buckets API (which is based on sorcery) assumes a 'if
you're using it, you can hold it safely while something else swaps it
out' model of management - so it is safe to update the entry in the
cache with something new while something else uses the old cached
entry. The 'local file name' associated with the URI would be created
with mkstemp, so the risk of collision with local file names is low.
In the same fashion, a local file that is currently open and being
streamed has a reference associated with it in the OS. Calling unlink
on it will not cause the file to be disposed of until it is released.
3) I think you need to also introduce a PUT method on HTTP Media Cache
because I can think of a bunch of scenarios where having a write operation
on func_curl may be lacking in the file needing to be retrieved (eg - trying
to pull ACL'd media from an S3 volume where you need custom HTTP request
headers, etc). We shouldn't try to architect/design for all of these
scenarios in Asterisk via a write operation on func_curl and a PUT to HTTP
Media Cache seems like a reasonable approach to handle that.
I had thought about this, but didn't have a strong use case for it -
thanks for providing one!
How about something like:
GET /media_cache - retrieve a List of [Sound] in the cache
PUT /media_cache (note: would need to have parameters passed in the body)
uri=URI to retrieve the media from
headers=JSON list of key/value pairs to pass with the uri
DELETE /media_cache?uri
uri=URI to remove from the cache
Sounds data model would be updated with something like the following:
uri: {
required: false,
description: If retrieved from a remote source, the
originating URI of the sound,
type: string
},
local_timestamp: {
required: false,
description: Creation timestamp of the sound on the local system,
type: datetime
},
remote_timestamp: {
required: false,
description: Creation timestamp of the sound as known by
the remote system (if remote),
type: datetime
}
--
Matthew Jordan
Digium, Inc. | Engineering Manager
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
Check us out at: http://digium.com http://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] [Code Review] 4147: config: BUG: Restore ability for non-templates to be used as base objects in config.
--- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/4147/ --- (Updated Nov. 4, 2014, 2:47 p.m.) Status -- This change has been marked as submitted. Review request for Asterisk Developers and Scott Griepentrog. Changes --- Committed in revision 427227 Bugs: ASTERISK-24487 https://issues.asterisk.org/jira/browse/ASTERISK-24487 Repository: Asterisk Description --- My recent refactor of config.c accidentally removed the capability for a object to inherit from a non-template object. The following was no longer valid and should have been: [mybase] something=else [myobj](mybase) This patch restores the capability to inherit from both template and non-template objects. Diffs - branches/12/main/config.c 427199 Diff: https://reviewboard.asterisk.org/r/4147/diff/ Testing --- Testsuite manager/config tests still pass. main/config unit tests still pass. Eyeball test using AMI/GetConfig passed. 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] 4143: testsuite: Close HTTP connections when test is complete to prevent reported leaks in tests/phoneprov/res_phoneprov and tests/manager/config
--- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/4143/ --- (Updated Nov. 4, 2014, 2:57 p.m.) Status -- This change has been marked as submitted. Review request for Asterisk Developers. Changes --- Committed in revision 5887 Repository: testsuite Description --- HTTP connections left open when a test completes causes leaks to be reported by REF_DEBUG. This ensures the connections are closed in two tests to ensure they pass with REF_DEBUG. Remove import of syncami from tests/channels/SIP/pcap_demo since it's not actually used. Diffs - /asterisk/trunk/tests/phoneprov/res_phoneprov/run-test 5878 /asterisk/trunk/tests/manager/config/ManagerConfigTest.py 5878 /asterisk/trunk/tests/channels/SIP/pcap_demo/run-test 5878 /asterisk/trunk/lib/python/asterisk/syncami.py 5878 Diff: https://reviewboard.asterisk.org/r/4143/diff/ Testing --- Against 13, tests passed with no leaks reported. Verified no other active test uses syncami. Only tests/channels/SIP/nat_supertest used it but that test is disabled per ASTERISK-19565. 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] 4135: Resolve race condition that can result in ARI apps not being notified of transfers
--- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/4135/ --- (Updated Nov. 4, 2014, 9:44 p.m.) Review request for Asterisk Developers. Changes --- Because of what Richard pointed out in the previous review, the approach I have taken was not workable due to the race condition not being resolved in parking code. Going by the approaches listed in the original description, I have shifted from approach 4 to approach 2. This means there is an API change in the way that transfers are published. Before this change, the call to publish a transfer was a single thing that created the transfer message and published. Now this has been separated into functions to create the transfer message and to publish it. For blind transfers, we take the approach of creating a minimal transfer message and fill in the details as we get them. Then we publish when we're ready to do so. For attended transfers, we create a minimal transfer message as well, but we have helper functions to complete the transfer message depending on how the transfer ends up progressing. With this approach, snapshots of bridges are taken early in the transfer process so that when it comes time to publish the transfer, we publish details as they existed when the transfer was initiated. Repository: Asterisk Description (updated) --- During blind transfer testing, it was noticed that tests were failing occasionally because the ARI blind transfer event was not being sent. After investigating, I detected a race condition in the blind transfer code. When blind transferring a single channel, the actual transfer operation (i.e. removing the transferee from the bridge and directing them to the proper dialplan location) is queued onto the transferee bridge channel. After queuing the transfer operation, the blind transfer Stasis message is published. At the time of publication, snapshots of the channels and bridge involved are created. The ARI subscriber to the blind transfer Stasis message then attempts to determine if the bridge or any of the involved channels are subscribed to by ARI applications. If so, then the blind transfer message is sent to the applications. The way that the ARI blind transfer message handler works is to first see if the transferer channel is subscribed to. If not, then iterate over all the chan nel IDs in the bridge snapshot and determine if any of those are subscribed to. In the test we were running, the lone transferee channel was subscribed to, so an ARI event should have been sent to our application. Occasionally, though, the bridge snapshot did not have any channels IDs on it at all. Why? The problem is that since the blind transfer operation is handled by a separate thread, it is possible that the transfer will have completed and the channels removed from the bridge before we publish the blind transfer Stasis message. Since the blind transfer has completed, the bridge on which the transfer occurred no longer has any channels on it, so the resulting bridge snapshot has no channels on it. Through investigation of the code, I found that attended transfers can have this issue too for the case where a transferee is transferred to an application. To fix this problem, I thought of four possible fixes: 1) Let the thread that actually performs the blind transfer publish the Stasis message. 2) Get the bridge snapshot before queuing the blind transfer operation. 3) Publish the blind transfer Stasis message before queuing the blind transfer operation. 4) Hold the bridge lock while queuing the blind transfer operation and publishing the blind transfer Stasis message. Option 1 is clearly the best option, but it also is made nearly impossible due to the way that bridge channel operations are queued. Bridge channel operations use frames, which require that their payload be copyable using memcpy(). Including any sort of pointer is a no-no. So I would be forced to come up with some inane method of representing multiple channels and bridges in a frame in order to do this. Option 2 is slightly more workable. Currently, there are functions to publish blind and attended transfers that require bridges and channels, not snapshots. Changing the API to accommodate snapshots is possible, but it is more widespread than I would like, and it changes the API. It also runs the slight risk of publishing stale data, though that is not likely. Option 3 is easiest to implement, but it runs the (very slight) risk that we could publish that a blind transfer happened successfully when in fact the attempt to queue the blind transfer operation failed. I almost went with this, but I felt like the possibility of lying in our events was a bad thing to do. Option 4 is my least favorite, but within a release felt like the most viable method.
Re: [asterisk-dev] [Code Review] 4132: config: Make ast_config_text_file_save and 'dialplan save' escape semicolons in values.
--- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/4132/#review13670 --- Ship it! Ship It! - opticron On Oct. 30, 2014, 7:02 p.m., George Joseph wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/4132/ --- (Updated Oct. 30, 2014, 7:02 p.m.) Review request for Asterisk Developers and Birger Harzenetter. Bugs: ASTERISK-20127 https://issues.asterisk.org/jira/browse/ASTERISK-20127 Repository: Asterisk Description --- I've been locally patching for this issue for 2 years but now someone else (WIMPy) has run into the same problem. When a config file is read, an unescaped semicolon signals comments which are stripped from the value before it's stored. Escaped semicolons are then unescaped and become part of the value. Both of these behaviors are normal and expected. When the config is serialized either by 'dialplan save' or AMI/UpdateConfig however, the now unescaped semicolons are written as-is. If you actually reload the file just saved, the unescaped semicolons are now treated as start of comments. Example: Lines such as PAGING_HEADER = Call-Info: \;answer-after=0 are being rewritten as PAGING_HEADER = Call-Info: ;answer-after=0 On re-read, everything after the now-unescaped semicolon is read as a comment with the result that the file is effectively corrupted. So... Since true comments are stripped on read, any semicolons in ast_variable.value must have been escaped originally. This patch re-escapes semicolons in ast_variable.values before they're written to file either by 'dialplan save' or config/ast_config_text_file_save which is called by AMI/UpdateConfig. I also fixed a few pre-existing formatting issues nearby in pbx_config.c This patch is for 13 but it will be applied to 1.8 - trunk. Diffs - branches/13/tests/test_strings.c 426808 branches/13/pbx/pbx_config.c 426808 branches/13/main/utils.c 426808 branches/13/main/config.c 426808 branches/13/include/asterisk/utils.h 426808 Diff: https://reviewboard.asterisk.org/r/4132/diff/ Testing --- Testsuite results before and after match. tests/manager/config will be updated to test escaped semicolons. A new testsuite test will be written to test dialplan save. 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] 4148: res_pjsip_multihomed: Provide logging during startup for an indication of what is going on
--- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/4148/#review13672 --- Ship it! Ship It! - Mark Michelson On Nov. 4, 2014, 5:42 p.m., Joshua Colp wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/4148/ --- (Updated Nov. 4, 2014, 5:42 p.m.) Review request for Asterisk Developers. Bugs: ASTERISK-24438 https://issues.asterisk.org/jira/browse/ASTERISK-24438 Repository: Asterisk Description --- On systems that are having DNS problems res_pjsip_multihomed may hang for awhile as it tries to figure out the local IPv4 and IPv6 address. This change adds logging so you know this is happening and also once done tells you what IP addresses it has used. Diffs - /branches/12/res/res_pjsip_multihomed.c 427199 Diff: https://reviewboard.asterisk.org/r/4148/diff/ Testing --- Ran and confirmed messages output. Thanks, Joshua Colp -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] [Code Review] 4145: testsuite: update pretty_print script for recent runtests.py changes.
--- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/4145/#review13673 --- Why the change to being a standalone script? I personally like the idea of it being a filter more. - Mark Michelson On Nov. 3, 2014, 3:43 p.m., George Joseph wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/4145/ --- (Updated Nov. 3, 2014, 3:43 p.m.) Review request for Asterisk Developers. Repository: testsuite Description --- Updated contrib/scripts/pretty_print so it works with recent runtests.py changes. Also changed it from a filter to a standalone script. Diffs - asterisk/trunk/contrib/scripts/pretty_print 5878 Diff: https://reviewboard.asterisk.org/r/4145/diff/ Testing --- 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
[asterisk-dev] [Code Review] 4149: main/file.c: fix possible extra ast_module_unref to format modules
--- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/4149/ --- Review request for Asterisk Developers. Bugs: ASTERISK-24492 https://issues.asterisk.org/jira/browse/ASTERISK-24492 Repository: Asterisk Description --- fn_wrapper only adds a reference to the format's module if the file was able to be opened. If not this causes an unmatched ast_module_unref in filestream_destructor. Diffs - /branches/11/main/file.c 427255 Diff: https://reviewboard.asterisk.org/r/4149/diff/ Testing --- Verified the issue and fix with tests/apps/voicemail/play_message + r4141. 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] 4146: res_pjsip: If an endpoint is associated with the dialog place it on the messag early
--- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/4146/#review13674 --- Ship it! Ship It! - Mark Michelson On Nov. 3, 2014, 5:55 p.m., Joshua Colp wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/4146/ --- (Updated Nov. 3, 2014, 5:55 p.m.) Review request for Asterisk Developers. Bugs: AST-1459 https://issues.asterisk.org/jira/browse/AST-1459 Repository: Asterisk Description --- Currently when distributing a message the code finds the dialog related to it and if present uses the information to send the message to the right serializer and to place the endpoint on the message. For the endpoint its presence is checked in the endpoint lookup step and placed into the expected endpoint spot. This causes problems as the dialog handling will occur before the endpoint lookup step, causing the endpoint to get lost and never placed on the message. This change removes the endpoint lookup step requirement and places the endpoint in the expected spot in the distribution step. If the endpoint lookup step is actually invoked it just immediately returns if an endpoint is already present and does nothing. Diffs - /branches/12/res/res_pjsip/pjsip_distributor.c 427112 Diff: https://reviewboard.asterisk.org/r/4146/diff/ Testing --- Added some code to determine if endpoint is present in the NAT handling code. Without the patch no endpoint would be present on the 200 OK response to an outgoing re-INVITE. With the patch an endpoint is present on the 200 OK response. Thanks, Joshua Colp -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] [Code Review] 4145: testsuite: update pretty_print script for recent runtests.py changes.
On Nov. 4, 2014, 3:53 p.m., Mark Michelson wrote: Why the change to being a standalone script? I personally like the idea of it being a filter more. I changed it locally months back for 2 reasons... The first was that runtests wasn't pre-calculating and printing the total number of tests to run back then. So I had to run runtests twice, once to get the total number (in dry-run mode) then again for real. The other one was buffering problems. ./runtests.py | pretty_print wasn't printing output as often as it should so I was always doing python -u ./runtests.py | pretty_print. Honestly, I didn't think anyone else was using it. :) I can change it back to a filter if that's more useful. - George --- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/4145/#review13673 --- On Nov. 3, 2014, 8:43 a.m., George Joseph wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/4145/ --- (Updated Nov. 3, 2014, 8:43 a.m.) Review request for Asterisk Developers. Repository: testsuite Description --- Updated contrib/scripts/pretty_print so it works with recent runtests.py changes. Also changed it from a filter to a standalone script. Diffs - asterisk/trunk/contrib/scripts/pretty_print 5878 Diff: https://reviewboard.asterisk.org/r/4145/diff/ Testing --- 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] 4132: config: Make ast_config_text_file_save and 'dialplan save' escape semicolons in values.
--- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/4132/ --- (Updated Nov. 4, 2014, 6:11 p.m.) Status -- This change has been marked as submitted. Review request for Asterisk Developers and Birger Harzenetter. Changes --- Committed in revision 427275 Bugs: ASTERISK-20127 https://issues.asterisk.org/jira/browse/ASTERISK-20127 Repository: Asterisk Description --- I've been locally patching for this issue for 2 years but now someone else (WIMPy) has run into the same problem. When a config file is read, an unescaped semicolon signals comments which are stripped from the value before it's stored. Escaped semicolons are then unescaped and become part of the value. Both of these behaviors are normal and expected. When the config is serialized either by 'dialplan save' or AMI/UpdateConfig however, the now unescaped semicolons are written as-is. If you actually reload the file just saved, the unescaped semicolons are now treated as start of comments. Example: Lines such as PAGING_HEADER = Call-Info: \;answer-after=0 are being rewritten as PAGING_HEADER = Call-Info: ;answer-after=0 On re-read, everything after the now-unescaped semicolon is read as a comment with the result that the file is effectively corrupted. So... Since true comments are stripped on read, any semicolons in ast_variable.value must have been escaped originally. This patch re-escapes semicolons in ast_variable.values before they're written to file either by 'dialplan save' or config/ast_config_text_file_save which is called by AMI/UpdateConfig. I also fixed a few pre-existing formatting issues nearby in pbx_config.c This patch is for 13 but it will be applied to 1.8 - trunk. Diffs - branches/13/tests/test_strings.c 426808 branches/13/pbx/pbx_config.c 426808 branches/13/main/utils.c 426808 branches/13/main/config.c 426808 branches/13/include/asterisk/utils.h 426808 Diff: https://reviewboard.asterisk.org/r/4132/diff/ Testing --- Testsuite results before and after match. tests/manager/config will be updated to test escaped semicolons. A new testsuite test will be written to test dialplan save. 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] 4134: testsute: Add 'add-relative-to-search-path' handler to TestModuleLoader
--- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/4134/ --- (Updated Nov. 4, 2014, 6:21 p.m.) Status -- This change has been marked as submitted. Review request for Asterisk Developers. Changes --- Committed in revision 5894 Repository: testsuite Description --- I've got some common code I want to share between a few tests so it's in the test's parent directory. However, there doesn't seem to be a way to add the parent directory to the search path without specifying an absolute path. So, I added a helper to TestModuleLoader that will allow you to add paths relative to the test directory. Example: test-modules: add-test-to-search-path: 'True' add-relative-to-search-path: ['..'] test-object: config-section: object-config typename: 'ManagerConfigTest.ManagerConfigTest' This adds test_path/.. to the search path. I.E. The test's parent directory. Diffs - asterisk/trunk/lib/python/asterisk/test_runner.py 5831 Diff: https://reviewboard.asterisk.org/r/4134/diff/ Testing --- Works for my tests and doesn't affect any others. 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] 4136: testsuite: Add escaped semicolons tests for UpdateConfig and dialplan save
--- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/4136/ --- (Updated Nov. 5, 2014, 12:27 a.m.) Status -- This change has been marked as submitted. Review request for Asterisk Developers. Changes --- Committed in revision 5899 Repository: testsuite Description --- These are the testsuite tests for https://reviewboard.asterisk.org/r/4132/ They are dependent on https://reviewboard.asterisk.org/r/4134/ being committed first. tests/manager/config/advanced/test-config.yaml was already in trunk, I just moved it. Diffs - asterisk/trunk/tests/pbx/tests.yaml 5831 asterisk/trunk/tests/pbx/dialplan_save/test-config.yaml PRE-CREATION asterisk/trunk/tests/pbx/dialplan_save/run-test PRE-CREATION asterisk/trunk/tests/pbx/dialplan_save/configs/ast1/extensions.conf PRE-CREATION asterisk/trunk/tests/manager/tests.yaml 5831 asterisk/trunk/tests/manager/config/tests.yaml PRE-CREATION asterisk/trunk/tests/manager/config/test-config.yaml 5831 asterisk/trunk/tests/manager/config/basic/test-config.yaml PRE-CREATION asterisk/trunk/tests/manager/config/advanced/test-config.yaml PRE-CREATION Diff: https://reviewboard.asterisk.org/r/4136/diff/ Testing --- The tests fail for non patched installs and pass for r4132 patched installs. 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
[asterisk-dev] [Code Review] 4150: res_hep: fix major leak that occurs when config is missing or enabled=no
--- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/4150/ --- Review request for Asterisk Developers. Bugs: ASTERISK-24491 https://issues.asterisk.org/jira/browse/ASTERISK-24491 Repository: Asterisk Description --- Add missing unref to hepv3_send_packet. Diffs - /branches/13/res/res_hep.c 427298 Diff: https://reviewboard.asterisk.org/r/4150/diff/ Testing --- Tested by Zane Conkle. 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] 4150: res_hep: fix major leak that occurs when config is missing or enabled=no
--- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/4150/#review13677 --- Ship it! Ship It! - Joshua Colp On Nov. 5, 2014, 1:05 a.m., Corey Farrell wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/4150/ --- (Updated Nov. 5, 2014, 1:05 a.m.) Review request for Asterisk Developers. Bugs: ASTERISK-24491 https://issues.asterisk.org/jira/browse/ASTERISK-24491 Repository: Asterisk Description --- Add missing unref to hepv3_send_packet. Diffs - /branches/13/res/res_hep.c 427298 Diff: https://reviewboard.asterisk.org/r/4150/diff/ Testing --- Tested by Zane Conkle. 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] 4150: res_hep: fix major leak that occurs when config is missing or enabled=no
On Nov. 4, 2014, 7:07 p.m., Joshua Colp wrote: Ship It! Into 12 as well... thanks for the fix :-) - Matt --- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/4150/#review13677 --- On Nov. 4, 2014, 7:05 p.m., Corey Farrell wrote: --- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/4150/ --- (Updated Nov. 4, 2014, 7:05 p.m.) Review request for Asterisk Developers. Bugs: ASTERISK-24491 https://issues.asterisk.org/jira/browse/ASTERISK-24491 Repository: Asterisk Description --- Add missing unref to hepv3_send_packet. Diffs - /branches/13/res/res_hep.c 427298 Diff: https://reviewboard.asterisk.org/r/4150/diff/ Testing --- Tested by Zane Conkle. 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] Asterisk 14 - Remote URI Playback
On 11/4/14, 3:40 PM, Matthew Jordan wrote: On Tue, Nov 4, 2014 at 12:57 PM, BJ Weschke bwesc...@btwtech.com wrote: Matt - This is a pretty neat idea, indeed, but I've got some questions/thoughts on implementation. :-) Apologies if all of this was already considered/accounted for already.. 1) Does the entire file need to be downloaded and in place on the HTTP Media Cache before you can call an ast_openstream on it? This could cause some problems with larger files not sitting on a fat pipe local to the Asterisk instance. It does need to be completely on the local file system, which would be a problem for extremely large files and/or slow network connections. The ability to do an 'asynchronous' version of this is not really present. The filestream code in the core of Asterisk doesn't have anything present that would allow it to buffer the file partially before playing back with some expected max size. If we went down that road, it'd almost be a completely separate filestream concept from what we have today, which is pretty non-trivial. I don't think I have a good solution for really large files just yet. There's some ways to do this using cURL (where we get back a chunk of binary data, buffer it, and immediately start turning it into frames for a channel) - but that feels like it would need a lot of work, since we'd be essentially creating a new remote filestream type. I know there's going to be a large population of Asterisk users that will want the simplicity of just specifying a URI for playback and expecting sorcery to happen. A decent number of them may even be OK with what may be a sub-second awkward silence to the caller on the line while things like the servicing thread synchronously queues the URI resource into the local HTTP media cache before playback. That's probably going to be an acceptable experience for a decent number of functional use cases. However, I think one somewhat common use case where this wouldn't go so well would be a list of URI resources that weren't already in HTTP media cache since they'd be fetched serially in-line at the time where playback really should be starting and block the channel with silence until the resource is set in media cache. eg - Playback(http://myserver.com/monkeys.wavhttp://myserver.com/can.wavhttp://myserver.com/act.wavhttp://myserver.com/like.wavhttp://myserver.com/weasels.wav) --- On an empty HTTP Media cache, the previous app invocation would probably sound pretty bad to the first caller going through this workflow. :-) Also, I think the inability to use in a URI for playback really limits the usefulness of this change. I totally understand why the typical URI decode doesn't work, but perhaps a combination of a URI encoded with an HTML entity representation is a suitable alternative? eg - (%26amp; == in a URI in Playback and do that pattern replacement in the URI before any other URI decoding/encoding operations. Ya, I know, it's a hack, but not allowing multiple parameters in a loaded queryString URL is way too restricting IMHO). 2) What kind of locking is in place on the design to prevent HTTP Media Cache from trying to update an expired resource that's already in the middle of being streamed to a channel? Items in the cache are reference counted, so if something is using an item in the cache while the cache is being purged, that is safely handled. The buckets API (which is based on sorcery) assumes a 'if you're using it, you can hold it safely while something else swaps it out' model of management - so it is safe to update the entry in the cache with something new while something else uses the old cached entry. The 'local file name' associated with the URI would be created with mkstemp, so the risk of collision with local file names is low. In the same fashion, a local file that is currently open and being streamed has a reference associated with it in the OS. Calling unlink on it will not cause the file to be disposed of until it is released. I had to do a little bit of reading up on the Bucket File API, but yes, that definitely resolves the concern I had, and that's pretty cool. :-) 3) I think you need to also introduce a PUT method on HTTP Media Cache because I can think of a bunch of scenarios where having a write operation on func_curl may be lacking in the file needing to be retrieved (eg - trying to pull ACL'd media from an S3 volume where you need custom HTTP request headers, etc). We shouldn't try to architect/design for all of these scenarios in Asterisk via a write operation on func_curl and a PUT to HTTP Media Cache seems like a reasonable approach to handle that. I had thought about this, but didn't have a strong use case for it - thanks for providing one! How about something like: GET /media_cache - retrieve a List of [Sound] in the cache PUT /media_cache (note: would need to have parameters passed in the body) uri=URI to retrieve the media from headers=JSON
