Re: [asterisk-dev] Call unhold/topology change indication order

[Kevin Harwell]

On Wed, May 11, 2022 at 9:54 AM Joshua C. Colp  wrote:

> On Wed, May 11, 2022 at 11:50 AM Fridrich Maximilian <
> m.fridr...@commend.com> wrote:
>
>> > You're in off-nominal untested un thought of territory, so the code
>> behavior
>> > probably reflects that. Specifically having both audio and video, and
>> doing
>> > hold/unhold. Audio hold is special and separate from stream negotiation,
>> > while video isn't, so things probably don't handle that.
>>
>> Considering that, I would like to have a discussion about considering
>> reverting
>> ASTERISK-28783 [1]. This change showed that the handling of non-default
>> streams
>> is not mature enough yet to be used in production environments.
>> Specifically,
>> one-way streams and hold/unhold are not handled correctly. In order to
>> keep
>> Asterisk reliably usable for many different use-cases (Swiss Army Knife),
>> I
>> would suggest reverting this change for now until the handling of
>> non-default
>> streams is mature enough to handle more than just the most basic
>> use-cases.
>>
>> Please let me know what you think about this suggestion.
>>
>
> Oh, that's my change from long ago. That change has existed in the code
> base for quite a long time. It's not something that can likely just be
> reverted, and I'd be hesitant in doing so. It would also require disabling
> the test coverage for it too I think. It could also cause ripples
> elsewhere. I'd be against it.
>
> Thoughts from others?
>
> --
> Joshua C. Colp
> Asterisk Technical Lead
> Sangoma Technologies
> Check us out at www.sangoma.com and www.asterisk.org
>

I too would be hesitant in doing a straight revert of the patch. I think at
this point a new patch would be needed that fixes the newly reported bug (
ASTERISK-30051), but also maintains the current behavior of ASTERISK-28783
in some way.
-- 
_
-- 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] Doxygen \since

[Kevin Harwell]

Thanks for the feedback everyone. It seems like generally speaking using
/since Doxygen command for the C API calls is not that useful and can be
left off.

A couple you brought up version documentation for public facing user API's
and protocols (AMI, ARI, dialplan functions etc...). AMI [1] and ARI [2]
have version numbers that get updated at Asterisk release time if a change
has occurred in either one.

I do agree too that having something like a /since value documented
somewhere for things like new or altered protocols would be helpful.
Unfortunately, we don't have a way to do that at this time, but would be
open to patches or simple ideas to include such. Especially if it could be
added to the automatic generation of documentation for such things.

[1]
https://wiki.asterisk.org/wiki/display/AST/Asterisk+Manager+Interface+%28AMI%29+Changes
[2] https://wiki.asterisk.org/wiki/display/AST/ARI+Versioning

>
-- 
_
-- 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 External Application Protocol

[Kevin Harwell]

Greetings,

There has already been some good discussion about the new speech to text
stuff [1], but as things begin to solidify I want to discuss the basic
protocol some more.

We've named it the Asterisk External Application Protocol (AEAP). For this
first version of the protocol we want to ensure that it's 1) simple, 2)
adaptable, and 3) generic. To those points while speech to text will be the
first use case implemented, we're hoping if the need arises this protocol
can be used for other things.

https://wiki.asterisk.org/wiki/display/AST/Asterisk+External+Application+Protocol

After implementing a very simple external application that uses the
protocol, and reading some of the feedback from the other thread [1] I
think it could use a few minor changes:

* Only send the version in the initial "setup" request. I don't really see
a reason to send it in every message.
* In responses change "status" to a number/code. As brought up in the
previous discussion [2] this would allow for response handlers to key off
that value.
* In the "setup" and "set" responses drop the "params" field. In the
response they don't seem useful. Either they were set successfully, or they
weren't. If they weren't then an error is returned instead.

Any agreements/disagreements? Any other ideas or thoughts? Keep in mind
that for this first version minimal is better. It's easy to add a field
later if we need it vs removing an unused one.

Thanks!

[1] http://lists.digium.com/pipermail/asterisk-dev/2021-March/078244.html
[2] http://lists.digium.com/pipermail/asterisk-dev/2021-March/078258.html

-- 
Kevin Harwell
Software Developer
Sangoma Technologies
Check us out at: https://sangoma.com & https://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

[asterisk-dev] Doxygen \since

[Kevin Harwell]

Greetings,

Looking for opinions.

When documenting API calls in Asterisk one can use the Doxygen \since
command [1] to specify which version of Asterisk the function was added in.
For example: \since 13.25.0 [2]

Do folks find this helpful, and worth having? As a developer, when adding a
new API does trying to figure out what version of Asterisk things will go
in become too cumbersome?

Personally, I've found having the version number on a function only
slightly helpful. I've used that info once, maybe twice, but feel it's not
worth the upfront cost (figuring out version info at patch time for each
branch, having to update a review if it doesn't make it in before the
expected release, etc...)

So my vote is to drop its usage. Certainly though if many others find it
useful, or have a good reason to continue using the command we can.

Thoughts?

[1] https://www.doxygen.nl/manual/commands.html#cmdsince
[2]
https://github.com/asterisk/asterisk/blob/master/include/asterisk/stasis.h#L305
-- 
Kevin Harwell
Software Developer
Sangoma Technologies
Check us out at: https://sangoma.com & https://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] Deadlock in SIP processing in Asterisk 16.

[Kevin Harwell]

Response inline.

On Tue, Nov 23, 2021 at 2:06 PM Steve Sether  wrote:

> We've had a couple instances of a deadlocks recently.  This happened while
> we were trying to move phones from one Asterisk server to another.  It's
> too much to describe here what goes in in this process, but from an
> Asterisk perspective it's a lot of reloading the dialplan regenerating
> pjsip.conf, reloading pjsip, and phones re-registering to the new Asterisk
> server through a proxy.
>
> The sip freeze has happened twice now when we move upwards of 80 phones at
> a time.
>
> The second time it happened we were able to get a core dump, and run it
> through the scripts built in to Asterisk.  The output is...  voluminous.  I
> tried running the core file through a scripting tool that for gdb that
> claims to find deadlocks (and worked before), but it crashes when it's
> expecting (I think?) a certain kind of locking that it's not seeing.
>
> Mainly, I need some kind of guidance on how to find out what's locking up
> Asterisk.  I can't seem to find anything that references the locks being
> held.  i.e. I don't really know what threads are locking the others, and
> other guides in using gdb don't seem to be much help.  I'm not a C
> programmer, so I don't have much experience in semaphores, low level locks,
> etc.
>
> Can anyone provide some kind of assistance, and look through the following
> for where to look?  Something is certainly locking up our Asterisk server,
> but at the moment I'm pretty stuck.  (I have the log ending in "-full", if
> needed but posting it here seems like more of a distraction than anything
> else).
>
> I've tried to edit this file down to more unique entries, and removed
> anything that's doesn't look like it's locked so it's at least possibly
> semi-readable. There's quite a few threads that are largely duplicates
>
>
> Any help is appreciated.  Thanks.
>
>
> Thread 113 (Thread 0x7faf4deac700 (LWP 17772)):
> #0  0x7fb0d292d334 in __lll_lock_wait () from /lib64/libpthread.so.0
> #1  0x7fb0d29285f3 in _L_lock_892 () from /lib64/libpthread.so.0
> #2  0x7fb0d29284d7 in pthread_mutex_lock () from /lib64/libpthread.so.0
> #3  0x7fb093276c1b in pbx_load_module () at pbx_config.c:2091
> #4  0x7fb093276e1e in handle_cli_dialplan_reload (e= out>, cmd=, a=) at
> pbx_config.c:1597
> #5  0x004ba668 in ast_cli_command_full (uid=-1, gid=-1, fd=112,
> s=0x7fafe800d839 "dialplan reload") at cli.c:2995
> #6  0x0060213b in action_command (s=0x7faf4deabcd0,
> m=0x7faf4deab3e0) at manager.c:5318
> #7  0x00606af0 in process_message (s=0x7faf4deabcd0,
> m=0x7faf4deab3e0) at manager.c:6689
> #8  0x00609dcb in do_message (data=0x7fb034002930) at
> manager.c:6902
> #9  session_do (data=0x7fb034002930) at manager.c:7007
> #10 0x005a24b7 in dummy_start (data=) at
> utils.c:1428
>
This thread is attempting to grab the 'reload_lock' lock, but is waiting on
...

I'm going to call the 'unknown thread id'. Note, this 'unknown thread id'
is missing some of the stack trace, but will still try to make an educated
guess.

> --
> #7  0x005137b0 in execute_state_callback (cb=0x5fa500
> , context=0x7faf703f3f88 "blf-danielBarnes126266",
> exten=0x7faf703f4118 "danielBarnes126266-user1", data=0x0, reason= optimized out>, hint=0x7faf
> 703f4600, device_state_info=0x0) at pbx.c:3284
> #8  0x005169d6 in ast_add_hint (e=0x7faf703f4080) at pbx.c:4057
> #9  0x00521c53 in ast_add_extension2_lockopt (con=0x7faf703f3e90,
> replace=0, extension=, priority=-1, label= optimized out>, callerid=, application= optimized out>, data
> =0x7faf703f4060, datad=0x45bdd0 , registrar=0x7fb09327b9b8
> "pbx_config", registrar_file=0x7faf70091221
> "exec.1636994706829225.140397385758464", registrar_line=1218,
> lock_context=1) at pbx.c:7572
> #10 0x005224da in ast_add_extension2 (con=,
> replace=, extension=,
> priority=, label=,
> callerid=, a
> pplication=0x7faf703f3fee
> "PJSIP/xxx:unavailable:call_state_xxx",
> data=0x7faf703f4060, datad=0x45bdd0 ,
> registrar=0x7fb09327b9b8 "pbx_config", registrar_f
> ile=0x7faf70091221 "exec.1636994706829225.140397385758464",
> registrar_line=1218) at pbx.c:7304
> #11 0x7fb09327641b in pbx_load_config (config_file=0x7fb09327b9e0
> "extensions.conf") at pbx_config.c:1890
> #12 0x7fb093276c2e in pbx_load_module () at pbx_config.c:2101
> #13 0x7fb093276e1e in handle_cli_dialplan_reload (e= out>, cmd=, a=) at
> pbx_config.c:1597
> #14 0x004ba668 in ast_cli_command_full (uid=-1, gid=-1, fd=106,
> s=0x7faf7f39 "dialplan reload") at cli.c:2995
> #15 0x0060213b in action_command (s=0x7fb0d04e2cd0,
> m=0x7fb0d04e23e0) at manager.c:5318
> #16 0x00606af0 in process_message (s=0x7fb0d04e2cd0,
> m=0x7fb0d04e23e0) at manager.c:6689
> #17 0x00609dcb in do_message (data=0x7fb034005820) at
> manager.c:6902
> #18 session_do (data=0x7fb034005820) at manager.c:7007
> #19 0x005a24b7 in 

Re: [asterisk-dev] Packet Loss Concealment in confbridge

[Kevin Harwell]

I can't speak much directly about the confbridge packet loss scenario, but
can talk a bit about OPUS. No guarantees it'll be helpful to this
situation, or not information you don't already know :-)

Most folks will want to leave codec OPUS alone, and let it do its thing.
Meaning, OPUS is pretty good at automatically adjusting itself to a given
situation. However, it does have some options, mostly encoder side, that
one can configure if needed, or desired. Note though, the setting of some
these options is more along the lines of making a recommendation to the
encoder/decoder vs telling it exactly what to do. Also, it can be a
balancing act when doing so. A gain in one direction may be a loss in
another. For example, setting a higher 'complexity' value will probably
result in more CPU utilization.

Now on to OPUS and packet loss. With nothing configured OPUS _should_
default to doing native PLC when packet loss is detected. FEC can also help
in a packet loss situation, but it's a little more complicated when, and
how that occurs. Enabling FEC does not necessarily mean it's being
utilized. For instance, in order for FEC data to be decoded by Sangoma's
codec_opus module for Asterisk several things must occur:

1) it must be enabled through configuration
2) both sides of a call must negotiate for it (via SDP)
3) packet loss must be perceived by the codec_opus module
4) a frame containing FEC data is received

Similarly, several conditions apply as to whether or not FEC data is
encoded:

1) it must be enabled through configuration
2) both sides of a call must negotiate for it (via SDP)
3) the encoder must be told to expect packet loss
4) the codec must be operating in a mode conducive to lower bandwidths.

More details below ...

On Wed, Oct 20, 2021 at 1:27 PM Pascal Cadotte  wrote:

> Thank you for taking the time to look into this and reply. It is very
> appreciated.
>
> I've done some more testing to get as few variables as possible from the
> tests I'm doing. This time around I've disable genericplc in codecs.conf to
> check the results from the opus fec option. With two users using the opus
> codec. When using the Dial application a 10% packet loss yields a decent
> audio quality. When using the Confbridge application the audio is VERY
> degraded.
>

In the non Confbridge scenario is transcoding occuring? If not then
Asterisk is simply passing through the audio frames, which may account for
some of the improved audio quality. Try forcing a transcode scenario
between two legs of a call and see if the audio sounds better or worse. Any
options set for codec_opus are only utilized while encoding or decoding.


>
> I've added JITTERBUFFER to all channels and added the option to the
> confbridge bridge.
> I've configured opus with fec=yes and have tried packet_loss=0 and
> packet_loss=50 with no difference in sound quality.
>

The 'packet_loss' option is an encoder side only option used in conjunction
with the 'fec' option. Setting the 'packet_loss' option adjusts an internal
threshold as to when the OPUS encoder should include FEC data in an encoded
frame. The higher the expected 'packet_loss' value the lower the threshold.


> I've used the following command on the laptop running one of the softphone
> to simulate packet loss
> sudo tc qdisc add dev enp0s31f6 root netem delay 2000ms 100ms 10%
> distribution normal
>
> Would I be able to dig deeper into this problem with the Asterisk sources
> only or does it sound like a problem in the codec implementation?
>

 It's hard to tell at this point. If you haven't already done so I'd try
the following:

* Use a different codec in the Confbridge scenario, and see how it
compares. For instance, if you swap opus for ulaw does it sound worse,
better, about the same?
* Next using only the default configuration forcodec_opus. Does it sound
better than the ulaw scenario?
* Enable FEC for codec_opus. Does it sound better, worse, the same?
* If worse or the same, then ensure both sides negotiated for it.
Ensure/force the encoder into a lower bandwidth mode by setting the
'max_bandwidth' option to narrow or medium, or set the 'max_playback_rate'
option to 16khz or less. Ensure the 'packet_loss' option is also
appropriately set (might just try 100, and if things improve then work
down).
* Enable the jitter buffer (Can try this option before enabling FEC as well
if you want)

If after all of that you're still having issues then try to find out if the
problem is occuring on the encoding or decoding side of things. Not sure if
this would work, but to check this you could try recording the Confbridge,
or perhaps "spy" on the incoming (decoding) side. I believe in the
recording scenario the Confbridge should write to the file after decoding,
but before encoding. So you should be able to listen to the recording to
see how the decoded audio sounds.

As far as looking at Asterisk sources, and if you're interested in how it
might all work, or not work then I'd start in 

Re: [asterisk-dev] Asterisk 16 deadlock (maybe in AMI) stops responding to SIP

[Kevin Harwell]

On Mon, Oct 4, 2021 at 4:36 PM Steve Sether  wrote:

>
> We're running  Asterisk certified/16.8-cert5
>
> I looked through the changelog for the cert versions 6 - 11, but didn't
> see this fix ported to this branch.  Did I miss something, or has this fix
> just not been back-ported yet?
>
You did not miss anything. The patch for that issue is not in Certified
Asterisk 16.8, cert5 or even cert11 (currently released version).


> On Mon, Oct 4, 2021 at 11:12 AM Steve Sether 
> wrote:
>
> > We've been running Asterisk 16 in a production environment for several
> > months.  During this time we've had several times where Asterisk locks
> up,
> > and stops responding to SIP messages and won't recover until Asterisk is
> > restarted.  RTP passes through, so existing conversations aren't
> affected,
> > but no new calls can be made.
> >
>
> What version of Asterisk? Cause there was already an issue[1] that was
> fixed for such things.
>
> [1] https://issues.asterisk.org/jira/browse/ASTERISK-29155
>
> --
> Joshua C. Colp
> Asterisk Technical Lead
> Sangoma Technologies
> Check us out at www.sangoma.com and www.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] Detecting B-leg channels

[Kevin Harwell]

What's the overall scenario you are trying to solve? Perhaps there is
another way to do what you want to do without even modifying Asterisk code?
For example, maybe this is something an ARI application could handle, or
even straight dialplan using a combination of app_dial, pre-dial handlers,
and such.

On Mon, Aug 23, 2021 at 5:29 AM Nikša Baldun  wrote:

> Hello,
>
> I am trying to modify bridge.c (function ast_bridge_transfer_attended)
> in order to send channels involved in SIP attended transfer to the
> dialplan. If both transferee and transfer target are bridged, that is
> relatively easy. However, if transfer target is ringing, I don't know
> how to find B-leg channels (there could be multiple, I suppose). So the
> question is, having a reference to A-leg channel, how to obtain a list
> of B-leg channels?
>
> Best 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
-- 
_
-- 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 19: res_adsi built although deprecated?

[Kevin Harwell]

On Mon, Aug 23, 2021 at 12:24 PM Dan Jenkins  wrote:

> Based on
> https://wiki.asterisk.org/wiki/display/AST/Module+Deprecation I think
> you’re right when you say it shouldn’t be built by default
>
> On Mon, 23 Aug 2021 at 15:15, Alexander Traud 
> wrote:
>
>> While creating a minimal installation of the upcoming Asterisk 19 with
>>
>> ./configure
>> make full
>> sudo make install samples config
>>
>> many notices, warnings and even errors pop up on start. Still too many
>> and they get more. For example, the module res_adsi is built on default
>> although it is deprecated. That creates several error messages alone.
>>
>> Is it intended that this module is built?
>>
>>
I agree with Dan and the wiki. It should not be default enabled. Please
create an issue for this on the tracker [1].

[1] https://issues.asterisk.org/

Thanks!
-- 
_
-- 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] =?UTF-8?B?44CQcmVzX3Bqc2lwX3JlZ2lzdHJhcg==?=.c: Error】

[Kevin Harwell]

On Wed, Dec 9, 2020 at 7:55 AM Alexander Traud 
wrote:

> > pj_strcspn2
>
> The fix for <https://issues.asterisk.org/jira/browse/ASTERISK-28641>
> raised the required version of the PJ Project to 2.6, see [1]:
> A) go for an external PJ Project, like 2.10
> B) go for ./configure --with-pjproject-bundled, see [2]
> C) reverse the change for ASTERISK-28641, see [3]
> D) go for Asterisk 13.29 or older
>
> Is B an alternative for you? If not, why?
> Is A an alternative for you? If not, why?
>
> @Asterisk Team
> The Wiki [4] states not 2.6 but 2.4 as minimum. Change the wiki or the
> source code?
>

I don't think it makes sense for us to continue to maintain compatibility
with older (too old?) versions of pjproject. As such I have updated the
wiki page, and do not feel the source code needs to be altered.


>
> [1] <
> https://github.com/pjsip/pjproject/commit/e03e14b7f1e0ff50964b14ba57583a71e793248b
> >
> [2] <
> https://www.asterisk.org/asterisk-13-8-0-now-easier-pjsip-install-method/>
> [3] <
> https://github.com/asterisk/asterisk/commit/1750847fc05eee9630eeea957658165021a6ad28.patch
> >
> [4] <https://wiki.asterisk.org/wiki/display/AST/PJSIP-pjproject>
>
>
>
> --
> _
> -- 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



-- 
Kevin Harwell
Software Developer
Sangoma Technologies
Check us out at: https://sangoma.com & https://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] Proposal for New Major Version Process Change

[Kevin Harwell]

+1

I would also would approve of other potential changes to releases and the
release process but will save that for another time :-D

On Wed, Jul 8, 2020 at 7:21 AM Joshua C. Colp  wrote:

> Greetings all,
>
> I've given this some thought in the past and thought with the impending
> branching of Asterisk 18 I'd get some input on a change to the process. The
> new major version process has evolved over time but hasn't really been
> changed lately. Let's look at what it is like in practice today:
>
> On July 15th under current process both the 18 branch and 18.0 branches
> will be cut. The 18 branch will continue to receive all bug fixes, but the
> 18.0 branch will only receive changes as a result of issues found through
> testing 18.0 or through big fixes to new functionality in it. This means
> that when 18.0.0 is actually released it is generally a few months behind.
> In the past this was to give it time to stabilize as it were. This presents
> the following issues:
>
> 1. It leaves a confusing area for developers where we have to ask "should
> this go into 18.0?"
> 2. It confuses users because if they upgrade to 18.0.0 then it is likely
> the other current releases have bug fixes they don't have, which has caused
> issues for users in the past.
>
> I don't think this is the best situation for either.
>
> I'd like to propose that instead of cutting the 18.0 branch on July 15th
> we simply cut the 18 branch, and that it continues to receive all bug
> fixes. Approximately a month before a target release of 18.0.0 we create
> the first release candidate, 18.0.0-rc1. At this time we also create
> release candidates of the other branches. All release candidates will then
> be left available for a prolonged period of time to give people ample time
> to test. On the release date all will be released, ensuring that all
> branches including 18 have the same set of bug fixes as appropriate to
> their version.
>
> This removes the confusion for developers over whether to include a fix,
> since the 18.0 branch won't exist until rc1 at which point normal cherry
> pick rules apply. This also eliminates the confusion experienced by users
> since all releases will be on the same page at the same time at release.
>
> What do people think? Do we believe that a month out is ample enough? The
> 18 branch itself will exist, so that can be used for early testing (and
> likely will be). If a month isn't enough it could be moved out further.
> Really I think thanks to the testing that happens and the code review I
> don't think we need as long of a stabilization period as has been needed in
> the past, so this helps shrink it.
>
> Cheers,
>
> --
> Joshua C. Colp
> Asterisk Technical Lead
> Sangoma Technologies
> Check us out at www.sangoma.com and www.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



-- 
Kevin Harwell
Software Developer
Sangoma Technologies
Check us out at: https://sangoma.com & https://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

[asterisk-dev] PJSIP_MEDIA_OFFER

[Kevin Harwell]

Greetings,

PJSIP_MEDIA_OFFER [1] has been around for a while now, but the
documentation is a little ambiguous. Is the expectation that codecs set via
the PJSIP_MEDIA_OFFER function completely override those specified on an
endpoint's configuration? For instance:

Endpoint config: allow=!all,ulaw
Dialplan override: Set(PJSIP_MEDIA_OFFER(audio)=!all,g722)

Then the outgoing SDP would contain g722 only.

I'm asking because that is not the way it works now. Given the above
scenario the outgoing SDP contains ulaw only. Currently, the code only
allows codecs set via PJSIP_MEDIA_OFFER to be included in the SDP only if
the given codec list has at least one codec in common with the codecs
specified in the configuration.

I'm not sure if setting codecs using PJSIP_MEDIA_OFFER should completely
override the configuration, but the way it seems to be currently working
doesn't seem right either.

So thoughts, ideas, and/or expectations on how it should work?

[1]
https://wiki.asterisk.org/wiki/display/AST/Asterisk+16+Function_PJSIP_MEDIA_OFFER

-- 
Kevin Harwell
Software Developer
Sangoma Technologies
Check us out at: https://sangoma.com & https://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] Pjsip aor with multiple contacts

[Kevin Harwell]

On Mon, Apr 27, 2020 at 5:49 AM Learn  wrote:

> Hi guys,
>
> sorry just a simple question which i can’t find an answer online.. if i
> have multiple contacts listed in one aor section in pjsip.conf and have
> quality on which of the contacts will be used if both contacts are
> reachable?
>
> ie:
> [trunk]
> type = aor
> contact = sip:t...@domain1.com:5061
> contact = sip:t...@domain2.com:5061
> qualify-frequency = 30
>
> is it round-robin, random, in the order of the config file or the lowest
> RTT?
>

It's semi-random.

>From what I can tell it appears it will choose the "first" reachable
contact (includes dynamic and static contacts) it knows about. I put
"first" in quotes though because the contacts are put into an unsorted
container, and then the "first" reachable contact in the container is used.
So depending on how a particular contact is hashed, and stored in the
container affects its location in said container.

If all you have are static contacts then the same one should be chosen each
time. However when including dynamic contacts it's possible (once
registered, and reachable) it could become the one used.


>
> cheers,
>
> Roland
>
>
-- 
Kevin Harwell
Software Developer
Sangoma Technologies
Check us out at: https://sangoma.com & https://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] ARI Text messaging : inconsistencies in the API ?

[Kevin Harwell]

On Wed, Feb 26, 2020 at 1:12 AM Jean Aunis  wrote:

> Le 25/02/2020 à 19:09, Kevin Harwell a écrit :
>
> 
>
>
> I could never get (2). When trying to send variables in the
> TextMessageReceived event I would get a validation error unless they are
> formatted like (3).
>
> (3) is the currently declared documented way to to it. As such any other
> way breaks the API definition. However, when executing a sendMessage (1) is
> the way it is currently working, so I'd be worried about breaking current
> implementations if we altered it to (3) for that case.
>
> So what to do?
>
> Option A: Leave sendMessage as is (1), update the documentation for it,
> and fix TextMessageReceived to send variables as defined like (3). Least
> breaking, but inconsistent way of sending and receiving variables.
>
> Option B: Update sendMessage to pass a TextMessageVariable like (3), and
> fix TextMessageReceived to send variables like (3). The current API
> definition doesn't change, but may break implementations.
>
> Option C: Leave sendMessage as is (1), update the TextMessageVariable API
> definition to be similar to (1), e.g { "var name": "var value" }, and not {
> "key": "var name", "value": "var value" }. This of course breaks the
> current API definition, and would break implementations if the validation
> error did not occur.
>
> While "A" is the safest (least breaking?), personally, I prefer and choose
> "C". While it does break the API it seemingly has not worked since the
> start so I don't think this will break any current implementations. It will
> also make sending and receiving variables more consistent.
>
> Thoughts?
>
> I agree with option "C".
>

Went ahead and went with option "C" [1].

[1] https://gerrit.asterisk.org/c/asterisk/+/13843

-- 
Kevin Harwell
Software Developer
Sangoma Technologies
Check us out at: https://sangoma.com & https://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] ARI Text messaging : inconsistencies in the API ?

[Kevin Harwell]

On Tue, Feb 25, 2020 at 4:43 AM Jean Aunis  wrote:

> Hello,
>
> I recently opened a issue regarding SIP headers handling in inbound
> messages (https://issues.asterisk.org/jira/browse/ASTERISK-28755).
>
> Besides that problem, I think there are inconsistencies in the data format
> provided by ARI for sending or receiving text messages, and also in the
> documentation. Actually there are 3 different data formats for message
> variables:
>
> 1- to send a message, additional variables may be provided in a
> "variables" field. Its value must be a JSON object whose keys are the
> variable names, and values are the variable values, i.e:
>
> ...
> "variables": { "My-Custom-Header": "the_value", "Another-header":
> "another_value" }
>
> 2- when a message is received, a TextMessageReceived is emitted, which
> contains a TextMessage which then contains a "variable" field. This field
> is a list of JSON objects, each one containing a single key (the variable
> name) with its value :
>
> ...
> "variables": [{ "My-Custom-Header": "the_value" }, { "Another-header":
> "another_value" }]
>
> (This is what I saw after quick-fixing the issue stated above)
>
> 3- the behaviour described in (2) is not consistent with the ARI
> documentation, which states:
>
> TextMessageVariable: A key/value pair variable in a text message.
>
> key: string - A unique key identifying the variable.
> value: string - The value of the variable.
>
> So I would expect the variable field to look like the following:
>
> ...
> "variables": [{ "key": "My-Custom-Header", "value": "the_value" }, {
> "key": "Another-header", "value": "another_value" }]
>
> I personally think formats (1) and (3) both make sense, but I find format
> (2) not very practical to use. Any thoughts on the subject ?
>
I could never get (2). When trying to send variables in the
TextMessageReceived event I would get a validation error unless they are
formatted like (3).

(3) is the currently declared documented way to to it. As such any other
way breaks the API definition. However, when executing a sendMessage (1) is
the way it is currently working, so I'd be worried about breaking current
implementations if we altered it to (3) for that case.

So what to do?

Option A: Leave sendMessage as is (1), update the documentation for it, and
fix TextMessageReceived to send variables as defined like (3). Least
breaking, but inconsistent way of sending and receiving variables.

Option B: Update sendMessage to pass a TextMessageVariable like (3), and
fix TextMessageReceived to send variables like (3). The current API
definition doesn't change, but may break implementations.

Option C: Leave sendMessage as is (1), update the TextMessageVariable API
definition to be similar to (1), e.g { "var name": "var value" }, and not {
"key": "var name", "value": "var value" }. This of course breaks the
current API definition, and would break implementations if the validation
error did not occur.

While "A" is the safest (least breaking?), personally, I prefer and choose
"C". While it does break the API it seemingly has not worked since the
start so I don't think this will break any current implementations. It will
also make sending and receiving variables more consistent.

Thoughts?

-- 
Kevin Harwell
Software Developer
Sangoma Technologies
Check us out at: https://sangoma.com & https://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 18 Planning: Codec Negotiation

[Kevin Harwell]

On Fri, Jan 31, 2020 at 1:06 AM Michael Maier  wrote:

> On 30.01.20 at 23:20 Kevin Harwell wrote:
> ...
> > No worries it's my bad. I can see how what I wrote was ambiguous. What I
> > meant was "if *either* remote *or* local is chosen". As in it doesn't
> > matter which option value you choose. Either one would result (in this
> > example) in opus not being included in list 2.
>
> Hmm, that's how I understood it - but I still can't see any possibility
> to not provide either remote or local value. Therefore I can't see any
> possibility to ever get opus in your given example above to the
> resulting list 2. But that would be ok anyway, because I don't ever want
> to have opus in the list in this specific case.
>

That's correct. A local or remote value, or some derivative of them
(_single/_limit), will always be specified. And opus will never be included
in list 2.


>
> Could you please tell me, how outgoing_sdp_send_prefs can be used
> *without* any active "value" (like local, local_limit, local_single,
> remote, remote_limit, remote_single) as long as *remote* is
> automatically used ("default") according documentation if no other value
> is provided? This would be the same for all other lists, too.
>
>
> From documentation:
> --
> remote - Order by what is optionally given by a "caller". Note, the
> resulting list will contain those codecs specified by Bob's
> configuration, which are not found also in the given remote list, as
> least preferred. Meaning they will be at the end, or bottom of the list
> (*default*)
> --
>
>
For any of the options a value can be specified by the user (e.g. local,
remote, local_single, etc...). If no value is specified then the default
value for that option is used. From the code's perspective there will never
be a case for outgoing_sdp_send_prefs, or any of the other options, where
one of its legal values is not always set for it. Either specified by the
user in the configuration, or using it uses the default.

So for example in the case of outgoing_sdp_send_prefs there is no way it
can be used *without* any active "value". It's impossible. Within the
code outgoing_sdp_send_prefs will always be set to one of its values.

-- 
Kevin Harwell
Senior Software Developer
Sangoma Technologies
Check us out at: https://sangoma.com & https://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] AMD

[Kevin Harwell]

On Thu, Jan 30, 2020 at 2:58 PM i...@magnussolution.com <
i...@magnussolution.com> wrote:

> in my country when I dial to a mobile and I not answer the call, the call
> going to the voicemail, but the audio is executed before the 200OK, on 183
> early media.
>
> so, I need to execute the AMD when I receive the 183, not the 200 OK.
>

Unfortunately I am unaware of any easy solution.

Something to be aware of if you are not. From what I understand app_dial is
reading the frames from the channel. Any solution that attempts to also
read frames from the same channel at the same time is going to run into
problems. So for instance, you can't execute app_dial and app_amd at the
same time.

If you wish to inject some kind of audio listening, and detection
algorithms while dialing you'll have to do that within the confines of the
dial application. Basically, while app_dial is waiting for the other side
to answer it's processing frames. When an audio frame is received then that
is where you'll want to do your detection. Also once answered you'll need
to continue processing incoming audio frames. Maybe you are already doing
all of this?

If that's the case then if a hangup occurs app_dial will automatically
handle what you need since it will detect the hangup and stop reading
frames, which in turn means audio will not get passed down into your
detection checks anymore. There is no loop to break out of since the dial
application is handing that for you (reading of frames, etc.).

-- 
Kevin Harwell
Senior Software Developer
Sangoma Technologies
Check us out at: https://sangoma.com & https://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 18 Planning: Codec Negotiation

[Kevin Harwell]

On Thu, Jan 30, 2020 at 3:01 PM Michael Maier  wrote:

> .
> >> 2. outgoing_sdp_send_prefs
> >>The list can be created on base of the callees
> >>allow line and list 1 (option local ...).
> >>
> >>Or:
> >>
> >>The list can be created on base of list 1
> >>(option remote ...) and the callees allow line.
> >>
> >>Both lists may have a different codec order or
> >>different codecs (if *_single is provided).
> >>
> >>Codecs not given in the callees allow line or
> >>list 1 are dropped (*_limit).
> >>
> >>
> > This is mostly correct, but for clarification selecting the "remote" or
> > "local" value will always only contain those codecs from the endpoint
> > configuration allow line. Or another way to say it is the resulting list
> is
> > the intersection of the two lists (list 1 and allow=) plus the codecs in
> > the allow line that are not in list 1. The order will change depending on
> > which value is used.
> >
> > This means that if list 1 contains a codec not found in the endpoints
> > allow= line then that codec will not be included in the resulting list.
> For
> > example;
> >
> > list 1 = opus,ulaw,alaw
> > allow= ulaw, alaw, g722
> >
> > Then if "remote" or "local" is chosen then the resulting list will never
> > have opus in it.
>
> Sorry, I don't understand at the moment, how it is possible to *not*
> choose "remote" or "local". According to your documentation, "remote" is
> the default if you don't provide any option to outgoing_sdp_send_prefs.
> Maybe I missunderstood some more ... .
>

No worries it's my bad. I can see how what I wrote was ambiguous. What I
meant was "if *either* remote *or* local is chosen". As in it doesn't
matter which option value you choose. Either one would result (in this
example) in opus not being included in list 2.

-- 
Kevin Harwell
Senior Software Developer
Sangoma Technologies
Check us out at: https://sangoma.com & https://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] AMD

[Kevin Harwell]

On Thu, Jan 30, 2020 at 1:04 PM i...@magnussolution.com <
i...@magnussolution.com> wrote:

> Hi Kevin, thanks for your help
>
> I’ll to try your recommendation and send you the feedback.
>
> There is any existent method to execute AMD on the 183?
>

I'm not sure. If you can please describe the overall scenario you are
trying to implement, or the problem you are trying to solve. With a bigger
picture of what you are trying to do someone might be able to point you in
a direction.

-- 
Kevin Harwell
Senior Software Developer
Sangoma Technologies
Check us out at: https://sangoma.com & https://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] AMD

[Kevin Harwell]

On Wed, Jan 29, 2020 at 3:07 PM i...@magnussolution.com <
i...@magnussolution.com> wrote:

> Hello
>
> I’m to try execute AMD on the 183 signalisation, to detect audio on early
> media.
>
>
> I’m work in  app_dial.c and it work ok when the audio start on the
> beginner, but when keep ringing I need to continue analyse until receive
> the 200 OK or some error. I already do it
>
> but, always there a but, when the call is canceled I need to stop the
> whatfor() method.
>
>
> while ((res = ast_waitfor(chan, 2 * maxWaitTimeForFrame)) > -1) {
> //here is where I analise the 183
>
> /* this code check the chan status to break the while()*/
> if (ast_channel_state(chan) != 5) {
>  ast_verb(1,"status channel answere %d
> \n",ast_channel_state(chan));
>  ast_frfree(f);
> break;
>  }
>
> }
>
>
> there are any method to check if the originate channel CANCEL the call?
>
>
Looking through the app_dial code it looks like the peerflags gets set upon
hangup. If you can get access to that (not sure where your code is located)
then you should be able to check the OPT_CALLER_HANGUP value for that.

Another alternative maybe is the hangupcause as it gets set on the channel
too when hung up so you might be able to retrieve that and check it for
some value, but not sure if the causes will give you what you need.

A third way is to check if the channel hung up using the "ast_check_hangup"
or "ast_check_hangup_locked" function (maybe the best option?).

-- 
Kevin Harwell
Senior Software Developer
Sangoma Technologies
Check us out at: https://sangoma.com & https://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 18 Planning: Codec Negotiation

[Kevin Harwell]

On Thu, Jan 30, 2020 at 4:55 AM Michael Maier  wrote:

> 
>
> Could the planned codec handling globally described like this:
>
>
Overall I think you have the gist of it. See below, though, for a couple of
clarifications.


>
> The codec handling is based on 4 lists.
>
> 1. incoming_sdp_receive_prefs
>This list is created based on the allow line
>of the callers extension and the SDP offer of
>the phone (local ...).
>
>Or:
>
>This list is created based on the SDP offer of
>the caller and the allow line of the extension
>(remote).
>
>Codecs not given in the callers allow line are
>dropped. Both list variants may have a
>different codec order.
>
>
> 2. outgoing_sdp_send_prefs
>The list can be created on base of the callees
>allow line and list 1 (option local ...).
>
>Or:
>
>The list can be created on base of list 1
>(option remote ...) and the callees allow line.
>
>Both lists may have a different codec order or
>different codecs (if *_single is provided).
>
>Codecs not given in the callees allow line or
>list 1 are dropped (*_limit).
>
>
This is mostly correct, but for clarification selecting the "remote" or
"local" value will always only contain those codecs from the endpoint
configuration allow line. Or another way to say it is the resulting list is
the intersection of the two lists (list 1 and allow=) plus the codecs in
the allow line that are not in list 1. The order will change depending on
which value is used.

This means that if list 1 contains a codec not found in the endpoints
allow= line then that codec will not be included in the resulting list. For
example;

list 1 = opus,ulaw,alaw
allow= ulaw, alaw, g722

Then if "remote" or "local" is chosen then the resulting list will never
have opus in it. Unless for some reason folks think it would make sense to
make an offer to a device containing codec(s) that were not part of its
Asterisk endpoint configuration definition.


>
> 3. outgoing_sdp_receive_prefs
>The list is created based on the received SDP
>and list 2 (remote ...).
>
>Or:
>
>The list is based on list 2 and the received
>SDP.
>
>These list variants may provide different codec
>orders or different codecs (if *_single is
>provided).
>
>This list only contains codecs which can be
>found in the received SDP and in list 2 at the
>same time.
>
>
> 4. incoming_sdp_send_prefs
>This list is created based on list 3 and 1
>(remote ...)
>
>Or
>
>the list is based on 1 and 3 (local ...).
>
>The Codec order may differ between those
>variants.
>
>This list only contains codecs which can be
>found in list 3 and 1 at the same time
>(*_limit).
>
>
Again this is mostly the case, but pretty much the same description from
above applies here too, i.e. the resulting list will never have codecs in
it that were not part of list 1.

-- 
Kevin Harwell
Senior Software Developer
Sangoma Technologies
Check us out at: https://sangoma.com & https://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 18 Planning: Codec Negotiation

[Kevin Harwell]

Ugh I used the wrong keyboard shortcuts and the message sent before I was
done. Below is the rest :-)

On Wed, Jan 29, 2020 at 3:42 PM Kevin Harwell  wrote:

> On Wed, Jan 29, 2020 at 3:12 PM Michael Maier 
> wrote:
>
>>
>>
>
>> 
>>
>> From my point of view, it should always be possible to prevent
>> transcoding as long as there is one codec which can be used on both
>> sides. If there is more than one codec equal on both sides, it's good to
>> have the possibility by your planned options if the local or the remote
>> most preferred codec should be used.
>>
>> Default configuration for me would be like that:
>> incoming_sdp_receive_prefs=local
>> outgoing_sdp_send_prefs=remote
>> outgoing_sdp_receive_prefs=local
>> incoming_sdp_send_prefs=local
>> transcode=avoid
>>
>> From my understanding, this should avoid any unnecessary transcoding as
>> long as there's just one common codec on both sides and should always
>> prefer the codecs desired by the caller.
>>
>> Did I got this correctly?
>>
>
> We're still working through the idea of the "transcode" option, and how it
> might work in practice. But what you have is the general idea. To better
> avoid it, in the setup you have above I'd probably modify the following:
>

incoming_sdp_send_prefs=remote

This would send in the answer to Alice the exact order preferred by Bob. If
Alice accepts then Asterisk should never transcode.

-- 
Kevin Harwell
Senior Software Developer
Sangoma Technologies
Check us out at: https://sangoma.com & https://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 18 Planning: Codec Negotiation

[Kevin Harwell]

On Wed, Jan 29, 2020 at 3:12 PM Michael Maier  wrote:

> 
>
> Will Asterisk 18 be a LTS version?
>

I'll defer the answer to that question to others :-)


> 
>
> From my point of view, it should always be possible to prevent
> transcoding as long as there is one codec which can be used on both
> sides. If there is more than one codec equal on both sides, it's good to
> have the possibility by your planned options if the local or the remote
> most preferred codec should be used.
>
> Default configuration for me would be like that:
> incoming_sdp_receive_prefs=local
> outgoing_sdp_send_prefs=remote
> outgoing_sdp_receive_prefs=local
> incoming_sdp_send_prefs=local
> transcode=avoid
>
> From my understanding, this should avoid any unnecessary transcoding as
> long as there's just one common codec on both sides and should always
> prefer the codecs desired by the caller.
>
> Did I got this correctly?
>

We're still working through the idea of the "transcode" option, and how it
might work in practice. But what you have is the general idea. To better
avoid it in the setup you have above I'd probably modify the following:



-- 
Kevin Harwell
Senior Software Developer
Sangoma Technologies
Check us out at: https://sangoma.com & https://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

[asterisk-dev] Asterisk 18 Planning: Codec Negotiation

[Kevin Harwell]

Greetings!

Over the years there have been numerous requests to improve the codec
negotiation process in Asterisk. Specifically, regarding what codecs are
offered, in what order, how Asterisk chooses which codec(s) to use, and of
course how transcoding is affected by that.

Well hopefully that wait will soon be over. Currently we have plans to work
on this for Asterisk 18. The bulk of that work will be around the addition
of new chan_pjsip options that will allow a user to better control codec
offerings, and order.

I've added a page to the wiki [1] beneath the Asterisk 18 roadmap page that
explains what those options are (along with a couple current codec related
ones), and how they will work. Please, if you have any interest in this
topic read through that page and let us know what you think, or how things
can be improved.

[1] https://wiki.asterisk.org/wiki/display/AST/Codec+Negotiation

Thanks!
-- 
Kevin Harwell
Senior Software Developer
Sangoma Technologies
Check us out at: https://sangoma.com & https://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] acl.c - option to turn off logging

[Kevin Harwell]

On Wed, Dec 4, 2019 at 5:05 AM Joshua C. Colp  wrote:

> On Wed, Dec 4, 2019 at 5:05 AM Jaco Kroon  wrote:
>
>> Hi All,
>>
>> In ast_apply_acl (main/acl.c) there is two lines that's issuing a
>> LOG_WARNING when an ACL gets denied.
>>
>> The first happens if the ACL is invalid.  I'm not too worried about this
>> specific one, it's probably a good thing if this gets logged always.
>>
>> The latter, in the case of AST_SENSE_DENY is a bit problematic for me.
>> I've submitted patches now to use ACLs in res_rtp_asterisk, and with large
>> number of rejects this can quickly spam the logs, and frankly, confuse
>> consumers.
>>
>> As I see it, there are two possible solutions:
>>
>> Solution 1:
>>
>> 1.  Add AST_SENSE_INVALID as a possible return.
>> 2.  Rename the current function to ast_apply_acl_(silent|nolog), and
>> remove the logging.
>> 3.  Add a replacement ast_apply_acl function which will generate the log
>> entries as per current.
>>
>> Solution 2:
>>
>> Simply don't log at all if the purpose argument is NULL.
>>
>> Solution two is the simpler fix, but it's probably also the less ideal
>> one.
>>
>> The adding of the AST_SENSE_INVALID will also mean that the replacement
>> function will need to rewrite AST_SENSE_INVALID => AST_SENSE_DENY, or we
>> need to audit all consumers of the function (there fortunately isn't a
>> great many of these) and wherever ast_apply_acl(...) == AST_SENSE_DENY is
>> found, it should be rewritten as ast_apply_acl(...) != AST_SENSE_ALLOW.
>>
>> Would dearly like some opinions on the matter.
>>
>> PS:  The advantage for me on using ACL over HA is simply the named ACL
>> functionality, so in rtp.conf I can state ice_acl = named_acl instead of
>> having to embed the ACL into rtp.conf
>>
>
> I would prefer #1 however the existing function should behave as it does
> now. Each consumer should not need to be touched, unless they are to be
> switched to silent. We have an obligation to maintain ABI and behavior of
> API functions as best we can in case there are any outside consumers as
> well.
>

Unfortunately due to how consumer possibly use of the current return value
I think the only way to handle this is with #2. Or well by adding another
function ast_apply_acl_silent, and removing the logging that is. Your new
changes could call this function, and nothing else would be potentially
affected.

-- 
Kevin Harwell
Senior Software Developer
Sangoma Technologies
Check us out at: https://sangoma.com & https://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] Memory leak since Asterisk 16.5.x / pjsip

[Kevin Harwell]

Actually can you create a new issue for this on the issue tracker. As well
included the following:

Has anything else changed? For instance was openssl upgraded between then
too?

Speaking of which, what version of openssl is installed? As well what OS,
and version?

I assume before downgrading you were using the bundled version of Asterisk?
When you downgraded to pjproject 2.8 did you also install the patches that
had been included with Asterisk for 2.8 that were under the
"third-party/pjproject/patches/" directory?

Lastly, can you attach the config_site.h you used and the ./configure
command you used when configuring/building pjproject 2.8.

Thanks!

On Sun, Sep 15, 2019 at 12:23 AM Michael Maier  wrote:

> Hello!
>
> Since Asterisk 16.5.x (without any additional patch at all), I' m seeing
> continuously rising memory consumption each hour even if there where no
> calls at all. It's about
> 792 kbytes (RSS) each hour (3 SIPS / TLS 1.2 trunks, 10 min
> ReRegistration, 240 s OPTIONS, 1 SIPS trunk, 60 s ReRegistration, 2 SIP
> extensions)
>
> Therefore I tested different scenarios:
>
> Asterisk 16.4.1 -> no memory leak
> Asterisk 16.5.1 -> memory leak
>
> Asterisk 16.4.1 with pjsip 4.9 -> memory leak
> Asterisk 16.5.1 with pjsip 4.8 -> no memory leak
>
>
> Therefore, I can say, that there is a problem related to pjsip 4.9 (maybe
> it's a pjsip problem itself or Asterisk should have been changed to adopt
> new behavior of pjsip 4.9).
>
> Anyway: Asterisk is quite unusable since 16.5.x. 2 times I already
> encountered the OOM killer reaping an asterisk 16.5.x process consuming far
> too much memory.
>
>
> BTW: I'm not really happy with the fact, that an existing LTS / stable
> version gets a new pjsip version "on the fly". From my point of view, this
> should have been done
> during a normal development cycle and not during a stable phase.
>
>
>
> Thanks
> Michael
>
> --
> _
> -- 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



-- 
Kevin Harwell
Digium - A Sangoma Company | Senior Software Developer
445 Jan Davis Drive NW - Huntsville, AL 35806 - US
Check us out at: https://digium.com & https://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] res_config_sqlite3 segfault?

[Kevin Harwell]

On Thu, Jul 11, 2019 at 5:11 AM Dennis Buteyn 
wrote:

> Just curious whether anyone ever tried to use this module. Its existence
> and usage appears to be vaguely documented.
>
> Asterisk seems to crash consistently on startup if you don't explicitly
> define "dbfile => ... " in res_config_sqlite3.conf. (Not having the config
> file at all is fine).
>
> Is this working as intended or should I file a bug report?
>
A crash is never working as intended, so I'd say file a bug report please
[1]. Be sure to get a backtrace [2] and attach it to the issue. A debug
Asterisk log [3] at startup could be helpful as well.

[1] https://issues.asterisk.org/
[2] https://wiki.asterisk.org/wiki/display/AST/Getting+a+Backtrace
[3] https://wiki.asterisk.org/wiki/display/AST/Collecting+Debug+Information

Thanks!

-- 
Kevin Harwell
Digium - A Sangoma Company | Senior Software Developer
445 Jan Davis Drive NW - Huntsville, AL 35806 - US
Check us out at: https://digium.com & https://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] bad AMI events order

[Kevin Harwell]

On Wed, Apr 24, 2019 at 10:29 AM marek cervenka  wrote:

> hi,
>
> in asterisk 13.24.1 is something "different" with AMI events (precisely
> Hangup event)
>
> scenario
>
> simple call to queue, call is answered by Agent
>
> in asterisk 13.23.1 is AMI flow like this
> { "event": "QueueCallerJoin", "uniqueid": "112600.457","linkedid":
> "112600.457" }
> { "event": "AgentCalled", "uniqueid": "112600.457","linkedid":
> "112600.457","destuniqueid": "112601.464","destlinkedid":
> "112600.457"}
> { "event": "AgentConnect", "uniqueid": "112600.457","linkedid":
> "112600.457","destuniqueid": "112601.464","destlinkedid":
> "112600.457",}
> { "event": "Hangup", "uniqueid": "112601.465","linkedid":
> "112600.457" }
> { "event": "Hangup", "uniqueid": "112601.471","linkedid":
> "112600.457" }
> { "event": "AgentComplete", "uniqueid": "112600.457","linkedid":
> "112600.457","destuniqueid": "112601.471","destlinkedid":
> "112600.457",}
> { "event": "Hangup", "uniqueid": "112601.464","linkedid":
> "112600.457" }
> { "event": "Hangup", "uniqueid": "112600.457","linkedid":
> "112600.457" }
>
> but it changed in asterisk 13.24.1 and later (ast 13.26.0 tested)
> { "event": "QueueCallerJoin","uniqueid": "112879.0" ,"linkedid":
> "112879.0" }
> { "event": "AgentCalled", "uniqueid": "112879.0" ,"linkedid":
> "112879.0","destuniqueid": "112879.7","destlinkedid":
> "112879.0" }
> { "event": "Hangup", "uniqueid": "112879.7" ,"linkedid":
> "112879.0" }
> { "event": "AgentConnect", "uniqueid": "112879.0" ,"linkedid":
> "112879.0","destuniqueid": "112879.7","destlinkedid":
> "112879.0" }
> { "event": "Hangup", "uniqueid": "112879.8" ,"linkedid":
> "112879.0" }
> { "event": "AgentComplete", "uniqueid": "112879.0" ,"linkedid":
> "112879.0","destuniqueid": "112879.14","destlinkedid":
> "112879.0" }
> { "event": "Hangup", "uniqueid": "112879.14","linkedid":
> "112879.0" }
> { "event": "Hangup", "uniqueid": "112879.0", "linkedid":
> "112879.0" }
>
> first Hangup is before AgentConnect
>
> do you think it can be considered bug?
>
Given the information it doesn't seem like a bug. Ordering between most AMI
events is not guaranteed.

> any ideas where this change happened?
>
If it's only due to threading and timing it'd be tough to track down.
Depending on timing an alteration could make it so any given thread is now
running slightly slower, or even faster, than before. Thus altering the
order.

>
> i found only these changes to app_queue
>
> https://issues.asterisk.org/jira/browse/ASTERISK-28125
>
>
> https://github.com/asterisk/asterisk/commit/f23a12244d8286e26554b7658a042f51497c1485
>
>
> Marek
>
>

-- 
Kevin Harwell
Digium - A Sangoma Company | Senior Software Developer
445 Jan Davis Drive NW - Huntsville, AL 35806 - US
Check us out at: https://digium.com & https://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] Adding new ARI for application execute

[Kevin Harwell]

On Tue, Apr 2, 2019 at 4:01 PM Sungtae Kim  wrote:

> So, here's some API draft.
>
> I will introduce 2 new ARI requests and 1 ARI event.
>

ARI is meant to be an alternative to diaplan applications, and not act as a
layer on top of them. Which I feel is the direction this idea is heading
towards. For instance, ARI is not meant to overlay app_queue, but allow a
developer to create their own queue app that interfaces with Asterisk
through ARI. I feel like doing things as proposed violates the underlying
design and goal of ARI. However, see my other response. Maybe this can be
done without changes to the ARI definitions and in a way that does not
undermine the design of ARI.


> 


-- 
Kevin Harwell
Digium - A Sangoma Company | Senior Software Developer
445 Jan Davis Drive NW - Huntsville, AL 35806 - US
Check us out at: https://digium.com & https://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] Adding new ARI for application execute

[Kevin Harwell]

Just throwing an idea out there (I have no idea if this is possible or how
feasible it would be to do this).

ARI is built to interface with applications. A given application controls,
and manipulates channels, bridges, etc... within its context. There are
already mechanism in place that allow a channel to exit an application, and
hand control off to something else. For instance, using 'continue' a
channel is passed to the dialplan, and 'move' a channel is passed to
another application.

With this in mind would it make sense to have the relevant dialplan
applications register themselves as an ARI application? Then you could
simply reuse existing definitions (e.g. move) to "transfer" channel
ownership to another application. From an ARI perspective it doesn't care
where or how an "app" is implemented it just has to conform to the
interface.

Obviously, this would mean modifying each chosen dialplan application in
some way so that it could register as an ARI application. It then uses the
same call to 'move' or 'continue' when it is done with a channel.

Again I have no idea if this is possible given the current state of things,
or if would simply be adding a few new API calls that make it easy for a
dialplan app to become an ARI application. But it might be worth some time
to look into?

On Sat, Mar 30, 2019 at 5:45 PM Sungtae Kim  wrote:

> Hi Asterisk team,
>
> I want to talk about some feature for the ARI.
>
> Currently, ARI doesn't allow executing the Asterisk application.
>
> But this makes ARI users giving up and tired to use the ARI.
> Because to use the Application, it has to be exit from the Stasis and
> jump to the dialplan to executing the application. And have to execute
> the Stasis() again to back to Stasis.
>
> Since it makes the channel needs to be exit from the Stasis, ARI can not
> control the call while it's not in the Stasis. This makes also hard to
> control the call.
>
> So, I was thinking how about make the stasis/ARI possible to execute the
> applications? And I've created ticket for adding this feature to ARI
> which is enabling the ARI to executing the application.
> https://issues.asterisk.org/jira/browse/ASTERISK-28365
>
> Btw, In terms of 'Application' things in Asterisk, I know it's bit weird
> sound.
>
> Because it's executing the application in the application. If the
> Application executed in the Asterisk, all the dialplan's info was
> changed, but this feature will not change it.
>
> It wasn't done in the Asterisk before. But if we think of the Stasis()
> application's specialty, I think this would be OK to having this feature.
>
> I've committed some codes regarding this, but put it into WIP status.
> Because I want to get more discussion about this before going further.
>
> Thank you.
>
> Best regards,
> Sungtae
>
>
> --
> _
> -- 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



-- 
Kevin Harwell
Digium - A Sangoma Company | Senior Software Developer
445 Jan Davis Drive NW - Huntsville, AL 35806 - US
Check us out at: https://digium.com & https://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] Dynamic server side event type filtering in ARI

[Kevin Harwell]

This is now up for review [1]. If you are interested please follow/continue
the discussion on the gerrit review. If you wish to download the patch and
test prior to submission please be sure to also download the dependent
review [2] (for your branch) and apply first.

Thanks to all for the feedback!

[1] https://gerrit.asterisk.org/#/c/asterisk/+/10978/
[2] https://gerrit.asterisk.org/#/c/asterisk/+/10977/

-- 
Kevin Harwell
Digium - A Sangoma Company | Senior Software Developer
445 Jan Davis Drive NW - Huntsville, AL 35806 - US
Check us out at: https://digium.com & https://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] AMI events in Asterisk 16.1 happening 26+ seconds after parking a call.

[Kevin Harwell]

On Fri, Dec 28, 2018 at 3:56 PM Steve Sether  wrote:

> On Thur, Dec 20, 2018 at 10:57 AM Kevin Harwell  
> 
>
> > Have you tested, or currently running with the exact same setup but with
> > another version of Asterisk and you are not seeing the delay?
>
> I tested Asterisk 13.20 under the same dialplan and config, and I couldn't 
> replicate the problem after a good 10-15 attempts. When I switched back to 
> 16.1 I could replicate it multiple times after 2-3 attempts.
>
> Asterisk 11 is problematic since parking is of course quite different, but 
> we've had no problems like this in several years of using the same dialplan, 
> and some minor config changes with 16.
>
> Sounds like a possible bug could have been introduced. Does this happen at
all under 13 (like a more recent version, 13.24.0 for instance)? Or just in
16? If you are willing and able you could try using 'git bisect' on the
branch in question to try and track down exactly what patch introduced the
problem.

> What's the exact test scenario you are running?
>
> Probably more complicated than is worth getting into.  By simple, I meant 
> merely monitoring AMI output, not the dialplan or Asterisk config.  So the 
> delay isn't being caused by the component connected to the AMI.  I'll work on 
> trying to provide a simple scenario with a simple dialplan next week that's 
> easy to replicate, or at least figure out if there's something specific to 
> our setup that causes this.
>
> A basic scenario and/or simple description on how to replicate it would be
most helpful.


> > After 'n' seconds of park time are you sending the call back to the dialplan
>
> We do do this, but I set the timeout to 10 minutes so it wouldn't interfere 
> with my testing.  The delays I'm seeing are more like 30 seconds to a minute, 
> and happen before the call gets sent back to the return_context I set in 
> ParkAndAnnounce.
>
>
Based on the fact it was working before in a previous version with no
change to configuration makes it sound like a bug to me. If you'd like you
can file a bug report on the Asterisk issue tracker [1]. Please read over
the guidelines [2] on how to do that if you haven't already, and be sure to
include a full debug log [3], along with the AMI output. Also any relevant
configuration you can share would be helpful as well.

[1] https://issues.asterisk.org/
[2] https://wiki.asterisk.org/wiki/display/AST/Asterisk+Issue+Guidelines
[3] https://wiki.asterisk.org/wiki/display/AST/Collecting+Debug+Information

Thanks!
-- 
Kevin Harwell
Digium - A Sangoma Company | Senior Software Developer
445 Jan Davis Drive NW - Huntsville, AL 35806 - US
Check us out at: https://digium.com & https://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] Dynamic server side event type filtering in ARI

[Kevin Harwell]

> Do you think a "reset" operation would be interesting? Something to
> remove all filters? Perhaps a DELETE? But that would be twisting the
> semantics of the DELETE, since the eventFilter resource would still be
> there. A POST on /applications/.../eventFilter/reset ? Or a POST with
> {"allow": null, "disallow": null} ?


It's probably worthwhile to have some kind of reset or way to clear the
filtering. I'm thinking that "no eventFilter" means the application would
get all events, so I think a DELETE would work here. By having "no
eventFilter" equal "all events" we can maintain the way things currently
work (meaning current applications would not have to change). We can also
always add this functionality in a subsequent patch too if app developers
decide it's needed.


>
>
-- 
> Sébastien Duthil
>
> ---
>

Many thanks for the detailed feedback!

-- 
Kevin Harwell
Digium - A Sangoma Company | Senior Software Developer
445 Jan Davis Drive NW - Huntsville, AL 35806 - US
Check us out at: https://digium.com & https://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] AMI events in Asterisk 16.1 happening 26+ seconds after parking a call.

[Kevin Harwell]

On Wed, Dec 19, 2018 at 4:39 PM Steve Sether  wrote:

> I'm testing Asterisk 16, and I'm seeing a very serious delay in
> bridging, and other events being displayed in the AMI, either that, or
> I'm misunderstanding how things are supposed to work.
>

Have you tested, or currently running with the exact same setup but with
another version of Asterisk and you are not seeing the delay?


> My test setup is very simple, I'm using netcat to connect to port 5038,
> and outputting to a file.  I've isolated to a test instance of Asterisk
> with no other calls on it.
>

What's the exact test scenario you are running?


>
> 
>
> This doesn't make much sense to me.  Why are there parking events
> happening so longer after the call is parked?  While there's description
> of these events in the documentation, I don't know of any documentation
> on how these events relate to call setup, parking, etc
>

After 'n' seconds of park time are you sending the call back to the
dialplan (what's the "parkingtime", "comebacktoorigin", and
"comebackcontext" settings set to in your configuration)? This could
account for the later events.


> Thanks for any help anyone can provide.
>
> Is this a bug in Asterisk, or do I need to better understand these
> events?  If the latter, how can I go about that?
>

 If you haven't already check out the following for more information, and
examples on call parking in Asterisk:

https://wiki.asterisk.org/wiki/display/AST/Call+Parking
https://blogs.asterisk.org/2016/03/30/setup-call-parking/

-- 
Kevin Harwell
Digium - A Sangoma Company | Senior Software Developer
445 Jan Davis Drive NW - Huntsville, AL 35806 - US
Check us out at: https://digium.com & https://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] Dynamic server side event type filtering in ARI

[Kevin Harwell]

On Thu, Dec 13, 2018 at 3:42 PM George Joseph  wrote:

>
>
> On Thu, Dec 13, 2018 at 2:27 PM Kevin Harwell  wrote:
>
>> Greetings,
>>
>> I'm looking into adding the ability for an ARI application to dynamically
>> control which event types it would like sent to it[1] (i.e. server side
>> event type filtering). I'm currently leaning toward implementing this as a
>> blacklist. I believe doing so would ease the development burden on the
>> Asterisk side as well as on the application side of things while
>> maintaining current application received event type expectations. Here's a
>> proposed REST interface:
>>
>> GET /applications/{applicationName}/excludeEventFilters
>>
> .
> excludeEventFilters sounds like you're excluding event filters.  What
> you're operating on is an eventExclusionList
>

How about eventExclusions? I don't have a real problem with using the world
"List", except it breaks our convention. Everywhere else we just use
plurals.


> Returns a list of exclude event filters.
>>
>> POST /applications/{applicationName}/excludeEventFilters
>>
>> Using a json object as a body parameter create a list of exclude
>> event filters. This will overwrite any existing filters list. For now the
>> json object *might* look something like the following:
>>
>> {  types: [ eventType, eventType, ...] }
>>
>
> When you POST, you're asking the object to take some action.
> If you want to use POST, then the json blob should contain an "add" list
> of types and a "remove" list of types.
>
> We SHOULD be using PUT to add or replace an entire list.
>

I'm not a REST expert by any means, but I thought POST aligned more with
create and PUT create/update. But I guess since we are working on the whole
list then we can get away with just a PUT, and as you say it will add or
replace/update the entire list.

>
>
>> By making it an object this would make it possible to add more filtering
>> in the future without having to update the definition.
>>
>> DELETE /applications/{applicationName}/excludeEventFilters
>>
>> Remove all filters from the exclude list.
>>
>
> DELETE deletes the list.  See below.
>
>> If people wanted I could also add the following?
>>
>> PUT /applications/{applicationName}/excludeEventFilters/{eventType}
>>
>> Add the specified “eventType” to the exclude list.
>>
>> DELETE /applications/{applicationName}/excludeEventFilters/{eventType}
>>
>> Remove the specified “eventType” from the exclude list.
>>
>
> You could DELETE /applications/{applicationName}/eventExclusionList/all
> to delete the event types from the list.
>

I think just DELETE'ing the list is fine. I was more thinking from an
Asterisk coding perspective at the time where we'd probably just clear the
internally stored collection.


>
>
>> Naming is hard, but I've used “exclude” in order to signify that matches
>> on a specified filter would block messages being sent to the application.
>> “Filters” I've used because it's filtering the messages that are being sent
>> to the application, and later we might want to filter off more than the
>> event type name.
>>
>> Anyhoo thoughts, opinions, alternative ideas are most welcome.
>>
>> Thanks!
>>
>> [1] https://issues.asterisk.org/jira/browse/ASTERISK-28106
>>
>> --
>> Kevin Harwell
>> Digium - A Sangoma Company | Senior Software Developer
>> 445 Jan Davis Drive NW - Huntsville, AL 35806 - US
>> Check us out at: https://digium.com & https://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
>
>
>
> --
> *George Joseph*
> Digium - A Sangoma Company | Software Developer | Software Engineering
> 445 Jan Davis Drive NW - Huntsville, AL 35806 - US
> direct/fax: +1 256 428 6012
> Check us out at: https://digium.com · https://sangoma.com
>
> --
> _
> -- 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



-- 
Kevin Harwell
Digium - A Sangoma Company | Senior Software Developer
445 Jan Davis Drive NW - Huntsville, AL 35806 - US
Check us out at: https://digium.com & https://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

[asterisk-dev] Dynamic server side event type filtering in ARI

[Kevin Harwell]

Greetings,

I'm looking into adding the ability for an ARI application to dynamically
control which event types it would like sent to it[1] (i.e. server side
event type filtering). I'm currently leaning toward implementing this as a
blacklist. I believe doing so would ease the development burden on the
Asterisk side as well as on the application side of things while
maintaining current application received event type expectations. Here's a
proposed REST interface:

GET /applications/{applicationName}/excludeEventFilters

Returns a list of exclude event filters.

POST /applications/{applicationName}/excludeEventFilters

Using a json object as a body parameter create a list of exclude event
filters. This will overwrite any existing filters list. For now the json
object *might* look something like the following:

{  types: [ eventType, eventType, ...] }

By making it an object this would make it possible to add more filtering in
the future without having to update the definition.

DELETE /applications/{applicationName}/excludeEventFilters

Remove all filters from the exclude list.

If people wanted I could also add the following?

PUT /applications/{applicationName}/excludeEventFilters/{eventType}

Add the specified “eventType” to the exclude list.

DELETE /applications/{applicationName}/excludeEventFilters/{eventType}

Remove the specified “eventType” from the exclude list.

Naming is hard, but I've used “exclude” in order to signify that matches on
a specified filter would block messages being sent to the application.
“Filters” I've used because it's filtering the messages that are being sent
to the application, and later we might want to filter off more than the
event type name.

Anyhoo thoughts, opinions, alternative ideas are most welcome.

Thanks!

[1] https://issues.asterisk.org/jira/browse/ASTERISK-28106

-- 
Kevin Harwell
Digium - A Sangoma Company | Senior Software Developer
445 Jan Davis Drive NW - Huntsville, AL 35806 - US
Check us out at: https://digium.com & https://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] Web Downloads

[Kevin Harwell]

On Tue, May 8, 2018 at 9:25 AM, Alexander Traud <pabstr...@compuserve.com>
wrote:

> > <http://www.asterisk.org/downloads>
>
> has a button to download the "latest version". That button states you
> download Asterisk 13. However, the download link points to Asterisk 15.
>
> The update might take a few minutes to sync, but the button should now
show the latest version: 15.4.0.

-- 

Kevin Harwell
Digium, Inc. | Software Developer
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

[asterisk-dev] Asterisk release branch deletions

[Kevin Harwell]

Greetings.

To make maintenance slightly easier we are going to delete all non current
release branches for the major branches of 13, 14, and 15.

For example all 13.* branches will be deleted from the repository except
for the most current active release(s). Which in the 13 case are the 13.19
branch (current release) and 13.20 branch (soon to be released).

Moving forward older release branches will continue to be deleted as new
releases come out. Since all releases are tagged there should be no problem
checking out a particular version if needed. Also, if circumstances so
arise a branch can be recreated from a given tag.

Current plans are to initiate this process on Monday March 12, 2018. If
anyone has any valid reasons, or concerns about the release branch
deletions please speak up.

Thanks!

-- 

Kevin Harwell
Digium, Inc. | Software Developer
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] Branching in the Testsuite

[Kevin Harwell]

On Mon, Jan 22, 2018 at 12:41 PM, Kevin Harwell <kharw...@digium.com> wrote:

> I'm getting ready to start the process of branching the testsuite. I'm
> going to give a basic overview here of what I'm going to do, so as things
> get posted on gerrit people will have some idea as to what is coming, and
> why.
>
> To start I'm not going to touch the current master branch. This will be
> renamed later to "legacy" once the new branches have all been created and
> readied.
>
> The first branch I'll create is the 13 branch. Once created I'm going to
> remove all tests that have their min version's marked as < 13.19.0 (current
> release of Asterisk). I'll then push this up for review. Once it's accepted
> I'll move onto the next step.
>
> Next I will create the 14 branch from the 13 branch. I'll then remove all
> tests from the 14 branch that have their min version's marked as < 14.7.5.
> I'll also remove all tests from the 13 branch that have a max version > 13.
> I'll then push both of these for review.
>
> Once accepted I'll then do similar for the 15 branch. It will be created
> from 14, and all tests will be removed that have a min version < 15.2.0.
> All tests with a max version > 14 will be removed from the 14 branch. Once
> these have been reviewed and accepted I will do the same for what will be
> the new master branch (probably temporarily call it that, "new_master",
> until we rename the old one to "legacy").
>
> Once all this part is done, or mostly done for a branch, I'll go through
> all the tests for each branch and remove the versioning stuff from the yaml
> files.
>
> At this point the branches should be in their final ready states. I'll
> update the Jenkins scripts to point to the new branches (13, 14, 15).  If
> everything seems good to go I'll rename the current master to "legacy", and
> rename "new_master" to "master". I'll also I'll create a tag for each
> branch based on the latest Asterisk version that's been released. At some
> point in this process I'll also update the mkrelease script to auto-create
> a new tag in the testsuite based on the version of Asterisk being released.
>
> I'm hoping by doing it this way it will minimize the size of the each
> review and help separate out the different types of changes.
>
> Thanks!
>
>
Actually, as the head of the testsuite branch is always moving toward the
next release I'm going to remove tests for each branch less than or equal
to the current released version of Asterisk for a branch. That'll make the
new branches starting point align with the following Asterisk versions:

13.20.0
14.7.6
15.3.0

To run any test against Asterisk prior to these versions one will need to
run them against the "legacy" branch.



Kevin Harwell
Digium, Inc. | Software Developer
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] Branching in the Testsuite

[Kevin Harwell]

I'm getting ready to start the process of branching the testsuite. I'm
going to give a basic overview here of what I'm going to do, so as things
get posted on gerrit people will have some idea as to what is coming, and
why.

To start I'm not going to touch the current master branch. This will be
renamed later to "legacy" once the new branches have all been created and
readied.

The first branch I'll create is the 13 branch. Once created I'm going to
remove all tests that have their min version's marked as < 13.19.0 (current
release of Asterisk). I'll then push this up for review. Once it's accepted
I'll move onto the next step.

Next I will create the 14 branch from the 13 branch. I'll then remove all
tests from the 14 branch that have their min version's marked as < 14.7.5.
I'll also remove all tests from the 13 branch that have a max version > 13.
I'll then push both of these for review.

Once accepted I'll then do similar for the 15 branch. It will be created
from 14, and all tests will be removed that have a min version < 15.2.0.
All tests with a max version > 14 will be removed from the 14 branch. Once
these have been reviewed and accepted I will do the same for what will be
the new master branch (probably temporarily call it that, "new_master",
until we rename the old one to "legacy").

Once all this part is done, or mostly done for a branch, I'll go through
all the tests for each branch and remove the versioning stuff from the yaml
files.

At this point the branches should be in their final ready states. I'll
update the Jenkins scripts to point to the new branches (13, 14, 15).  If
everything seems good to go I'll rename the current master to "legacy", and
rename "new_master" to "master". I'll also I'll create a tag for each
branch based on the latest Asterisk version that's been released. At some
point in this process I'll also update the mkrelease script to auto-create
a new tag in the testsuite based on the version of Asterisk being released.

I'm hoping by doing it this way it will minimize the size of the each
review and help separate out the different types of changes.

Thanks!
-- 

Kevin Harwell
Digium, Inc. | Software Developer
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] Minor Release Branches

[Kevin Harwell]

On Tue, Dec 19, 2017 at 10:12 AM, Corey Farrell <g...@cfware.com> wrote:

> I'd like to propose that we make minor release branches temporary.  What I
> mean is 13.15, 15.0, etc.  The sole purpose of the '13.15' was to allow
> cherry-picking fixes to the 13.15.x series.  As soon as 13.16.0 was
> released the '13.15' branch was closed to new merges.  The latest commit on
> '13.15' is tagged as '13.15.1' so we would not be orphaning any commits by
> doing this. When you click "Cherry-pick" from the gerrit web ui and type
> "15", the selection list shows "13.15" first (and selects it by default).
>
> Anyone have thoughts on this?
>
>
Sounds good to me. You might even be able to automate this by making it
part of the mkrelease script.

Kevin Harwell
Digium, Inc. | Software Developer
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] Branching in the Testsuite

[Kevin Harwell]

I went ahead and created an issue to track this:

https://issues.asterisk.org/jira/browse/ASTERISK-27492

Feel free to add comments or suggestions on the issue as well.

On Fri, Dec 15, 2017 at 10:59 AM, Kevin Harwell <kharw...@digium.com> wrote:

> Greetings,
>
> We're thinking about adding a branching system to the Asterisk Testsuite.
> Each branch would be named the same as, and correspond to, an Asterisk
> branch. So for instance the following branches would probably be created:
>
> 13, 14, 15
>
> For each release of Asterisk we will also create a tag in the Testsuite
> that corresponds to that release's tag. That way someone could checkout
> both tags for easy testing
>
> Other advantages? Most all, if not all, the current versioning stuff found
> in the Testsuite could go away, or be safely ignored moving forward. The
> versioning has become a bit cumbersome especially when you have to make a
> backward incompatible change to a test. Moving the version control out of
> the Testsuite and into a version control system should alleviate the need
> for this moving forward.
>
> Please let us know your thoughts and considerations on moving forward with
> this model. Especially any potential pitfalls or problems you might see
> with it.
>
> Thanks!
>
> --
>
> Kevin Harwell
> Digium, Inc. | Software Developer
> 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
> Check us out at: http://digium.com & http://asterisk.org
>
>


-- 

Kevin Harwell
Digium, Inc. | Software Developer
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

[asterisk-dev] Branching in the Testsuite

[Kevin Harwell]

Greetings,

We're thinking about adding a branching system to the Asterisk Testsuite.
Each branch would be named the same as, and correspond to, an Asterisk
branch. So for instance the following branches would probably be created:

13, 14, 15

For each release of Asterisk we will also create a tag in the Testsuite
that corresponds to that release's tag. That way someone could checkout
both tags for easy testing

Other advantages? Most all, if not all, the current versioning stuff found
in the Testsuite could go away, or be safely ignored moving forward. The
versioning has become a bit cumbersome especially when you have to make a
backward incompatible change to a test. Moving the version control out of
the Testsuite and into a version control system should alleviate the need
for this moving forward.

Please let us know your thoughts and considerations on moving forward with
this model. Especially any potential pitfalls or problems you might see
with it.

Thanks!

-- 

Kevin Harwell
Digium, Inc. | Software Developer
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] Help with AOC (Advice Of Charge) - price info on outbound calls

[Kevin Harwell]

On Mon, Nov 20, 2017 at 8:51 AM, Marin Odrljin <ma...@maxcom.hr> wrote:

> Hi everybody,
>
>
>
> I have already asked this question on 'asterisk-app-dev' list and on
> community site https://community.asterisk.org/t/get-aoc-information-via-
> ari/72532 but unfortunatelly there was no any reply in last few weeks, so
> my last chance is to hope that anyone from this list could know anything
> about AOC. Sorry if someone of you have already seen it there and I'm too
> boring with it.
>
>
>
> On some of our ISDN trunks at the end of the outbound calls, we are
> getting pricing info from the carrier. I would like to read it with ARI.
> From the AOC documentation (https://wiki.asterisk.org/
> wiki/display/AST/Advice+of+Charge) it seems like it is possible to get it
> only via AMI only or am I wrong? Does anyone has an idea if it could be
> read somehow else except AMI, e.g. channel variables which can be passed to
> or read via ARI? If I already use ARI, I wouldn’t like to connect to AMI as
> well just because of getting AOC.
>
>
>
> If that's not possible, what would be the best way to implement it?
>
>
>
>
>
> Thanks for any suggestion.
>
> Marin
>

Have you tried the subscribe to all events[1] option in ARI? If not give
that a try and see if the event(s) show up.

[1] https://wiki.asterisk.org/wiki/display/AST/Asterisk+13+Events+REST+API


-- 

Kevin Harwell
Digium, Inc. | Software Developer
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] AstDB mySQL implementation

[Kevin Harwell]

On Mon, Oct 30, 2017 at 1:19 PM, Nir Simionovich <nir.simionov...@gmail.com>
wrote:

> Definite +1 on the Documentation side - for sure. Here is a stupid
> question, is there a "Best Practices" coding document somewhere?
> I remember that many years ago there was something really basic, but much
> has changed since then.
>

Are you referring to the coding guidelines? If so those can be found on the
wiki[1].

[1] https://wiki.asterisk.org/wiki/display/AST/Coding+Guidelines

-- 

Kevin Harwell
Digium, Inc. | Software Developer
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] New application for MQTT send

[Kevin Harwell]

On Fri, Oct 20, 2017 at 2:51 PM, Gabriel Ortiz Lour <ortiz.ad...@gmail.com>
wrote:

> Hi devs!
>
>   I want to code a new asterisk App to send messages over MQTT. looking
> the docs the MQTT lib needs frequent calling to a "loop" function, since
> the "send" method is asyncronous.
>
>   I don't want to use it externally with "System" or "AGI" since it will
> be called in the ahngup handler and I would like to use the fast "publish"
> call (hangup handlers should be quick, right? :)
>
>   Where would I put this frequent calling on asterisk code? should I build
> a thread for this? or put inside some asterisk "main loop"?
>

Usually you want something like this to be non-blocking, so you'll need to
put this in a separate thread (unless for some reason you want the main
thread to block while it is in the "loop"). So in your application exec
handler you'd initiate a thread that runs the "loop".


>
> Thanks,
> Gabriel
>
>
>

-- 

Kevin Harwell
Digium, Inc. | Software Developer
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] Opus Codec not in the translation array?

[Kevin Harwell]

On Tue, Aug 8, 2017 at 5:45 PM, Steve Murphy <m...@parsetree.com> wrote:

>
> On Tue, Aug 8, 2017 at 4:21 PM, Kevin Harwell <kharw...@digium.com> wrote:
>
>> On Tue, Aug 8, 2017 at 11:29 AM, Steve Murphy <m...@parsetree.com> wrote:
>>
>>> When I load the opus codec (from digium),
>>> I don't see it in the "core show translation" output.
>>> Anybody know why?
>>>
>>>
>> I've downloaded "codec_opus" (from Digium) for Asterisk 13. After
>> starting Asterisk I issued the following command from the CLI:
>>
>> core show translation
>>
>> I was able to see opus information in the table output.
>>
>> What version of Asterisk are you having the problem in? Also how did you
>> obtain the codec? Did you select it through menuselect or did you download
>> it manually and then copy the *.so files into the Asterisk lib directory?
>>
>
> I'm in 13.17.0.
> ​ Installed the external via menuselect, the installation downloaded and
> installed the codecs (opus, slik, sirens)​
>
>
> ​Weird!
>
> I just checked again. opus is now in the list!
>
> It's not like I just missed it. I restarted asterisk. Not in the list.
> Restarted again. Not in the list.
> wrote my email.
> when I spotted your answer, I was going to include the output of "core
> show translation", but the
> originals were too far back in the past to scroll to, so I re-entered the
> command, and doggone-it,
> opus in the array now.
>
> Sorry to bother you. Maybe it took a few (>15min?) to register? (But the
> others showed up right away).
> For anyone else tempted to ask after installation and startup, if you
> don't spot opus, wait a few more mins
> and try again!
>
> murf
>

No worries I am glad to hear it is now working okay. My favorite kind of
bugs are the kind that turn out to not be bugs :-)

-- 

Kevin Harwell
Digium, Inc. | Software Developer
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] Opus Codec not in the translation array?

[Kevin Harwell]

On Tue, Aug 8, 2017 at 11:29 AM, Steve Murphy <m...@parsetree.com> wrote:

> When I load the opus codec (from digium),
> I don't see it in the "core show translation" output.
> Anybody know why?
>
>
I've downloaded "codec_opus" (from Digium) for Asterisk 13. After starting
Asterisk I issued the following command from the CLI:

core show translation

I was able to see opus information in the table output.

What version of Asterisk are you having the problem in? Also how did you
obtain the codec? Did you select it through menuselect or did you download
it manually and then copy the *.so files into the Asterisk lib directory?

-- 

Kevin Harwell
Digium, Inc. | Software Developer
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] MOH still playing after attended transfer

[Kevin Harwell]

On Fri, Jul 28, 2017 at 3:10 AM, Jason TOMLINSON <j.tomlin...@isi-com.com>
wrote:

> Hi,
>

Greetings!


>
>
> I raised an issue [ https://issues.asterisk.org/jira/browse/ASTERISK-27071
> ] where music on hold keeps playing on the held channel after an attended
> transfer on asterisk 13
>
> It affects calls coming in though a trunk from an alcatel pbx, but after
> digging though the code it seems likely that it might affect any trunk in
> general which requests an attended transfer via replaces
>
>
>
> The invite/replaces arrives at chan_sip.c -> handle_invite_replaces which
> does its thing to do the transfer, but nowhere (it seems) is the moh
> stopped on the waiting channel (unlike in asterisk 11 pre-bridge changes
> where all channels are explicitely stopped).
>
>
>
> So, after the transfer is done and we get the bridge concerned I added (in
> the if(bridge){…} block near the end):
>
> struct ast_bridge_channel *other;
>
> AST_LIST_TRAVERSE(>channels, other, entry) {
>
>ast_moh_stop(other->chan); /*attended trf
> done, so stop all moh*/
>
> }
>
>
>
> Which works.
>
>
>
> So, is this a good way to go? Ie, is this the correct place to stop moh,
> and/or should I be queuing up an AST_CONTROL_UNHOLD frame instead on the
> channels?
>

The bulk of the transfer handling code is now done through the bridging
framework (Asterisk 12+). My first inclination was going to be say the code
may need to be modified somewhere within the bridging framework itself in
order to handle this case. That way it is fixed in one place and other
users of the bridging framework are fixed as well.

>From what I can tell by glancing at the code it appears a modification
would need to be done within ast_bridge_impart[_interal] if you went that
route. However, I am unsure of the possible side effects as this function
is called from several other places (and some of those other places in turn
stop the moh themselves, so there may be a reason why it was not done at
the bridge_impart level). If you are feeling adventurous it might be worth
looking into though.

That all being said the easier route and the fix with less side effects is
the one you propose (I believe res_pjsip_refer suffers from this same
problem so it would be good to fix there as well too). I do lean toward
queuing up an AST_CONTROL_UNHOLD frame instead of calling ast_moh_stop
directly though.

Whatever you decide I would go ahead and push up a patch to Asterisk's
Gerrit server[1]. Once pushed up for code review others will have a better
idea of your proposed changes and will comment appropriately.

[1] https://wiki.asterisk.org/wiki/display/AST/Gerrit+Usage


>
>
> Thanks for any advice!
>
>
>
> Jason
>
>
>
>
>

Hope that helps and thanks for your contribution!

-- 

Kevin Harwell
Digium, Inc. | Software Developer
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] AMI/ARI versioning

[Kevin Harwell]

In order to bring this topic to conclusion I think we'll move forward with
the following versioning model for AMI and ARI since it seems to have
garnered the most votes:

MAJOR.MINOR.PATCH

Where the following definitions apply:

MAJOR - changes when a new major version of Asterisk is released
MINOR - changes when an incompatible API modification is made
PATCH - changes when backwards compatible updates are made (new additions
or bug fixes)

This is basically option number 2 that was outlined in the "ARI versioning
in 13 and 14" thread [1].

I've created a page [2] on the Asterisk wiki for ARI and updated an
existing page for AMI [3] that essentially states the above for each.

Thanks to all for your input and suggestions!

[1] http://lists.digium.com/pipermail/asterisk-dev/2016-November/075964.html
[2] https://wiki.asterisk.org/wiki/display/AST/ARI+Versioning
[3]
https://wiki.asterisk.org/wiki/display/AST/Asterisk+Manager+Interface+%28AMI%29+Changes

Kevin Harwell
Digium, Inc. | Software Developer
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] OPUS horrible quality with packet loss

[Kevin Harwell]

On Mon, Apr 3, 2017 at 1:28 PM, Yury Tsaregorodtsev 
wrote:

> after fixing attr->fec in open source edition of OPUS and applying
> Alexanders patch: ASTERISK-25629 (Native Packet-Loss Concealment)
> I have following results:
>
> I setup 2 hosts with asterisk 13.14.0 and made dozen calls in OPUS between
> them.
> On 2nd host I've simulated packet delay and loss:
>
> tc qdisc add dev eth0 root netem loss 20% delay 100ms 20ms distribution normal
>
>
> On 1st host (call origination side) all media been recorded using
> App_Monitor.
> On 2nd host it was simple Playback extension with demo-instruct.sln16
>
> Config for digium codec_opus on both was:
> [opus]
> type=opus
> packet_loss=40
> max_playback_rate=48000
> bitrate=24000
> cbr=0
> fec=1
>
> Config for open source edition of OPUS was same, but replaced values in
> include/asterisk/opus.h
> (and as well I've added to codecs/codec_opus_open_source.c  status =
> opus_encoder_ctl(opvt->opus, OPUS_SET_PACKET_LOSS_PERC(packet_loss));)
>
> All recorded degraded media files were compared to original (recorded with
> AppMonitor as well, but without any delays, losses) accordingly to ITU-T P.862
> (Perceptual evaluation of speech quality (PESQ)):
>
> Reading degraded file  opus_opensource-maxbitrate_
> 24000-cbr_0-fec_1-ID1.wav P.862 Prediction (Raw MOS, MOS-LQO):  = 2.840
> 2.589 8000 nb
> Reading degraded file  opus_opensource-maxbitrate_
> 24000-cbr_0-fec_1-ID2.wav P.862 Prediction (Raw MOS, MOS-LQO):  = 2.507
> 2.143 8000 nb
> Reading degraded file  opus_opensource-maxbitrate_
> 24000-cbr_0-fec_1-ID3.wav P.862 Prediction (Raw MOS, MOS-LQO):  = 2.379
> 1.994 8000 nb
> Reading degraded file  opus_opensource-maxbitrate_
> 24000-cbr_0-fec_1-ID4.wav P.862 Prediction (Raw MOS, MOS-LQO):  = 2.472
> 2.102 8000 nb
> Reading degraded file  opus_opensource-maxbitrate_
> 24000-cbr_0-fec_1-ID5.wav P.862 Prediction (Raw MOS, MOS-LQO):  = 2.413
> 2.032 8000 nb
>
> Reading degraded file  opus_digium-maxbitrate_24000-cbr_0-fec_1-ID1.wav P.862
> Prediction (Raw MOS, MOS-LQO):  = 1.332 1.258 8000 nb
> Reading degraded file  opus_digium-maxbitrate_24000-cbr_0-fec_1-ID2.wav P.862
> Prediction (Raw MOS, MOS-LQO):  = 0.738 1.110 8000 nb
> Reading degraded file  opus_digium-maxbitrate_24000-cbr_0-fec_1-ID3.wav P.862
> Prediction (Raw MOS, MOS-LQO):  = 2.426 2.047 8000 nb
> Reading degraded file  opus_digium-maxbitrate_24000-cbr_0-fec_1-ID4.wav P.862
> Prediction (Raw MOS, MOS-LQO):  = 0.920 1.143 8000 nb
> Reading degraded file  opus_digium-maxbitrate_24000-cbr_0-fec_1-ID5.wav P.862
> Prediction (Raw MOS, MOS-LQO):  = 2.680 2.366 8000 nb
>
> MOS on calls using open source opus higher almost twice.
> Subjective opinion regarding audio quality: using open source codec
> quality almost same as in example on http://opus-codec.org/examples/ with
> 30% loss and FEC, acceptable for ears, but
> using digium opus quality is not acceptable, a lot of spikes,
> interruptions.
>
> I also double checked the fact before applying ASTERISK-25629 patch
> asterisk don't drop lately arrived RTP.
> I've recorded UDP dump and replayed it using "bittwist" utility, without
> patch all RTP packets been played again, with patch all of them been
> ignored.
>
>
Hi Yury,

We for sure want to look more into this. If you would open an issue on the
Asterisk issue tracker [1] it would be much appreciated. Be sure to include
all your findings.

When possible list the exact version numbers you are using for the various
tools and libraries being used (Asterisk - output of running "asterisk -V",
PESQ, Opus library for when you used the Asterisk open source codec, etc).

Also if possible include information about your Asterisk setup. Dialplan
used (extensions.conf), endpoint configuration (pjsip.conf or sip.conf),
etc...

Also include the exact commands you used when running tests. All of this
will greatly help in duplicating results.

[1] https://issues.asterisk.org

Thanks!

Kevin
-- 
_
-- 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] OPUS horrible quality with packet loss

[Kevin Harwell]

On Mon, Apr 3, 2017 at 3:38 PM, Yury Tsaregorodtsev 
wrote:

> Even forced enabled jitter doesn't make asterisk to ignore late arrived
> packets.
> During my tests jb was always enabled (forced).
>

Hrm I'd think the jitter buffer should ignore or drop the late packets.
That is packets arriving with timestamps marked as before packets that have
already left the jitter buffer and have been processed by the audio
core/translated.

Just to double check what channel (inbound or outbound) are you attaching
the jitter buffer too and is it the one that would receive the late
packets? For instance if it is needed on the outbound channel then you'd
need to use a pre-dial handler:

exten => outbound_jitterbuf,1,NoOp()
  same => n,Set(JITTERBUFFER(adaptive)=default)
  same => n,Return()

exten => _1XX,1,Noop()
  same => n,Dial(${TECH}/${EXTEN},20,b(default^outbound_jitterbuf^1))
  same => n,Hangup()

Thanks,

Kevin
-- 
_
-- 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] OPUS horrible quality with packet loss

[Kevin Harwell]

On Mon, Apr 3, 2017 at 1:28 PM, Yury Tsaregorodtsev 
wrote:

> 
>
MOS on calls using open source opus higher almost twice.
> Subjective opinion regarding audio quality: using open source codec
> quality almost same as in example on http://opus-codec.org/examples/ with
> 30% loss and FEC, acceptable for ears, but
> using digium opus quality is not acceptable, a lot of spikes,
> interruptions.
>
> I also double checked the fact before applying ASTERISK-25629 patch
> asterisk don't drop lately arrived RTP.
>

Dropped packets and late arriving packets are two separate issue and are
handled as such in Asterisk. The Digium Opus codec can handle dropped
packets by enabling FEC. If the problem is late arriving packets than
applying a jitter buffer to the audio stream exhibiting the problem should
help alleviate that.
-- 
_
-- 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] OPUS horrible quality with packet loss

[Kevin Harwell]

On Fri, Mar 31, 2017 at 6:54 PM, Yury Tsaregorodtsev <aero.1...@icloud.com>
wrote:

> Examples of OPUS with 30% of LOSS with FEC on http://opus-codec.org/
> examples/
> Sounds too perfect. Why I can't achieve even similar quality on asterisk
> with built codec by digium?
> To simulate 30% packet loss I use:
>
>  # tc qdisc add dev eth0 root netem delay 100ms loss 30%
>
> But even with 15-20% of loss it's almost impossible to talk.
> Tried different bitrates, result is always same.
> If I do PESQ predicted MOS of degraded audio (recorded with packet loss)
> in compare to original: 1.025
> Horrible results, horrible sound.
>
> Anyone get better experience using opus with huge packet losses ?
>
>
Have you enabled FEC and made sure both sides negotiated it? If not you can
enable it within "codecs.conf" by setting "fec=yes".

When a packet has been lost and the decoder receives a frame with FEC data
(and fec is enabled) it will attempt to rebuild the lost packet (current
packet minus one) from the given FEC information.


Kevin Harwell
Digium, Inc. | Software Developer
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] AMI/ARI versioning

[Kevin Harwell]

On Thu, Mar 30, 2017 at 6:54 PM, Corey Farrell <g...@cfware.com> wrote:

> On 03/30/2017 07:14 PM, Kevin Harwell wrote:
> I think it's worth referencing a previous discussion on this [1].
>

Yes, thank you! I looked for this and for some reason my searches turned up
nothing.


> I agree with Mark's idea that having the ARI/AMI major version tied to the
> Asterisk branch could lead to confusion, lead people to believe that ARI
> 14.3.0 == Asterisk 14.3.0.
>

Yeah I could see that causing confusion.


>
> [1] http://lists.digium.com/pipermail/asterisk-dev/2016-
> November/075964.html
>
>
Mark Michelson wrote:

> 2) Bump the major version of ARI for each major release of Asterisk. We
> won't retroactively apply this to the upgrade from Asterisk 12 to
> Asterisk 13. So Asterisk 13 will have ARI versions 1.X.Y, Asterisk 14
> will have ARI versions 2.X.Y, and Asterisk 15 will end up with Asterisk
> 3.X.Y


I'm assuming the other numbers would just be reset here? For instance when
Asterisk 15 is released it would it become 3.0.0?

I think either way we do it the versioning ends up being somewhat localized
to the associated branch and the major number can't change once set on a
branch.
-- 
_
-- 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] AMI/ARI versioning

[Kevin Harwell]

>
>
> [asterisk-branch-number].[minor].[patch]
>
>
Actually, the proposal might be better represented as the following:

[asterisk-branch-number].[major].[minor/patch]

Or another way to state it:

[asterisk-branch-number].[api breaking].[api non breaking]
-- 
_
-- 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] AMI/ARI versioning

[Kevin Harwell]

Greetings,

(I believe this topic has been brought up before, but I was unable to
locate the thread)

In theory, AMI/ARI versions follow the semantic versioning pattern [1]. The
major version number of each started at 1 (1.0.0) and is supposedly bumped
when a new major version of the API is released.

However, in practice the API's major version is usually bumped when a new
major version of Asterisk is released and not changed otherwise. This is
done in order to alleviate API maintenance burdens, and the weird situation
one could get into where an older version of Asterisk specifies a higher
AMI/ARI version number than a newer version of Asterisk. For instance,
because what could be a breaking API change in Asterisk 13 (version bumped)
may not be in Asterisk 14 (version not bumped). So in reality Asterisk
AMI/ARI API's exhibit the following pattern:

[asterisk-branch-number].[minor].[patch]

With the exception that currently the major version number is not actually
the Asterisk branch number. In order to bring that more into alignment it
has been proposed to do just that. Make the major number the same as the
associated Asterisk branch number. So AMI/ARI API version numbers would
then start with 13.x.x for Asterisk 13 and 14.x.x for Asterisk 14.

Thoughts and opinions?

[1] http://semver.org/
-- 

Kevin Harwell
Digium, Inc. | Software Developer
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] Dynamic Payloads

[Kevin Harwell]

On Thu, Mar 16, 2017 at 4:25 PM, James Cloos <cl...@jhcloos.com> wrote:

> Given Alexander's note, clearly something along those lines must be
> done.
>
> But instead of hardcoding the current mapping in the dynamic option's c
> code, I'd put it in a config file.
>
> Ie, the config file would specify static mappings for otherwise dynamic
> codecs.  It should provide commented out examples which match the static
> numbers used by pre-dynamic versions of asterisk to show how to set
> them.
>
> This would allow one to only force static mappings when one has a peer
> which requires them.
>
>
Hi James,

This idea was discussed a bit in #asterisk-dev the other day too. I think
adding this as a configurable option would be beneficial for the reason you
laid out. However, due to the nature of the changes required to make that
work we're going to move forward with just using the current payload values
assigned by Asterisk as defaults. This should cover the majority of user
cases with less complexity.

-- 

Kevin Harwell
Digium, Inc. | Software Developer
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] Dynamic Payloads

[Kevin Harwell]

Alexander, thanks for the reply!

I'm going to move forward with using the original static values as defaults
in order to hopefully minimize any issues.

Currently what I am thinking is when a dynamic payload type needs an
assignment it will first check to see if a default value exists for it. If
so, then use that unless another dynamic payload type has already claimed
it (which hopefully won't happen too often).

On Thu, Mar 16, 2017 at 4:31 AM, Alexander Traud <pabstr...@compuserve.com>
wrote:

> > Is there any advantage to falling back to [the currently used] numbers
> as defaults for a given format?
>
> If the remote party cares about a dynamic RTP payload type number but
> ignores its "=rtpmap:", this is a software bug for sure [1][2][3].
> Consequently, you are asking whether SIP/SDP implementations are known
> which are still in use and contain such a software bug.
>
> Yes, I know such an implementation, released last year by a company in the
> SIP market since day one. If I use another number in the range 96-127, I
> face no audio on incoming calls at that phone (and then it must be
> restarted to continue to do any audio). I have to use exactly the type
> number expected by that phone. This bug was reported and is confirmed.
> Although this is a severe bug, a resolution is questionable. Therefore,
> yes, I see an advantage.
>
> [1] <https://tools.ietf.org/html/rfc4566#section-5.14> sub-field 
> [2] <https://tools.ietf.org/html/rfc4566#section-6> attribute =rtpmap:
> [3] <https://tools.ietf.org/html/rfc4566#section-8.2.3>
>
>
>
-- 

Kevin Harwell
Digium, Inc. | Software Developer
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] Line length restrictions in code changes

[Kevin Harwell]

On Thu, Mar 16, 2017 at 2:54 PM, Matthew Jordan <mjor...@digium.com> wrote:

> 
>
> Personally, I find this:
>
> if (a_good_variable_name->another_good_name &&
> do_something_to_it(a_good_variable_name->another_good_name)) {
> // Do things
> }
>

I prefer this to the alternative as well.


> if (a_good_variable_name->another_good_name
> && do_something_to_it(a_good_variable_name->another_good_name)) {
> // Do things
> }
>
> 
>
> Questions than:
> (1) Should there even be a line length rule?
>

I lean toward yes just to keep things sane (e.g. keeping someone extending
a function definition to infinity and beyond). Also sometimes I split my
editor's screen vertically and have multiple code views up. The vertical
split reduces my column length and I either have to start scrolling or (in
my current setup) the line gets wrapped. Both hurt readability for me.

(2) If there is a line length, what is a reasonable length given some
of our function names? (Looking at things like
ast_sip_get_mwi_disable_initial_unsolicited)

I personally think the current length of 90 is reasonable. I'll add though
that going a bit above this (say up to 100) in some cases should not
prevent code submission. For instance if a variable name is going to extend
an 'if' statement 4 more characters there is no reason to break that up.

(3) Should we simply advocate for readability, with examples of what
is readable and what is not?

Readability should be first and foremost, and some examples would probably
help with that.

-- 

Kevin Harwell
Digium, Inc. | Software Developer
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

[asterisk-dev] Dynamic Payloads

[Kevin Harwell]

Greetings,

Currently, and for the most part, dynamic payload types in Asterisk are
statically declared. This of course is not ideal. Because of that, I have
been working on an issue [1] that makes it so Asterisk no longer statically
declares dynamic payload types, but instead allocates them per RTP instance
as formats are needed.

Due to the nature of the changes I've put in an option that can turn this
behavior 'on' or 'off'. In Asterisk 14 it will default to 'off' meaning
dynamic payload type handling will retain the current behavior (statically
declared). However, in the master branch (what will become Asterisk 15) the
behavior will default to 'on'.

There is one question that merits some discussion though with regards to
the new way of handling the dynamic payloads. Even with a configuration
option available what do people think about having the dynamic payload
types default to the old number originally specified in Asterisk?

So in this case instead of using the first unused dynamic payload number
found it would attempt to use the old number Asterisk used to use when
statically declaring them.

Is there any advantage to falling back to those numbers as defaults for a
given format? Would it lessen the chance of this being a potential breaking
change for people (with the option of course people can always fall back to
the way things used to work if need be)?

[1] https://issues.asterisk.org/jira/browse/ASTERISK-26515

-- 

Kevin Harwell
Digium, Inc. | Software Developer
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] app_queue: RINGNOANSWER event

[Kevin Harwell]

On Thu, Jan 19, 2017 at 12:22 PM, Troy Bowman <t...@lump.net> wrote:

> To me, RINGNOANSWER means that the agent either rejected or let it ring to
> timeout while the caller was waiting.  If the elapsed seconds equals
> timeout, they let it ring and never answered.  If the elapsed seconds is
> under the timeout, they rejected the call.
>
> 
>
> In my opinion, if the caller abandons while we are ringing the agent's
> phone, it is not the agent's fault that the agent didn't pick up.  If a
> RINGNOANSWER would happen in that case, I'd be assigning fault where there
> is none.  In our call center, RINGNOANSWER is a criminal offense.  :)
>

This would be my interpretation as well. That is that RINGNOANSWER implies
that in some way the agent is to blame for the call not connecting.


>
> I sincerely hope we don't change this behavior.
>
> If the impetus for this is to show how long the agent's phone rang, we
> should put that statistic in data4 of ABANDON or something like that,
> because we already identify whether an agent's phone was in the process of
> ringing or being whispered to in ABANDON.  Even RINGCANCELED is misleading
> because the agent did not cancel.  It is still and ABANDON.
>
>
> On Thu, Jan 19, 2017 at 2:59 AM, Tomec Martin <to...@ipex.cz> wrote:
>
>> 
>>
>>
>>
>> So there are 2 ways to move forward:
>>
>> A) Create RINGNOANSWER event after every call end without answer.
>> That breaks backward compatibility for thoose who rely on current behavior.
>>
>> B)  Create new event RINGCANCELED – which can be misleading, because
>> call was not canceled.
>>
>
Between these options I lean toward 'B'. Creating a new event would
hopefully have a minimal amount of side effects. *Hopefully* most
parsers/filters would just ignore the new event.

I agree that RINGCANCELED can be misleading as well. Since ABANDON seems to
mean the caller hung up then how about calling it RINGABANDON instead?

A third option (mentioned on the code review [1] and by Troy) would be to
include the agent name/info in the ABANDON event.

[1] https://gerrit.asterisk.org/#/c/4649/

Kevin Harwell
Digium, Inc. | Software Developer
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] ARI versioning in 13 and 14

[Kevin Harwell]

On Thu, Nov 17, 2016 at 12:32 PM, Mark Michelson <mmichel...@digium.com>
wrote:

>
> 
>
> 2) Bump the major version of ARI for each major release of Asterisk. We
> won't retroactively apply this to the upgrade from Asterisk 12 to Asterisk
> 13. So Asterisk 13 will have ARI versions 1.X.Y, Asterisk 14 will have ARI
> versions 2.X.Y, and Asterisk 15 will end up with Asterisk 3.X.Y
>
>
+1 for option 2.

Kevin Harwell
Digium, Inc. | Software Developer
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] ARI StasisEnd event vs. channel variables

[Kevin Harwell]

On Fri, Oct 21, 2016 at 10:49 AM, Corey Farrell  wrote:

>
> I'm in favor per app config.  I do not yet use ARI, but when I do I
> will have '#tryinclude /etc/asterisk/ari.d/*.conf' in ari.conf.  My
> hope is that each ARI app would install it's own config to
> /etc/asterisk/ari.d, avoid modification of ari.conf / global options.
> Per app config would also be important if dialplan functions can be
> added to StasisEnd.
>
>
This is getting down more into implementation details, but instead of
configs what about adding the desired variables to the event subscribe
command? Each app could subscribe (or when they subscribe) to an event and
specify the variable(s) they desire. At least to start this could be
limited to a small list of allowed events and variables.
-- 
_
-- 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] 4606: chan_sip: make progressinband default to no

[Kevin Harwell]

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

(Updated April 10, 2015, 4:04 p.m.)


Status
--

This change has been marked as submitted.


Review request for Asterisk Developers.


Changes
---

Committed in revision 434654


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


Repository: Asterisk


Description
---

After the progressinband value setting of never was updated to never send a 
183 this separated its use from the no value. Since never was the default, 
but most users probably expect no this patch updates the default for the 
progressinband setting to no.


Diffs
-

  branches/13/configs/samples/sip.conf.sample 434508 
  branches/13/channels/sip/include/sip.h 434508 
  branches/13/channels/chan_sip.c 434508 
  branches/13/CHANGES 434508 

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


Testing
---

Started Asterisk and loaded chan_sip with the new default value for 
progressinband. Check to make sure that is what it was set to. Changed the 
setting to the other values and reloaded/checked between each to make sure 
those got set correctly as well.


Thanks,

Kevin Harwell

-- 
_
-- 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] 4606: chan_sip: make progressinband default to no

[Kevin Harwell]

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

(Updated April 9, 2015, 12:05 p.m.)


Review request for Asterisk Developers.


Changes
---

Addressed review feedback.


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


Repository: Asterisk


Description
---

After the progressinband value setting of never was updated to never send a 
183 this separated its use from the no value. Since never was the default, 
but most users probably expect no this patch updates the default for the 
progressinband setting to no.


Diffs (updated)
-

  branches/13/configs/samples/sip.conf.sample 434508 
  branches/13/channels/sip/include/sip.h 434508 
  branches/13/channels/chan_sip.c 434508 
  branches/13/CHANGES 434508 

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


Testing
---

Started Asterisk and loaded chan_sip with the new default value for 
progressinband. Check to make sure that is what it was set to. Changed the 
setting to the other values and reloaded/checked between each to make sure 
those got set correctly as well.


Thanks,

Kevin Harwell

-- 
_
-- 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] 4606: chan_sip: make progressinband default to no

[Kevin Harwell]

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

Review request for Asterisk Developers.


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


Repository: Asterisk


Description
---

After the progressinband value setting of never was updated to never send a 
183 this separated its use from the no value. Since never was the default, 
but most users probably expect no this patch updates the default for the 
progressinband setting to no.


Diffs
-

  branches/13/configs/samples/sip.conf.sample 434508 
  branches/13/channels/sip/include/sip.h 434508 
  branches/13/channels/chan_sip.c 434508 
  branches/13/CHANGES 434508 

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


Testing
---

Started Asterisk and loaded chan_sip with the new default value for 
progressinband. Check to make sure that is what it was set to. Changed the 
setting to the other values and reloaded/checked between each to make sure 
those got set correctly as well.


Thanks,

Kevin Harwell

-- 
_
-- 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] 4592: chan_pjsip: 183 sent when inband_progress=no

[Kevin Harwell]

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

(Updated April 8, 2015, 12:07 p.m.)


Status
--

This change has been discarded.


Review request for Asterisk Developers.


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


Repository: Asterisk


Description
---

The issue started out as early media not playing in chan_sip. However, it was 
then reported that once the 'progressinband' option was set to 'yes' it would 
work, but that the default behavior was different than that of chan_pjsip. 
chan_pjsip's 'inband_progress' option defaults to 'no' as well, but it still 
sends a 183. It turns out chan_pjsip was always sending a 183 despite whatever 
the 'inband_progress' option was set to. Fixed it so chan_pjsip only sends a 
183 if 'inband_progress' is set to 'yes'.


Diffs
-

  branches/13/channels/chan_pjsip.c 434021 

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


Testing
---

Duplicated the issue with chan_pjsip always sending the 183. After the patch it 
will only send it when 'inband_progress' is set to 'yes'


Thanks,

Kevin Harwell

-- 
_
-- 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] progressinband in chan_sip default value

[Kevin Harwell]

Greetings,

A few months ago an issue [1] was reported that when the progressinband
option found in chan_sip was set to never it was not working correctly in
some scenarios. A fix for the issue was committed [2]. However, the fix had
a side effect of changing the scope of never somewhat and since never
is the default this can potentially cause some confusion or unexpected
behavior when upgrading.

It's believed that changing the default from never to no would be more
appropriate for most users as then progressinband would default to
working similar to how it was before.

Thoughts on this? Leave it defaulting to never? Changing it to no would
be fine?

[1] https://issues.asterisk.org/jira/browse/ASTERISK-23972
[2] https://reviewboard.asterisk.org/r/3700

-- 

Kevin Harwell
Digium, Inc. | Software Developer
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] 4597: res_pjsip: add CLI command to show global and system configuration

[Kevin Harwell]

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

(Updated April 8, 2015, 12:52 p.m.)


Review request for Asterisk Developers.


Changes
---

Updated review and changes description.


Summary (updated)
-

res_pjsip: add CLI command to show global and system configuration


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


Repository: Asterisk


Description (updated)
---

Added a new CLI command for res_pjsip that shows both global and system 
configuration settings:

pjsip show settings


Diffs (updated)
-

  branches/13/res/res_pjsip/include/res_pjsip_private.h 434423 
  branches/13/res/res_pjsip/config_system.c 434423 
  branches/13/res/res_pjsip/config_global.c 434423 
  branches/13/res/res_pjsip.c 434423 
  branches/13/CHANGES 434423 

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


Testing (updated)
---

Ran the command and checked output. Changed some options and reloaded and made 
sure global settings changed, but system ones did not. Changed some settings 
again and restarted and made sure both global and system changes took effect. 
Also removed the sections completely from the pjsip.conf file and made sure the 
defaults were shown.


Thanks,

Kevin Harwell

-- 
_
-- 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] 4575: bridge.c: Hangup attended transfer target after it has been swapped out

[Kevin Harwell]

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

(Updated April 7, 2015, 11:41 a.m.)


Status
--

This change has been marked as submitted.


Review request for Asterisk Developers.


Changes
---

Committed in revision 434240


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


Repository: Asterisk


Description
---

After completing an attended transfer the transfer target channel (the one that 
gets swapped out) was not being hung up after leaving the bridge. This resulted 
in a channel possibly being left around. Added an explicit softhangup for the 
channel in question after the transfer is successfully completed in order to 
make sure the channel is hung up.


Diffs
-

  branches/13/main/bridge.c 433917 

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


Testing
---

There was a testsuite test that initially caught the problem. Ran the modified 
test (had been set to always pass) after applying the patch and it worked as 
expected. Also did some manual testing with different attended transfer 
scenarios.


Thanks,

Kevin Harwell

-- 
_
-- 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] 4597: res_pjsip: add CLI commands for global and system configuration

[Kevin Harwell]

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

(Updated April 7, 2015, 11:05 a.m.)


Review request for Asterisk Developers.


Changes
---

Added text to CHANGES file.


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


Repository: Asterisk


Description
---

Added two new CLI commands for res_pjsip global and system configuration 
settings:

pjsip show global
pjsip show system


Diffs (updated)
-

  branches/13/res/res_pjsip/config_system.c 434150 
  branches/13/res/res_pjsip/config_global.c 434150 
  branches/13/CHANGES 434150 

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


Testing
---

Ran the commands and checked output. Changed some options and reloaded and made 
sure global settings changed, but system ones did not. Changed some settings 
again and restarted and made sure both global and system changes too effect. 
Also removed the sections completely from the pjsip.conf file and made sure the 
defaults were shown.


Thanks,

Kevin Harwell

-- 
_
-- 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] 4598: Refactor duplicated DNS routines into common sections

[Kevin Harwell]

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



/team/group/dns/main/dns_test.c
https://reviewboard.asterisk.org/r/4598/#comment25772

Consider saving the string length to a variable so you won't have to 
calculate it several times.



/trunk/main/dns_core.c
https://reviewboard.asterisk.org/r/4598/#comment25769

No value is set on true.



/trunk/main/dns_naptr.c
https://reviewboard.asterisk.org/r/4598/#comment25770

Extraneous merge nomenclature.


- Kevin Harwell


On April 6, 2015, 5:46 p.m., Mark Michelson wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://reviewboard.asterisk.org/r/4598/
 ---
 
 (Updated April 6, 2015, 5:46 p.m.)
 
 
 Review request for Asterisk Developers.
 
 
 Repository: Asterisk
 
 
 Description
 ---
 
 Josh worked on SRV in one branch, and I worked on NAPTR in a separate branch. 
 Independently we kept coming to realizations that something that one of us 
 had developed independently would be needed by the other person. We decided 
 to simply have copies of common functionality in our branches. After merging, 
 we would perform a refactor to remove duplication.
 
 This changeset introduces no new DNS functionality. Instead, it takes some 
 duplicated code and places them into common areas of the DNS core.
 
 
 Diffs
 -
 
   /trunk/tests/test_dns_srv.c 434186 
   /trunk/tests/test_dns_naptr.c 434186 
   /trunk/main/dns_srv.c 434186 
   /trunk/main/dns_naptr.c 434186 
   /trunk/main/dns_core.c 434186 
   /trunk/include/asterisk/dns_internal.h 434186 
   /team/group/dns/main/dns_test.c PRE-CREATION 
   /team/group/dns/include/asterisk/dns_test.h PRE-CREATION 
 
 Diff: https://reviewboard.asterisk.org/r/4598/diff/
 
 
 Testing
 ---
 
 All DNS unit tests continue to pass.
 
 
 Thanks,
 
 Mark Michelson
 


-- 
_
-- 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] 4597: res_pjsip: add CLI commands for global and system configuration

[Kevin Harwell]

 On April 7, 2015, 1:04 p.m., Mark Michelson wrote:
  branches/13/res/res_pjsip/config_system.c, lines 149-155
  https://reviewboard.asterisk.org/r/4597/diff/2/?file=73683#file73683line149
 
  This should be impossible to happen since default system configuration 
  should automatically get set on start-up if no system section was present 
  in pjsip.conf. If default system configuration setup on startup fails, then 
  res_pjsip.so should fail to load.
  
  I think an assertion here that cfg is non-NULL would do the trick 
  instead of trying again to create default configuration settings

If the system settings are not specified in the config file no default object 
exist, but has to be created from the specified system defaults. Each time 
sorcery allocs an object it creates it and sets its fields to the default 
values. At initialization when no system settings exist an object is created 
with defaults and then applied, but then gets deleted. So in order to access 
the default object again it needs to be re-created.

An alternative would be to keep a global defaults object around, but I don't 
see a reason to maintain that pointer just for CLI use.


- Kevin


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


On April 7, 2015, 11:05 a.m., Kevin Harwell wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://reviewboard.asterisk.org/r/4597/
 ---
 
 (Updated April 7, 2015, 11:05 a.m.)
 
 
 Review request for Asterisk Developers.
 
 
 Bugs: ASTERISK-24918
 https://issues.asterisk.org/jira/browse/ASTERISK-24918
 
 
 Repository: Asterisk
 
 
 Description
 ---
 
 Added two new CLI commands for res_pjsip global and system configuration 
 settings:
 
 pjsip show global
 pjsip show system
 
 
 Diffs
 -
 
   branches/13/res/res_pjsip/config_system.c 434150 
   branches/13/res/res_pjsip/config_global.c 434150 
   branches/13/CHANGES 434150 
 
 Diff: https://reviewboard.asterisk.org/r/4597/diff/
 
 
 Testing
 ---
 
 Ran the commands and checked output. Changed some options and reloaded and 
 made sure global settings changed, but system ones did not. Changed some 
 settings again and restarted and made sure both global and system changes too 
 effect. Also removed the sections completely from the pjsip.conf file and 
 made sure the defaults were shown.
 
 
 Thanks,
 
 Kevin Harwell
 


-- 
_
-- 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] 4597: res_pjsip: add CLI commands for global and system configuration

[Kevin Harwell]

 On April 7, 2015, 2:55 p.m., Olle E Johansson wrote:
  global is used for global variabels. Other CLI commands have show 
  settings - can't we reuse the same with some extra options for system?
 
 rmudgett wrote:
 Where are you getting global variables from the command?
 
 pjsip show global gives the settings for the pjsip.conf [global] 
 section.
 
 The command seems aptly named.
 
 Olle E Johansson wrote:
 core show global has for a long time been used to show global 
 variables. For settings we've used show settings both in core and in SIP - 
 maybe other modules. 
 
 If we are going to use global for something else, then it will be 
 confusing. We only have a global section previously in the dialplan - in 
 other modules it's mostly called general.
 
 But if you already broke this, I rest my case. Just wanted to point out 
 that I feel it's strange.

I tend to agree with both opinions, but since consistency is a good thing and 
doing a quick survey of some other commands most seem to use the show 
settings. Also it allowed me to combine the two commands into one: pjsip show 
settings.


- Kevin


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


On April 7, 2015, 11:05 a.m., Kevin Harwell wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://reviewboard.asterisk.org/r/4597/
 ---
 
 (Updated April 7, 2015, 11:05 a.m.)
 
 
 Review request for Asterisk Developers.
 
 
 Bugs: ASTERISK-24918
 https://issues.asterisk.org/jira/browse/ASTERISK-24918
 
 
 Repository: Asterisk
 
 
 Description
 ---
 
 Added two new CLI commands for res_pjsip global and system configuration 
 settings:
 
 pjsip show global
 pjsip show system
 
 
 Diffs
 -
 
   branches/13/res/res_pjsip/config_system.c 434150 
   branches/13/res/res_pjsip/config_global.c 434150 
   branches/13/CHANGES 434150 
 
 Diff: https://reviewboard.asterisk.org/r/4597/diff/
 
 
 Testing
 ---
 
 Ran the commands and checked output. Changed some options and reloaded and 
 made sure global settings changed, but system ones did not. Changed some 
 settings again and restarted and made sure both global and system changes too 
 effect. Also removed the sections completely from the pjsip.conf file and 
 made sure the defaults were shown.
 
 
 Thanks,
 
 Kevin Harwell
 


-- 
_
-- 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] 4597: res_pjsip: add CLI commands for global and system configuration

[Kevin Harwell]

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

(Updated April 7, 2015, 5:35 p.m.)


Review request for Asterisk Developers.


Changes
---

Combined the two commands into a single one: 'pjsip show settings'


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


Repository: Asterisk


Description
---

Added two new CLI commands for res_pjsip global and system configuration 
settings:

pjsip show global
pjsip show system


Diffs (updated)
-

  branches/13/res/res_pjsip/include/res_pjsip_private.h 434150 
  branches/13/res/res_pjsip/config_system.c 434150 
  branches/13/res/res_pjsip/config_global.c 434150 
  branches/13/res/res_pjsip.c 434150 
  branches/13/CHANGES 434150 

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


Testing
---

Ran the commands and checked output. Changed some options and reloaded and made 
sure global settings changed, but system ones did not. Changed some settings 
again and restarted and made sure both global and system changes too effect. 
Also removed the sections completely from the pjsip.conf file and made sure the 
defaults were shown.


Thanks,

Kevin Harwell

-- 
_
-- 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] 4598: Refactor duplicated DNS routines into common sections

[Kevin Harwell]

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

Ship it!



/trunk/main/dns_test.c
https://reviewboard.asterisk.org/r/4598/#comment25786

moar nitpicking :-) this could be changed to actual_len as well if you were 
so inclined.


- Kevin Harwell


On April 7, 2015, 12:49 p.m., Mark Michelson wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://reviewboard.asterisk.org/r/4598/
 ---
 
 (Updated April 7, 2015, 12:49 p.m.)
 
 
 Review request for Asterisk Developers.
 
 
 Repository: Asterisk
 
 
 Description
 ---
 
 Josh worked on SRV in one branch, and I worked on NAPTR in a separate branch. 
 Independently we kept coming to realizations that something that one of us 
 had developed independently would be needed by the other person. We decided 
 to simply have copies of common functionality in our branches. After merging, 
 we would perform a refactor to remove duplication.
 
 This changeset introduces no new DNS functionality. Instead, it takes some 
 duplicated code and places them into common areas of the DNS core.
 
 
 Diffs
 -
 
   /trunk/tests/test_dns_srv.c 434218 
   /trunk/tests/test_dns_naptr.c 434218 
   /trunk/main/dns_test.c PRE-CREATION 
   /trunk/main/dns_srv.c 434218 
   /trunk/main/dns_naptr.c 434218 
   /trunk/main/dns_core.c 434218 
   /trunk/include/asterisk/dns_test.h PRE-CREATION 
   /trunk/include/asterisk/dns_internal.h 434218 
 
 Diff: https://reviewboard.asterisk.org/r/4598/diff/
 
 
 Testing
 ---
 
 All DNS unit tests continue to pass.
 
 
 Thanks,
 
 Mark Michelson
 


-- 
_
-- 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] 4592: chan_pjsip: 183 sent when inband_progress=no

[Kevin Harwell]

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

Review request for Asterisk Developers.


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


Repository: Asterisk


Description
---

The issue started out as early media not playing in chan_sip. However, it was 
then reported that once the 'progressinband' option was set to 'yes' it would 
work, but that the default behavior was different than that of chan_pjsip. 
chan_pjsip's 'inband_progress' option defaults to 'no' as well, but it still 
sends a 183. It turns out chan_pjsip was always sending a 183 despite whatever 
the 'inband_progress' option was set to. Fixed it so chan_pjsip only sends a 
183 if 'inband_progress' is set to 'yes'.


Diffs
-

  branches/13/channels/chan_pjsip.c 434021 

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


Testing
---

Duplicated the issue with chan_pjsip always sending the 183. After the patch it 
will only send it when 'inband_progress' is set to 'yes'


Thanks,

Kevin Harwell

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

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

[asterisk-dev] Change in testsuite[master]: non_stasis_bridge_to_stasis_bridge: Update regex for ami events

[Kevin Harwell (Code Review)]

Kevin Harwell has uploaded a new patch set (#3).

Change subject: non_stasis_bridge_to_stasis_bridge: Update regex for ami events
..

non_stasis_bridge_to_stasis_bridge: Update regex for ami events

Due to a bug in Asterisk, in some cases, the channel would not be hung up after
leaving the bridge upon completing an attended transfer. With that fixed this
test can now be expected to pass, so the 'expected-result: False' has been
removed. Also a couple of events attempted to match against the wrong regex,
so those were modified accordingly.

Change-Id: I0a3bcb1a0df7e7bdca02be827288f5f08b5140ce
---
M 
tests/rest_api/external_interaction/attended_transfer/non_stasis_bridge_to_stasis_bridge/test-config.yaml
1 file changed, 4 insertions(+), 7 deletions(-)


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

Gerrit-MessageType: newpatchset
Gerrit-Change-Id: I0a3bcb1a0df7e7bdca02be827288f5f08b5140ce
Gerrit-PatchSet: 3
Gerrit-Project: testsuite
Gerrit-Branch: master
Gerrit-Owner: Kevin Harwell kharw...@digium.com
Gerrit-Reviewer: Ashley Sanders asand...@digium.com
Gerrit-Reviewer: Corey Farrell g...@cfware.com
Gerrit-Reviewer: John Bigelow jbige...@digium.com
Gerrit-Reviewer: Kevin Harwell kharw...@digium.com

-- 
_
-- 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] 4582: res_pjsip: config option 'timers' can't be set to 'no'

[Kevin Harwell]

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

(Updated April 6, 2015, 2:23 p.m.)


Status
--

This change has been marked as submitted.


Review request for Asterisk Developers.


Changes
---

Committed in revision 434131


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


Repository: Asterisk


Description
---

When setting the configuration option 'timers' equal to 'no' the bit flag was 
not properly negated. This patch clears all associated flags and only sets the 
specified one. pjsip will handle any necessary flag combinations. Also went 
ahead and did similar for the '100rel' option.


Diffs
-

  branches/13/res/res_pjsip/pjsip_configuration.c 433966 
  branches/13/res/res_pjsip.c 433966 

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


Testing
---

Made sure the option can now be set to 'no' and that it clears the bit. Also 
set it to the other values and reloaded to make sure the field was updated 
correctly.


Thanks,

Kevin Harwell

-- 
_
-- 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] 4597: res_pjsip: add CLI commands for global and system configuration

[Kevin Harwell]

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

Review request for Asterisk Developers.


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


Repository: Asterisk


Description
---

Added two new CLI commands for res_pjsip global and system configuration 
settings:

pjsip show global
pjsip show system


Diffs
-

  branches/13/res/res_pjsip/config_system.c 434150 
  branches/13/res/res_pjsip/config_global.c 434150 

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


Testing
---

Ran the commands and checked output. Changed some options and reloaded and made 
sure global settings changed, but system ones did not. Changed some settings 
again and restarted and made sure both global and system changes too effect. 
Also removed the sections completely from the pjsip.conf file and made sure the 
defaults were shown.


Thanks,

Kevin Harwell

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

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

[asterisk-dev] Change in testsuite[master]: non_stasis_bridge_to_stasis_bridge: Update regex for ami events

[Kevin Harwell (Code Review)]

Kevin Harwell has posted comments on this change.

Change subject: non_stasis_bridge_to_stasis_bridge: Update regex for ami events
..


Patch Set 3:

Updated the per review based on feedback and other findings.

A couple of things:
1. I am an idiot and my eyes were playing tricks on me, but there is actually 
nothing wrong with the regex parsing of '-'. The regex on those particular 
events were missing some text.

2. To answer John and Corey's question about why that particular event action 
was moved: There original reason was after applying the Asterisk fix the test 
was still failing due to what seemed like bob being hung up too early. I moved 
it thinking there might have been bit of a race between events, but it turned 
out the problem was due to the regex being wrong on some events. Then I forgot 
to move it back. I've now moved it back and will leave the comment there since 
it applies again.

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

Gerrit-MessageType: comment
Gerrit-Change-Id: I0a3bcb1a0df7e7bdca02be827288f5f08b5140ce
Gerrit-PatchSet: 3
Gerrit-Project: testsuite
Gerrit-Branch: master
Gerrit-Owner: Kevin Harwell kharw...@digium.com
Gerrit-Reviewer: Ashley Sanders asand...@digium.com
Gerrit-Reviewer: Corey Farrell g...@cfware.com
Gerrit-Reviewer: John Bigelow jbige...@digium.com
Gerrit-Reviewer: Kevin Harwell kharw...@digium.com
Gerrit-HasComments: No

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

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

[asterisk-dev] Change in testsuite[master]: non_stasis_bridge_to_stasis_bridge: Update regex for ami events

[Kevin Harwell (Code Review)]

Hello Ashley Sanders, Corey Farrell,

I'd like you to reexamine a change.  Please visit

https://gerrit.asterisk.org/25

to look at the new patch set (#3).

Change subject: non_stasis_bridge_to_stasis_bridge: Update regex for ami events
..

non_stasis_bridge_to_stasis_bridge: Update regex for ami events

Due to a bug in Asterisk, in some cases, the channel would not be hung up after
leaving the bridge upon completing an attended transfer. With that fixed this
test can now be expected to pass, so the 'expected-result: False' has been
removed. Also a couple of events attempted to match against the wrong regex,
so those were modified accordingly.

Change-Id: I0a3bcb1a0df7e7bdca02be827288f5f08b5140ce
---
M 
tests/rest_api/external_interaction/attended_transfer/non_stasis_bridge_to_stasis_bridge/test-config.yaml
1 file changed, 4 insertions(+), 7 deletions(-)


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

Gerrit-MessageType: newpatchset
Gerrit-Change-Id: I0a3bcb1a0df7e7bdca02be827288f5f08b5140ce
Gerrit-PatchSet: 3
Gerrit-Project: testsuite
Gerrit-Branch: master
Gerrit-Owner: Kevin Harwell kharw...@digium.com
Gerrit-Reviewer: Ashley Sanders asand...@digium.com
Gerrit-Reviewer: Corey Farrell g...@cfware.com
Gerrit-Reviewer: John Bigelow jbige...@digium.com

-- 
_
-- 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] 4582: res_pjsip: config option 'timers' can't be set to 'no'

[Kevin Harwell]

 On April 3, 2015, 4:28 p.m., rmudgett wrote:
  branches/13/res/res_pjsip/pjsip_configuration.c, lines 152-153
  https://reviewboard.asterisk.org/r/4582/diff/1/?file=73574#file73574line152
 
  Are the flags exclusive to each other?
  Maybe SUPPORT is needed to enable the functionality and REQUIRE to make 
  it mandatory.

I looked at the pjsip code and they seem to take care of adding the other flags 
if needed, so I figured to just let them handle it.


- Kevin


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


On April 3, 2015, 2:58 p.m., Kevin Harwell wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://reviewboard.asterisk.org/r/4582/
 ---
 
 (Updated April 3, 2015, 2:58 p.m.)
 
 
 Review request for Asterisk Developers.
 
 
 Bugs: ASTERISK-24910
 https://issues.asterisk.org/jira/browse/ASTERISK-24910
 
 
 Repository: Asterisk
 
 
 Description
 ---
 
 When setting the configuration option 'timers' equal to 'no' the bit flag was 
 not properly negated. This patch clears all associated flags and only sets 
 the specified one. pjsip will handle any necessary flag combinations. Also 
 went ahead and did similar for the '100rel' option.
 
 
 Diffs
 -
 
   branches/13/res/res_pjsip/pjsip_configuration.c 433966 
 
 Diff: https://reviewboard.asterisk.org/r/4582/diff/
 
 
 Testing
 ---
 
 Made sure the option can now be set to 'no' and that it clears the bit. Also 
 set it to the other values and reloaded to make sure the field was updated 
 correctly.
 
 
 Thanks,
 
 Kevin Harwell
 


-- 
_
-- 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] 4582: res_pjsip: config option 'timers' can't be set to 'no'

[Kevin Harwell]

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

(Updated April 3, 2015, 5:25 p.m.)


Review request for Asterisk Developers.


Changes
---

Addressed feedback.


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


Repository: Asterisk


Description
---

When setting the configuration option 'timers' equal to 'no' the bit flag was 
not properly negated. This patch clears all associated flags and only sets the 
specified one. pjsip will handle any necessary flag combinations. Also went 
ahead and did similar for the '100rel' option.


Diffs (updated)
-

  branches/13/res/res_pjsip/pjsip_configuration.c 433966 
  branches/13/res/res_pjsip.c 433966 

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


Testing
---

Made sure the option can now be set to 'no' and that it clears the bit. Also 
set it to the other values and reloaded to make sure the field was updated 
correctly.


Thanks,

Kevin Harwell

-- 
_
-- 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] 4582: res_pjsip: config option 'timers' can't be set to 'no'

[Kevin Harwell]

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

(Updated April 3, 2015, 5:52 p.m.)


Review request for Asterisk Developers.


Changes
---

Added description in the enumeration doc field for forced stating that it is 
an alias of always.


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


Repository: Asterisk


Description
---

When setting the configuration option 'timers' equal to 'no' the bit flag was 
not properly negated. This patch clears all associated flags and only sets the 
specified one. pjsip will handle any necessary flag combinations. Also went 
ahead and did similar for the '100rel' option.


Diffs (updated)
-

  branches/13/res/res_pjsip/pjsip_configuration.c 433966 
  branches/13/res/res_pjsip.c 433966 

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


Testing
---

Made sure the option can now be set to 'no' and that it clears the bit. Also 
set it to the other values and reloaded to make sure the field was updated 
correctly.


Thanks,

Kevin Harwell

-- 
_
-- 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] 4577: res_pjsip_t38: T38 fax fails when using authentication with PJSIP sender

[Kevin Harwell]

 On April 2, 2015, 6:13 p.m., Kevin Harwell wrote:
  It is probably always the case that framehooks should not be attached 
  twice. If this is true then it might be better to add a check in 
  'ast_framehook_attach' that first makes sure the hook is not already in the 
  list. If so don't add it again.
 
 rmudgett wrote:
 It is specific framehooks that cannot be attached twice.  It is not a 
 general requirement/property of the framehook concept.

Just curious, but what's a case where a framehook should be attached twice?


- Kevin


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


On April 2, 2015, 2:08 p.m., Jonathan Rose wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://reviewboard.asterisk.org/r/4577/
 ---
 
 (Updated April 2, 2015, 2:08 p.m.)
 
 
 Review request for Asterisk Developers and Joshua Colp.
 
 
 Bugs: ASTERISK-24933
 https://issues.asterisk.org/jira/browse/ASTERISK-24933
 
 
 Repository: Asterisk
 
 
 Description
 ---
 
 Description:
 Two Asterisk boxes each have the other as endpoints with authentication set.
 First Asterisk box originates a call to the second using the PJSIP endpoint.
 The first Asterisk box uses an extension with sendfax, the second uses
 an extension with receivefax.
 
 The session starts fairly normally, but resolution never appears in fax show
 session output. After a while (~25 seconds) the call drops and the fax fails.
 Error messages shown are as follows:
 Sender: The call dropped prematurely
 Receiver: Disconnected after permitted retries
 
 Note that when not using authentication, the FAX will complete as expected.
 When using chan_sip as the sender to a receiver of chan_pjsip, the FAX will
 also complete as expected with authentication, but if chan_pjsip is the sender
 it will fail regardless of whether the recipient is chan_sip or chan_pjsip.
 
 The problem is caused by duplication of a framehook in res_pjsip_t38 which
 occurs on the second invite sent out when responding to the auth challenge.
 
 Fix:
 In order to fix this, I added a simple flag to the pjsip session struct that 
 would
 be raised when the framehook is first attached to prevent duplication. I 
 wouldn't
 be surprised if there were a better way to do this.
 
 
 Diffs
 -
 
   /certified/branches/13.1/res/res_pjsip_t38.c 433316 
   /certified/branches/13.1/include/asterisk/res_pjsip_session.h 433316 
 
 Diff: https://reviewboard.asterisk.org/r/4577/diff/
 
 
 Testing
 ---
 
 I've duplicated and modified the t38 PJSIP fax test in the testsuite to 
 include authentication. It fails without the patch and passes with the patch. 
 I also tested this locally with my two Asterisk machines in the above 
 scenario. I'll be linking the test after putting it on Gerrit.
 
 
 Thanks,
 
 Jonathan Rose
 


-- 
_
-- 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] 4575: bridge.c: Hangup attended transfer target after it has been swapped out

[Kevin Harwell]

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

Review request for Asterisk Developers.


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


Repository: Asterisk


Description
---

After completing an attended transfer the transfer target channel (the one that 
gets swapped out) was not being hung up after leaving the bridge. This resulted 
in a channel possibly being left around. Added an explicit softhangup for the 
channel in question after the transfer is successfully completed in order to 
make sure the channel is hung up.


Diffs
-

  branches/13/main/bridge.c 433917 

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


Testing
---

There was a testsuite test that initially caught the problem. Ran the modified 
test (had been set to always pass) after applying the patch and it worked as 
expected. Also did some manual testing with different attended transfer 
scenarios.


Thanks,

Kevin Harwell

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

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

[asterisk-dev] Change in testsuite[master]: non_stasis_bridge_to_stasis_bridge: Update regex for ami events

[Kevin Harwell (Code Review)]

Kevin Harwell has uploaded a new patch set (#2).

Change subject: non_stasis_bridge_to_stasis_bridge: Update regex for ami events
..

non_stasis_bridge_to_stasis_bridge: Update regex for ami events

Due to a bug in Asterisk, in some cases, the channel would not be hung up after
leaving the bridge upon completing an attended transfer. With that fixed this
test can now be expected to pass. However there were a few spots where the ami
event matching class had trouble matching events with a '-' included. Removed
the '-' to no longer be part of the search criteria. The test now works as
expected.

Change-Id: I0a3bcb1a0df7e7bdca02be827288f5f08b5140ce
---
M 
tests/rest_api/external_interaction/attended_transfer/non_stasis_bridge_to_stasis_bridge/test-config.yaml
1 file changed, 9 insertions(+), 11 deletions(-)


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

Gerrit-MessageType: newpatchset
Gerrit-Change-Id: I0a3bcb1a0df7e7bdca02be827288f5f08b5140ce
Gerrit-PatchSet: 2
Gerrit-Project: testsuite
Gerrit-Branch: master
Gerrit-Owner: Kevin Harwell kharw...@digium.com

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

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

[asterisk-dev] Change in testsuite[master]: non_stasis_bridge_to_stasis_bridge: Update regex for ami events

[Kevin Harwell (Code Review)]

Kevin Harwell has uploaded a new change for review.

  https://gerrit.asterisk.org/25

Change subject: non_stasis_bridge_to_stasis_bridge: Update regex for ami events
..

non_stasis_bridge_to_stasis_bridge: Update regex for ami events

Due to a bug in Asterisk, in some cases, the channel would not be hung up after
leaving the bridge upon completing an attended transfer. With that fixed this
test can now be expected to pass. However there were a few spots where the ami
event matching class had trouble matching events with a '-' included. Removed
the '-' to no longer be part of the search criteria. The test now works as
expected.

Change-Id: I0a3bcb1a0df7e7bdca02be827288f5f08b5140ce
---
M 
tests/rest_api/external_interaction/attended_transfer/non_stasis_bridge_to_stasis_bridge/test-config.yaml
1 file changed, 11 insertions(+), 9 deletions(-)


  git pull ssh://gerrit.asterisk.org:29418/testsuite refs/changes/25/25/1

diff --git 
a/tests/rest_api/external_interaction/attended_transfer/non_stasis_bridge_to_stasis_bridge/test-config.yaml
 
b/tests/rest_api/external_interaction/attended_transfer/non_stasis_bridge_to_stasis_bridge/test-config.yaml
index 97009bb..009ea99 100644
--- 
a/tests/rest_api/external_interaction/attended_transfer/non_stasis_bridge_to_stasis_bridge/test-config.yaml
+++ 
b/tests/rest_api/external_interaction/attended_transfer/non_stasis_bridge_to_stasis_bridge/test-config.yaml
@@ -44,6 +44,7 @@
 typename: 'pluggable_modules.EventActionModule'
 
 test-object-config:
+#reactor-timeout: 60
 apps: testsuite
 test-iterations:
 -
@@ -273,6 +274,11 @@
 channel:
 name: 'Local/_attended@transfer-.*;2'
 count: 1
+ami-actions:
+action:
+   action: 'Hangup'
+   channel: '/^PJSIP/bob-.*$/'
+
 # Ensure alice's second channel exits the Stasis app. Then hang up bob.
 -
 ari-events:
@@ -282,10 +288,6 @@
 channel:
 name: 'PJSIP/alice-.*'
 count: 1
-ami-actions:
-action:
-   action: 'Hangup'
-   channel: '/^PJSIP/bob-.*$/'
 # Upon hanging up bob, ensure bob leaves the non-Stasis bridge and is hung
 # up.
 -
@@ -311,7 +313,7 @@
 conditions:
 match:
 Event: 'BridgeLeave'
-Channel: 'Local/_attended-.*;1'
+Channel: 'Local/_attended.*;1'
 nomatch:
 BridgeUniqueid: 'test_bridge'
 count: 1
@@ -320,7 +322,7 @@
 conditions:
 match:
 Event: 'Hangup'
-Channel: 'Local/_attended-.*;1'
+Channel: 'Local/_attended.*;1'
 count: 1
 # Ensure the local channel half in Stasis bridge with carol leaves the
 # bridge.
@@ -332,7 +334,7 @@
 bridge:
 id: 'test_bridge'
 channel:
-name: 'Local/_attended-.*;2'
+name: 'Local/_attended.*;2'
 count: 1
 # Ensure the local channel half in Stasis bridge with carol exits the
 # Stasis app. Then hang up carol.
@@ -342,7 +344,7 @@
 type: StasisEnd
 application: 'testsuite'
 channel:
-name: 'Local/_attended-.*;2'
+name: 'Local/_attended.*;2'
 count: 1
 ari-requests:
 method: 'delete'
@@ -394,5 +396,5 @@
 - ARI
 - pjsip
 # Expect test to fail until ASTERISK-24782 is resolved.
-expected-result: False
+#expected-result: False
 

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

Gerrit-MessageType: newchange
Gerrit-Change-Id: I0a3bcb1a0df7e7bdca02be827288f5f08b5140ce
Gerrit-PatchSet: 1
Gerrit-Project: testsuite
Gerrit-Branch: master
Gerrit-Owner: Kevin Harwell kharw...@digium.com

-- 
_
-- 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] 4577: res_pjsip_t38: T38 fax fails when using authentication with PJSIP sender

[Kevin Harwell]

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


It is probably always the case that framehooks should not be attached twice. If 
this is true then it might be better to add a check in 'ast_framehook_attach' 
that first makes sure the hook is not already in the list. If so don't add it 
again.

- Kevin Harwell


On April 2, 2015, 2:08 p.m., Jonathan Rose wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://reviewboard.asterisk.org/r/4577/
 ---
 
 (Updated April 2, 2015, 2:08 p.m.)
 
 
 Review request for Asterisk Developers and Joshua Colp.
 
 
 Bugs: ASTERISK-24933
 https://issues.asterisk.org/jira/browse/ASTERISK-24933
 
 
 Repository: Asterisk
 
 
 Description
 ---
 
 Description:
 Two Asterisk boxes each have the other as endpoints with authentication set.
 First Asterisk box originates a call to the second using the PJSIP endpoint.
 The first Asterisk box uses an extension with sendfax, the second uses
 an extension with receivefax.
 
 The session starts fairly normally, but resolution never appears in fax show
 session output. After a while (~25 seconds) the call drops and the fax fails.
 Error messages shown are as follows:
 Sender: The call dropped prematurely
 Receiver: Disconnected after permitted retries
 
 Note that when not using authentication, the FAX will complete as expected.
 When using chan_sip as the sender to a receiver of chan_pjsip, the FAX will
 also complete as expected with authentication, but if chan_pjsip is the sender
 it will fail regardless of whether the recipient is chan_sip or chan_pjsip.
 
 The problem is caused by duplication of a framehook in res_pjsip_t38 which
 occurs on the second invite sent out when responding to the auth challenge.
 
 Fix:
 In order to fix this, I added a simple flag to the pjsip session struct that 
 would
 be raised when the framehook is first attached to prevent duplication. I 
 wouldn't
 be surprised if there were a better way to do this.
 
 
 Diffs
 -
 
   /certified/branches/13.1/res/res_pjsip_t38.c 433316 
   /certified/branches/13.1/include/asterisk/res_pjsip_session.h 433316 
 
 Diff: https://reviewboard.asterisk.org/r/4577/diff/
 
 
 Testing
 ---
 
 I've duplicated and modified the t38 PJSIP fax test in the testsuite to 
 include authentication. It fails without the patch and passes with the patch. 
 I also tested this locally with my two Asterisk machines in the above 
 scenario. I'll be linking the test after putting it on Gerrit.
 
 
 Thanks,
 
 Jonathan Rose
 


-- 
_
-- 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] 4542: DNS: Add NAPTR support and tests

[Kevin Harwell]

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

Ship it!


Ship It!

- Kevin Harwell


On April 1, 2015, 9:51 a.m., Mark Michelson wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://reviewboard.asterisk.org/r/4542/
 ---
 
 (Updated April 1, 2015, 9:51 a.m.)
 
 
 Review request for Asterisk Developers.
 
 
 Repository: Asterisk
 
 
 Description
 ---
 
 This adds NAPTR support for DNS in Asterisk.
 
 The main parts of this are the functions for allocating a DNS NAPTR record 
 when a resolver wishes to add a NAPTR record, the sorting algorithm for 
 sorting DNS NAPTR records, and the tests that use a mock DNS resolver.
 
 NOTE: There is likely to be some overlap here in this review and Josh's SRV 
 review (/r/4528). Our stance on this is that we will factor out the 
 duplicated code once both SRV and NAPTR have been merged into the main DNS 
 branch. The factoring out of common functions will be placed in its own 
 review.
 
 
 Diffs
 -
 
   /team/group/dns/tests/test_dns_naptr.c PRE-CREATION 
   /team/group/dns/res/res_resolver_unbound.c 433885 
   /team/group/dns/main/dns_naptr.c 433885 
   /team/group/dns/main/dns_core.c 433885 
   /team/group/dns/include/asterisk/dns_internal.h 433885 
 
 Diff: https://reviewboard.asterisk.org/r/4542/diff/
 
 
 Testing
 ---
 
 All previous DNS tests continue to pass, and all new tests added in this 
 review pass as well.
 
 
 Thanks,
 
 Mark Michelson
 


-- 
_
-- 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] 4542: DNS: Add NAPTR support and tests

[Kevin Harwell]

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



/team/group/dns/include/asterisk/dns_internal.h
https://reviewboard.asterisk.org/r/4542/#comment25605

These methods should not start with ast_* unless they are meant to be 
exposed externally/exported. If they are then they should be moved to a more 
public include file.



/team/group/dns/main/dns_naptr.c
https://reviewboard.asterisk.org/r/4542/#comment25604

This seems like it should be a non assert check. What happens if asterisk 
is not compiled without debug on and this is false?



/team/group/dns/res/res_resolver_unbound.c
https://reviewboard.asterisk.org/r/4542/#comment25608

Any reason to continue if a failure occurs?



/team/group/dns/tests/test_dns_naptr.c
https://reviewboard.asterisk.org/r/4542/#comment25606

Should these failures break the loop and just goto cleanup as well?


- Kevin Harwell


On March 27, 2015, 9:45 a.m., Mark Michelson wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://reviewboard.asterisk.org/r/4542/
 ---
 
 (Updated March 27, 2015, 9:45 a.m.)
 
 
 Review request for Asterisk Developers.
 
 
 Repository: Asterisk
 
 
 Description
 ---
 
 This adds NAPTR support for DNS in Asterisk.
 
 The main parts of this are the functions for allocating a DNS NAPTR record 
 when a resolver wishes to add a NAPTR record, the sorting algorithm for 
 sorting DNS NAPTR records, and the tests that use a mock DNS resolver.
 
 NOTE: There is likely to be some overlap here in this review and Josh's SRV 
 review (/r/4528). Our stance on this is that we will factor out the 
 duplicated code once both SRV and NAPTR have been merged into the main DNS 
 branch. The factoring out of common functions will be placed in its own 
 review.
 
 
 Diffs
 -
 
   /team/group/dns/tests/test_dns_naptr.c PRE-CREATION 
   /team/group/dns/res/res_resolver_unbound.c 433573 
   /team/group/dns/main/dns_naptr.c 433573 
   /team/group/dns/main/dns_core.c 433573 
   /team/group/dns/include/asterisk/dns_internal.h 433573 
 
 Diff: https://reviewboard.asterisk.org/r/4542/diff/
 
 
 Testing
 ---
 
 All previous DNS tests continue to pass, and all new tests added in this 
 review pass as well.
 
 
 Thanks,
 
 Mark Michelson
 


-- 
_
-- 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] 4520: Testsuite: stasis: set a channel variable on websocket disconnect error

[Kevin Harwell]

 On March 24, 2015, 1:15 p.m., Kevin Harwell wrote:
  ./asterisk/trunk/tests/rest_api/applications/stasis_status/test_case.py, 
  lines 22-23
  https://reviewboard.asterisk.org/r/4520/diff/1/?file=72750#file72750line22
 
  A lot of the code in this object as well as others (AriClient, 
  ObservableObject) looks similar to much of the code found in the 
  AriTestObject or AriBaseTestObject.
  
  I'm thinking you can inherit instead from one of those two ARI test 
  objects and simplify things greatly, overriding/adding methods where 
  needed. You might even be able to get away with using the 
  WebSocketEventModule and handling things like adding a channel to a bridge 
  or disconnecting the websocket in raised callbacks. At least for a couple 
  of these scenarios. For that though you would have to break the scenarios 
  into separate tests.
 
 Ashley Sanders wrote:
 The issue with using the AriBaseTestObject (or any of its derived types) 
 was that there are certain events that I must intercept to start monitoring 
 for the channel variable in unusual ways. Also, I have the need to exercise 
 ARI after I blow away the websocket out from underneath it.
 
 Having said that, there are many things in these classes that could be 
 pulled up into one of the generalized classes (e.g. the observer logic, the 
 channel variable monitor, the base test scenario class and the test case 
 itself - assuming I change its name to something more generic.)
 
 At this point, I think I am going to defer to Matt's comment from another 
 issue in this review (in a nutshell, he stated that pulling everything up at 
 this point is overkill):
 --- mjordan comment begin here ---
I don't disagree that this *could* go in that direction. But for it to 
 be truly generic, you'd want to:
(a) As you noted, change some of the naming and place it in 
 lib/python/asterisk
(b) Have it be a test object in the pluggable framework, which would 
 have to take some careful thought about how it could be configured to look at 
 a particular
set of scenarios. Generally, once we have a 'generic' piece of 
 functionality, we'd want for it to be instantiated via the TestRunner, and 
 then have either 
other pluggable modules attach into it, or have small Python 
 modules provided by the test attach to it.
 
I do think having the scenario factory function get put into here 
 would be fine. 
 
Overall, once you've got a reason to pull it out of run-test, I'm not 
 against it - but I'm not sure this review is at that point.
 
The other direction you could take would be fully pull it out in this 
 review, make it generic, and put it in lib/python/asterisk. But that might be 
 more work
than is necessary at this point, and since we don't have a second test 
 (yet!) that would make use of it, I'm not sure it is warranted.
 --- mjordan comment end here ---

That's fair enough. It looked like for the couple of test cases you had 
implemented you could get away with using one of the current ARI test objects 
as you can register to receive various events and you should also have access 
to the websocket in order to disconnect it when needed, but it sounds like you 
are still adding scenarios that might not fit as neatly. So I agree with Matt 
that merging that functionality (making it generic) for those changes into the 
current classes can be done later.


- Kevin


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


On March 27, 2015, 10:58 a.m., Ashley Sanders wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://reviewboard.asterisk.org/r/4520/
 ---
 
 (Updated March 27, 2015, 10:58 a.m.)
 
 
 Review request for Asterisk Developers.
 
 
 Bugs: ASTERISK-24802
 https://issues.asterisk.org/jira/browse/ASTERISK-24802
 
 
 Repository: testsuite
 
 
 Description
 ---
 
 When an error occurs while writing to a web socket, the web socket is 
 disconnected and the event is logged. A side-effect of this, however, is that 
 any application on the other side waiting for a response from Stasis is left 
 hanging indefinitely (as there is no mechanism presently available for 
 notifying interested parties about web socket error states in Stasis).
 
 This patch introduces a new channel variable: STASISSTATUS to give outside 
 applications context when errors occur in Stasis that interrupt normal 
 processing.
 
 This test exercises two scenarios to elicit updates to the STASISSTATUS 
 channel variable:
 1) The 'Bugs' scenario: tests the situation where a call is originated 
 requesting an app that was never

Re: [asterisk-dev] [Code Review] 4523: res_pjsip_registrar_expire.c: Cleanup scheduler leaks on unload/shutdown.

[Kevin Harwell]

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

Ship it!


Ship It!

- Kevin Harwell


On March 26, 2015, 11:46 a.m., rmudgett wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://reviewboard.asterisk.org/r/4523/
 ---
 
 (Updated March 26, 2015, 11:46 a.m.)
 
 
 Review request for Asterisk Developers.
 
 
 Repository: Asterisk
 
 
 Description
 ---
 
 Contact expiration object refs were leaked when the module was unloaded.
 
 * Made empty the scheduler of entries before destroying it to release the
 object ref held by the scheduler entry.
 
 
 Diffs
 -
 
   /branches/13/res/res_pjsip_registrar_expire.c 433444 
 
 Diff: https://reviewboard.asterisk.org/r/4523/diff/
 
 
 Testing
 ---
 
 Before the patch valgrind reported struct contact_expiration object memory 
 leaks.
 After the patch valgrind no longer reports those leaks.
 
 
 Thanks,
 
 rmudgett
 


-- 
_
-- 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] 4477: app_confbridge (11): file playback blocks dtmf

[Kevin Harwell]

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

(Updated March 26, 2015, noon)


Status
--

This change has been marked as submitted.


Review request for Asterisk Developers.


Changes
---

Committed in revision 433445


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


Repository: Asterisk


Description
---

Attempting to execute DTMF in a confbridge while file playback (prompt, 
announcement, etc) is occurring is not allowed. You have to wait until the 
sound file has completed before entering DTMF. This patch fixes it so that 
app_confbridge now monitors for dtmf key presses during file playback. If a key 
is pressed playback stops and it executes the matched menu option.


Diffs
-

  branches/11/apps/app_confbridge.c 433195 

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


Testing
---

Manual testing done. Setup a basic conference bridge that allowed both regular 
and admin users to enter. Ran through various menu options to make sure the 
sound file playback would stop (no longer have to wait) and a new option was 
executed when appropriate. Also ran the app_confbridge testsuite tests to make 
sure they still passed.


Thanks,

Kevin Harwell

-- 
_
-- 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] 4510: app_confbridge (13): file playback blocks dtmf

[Kevin Harwell]

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

(Updated March 26, 2015, 12:04 p.m.)


Status
--

This change has been marked as submitted.


Review request for Asterisk Developers.


Changes
---

Committed in revision 433446


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


Repository: Asterisk


Description
---

This is the Asterisk 13 version of the following: 
https://reviewboard.asterisk.org/r/4477/

Attempting to execute DTMF in a confbridge while file playback (prompt, 
announcement, etc) is occurring is not allowed. You have to wait until the 
sound file has completed before entering DTMF. This patch fixes it so that 
app_confbridge now monitors for dtmf key presses during file playback. If a key 
is pressed playback stops and it executes the matched menu option. Unlike the 
Asterisk 11 patch this version does not re-queue the dtmf frame, but instead 
uses an already available function that monitors for dtmf presses during 
playback.


Diffs
-

  branches/13/main/bridge_channel.c 433344 
  branches/13/include/asterisk/bridge_channel.h 433344 
  branches/13/apps/app_confbridge.c 433344 

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


Testing
---

Manual testing done. Setup a basic conference bridge that allowed both regular 
and admin users to enter. Ran through various menu options to make sure the 
sound file playback would stop (no longer have to wait) and a new option was 
executed when appropriate. Also ran the app_confbridge testsuite tests to make 
sure they still passed.


Thanks,

Kevin Harwell

-- 
_
-- 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] 4510: app_confbridge (13): file playback blocks dtmf

[Kevin Harwell]

 On March 24, 2015, 12:01 p.m., rmudgett wrote:
  branches/13/main/bridge_channel.c, line 1575
  https://reviewboard.asterisk.org/r/4510/diff/2/?file=72687#file72687line1575
 
  Just
  if (digit)
  is sufficient.
  
  If anything, you should assert:
  ast_assert(0 = digit)
  because passing in a negative value is invalid.

Oh yeah whoops. I had it at that, but then changed it to  0 thinking I was 
going to need to pass in a -1 for submenu functionality, but we decided to drop 
that for now. I'll change it back.


- Kevin


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


On March 19, 2015, 4:59 p.m., Kevin Harwell wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://reviewboard.asterisk.org/r/4510/
 ---
 
 (Updated March 19, 2015, 4:59 p.m.)
 
 
 Review request for Asterisk Developers.
 
 
 Bugs: ASTERISK-24864
 https://issues.asterisk.org/jira/browse/ASTERISK-24864
 
 
 Repository: Asterisk
 
 
 Description
 ---
 
 This is the Asterisk 13 version of the following: 
 https://reviewboard.asterisk.org/r/4477/
 
 Attempting to execute DTMF in a confbridge while file playback (prompt, 
 announcement, etc) is occurring is not allowed. You have to wait until the 
 sound file has completed before entering DTMF. This patch fixes it so that 
 app_confbridge now monitors for dtmf key presses during file playback. If a 
 key is pressed playback stops and it executes the matched menu option. Unlike 
 the Asterisk 11 patch this version does not re-queue the dtmf frame, but 
 instead uses an already available function that monitors for dtmf presses 
 during playback.
 
 
 Diffs
 -
 
   branches/13/main/bridge_channel.c 433195 
   branches/13/include/asterisk/bridge_channel.h 433195 
   branches/13/apps/app_confbridge.c 433195 
 
 Diff: https://reviewboard.asterisk.org/r/4510/diff/
 
 
 Testing
 ---
 
 Manual testing done. Setup a basic conference bridge that allowed both 
 regular and admin users to enter. Ran through various menu options to make 
 sure the sound file playback would stop (no longer have to wait) and a new 
 option was executed when appropriate. Also ran the app_confbridge testsuite 
 tests to make sure they still passed.
 
 
 Thanks,
 
 Kevin Harwell
 


-- 
_
-- 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] 4510: app_confbridge (13): file playback blocks dtmf

[Kevin Harwell]

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

(Updated March 24, 2015, 3:30 p.m.)


Review request for Asterisk Developers.


Changes
---

Addressed review feedback.


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


Repository: Asterisk


Description
---

This is the Asterisk 13 version of the following: 
https://reviewboard.asterisk.org/r/4477/

Attempting to execute DTMF in a confbridge while file playback (prompt, 
announcement, etc) is occurring is not allowed. You have to wait until the 
sound file has completed before entering DTMF. This patch fixes it so that 
app_confbridge now monitors for dtmf key presses during file playback. If a key 
is pressed playback stops and it executes the matched menu option. Unlike the 
Asterisk 11 patch this version does not re-queue the dtmf frame, but instead 
uses an already available function that monitors for dtmf presses during 
playback.


Diffs (updated)
-

  branches/13/main/bridge_channel.c 433344 
  branches/13/include/asterisk/bridge_channel.h 433344 
  branches/13/apps/app_confbridge.c 433344 

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


Testing
---

Manual testing done. Setup a basic conference bridge that allowed both regular 
and admin users to enter. Ran through various menu options to make sure the 
sound file playback would stop (no longer have to wait) and a new option was 
executed when appropriate. Also ran the app_confbridge testsuite tests to make 
sure they still passed.


Thanks,

Kevin Harwell

-- 
_
-- 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] 4498: res_pjsip: Enable unload of all modules at shutdown

[Kevin Harwell]

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



/branches/13/res/res_pjsip_outbound_registration.c
https://reviewboard.asterisk.org/r/4498/#comment25410

I ran the res_pjsip_outbound_registration testsuite test locally and never 
received any fracks/crashes with this line added or removed.

I *think* removing the unref causes a leak. The pjsip code holds onto a 
reference of the client state. Each time pjsip_regc_send gets called the ref on 
the client_state is incremented. The timer_cb removes this ref.


While testing res_pjsip_outbound_registration I wanted to see if a frack would 
occur while unloading during registration attempts, but instead Asterisk 
crashed after unloading.  I believe this is due to the module unloading, yet 
pjsip is still attempting to register to a non existent remote server. After a 
timeout it then attempts to call back into the module, which has now been 
unloaded.

A similar thing occurred with res_pjsip_outbound_publish and some code was put 
into place that makes the module wait to fully unload until all registration 
attempts are complete. Something similar will need to be done here for outbound 
registrations.

That being said if you feel that fixing this is outside the scope of the 
changes found here then an issue can be made so it can be fixed at a later time.

- Kevin Harwell


On March 20, 2015, 11:17 p.m., Corey Farrell wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://reviewboard.asterisk.org/r/4498/
 ---
 
 (Updated March 20, 2015, 11:17 p.m.)
 
 
 Review request for Asterisk Developers.
 
 
 Bugs: ASTERISK-24731
 https://issues.asterisk.org/jira/browse/ASTERISK-24731
 
 
 Repository: Asterisk
 
 
 Description
 ---
 
 This patch allows all PJSIP modules to shutdown cleanly, once approved we'll 
 be able enable it in the Bamboo Reference Checks Job.
 
 * Move most of res_pjsip:module_unload to unload_pjsip to resolve crashes 
 caused by running PJSIP functions from non-PJSIP threads.
 * Remove call to pjsip_endpt_destroy(ast_pjsip_endpoint), it was causing 
 crashes in some cases.  In theory pj_shutdown() should take care of this for 
 us.
 * Mark res_pjsip_keepalive and res_pjsip_session as allowed to unload at 
 shutdown.
 * Resolve leaked config global in res_pjsip_notify.
 * Unregister pubsub pjsip service module.
 * Implement cleanup for res_pjsip_session.
 * Fix a pre-existing FRACK in res_pjsip_outbound_registration.
 
 More about res_pjsip_outbound_registration:
 tests/channels/pjsip/ami/show_registrations_outbound has an AO2 FRACK during 
 shutdown.  I get this error with or without my patch.  I've removed what I 
 believe is an extra unref, but this doesn't solve all the FRACK's.
 
 
 Diffs
 -
 
   /branches/13/res/res_pjsip_session.c 433244 
   /branches/13/res/res_pjsip_pubsub.c 433244 
   /branches/13/res/res_pjsip_outbound_registration.c 433244 
   /branches/13/res/res_pjsip_notify.c 433244 
   /branches/13/res/res_pjsip_keepalive.c 433244 
   /branches/13/res/res_pjsip.c 433244 
 
 Diff: https://reviewboard.asterisk.org/r/4498/diff/
 
 
 Testing
 ---
 
 All of tests/channels/pjsip.  Some tests still have reference leaks, but most 
 tests do not.
 
 Can someone retest tests/channels/pjsip/ami/show_registrations_outbound to 
 confirm that I haven't made it worse?  Seems to make no difference on my 
 system, but Bamboo doesn't seem to have a problem with this test.
 
 
 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