given their own mailing lists which has made this one less
traffic as well.
[1] irc.freenode.net #asterisk-dev
[2] http://lists.digium.com/pipermail/asterisk-app-dev/
[3] http://lists.digium.com/pipermail/asterisk-code-review/
--
Joshua Colp
Digium, Inc. | Senior Software Developer
445 Jan Davis
://gerrit.asterisk.org/#/admin/projects/asterisk
The repository is also mirrored onto github for browsing and read-only
clones:
https://github.com/asterisk/asterisk/
I also do agree that stuff still needs to be updated. We'll get there!
Cheers,
--
Joshua Colp
Digium, Inc. | Senior Software
the expected order (opus,ulaw) is offered.
Question 2: Shall I open an issue for this, or is that intended?
If you reload it should have the new preference order. This would be a
bug, likely in chan_sip itself.
--
Joshua Colp
Digium, Inc. | Senior Software Developer
445 Jan Davis Drive NW - Huntsville, AL
elsewhere would be this.
--
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
Greetings all,
Based on the feedback I've updated the wiki page[1] with tweaks,
additional potential tests, clarification, etc.
Cheers,
[1] https://wiki.asterisk.org/wiki/display/~jcolp/Sorcery+Caching
--
Joshua Colp
Digium, Inc. | Senior Software Developer
445 Jan Davis Drive NW
George Joseph wrote:
On Thu, Apr 30, 2015 at 10:29 AM, Joshua Colp jc...@digium.com
mailto:jc...@digium.com wrote:
George Joseph wrote:
Ok, but will the caching wizard support the C,U,D operations as the
memory wizard does?.
They could, but the caching infrastructure
for caching because there are no
observers on retrieval. As well, the observers are only invoked when the
operation actually occurs.
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
a handle to it to create/update/destroy?
Wrap that up in a higher level API like you want above and you extend
sorcery in a way that's useful in multiple ways.
Cheers,
--
Joshua Colp
Digium, Inc. | Senior Software Developer
445 Jan Davis Drive NW - Huntsville, AL 35806 - US
Check us out
George Joseph wrote:
On Thu, Apr 30, 2015 at 2:01 PM, Joshua Colp jc...@digium.com
mailto:jc...@digium.com wrote:
George Joseph wrote:
Change https://gerrit.asterisk.org/261 sparked some discussion about
contacts and contact status so I'd like to continue that here
George Joseph wrote:
On Thu, Apr 30, 2015 at 5:06 PM, Joshua Colp jc...@digium.com
mailto:jc...@digium.com wrote:
George Joseph wrote:
On Thu, Apr 30, 2015 at 3:59 PM, Joshua Colp jc...@digium.com
mailto:jc...@digium.com
mailto:jc...@digium.com mailto:jc
a contact status changes I need to be able to store this information
That sort of thing.
--
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
George Joseph wrote:
On Thu, Apr 30, 2015 at 3:59 PM, Joshua Colp jc...@digium.com
mailto:jc...@digium.com wrote:
George Joseph wrote:
snip
What if contacts are stored in an external
database? Your
proposal
would
George Joseph wrote:
On Tue, Apr 28, 2015 at 10:28 AM, Joshua Colp jc...@digium.com
mailto:jc...@digium.com wrote:
Kia ora,
I've created a wiki page[1] which details the beginnings of a basic
memory based caching wizard for sorcery. Right now while caching is
possible using
mechanisms that should be exposed to allow
explicit object expiration?
3. Are the defaults sane?
4. Is there additional testing that should be done?
5. Does anything need additional explanation?
Cheers,
[1] https://wiki.asterisk.org/wiki/display/~jcolp/Sorcery+Caching
--
Joshua Colp
Digium, Inc
with, though.
--
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
.
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
commit with the
original changes. The single commit you post for review is what is
reviewed and merged into the branch.
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
Joshua Colp has posted comments on this change.
Change subject: Optional API: Fix handling of sources that are both provider
and user.
..
Patch Set 1: Code-Review+2 Verified+1
--
To view, visit https://gerrit.asterisk.org/73
Joshua Colp has uploaded a new patch set (#2).
Change subject: pjsip: Add basic resolver tests covering A/, SRV, and NAPTR.
..
pjsip: Add basic resolver tests covering A/, SRV, and NAPTR.
These tests cover the following
Joshua Colp has posted comments on this change.
Change subject: res_monitor: Add dependency on func_periodic_hook.
..
Patch Set 1: Code-Review+2 Verified+1
--
To view, visit https://gerrit.asterisk.org/72
To unsubscribe
Joshua Colp has submitted this change and it was merged.
Change subject: res_monitor: Add dependency on func_periodic_hook.
..
res_monitor: Add dependency on func_periodic_hook.
OPTIONAL_API has conditionals to define
Joshua Colp has posted comments on this change.
Change subject: git migration: Refactor the ASTERISK_FILE_VERSION macro
..
Patch Set 5: Code-Review+2 Verified+1
--
To view, visit https://gerrit.asterisk.org/58
To unsubscribe
Joshua Colp has posted comments on this change.
Change subject: tests/channels/pjsip/config_wizard/hints: Add 'has_hint'
variable
..
Patch Set 1: Code-Review+1
--
To view, visit https://gerrit.asterisk.org/41
To unsubscribe
Joshua Colp has submitted this change and it was merged.
Change subject: git migration: Remove support for file versions
..
git migration: Remove support for file versions
Git does not support the ability to replace a token
Joshua Colp has posted comments on this change.
Change subject: git migration: Remove support for file versions
..
Patch Set 3: Code-Review+2 Verified+1
--
To view, visit https://gerrit.asterisk.org/61
To unsubscribe, visit
Joshua Colp has posted comments on this change.
Change subject: git migration: Remove support for file versions
..
Patch Set 3: Code-Review+2 Verified+1
--
To view, visit https://gerrit.asterisk.org/60
To unsubscribe, visit
Joshua Colp has uploaded a new change for review.
https://gerrit.asterisk.org/75
Change subject: res_pjsip: Add external PJSIP resolver implementation using
core DNS API.
..
res_pjsip: Add external PJSIP resolver
Joshua Colp has submitted this change and it was merged.
Change subject: git migration: Remove support for file versions
..
git migration: Remove support for file versions
Git does not support the ability to replace a token
://reviewboard.asterisk.org/r/4587/#comment25807
You *CAN NOT* do this. Sorcery objects are immutable. You have to create a
new one and then update using it.
branches/13/res/res_pjsip/pjsip_options.c
https://reviewboard.asterisk.org/r/4587/#comment25808
Same here.
- Joshua Colp
On April 7
Joshua Colp has uploaded a new change for review.
https://gerrit.asterisk.org/37
Change subject: pjsip: Add test for OPTIONS requests received in-dialog.
..
pjsip: Add test for OPTIONS requests received in-dialog.
This test
---
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/4606/#review15160
---
Ship it!
Ship It!
- Joshua Colp
On April 9, 2015, 5:05 p.m
/#comment25814
Expand this to clarify that the actual behavior will match that of previous
versions.
- Joshua Colp
On April 9, 2015, 4:35 p.m., Kevin Harwell wrote:
---
This is an automatically generated e-mail. To reply, visit
.
I think instead of using our own scheduler the PJSIP one should be used
instead. There's a guarantee that only one scheduled item will occur at a time,
so you won't clash with the transaction timers.
- Joshua Colp
On April 3, 2015, 8:12 p.m., George Joseph wrote
On March 23, 2015, 8:01 p.m., Matt Jordan wrote:
Thanks for the patch! I've clicked the Ship It button, although the same
statement about requiring tests for things going into Asterisk 13 that I
made on the DTMF review applies here as well.
In this particular case, a test for this
of what is going on
and how this fixes it? The load order, the unload order, what happens when,
that sort of thing.
- Joshua Colp
On April 8, 2015, 6:09 p.m., George Joseph wrote:
---
This is an automatically generated e-mail. To reply
---
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/4590/#review15143
---
Ship it!
Ship It!
- Joshua Colp
On April 8, 2015, 6:21 p.m
---
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/4607/#review15165
---
Ship it!
Ship It!
- Joshua Colp
On April 9, 2015, 5:04 p.m
://reviewboard.asterisk.org/r/4597/#comment25795
That isn't quite what the CLI command does. It shows both the global and
system configuration settings.
Remember to update your description/testing if you make changes that render
them, well, inaccurate.
- Joshua Colp
On April 7, 2015, 10:35 p.m., Kevin Harwell
---
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/4598/#review15131
---
Ship it!
Ship It!
- Joshua Colp
On April 7, 2015, 5:49 p.m
Joshua Colp has uploaded a new change for review.
https://gerrit.asterisk.org/31
Change subject: pjsip: Add basic resolver tests covering A/, SRV, and NAPTR.
..
pjsip: Add basic resolver tests covering A/, SRV
://reviewboard.asterisk.org/r/4590/#comment25796
Extend this comment to explain why so the next person looking at it will
know what is up. It took me a bit after looking at things to understand what
exactly was going on.
- Joshua Colp
On April 4, 2015, 12:17 p.m., Corey Farrell wrote
---
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/4597/#review15133
---
Ship it!
Ship It!
- Joshua Colp
On April 8, 2015, 5:52 p.m
---
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/4600/#review15132
---
Ship it!
Ship It!
- Joshua Colp
On April 8, 2015, 5:24 p.m
/configure UNKNOWN
Diff: https://reviewboard.asterisk.org/r/4603/diff/
Testing
---
Ran unit tests, they pass. Ran testsuite tests, they pass. Did spot checking
using my own domains. They resolve as expected.
Thanks,
Joshua Colp
Joshua Colp has posted comments on this change.
Change subject: Testsuite: New test for FAX via PJSIP T38 with authentication
..
Patch Set 4: Verified+1
--
To view, visit https://gerrit.asterisk.org/28
To unsubscribe, visit
Joshua Colp has submitted this change and it was merged.
Change subject: Testsuite: New test for FAX via PJSIP T38 with authentication
..
Testsuite: New test for FAX via PJSIP T38 with authentication
Add a test for PJSIP t38
---
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/4549/#review15065
---
Ship it!
Ship It!
- Joshua Colp
On April 6, 2015, 2:39 a.m
the two others?
- Joshua Colp
On March 31, 2015, 5:57 a.m., George Joseph wrote:
---
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/4572
to only set the far
max datagram if not explicitly configured. Right now it will set it again
needlessly.
- Joshua Colp
On April 3, 2015, 10:10 p.m., Juergen Spies wrote:
---
This is an automatically generated e-mail. To reply, visit
of the datastore itself is what you care about. As a result you don't need to
create space to store the framehook id. You can just create the datastore and
attach it.
- Joshua Colp
On April 3, 2015, 5:03 p.m., Jonathan Rose wrote
On April 6, 2015, 1:24 p.m., Joshua Colp wrote:
I think the t38_interpret_sdp function should be updated to only set the
far max datagram if not explicitly configured. Right now it will set it
again needlessly.
Juergen Spies wrote:
That is true if we can be sure
://reviewboard.asterisk.org/r/4577/#comment25752
How could this occur?
- Joshua Colp
On April 6, 2015, 4:14 p.m., Jonathan Rose wrote:
---
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/4577
On April 6, 2015, 4:16 p.m., Joshua Colp wrote:
/certified/branches/13.1/res/res_pjsip_t38.c, lines 493-498
https://reviewboard.asterisk.org/r/4577/diff/3/?file=73632#file73632line493
How could this occur?
Jonathan Rose wrote:
As far as I know, it should never occur. I'm
/4588/#comment25746
Newer code should use sscanf for converting.
trunk/channels/chan_iax2.c
https://reviewboard.asterisk.org/r/4588/#comment25745
This should be removed.
- Joshua Colp
On April 3, 2015, 10:06 p.m., Y Ateya wrote
/res_resolver_unbound.c 433815
/trunk/main/dns_srv.c 433815
/trunk/main/dns_core.c 433815
/trunk/include/asterisk/dns_internal.h 433815
Diff: https://reviewboard.asterisk.org/r/4528/diff/
Testing
---
Executed unit tests and confirmed they pass.
Thanks,
Joshua Colp
: https://reviewboard.asterisk.org/r/4556/diff/
Testing
---
Ran unit tests, they are happy.
Thanks,
Joshua Colp
--
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
asterisk-dev mailing list
Joshua Colp has posted comments on this change.
Change subject: rest_api/channels/snoop_spy: Stop test on bridge destruction
..
Patch Set 1: Verified+1
--
To view, visit https://gerrit.asterisk.org/21
To unsubscribe, visit
Joshua Colp has submitted this change and it was merged.
Change subject: rest_api/channels/snoop_spy: Stop test on bridge destruction
..
rest_api/channels/snoop_spy: Stop test on bridge destruction
The snoop_spy test
Joshua Colp has posted comments on this change.
Change subject: rest_api/channels/snoop_spy: Stop test on bridge destruction
..
Patch Set 1: Code-Review+2
--
To view, visit https://gerrit.asterisk.org/21
To unsubscribe, visit
---
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/4557/#review14969
---
Ship it!
Ship It!
- Joshua Colp
On March 29, 2015, 6:30
On March 31, 2015, 3:19 p.m., Michael Young wrote:
I would hold off on committing this patch as I feel it is not really a
proper solution. I believe that this is just short circuiting the
conditional and always applying remapping if IPv6 is involved or not. On
the issue tracker,
---
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/4563/#review14970
---
Ship it!
Ship It!
- Joshua Colp
On March 30, 2015, 2:23
, Valentin has provided some debug logs which, unless I am
reading them wrong, point to a configuration error. The IPv4 addresses are
not being mapped to IPv6 at all according to the debug logs.
Joshua Colp wrote:
If the socket is bound to :: they'll be IPv6 mapped. I've seen
/include/asterisk/dns_internal.h 433815
Diff: https://reviewboard.asterisk.org/r/4528/diff/
Testing
---
Executed unit tests and confirmed they pass.
Thanks,
Joshua Colp
--
_
-- Bandwidth and Colocation Provided by http
.
- Joshua Colp
On March 28, 2015, 3:19 a.m., Matt Jordan wrote:
---
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/4549
://reviewboard.asterisk.org/r/4519/#comment25586
Nitpick: A failure occurred when executing the Stasis application.
Otherwise good.
- Joshua Colp
On March 28, 2015, 5:38 a.m., Ashley Sanders wrote:
---
This is an automatically generated e-mail
, they are 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
.
--
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
snip all the things
G, it requires an rdata. I'll ponder further.
--
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
,
--
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
and since we presumably will have already sent a message, or shortly will,
it'll all be fine?
If that happens do the callers cope fine with it?
- Joshua Colp
On March 26, 2015, 10:54 p.m., Mark Michelson wrote
---
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/4538/#review14891
---
Ship it!
Ship It!
- Joshua Colp
On March 27, 2015, 11:52
/r/4512/diff/
Testing
---
Hacked in a query to my own domain and confirmed it worked. Also ran the unit
tests and confirmed they pass.
Thanks,
Joshua Colp
--
_
-- Bandwidth and Colocation Provided by http://www.api
On March 24, 2015, 3:39 p.m., Mark Michelson wrote:
I'm not a big fan of this module for a couple of reasons:
1) The data in the request URI is intended to describe who the call is
destined to be sent to, not who the call originated from. There are systems
out there where the
registered to
in the same way that chan_sip used the 'regserver' field.
This functionality does not currently exist.
[1] https://wiki.asterisk.org/wiki/display/AST/Setting+up+PJSIP+Realtime
--
Joshua Colp
Digium, Inc. | Senior Software Developer
445 Jan Davis Drive NW - Huntsville, AL 35806 - US
Check
but no
guarantees.
[1]
https://wiki.asterisk.org/wiki/display/AST/Asterisk+Issue+Guidelines#AsteriskIssueGuidelines-Howtorequestafeature
--
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
--
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
Colp
On March 19, 2015, 6:36 p.m., Joshua Colp wrote:
---
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/4512/
---
(Updated March 19
On March 23, 2015, 9:45 p.m., Matt Jordan wrote:
./branches/13/apps/app_stasis.c, lines 75-79
https://reviewboard.asterisk.org/r/4519/diff/1/?file=72716#file72716line75
You'll want to document this new channel variable in the XML
documentation at the top of the file. Something
://reviewboard.asterisk.org/r/4519/#comment25382
+1 to this. I think following the pattern for other applications that do
this is good - they just do success/failed.
Just a comment on the code review itself: Please always fill in the Testing
Done field with the testing you've done.
- Joshua Colp
On March 23
endpont independence of the ACL, not require additional search endpoint
checking ACL.
I don't understand what you mean here.
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
on use of transport=, it's not needed here.
/asterisk/trunk/tests/channels/pjsip/rpid_immediate/configs/ast1/pjsip.conf
https://reviewboard.asterisk.org/r/4518/#comment25379
Same for contacts when udp is wanted. The transport= isn't needed.
- Joshua Colp
On March 23, 2015, 9:55 p.m., rmudgett
configuration for this module also needs to
exist somewhere. I think it should also be turned off by default because in
some deployments it could start breaking things. (Matching on an endpoint that
wasn't expected to previously)
- Joshua Colp
On March 11, 2015, 4:30 p.m., Dmitriy Serov wrote
---
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/4477/#review14786
---
Ship it!
Ship It!
- Joshua Colp
On March 19, 2015, 9:59
---
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/4496/#review14784
---
Ship it!
Ship It!
- Joshua Colp
On March 14, 2015, 3:21
to maintain.
From an implementation perspective it's not hard. Allow ACLs to be
specified on the endpoint. This can be a vector of strings. In
res_pjsip_acl check the endpoint for ACLs and enforce their
restrictions. If no ACLs are present on the endpoint enforce the global
ACLs.
Cheers,
--
Joshua
ran the unit
tests and confirmed they pass.
Thanks,
Joshua Colp
--
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
http
-CREATION
/trunk/include/asterisk/dns_internal.h PRE-CREATION
/trunk/include/asterisk/dns_core.h PRE-CREATION
Diff: https://reviewboard.asterisk.org/r/4474/diff/
Testing
---
Ran DNS unit tests as done by Mark, they are happy.
Thanks,
Joshua Colp
.
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
---
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/4514/#review14738
---
Ship it!
Ship It!
- Joshua Colp
On March 18, 2015, 10:33
the underlying issue for the
particular configuration.
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
---
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/4504/#review14715
---
Ship it!
Ship It!
- Joshua Colp
On March 16, 2015, 5:48
not have any impact on the dialog.
- Joshua Colp
On March 15, 2015, 8:02 a.m., yaron nahum wrote:
---
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/4499
---
On March 13, 2015, 4:04 p.m., Joshua Colp wrote:
---
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/4474
PRE-CREATION
/trunk/include/asterisk/dns_core.h PRE-CREATION
Diff: https://reviewboard.asterisk.org/r/4474/diff/
Testing
---
Ran DNS unit tests as done by Mark, they are happy.
Thanks,
Joshua Colp
--
_
-- Bandwidth
PRE-CREATION
/trunk/include/asterisk/dns_core.h PRE-CREATION
Diff: https://reviewboard.asterisk.org/r/4474/diff/
Testing
---
Ran DNS unit tests as done by Mark, they are happy.
Thanks,
Joshua Colp
--
_
-- Bandwidth
()
could be passed to ast_dns_resolve_cancel(), and that's it. This would be
similar to how ast_dns_resolve_recurring() works.
Joshua Colp wrote:
I'm not sure how that would stop the reading of results though. We'd need
to add a lock in, which is something I was trying to avoid
., Joshua Colp wrote:
---
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/4474/
---
(Updated March 16, 2015, 2:33 p.m.)
Review request
PRE-CREATION
/trunk/include/asterisk/dns_core.h PRE-CREATION
Diff: https://reviewboard.asterisk.org/r/4474/diff/
Testing
---
Ran DNS unit tests as done by Mark, they are happy.
Thanks,
Joshua Colp
--
_
-- Bandwidth
PRE-CREATION
/trunk/include/asterisk/dns_core.h PRE-CREATION
Diff: https://reviewboard.asterisk.org/r/4474/diff/
Testing
---
Ran DNS unit tests as done by Mark, they are happy.
Thanks,
Joshua Colp
--
_
-- Bandwidth
201 - 300 of 1200 matches
Mail list logo
