---
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/2959/#review10237
---
Ship it!
branches/12/res/res_pjsip_pubsub.c
---
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/2987/#review10232
---
Ship it!
branches/12/include/asterisk/stasis.h
---
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/3016/
---
(Updated Nov. 21, 2013, 4:38 p.m.)
Status
--
This change has been
---
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/2994/
---
(Updated Nov. 21, 2013, 2:47 p.m.)
Review request for Asterisk Developers
On Nov. 21, 2013, 12:59 a.m., Paul Belanger wrote:
branches/12/rest-api/api-docs/device_states.json, line 11
https://reviewboard.asterisk.org/r/3025/diff/1/?file=48553#file48553line11
Hmm, not a fan of this URL schema. At first glance, what about just
/states.
On Nov. 21, 2013, 12:53 p.m., opticron wrote:
branches/12/include/asterisk/stasis_app.h, line 180
https://reviewboard.asterisk.org/r/2947/diff/5/?file=48327#file48327line180
This should return the enum instead of int.
Kevin Harwell wrote:
The problem with making this an enum
---
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/3024/#review10240
---
Ship it!
Ship It!
- Joshua Colp
On Nov. 20, 2013, 9:12
George Joseph wrote:
Just FYI... I've got a whole bunch of pjsip cli stuff waiting on this
patch to be committed. Any chance of this happening this week?
It'll get reviewed today and pending any other findings arising it'll go
in shortly.
If possible you could just throw your stuff up
---
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/3023/#review10242
---
Shouldn't something like this be a channel function from which
---
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/3025/#review10254
---
branches/12/include/asterisk/stasis_app.h
---
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/2947/
---
(Updated Nov. 21, 2013, 1:50 p.m.)
Review request for Asterisk
---
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/3025/#review10257
---
branches/12/include/asterisk/stasis_app.h
---
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/3023/#review10235
---
Ship it!
Ship It!
- Joshua Colp
On Nov. 20, 2013, 9:12
---
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/3025/#review10260
---
branches/12/res/res_stasis_device_state.c
---
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/3024/#review10236
---
I don't see where the user event is actually checked...
On Nov. 21, 2013, 8:05 p.m., Matt Jordan wrote:
/branches/12/res/res_stasis_snoop.c, lines 215-228
https://reviewboard.asterisk.org/r/3003/diff/3/?file=48153#file48153line215
Going out on a limb here, but if this ever occurs, something has gone
horribly wrong. We should never
---
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/3003/#review10253
---
/branches/12/res/res_stasis_snoop.c
On Nov. 21, 2013, 12:59 a.m., Paul Belanger wrote:
Thanks for this, I plan to spend some time over the weekend trying this
out. My comments are mostly from the ARIs POV, specifically what is a
device in ARI? and is that the same as an endpoint?
I'd akin this more to a virtual generic
On Nov. 21, 2013, 6:04 p.m., Mark Michelson wrote:
branches/12/res/res_stasis_device_state.c, lines 142-149
https://reviewboard.asterisk.org/r/3025/diff/1/?file=48549#file48549line142
Instead of constructing a device_state_subscription and searching by
OBJ_SEARCH_OBJECT, just use
---
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/3025/
---
(Updated Nov. 21, 2013, 6:25 p.m.)
Review request for Asterisk
On Nov. 20, 2013, 6:07 p.m., Matt Jordan wrote:
/branches/12/main/http.c, line 631
https://reviewboard.asterisk.org/r/2994/diff/2/?file=48312#file48312line631
Particularly since this is coming from an external source, we should
probably use sscanf.
You pretty much do
On Thu, Nov 21, 2013 at 7:25 AM, Joshua Colp jc...@digium.com wrote:
George Joseph wrote:
Just FYI... I've got a whole bunch of pjsip cli stuff waiting on this
patch to be committed. Any chance of this happening this week?
It'll get reviewed today and pending any other findings arising
On Nov. 21, 2013, 2:17 p.m., Joshua Colp wrote:
The code itself looks fine, the only nagging question I have is why not
just treat the variable as a temporary return variable in the case when you
have multiple MixMonitor instances and use Set in the dialplan to set
another variable
On Nov. 21, 2013, 4:40 p.m., Tilghman Lesher wrote:
Shouldn't something like this be a channel function from which you retrieve
the value, instead of specifying a variable into which the name is placed?
Seems like a significant regression in spitting things out to channel
variables,
On Nov. 14, 2013, 4:53 p.m., Mark Michelson wrote:
/branches/12/res/res_stasis_snoop.c, line 142
https://reviewboard.asterisk.org/r/3003/diff/3/?file=48153#file48153line142
Hm, would it be more useful to publish the snoop messages on the spyee
channel's topic? I would suspect
---
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/3017/#review10233
---
Ship it!
- Joshua Colp
On Nov. 18, 2013, 9:25 p.m.,
---
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/3023/#review10231
---
The code itself looks fine, the only nagging question I have
On Nov. 21, 2013, 6:09 p.m., opticron wrote:
/asterisk/trunk/tests/apps/say_interrupt/configs/ast1/sip.conf, lines 1-12
https://reviewboard.asterisk.org/r/3018/diff/1/?file=48290#file48290line1
This entire file seems irrelevant to the the test being added and
directs calls to a
---
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/3019/
---
(Updated Nov. 21, 2013, 9:55 a.m.)
Status
--
This change has been
---
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/3020/#review10244
---
Ship it!
Extraneous white space and a suggestion. Nice work!
---
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/2947/
---
(Updated Nov. 21, 2013, 2:24 p.m.)
Review request for Asterisk
On Nov. 22, 2013, 12:04 a.m., Mark Michelson wrote:
branches/12/res/res_stasis_device_state.c, lines 142-149
https://reviewboard.asterisk.org/r/3025/diff/1/?file=48549#file48549line142
Instead of constructing a device_state_subscription and searching by
OBJ_SEARCH_OBJECT, just
---
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/3015/#review10243
---
Ship it!
Ship It!
On Nov. 7, 2013, 3:37 p.m., Joshua Colp wrote:
To make sure I better understand the situation...
Is it caching an old stale entry without address?
Then when device state is queried it uses that old stale entry instead of
requerying realtime... so it thinks it has no address when
On Nov. 21, 2013, 4:40 p.m., Tilghman Lesher wrote:
Shouldn't something like this be a channel function from which you retrieve
the value, instead of specifying a variable into which the name is placed?
Seems like a significant regression in spitting things out to channel
variables,
---
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/3018/#review10245
---
On Nov. 21, 2013, 3:38 p.m., Joshua Colp wrote:
I don't see where the user event is actually checked... shouldn't you have
specified the requirement of a Yay event in your test-config.yaml?
Nope, SimpleTestCase determines pass/fail based solely on the number of
UserEvents that are
---
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/3015/
---
(Updated Nov. 21, 2013, 3:40 p.m.)
Review request for Asterisk
---
This is an automatically generated e-mail. To reply, visit:
https://reviewboard.asterisk.org/r/3025/
---
(Updated Nov. 21, 2013, 1:12 p.m.)
Review request for Asterisk
On Nov. 21, 2013, 12:53 p.m., opticron wrote:
branches/12/include/asterisk/stasis_app.h, line 180
https://reviewboard.asterisk.org/r/2947/diff/5/?file=48327#file48327line180
This should return the enum instead of int.
The problem with making this an enum is currently it is assumed
40 matches
Mail list logo
