Re: [asterisk-dev] Asterisk MoS and RTCP data [pardon the directness and language :-)]

On Thu, Nov 6, 2014 at 8:30 AM, Nir Simionovich wrote: > Hi All, > > So, if there is one thing I really like about PJSIP and WebRTC (specifically > with mobile) is the ability to produce meaningful MoS scoring for calls in > real time. Now, Asterisk doesn't have that capability, at least, not duri

Re: [asterisk-dev] Asterisk 14 - Remote URI Playback

On Thu, Nov 6, 2014 at 6:46 PM, Joshua Colp wrote: >> >> I think this is the way to do this in the long run. There's some major >> technical hurdles to overcome with this, however: >> >> (1) A remote file stream doesn't have the ability to do a 'parallel >> fetch' the way it is proposed on the wik

Re: [asterisk-dev] func_jitterbuffer handling of masquerades

Matthew Jordan wrote: (Conserve the bytes) This gets further weird with ConfBridge (unfortunately), which uses func_jitterbuffer to put a jitterbuffer on each channel that joins. This works great unless they get masqueraded out of the ConfBridge. Should the jitterbuffer travel with them at th

Re: [asterisk-dev] Asterisk 14 - Remote URI Playback

Matthew Jordan wrote: I think this is the way to do this in the long run. There's some major technical hurdles to overcome with this, however: (1) A remote file stream doesn't have the ability to do a 'parallel fetch' the way it is proposed on the wiki page. For video streams, that means Ast

Re: [asterisk-dev] Asterisk 14 - Remote URI Playback

On 11/6/14, 4:04 PM, Matthew Jordan wrote: eg - Playback(http://myserver.com/monkeys.wav&http://myserver.com/can.wav&http://myserver.com/act.wav&http://myserver.com/like.wav&http://myserver.com/weasels.wav) <--- On an empty HTTP Media cache, the previous app invocation would probably sound pr

[asterisk-dev] [Code Review] 4156: Test Suite: Allow setting snaplen & buffer_size for packet capturing

--- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/4156/ --- Review request for Asterisk Developers. Repository: testsuite Descriptio

Re: [asterisk-dev] Asterisk 14 - Remote URI Playback

On Wed, Nov 5, 2014 at 1:45 AM, BJ Weschke wrote: > On 11/4/14, 3:40 PM, Matthew Jordan wrote: >> >> On Tue, Nov 4, 2014 at 12:57 PM, BJ Weschke wrote: >>> >>> Matt - >>> >>> This is a pretty neat idea, indeed, but I've got some >>> questions/thoughts on >>> implementation. :-) Apologies if

Re: [asterisk-dev] Asterisk 14 - Remote URI Playback

On Wed, Nov 5, 2014 at 3:58 AM, Johan Wilfer wrote: > Den 2014-11-05 08:45, BJ Weschke skrev: >> >> >> As for the timestamps for deciding whether the local cache is dirty, I >> don't think we should try to reinvent the wheel here. We should stick >> what's already well established for stuff like

Re: [asterisk-dev] [Code Review] 4101: Channel Originate/Continue via ARI support for labels in dialplan is incomplete

> On Nov. 5, 2014, 11:43 a.m., Joshua Colp wrote: > > Matt brought it up that this is actually a backwards incompatible change - > > specifically changing priority into a string from an integer. What about > > having label as a separate argument that is optional? If present it's > > treated as

Re: [asterisk-dev] func_jitterbuffer handling of masquerades

On Wed, Nov 5, 2014 at 12:24 PM, Joshua Colp wrote: > Corey Farrell wrote: > > > >> >> The change I am proposing is that we always have an active JB after >> masquerade if either side had one before the masquerade. So in >> scenario 1 and 2 listed above this would cause the only active >> jitter

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/#review13703 --- /branches/12/include/asterisk/stasis_bridges.h

Re: [asterisk-dev] [Code Review] 4123: app_agent_pool: Make agent alert interruptable by DTMF.

--- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/4123/ --- (Updated Nov. 6, 2014, 12:55 p.m.) Status -- This change has been mar

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/ --- (Updated Nov. 6, 2014, 12:20 p.m.) Status -- This change has been mar

[asterisk-dev] [Code Review] 4155: PJSIP: Allow contact rewriting to fall back for reliable transports

--- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/4155/ --- Review request for Asterisk Developers and Joshua Colp. Bugs: ASTERISK-244

[asterisk-dev] Asterisk MoS and RTCP data [pardon the directness and language :-)]

Hi All, So, if there is one thing I really like about PJSIP and WebRTC (specifically with mobile) is the ability to produce meaningful MoS scoring for calls in real time. Now, Asterisk doesn't have that capability, at least, not during the actual call - but only after. In itself, not an issue - i

Re: [asterisk-dev] [Code Review] 4101: Channel Originate/Continue via ARI support for labels in dialplan is incomplete

> On Nov. 5, 2014, 5:43 p.m., Joshua Colp wrote: > > Matt brought it up that this is actually a backwards incompatible change - > > specifically changing priority into a string from an integer. What about > > having label as a separate argument that is optional? If present it's > > treated as

Re: [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/ --- (Updated Nov. 6, 2014, 6:10 a.m.) Status -- This change has been mark

[asterisk-dev] [Code Review] 4153: manager: HTTP connections leak references

--- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/4153/ --- Review request for Asterisk Developers. Bugs: ASTERISK-24505 https://i

Re: [asterisk-dev] [Code Review] 4151: Fix compiler error when using ./configure --enable-dev-mode --enable-coverage

> On Nov. 6, 2014, 6:04 a.m., wdoekes wrote: > > Isn't the better fix to disable coverage for the shadow compilation? Probably. I have updated code but I won't have time to test until this weekend. I'll update the review once I've had a chance to do some builds with it. - Corey -

Re: [asterisk-dev] [Code Review] 4152: chan_console: Fix reference leaks to pvt

--- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/4152/ --- (Updated Nov. 6, 2014, 6:06 a.m.) Review request for Asterisk Developers.

Re: [asterisk-dev] [Code Review] 4151: Fix compiler error when using ./configure --enable-dev-mode --enable-coverage

--- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/4151/#review13701 --- Isn't the better fix to disable coverage for the shadow compila

Re: [asterisk-dev] [Code Review] 4152: chan_console: Fix reference leaks to pvt

--- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/4152/#review13700 --- Ship it! Minor nits. /branches/11/channels/chan_console.c

[asterisk-dev] [Code Review] 4152: chan_console: Fix reference leaks to pvt

--- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/4152/ --- Review request for Asterisk Developers. Bugs: ASTERISK-24504 https://i

[asterisk-dev] [Code Review] 4151: Fix compiler error when using ./configure --enable-dev-mode --enable-coverage

--- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/4151/ --- Review request for Asterisk Developers. Bugs: ASTERISK-24502 https://i

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/ --- (Updated Nov. 6, 2014, 3:22 a.m.) Status -- This change has been mark

Re: [asterisk-dev] [Code Review] 4114: Prevent stringfields from accumulating unused memory

--- This is an automatically generated e-mail. To reply, visit: https://reviewboard.asterisk.org/r/4114/ --- (Updated Nov. 6, 2014, 3:05 a.m.) Status -- This change has been mark