Re: [asterisk-dev] ARI events order

[Matthew Jordan]

On Wed, Sep 5, 2018 at 5:23 PM Seán C. McCord  wrote:

> As to the events should have a deterministic order or not, I cannot speak,
> but this is definitely normal behaviour.
>
>
> On Wed, Sep 5, 2018 at 12:22 PM Jean Aunis  wrote:
>
>> Hello,
>>
>> It looks like the ARI events ordering during channel destruction is not
>> deterministic. I noticed this for ChannelLeftBridge and ChannelDestroyed
>> events : given a channel is in a bridge and is hanged up, sometimes
>> ChannelLeftBridge is raised before ChannelDestroyed, sometimes it's the
>> contrary. Test conditions are exactly the same in both cases.
>>
>> Is this non-deterministic behaviour normal, or should it be considered as
>> a bug ?
>>
>> To my mind, ChannelDestroyed should always be the very last event raised
>> for a given channel. From a developper point of view, it would give a clear
>> indication that the resources associated to the channel can be freed.
>>
>> Regards
>>
> The events regarding a Channel entering and leaving a Bridge are
deterministic with respect to the Bridge's lifetime, but are not
deterministic with respect to the Channel's lifetime. While it's a bit
different, this is discussed somewhat on the AMI specification page:

https://wiki.asterisk.org/wiki/display/AST/AMI+v2+Specification#AMIv2Specification-Bridging

While AMI and ARI are two different APIs, both are built on top of a shared
internal abstraction layer inside Asterisk that determines that event
ordering. In the case of channels, channel event ordering is guaranteed
when those events are published to what is known as the 'channel' topic for
that channel. The act of entering / leaving a bridge is published to the
bridge's topic, which is technically independent of the channel's topic. As
such, the ordering of those events as they are presented to the AMI / ARI
topics is not guaranteed.

An example can be seen in publishing the bridge leave message:

void ast_bridge_publish_leave(struct ast_bridge *bridge, struct ast_channel
*chan)
{
struct stasis_message *msg;

if (ast_test_flag(>feature_flags, AST_BRIDGE_FLAG_INVISIBLE)) {
return;
}
msg = ast_bridge_blob_create(ast_channel_left_bridge_type(), bridge,
chan, NULL);
if (!msg) {
return;
}

/* state first, then leave blob (opposite of enter, preserves nesting
of events) */
bridge_publish_state_from_blob(bridge, stasis_message_data(msg));
stasis_publish(ast_bridge_topic(bridge), msg);
ao2_ref(msg, -1);
}

Note that we're publishing that message to the bridge topic -
ast_bridge_topic(bridge) - as opposed to the channel topic (which would be
ast_channel_topic(chan)). (To be pedantic, if you really wanted to preserve
event ordering for both the bridge and the channel's respective lifetimes,
you'd have to make a new aggregation topic for each channel / bridge and
publish their messages to those aggregation topics, but that's a lot of
overhead.)

You could argue that it *should* be ordered with respect to both the
channel and bridge's lifetime, but generally enforcing that ordering
imposes a penalty on the system, as it requires more synchronization. If
someone went down that path, it'd require some careful testing to ensure it
doesn't bog things down in some massive way.

-- 
Matthew Jordan
Digium, Inc. | CTO
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 --

Astricon is coming up October 9-11!  Signup is available at: 
https://www.asterisk.org/community/astricon-user-conference

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

Re: [asterisk-dev] Asterisk 14 doesn't cache media, really

[Matthew Jordan]

On Thu, Feb 22, 2018 at 12:06 PM, Joshua Colp <jc...@digium.com> wrote:

> On Wed, Feb 21, 2018, at 7:42 PM, Gaurav Khurana wrote:
> > Does anyone know about how caching of media actually happens in Asterisk
> > 14? What I observe is that in the case of a media uri being presented to
> > Asterisk to play to the caller, Asterisk fetches the media, stores it
> > in /tmp and plays it back. Now, when the same media uri is presented to
> > Asterisk again whether in the same Call (SIP session with a given
> > caller) or a new call, Asterisk makes a web request to fetch the media
> > file again and replaces the existing file under /tmp  with the new one.
> > This is kinda fine but what doesn't seem right is that when Media server
> > serving the media files is down, Asterisk fails to play it instead of
> > using the cached media file.
>
> I don't think that scenario was targeted for the support when it was
> written. It may have just been written to not download the file if it
> hasn't changed which would explain the behavior you are seeing. I think
> it'd be reasonable to add support for the scenario and shouldn't be too bad
> depending on the code.
>
>
Well sort of.

It caches it *if* the HTTP response from the upstream provider indicates
that it *can* be cached. That's a complex topic, but it boils down to a few
things:

- Does it have an ETag? If so, we store that in the metadata in the media
cache layer. If the ETag changes (which we check with a HEAD request), we
have to get a new version.
- Does it have a 'cache-control' header? If so, does it tell us to not
cache it? If so, we get a new version of the file each time.
- Is there an expiration time? (cache-control header value of max-age or
s-maxage, or an expires header value). If it expired, we get a new version
of the file.

So - you'll need to check the HTTP responses from your server to determine
why we would get a new version each time. Having an expiration value, no
ETag, or cache-control values that indicate that we shouldn't cache the
file would explain why we get it each time.


-- 
Matthew Jordan
Digium, Inc. | CTO
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

[Matthew Jordan]

On Wed, Nov 22, 2017 at 2:46 AM, Marin Odrljin <ma...@maxcom.hr> wrote:
>
> Yes, that’s the way my app works all the time, there is no any AOC event sent 
> to ARI. I was also expecting such events are sent to Stasis since I have 
> found in ‘stasis.conf’ possibility to decline them:
>
>
>
> ; decline=aoc_s_type
>
> ; decline=aoc_d_type
>
> ; decline=aoc_e_type
>
>
>
> Other configuration files where AOC is mentioned are:
>
> -  ‘manager.conf’ for AMI which probably works, but I didn’t try it 
> till now and would like to avoid it if possible
>
> -  ‘chan-dahdi.conf’ where I have enabled them
>
> -  ‘sip.conf’ for snom endpoints which I don’t need
>
>


Unfortunately, AOC events don't have a JSON representation and aren't
published to a Stasis topic that goes to ARI applications.

In aoc_publish_blob, you can see that we only publish the various AOC
events to the Manager topic (via ast_manager_get_topic):

msg = stasis_message_create(msg_type, aoc_event);
ao2_ref(aoc_event, -1);

stasis_publish(ast_manager_get_topic(), msg);

That pretty much limits AOC events to AMI today.

If you wanted this in ARI, you could pretty easily provide a patch to
do so. You'd need to:

* Change the topic that the messages are published to one that is
received by ARI. Assuming there is a channel involved, the easiest of
these is the channel topic. If there is no channel, you could publish
it to the generic 'all channels' topic. (Not all AOC events have a
channel, so you'd need to make sure it goes to some topic that makes
sense when that's the case.)

* Provide a JSON representation of the message. That means defining a
.to_json callback here which formats the message into JSON:

STASIS_MESSAGE_TYPE_DEFN(
aoc_s_type,
.to_ami = aoc_s_to_ami);

STASIS_MESSAGE_TYPE_DEFN(
aoc_d_type,
.to_ami = aoc_d_to_ami);

STASIS_MESSAGE_TYPE_DEFN(
aoc_e_type,
.to_ami = aoc_e_to_ami);

* Add the JSON representation of the message to the Swagger
specification (events.json) so that things get validated correctly.


For what it's worth, the data models wiki page shows the various
events that can be received:

https://wiki.asterisk.org/wiki/display/AST/Asterisk+13+REST+Data+Models

-- 
Matthew Jordan
Digium, Inc. | CTO
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] Line length restrictions in code changes

[Matthew Jordan]

Warning: bike shedding.

On several code reviews, comments have been left along with a -1 on
the review - indicating that it is not acceptable for merging - due to
line length restrictions. While this is technically correct per our
coding guidelines, it doesn't always result in the most readable code.

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
}

To be preferable to:

if (a_good_variable_name->another_good_name
&& do_something_to_it(a_good_variable_name->another_good_name)) {
// Do things
}

This is typically because the indentation of the second part of the
boolean test lines up with the code that is to be executed if both
conditions is true, which is more visually jarring than just reading
the first line.

I'll grant this is probably a personal preference, but we have
certainly opted for the former over the latter in many places in the
code.

While I know that we aren't all sitting around with dual screens, we
also aren't living in 1979 with dumb terminals. The line length
restriction of 90 columns seems reasonable until you end up with long
function names, which - since we live in a land of void * - is
generally something that we should encourage. I'd like to say that
some common sense about when to apply the line length rule and when
not to would "work for us", but that doesn't appear to be the case.

Questions than:
(1) Should there even be a line length rule?
(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)
(3) Should we simply advocate for readability, with examples of what
is readable and what is not?

Matt

-- 
Matthew Jordan
Digium, Inc. | CTO
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
Check us out at: http://digium.com & http://asterisk.org

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

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

Re: [asterisk-dev] Asterisk goes Spatial Conferencing: the STEAK project

[Matthew Jordan]

On Thu, Mar 2, 2017 at 3:46 AM, Dennis Guse
<dennis.g...@alumni.tu-berlin.de> wrote:
> Since all patches are now merged, this will be the last eMail from me on
> this thread.
> Here are just the steps to setup the binaural synthesis and the required
> stereo-capable OPUS module:
>
> ```
> git clone http://gerrit.asterisk.org/asterisk
> git clone  https://github.com/SteakConferencing/asterisk-opus
>
> cp asterisk-opus/codec/* asterisk/codec
>
> cd asterisk
>
> ./configure
>
> make menuconfig
> #Enable "Bridging modules"/binaural_rendering_in_bridge_softmix
> #Enable "Codec Translators"/codec_opus_open_source
> #Disable "Channel Drivers"/chan_sip - might avoid some issues if WebRTC is
> desired ;)
>
> make
> ```
>
> Tested with Asterisk (comit-id 00d1c7ddd28557aa845c3522956852a60310df96).
>
> Enjoy!
> ---
> Dennis Guse

Thank you Dennis for all your hard work on this feature!

Matt

-- 
Matthew Jordan
Digium, Inc. | CTO
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
Check us out at: http://digium.com & http://asterisk.org

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

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

Re: [asterisk-dev] asterisk-dev Digest, Vol 151, Issue 14

[Matthew Jordan]

On Wed, Feb 22, 2017 at 1:20 AM, Dương Nguyễn Văn <vanduong...@gmail.com> wrote:
>
> Re: Contents of asterisk-dev digest...
>

Thanks for pointing that individual out. They've been unsubscribed.

-- 
Matthew Jordan
Digium, Inc. | CTO
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] Subscription Persistence Issues

[Matthew Jordan]

On Tue, Feb 7, 2017 at 1:16 PM, George Joseph <gjos...@digium.com> wrote:

> Greetings All,
>
> I've been working on the (many) issues with recreating inbound
> subscriptions after an asterisk restart.  I have an approach that works but
> has a drawback:  We can recreate the subscription on startup from the data
> we persist and can even send a NOTIFY to each subscriber BUT with the
> current version of pjproject, we can't actually set the expiration timer.
> I have a pjproject patch ready that allows us to set tie timer but the
> drawback is that this approach will only work with bundled pjproject or a
> patched version of your own.
>
> There's an alternative though...   When asterisk restarts, instead of
> sending 'active' NOTIFYs to each subscriber, we could send
> 'terminate,probation' instead.  The RFCs say that a "client SHOULD retry at
> some later time".  While this approach will work with any version of
> pjproject there are issues here as well.  The first issue is the word
> 'SHOULD'.  There's no guarantee that the client will actually resubscribe.
> The second issue is the extra SUBSCRIBE/OK/NOTIFY/OK exchange between
> asterisk and the client at startup.  We can tell the client to retry not
> before a random interval similar to how we stagger sending OPTIONS messages
> at startup but it's still an extra 4 packets per subscription.
>
> Neither approach is harder or easier than the other to implement.  It's
> just a matter of backwards compatibility vs extra traffic and the 'SHOULD'
> uncertainty.
>
> Thoughts?
>
>
If you go with the first approach, do the changes to pjproject to fix the
expiration timer issues cause any API changes? Or is it merely fixing a bug
in pjproject?

-- 
Matthew Jordan
Digium, Inc. | CTO
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] Wish: adding intelligent codec negotiation to asterisk / pjsip

[Matthew Jordan]

On Mon, Jan 30, 2017 at 4:44 PM, George Joseph <gjos...@digium.com> wrote:

>
>
> On Mon, Jan 30, 2017 at 3:32 PM, Matthew Jordan <mjor...@digium.com>
> wrote:
>
>>
>>
>> On Mon, Jan 30, 2017 at 3:22 PM, Matt Fredrickson <cres...@digium.com>
>> wrote:
>>
>>> Hey Michael,
>>>
>>> First off, thanks for taking the time to express some of your thoughts
>>> and concerns to the asterisk-dev list.  I'll keep my reply to your
>>> email inline below.
>>>
>>> On Mon, Jan 30, 2017 at 4:13 AM, Michael Maier <m1278...@allmail.net>
>>> wrote:
>>> > Dear developers,
>>> >
>>> > I've been redirected to this mailing list by Joshua Colp during fixing
>>> a
>>> > one way audio bug[1] to discuss another solution as provided in the
>>> fix.
>>> >
>>> > Background:
>>> > - A lot of people complain about bad VoIP call quality compared to the
>>> > old POTS / ISDN devices. What do they mean from a technical point of
>>> > view: High latencies (resulting in echo), digital sound because of
>>> "bad"
>>> > codecs, general quality loss during transcoding and many other reasons
>>> more.
>>> > - In Europe, HD audio is being adopted slowly. This means, more and
>>> more
>>> > UAs can natively handle HD codecs like g722. But they must be downward
>>> > compatible at the same time for older UAs, which just speak alaw (like
>>> > the old POTS devices e.g. or UAs which are not yet HD capable).
>>> > Therefore, they advertise at least two codecs: g722 and alaw (mostly
>>> > plus some more like ulaw or some other codecs).
>>>
>>> So there are multiple reasons why you could be seeing reportedly bad
>>> call quality that come to my mind:
>>>
>>> 1. Transcoding - changes the audio, but typically doesn't make things
>>> sound *too* bad.  Obviously it is codec dependent as to how bad it
>>> sounds afterwards, but most modern codecs aren't terrible for speech
>>> replication and encoding.  Usually this is not where call quality
>>> problems are noticed.
>>>
>>> 2. Packet loss and jitter related problems.  In an ISDN network, there
>>> is a guaranteed real time audio channel for transporting media.  As
>>> long as the data pumps on the transmit and receive side are working
>>> properly, you should hear almost no audio quality issues.  VoIP tries
>>> to transport real time audio over a non-guaranteed transport channel.
>>> This sometimes causes bad audio quality issues due to packet loss,
>>> packet reordering, or extreme packet delays.  Enabling Asterisk's
>>> jitter buffers typically improves many problems that arise due to
>>> this.  They are typically *not* enabled by default and so must be
>>> explicitly enabled.
>>>
>>> I'm hoping you already have dived into your problem to look at both
>>> the above elements, and have confirmed that you are not dealing with
>>> the second problem instead of voice mutation due to the first problem.
>>> Usually you can track the second problem by doing packet captures of
>>> the voice conversations in question as well as look at RTCP
>>> statistics.
>>>
>>> > What does this mean to Asterisk?
>>> > My conviction is, that Asterisk shouldn't make things even worse when
>>> > handling calls / codecs by forcing unnecessary transcoding, which
>>> > unnecessarily harms call quality. Next point of unnecessary
>>> transcoding:
>>> > it unnecessarily steals system resources from the machine asterisk is
>>> > running on.
>>> > Asterisk should harm each call it handles and the underlying machine as
>>> > little as possible.
>>> >
>>> > Therefore I would like to see a (switchable) feature, that asterisk /
>>> > pjsip always tries to primarily advertise codecs, which are supported
>>> by
>>> > both UAs and remove those codecs, which are not supported by one of the
>>> > UAs. This prevents unnecessary transcoding.
>>>
>>> This actually would be a really neat thing for Asterisk to be able to
>>> do.  Last time I looked at it, there are quite a few challenges in
>>> making it happen.  Asterisk is designed to be a back to back user
>>> agent, and it inherently is designed to terminate media and codecs
>>> individually with each leg in question, but not necessarily toget

Re: [asterisk-dev] Wish: adding intelligent codec negotiation to asterisk / pjsip

[Matthew Jordan]

times.

The last time I gave that a shot I more or less had it working, and then
broke myself (and my patch) on the rocks of Local channels. Trying to get
Local channel chains to respect the codecs down a chain (generally 3+ is
enough to trip errors) is a non-trivial operation. When setting up the call
you more or less can control the situation - the codec preferences are
passed down the chain via ast_request. However, when things are coming back
in the other direction, you don't have an easy reference to the channel
that created you. It can involve reaching across bridges and local channel
bridges, which is dangerous. Both are prone to error and deadlocks. Holding
a reference to your creator isn't safe, as the creator can be masqueraded
away (in really weird situations). The other option is to pass the
information down in a frame, but now you can't guarantee much, as that's an
asynchronous operation.

In transcoding situations, you also have to pick where in that chain you
choose to do transcoding - which is not always easy to figure out.

Things get challenging as well when you have a multi-party bridge involved
at all - either when a dialed party has to be placed into a multi-party
bridge or when you have a chain of Local channels dialing someone and the
far end of the Local channel chain is already in a multi-party bridge.

Generally, this is an architectural limitation of Asterisk that - while not
impossible to craft a solution for - is far harder than it may seem when
you're only thinking of two-party calling with non-Local channels.

-- 
Matthew Jordan
Digium, Inc. | CTO
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] Subscription behavior when an incoming registration goes away?

[Matthew Jordan]

On Thu, Dec 22, 2016 at 9:32 AM, George Joseph <gjos...@digium.com> wrote:

> When an incoming registration goes away, either because it expires or it
> was explicitly expired, what should we do with subscriptions the contact
> may have?  Right now we do nothing which means that activity for those
> subscriptions will trigger NOTIFYs which will time out and retry until
> timer_b expires.  Only then will they be deleted.
>
> Should we:
>
>- Leave the behavior as is?
>- Automatically remove the subscriptions for a contact that has been
>deleted?
>- Create a global option to control auto deletion?
>- Create an aor option to control auto deletion?
>
> Opinions?
>
>
If an AoR only has dynamic contacts, and those dynamic contacts are no
longer valid (or the AoR no longer has any contacts), then at the very
least I would think we wouldn't want to send the NOTIFY requests until the
AoR has valid contacts. There's certainly no reason to use memory/CPU
cycles on something that will never succeed.

You may or may not want to actually remove the underlying subscription. I
could see a scenario in which a phone's REGISTER request goes "missing",
and so the registration drops - maybe for just a short period of time. When
the new REGISTER request does succeed, the phone may or may not send a new
SUBSCRIBE request (which may have a very different timer). If we
auto-deleted the underlying subscription, we could have a situation where
the phone is re-registered but no longer receives state updates.

I'll grant the above scenario is pretty unlikely, but it is plausible.

Matt

-- 
Matthew Jordan
Digium, Inc. | CTO
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 missed calls per agent - caller hangup before timeout

[Matthew Jordan]

On Thu, Dec 15, 2016 at 10:17 AM, marek cervenka <cerva...@gmail.com> wrote:

> i think i foud possible solution. can you confirm if i'm on correct path?
>
> sql data looks
>
> +-++-+--
> -+---+-+---+---+---+---+---+
> | id  | time   | callid  | queuename | agent |
> event   | data1 | data2 | data3 | data4 | data5 |
> | 165913 | 2016-12-14 11:01:20.965839 | 1481709660.56899  | queue1 |
> NONE  | ABANDON | 1 | 1 | 9 |   |   |
>
> data3 contains ringtime but agent is filled as "NONE"
>
>
> in app_queue there are 2 places which fills ABANDON
>
>
> function queue_exec
>
> stop:
> if (res) {
> if (res < 0) {
> if (!qe.handled) {
> record_abandoned();
> *ast_queue_log(args.queuename, ast_channel_uniqueid(chan),
> "NONE", "ABANDON",   "%d|%d|%ld", qe.pos, qe.opos,  (long) (time(NULL) -
> qe.start));*
> res = -1;
> } else if (qcontinue) {
> reason = QUEUE_CONTINUE;
> res = 0;
> }
> } else if (qe.valid_digits) {
> ast_queue_log(args.queuename, ast_channel_uniqueid(chan),
> "NONE", "EXITWITHKEY",
> "%s|%d|%d|%ld", qe.digits, qe.pos, qe.opos, (long)
> (time(NULL) - qe.start));
> }
>
>
> BUT
>
> in try_calling function
>
> there is member filled
>
> } else if (ast_check_hangup(qe->chan)) {
> /* Caller must have hung up just before being connected */
> ast_log(LOG_NOTICE, "Caller was about to talk to agent on
> %s but the caller hungup.\n", ast_channel_name(peer));
> *ast_queue_log(queuename, ast_channel_uniqueid(qe->chan),
> member->membername, "ABANDON", "%d|%d|%ld", qe->pos, qe->opos, (long)
> (time(NULL) - qe->start));*
> record_abandoned(qe);
> ast_channel_publish_dial(qe->chan, peer,
> member->interface, ast_hangup_cause_to_dial_status(ast_channel_
> hangupcause(peer)));
> ast_autoservice_chan_hangup_peer(qe->chan, peer);
> ao2_ref(member, -1);
> return -1;
> }
>
>
> why isnt used the try_calling to fill ABANDON?
>
> is it safe fill member (if exist) in queue_exec?
>
>
These two locations are fulfilling two different purposes.

The first, in queue_exec, handles the case where the caller abandons the
queue prior to any queue member being selected. The second, as the comment
suggests, handles the case where the caller abandons the queue after the
queue member has been selected but before the two parties have been
connected.

As such, no, you cannot get a queue member name in queue_exec, as there is
no queue member that has been chosen.





>
>  Přeposlaná zpráva 
> Předmět: app_queue missed calls per agent - caller hangup before timeout
> Datum: Wed, 14 Dec 2016 14:26:21 +0100
> Od: marek cervenka <cerva...@gmail.com> <cerva...@gmail.com>
> Komu: Asterisk Users Mailing List - Non-Commercial Discussion
> <asterisk-us...@lists.digium.com> <asterisk-us...@lists.digium.com>
>
>
> hi,
>
> i'm trying get report about missed calls per agent. i'm using queue_log
> and RINGNOANSWER event
> but i found problem described here
>
> ---https://www.thirdlane.com/forum/queue-log-problem
>
> RINGNOANSWER only happens if the call TIMES OUT ringing the agent and it
> returns to the queue. If your agent has a 30 second timeout and the
> caller ABANDONS the call in 5 seconds it will log an ABANDON not a
> RINGNOANSWER.
>
> This is the only time ast_queue_log is executed with RINGNOANSWER. The
> subsequent code of this function goes on to autopause the agent/member
> if autopause is enabled. Not something that happens when callers hang up
> when ringing the agents.
>
> /*! \brief RNA == Ring No Answer. Common code that is executed when we
> try a queue member and they don't answer. */
> static void rna(int rnatime, struct queue_ent *qe, char *interface, char
> *membername)
> {
> if (option_verbose > 2)
> ast_verbose( VERBOSE_PREFIX_3 "Nobody picked up in %d ms\n", rnatime);
> ast_queue_log(qe->parent->name, qe->chan->uniqueid, membername,
> "RINGNOANSWER", "%d", rnatime);
> ---
>
>
> any tips howto detect missed calls where caller hangup before timeout?
> tnx
> Marek
>
>
> --
> _
> -- Ban

Re: [asterisk-dev] Possible change to the AMI PJSIPShowRegistrationsInbound command

[Matthew Jordan]

On Tue, Dec 6, 2016 at 4:27 PM, Matt Fredrickson <cres...@digium.com> wrote:

> On Tue, Dec 6, 2016 at 12:30 PM, Joshua Colp <jc...@digium.com> wrote:
> > On Tue, Dec 6, 2016, at 10:43 AM, George Joseph wrote:
> >> We just discovered that the PJSIPShowRegistrationsInbound command really
> >> only dumps all aors regardless of whether there's an inbound
> registration
> >> associated with it or not.  Fixing this would mean a change to what this
> >> command returns so I'm trying to get some feedback.  There are 2
> solution
> >> alternatives...
> >>
> >> 1.  We could replace the current InboundRegistrationDetail event (which
> >> isn't even registered) with a ContactStatusDetail event.  Obviously this
> >> is
> >> a change for anyone who uses this command.
> >>
> >> 2.  We could send a ContactStatusDetail event along with the existing
> >> InboundRegistrationDetail event.  This would double the number of events
> >> sent and therefore increase the total data sent.
> >>
> >> Honestly I'm not sure how this command was ever useful to anybody so I'm
> >> leaning towards option 1 but we need feedback.
> >>
> >> This would be a change to 13, 14 and master.
> >
> > Since it was not really useful I'm okay with 1.
>
> Just as something to consider:
>
> If we make breaking changes to AMI, this would require a major number
> version bump, right?
>
>
Yes, it would.

-- 
Matthew Jordan
Digium, Inc. | CTO
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] ast_sip_session

[Matthew Jordan]

On Tue, Nov 15, 2016 at 6:17 AM, Joshua Colp <jc...@digium.com> wrote:

> On Mon, Nov 14, 2016, at 03:46 AM, Kelvin Chua wrote:
> > playing around chan_pjsip/res_pjsip
> >
> > i have some data i want to pass from upstream to downstream on reponse
> > for
> > example, P-Associated-URI
> >
> > i figured that datastore on ast_sip_session only handles either the
> > upstream channel or the downstream channel. I can already parse the
> > header
> > on upstream but stuck on how to write
> > this to the reply downstream. any pointers?
>
> There is no generic mechanism for doing this currently: specifically
> passing data back on a response or answer. The closest thing would be to
> add a new frame type (frame.h) to Asterisk, put data on it (in an
> ast_frame), propagate it through, and have it read/handled on the other
> side. If you end up with specific questions you can respond back with
> them, but you are sort of venturing into uncharted territory unless
> someone else has an idea on how to better do it.
>
>
I'd throw out there as well that this _may_ not be worth doing,
particularly automatically. As a B2BUA, you're always going to be fighting
against Asterisk's model of channels and bridges if you want to
automatically propagate information from an inbound channel to an outbound
channel.

Things you have to think through:
(1) What happens when there are Local channels?
(2) What happens if there are multiple outbound channels (parallel dial)?
(3) What happens if I'm in a bridge with multiple channels (conference)?
(4) If the information can be provided in a re-INVITE, what occurs if I
pass this information along before or after an answer?

One of the safer ways of handling the notion of passing things from an
inbound to an outbound channel is to have the dialplan do it. You can use
functions like PJSIP_HEADER to read values off of an inbound channel, store
them in a channel variable with inheritance, then use a pre-dial handler
with PJSIP_HEADER (or CHANNEL, etc.) to modify the outbound channel(s)
prior to dialing. Doing that gives you more control over exactly _when_ you
pass information along, and helps you avoid the many, many edge cases that
can occur.

-- 
Matthew Jordan
Digium, Inc. | CTO
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] group video calling

[Matthew Jordan]

On Mon, Nov 14, 2016 at 4:56 AM, ZAIN AFTAB <zain...@hotmail.com> wrote:

> Hi All,
>
>   I have posted this question in the asterisk forum, and they
> asked me to contact the asterisk-development forum.
>
>
> I want to call ring group where 2 monitors will ring simultaneously, and I
> want pre video feature for it( that is video before answering the call). I
> am surprised that it works when I dial one SIP video monitor ( I get the
> video before answering the call), but when I dial the ring group (with two
> sip extensions), I dont get the video before answering the call. I only get
> video once the call is answered.
>
>
> 3CX supports this feature by default, we dont need to configure anything,
> I believe there must be some options for asterisk as well.
>
> I need this feature for my video door entry system, it is a big project,
> and I want to solve it for my customers
> Is there anyone who has worked on this kind of project before ? Any help
> would be much appreciated
>
> thanks in advance
>

Asterisk does not mix media during an early bridge situation, regardless of
the media type. In a situation where a parallel dial is occurring, Asterisk
will simply pick a winner and forward the media on to the caller.

Assuming Asterisk was modified to mix early media, Asterisk would still not
forward two or more video streams. Asterisk does not mix or transcode
video, nor does it support forwarding multiple video sources in a single
stream (in a selective forwarding unit fashion).

Changing the behavior of the previous two points would require relatively
large and substantial changes in Asterisk.

I would expect Asterisk to forward a single video stream in an early
bridge; if that's not happening, I would suspect that's something that
could be fixed relatively easily in app_dial.

-- 
Matthew Jordan
Digium, Inc. | CTO
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] Proposed Working Group Guidelines

[Matthew Jordan]

On Mon, Nov 7, 2016 at 5:00 AM, Dan Jenkins <dan.jenkin...@gmail.com> wrote:

>
> On Fri, Nov 4, 2016 at 2:07 PM, Matt Fredrickson <cres...@digium.com>
> wrote:
>
>> Hey All,
>>
>> I've been thinking a lot about how working groups might work within
>> the context of the Asterisk project.  Here are a few guidelines that I
>> have come up with governing working groups.  Some of these guidelines
>> come from the Node project, as they have a lot of pre-existing
>> material on doing this.  I deliberately avoided comprehensively
>> importing their structure and guidelines, but pulled from some of
>> their more essential core principles.
>>
>> 1. There is no explicit or implicit commitment that a working group’s
>> output will actually be turned into code/patches by Digium or anybody
>> else outside of the working group.
>>
>> 2. Some working group topics might include: documentation, feature
>> request list, benchmarking, debug-ability, bug tracker triaging and
>> replication, migration efforts from SIP to PJSIP (and more?)
>>
>> 3. They need somewhere to “work” - so a section of the asterisk.org
>> wiki and probably a mailing list.  This can be a work item for me to
>> get taken care of.
>>
>> 4. Need a regular (weekly?) meeting time and “place” (an Asterisk
>> conference call, IRC, a google hangout, etc).
>>
>> 5. Need a charter of some sort - a charter would be a clearly defined
>> mission statement determining the subject matter of the group’s
>> efforts.
>>
>> 6. Need at least three initial members (pulled from node.js guidelines)
>>
>> 7. Need to follow a consensus seeking process for any decisions
>> (https://en.wikipedia.org/wiki/Consensus-seeking_decision-making)
>>
>> 8. Membership cannot be changed (added or removed) without unanimous
>> consensus of the members of the group (pulled from node.js guidelines)
>>
>> 9. In order to create one, talk to me and I can see about getting
>> infrastructure (mailing list, wiki, git access) setup.
>>
>> Let me know if you have any thoughts, questions, or qualms with the
>> above guidelines.  I'll wiki-fy the results of any discussion here.
>>
>> --
>> Matthew Fredrickson
>> Digium, Inc. | Engineering Manager
>> 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
>>
>> --
>> _
>> -- 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
>
>
>
> Hi Matt,
>
> Firstly, thanks for compiling all of this.
>
> Some comments around having the discussions etc.
>
> Please, no more mailing lists. Please? I'd rather not use the wiki for
> working groups - the wiki doesn't encourage conversation; instead its a
> place to go to document something and maybe write some comments on it - its
> really not the best place to have a conversation - I guess this is where
> the mailing lists come in but I'd love to get away from mailing lists - we
> have discourse now for example which is a MUCH better environment to have
> these conversations. I'd personally like to just replicate the node.js
> environment on github, with github issues and labels etc but its been made
> clear that isn't really an option unfortunately.
>
> There was talk of needing at least one core contributor (doesn't need to
> be a digium employee in my mind) to be one of the 3 initial members - is
> this still true?
>
>
I mentioned that I thought it would be a good idea to have an Asterisk
Developer involved in any working group, simply as they can help to
validate the feasibility of an idea. Whether or not that should be a
requirement is up for debate.

-- 
Matthew Jordan
Digium, Inc. | CTO
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] Remote media playback mea culpa

[Matthew Jordan]

Hey all -

At AstriDevCon this year, I noted that while we implemented remote media
playback in Asterisk 14 [1], it didn't yet work with ARI. I was looking at
finishing off this feature for a slightly later release of Asterisk 14, but
as I was playing around with it, I realized that it actually *does* work,
although the way in which you invoke the remote playback is admittedly a
little funky.

When posting a /play operation on a bridge or channel resource, providing
an HTTP or HTTPS URI to a media identifier of type 'sound:' will cause the
Asterisk core to go ahead and pull the media from the provided HTTP/HTTPS
URI. That is, something like this will work:

POST /channels/my_unique_id/play?media=sound:
http://remote_ip_address/foo.wav

(Note that you'd obviously want to URL encode the URI of the media to be
retrieved)

This works as well, of course, with JSON bodies POSTed.

I've updated the feature description accordingly [2].

Note that I do think Ben Langfeld's comments about supporting text/uri-list
is reasonable, and would be useful in the long run. In the short term, at
least, this feature does work from ARI.

Matt

[1] https://wiki.asterisk.org/wiki/display/AST/Asterisk+14+Documentation
[2]
https://wiki.asterisk.org/wiki/display/AST/Asterisk+14+Project+-+URI+Media+Playback

-- 
Matthew Jordan
Digium, Inc. | CTO
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

[Matthew Jordan]

On Tue, Oct 18, 2016 at 4:02 PM, Joshua Colp <jc...@digium.com> wrote:
> Matthew Jordan wrote:
>
> 
>
>
>> There are a few wrinkles with emitting channel variables with
>> arbitrary events (of which StasisEnd would qualify).
>>
>> When an event is emitted out of the APIs, it's typically being done so
>> as a result of a message having been published on the Stasis message
>> bus. The messages on the bus don't contain a reference to a channel,
>> but rather a snapshot of the channel. Those snapshots, by default,
>> don't contain any channel variables, primarily for performance
>> reasons. Additionally, since dialplan functions can be freely
>> interchanged with channel variables, it's impossible (or very costly)
>> to evaluate dialplan function expressions on each snapshot creation.
>>
>> Unfortunately, you really do need to rely on the messages coming
>> across the bus. By the time code is processing the sending of a
>> StasisEnd event, the ast_channel itself may already be gone. As such,
>> the variables have to be stored on the snapshot in some fashion.
>>
>> AMI accomplished this by creating a core concept known as 'manager
>> variables'. These are set directly on the ast_channel structure, and -
>> when a snapshot is created - are evaluated and copied onto the
>> snapshot. Again, this is a rather costly operation, but it does limit
>> the impact of including variables on messages, as you have to
>> explicitly tell Asterisk which state you want transmitted along with
>> the channel.
>>
>> If we wanted a similar concept in ARI, the manager variables could be
>> reused. I would note that you absolutely will take a performance hit
>> when using them - building and conveying that much state in every
>> event is not cheap. Because StasisEnd is rather 'special' - often the
>> channel core isn't aware of it - I'm not sure how you would convey
>> variables only on that event and not on all the rest.
>
>
> The actual raising of StasisEnd is explicitly done inside of Stasis and
> lives there. When raised the channel is there and valid. It currently uses a
> channel blob as the payload but this could be changed to something else that
> would allow channel variables (only channel variables explicitly set on the
> channel) to also be added. This would scope the channel variables addition
> to only StasisEnd. Now... if we wanted channel variables on every message...
> then yeah, it would be difficult.
>

Two thoughts:
(1) I wonder if anyone needs the state conveyed on events other than
StasisEnd? If Asterisk is maintaining all of your state for you, and
you need to know some part of the state in your external application,
how do you ask for it?

(2) Even if we emit variable state on StasisEnd, how would we know
which state to emit? Would we want to require users to provide it up
front in ari.conf, or through some more dynamic mechanism?

-- 
Matthew Jordan
Digium, Inc. | CTO
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

[Matthew Jordan]

On Tue, Oct 18, 2016 at 9:26 AM, Joshua Colp <jc...@digium.com> wrote:
> Matt Fredrickson wrote:
>
> 
>
>>
>> First off, sorry about the delayed response.  Your proposal sounds
>> reasonable to me - that is to say, I can't see anything wrong with
>> adding that behavior.  Perhaps making channel variable dumping on
>> StasisEnd optional instead of mandatory would be better, but other
>> than that everything seems sane.  Maybe Josh or Mark might want to
>> weigh in on it.
>
>
> I don't think that channel variables are substantial enough in the case
> where this isn't being used to really need to adding a knob to turn it
> on/off. That's just me, though.
>

There are a few wrinkles with emitting channel variables with
arbitrary events (of which StasisEnd would qualify).

When an event is emitted out of the APIs, it's typically being done so
as a result of a message having been published on the Stasis message
bus. The messages on the bus don't contain a reference to a channel,
but rather a snapshot of the channel. Those snapshots, by default,
don't contain any channel variables, primarily for performance
reasons. Additionally, since dialplan functions can be freely
interchanged with channel variables, it's impossible (or very costly)
to evaluate dialplan function expressions on each snapshot creation.

Unfortunately, you really do need to rely on the messages coming
across the bus. By the time code is processing the sending of a
StasisEnd event, the ast_channel itself may already be gone. As such,
the variables have to be stored on the snapshot in some fashion.

AMI accomplished this by creating a core concept known as 'manager
variables'. These are set directly on the ast_channel structure, and -
when a snapshot is created - are evaluated and copied onto the
snapshot. Again, this is a rather costly operation, but it does limit
the impact of including variables on messages, as you have to
explicitly tell Asterisk which state you want transmitted along with
the channel.

If we wanted a similar concept in ARI, the manager variables could be
reused. I would note that you absolutely will take a performance hit
when using them - building and conveying that much state in every
event is not cheap. Because StasisEnd is rather 'special' - often the
channel core isn't aware of it - I'm not sure how you would convey
variables only on that event and not on all the rest.

-- 
Matthew Jordan
Digium, Inc. | CTO
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] Retransmission timeout reached on transmission

[Matthew Jordan]

On Fri, Oct 14, 2016 at 12:11 AM, Prakash Agrawal
<prakash.wr...@gmail.com> wrote:
> Hi,
>
> I am not able to make a call from OriginateAction using Asterisk AMI for
> first time.
>
> I am trying to call usiing Zoiper, AMI and Asterisk.I am using
> OriginateAction of AMI to call.
> I make a  first call from Zoiper(Softphone) and disconnect the call. Then i
> call using OriginateAction and the call is connecting.
> But when I leave my system idle for sometime and again try to connect using
> OriginateAction it is throwing the error.
>
> chan_sip.c:4059 retrans_pkt: Retransmission timeout reached on transmission
> 0d8153c274a41616484168e3180f9fbf@192.168.230.128:5060 for seqno 102
> (Critical Request) -- See
> https://wiki.asterisk.org/wiki/display/AST/SIP+Retransmissions
> Packet timed out after 32000ms with no response
>

The asterisk-dev list is used for discussion regarding the development
of Asterisk, not for assistance in its usage.

Please ask your question on the asterisk-users mailing list [1] or on
the community forums [2].

[1] http://lists.digium.com/mailman/listinfo/asterisk-users
[2] https://community.asterisk.org/

-- 
Matthew Jordan
Digium, Inc. | CTO
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] Viva Chan_Sip, may it rest in peace

[Matthew Jordan]

 Currently, Asterisk is running dual sip stacks. The argument is that to
>> deprecate PJSIP there must be broader adoption. There is currently nothing
>> motivating adoption but much slowing it.
>>
>> What are some of the hurdles to adoption?
>> 1. Apathy.  If it ain't broke don't fix it. Many would argue chan_sip is
>> broke but it is the "devil you know". A decade of documentation and a broad
>> user base allows people to be pretty forgiving of flaws. Almost any issue
>> has some sort of work around or generally accepted idea of I guess we can
>> live with it.
>>
>> 2. One Ring to rule them all!!  PJSIP requires up to 6 sections of
>> configuration. Once you dig in, this method makes sense. But at a glance,
>> you have just multiplied the workload to  6 times that of chan_sip's single
>> blob config. Though it is not really 600% more effort it may be enough to
>> scare some away
>>
>> 3. Mo Adoption, Mo problems!
>> The only way to clean up all the edge cases and weird bugs is to hit them
>> in the first place.  Dogfooding only gets you so far.  You can make anything
>> working clean in a single environment and single use case. But what happens
>> when people start flinging wrenches. Things break. 100 wrenches may break 10
>> things. 1000 wrenches may break 100 things.  In the ladder case, you have
>> 100 people saying pjsip sucks, and pjsip is crap. As with all things the 900
>> assume all is good and move on with their lives telling no one of their
>> glory. So you have 10% of the voices running unopposed. You fix the 100
>> issues and that is great but those 100 people have gone back to the comfort
>> of chan_sip and are stuck at point 1.
>>
>> Escaping the cycle.
>>
>> So how do we dredge through this mess and get high adoption?
>>
>> You have to make #1 not an option.  This means potentially breaking the
>> universe. This is why I think there is a tendency to be gunshy. No one wants
>> to be the guy who broke the universe.  But breaking the universe gets us to
>> #3 without falling back into #1.   Once The universe breaks and we are in #3
>> many of the edges will be found and fixed. Suddenly PJSIP becomes usable in
>> most, if not all situations. The issues in #2 will automatically resolve as
>> there is more information and it becomes the "accepted way" of doing things.
>> The old dogs will have to refactor how they do configuration but I am
>> confident once they do a few they will figure out the bark is bigger than
>> the bite.
>>
>> tl;dr to get adoption you have to force it.  There will be blood, but
>> nothing that can't be cleaned up with a little bleach and some elbow grease
>>
>> --
>> James
>>
>> --
>> _
>> -- 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



-- 
Matthew Jordan
Digium, Inc. | CTO
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] Working Groups

[Matthew Jordan]

 to say that I think the output of working groups
would be ignored - far from it, as I think everyone would benefit from
this process - but the more ambitious the recommendation, the more
difficult it is to build consensus and resources to accomplish the
goal. Having expectations be set would be good to avoid
disappointment.

Matt

-- 
Matthew Jordan
Digium, Inc. | CTO
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
Check us out at: http://digium.com & http://asterisk.org

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

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

Re: [asterisk-dev] [asterisk-commits] format ogg opus: New format (asterisk[master])

[Matthew Jordan]

On Tue, Oct 4, 2016 at 4:41 PM, ApexVitality
<aljeandrorodri...@gmail.com> wrote:
> unsubscribe me from this list or any other list pls
>

Instructions are at the bottom of every e-mail:

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


-- 
Matthew Jordan
Digium, Inc. | CTO
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] BRIDGEPEER on multi-party conferences: Thoughts?

[Matthew Jordan]

On Wed, Aug 10, 2016 at 10:42 AM, Richard Mudgett <rmudg...@digium.com> wrote:
>
>
> On Tue, Aug 9, 2016 at 6:01 PM, Mark Michelson <mmichel...@digium.com>
> wrote:
>>
>> Hi folks,
>>
>> I've been looking into a Digium customer issue where ConfBridge audio has
>> been dropping out. The main issue there had to do with DNS, and there is
>> currently a review [1] up to fix that.
>>
>> A secondary issue, though, is that there would be brief audio cutouts when
>> participants joined and left the conference. Looking into it, I believe the
>> problem is that when a participant enters or leaves the bridge, the
>> BRIDGEPEER channel variable is updated for every remaining participant in
>> the bridge. The basic algorithm is like this:
>>
>> * Lock the bridge
>> * Iterate through the channels in the bridge (a maximum of 11 of them)
>> * Lock the channel
>> * Append the channel to an array of channel names
>> * Unlock the channel
>> * Iterate through the channels in the bridge again (no upper limit this
>> time)
>> * Lock the channel
>> * Set the BRIDGEPEER channel variable using the names in the generated
>> array from before (comma-separated)
>> * Unlock the channel
>> * Unlock the bridge
>>
>> In addition, this same process occurs every time an announcement is played
>> into a bridge, such as join/leave beeps. Playing an announcement involves
>> pushing an announcer channel into the bridge and then removing the announcer
>> channel when the playback completes.
>>
>> My question to the list is this: do you find value in having the
>> participants in a multi-party bridge packaged into the BRIDGEPEER channel
>> variable? I know that for two-party bridges, there are probably lots of
>> scripts and dialplans out there that rely on that variable to be set; my
>> question specifically is for bridges with more than two parties.
>>
>> My thoughts on the matter are that since bridges are query-able now
>> directly, getting the list of participants from the bridge makes more sense
>> than trying to get the participants based on a single channel in that
>> bridge. In addition, the code places a hard limit on the number of channel
>> names it will actually put in the BRIDGEPEER variable. The code currently
>> has a #define that makes it so that only the first 11 channels in the bridge
>> will have their names in BRIDGEPEER. Because of the hard-coded maximum, if
>> you have more than 11 channels in the bridge, you can't get the full list of
>> participants using BRIDGEPEER.
>
>
> Relying on BRIDGEPEER for only two party bridges will break down when you
> consider that
> ad-hock multi-party bridges are now allowed.  A bridge may start out being
> two party but wind up
> with multiple participants due to the DTMF transfer feature allowing ad-hock
> multi-party bridges.
>
> The upper limit of 11 is bowing to reality that BRIDGEPEER is not a good way
> to get participants
> for larger multi-party bridges.
>

I know ad-hoc multi-party bridges are why we ended up going with the
approach that we did. I think the issue that Mark outlines, however,
shows that the implications of the approach in large multi-party
bridges - ad-hoc or otherwise - becomes prohibitive.

Corey's suggestion of having the same behavior, but only calculating
it when someone asks for BRIDGEPEER - seems like a reasonable middle
ground. The downside is just that there won't be any events fed to
people, which means people who have built systems looking for those
events are going to be broken.

I suppose we could do the 'unfortunate' thing of having an
asterisk.conf (or some other relatively low level configuration file)
that sets whether or not BRIDGEPEER is evaluated on the fly or all the
time in 13/14, and in master, simply change it to a request-only
variant.

-- 
Matthew Jordan
Digium, Inc. | CTO
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] BRIDGEPEER on multi-party conferences: Thoughts?

[Matthew Jordan]

On Wed, Aug 10, 2016 at 10:11 AM, Corey Farrell <g...@cfware.com> wrote:
> It might be a problem if BRIDGEPEER is being compared to an empty string to
> see if a channel is alone.
>
> What if you made BRIDGEPEER into a built-in channel variable (like
> ${EPOCH}).  This would mean that you wouldn't be setting any channels, you'd
> only do a lookup when requested.  One side-effect is that VarSet events
> would never be produced for this variable, not sure how much this would
> matter given better events to monitor ConfBridge joins/parts?
>

I think fixing this is going to be a breaking change no matter what we
do. Having a 'pull' mechanism that still results in the same output is
nice, in that if someone *were* relying on getting some form of list
of the participants, they can still do so.

I will say that removing the VarSet for BRIDGEPEER would break a fair
number of testsuite tests, although that shouldn't be a reason not to
do the change. It is evidence, however, that we ourselves relied on
the setting of BRIDGEPEER to get an indication of who the channel was
in a bridge with.

-- 
Matthew Jordan
Digium, Inc. | CTO
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
Check us out at: http://digium.com & http://asterisk.org

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

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

Re: [asterisk-dev] Asterisk goes Spatial Conferencing: the STEAK project

[Matthew Jordan]

Hi Dennis:

Apologies for not responding quicker to your e-mail - I've been on
vacation the last week and a half. Some comments inline below.

On Sat, Jul 23, 2016 at 3:50 AM, Dennis Guse
<dennis.g...@alumni.tu-berlin.de> wrote:
> Then lets get started.
> Due to the relatively large number of changes, we will split them up
> into individual patches:

Individual patches are great! Smaller changes are always easier to review.

> 1) Support for interleaved stereo (mainly softmix and struct channel)
> 2) Extension of confbridge with binaural synthesis via convolution (if
> channel supports stereo)
>
> For the patches, we will remove the hard dependency to OPUS (although
> we will stick to using it) and also enable L16 with stereo.
>
> Nevertheless, there are still some open questions:
>
> 1. Storage and description of HRTFs
> Impulse responses are at the moment compiled into Asterisk as a header file.
> This header file is generated using a custom C-program converting a
> multi-channel wave file into a float-array - hrirs_fabian.wav was
> taken from the SoundScapeRenderer
> https://github.com/SoundScapeRenderer/ssr/tree/master/data/impulse_responses/hrirs
>
> For positioning a sound source, the HRTFs for the left and for the
> right ear need to be selected according to the desired angle.
> This information is at the moment hard-coded as we use a 720-channel
> wave (interleaved: left, right) to cover 360 degrees completely.
>
> Would you prefer to compile the HRTFs into Asterisk (incl. the
> hard-coded description) or rather make this configurable?
> For the second option, we would need some support in terms of how to
> add configuration options.

For an initial implementation, I would recommend hard-coding it. If a
different data set is needed for different listeners, that would be an
improvement that someone could make at a latter time.

> 2. Configuration of positioning of conference participants
> The positioning of individual participants is at the moment hard-coded
> (compiled via header-file).
> This is basically an array containing the angles at which participant
> _n_ is going to be seated.
> This could also be made configurable via configuration file.
>
> Furthermore, all participants of a conference receive the _same_
> acoustical environment (i.e., participant 1 always sits in front of
> the listener etc.).
> This  limits the computational requirements while individual listeners
> cannot configure their desired seating order.
> In fact, the own signal of a participant is subtracted after rendering
> the whole environment before sending the signals back.

Again, I would punt on making this configurable. If the default
experience is "good enough", effort put into making this configurable
will be wasted. If it is not "good enough", then effort could be
expended into making it configurable.

> 3. Internal sampling rate of Confbridge
> The binaural synthesis is at the moment conducted at 48kHz.
> This is actually due to our use of OPUS, which always uses 48kHz for
> the decoded signals.
> Is this ok?

I'm not sure I have a good answer to this. I think it depends on what
the experience is like if a lower sampling rate is used. What happens
if the sampling rate used in the conference is 8kHz or 16kHz?

> 4. Is the dependency to libfftw3 an issue?

libfftw3 if GPLv2, so no, it should not be an issue.

https://github.com/FFTW/fftw3/blob/master/COPYING

That being said, it should not be a hard dependency. If libfftw3 is
not installed, the feature should simply not be available.

-- 
Matthew Jordan
Digium, Inc. | CTO
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
Check us out at: http://digium.com & http://asterisk.org

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

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

Re: [asterisk-dev] Asterisk goes Spatial Conferencing: the STEAK project

[Matthew Jordan]

On Tue, Jul 19, 2016 at 4:59 PM, Matt Fredrickson <cres...@digium.com>
wrote:

> On Tue, Jul 19, 2016 at 12:59 PM, Sean Bright <sean.bri...@gmail.com>
> wrote:
> > On 7/19/2016 10:35 AM, Matt Fredrickson wrote:
> >>
> >> Response below.
> >>
> >> On Mon, Jul 18, 2016 at 7:18 AM, Dennis Guse
> >> <dennis.g...@alumni.tu-berlin.de> wrote:
> >>>
> >>> Technical Details (at the moment the modifications are based upon
> >>> 13.6.0):
> >>> * Enabled OPUS (with incoming stereo and outgoing stereo [interleaved])
> >>> * Extended softmix for stereo support (downmixing)
> >>> * Extended the default confbridge (basically added a convolution
> engine)
> >
> >
> > If Opus is a required part of the implementation - and from reading the
> > description of the work being done it appears to be - wouldn't that make
> > this ineligible for inclusion?
>
> My hope is that there is a large amount of core Asterisk work which
> does not explicitly require Opus for it to be merged.  I'm hoping that
> our current Opus legal impasses will not go on forever, but until
> things clear up with regards to it, this is the best response I can
> give.
>
>
The only thing that we can't include at this time is the codec module
itself, which - if implemented correctly - should be a separate shared
object library. That means that all the rest can be put up for code review,
and anyone who wants to take advantage of the new feature(s) can simply
load an externally available codec_opus.

So - if you're interested - please do contribute the patches back upstream.

-- 
Matthew Jordan
Digium, Inc. | CTO
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] Development of asterisk 1.4.23 Can we please get some development?

[Matthew Jordan]

On Thu, Jul 14, 2016 at 5:25 PM, Loren Tedford <lorentedf...@gmail.com>
wrote:

> I have only been using the project since 2013 I had no idea at the time
> what version of asterisk was being used to install the modules needed..
>
> Forgotten or not this is where we stand with it now..
>
> Even if a developer donated 20 minutes on it a week that adds up to
> roughly 17 hrs of possible improvement from what we got..
>
> I have experimented with trying to cobble things together on older
> versions of asterisk what i generally find is it literally barfs all over
> the place.. It really seems like they have changed some thing in the way
> asterisk handles the transmit and receive sides of everything.. To my
> knowledge I do not see any developers with  in the app_rpt actually posting
> any work or upgrades to the project.. I figured since asterisk was asterisk
> at one point in time developers might at least be interested in helping out
> or donating some time..
>
> Their is alot of cool things that could be done with it if it was
> integrated with asterisk phone system today even in the commercial world..
>
> I wonder what exact core changes occurred to create the problem we have
> today and is it reversible or do we need to completely redesign asterisk..
>
>
The modules you are referring to were removed quite awhile ago due to not
having an active maintainer contributing to the project [1]. Since no one
active in the project used the modules, or could verify their
functionality, and those who were using them had forked Asterisk
completely, we opted to remove them rather than ship broken or vulnerable
code.

I do not think that anyone in Digium is interested in maintaining these
modules, nor is anyone here interested in doing the port of the old 1.4
modules to the existing code base. I think all of us would be happy to
answer questions, but someone else in the greater Asterisk community would
have to do the work and commit to being the maintainer of those modules.

Asterisk is an open source project. As an open source project, anyone -
absolutely *anyone* - can step up, modify the existing
app_rpt/chan_usbradio/core of Asterisk, and submit the patches back to the
project. We have a lot of resources to help with that:

(1) Coding guidelines so that your submission fits within the standards of
the rest of the project [2]
(2) A well defined process for submitting patches to the project [3],
participating in code review [4], and understanding the kinds of things
reviewers will look for in submissions [5]
(3) An automated test suite for verifying functionality [6], with a Jenkins
based open source infrastructure definition [7] that trigger on patch
submission
(4) This mailing list, for when you have questions about the code and get
stuck
(5) The #asterisk-dev IRC channel, for when you want your questions
answered in real-time

If you're interested, you may want to review the resources mentioned above
and linked below, and familiarize yourself with the major changes in
Asterisk from 1.4 to now. The most influential of those would be:

(1) The API changes made in DAHDI, which - if I understand correctly - were
never adopted by the modules and were the first breaking change
(2) The adoption of reference counted semantics for ast_channel done in
Asterisk 1.8
(3) The opaquification of the ast_channel structure done in Asterisk 11
(4) If any native bridging is used anywhere, the bridging framework
introduced in Asterisk 12
(5) The stasis message bus as a mechanism to raise information to reporting
systems (CDR, CEL, AMI), introduced in Asterisk 12

Matt


[1] https://reviewboard.asterisk.org/r/1764/
[2] https://wiki.asterisk.org/wiki/display/AST/Coding+Guidelines
[3] https://wiki.asterisk.org/wiki/display/AST/Patch+Contribution+Process
[4] https://wiki.asterisk.org/wiki/display/AST/Code+Review
[5] https://wiki.asterisk.org/wiki/display/AST/Code+Review+Checklist
[6]
https://wiki.asterisk.org/wiki/display/AST/Asterisk+Test+Suite+Documentation
[7] http://git.asterisk.org/gitweb/?p=asterisk/infrastructure.git;a=summary

-- 
Matthew Jordan
Digium, Inc. | CTO
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
Check us out at: http://digium.com & http://asterisk.org
-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

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

Re: [asterisk-dev] Asterisk Load Performance

[Matthew Jordan]

On Wed, Jul 6, 2016 at 2:20 PM, Michael Petruzzello <
michael.petruzze...@civi.com> wrote:

> On Tue, Jul 5, 2016 at 4:03 PM, Jonathan Rose  motorolasolutions.com> wrote:
>
> > If you don't need all of your participants actually to be speaking at a
> > time (and I hope not with that kind of volume), you could use holding
> > bridges for the vast majority of the partipants. Link the bridges using a
> > local channel with the Hold bridge side being set to use the 'announcer'
> > bridge role and the hold bridge will effectively just be voiceless
> > conference participants. If you want, you can listen for DTMF events to
> > move the participants back and forth between the different bridges.
>
> Doing the conference this way results in the same kind of long voice queue
> warnings/errors as before and eventually the DNS lookup for the server
> fails. All 5,000 callers were able to get in though, which is a bit better
> than before.
>
> On Tue, Jul 5, 2016 at 5:09 PM, *Richard Mudgett  <http://digium.com>*> wrote:
>
> > The exceptionally long voice queue length messages can be a symptom of
> > thread
> > starvation as the Local channels frame queue has developed an excessive
> > backlog.
> >
> > The forthcoming v13.10.0 release should indirectly take care of the
> EEXISTS
> > messages
> > as part of the https://issues.asterisk.org/jira/browse/ASTERISK-26088
> fix.
> > Working on
> > that issue I saw the EEXISTS messages for REGISTER and SUBSCRIBE message
> > processing.  The issue was a result of the original message and
> > retransmissions getting
> > backlogged in the serializer/taskprocessor and responses sent using
> another
> > serializer.
> >
> > Looks like your system's DNS resolver has gotten overwhelmed.
>
> Is there any configuration changes I can make to help alleviate the thread
> starvation on the Local channels frame queue?
>
> It does not make sense to me that the system's DNS resolver is getting
> overwhelmed. When I have 10,000 calls in one bridge, this does not occur.
> When I have multiple bridges with locally originated channels bridging them
> then the DNS errors occur.
>
> > Wow.  Thanks Jonathan.  I hadn't thought of doing it that way.  That
> should
> > really drop the mixing load.
> > Probably should allow only ulaw or alaw (pick one) for all participants
> to
> > minimize translation costs.
> > One additional thing I should add is that those linking Local channel
> > bridges should just allow the
> > chosen alaw/ulaw to reduce translation to each participant in the holding
> > bridge.  The forthcoming
> > v13.10.0 adds the ability to specify formats when ARI originates a
> channel
> > (Local in this case) and
> > an originator channel is not available.  (See CHANGES file)
>
> I have only been allowing ulaw. That is very interesting to note about the
> Local channels. I'll keep that in mind.
>
> Well, thank you Jonathan, Richard, and Matthew. You have all been really
> helpful. This has been really interesting trying to get 10,000 callers on
> one Asterisk server. As Asterisk is not capable on one server for what I am
> trying to do, I am going to design a scalable, multi-server architecture
> instead.
>

 While that's definitely a more sustainable approach, it has been awfully
entertaining/interesting to see how far you were able to take it. I think
everyone was pretty impressed when you hit 5000 channels in a single
bridge. Thanks for giving it a shot!

As an aside, what were you using to simulate the callers? SIPp + a pcap
file, or something else?

Matt

-- 
Matthew Jordan
Digium, Inc. | CTO
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
Check us out at: http://digium.com & http://asterisk.org
-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

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

Re: [asterisk-dev] ASTERISK-26145 - Task Process Issues possibly caused by HEP

[Matthew Jordan]

On Tue, Jun 28, 2016 at 9:48 AM, Matt Fredrickson <cres...@digium.com> wrote:
> On Tue, Jun 28, 2016 at 8:54 AM, Ross Beer <ross.b...@outlook.com> wrote:
>> Hi,
>>
>>
>> I am still facing a task processor issue on subm:rtp_topic-00de, looking
>> at the backtrace it looks to be related to HEP.
>
> Sounds like you're having some good luck sleuthing :-)
>
>> HEP is enabled by default and sends packets to 192.168.1.1:9061, shouldn't
>> this be disabled by default and not enabled in Asterisk 13? It makes no
>> sense to send packets if you can't be sure that a HEP server exists at the
>> default server location.
>
> I'd tend to agree with that logic.  I haven't done much work with HEP,
> but if HEP is enabled by default, we should probably change that
> behavior.  HEP should only be enabled if you "opt in" by setting it
> up.
>
> Just my .02.
>
> Anybody else have any thoughts?
>

I don't really care if they are enabled by default or not. For the
most part, most modules in Asterisk are 'opt-out', not 'opt-in', but
it doesn't really matter to me. Alternatively, instead of disabling
the modules from building, the HEP modules can be disabled by setting
the 'enabled' option to 'no' - which could also be changed in the
sample config file.

I will say that if you're installing the sample config files and not
updating them - particularly for things that you aren't interfacing to
- then you're setting up your systems poorly. The sample config files
have long been used for documentation purposes - running 'make
samples' and walking away is going to give you a bad time, and not
just because of the HEP modules.

Since these are just config file modifications we're talking about, a
patch should be provided and submitted to Gerrit. This is a patch that
anyone - including the issue reporter - could write. To echo what Josh
said, this doesn't really merit a lengthy discussion on the mailing
list, nor does it require 'poking' developers.

Matt

-- 
Matthew Jordan
Digium, Inc. | CTO
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
Check us out at: http://digium.com & http://asterisk.org

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

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

Re: [asterisk-dev] Asterisk Load Performance

[Matthew Jordan]

> >> a lot of
>> >> processing time and the CDR taskprocessor queue backlog can take
>> >> minutes to
>> >> clear.
>> >>
>> >
>> >To echo what Richard said, because Asterisk is now sharing state
>> >across the Stasis message bus, turning off subscribers to that bus
>> >will help performance. Some easy ones to disable, if you aren't using
>> >them, are CDRs, CEL, and AMI. Those all do a reasonable amount of
>> >processing, and you can get some noticeable improvement by disabling
>> >them.
>> >
>> >Once you get past that, you can start fiddling with some of the lower
>> >level options. To start, you can throttle things back further by
>> >disabling certain internal messages in stasis.conf. As stasis.conf
>> >notes, functionality within Asterisk can break (or just not happen) if
>> >some messages are removed. For example, disabling
>> >'ast_channel_snapshot_type' would break ... most things. You may
>> >however be able to streamline your application by looking at what ARI
>> >messages it cares about, what messages it doesn't, inspecting the
>> >code, and disabling those that you don't care about. Lots of testing
>> >should occur before doing this, of course.
>> >
>> >You may also be able to get some different performance characteristics
>> >by changing the threadpool options for the message bus in stasis.conf.
>> >This may make a difference, depending on the underlying machine.
>>
>> Thank you for the suggestions.
>>
>> I'm running Asterisk on 40 vCPUs with 120 GB of RAM. Changing the thread
>> pool options to many more threads is not increasing performance, and at a
>> certain point it decreases performance.
>>
>> With further testing and having implemented your suggestions, I am
>> realizing the subm:devService-test-0038 task processor is a major
>> bottleneck. I have always read that Asterisk can handle as many calls as the
>> hardware allows, but I'm not seeing that.
>>
>> I can go with a different architecture of multiple Asterisk servers
>> working together, but I would prefer one server to reduce complexity.
>>
>> What I am doing is not really a stress test because I really need Asterisk
>> to handle 1000s of callers calling in within a few minutes.
>
>
> The subm:devService-test-0038 taskprocessor is servicing the stasis
> message bus
> communication with your devService-test ARI application.  Since each
> taskprocessor is
> executed by one thread, that is going to be a bottleneck.  One thing you can
> try is to
> register multiple copies of your ARI application and randomly spread the
> calls to the
> different copies of the application.  (devService-test1,
> devService-test2,...)
>

To follow up with Richard's suggestion:

Events being written out (either over a WebSocket in ARI or over a
direct TCP socket in AMI) have to be fully written before the next
event is written. That means that the client application processing
the events can directly slow down the rate at which events are sent if
the process that is reading the event does not keep reading from the
socket as quickly as possible. You may already be doing this - in
which case, disregard the suggestion - but you may want to have one
thread/process read from the ARI WebSocket, and farm out the
processing of the events to some other thread/process.

-- 
Matthew Jordan
Digium, Inc. | CTO
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
Check us out at: http://digium.com & http://asterisk.org

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

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

Re: [asterisk-dev] Asterisk Load Performance

[Matthew Jordan]

On Fri, Jun 17, 2016 at 1:37 PM, Richard Mudgett <rmudg...@digium.com> wrote:
>
>
> On Fri, Jun 17, 2016 at 12:36 PM, Michael Petruzzello
> <michael.petruzze...@civi.com> wrote:
>>
>> Hello,
>>
>> I am currently working on determining bottlenecks in Asterisk and a Stasis
>> App. I'm currently trying to handle 83.3 calls/second. For the most part,
>> Asterisk and the Stasis APP handle that well, but there is a 60+ second
>> delay in response time.
>>
>> On the Asterisk side, I am seeing the following warnings. [Jun 17
>> 12:00:16] WARNING[23561]: taskprocessor.c:803 taskprocessor_push: The
>> 'subm:cdr_engine-0003' task processor queue reached 500 scheduled tasks.
>> [Jun 17 12:00:18] WARNING[25477][C-0068]: taskprocessor.c:803
>> taskprocessor_push: The 'subm:devService-test-0038' task processor queue
>> reached 500 scheduled tasks.
>> [Jun 17 12:00:21] WARNING[26298][C-00a3]: taskprocessor.c:803
>> taskprocessor_push: The 'subp:PJSIP/sippeer-0022' task processor queue
>> reached 500 scheduled tasks.
>> [Jun 17 12:00:23] WARNING[27339][C-010d]: taskprocessor.c:803
>> taskprocessor_push: The 'subm:ast_channel_topic_all-cached-0032' task
>> processor queue reached 500 scheduled tasks.
>> [Jun 17 12:01:32] WARNING[31697][C-03b2]: taskprocessor.c:803
>> taskprocessor_push: The 'subm:ast_channel_topic_all-0036' task processor
>> queue reached 500 scheduled tasks.
>> [Jun 17 12:05:55] WARNING[23280]: taskprocessor.c:803 taskprocessor_push:
>> The 'SIP' task processor queue reached 500 scheduled tasks.
>>
>> I have not seen a configuration setting on Asterisk to prevent these
>> warnings from occurring (I'm trying to avoid modifying Asterisk source code
>> if possible). Looking at the task processors, I see the queue to the stasis
>> app bottlenecks:
>> subm:devService-test-00384560990  0
>> 1041689. It does clear up relatively quickly. The CDR engine also bottle
>> necks (extremely badly), but I don't use that. Nothing else comes close to
>> having a large queue.
>>
>> The stasis app itself is extremely streamlined and is very capable of
>> handling a large number of messages at a time. The app runs with the JVM so
>> I am also researching into that as well as the netty library I am using for
>> the websocket connections.
>>
>> Any insight into Asterisk's side of the equation and how it scales on 40
>> vCPUs would be greatly appreciated.
>
>
> There are no options to disable those taskprocessor queue size warnings.
> They are a
> symptom of the system being severely stressed.  If the stress continues it
> is possible
> that the system could consume all memory in those taskprocessor queues.
>
> Recent changes to the Asterisk v13 branch were made to help throttle back
> incoming
> SIP requests on PJSIP when the taskprocessors become backlogged like you are
> seeing.
> These changes will be in the forthcoming v13.10.0 release.  If you want, you
> can test with
> the current v13 branch to see how these changes affect your stress testing.
>
> If you don't need CDR's then you really need to disable them as they consume
> a lot of
> processing time and the CDR taskprocessor queue backlog can take minutes to
> clear.
>

To echo what Richard said, because Asterisk is now sharing state
across the Stasis message bus, turning off subscribers to that bus
will help performance. Some easy ones to disable, if you aren't using
them, are CDRs, CEL, and AMI. Those all do a reasonable amount of
processing, and you can get some noticeable improvement by disabling
them.

Once you get past that, you can start fiddling with some of the lower
level options. To start, you can throttle things back further by
disabling certain internal messages in stasis.conf. As stasis.conf
notes, functionality within Asterisk can break (or just not happen) if
some messages are removed. For example, disabling
'ast_channel_snapshot_type' would break ... most things. You may
however be able to streamline your application by looking at what ARI
messages it cares about, what messages it doesn't, inspecting the
code, and disabling those that you don't care about. Lots of testing
should occur before doing this, of course.

You may also be able to get some different performance characteristics
by changing the threadpool options for the message bus in stasis.conf.
This may make a difference, depending on the underlying machine.

-- 
Matthew Jordan
Digium, Inc. | CTO
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 for developing a channel driver module

[Matthew Jordan]

On Mon, May 23, 2016 at 2:23 AM, Gilles Mazoyer
<mazoyer.gil...@omega.ovh> wrote:
> Hi
>
> Thank you for the information.
> That's what i already do so no need to change my module. Good !!!
>

Hi Gilles -

One other hopefully useful comment I could make is to follow the
models of the newer channel drivers, as opposed to some of the older
ones. Over time, the developer community has moved towards splitting
channel drivers up into components, as opposed to lumping all of the
functionality into a single monolithic file/module. This greatly aids
maintainability.

While it is somewhat an extreme example of this, the PJSIP channel
driver consists of:
 - The channel driver (chan_pjsip), which acts as a bridge between the
Asterisk channel core and the rest of the protocol stack
 - The basic protocol stack (res_pjsip), which interfaces with the
PJSIP library and provides major functionality for the SIP protocol
 - Specific modules that build on aspects of the SIP protocol, such as
res_pjsip_session for requests the create media sessions,
res_pjsip_registrar for handling registrations, etc.
 - And even more specific modules for very specific SIP features, such
as dialog info bodies

I'd encourage anyone writing a new channel driver to think of
splitting the functionality up into - at a minimum - separate files.
Keeping the Asterisk channel core integration separate from the
protocol handling itself generally keeps things a lot cleaner.

Hope this helps -

Matt

-- 
Matthew Jordan
Digium, Inc. | Director of Technology
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 14 Feature Freeze Reminder

[Matthew Jordan]

Hello everyone!

As you may or may not be aware, today is the feature free reminder [1] for the
next version of Asterisk. This is a notice that Asterisk 14 will be feature
frozen on July 20th, 2016. Having the branch be feature frozen gives the
Asterisk Developer Community time to test out the new features and improvements
that have been made to master since the last major release, Asterisk 13.

"But wait," you may ask yourself. "What does 'feature freeze' even mean if we
are adding new features to Asterisk 13?"

Good question!

On July 20th, the Asterisk team will create the Asterisk 14 branch, along with
a branch specifically for the first release of Asterisk 14, 14.0.0. As new
features are developed, they can be proposed both for Asterisk 13 as well as
for the Asterisk 14 mainline branch, subject to the 'you must have tests for
release branches' policy [2]. Meanwhile, the Asterisk 14.0.0 branch will remain
frozen, and the first beta/release candidates will be cut from it. When Asterisk
14.1.0 is released, it will contain any minor new features or improvements
that were made in the meantime and were merged into the Asterisk 14
mainline branch.

This policy balances the need to test out the new changes in master in a version
that is not a moving target, while allowing the Asterisk Developer Community to
continue to improve and enhance Asterisk.

Happy Coding -

Matt

[1] https://wiki.asterisk.org/wiki/display/AST/Asterisk+Versions
[2] 
https://wiki.asterisk.org/wiki/display/AST/Software+Configuration+Management+Policies#SoftwareConfigurationManagementPolicies-NewFeatures

-- 
Matthew Jordan
Digium, Inc. | Director of Technology
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] Plan for updating the ARI Swagger Version

[Matthew Jordan]

On Tue, Feb 9, 2016 at 3:56 AM, Dan Jenkins <dan.jenkin...@gmail.com> wrote:

> Hi Everyone,
>
> I've been looking at how we can add proxy support (1) to the Node.js ARI
> Client for the past couple of days and have hit a few issues which I'm sure
> we'll be able to work out. But this has led me down the path of looking
> into the current status of swagger.
>
> Swagger recently donated it's specification to the OpenAPI initiative and
> so the specification is now called the OpenAPI specification. It was also
> bumped to version 2.0 (2). While updating a dependency for no real gain
> isn't always seen as a good thing. In this case, I feel we are going to get
> to a point (and are already nearing it) where tools that we want to use
> around swagger will become obsolete for the version of swagger we are using
> within Asterisk.
>
> I've been looking at generating libraries from the swagger specification
> and came across many many issues because we're using version 1.1 - the
> swagger team were surprised I was even attempting it. The other code
> generator I was looking at has a minimum of specification version 1.2. I
> fear this issue will only get worse as time goes on.
>

I do think it would be good for us to upgrade our version of Swagger we're
using. We're really using a strange hybrid of 1.1 and 1.2 (mostly 1.1), due
to the state of flux the 1.2 specification was in when we added the ARI API
to Asterisk.

That aside, I will note a few personal issues I have with Swagger:
(1) Their version bumps are all major. 1.1 to 1.2 is a massive change; 1.2
to 2.0 is another massive change. They don't adhere to semantic versioning,
and you can expect pedantic changes that add little value but break
compatibility horribly to be in any version change. Since we wrote our own
Swagger generator to build the C code for ARI, this is a major project for
Asterisk.
(2) As a project, they are absolutely terrible at backwards compatibility;
their recent statement of deprecating swagger-tools [1] does not fill me
with confidence that they are going to get better at supporting the users
of their specification/libraries. We absolutely will be chasing a moving
target if we try to keep compatibility with them.
(3) This doesn't just impact Asterisk; any client library that works with
ARI has to accommodate multiple schema versions. For the ari-py library,
that's going to be inherently destructive, as it only understands the 1.1
schema. It also means we can't update our Swagger support without breaking
existing applications.

All of my griping aside, I do think it is good to update our Swagger
version when doing so makes the lives of Asterisk developers better, but I
think updating for the sake of staying in lock-step with Swagger is not
going to end well for the project. (It honestly feels like chasing Google
Talk/Voice and their never-ending changes to their "spec".)


>
> Now, I'm not saying we need to change it right now, and I know there are
> inherent difficulties with upgrading the version of the specification that
> we use, as it then ruins libraries that expect to work with swagger version
> 1.1 etc, however, I think we do need a plan to update the version - whether
> that's with Asterisk 14 or whatever; as long as its on the roadmap then I'm
> happy, currently I don't think it is.
>
> What are people's thoughts?
>
>
I think it would be good to put it on the list of things that would be nice
to see in Asterisk 14.

I will say that this is one of the very few places in Asterisk where
someone without C experience could contribute! The generators are all
written in Python, using mustache templates to build out the wiki
documentation and C implementation/header files. So long as you don't
change the structure of what is fed to the mustache templates, you could
conceivably update the JSON and Python interpreters and not have to know a
single line of C code.

[1] https://github.com/apigee-127/swagger-tools/issues/335

-- 
Matthew Jordan
Digium, Inc. | Director of Technology
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] Proposal to bring pjproject back into the fold

[Matthew Jordan]

s, not removing the
static libraries. Asterisk will still run, and now crash in a different
fashion. They will then attempt to remove the static libraries, and now
Asterisk will complain that it can't find pjproject because you're using
RHEL and your pkg-config path isn't set up correctly.

Is this all user error? Of course. But this happens *a lot*, and it is
signals that there is a problem with the environment that we're expecting
people to operate under.


Can all of the above issues be alleviated in some fashion via various
technical changes? I'd hazard a guess and say "yes". However, I think that
even if we alleviate them, we're going to still be left with a situation
where the most important functionality in Asterisk - its SIP stack - is
more challenging to get configured and set up than what users feel it
should be. That's a bad situation for users. I know the packagers feel that
having anything embedded or statically linked is worse for users;
unfortunately, after witnessing where we're at after nearly three years
with the current model, I disagree with that feeling.

I think a number of developers in the Asterisk project are frustrated by
this situation. There has been a lot of time and energy invested into
trying to make the current model work, and we still see a lot of users
frustrated by the current requirements we're levying on them. Continuing to
throw more development time at a problem to satisfy a small group of people
who categorically refuse to brook any compromise is a difficult proposition
for me.

I'll go so far as to say that in my time on the Asterisk project, I
personally feel that the single worst technical decision I've made was in
making it so that the only way to use pjproject was via shared object
libraries. The pain to users, and the impact this has had on adoption of
the PJSIP stack in Asterisk, isn't something I can even begin to calculate.

[1]
https://wiki.asterisk.org/wiki/display/AST/Building+and+Installing+pjproject

-- 
Matthew Jordan
Digium, Inc. | Director of Technology
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] Proposal to bring pjproject back into the fold

[Matthew Jordan]

On Wed, Jan 20, 2016 at 11:04 AM, Tzafrir Cohen <tzafrir.co...@xorcom.com>
wrote:

> On Wed, Jan 20, 2016 at 09:49:32AM -0600, Matthew Jordan wrote:
> > On Wed, Jan 20, 2016 at 8:22 AM, Jared Smith <jaredsm...@jaredsmith.net>
>
> > So why is pjproject such a pain?
> >
> > There's probably a number of reasons, and I'm probably forgetting some,
> but
> > I'd boil the top ones down to the following:
> >
> > * pjproject embeds third party libraries.
> >
> > Some of those third party libraries are also libraries that Asterisk can
> > use; if Asterisk needs to use them, you have to tell pjproject to not use
> > its embedded version. While it is easy to say that pjproject should "just
> > not do that", that misses the original - and still one of the most
> common -
> > use cases of pjproject; namely, as an embedded systems library. For
> people
> > building SIP devices on embedded platforms, having embedded versions of
> > GSM, SRTP, and other useful libraries is actually advantageous. Packages
> > are not usually available for, say, VxWorks, and if I know pjproject can
> be
> > built using my esoteric toolchain, I don't have to try and make libsrtp
> > build as well with it.
> >
> > As a result, pjproject is highly unlikely to ever remove their embedding
> of
> > third party libraries, despite our attempts at convincing them to do
> that.
> > They serve *more* than just the Asterisk project, and our needs are not
> > always going to match 100% with theirs.
> >
> > The implications of that are that we're going to need to work around
> and/or
> > deal with the third party libraries they embed in some fashion.
>
> I'm not sure what your exact issue is here.
>
> Is there any specific library that pjproject currently embeds that can't
> be trivially disabled? Do you think there is an issue with pjproject not
> defaulting enough to using system libraries where possible?
>
> > * pjproject static/shared libraries is confusing for many people
> >
> > It is not uncommon for people to build static libraries of pjproject the
> > first time around (missing the instructions to not do that), install
> them,
> > and run Asterisk. Asterisk then will crash or do something terrible. They
> > will then attempt to install the shared object libraries, not removing
> the
> > static libraries. Asterisk will still run, and now crash in a different
> > fashion. They will then attempt to remove the static libraries, and now
> > Asterisk will complain that it can't find pjproject because you're using
> > RHEL and your pkg-config path isn't set up correctly.
>
> Hang on. This is RHEL. A stable platform. Why can't they just use
> pjproject packages and be done with it?
>
>
The same question could be asked of why they choose to build Asterisk from
source.

I won't get into why a user may choose to build from source versus install
from packages, nor am I going to blame a user for choosing to do so. The
user experience in that situation is sub-optimal.

Matt

-- 
Matthew Jordan
Digium, Inc. | Director of Technology
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] Proposal to bring pjproject back into the fold

[Matthew Jordan]

On Tue, Jan 19, 2016 at 6:04 AM, Joshua Colp <jc...@digium.com> wrote:

> George Joseph wrote:
>
>> I'm VERY frustrated with pjproject right now.  Not the software itself
>> (well maybe a little) but the fact that troubleshooting is a nightmare
>> because we can't control what version of pjproject was installed along
>> with Asterisk and we can't control what options it was compiled with.
>> This leads to issue where we're getting great debugging from Asterisk
>> but nothing at all from pjproject because the user installed from their
>> distro and it has no debugging info.  So now we have to walk them though
>> getting pjproject from source, etc, etc.  This can also cause issues
>> should Teluu change an API or some behavior that we're not prepared for
>> and the user just does a 'yum update pjproject' and Asterisk dies.  Then
>> there's the issue where even though the verison is the same, the
>> compiled-in options differ, some of them quite fatally.  That unleashes
>> a whole other mess.
>>
>
> There is the middle ground which is keep the ability to link against a
> shared system library if present but also bundle a pjproject and use it if
> the system library is not present (or you force the bundled version).
>

I'd certainly still like a packaged pjproject to take precedence if
available. This allows package maintainers to meet the guidelines of their
distros, and eases their burden.


>
> pjproject was deeply embedded in 11 and I don't think that was right but
>> I think we went too far in 13 by taking the hands-off approach.  Maybe
>> at the start of 13 it was ok, but we've since put chan_sip into
>> "extended" support so we're pushing chan_pjsip as the supported stack,
>> instead of it just being optional.  Not to mention that chan_sip needs
>> res_rtp_asterisk which is also dependent on pjproject.  Can you see
>> where I'm going? :)
>>
>
> In the current shared library method it is not a hard dependency.
>
>
>> I propose that we bring pjproject into a new 'third-party' directory and
>> statically link our res_pjsip* modules to it.  We should NOT check it
>> into the Asterisk repository however.  Instead we should use scripts
>> like get_mp3_source to get a specific pjproject version and a 'patches'
>> directory that IS checked in that has things we've discovered we need.
>> The patches should always be proposed upstream.
>>
>> It's a lot of work but I'm willing to dig in and I'll bet I could get a
>> few volunteers to help.
>>
>
> From a technical perspective you can not statically link each module to
> PJSIP, each module will end up with its own isolated running copy. You need
> to statically link it into one module (res_pjsip, or res_pjproject for
> example) and have it export all of the symbols to everything else.
> Additionally because all the symbols aren't actually being used the linker
> also likes to remove them unless you do magic to force them to be present
> regardless. This is how the PJSIP support was originally developed before
> shared library support was added to pjproject. If you go back in time
> almost everything needed to make it work in a bundled configuration is
> there already.
>

Would we automatically download and link pjproject when someone runs
'make', or would it require some different make target?

-- 
Matthew Jordan
Digium, Inc. | Director of Technology
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
Check us out at: http://digium.com & http://asterisk.org
-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

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

Re: [asterisk-dev] Asterisk - 13.6.0 - While bring up Asterisk seeing error "undefined symbol":

[Matthew Jordan]

On Thu, Dec 31, 2015 at 6:20 AM, Boobalan M <boobalan...@plintron.com>
wrote:

> Hi Team,
>
>
>
> We are encountering below issue often when try to make asterisk up.
>
>
>
> "
>
> [Dec 31 13:31:35] WARNING[17782]: loader.c:553 load_dynamic_module: Error
> loading module 'app_voicemail.so':
> /usr/lib64/asterisk/modules/app_voicemail.so: undefined symbol:
> ast_say_date_with_format
>
> "
>
>
>
> This issue we can able to solve rebuilding whole asterisk only. But some
> times, rebuild also doesn't work.
>
>
>
> Both Asterisk logs and symbols details of one of the modules(
> app_voicemail.so) from error list are attached.
>
>
>
> We could see “ast_say_date_with_format” is marked as undefined . This we
> are saying from “nm --demangle app_voicemail.so” output. But I am not
> sure why it often comes.
>
>
>
> Can you please suggestion on this to sort it out since we are facing this
> issue very often.
>
>
>

ast_say_date_with_format is a function pointer, defined in say.h:

SAY_EXTERN int (* ast_say_date_with_format)(struct ast_channel *chan,
time_t t, const char *ints, const char *lang, const char *format, const
char *timezone) SAY_INIT(ast_say_date_with_format);

As the documentation in that header file explains, a module must assign
these function pointers if they wish to change the default functionality
from the internal implementation in say.c. You'll note that this is done by
a constructor function in say.c:

/*! \brief
 * remap the 'say' functions to use those in this file
 */
static void __attribute__((constructor)) __say_init(void)
{
ast_say_number_full = say_number_full;
ast_say_enumeration_full = say_enumeration_full;
ast_say_digit_str_full = say_digit_str_full;
ast_say_character_str_full = say_character_str_full;
ast_say_phonetic_str_full = say_phonetic_str_full;
ast_say_datetime = say_datetime;
ast_say_time = say_time;
ast_say_date = say_date;
ast_say_datetime_from_now = say_datetime_from_now;
ast_say_date_with_format = say_date_with_format;
}

As well, if loaded, app_playback will override this in its say_init_mode
function. This allows it to change the hardcoded 'say' functions in the
core with the functionality provided by say.conf.

All of this is to say: ast_say_date_with_format is absolutely a defined
function pointer. I'm not sure what compiler you're using, what you've
modified, or how you're building Asterisk, but in all the tens of thousands
of builds I've seen done with both gcc and clang, I've never seen either
compiler have a problem finding the declaration of this function pointer.

The fact that your Errors.txt file is littered with many other symbol
resolution issues makes me think that you have 'tweaked' something,
attempted to build on a very non-standard platform, or are otherwise
operating outside the bounds of the usual build system.

Matt

-- 
Matthew Jordan
Digium, Inc. | Director of Technology
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
Check us out at: http://digium.com & http://asterisk.org
-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

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

Re: [asterisk-dev] Asterisk - 13.6.0 - Registering OWN Module(Application):

[Matthew Jordan]

On Tue, Dec 29, 2015 at 11:50 PM, Kirill Marchuk <62...@mail.ru> wrote:

> Hi Boobalan
>
>  Can you check your code against this one ? (pretty old, but still
> relevant, I guess)
> http://blog.russellbryant.net/2008/06/19/how-to-write-an-asterisk-module-part-1/
>
>  Especially, did you use one of the AST_MODULE_INFO macros ?
>
> Luck !
>
> and Happy New Year!
>
> Kirill Marchuk
>

That blog post is still pretty accurate - we haven't changed the semantics
of loading/registering a module much over the years.

The code in loader.c tells you why this WARNING message is being raised:

/* the dlopen() succeeded, let's find out if the module
   registered itself */
/* note that this will only work properly as long as
   ast_module_register() (which is called by the module's
   constructor) places the new module at the tail of the
   module_list
*/
if (resource_being_loaded != (mod = AST_DLLIST_LAST(_list))) {
ast_log(LOG_WARNING, "Module '%s' did not register itself during
load\n", resource_in);
/* no, it did not, so close it and return */
logged_dlclose(resource_in, lib);
/* note that the module's destructor will call
ast_module_unregister(),
   which will free the structure we allocated in
resource_being_loaded */
return NULL;
}

The module's constructor attributes are automatically added by the
aforementioned AST_MODULE_INFO macros. Failure to add those will cause your
module to not be registered, and hence not be loaded.

-- 
Matthew Jordan
Digium, Inc. | Director of Technology
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] Implementing Native Bridging in a DAHDI kernel driver

[Matthew Jordan]

On Wed, Dec 23, 2015 at 10:27 PM, Fábio Urquiza <f...@cesar.org.br> wrote:

> Hi Matthew. I'm current working on the last 11 version.
>
>
Assuming you want to create a two-party 'native' bridge at the Asterisk
level, then you'll want to look into the 'bridge' channel driver callback
in chan_dahdi as an example to follow. Asterisk will call this channel
driver callback with the two channels that are bridged together. In
Asterisk 11, chan_dahdi performs the reads on the DAHDI channels and - when
a FD on one channel indicates there is data - directly writes the received
data from DAHDI out to the other DAHDI channel with no decoding.

Note that in Asterisk 12+, this mechanism changed. Instead of using a
channel driver callback, a bridging framework is used. That bridging
framework has a pluggable interface, allowing a native bridging technology
to be written in a separate module (outside of the channel driver) and
selected based on criteria it presents to the core. The DAHDI native
bridging is now implemented in the bridge_native_dahdi module.

Matt

-- 
Matthew Jordan
Digium, Inc. | Director of Technology
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] Lock inversion deadlock in asterisk-11.21.0-rc1 and probably 12.x and 13.x

[Matthew Jordan]

On Wed, Dec 23, 2015 at 10:16 AM, Steve Davies <davies...@gmail.com> wrote:

> Thanks Joshua,
>
> I think I knew that, but felt that it might not be seen in a timely
> fashion if that was what I did.
>
> In hindsight, raising both the email and the ticket would have been best.
> My bad - I must be slowing down for Xmas.
>
>
>
Better to make sure everyone knows before a release gets made than to let
it slip through. Thanks Steve!

-- 
Matthew Jordan
Digium, Inc. | Director of Technology
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] Implementing Native Bridging in a DAHDI kernel driver

[Matthew Jordan]

On Tue, Dec 22, 2015 at 4:49 PM, Fábio Urquiza <f...@cesar.org.br> wrote:

> Hi All,
>
> I have a PABX hardware composed of several FXO, FXS and E1 cards and a
> Digital Matrix IC that commutes TDM between it's channels. The software
> that runs the PABX CPU is a embedded linux distribution and I'm planning
> using Asterisk as the Softswitch. I've already have developed a driver with
> basic functions to detect phone off the hook and dial tones, do ringing and
> to commute channels of different cards but now I need to figure out how to
> interface that with Asterisk.
>
> I imagine that I have to implement some DAHDI functions and structures in
> order to the Asterisk dahdi_chan detect the cards and map all to spans. The
> problem is that the natural flow of a DAHDI call consists getting the TDM
> from a channel using dahdi_receive() and sending the TDM to another channel
> using dahdi_transmit(), and I need the TDM to be commuted internally in the
> driver using the Digital Matrix IC.
>
> Browsing the Asterisk documentation I came along a concept called "Native
> bridging" in which all bridging are done internally, with no TDM going
> through the Asterisk. I like to ask you if that is the best approach to
> take on that matter and if you have some pointers of how to implement that
> concept in the DAHDI driver that I'm writing for this particular hardware.
>
> Thanks and best regards,
>
> -Fabio Urquiza
>

Hi Fabio:

The answer to this depends on which version of Asterisk you're targeting.
Which version did you have in mind?

Matt

-- 
Matthew Jordan
Digium, Inc. | Director of Technology
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: wrapuptime is intermittently disregarded

[Matthew Jordan]

On Wed, Dec 16, 2015 at 3:18 AM, Tomec Martin <to...@ipex.cz> wrote:

> Hi all,
>
>
>
> I am solving issue ASTERISK-19820 and want to write patch, but I am not
> sure if I am on good way. Let me explain the issue:
>
> When agent in queue hangs up, his status is updated immediately, but the
> queue member lastcall time is updated after a while (after some logging
> etc.) in function update_queue. So when another caller wants to ring this
> agent, it gets new member status (not_inuse) and old queue member data
> (with old lastcall time). So wrapuptime is compared to wrong (old) lastcall
> time.
>
>
>
> My supposed solution is:
>
> Add new variable „is_in_call“ to struct member
>
> Set „is_in_call“ to true, when the call starts.
>
> Set „is_in_call“ to false on hangup callback (in function update_queue).
>
> Together with wrapuptime check also if „is_in_call“ is set to true.
>
>
>
> I don’t know how to determine call start and I am not sure if the variable
> should be named „is_in_call“. Any opinions are welcome.
>
>
>
> Thanks,
>
> Martin Tomec
>
>
>
Hi Martin:

Most of my thoughts on this come from Asterisk 13. Looking at the issue, it
appears as if the situation hasn't changed between when that issue was
filed and now, so hopefully this line of thinking is applicable to whatever
version you're looking at.

I can definitely see how this could be a bit racey. We essentially have two
things competing here:
 * The updating of the queue member status in update_status. This is,
interestingly enough, updated via a device state change or extension state
change. Even all the way back in 1.8 - and earlier - this would be handled
by some kind of asynchronous message mechanism, which would certainly be
happening on a different thread of execution than the channel threads
sitting in the queue.
 * The update of the 'queue' - which is really updating the member's state
in the queue, followed by updating various statistics of the queue -
happens in 13 when we detect one of three things happening:
  (1) A blind transfer away from the member
  (2) An attended transfer away from the member
  (3) A hangup of the member
  In all of these cases, these again are handled asynchronously off the
message bus. That wouldn't be the case in 11 and earlier - in those
versions, we'd be looking directly at either a masquerade occurring or soft
hangup flags on the member channel. Either way, it's certainly out of band
with the calls to update_status - and it is the same again in 13.

I've tried to think of another solution other than what you're proposing.
Essentially, we'd ideally like to rely on status to know if the member is
on a call or not; however, given the race condition occurring between the
changing of the member state (which should tell us that) and the "clean up
of the member in the queue" logic that is called via update_queue, I don't
think that's quite possible.

I don't think we can also easily combine update_queue with update_status.
update_status is called whenever a device/extension state changes, and
applies in situations other than just termination of a call. update_queue,
on the other hand, only happens on call end, and has certain logic that it
needs.

So: adding something to track the boolean state of whether or not a member
is on a call or not is probably the best approach.

As a cautionary point, I would be careful to test this logic here:

static int is_member_available(struct call_queue *q, struct member *mem)
{
int available = 0;

switch (mem->status) {
case AST_DEVICE_INVALID:
case AST_DEVICE_UNAVAILABLE:
break;
case AST_DEVICE_INUSE:
case AST_DEVICE_BUSY:
case AST_DEVICE_RINGING:
case AST_DEVICE_RINGINUSE:
case AST_DEVICE_ONHOLD:
if (!mem->ringinuse) {
break;
}
/* else fall through */
case AST_DEVICE_NOT_INUSE:
case AST_DEVICE_UNKNOWN:
if (!mem->paused) {
available = 1;
}
break;
}

/* Let wrapuptimes override device state availability */
if (mem->lastcall && q->wrapuptime && (time(NULL) - q->wrapuptime <
mem->lastcall)) {
available = 0;
}
return available;
}

As it would be prone to the race condition you're describing.

-- 
Matthew Jordan
Digium, Inc. | Director of Technology
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] Transcoding: Codec 2, iLBC 20, SILK, GSM-EFR, AMR(-WB)

[Matthew Jordan]

gotiation, if appropriate

There's some good examples of these tests currently in the Asterisk Test
Suite. Most of these tests simply use SIPp to send/receive an offer from
Asterisk and receive/send a corresponding answer:
 * tests/channels/SIP/SDP_offer_answer
 * tests/channels/SIP/SDP_attribute_passthrough
 *
tests/channels/pjsip/sdp_offer_answer/incoming/nominal/single-media-stream/audio/basic
 *
tests/channels/pjsip/sdp_offer_answer/attribute_passthrough/speex_h263_h264

Clearly, additional tests could be written beyond pass through/negotiation,
but it's a good starting point.

-- 
Matthew Jordan
Digium, Inc. | Director of Technology
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] Bridges, T.38, and other good times

[Matthew Jordan]

works around this. However, we have a number of
scenarios where "things happen" in a bridge that involves state on a
channel and - right now - we don't have a unified way of handling it. In
addition to T.38, we also have channels being put on hold, DTMF traversing
a channel, and more. Often, the channel driver has this state - but
instead, we have a lot of 'clean up' logic being added to the bridging core
to handle these situations.

As I see it, we really only have two options here:
(1) Add code to the bridging framework to clean up T.38 on a channel when
it leaves. This is kind of annoying, as it will happen on every channel
when it leaves, regardless of whether or not the channel even supports T.38.
(2) Add a new channel technology callback that a bridge can use to inform a
channel driver that it is being ejected from a bridge. This would give us a
single place to put cleanup logic that has to happen in a channel driver
when it is no longer bridged.

I'm not sure those two options will work, exactly, but it's the best
options that I can think of after exhausting lots of other code changes in
the bridging core. If someone has other suggestions, I'd be more than happy
to entertain them.

Matt


[1] https://jenkins.asterisk.org/
[2]
https://jenkins.asterisk.org/jenkins/job/periodic-asterisk-master/75/testReport/junit/%28root%29/AsteriskTestSuite/tests_fax_pjsip_directmedia_reinvite_t38/
[3] https://gerrit.asterisk.org/#/c/1761/
[4]
https://jenkins.asterisk.org/jenkins/job/periodic-asterisk-master/80/testReport/junit/%28root%29/AsteriskTestSuite/tests_masquerade/

-- 
Matthew Jordan
Digium, Inc. | Director of Technology
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] Transcoding: Codec 2, iLBC 20, SILK, GSM-EFR, AMR(-WB)

[Matthew Jordan]

some
configuration mechanisms for those media formats. I'd have to look more
closely to determine if they are still needed. Keep in mind you can have
pass through support with the format modules - you don't need necessarily
need a format module to pass media from one channel through a bridge to
another, the core merely has to know that the format exists. That also
explains why the media format attribute modules exist - they provide
assistance during negotiation.

SILK and CELT have commercial but free modules offered by Digium - although
due to time constraints, versions of those modules have not been released
for Asterisk 13.



> Final Sentence
>
> Although it would be nice to see at least some of this work in Asterisk, I
> am mainly interested in a code-review. Is it possible to submit everything
> for code-review even if there is no chance to pass?
>

Code posted to Gerrit really does need to be licensed back to the project -
in fact, that's why we require a CLA to be assigned to log into Gerrit. It
makes it a lot simpler for everyone participating in the project to know
what rules they are playing by.

That being said, everything you've proposed sounds like it would be
admissible. Codec modules are the only thing to be careful with, and both
codec2 and ilbc are fine.

Thanks for the contributions - and please keep them coming!

Matt

-- 
Matthew Jordan
Digium, Inc. | Director of Technology
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] SIP channel X Local Channel

[Matthew Jordan]

On Tue, Dec 1, 2015 at 3:00 PM, Gabriel Ortiz Lour <ortiz.ad...@gmail.com>
wrote:

>
> Hi all,
>
>   Having trouble with understanding how chan_sip relates with chan_local.
> I know I'm using a very old asterisk version (1.8.19.0) but here is what
> I'm trying to do:
>
>   I'm using "use_q850_reason" to transport de HANGUPCAUSE from one * box
> to another, as I can see in the 2nd * log:
>
> ">> Using Reason header for cause code: 50"
>
> This number (50) came from the HANGUPCAUSE i've set on the 1st * box.
>
> The thing is that I used the AMI to generate a call using a Local channel,
> and I would like to receive that number in the "Reason" field of the
> OriginateResponse, so I would know the HANGUPCAUSE of the 1st * box.
>
> The problem is that the SIP channel in the case is never answered, I'm
> fighting with the code on chan_sip function "handle_response" and in the
> channel.c "__ast_request_and_dial", but I can't find where the two channels
> relate, where to get the "50" that I need...!
>
> Anyone could help me with some pointers on that?
>
>
You can't reach across channels from one channel driver to another in any
kind of safe fashion. That is, code in chan_sip cannot call or set code in
chan_local directly.

If one channel needs to inform another channel about some piece of
information, then it needs to do so using one of the built-in mechanisms
that pass information between channels. In your version, you're best off
modifying the control frame AST_CONTROL_HANGUP to pass the chan_sip
specific Reason code along with it. You'd do something like the following:
* Update ast_queue_hangup_with_cause to have a new reason parameter set by
chan_sip, and pass not just the hangup cause code but also the reason code
along with it. That would make f.data point to a structure containing both
cause codes, and have the datalen value be set in the frame to the size of
the struct.
* Update everyone who handles AST_CONTROL_HANGUP and extracts the cause
code out of it to get it from the new structure
* Update the origination routines to extract the Reason code out of its
handling of AST_CONTROL_HANGUP

That's probably your best path, anyway. It's important to note that another
way of doing this was implemented in Asterisk 11. There's a separate
control frame that handles cause code information that all channel drivers
can use to pass that information along to the core, and potentially further
if desired. That mechanism has a reasonable amount of work associated with
it, so it wouldn't backport well. If, however, Asterisk 11 is an option,
you may want to look into that functionality. The control frame that
handles cause code propagation (which could reasonably be extended for more
information) is AST_CONTROL_PVT_CAUSE_CODE.

-- 
Matthew Jordan
Digium, Inc. | Director of Technology
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
Check us out at: http://digium.com & http://asterisk.org
-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

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

Re: [asterisk-dev] Asterisk Docker Containers: Phase 1

[Matthew Jordan]

> On Mon, Nov 16, 2015 at 4:31 PM, Steve Edwards <asterisk@sedwards.com>
> wrote:
>
>> On Mon, Nov 16, 2015 at 4:31 PM, Steve Edwards <asterisk@sedwards.com>
>>> wrote:
>>> >
>>> > On Mon, 16 Nov 2015, Leif Madsen wrote:
>>> >
>>> >> I wrote up a lengthy blog post that likely borders on ranting:
>>> >>
>>> >>
>>> http://blog.leifmadsen.com/blog/2015/11/10/asterisk-docker-container-phase-1/
>>> >
>>> >
>>>
>>
Great blog post :-)

Would it be appropriate to summarize the current state of things as "we
need a spec file for Asterisk"?



> > I've only read the first x paragraphs (I'll read more later), and I hope
>>> I'm not flying off the handle.
>>> >
>>> > I used to make source level changes for some of my projects.
>>> Fortunately, all the functionality I now need is provided by the RPMs.
>>> >
>>> > All of my current clients are 'from packages' and I'd hate for the
>>> results of the referenced poll to lead to the demise of the packages.
>>>
>>
>> On Mon, 16 Nov 2015, Leif Madsen wrote:
>>
>> I'm not sure what "demise" you're talking about.
>>>
>>
>> This is why I prefaced my post with 'I hope I'm not flying off the
>> handle.'
>>
>> The potential 'demise' I referred to would be for someone to read your
>> post and apply the results from a single poll with a specific demographic
>> to the general demographic.
>>
>> There is also no "poll" going on...
>>>
>>
>> 'Referenced' is past tense -- referring to the poll you referenced.
>>
>> Nothing that I'm doing will stop people from building packages, so I'm
>>> really confused by your statement.
>>>
>>
>> I get that containers do not preclude people from building packages. I
>> was not commenting on your work, only on the statement 'no one really uses
>> packages.'
>>
>> Not one thing I am proposing will change your workflow.
>>>
>>
>> I look forward to reading your post in depth when I have the time.
>>
>> Sorry for the kerfuffle.
>> <http://lists.digium.com/mailman/listinfo/asterisk-dev>
>>
>
Just to address Steve's point:

Packages aren't going anywhere. I do think we can all agree that the state
of Asterisk packaging could use some improvement, but that's a separate
discussion.

Docker is another way to deploy Asterisk, that may or may not use packages.
(And as Chad pointed out, we're using Docker here at Digium for that
purpose.) As Leif mentioned in his blog post, there's definitely benefits
to using packages with Docker, as it reduces the size of the Docker images.
If the goal is to have a universally accepted Docker file for the Asterisk
project, then it probably make sense to use packages; that would
necessitate either having dependable packages for a variety of distros, or
include a .spec file with the project.

Leif: Does that sound correct?

Matt

-- 
Matthew Jordan
Digium, Inc. | Director of Technology
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] Bug marshals back !

[Matthew Jordan]

On Wed, Nov 18, 2015 at 6:58 AM, Olle E. Johansson <o...@edvina.net> wrote:

> Yay!
>
> I notice in a bug report that the response talks about  a Bug Marshal. I
> am very happy that we have bug marshals back in the process. Is there a
> document somewhere outlining the process of becoming one and what they do
> nowadays?
>
> Cheers,
> /O
>
>
Hey Olle!

I don't think the term bug marshal ever went away. If that was unclear,
then I'm sorry about that. As long as I've been around, there's always been
special settings set up for JIRA users who are in the "Asterisk Developers"
group (such as the ability to see reported security vulnerabilities, etc.).
People who generally help solve problems in JIRA are always put in that
group.

The Asterisk wiki documents what a Bug Marshal does in the Issue Tracker
Workflow page:

https://wiki.asterisk.org/wiki/display/AST/Issue+Tracker+Workflow

Additional guidelines for what constitutes a "good" bug report can be found
on the Asterisk Issue Guidelines page (which is linked from the previously
mentioned page as well):

https://wiki.asterisk.org/wiki/display/AST/Asterisk+Issue+Guidelines

Let me know if there's anything you think might be missing on those wiki
pages - we're always trying to improve the documentation of the project!

Thanks -

Matt

-- 
Matthew Jordan
Digium, Inc. | Director of Technology
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
Check us out at: http://digium.com & http://asterisk.org
-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

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

Re: [asterisk-dev] Asterisk 1.8 deadlock with Kernel 4.1

[Matthew Jordan]

On Wed, Nov 18, 2015 at 12:37 PM, Stefan Priebe <s.pri...@profihost.ag>
wrote:

> Hello,
>
> since Upgrading our Asterisk System from Kernel 3.18.17 to 4.1.13 it
> deadlocks every few hours (kill -9 is the only thing working). Booting
> with 3.18 again let it run smooth again.
>
> I've now also two gdb backtraces from two crashes:
> http://pastebin.com/raw.php?i=yih5jNt8
>
> http://pastebin.com/raw.php?i=kGEcvH4T
>
> The kernel guys forwarded me to asterisk to find out where it hangs.
>
>
Your pastebin links don't appear to be working.

Please either attach the backtraces, or send them along in the text of the
e-mail. (Plus, that way we'll have them for posterity.)

-- 
Matthew Jordan
Digium, Inc. | Director of Technology
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
Check us out at: http://digium.com & http://asterisk.org
-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

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

Re: [asterisk-dev] Asterisk 1.8 deadlock with Kernel 4.1

[Matthew Jordan]

On Wed, Nov 18, 2015 at 2:01 PM, Stefan Priebe <s.pri...@profihost.ag>
wrote:

> Am 18.11.2015 um 19:46 schrieb Matthew Jordan:
>
>>
>>
>> On Wed, Nov 18, 2015 at 12:37 PM, Stefan Priebe <s.pri...@profihost.ag
>> <mailto:s.pri...@profihost.ag>> wrote:
>>
>> Hello,
>>
>> since Upgrading our Asterisk System from Kernel 3.18.17 to 4.1.13 it
>> deadlocks every few hours (kill -9 is the only thing working). Booting
>> with 3.18 again let it run smooth again.
>>
>> I've now also two gdb backtraces from two crashes:
>> http://pastebin.com/raw.php?i=yih5jNt8
>>
>> http://pastebin.com/raw.php?i=kGEcvH4T
>>
>> The kernel guys forwarded me to asterisk to find out where it hangs.
>>
>>
>> Your pastebin links don't appear to be working.
>>
>
> Pastebin is down for raw links. It's up for the normal links.
>
> http://pastebin.com/yih5jNt8
> and
> http://pastebin.com/kGEcvH4T
>
>
>> Please either attach the backtraces, or send them along in the text of
>> the e-mail. (Plus, that way we'll have them for posterity.)
>>
>
> Sure here it comes:
> Thread 35 (Thread 0x7f295e945700 (LWP 26637)):
> #0  pthread_cond_wait@@GLIBC_2.3.2 () at
> ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:162
> #1  0x004e51ad in __ast_cond_wait (filename=0x5d3c04
> "taskprocessor.c", lineno=310,
> func=0x5d4320 "tps_processing_function", cond_name=0x5d3f71
> ">poll_cond", mutex_name=0x5d3f5a ">taskprocessor_lock",
> cond=0x19e9ad0, t=0x19e9b08) at lock.c:565
> #2  0x00555e9a in tps_processing_function (data=0x19e9ac8) at
> taskprocessor.c:310
> #3  0x00569280 in dummy_start (data=0x19eb300) at utils.c:1173
> #4  0x7f295d5dcb50 in start_thread (arg=) at
> pthread_create.c:304
> #5  0x7f295de3195d in clone () at
> ../sysdeps/unix/sysv/linux/x86_64/clone.S:112
> #6  0x in ?? ()
>
> Thread 34 (Thread 0x7f295e8c9700 (LWP 26638)):
> #0  0x7f295de26d13 in *__GI___poll (fds=,
> nfds=, timeout=-1)
> at ../sysdeps/unix/sysv/linux/poll.c:87
> #1  0x0043e5e4 in listener (unused=0x0) at asterisk.c:1393
> #2  0x00569280 in dummy_start (data=0x19ec150) at utils.c:1173
> #3  0x7f295d5dcb50 in start_thread (arg=) at
> pthread_create.c:304
> #4  0x7f295de3195d in clone () at
> ../sysdeps/unix/sysv/linux/x86_64/clone.S:112
> #5  0x in ?? ()
>
> Thread 33 (Thread 0x7f295e84d700 (LWP 26639)):
> #0  pthread_cond_wait@@GLIBC_2.3.2 () at
> ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:162
> #1  0x004e51ad in __ast_cond_wait (filename=0x5bcdf4 "logger.c",
> lineno=1072, func=0x5bdc02 "logger_thread",
> cond_name=0x5bd8ae "", mutex_name=0x5bd8a0 "",
> cond=0x826b80, t=0x80e550) at lock.c:565
> #2  0x004ea0fa in logger_thread (data=0x0) at logger.c:1072
> #3  0x00569280 in dummy_start (data=0x19ec1c0) at utils.c:1173
> #4  0x7f295d5dcb50 in start_thread (arg=) at
> pthread_create.c:304
> #5  0x7f295de3195d in clone () at
> ../sysdeps/unix/sysv/linux/x86_64/clone.S:112
> #6  0x in ?? ()
>
> Thread 32 (Thread 0x7f295c08d700 (LWP 26653)):
> #0  pthread_cond_wait@@GLIBC_2.3.2 () at
> ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:162
> #1  0x004e51ad in __ast_cond_wait (filename=0x5ae3d4
> "devicestate.c", lineno=549, func=0x5aeb10 "do_devstate_changes",
> cond_name=0x5ae687 "_pending", mutex_name=0x5ae697
> "_changes.lock", cond=0x825ea0, t=0x80b4f0) at lock.c:565
> #2  0x004a0764 in do_devstate_changes (data=0x0) at
> devicestate.c:549
> #3  0x00569280 in dummy_start (data=0x1ed7b90) at utils.c:1173
> #4  0x7f295d5dcb50 in start_thread (arg=) at
> pthread_create.c:304
> #5  0x7f295de3195d in clone () at
> ../sysdeps/unix/sysv/linux/x86_64/clone.S:112
> #6  0x in ?? ()
>
> Thread 31 (Thread 0x7f295c011700 (LWP 26654)):
> #0  0x7f295de3287d in recvmsg () at
> ../sysdeps/unix/syscall-template.S:82
> #1  0x7f295de52fcc in make_request (fd=35, pid=26631,
> seen_ipv4=, seen_ipv6=,
> in6ai=, in6ailen=) at
> ../sysdeps/unix/sysv/linux/check_pf.c:119
> #2  0x7f295de5344a in __check_pf (seen_ipv4=0x7f295c00e85f,
> seen_ipv6=0x7f295c00e85e, in6ai=0x7f295c00e840,
> in6ailen=0x7f295c00e838) at ../sysdeps/unix/sysv/linux/check_pf.c:271
> #3  0x7f295de10007 in *__GI_getaddrinfo (name=0x7f295c00e8b0
> "10.12.12.55", service=0x7f295c00e8bc "2

Re: [asterisk-dev] Lockups in Asterisk 11

[Matthew Jordan]

do
 0xb6190440 (1)
main/logger.c:1702 ast_bt_get_addresses() (0x813f3a6+19)
main/lock.c:258 __ast_pthread_mutex_lock() (0x8138607+85)
channels/chan_sip.c:28926 handle_request_do()
channels/chan_sip.c:3045 _sip_tcp_helper_thread()
channels/chan_sip.c:2572 sip_tcp_worker_fn()
main/tcptls.c:694 handle_tcptls_connection()
main/utils.c:1223 dummy_start()
:0 start_thread()
libc.so.6 clone() (0xb76e60d0+5E)
=== --- ---> Locked Here: chan_sip.c line 28923 (handle_request_do)
=== ---
===
===

And this shows that the TCP/TLS thread is waiting on a lock held by the
monitor thread; most likely, this is the SIP pvt lock currently held by the
thread.

Things to investigate:
(1) Get a gdb backtrace when this occurs, so you can find out exactly what
the AstDB synchronization thread is doing that is blocking for a long
period of time.
(2) Find out *exactly* what is occurring on your system. If the AstDB
synchronization thread is taking a noticeable amount of time to do work,
you almost certainly have either a problem in your AstDB; have other I/O
problems on the system; or have something occurring here that is outside
the control of Asterisk.

Either way, nothing above makes me think there is a bug in Asterisk.

-- 
Matthew Jordan
Digium, Inc. | Director of Technology
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
Check us out at: http://digium.com & http://asterisk.org
-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

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

Re: [asterisk-dev] Asterisk-11 Trying to get Channel Name related to RTP/SIP Private

[Matthew Jordan]

On Fri, Oct 30, 2015 at 11:46 AM, Mark Murawski <markm-li...@intellasoft.net
> wrote:

> Howdy All,
>
> I'm working on trying to output the channel related to an rtp stream.  I
> found this line in ast_rtp_read()/res_rtp_asterisk.c and this pointed me to
> a starting position:
>
> ast_verb(4, "%p -- Probation passed - setting RTP source address to %s\n",
> rtp, ast_sockaddr_stringify())
>
> I figured to tried this:
> {
>   struct ast_channel *chan = ast_rtp_instance_get_chan(instance);
>   ast_verb(4, "<%s> %p -- Probation passed - setting RTP source address to
> %s\n", chan ? ast_channel_name(chan) : "NoChannel", rtp,
> ast_sockaddr_stringify());
> }
>
> Sometimes this works, and sometimes this doesn't and I'm not sure why.
>
> If media is setup "slowly", i'll get this:
> > [2015-10-30 10:58:04.855] > [C-]  0xb4a94618 --
> Probation passed - setting RTP source address to 192.168.5.125:
>
> It appears that if the media is setup "fast" I'll get this output:
>> [2015-10-30 10:28:54.846]> [C-000a]
>  0x89ffda8 -- Probation passed - setting RTP source
> address to 192.168.5.123:2224
>> [2015-10-30 10:28:54.846]> [C-000a]
>  0x89ec480 -- Probation passed - setting RTP source
> address to 192.168.5.129:2250
>
> How can I reliably get the channel name here (or pick a better spot to get
> the channel name related to rtp ports)?
>

First, you could just upgrade to 13, which has this feature already.

If that's not an option, then you have to do something along the following
lines:

(1) Inject the channel name into the RTP engine/instance when the RTP
instance is first created. It generally isn't safe or reliable to go the
other direction. While packet to packet bridging does that, it does so in a
very particular way, that I would not recommend doing in Asterisk 11 on
every RTCP read (or at other times).

(2) Whenever a masquerade occurs, where the SIP pvt gets moved from one
channel to another, re-update the RTP instance with the new channel name.
Note: this is why you should just move to Asterisk 13, as a masquerade
generally does not occur where the new channel owning the SIP pvt is
expected to survive for long. (There are exceptions, but FAR fewer than
what you'll find in Asterisk 11.)

Any other approach is liable to not work. You may want to look at the
original patch Jaco Kroon had for this feature on the issue tracker:

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

If you read the comments however, you'll note again why you should just do
this in Asterisk 13+, as you're liable to run into a lot of corner cases
where the channel is not around when you think it should be in 11.

-- 
Matthew Jordan
Digium, Inc. | Director of Technology
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] PJSIP realtime scalability problem

[Matthew Jordan]

((object = ao2_t_iterator_next(, "iterate thru endpoints table")))
>> {
>
>> const char *id = formatter_entry->get_id(object);
>
>> if (!strncasecmp(word, id, wordlen)
>
>> && ++which > state) {
>
>> result = ast_strdup(id);
>
>> }
>
>> ao2_t_ref(object, -1, "toss iterator endpoint ptr before break");
>
>> if (result) {
>
>> break;
>
>> }
>
>> }
>
>>
>
>> Since the endpoint formatter_entry only has a 'get by id' callback:
>
>>
>
>> static void *cli_endpoint_retrieve_by_id(const char *id)
>
>> {
>
>> return ast_sorcery_retrieve_by_id(ast_sip_get_sorcery(), "endpoint", id);
>
>> }
>
>>
>
>> That means that for every partial match that you have on an endpoint,
>
>> we do a separate lookup.
>
>>
>
>> Alternatively, we could go pull a partial match in a single query,
>
>> than iterate over the returned set of matches. Clearly that would be a
>
>> lot better in this case.
>
>>
>
>> >
>
>> > Why would asterisk need to load the whole list of endpoints more than
>> > 300
>
>> > times is just completely beyond me.
>
>> >
>
>>
>
>> Hyperbole aside, it's because PJSIP chose a sane, maintainable method
>
>> to interact with its storage backends and uses a data abstraction
>
>> layer above its SQL statements - unlike chan_sip, which just embeds
>
>> the statements willy-nilly in the codebase. The downside of this is
>
>> that sometimes - in some specific cases - we aren't as efficient as we
>
>> should be.
>
>>
>
>> That's fixable however. Please do file a specific issue for the tab
>
>> completion case, as that should be improved.
>
>
>
> First of all, again, I'd prefer that completion to be performed not against
> all the endpoints
>
> in db, but only those loaded and cached.
>
> Second, my test environment doesn't have 10K of endpoints, but only
> currently 173.
>
> I imagine that if I did it against all 10K endpoints it would never finish.
>
> Sure I'll open an issue for that.
>

Thanks!

>
>> >
>

If I boil your issues down, it sounds like the problems are mostly around:
(1) CLI commands (or AMI actions, for that matter) that attempt to
operate on all endpoints. Generally, options that accessed only the
subset of the endpoints that were present in the cache would be
desirable.
(2) Initial loading of endpoints can take awhile and present a lot of
contention on the database.

Does that sound right?

Matt

-- 
Matthew Jordan
Digium, Inc. | Director of Technology
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] PJSIP realtime scalability problem

[Matthew Jordan]

On Sat, Oct 17, 2015 at 10:03 AM, Michael Ulitskiy  wrote:
> Matthew,
>
>
>
> Thanks for the reply.
>
> Yes I do have caching enabled. While caching does somewhat help (there are
> different problems there)

Which problems?

> with ongoing load it has nothing to do with initial load that is still done
> in the extremely inefficient way
>
> I described in my original email.

I'm not sure why that would be the case. You'll need to be more
specific, and provide your sorcery.conf configuration as well as the
specific operations/times when there are issues.

> Caching also doesn't help at all with CLI commands like "pjsip show
> endpoints" in which case asterisk
>
> reloads the whole list from db instead of showing what it has in-memory.

That actually is by design.

Say we are caching endpoints. The cache only contains the n most
recently requested endpoints, *not* every endpoint that you may have
in your system. Hence, if you ask for all endpoints, we have to bypass
the cache and get all endpoints in order to accurately fulfill the
request.

Given that this is a human interaction and not a run-time machine
interaction, the fact that you're requesting all endpoints results in
going out to the database is not unreasonable.

> Also I've noticed another very awkward problem. If I type "pjsip show
> endpoint" in the console and then
>
> press "Tab" then asterisk hangs for over a minute and I register over 300
> queries like this in the db log:

So, first, you are asking for name completion against 10k endpoints.
Regardless of the number of database queries, that's a large set to
complete against. Granted, there's no reason to go get the dataset on
every single entry...

>
>
> SELECT * FROM pjsip_endpoints_v WHERE id LIKE '%' ORDER BY id
>

... which does appear as if that is what we are doing. In pjsip_cli:

while ((object = ao2_t_iterator_next(, "iterate thru endpoints table"))) {
const char *id = formatter_entry->get_id(object);
if (!strncasecmp(word, id, wordlen)
&& ++which > state) {
result = ast_strdup(id);
}
ao2_t_ref(object, -1, "toss iterator endpoint ptr before break");
if (result) {
break;
}
}

Since the endpoint formatter_entry only has a 'get by id' callback:

static void *cli_endpoint_retrieve_by_id(const char *id)
{
return ast_sorcery_retrieve_by_id(ast_sip_get_sorcery(), "endpoint", id);
}

That means that for every partial match that you have on an endpoint,
we do a separate lookup.

Alternatively, we could go pull a partial match in a single query,
than iterate over the returned set of matches. Clearly that would be a
lot better in this case.

>
> Why would asterisk need to load the whole list of endpoints more than 300
> times is just completely beyond me.
>

Hyperbole aside, it's because PJSIP chose a sane, maintainable method
to interact with its storage backends and uses a data abstraction
layer above its SQL statements - unlike chan_sip, which just embeds
the statements willy-nilly in the codebase. The downside of this is
that sometimes - in some specific cases - we aren't as efficient as we
should be.

That's fixable however. Please do file a specific issue for the tab
completion case, as that should be improved.

>
> For a long time it was my understanding that "dynamic realtime" means
> loading data from db on demand.
>
> What pjsip does now is not a dynamic realtime. What it does seems like the
> mix of both worlds: static realtime in the beginning -
>
> loading everything from db and dynamic afterwords - issuing queries whenever
> it needs endpoint data (caching helps here).
>
>
>
> Unless I'm missing something and there's a another/better way to use it, I
> think pjsip realtime is not usable now
>
> at any scale other than very trivial one.
>

Please leave hyperbole at the door. If you'd like help narrowing down
the specific cases that are causing issues, that'd be great. We'd love
to help. "I think this sucks" isn't helpful.

Right now, you've pointed out one specific case that clearly needs
improvement. Please provide specific evidence for each case that
you're running into, when caching is enabled, where a run-time
operation is substantially less efficient than it should be.

And remember: this is an open source project. If you'd like to help
fix things, that's always appreciated.

Matt

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

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

Re: [asterisk-dev] contrib/realtime sources

[Matthew Jordan]

On Thu, Oct 15, 2015 at 12:16 PM, James Cloos <cl...@jhcloos.com> wrote:
>>>>>> "JC" == Joshua Colp <jc...@digium.com> writes:
>
> JC> That's correct, they are produced as part of the release process
> JC> itself and not kept under version control. What produces the schemas
> JC> is alembic. Alembic can also be used directly against a database.
>
> Apologies for not completing my thought.
>
> I meant to add: [Given all of that,] where is the code which uses
> alembic to generate the sql files during the release process?
>
> I don't see any explicit calls when running git grep alembic.  And th
> wiki page ignores anything other than using alembic to access a db
> directly.
>
> Thanks,
>
> -JimC
> --

Hi James:

All of the release scripts are in the repotools repository [1]. The
one you're looking for specifically is alembic_creator.py [2], which
is invoked by mkrelease.py [3].

Note that the repotools project is also an open source project, so if
you see something in there that you'd like to propose for a change,
patches are always welcome on Gerrit!

Matt

[1] http://git.asterisk.org/gitweb/?p=asterisk/repotools.git;a=tree
[2] 
http://git.asterisk.org/gitweb/?p=asterisk/repotools.git;a=blob;f=alembic_creator.py;hb=HEAD
[3] 
http://git.asterisk.org/gitweb/?p=asterisk/repotools.git;a=blob;f=mkrelease.py;hb=HEAD

-- 
Matthew Jordan
Digium, Inc. | Director of Technology
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] PJSIP realtime scalability problem

[Matthew Jordan]

On Thu, Oct 15, 2015 at 10:58 AM, Michael Ulitskiy <mulits...@acedsl.com> wrote:
> Hello,
>
>
>
> I have a system consisting of OpenSIPS proxy, working as registrar and
> outbound proxy for subscribers and multiple
>
> asterisk systems behind it providing all kind of media services to
> subscribers. OpenSIPS proxy dynamically assigns
>
> which asterisk a particular endpoint should be served at and then forwards
> all messages from that endpoint to the
>
> selected asterisk server. Since this is dynamic process there's no
> predefined list of endpoints assigned to each asterisk server.
>
> Each asterisk server must be prepared to handle requests from any endpoint.
>
> Currently I'm using chan_sip with dynamic realtime and it works well.
> Whenever a request arrives to an asterisk it retrieves that
>
> endpoint (peer) from db and caches it. chan_sip never attempts to retrieve
> the whole list of endpoints.
>
>
>
> Now I'm considering migrating to chan_pjsip and immediately I encountered a
> problem. Unlike chan_sip, pjsip is retrieving
>
> the whole list of subscribers multiple times during initial load. Then it
> does it again every time you issue "pjsip list/show endpoints/aors"
>
> CLI commands. Even worse (much worse), after initial load of AORs and
> endpoints with the queries that looks like this:
>
>
>
> SELECT * FROM pjsip_aors_v WHERE id LIKE '%' ORDER BY id
>
> SELECT * FROM pjsip_endpoints_v WHERE id LIKE '%' ORDER BY id
>
>
>
> it follows on with loading every AOR individually with queries like this:
>
>
>
> SELECT * FROM pjsip_aors_v WHERE id = 'ep1'
>
> SELECT * FROM pjsip_aors_v WHERE id = 'ep2'
>
> ...
>
> SELECT * FROM pjsip_aors_v WHERE id = 'epN'
>
>
>
> Then it goes on with loading every endpoint individually with queries like
> this:
>
>
>
> SELECT * FROM pjsip_endpoints_v WHERE id = 'ep1'
>
> SELECT * FROM pjsip_endpoints_v WHERE id = 'ep2'
>
> ...
>
> SELECT * FROM pjsip_endpoints_v WHERE id = 'epN'
>
>
>
> I currently have around 10K of endpoints and it's completely unacceptable
> even at my scale and I'm sure there are much
>
> bigger installations out there.
>
>
>
> I asked this question on asterisk-users already
> (http://lists.digium.com/pipermail/asterisk-users/2015-October/287742.html)
>
> and was told by Joshua Colp that this is how things stands now and it works
> as intended.
>
>
>
> So I would like to ask developers if there are any plans to address it and
> make it behave more like chan_sip does. If no
>
> I'd like to know how developers suggest the installations with larger number
> of endpoints to handle this. I'm open to any
>
> suggestions. Right now it looks like show-stopper to me.
>

Hi Michael:

Have you tried sorcery caching yet?

https://wiki.asterisk.org/wiki/display/AST/Sorcery+Caching

It is new in 13.5.0, and was designed explicitly for this kind of
scenario. It probably didn't exist when Josh answered you on the
-users list, but I would take a look at putting a cache in
sorcery.conf for your PJSIP endpoints.

Matt

-- 
Matthew Jordan
Digium, Inc. | Director of Technology
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] SIP/SDP: ptime in translation module?

[Matthew Jordan]

n.
(2) It goes against the contract ast_format tries hard to enforce.
You'll either kill performance by requiring a large amount of new
ast_format structures when you don't want them, or you'll cause major
threading issues. Either channels will be running with a packetization
they didn't want, or you may just crash. Or both.

If setting it on the ast_frame doesn't work - and that's fair - and
packetization is a media session attribute - why not just store it on
the ast_translator on the channel? Frankly, it is the closest to
something keeping track of the state of the media session that I can
think of, and that's really where packetization should probably go.

-- 
Matthew Jordan
Digium, Inc. | Director of Technology
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] Discovering Asterisk with consul

[Matthew Jordan]

On Fri, Oct 9, 2015 at 6:57 AM, Sylvain Boily <sbo...@avencall.com> wrote:
> Hello,
>
> Le 2015-10-04 22:09, Matthew Jordan a écrit :
>>
>> On Thu, Oct 1, 2015 at 4:11 PM, Sylvain Boily <sbo...@avencall.com> wrote:
>>>
>>> Hello,
>>>
>>> I developped a small module to plug asterisk with consul. Also i wrote
>>> small
>>> documentation, a dockerfile and a docker-compose yaml to play with it
>>> easily.
>>>
>>> code source is here : https://github.com/sboily/asterisk-consul-module
>>>
>>> My example is only to loadbalance ARI, auto discovery service and
>>> autoscaling, but you can imagine what you want. I'm using consul-template
>>> to
>>> generate the config for haproxy. You can imagine to loadbalance asterisk
>>> sip
>>> with kamailio automatically if you want.
>>>
>>> This email is only to sharing my idea with the community ;-)
>>> Good and bad feedback is welcome.
>>>
>> I like the idea for sure, and think it would be a pretty cool
>> addition. If you'd like to push the module up for review, I think
>> that'd be pretty great - there's a few minor coding guideline [1]
>> things you might want to take a look at first, but nothing too major.
>
>
> I did review with my colleague Etienne Lessard, and we follow your
> guidelines. I think it's better ;-)
>
>>
>> If you'd like to get it into Asterisk 13 as well as master (which will
>> eventually be 14), we can talk about writing automated tests :-)
>
>
> There is automated test now.
>

Awesome!

We should talk about ways to coordinate the automated testing efforts.
Probably something to discuss at DevCon, wince we'll all be in a room
together next week.

-- 
Matthew Jordan
Digium, Inc. | Director of Technology
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
Check us out at: http://digium.com & http://asterisk.org

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

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

Re: [asterisk-dev] Asterisk 13.6.0-rc2 Possible CDR Bug

[Matthew Jordan]

On Wed, Oct 7, 2015 at 2:06 PM, Ross Beer <ross.b...@outlook.com> wrote:
> Hi,
>
> I am having an issue setting custom variables in a CDR record for a call
> once it has hung up. Setting variables before a dial are inserted into the
> CDR correctly. I am using the following hangup_handler as per previous
> versions:
>
> [record-hangupcause]
>
> exten => s,1,Set(CDR(hangupcause)=${HANGUPCAUSE})
> exten => s,n,Return()
>
>
> Before the dial a hangup handler is registered:
>
> Set(CHANNEL(hangup_handler_push)=record-hangupcause,s,1)
>
>
> The routine is called and the variables are being set, however not on the
> channel's CDR which made the call.
>
> By changing the cdr option 'endbeforehexten=no' this should keep the CDR
> accessible, however all this does is cause another CDR to be created for the
> 'h' extension.
>
> Is there currently a bug with accessing CDR data for a channel that has been
> hung-up? It looks to me that the CDR is closed before the hangup_handler is
> called. However this shouldn't be the case!
> I would be grateful for any feedback you can offer!
>
> I am happy to open a bug report, but I would prefer to have this
> acknowledged before doing so.
> Ross
>

Hey Ross -

Sorry I didn't reply sooner.

The short answer is that it is working as designed; the long answer is
that I think the design is wrong. (As the guy responsible, I feel like
I'm only throwing stones at myself.)

Keeping a single CDR running after channels have left a bridge was one
of those things that was relatively "easy" in 11 and earlier versions,
and is a bit more challenging in 13. I think in this case that we
probably should revisit the rules around it.

I do know this has come up a few times on the mailing lists, but I
don't think anyone has made an issue yet. Please do made one,
referencing this discussion.

Just to summarize what I think should happen:

endbeforehexten=no should cause no new CDR to be created in the 'h'
extension, and the 'end' time on the CDR should not be set. The CDR
should allow manipulation of its properties via the CDR function.

Does that sound right?

-- 
Matthew Jordan
Digium, Inc. | Director of Technology
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] SIP/SDP: ptime in translation module?

[Matthew Jordan]

On Fri, Oct 2, 2015 at 2:13 PM, Alexander Traud
<pabstr...@compuserve.com> wrote:
> I am creating a translation module for AMR-WB. In one scenario on the
> SIP/SDP layer, a higher ptime was negotiated than the default one. For
> example, 60ms were negotiated instead of the AMR default 20ms. Now, Asterisk
> should send three frames per RTP packet. I try to play one of the recorded
> voices (slin8). Asterisk sends 320 samples to my translation module; the
> default for 20ms packetization. My translation module has to wait 960
> samples to create the frames.
>
> Which structure do I have to query: How do know the ptime, there in such a
> transcoding module? This was available in Asterisk 11 via
> ast_format->cur_ms. How do I access this information in Asterisk 13|master?
>
> I am asking asterisk-dev, because all transcoding modules might be affected.
> At least with AMR-WB, I have to code/build those frames within the module
> because RFC 4867 mandates a special header (section 4.3.5.2 and 4.4.5.1). At
> first glance, this could be an architectural issue. Therefore, I am asking
> for advice how to approach this: Simply, re-adding "cur_ms" to ast_format?
>

I don't think we want to add cur_ms back to ast_format, for two
reasons. The first is simply that packetization is negotiated at the
media level, and applies to all formats negotiated for that media
session. Hence why it was removed from the formats themselves - it
exists at a "higher" level.

Second, formats in 13+ are immutable by convention; this gave Asterisk
a big performance improvement as it didn't have to copy the format
structs all over the place. Unfortunately, that also means you don't
want to change them too often. Generally, once created for a channel,
you don't want to put more information in them or otherwise muck with
them. Modifying a format during negotiation can be done, but there's a
hit you pay for doing it at that point.

Currently, packetization is only stored on the RTP instance, as that
represents the media session that was negotiated along with all
formats in that media session.

If you need to get that information into a codec module, there's a few options:

1) Implement an attribute module for the format, such as
res_format_amr_wb. You can set arbitrary attributes on any given
format, and it will set those attributes in various callbacks into the
module. The callbacks are responsible for creating a new cloned
format, setting attributes on it in some private data structure, and
returning the clone. The format core is smart enough to not impact
"normal" formats using this approach. You can look at the existing
implementations, such as res_format_attr_opus, to get a hint on how to
do that. There are, however, a few issues with this approach:

a) By default, the format attribute modules expect to get their
attributes out of an 'fmtp' line in an SDP. The ptime attribute won't
be passed along with that. That means that you'll have to update
parsers of 'ptime' in the various channel drivers to call
ast_format_attribute_set with the ptime value, and handle the cloned
format appropriately.

b) You'll need to pull the format for the RTP instance's codecs out
using ast_rtp_codecs_get_payload_format, which may be tricky. Another
way of handling this approach would be to implement the call to
ast_format_attribute_set in ast_rtp_codecs_set_framing, as it knows
how to get at the formats stored in the RTP instance.

2) Another option would be to just store the framing on the frame
itself. Frames are not immutable; they are created by the RTP instance
(which has the framing for that instance available on it), and could
easily be set in ast_rtp_read. Since the framing negotiated is not
dependent on the format but on the media session itself, it seems more
appropriate to store it on the frames generated by that media session.
What's nice about this is that codec modules are fed frames already;
that means there's no additional lookups you'll have to do in your
codec module.

Of the two approaches I like #2 best, but some others may want to
chime in on this as well.

Matt

-- 
Matthew Jordan
Digium, Inc. | Director of Technology
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] Discovering Asterisk with consul

[Matthew Jordan]

On Thu, Oct 1, 2015 at 4:11 PM, Sylvain Boily <sbo...@avencall.com> wrote:
> Hello,
>
> I developped a small module to plug asterisk with consul. Also i wrote small
> documentation, a dockerfile and a docker-compose yaml to play with it
> easily.
>
> code source is here : https://github.com/sboily/asterisk-consul-module
>
> My example is only to loadbalance ARI, auto discovery service and
> autoscaling, but you can imagine what you want. I'm using consul-template to
> generate the config for haproxy. You can imagine to loadbalance asterisk sip
> with kamailio automatically if you want.
>
> This email is only to sharing my idea with the community ;-)
> Good and bad feedback is welcome.
>

I like the idea for sure, and think it would be a pretty cool
addition. If you'd like to push the module up for review, I think
that'd be pretty great - there's a few minor coding guideline [1]
things you might want to take a look at first, but nothing too major.

If you'd like to get it into Asterisk 13 as well as master (which will
eventually be 14), we can talk about writing automated tests :-)

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

-- 
Matthew Jordan
Digium, Inc. | Director of Technology
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
Check us out at: http://digium.com & http://asterisk.org

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

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

Re: [asterisk-dev] Asterisk + WebRTC: No audio on any direction

[Matthew Jordan]

On Fri, Sep 4, 2015 at 7:51 PM,  <asandoval...@gmail.com> wrote:
> Hello everyone. I'd appreciate a lot your help with this issue. I'm running
> a very basic script of JS for subscribing my jsSIP User Agent to my local
> Asterisk server and making a voice call. I don't get any warnings or errors
> from the Asterisk CLI, but when I make a call to a legacy SIP phone or SIP
> trunk well configured, there is no audio on any side although there is
> ringing, calls can be answered and they never drop.
>
> The IP address of the SIP messages is correct both in the header of the
> message and in the RTP description, and it succeeds with sending ICE
> candidates. My Asterisk 12 was compiled with SRTP and pjproject. I don't get
> any error or warning messages on Asterisk, and I suppose that the SIP
> messages are ok.
>
> I read at the Asterisk WebRTC Wiki
> (https://wiki.asterisk.org/wiki/display/AST/Asterisk+WebRTC+Support) this:
> "Starting with Asterisk 12 you need to have pjproject libraries installed,
> otherwise you most likely won't have audio in your WebRTC calls and no
> warning whatsoever!"
> I properly installed it and selected it for the Asterisk compilation, but I
> wonder wether I did it wrong, and how can I check it ...
>
> These are my files:
>
> http.conf
> [general]
> enabled=yes;
> bindaddr=0.0.0.0;
> bindport=8088;
> prefix=asterisk;
> tlsenable=yes;
> tlsbindaddr=0.0.0.0:8089;
> tlscertfile=/etc/asterisk/keys/asterisk.pem;
> tlsprivatekey=/etc/asterisk/keys/asterisk.pem;
>
> rtp.conf
> [general]
> rtpstart=1;
> rtpend=2;
> icesupport=true;
> stunaddr=stun.l.google.com:19302;
>
> sip.conf
> [general]
> context=toSipTrunk
> allow=ulaw
> allow=alaw
> allow=gsm
>
> [1000] ;legacy softphone (zoiper)
> secret=**
> type=friend
> host=dynamic
> dtmfmode=rfc2833
> disallow=all
> allow=ulaw
> allow=alaw
> context=myContext
>
> [1001] ;jsSIP User Agent
> type=friend
> username=1001
> host=dynamic
> secret=**
> encryption=yes
> avpf=yes
> icesupport=yes
> directmedia=no
> transport=udp,ws
> force_avp=yes
> dtlsenable=yes
> dtlsverify=no
> disallow=all
> allow=ilbc
> allow=g729
> allow=gsm
> allow=g723
> allow=ulaw
> dtlscertfile=/etc/asterisk/keys/asterisk.pem
> dtlsprivatekey=/etc/asterisk/keys/asterisk.pem
> dtlssetup=actpass
> context=myContext
>
> ... Thanks in advance

The asterisk-dev mailing list is for discussions regarding the actual
source code of Asterisk. Please use the asterisk-users mailing list
[1] for deployment, setup, troubleshooting, and other related
questions.

[1] http://lists.digium.com/mailman/listinfo/asterisk-users

-- 
Matthew Jordan
Digium, Inc. | Director of Technology
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] New Features Coming in 13.5.0

[Matthew Jordan]

 ==

While Push Configuration is nice, it is only applicable to Sorcery managed
configuration. Manipulating modules - load, reload, unload - is a very
common operation. Those operations are now supported natively in ARI as
well. As an example, to reload chan_sip you would do the following:

curl -X PUT -u asterisk:secret
https://localhost:8088/ari/asterisk/modules/chan_sip

Note that the new module operations were implemented by Benjamin Ford and
Scott Emidy, two co-op students here at Digium, as part of their final
project as co-op students. They planned the project, wrote the Swagger
specification for the new operations, survived withering code reviews,
wrote a bevy of tests to cover the new functionality, tweaked the module
API in Asterisk, and wrote the ARI commands - and did a great job.


== A Few Final New Features ==

In addition to the previously mentioned features, a few other very nice
improvements have been made. These include:
* Addition of the 'rtptimeout' option to the PJSIP stack
* New AMI events for the PJSIP stack that help to inform of lifecycle
changes in Contacts
* Support for ';line' functionality for PJSIP outbound registrations

A huge thank-you to all the contributors for new features in this release,
including George Joseph and Dmitriy Serov.


Note that as with all new features in Asterisk, these features have
automated tests in the Asterisk Test Suite. However, if something did get
missed, please make sure you file an issue and let the developer community
know.

Thanks!

Matt

-- 
Matthew Jordan
Digium, Inc. | Director of Technology
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] R: Using the Call Manager events queue to identify incoming calls (from DAHDI)

[Matthew Jordan]

On Thu, Jul 23, 2015 at 5:19 AM, Domenico DI MIERI tecn...@finsea.net
wrote:

 It could be a solution

 But actually I’ld prefer to understand the sequence of events so that I
 can monitor the activities of some users in the office.



 Thus I’ld need a more complete comprehnsion of the events that asterisk
 generates for different sources and targets:



 Channel Created

 Link

 Canellel destroyed



 …



 Isn’t there something that explains it in details?


For versions of Asterisk prior to Asterisk 12 - no, there is nothing that
explains the full lifetime of a channel in detail.

For versions 12 and forward: yes:
https://wiki.asterisk.org/wiki/display/AST/AMI+v2+Specification

-- 
Matthew Jordan
Digium, Inc. | Director of Technology
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 Snoop

[Matthew Jordan]

On Sun, Jul 19, 2015 at 4:01 PM, Phil Mickelson p...@cbasoftware.com
wrote:

 Thank you for your response.

 Phil Mickelson

 On Sun, Jul 19, 2015 at 4:56 PM, Joshua Colp jc...@digium.com wrote:

 Phil Mickelson wrote:

 Hello,

 I've written a full answering service application with Asterisk at the
 center.  All of my interaction with Asterisk is through ARI.  Thank you
 so much for this feature!  Without it I wouldn't have been able to make
 this work!

 I've just implemented a new Snoop feature.  Without boring you with the
 details (unless you want them) I am able to Snoop on an operator
 regardless of whether or not they are on an active call.  However, the
 only way the Whisper option works is if they are on an actual call.  The
 only difference internally is there are two channels connected through a
 central bridge.  Otherwise, the operator's channel is the only one in
 that bridge.

 Since I can hear the operator regardless of the current call situation
 I'm assuming there must be code in the Snoop option to mute the operator
 if a call is not active?


 There is no code to do that. What whispering does require though (for
 both Chanspy and Snoop channels) is a constant media stream out to the
 channel. It's likely that in the specific scenario there is nothing
 generating a stream and thus nothing to whisper into.

 There's an open issue[1] to remove this requirement but I know of noone
 currently working on it.

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


Well nuts. Looks like my theory wasn't right :-)

I wonder - as a workaround until that issue is addressed, you *may* be able
to force the Whisper by starting Silence on the target channel first:

https://wiki.asterisk.org/wiki/display/AST/Asterisk+13+Channels+REST+API#Asterisk13ChannelsRESTAPI-startSilence

That *should* start silence frames going to the target of the Snoop
channel, at which point, there's at least something flowing through to
allow the audiohook to start sending Whispered audio.

(If I'm wrong, Josh will tell me why :-)

-- 
Matthew Jordan
Digium, Inc. | Director of Technology
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 Snoop

[Matthew Jordan]

On Fri, Jul 17, 2015 at 10:14 AM, Phil Mickelson p...@cbasoftware.com
wrote:

 Hello,

 I've written a full answering service application with Asterisk at the
 center.  All of my interaction with Asterisk is through ARI.  Thank you so
 much for this feature!  Without it I wouldn't have been able to make this
 work!


Thanks! That's really great to hear. A lot of times it's hard to know
whether or not a feature is actually making people's lives easier or better
- it's always nice to know that it's working well!



 I've just implemented a new Snoop feature.  Without boring you with the
 details (unless you want them) I am able to Snoop on an operator regardless
 of whether or not they are on an active call.  However, the only way the
 Whisper option works is if they are on an actual call.  The only difference
 internally is there are two channels connected through a central bridge.
 Otherwise, the operator's channel is the only one in that bridge.


I'd definitely be interested in knowing what you've implemented - it's
always cool to hear how someone makes use of Asterisk and ARI!

I would expect the Whisper option to work regardless of the channel's
presence in a bridge. In both cases (snooping/whispering), the Snoop
operation works by hooking itself onto the target channel using an
audiohook. That audiohook feeds audio into/out of the target channel's
stream, which means that so long as audio is flowing in the intended
direction(s), it should get piped in/out.

There could be two things going on here:
1) There's a bug in the Whisper audiohook code or the Snoop code in ARI.
That's certainly possible, as it's one of the more complex parts of ARI.
2) The channel isn't answered or - internally - hasn't been told to send a
progress (183 w/SDP, etc.) notification. Ideally, we'd handle the latter of
those two cases automatically if a Snoop channel is attached to a channel
(which means that would be a bug as well) - but I'd be curious to know if
the channel is answered or not when you attach the Whispering Snoop channel
to it.


 Since I can hear the operator regardless of the current call situation I'm
 assuming there must be code in the Snoop option to mute the operator if a
 call is not active?

 Just to be sure, I setup the entire procedure using Swagger instead of my
 program and got the same results.  I also used the Delete Mute option to
 make sure the operator wasn't muted.

 Once the operator was on a live call I then had to run Snoop again and was
 able to Whisper to the operator.  I didn't check if I could still Whisper
 to the operator after the call ended.  I should.

 Am I right about the restriction for Whisper?  If not, any suggestions?
 And, if I am right, can a new option be added to allow Whisper to work
 without an active call?  And, if that would be a bounty type change if
 someone is interested in making it can you please let me know how much it
 would cost?


The wiki page on bug bounties outlines how that process works:

https://wiki.asterisk.org/wiki/display/AST/Asterisk+Bug+Bounties

I can't really say how much it would cost, as that's something that's
negotiated between the person offering the bounty and those who choose to
take it.



 Thank you for your time!  And, thank you again for ARI!!!


No problem! Hopefully we can figure out what is going on with your Whisper
scenario. If the channel is answered and the Whisper isn't working, please
do open up an issue and attach the logs illustrating it so we can't get to
the bottom of the problem.

Matt

-- 
Matthew Jordan
Digium, Inc. | Director of Technology
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] Deadlock in pthread_exit due to lazy binding with libgcc

[Matthew Jordan]

On Sun, Jul 19, 2015 at 3:28 PM, Sedat Karahancı i...@taxim.cab wrote:

Hi everybody
 We are looking for freelancers for a Push To Talk Project like Zello and
 Voxer.
 We still could not decide to choose Asterix or ? And we are looking for
 people freelancer or consultant for supporting us on this project ?
 Best,
 Sedat



Hijacking a conversation is not a good way to hire consultants or get help
for your project.

The asterisk-dev list is for discussion of the Asterisk source code. For
commercial related discussions, please use the asterisk-biz list.

http://lists.digium.com/mailman/listinfo/asterisk-biz

-- 
Matthew Jordan
Digium, Inc. | Director of Technology
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] storing INVITE fmtp and use it to send relay

[Matthew Jordan]

On Mon, Jun 29, 2015 at 4:36 AM, Kelvin Chua kel...@gmail.com wrote:
 Guys,

 just tried asterisk13 and added seanbrights' patch for opus.

 incoming INVITE has fmtp --
 maxplaybackrate=8000;sprop-maxcapturerate=8000
 but INVITE to my registered peer is --
 maxplaybackrate=48000;sprop-maxcapturerate=48000

 it should not even have to load up the opus patch because it is just a
 passthrough
 have you changed anything to chan_sip.c to make this work?


Do you have res_format_attr_opus loaded?

-- 
Matthew Jordan
Digium, Inc. | Director of Technology
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] To set realm in asterisk

[Matthew Jordan]

On Fri, Jun 19, 2015 at 1:15 AM, viji iyer viji...@gmail.com wrote:
 Hello all,

 I am new to asterisk. And I am trying to change the realm in sip.conf file
 to some custom name in the format:
 u...@xyz.com

 and domain as xyz.com

 realm = u...@xyz.com
 domain = xyz.com


 But the phones (using x lite phones) doesn't register.

 If we remove the above lines the phones get registered

 I also tried setting
 realm=xyz.com
 domainasrealm=yes

 Could you please let me know what configuration am I missing.


This question is not appropriate for the asterisk-dev mailing list,
which is concerned with discussing the actual implementation of the
Asterisk code.

Please ask your question on the asterisk-users mailing list. The vast
majority of developers exist on both mailing list, and not
surprisingly, the asterisk-users mailing list has a large number of
talented and industrious users of Asterisk who could also answer your
question.

-- 
Matthew Jordan
Digium, Inc. | Director of Technology
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] text2wav in ARI

[Matthew Jordan]

On Wed, Jun 17, 2015 at 4:17 AM, Sumesh M S sumes...@gmail.com wrote:
 Hi

 I would like to know is there a way to use Festival (text2wav) in ARI with
 JavaScript or PHP. Or is there any alternative solution for text to wave
 conversion with ARI?


Currently, there isn't a way to do this with ARI. Some discussion
about this feature has occurred on the asterisk-app-dev mailing list,
as well as at AstriDevCons. It's currently on a list of features that
people have expressed an interest in:

https://wiki.asterisk.org/wiki/display/AST/ARI+Feature+Wish-list

If you'd be interested in writing said feature, folks on the mailing
list could certainly help point you in the right direction.

Matt

-- 
Matthew Jordan
Digium, Inc. | Director of Technology
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] pjsip vs cel

[Matthew Jordan]

On Wed, Jun 10, 2015 at 11:30 PM, James Cloos cl...@jhcloos.com wrote:
 RM == Richard Mudgett rmudg...@digium.com writes:

 RM You can specify the dialplan context incoming calls go to when defining
 RM the endpoint.

 Obviously I've done that.  The issue is that the CHAN_START cel event
 does not reflect the specified context and the INVITE's ruri like
 chan_sip's CHAN_START event does, even though the subsequent events do.

 I thought I had explained that clearly; apologies for missing any
 ambiguity in my note.

It is a bug. When we allocate a channel in chan_pjsip, we are passing
empty strings into ast_channel_alloc_with_endpoint for the extension
and context parameters. The act of creating the channel in
ast_channel_alloc will, when the routine is finished, publish the
existence of the channel to the 'world' via Stasis, which will create
the CHAN_START event in CEL.

We set the context/extension later on in chan_pjsip_new after the
channel has been created; it should be trivial to refactor that to
pass that information into ast_channel_alloc_with_endpoint.


-- 
Matthew Jordan
Digium, Inc. | Director of Technology
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
Check us out at: http://digium.com  http://asterisk.org

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

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

Re: [asterisk-dev] Asterisk Beacon Module Proposal

[Matthew Jordan]

 asks for a token but does not
present the current token when it does so, it will be rejected. The
module should then request a new Server ID.

At any point in time, there is only one token associated with one
Server ID, not multiples.

Really, if this needs substantially more explanation on the wiki page,
that's fine, but this is really a mechanism to try and reasonably
prevent collisions. It is not meant to be a security mechanism (other
than it may frustrate someone who really is bored and tries to spoof
random UUIDs). The usage of reporting server assigned UUIDs is
probably going to account for 99% of our cases.


Hopefully this answers some of the concerns and suggestions.

Thanks!

Matt

-- 
Matthew Jordan
Digium, Inc. | Director of Technology
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] systemd sd_notify() [was: Re: Journald support for Asterisk]

[Matthew Jordan]

On Sun, May 10, 2015 at 3:03 AM, Tzafrir Cohen tzafrir.co...@xorcom.com wrote:
 On Sat, May 09, 2015 at 10:17:24AM +0200, Ludovic Gasc wrote:
 Hi,

 Systemd and Journald is now by default on Debian Jessie and Ubuntu 15.04,
 as on RHEL/CentOS.
 Journald supports syslog format, nevertheless, at least for us, the
 structured log system provided with journald helps us to debug the
 production.

 Slightly off-topic: if anybody wants to implement support for
 sd_notify(3)[1] in Asterisk, it would be nice.

 Suppose there would be a function called ast_daemon_changed_state()[2] to
 notify journald on end of start, start/end of reload and start of end.
 Is this information useful to anything else besides notifying systemd
 via sd_notify()?

 [1] http://www.freedesktop.org/software/systemd/man/sd_notify.html

 [2] Bad name, I know.

I'm not sure I'd create a new C API for this. Asterisk already uses
Stasis to convey a lot of this information, although today, it is only
consumed by AMI. The right way to do this would be to pull the
messages out of the manager topic and make them a bit more publicly
consumable. If that is done, you could then have a completely
independent external module that interfaces with systemd.

Since there isn't a reload start/stop, there'd have to be at least one
new message added as well.

The messages to look at are:

The publishing of Reload in loader.c::publish_reload_message
The publishing of FullyBooted in asterisk.c::publish_fully_booted
The publishing of Shutdown in asterisk.c::really_quit

-- 
Matthew Jordan
Digium, Inc. | Director of Technology
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] (unreported) uninitialized: struct ast_sockaddr

[Matthew Jordan]

On Mon, May 11, 2015 at 9:16 AM, Alexander Traud
pabstr...@compuserve.com wrote:
 B) Change my patch not to use a char* but char[128].
 Your easiest option with less chance of regression elsewhere would be this.

 Yes. Anyway: Is the Asterisk team interested in a patch at least for the 5
 affected files? These are 54 changes. I am not sure if the path via an issue
 (Jira) and a commit (Gerrit) is welcome for something like this.

 Furthermore, again there are several options:
   I) in those 5 files, report only those 54 changes which I need; or
  II) in those 5 files, correct *all* struct inits
 The latter is interesting, because there are memsets(.) which get
 unnecessary then. This created an additional option/question:
 III) shall I remove all - then duplicate - struct inits as well?

 Or shall I stop wasting anyone's time and go for option B, a char[128]?

I wouldn't say you're wasting anyone's time. It's a good question.

What you're proposing is a change to the semantics of ast_sockaddr in
order to accommodate a change in a patch you're making. A few things
to keep in mind:
1) Your module/patch, as well as the rest of the Asterisk modules, may
not be the only consumers of ast_sockaddr. It is a fundamental data
structure in Asterisk; other third party modules may use it. Since
your change modifies the semantics of the struct, you will also break
them.
2) If the rest of your patch is never pushed back up to the main
project, then the change you've made has little positive affect, while
breaking most other external modules that use it. That's not good for
the project. On the other hand, if you propose your feature for
inclusion as well, there's more of a benefit to the change.

That aside, if you can make a change with a little bit more work that
maintains the existing usage semantics, you get the best of both
worlds: your new feature gets what it needs, and the mainline Asterisk
project - as well as other third party modules - aren't broken.

So yes, I'd just use a char array with a fixed length.

-- 
Matthew Jordan
Digium, Inc. | Director of Technology
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] Journald support for Asterisk

[Matthew Jordan]

On Sat, May 9, 2015 at 9:15 AM, Bruce Ferrell bferr...@baywinds.org wrote:
 On 05/09/2015 01:17 AM, Ludovic Gasc wrote:
 Hi,

 Systemd and Journald is now by default on Debian Jessie and Ubuntu 15.04, as 
 on RHEL/CentOS.
 Journald supports syslog format, nevertheless, at least for us, the 
 structured log system provided with journald helps us to debug the 
 production.

 The idea behind that is to attach metadata with a log line to facilitate the 
 search with journalctl, you can write queries to find the errors.

 For example, with Apache: 
 http://httpd.apache.org/docs/trunk/mod/mod_journald.html

 For our Python daemons, for each log line, we store account_id, request_id, 
 endpoint and method used to be easy to retrieve quickly interesting logs.

 Moreover, not yet used for us, but you can generate statistics about your 
 source code real usage based
 on: 
 http://www.freedesktop.org/software/systemd/man/systemd.journal-fields.html#CODE_FILE=

 For Asterisk, for example with dialplan logging, you should attach the 
 context, the extension and the channel.

 You can simulate this journald feature with a specific format message for 
 your logs, nevertheless, journalctl is more user-friendly to retrieve 
 pertinent logs compare to the
 classical grep usage.
 ave no idea if i
 I'm permitted to raise the question about an eventual journald support in 
 Asterisk because I don't find anything about that in issues tracker nor 
 mailing list.

 Moreover, I understand that even if you add the journald support, it's 
 certainly necessary to change logging everywhere in Asterisk, however, I 
 should help to do that.

 Regards
 --
 Ludovic Gasc (GMLudo)
 http://www.gmludo.eu/


 systemd and journald SUCK to high heaven.  I have no idea if the issues I've 
 had with them (OpenSUSE) are distro related or inherent.

 I have seen that the implementation of apache with a static systemd/journald 
 module will no longer correctly serve content.

 Please do NOT do this.  It also breaks fail2ban site security.  Asterisk 
 works well now.  It integrates easily.

Being very honest, my knowledge of systemd and journald is not
extensive. I have no real position on systemd/journald one way or the
other. I will say that I do not view it as an inevitable conclusion,
nor a necessary requirement for Asterisk. As such, I'm viewing this
only as a proposal for we'd like to change the vast majority of log
statements in Asterisk.

First, as Bruno pointed out, a lot of external systems rely on parsing
log messages. Asterisk does not exist in a vacuum, and is often a
component in a much larger system. As such, any modification to
Asterisk's logging would have to be configurable.

Second, the logging system in Asterisk has a measurable impact on
performance. Unfortunately, adding a configuration option that is
evaluated on every log statement will further degrade performance when
logging verbosity is increased. A compile time option is not a
pleasant alternative either. Note that we experienced a similar
situation in Asterisk 11 with the remote console independent verbosity
setting, and spent a lot of time over many point releases getting the
performance back in line.

It is also telling that Apache's mod_journald states:
{quote}
Performance warning

Currently, systemd-journald is not designed for high-throughput
logging and logging access_log to systemd-journald could decrease the
performance a lot.
{quote}

Third, journald seems to be providing structured log data. While some
logging statements in Asterisk may benefit from such a system, many
may not. Asterisk can be *extremely* chatty. I'm not sure that every
log statement in Asterisk should be converted or support such a
system. A more concrete proposal over what messages are appropriate
for journald would be nice.

I'd be curious if another option would be to treat journald as we
currently treat syslog - not as a formatting option, but as a
destination. If that were possible, support could be added for it
without necessarily impacting the existing log statements. Asterisk
supports the concept of having dynamic log channels, and support for
journald could then also be added as an external module without
impacting the core - or impacting users who don't care for it.

-- 
Matthew Jordan
Digium, Inc. | Director of Technology
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
Check us out at: http://digium.com  http://asterisk.org

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

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

Re: [asterisk-dev] Asterisk Beacon Module Proposal

[Matthew Jordan]

On Fri, May 8, 2015 at 4:54 PM, Rodrigo Ramírez Norambuena
decipher...@gmail.com wrote:
 On Fri, May 08, 2015 at 11:49:39AM -0400, Moises Silva wrote:
 On Thu, May 7, 2015 at 10:35 PM, Matthew Jordan mjor...@digium.com wrote:

  Hey everyone -
 
  At the past several AstriDevCon events, we've had an open discussion
  about adding a module to Asterisk that would gather anonymous usage
  statistics. Said module would be used to help the Asterisk Developer
  community better support the users of Asterisk, as we would have some
  indication of the modules being used by the reporting segment of the
  Asterisk community.


 Is there a need for this to be an Asterisk module itself and not an
 external monitoring service/agent collecting (e.g via AMI) and pushing the
 stats? I'm just thinking this is not the kind of thing that *needs* to be
 in a C module. It'd be sad to have your Asterisk system crashing or
 misbehaving because of a bug in the beacon module.

There's a few issues with doing it outside of Asterisk:

1) Not all of the data you may want to retrieve may be readily
available. Granted, right now, I don't think that's the case, but
there's certainly more flexibility if you have access to Asterisk's C
APIs.

2) There's no real way to guarantee that someone will run a daemon
next to Asterisk, or that said daemon won't have some other
interaction that we won't expect. The only way I can think of to
reasonably introduce such a daemon is to make it part of the Asterisk
'install' target, and/or add it to packages. I'm not sure if having a
separate daemon spin up suddenly on someone's system, with no
warnings, would be much better.

That being said, I do think there's a few small benefits to making
this part of Asterisk:
1) We can give a visual warning that it is enabled. That's not as easy
to do via an external process.
2) Disabling it is done in a manner that is similar to other Asterisk
modules - don't build it in menuselect, or disable it in a .conf file.
3) Less important, it would have access to the C APIs in Asterisk.
With the advent of the Stasis message bus, we have mechanisms that can
prevent said module from impacting the critical run-time parts of
Asterisk. That gives us a lot of the power/flexibility of the Asterisk
APIs, while minimizing risk.

Your point is a good one though. No one wants the statistics module to
have a negative impact on their system. To that affect, there's a few
ways the proposal on the wiki minimizes risk:
1) It's relatively simple, and doesn't try to get a bunch of
information out of a lot of modules that may or may not be there. To
whit, all of the APIs needed for the information are in the core, and
have a reasonably minimal impact on the run-time aspects of Asterisk:
  - ast_get_version/ast_get_version_num: version.h
  - ast_active_calls/ast_processed_calls: pbx.h
  - ast_startuptime/ast_lastreloadtime: global constants in options.h
  - ast_update_module_list: module.h
2) The project plans outlines tests that should be created for the
module. That includes standing up a version of the REST API in the
testsuite, and providing both nominial and off-nominal tests.


 Other idea is a create a service/agent using ARI, is really needed add this
 module on 11 version?.

There are more Asterisk 11 systems out there than Asterisk 13 systems
(which is not surprising in the least). If the goal is to get a good
picture of what Asterisk systems are out there, having a module that
applies to all of the currently supported Asterisk versions makes
sense.

ARI has no relationship to the server, either one stood up by someone
running Asterisk or the proposed community service. For the Asterisk
13+ variant of the module, an ARI resource is proposed for a local
Asterisk instance as a way to see what data was last transmitted.

 A point i dont saw in the doc is what happens when dont have internet for
 notified the stats or have a problem for send the request. There should be a
 queue of stats to notify but this could has a conflict with rate limit inbound
 request of api server.

I disagree. I don't think queueing statistics is a good idea. A lot of
things can go wrong; e.g., what happens if the Asterisk server is
behind a firewall that blocks HTTPS? We'd never send the data; the
data would pile up; Asterisk would consume all of the systems memory,
etc.

The proposal on the wiki aims for some element of simplicity.
Simplicity minimizes errors and risk. To Moises's point, no one wants
the anonymous statistics module to impact their service.

-- 
Matthew Jordan
Digium, Inc. | Director of Technology
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
Check us out at: http://digium.com  http://asterisk.org

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

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

Re: [asterisk-dev] Asterisk Beacon Module Proposal

[Matthew Jordan]

On Thu, May 7, 2015 at 11:40 PM, George Joseph
george.jos...@fairview5.com wrote:
 On Thu, May 7, 2015 at 8:35 PM, Matthew Jordan mjor...@digium.com wrote:

 Hey everyone -

 At the past several AstriDevCon events, we've had an open discussion
 about adding a module to Asterisk that would gather anonymous usage
 statistics. Said module would be used to help the Asterisk Developer
 community better support the users of Asterisk, as we would have some
 indication of the modules being used by the reporting segment of the
 Asterisk community. There are, of course, a couple of agreed upon
 stipulations for such a module:

 * As noted, all information gathering must be anonymous. No
 information about the sending system should allow for someone viewing
 the data to be able to identify the system in quesiton.

 * The module must send all of its data encrypted.

 * Users must be notified as the last message on startup that anonymous
 usage statistics are being gathered.

 * The module must provide the ability for users to opt out of
 gathering statistics.

 * Users must be able to go to asterisk.org and view the statistics
 gathered for their server. The module must provide a unique,
 non-identifying token that users can use to view the gathered
 statistics for their servers.

 After some careful thought, we've put together a proposal for such a
 module – called “Beacon” - on the Asterisk wiki [1]. In addition to
 meeting the requirements discussed at previous AstriDevCons, the
 proposal on the wiki outlines a Swagger schema for a REST API that the
 module will talk to. The module configuration will support sending the
 usage statistics to more than just the server at asterisk.org,
 effectively allowing anyone to send statistics from their servers to
 other implementations of the REST API. This can be beneficial for
 people deploying large numbers of Asterisk servers.

 As mentioned, the asterisk.org site will be updated to allow for users
 to view the collected statistics. A sample screenshot is attached to
 this e-mail. Note that this is merely a mock up given some fake data,
 but it should hopefully illustrate what this may look like for
 Asterisk users.


 How about a summary dashboard anyone can view?

Sure! I'm not sure I can get the webby folks to create a wireframe for
that quickly, but I think it's something we should have.

I always liked the Linux Mint community page:

http://community.linuxmint.com/

Something similar to that for Asterisk would be pretty cool.


 Total number of pbxes by version, global count of modules used,  OSes used,
 etc.

 Another thing that might be useful is a histogram of peer/endpoint count per
 pbx.  How many pbxes with 1-50, 51-250, 251-1000, etc.  Maybe by technology,
 IAX2, SIP, PJSIP, etc.

I'd love that information, as it would really help get a feel for how
Asterisk is being used.

The only issue I have with gathering that data is that channel drivers
don't provide an easy API to get at that information (with the
exception, of course, of PJSIP. Go sorcery go!) The only option I can
think of is to use a config hook, i.e., a config_hook_cb, and process
the bare minimum of a config file for the channel drivers when they
are loaded/reloaded. That would require a bit more processing when
said config files are loaded/reloaded. I don't think we'd want to
report much more than counts of peers/friends/users/endpoints.

If others are okay with the small overhead of processing config files,
I can add it to the spec.

-- 
_
-- 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 Beacon Module Proposal

[Matthew Jordan]

Hey everyone -

At the past several AstriDevCon events, we've had an open discussion
about adding a module to Asterisk that would gather anonymous usage
statistics. Said module would be used to help the Asterisk Developer
community better support the users of Asterisk, as we would have some
indication of the modules being used by the reporting segment of the
Asterisk community. There are, of course, a couple of agreed upon
stipulations for such a module:

* As noted, all information gathering must be anonymous. No
information about the sending system should allow for someone viewing
the data to be able to identify the system in quesiton.

* The module must send all of its data encrypted.

* Users must be notified as the last message on startup that anonymous
usage statistics are being gathered.

* The module must provide the ability for users to opt out of
gathering statistics.

* Users must be able to go to asterisk.org and view the statistics
gathered for their server. The module must provide a unique,
non-identifying token that users can use to view the gathered
statistics for their servers.

After some careful thought, we've put together a proposal for such a
module – called “Beacon” - on the Asterisk wiki [1]. In addition to
meeting the requirements discussed at previous AstriDevCons, the
proposal on the wiki outlines a Swagger schema for a REST API that the
module will talk to. The module configuration will support sending the
usage statistics to more than just the server at asterisk.org,
effectively allowing anyone to send statistics from their servers to
other implementations of the REST API. This can be beneficial for
people deploying large numbers of Asterisk servers.

As mentioned, the asterisk.org site will be updated to allow for users
to view the collected statistics. A sample screenshot is attached to
this e-mail. Note that this is merely a mock up given some fake data,
but it should hopefully illustrate what this may look like for
Asterisk users.

Please take a look at the spec on the wiki and the proposed project,
and comment here with any suggestions for improvements.

Thanks!

Matt

[1] https://wiki.asterisk.org/wiki/display/AST/Asterisk+Beacon+Module

-- 
Matthew Jordan
Digium, Inc. | Director of Technology
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 14 Status and Project Timeline

[Matthew Jordan]

 as the
aforementioned issues, it has been a topic of conversation on the
mailing list a few times [19] [20]. Much of this has centered around
better integration between Asterisk and Kamailio. However, with the
exception of Daniel's proposal for a new authentication scheme, I
think we're still a little muddy on where the real problem areas with
scaling Asterisk horizontally lie. In many conversations – both on the
asterisk-dev list and in person with various people in the community –
I continually get the impression that while there are many areas for
improvement, no one is really quite sure what the real, intransigent
issues are, much less how to resolve them.

To that extent, I'd like to resurrect some of the threads that were
going on a few months ago, and try to reach some conclusion about what
areas in Asterisk are best to focus on to solve some of the
scalability issues people have alluded to over the years. Time is
always a limited commodity – and having people in the community
thinking about the most important problems will give Asterisk the
biggest payoff when features targeting scalability issues are
implemented.


= Conclusions =

So where does this leave us?

While we've made a lot of great progress on a number of the items from
AstriDevCon, it feels like we're still quite a ways out from the goals
outlined in that meeting. We still have a lot of infrastructure
improvements to make, we have a lot of features to document and
existing documentation to improve on, we have a plethora of ARI
features that people would love to have, and we're still not quite
sure where we should improve Asterisk to make it scale better.

All of that is a lot to cram in the next few months, and cramming
things is rarely a good idea.

To that extent, I'm proposing that we hold off on the Asterisk 14
deadlines for now. Having a stable release schedule is great for the
project and for users, but not at the expense of having a release that
doesn't meet its goals. While I don't want to hold users hostage to an
unimplemented feature list, I also want to make sure that we take
advantage of the Standard release, and that whatever we release moves
the Asterisk project substantially forward.

If you have any thoughts or comments on the above, I'd love to hear them.

And, as always, thanks for supporting the Asterisk project!

Matt


[1] https://wiki.asterisk.org/wiki/display/AST/Asterisk+Versions
[2] https://wiki.asterisk.org/wiki/display/AST/AstriDevCon+2014
[3] http://lists.digium.com/pipermail/asterisk-dev/2014-September/070303.html
[4] http://lists.digium.com/pipermail/asterisk-dev/2014-December/072024.html
[5] https://gerrit.asterisk.org
[6] http://lists.digium.com/pipermail/asterisk-dev/2015-March/073461.html
[7] http://lists.digium.com/pipermail/asterisk-dev/2015-April/074129.html
[8] http://lists.digium.com/pipermail/asterisk-dev/2015-April/074589.html
[9] https://wiki.asterisk.org/wiki/display/AST/Gerrit+Usage
[10] https://wiki.asterisk.org/wiki/pages/viewpage.action?pageId=29395573
[11] https://github.com/asterisk/ari-examples
[12] https://github.com/asterisk/voicemail-docs
[13] https://github.com/asterisk/node-confbridge
[14] 
https://wiki.asterisk.org/wiki/display/AST/res_pjsip+Remote+Attended+Transfers
[15] https://wiki.asterisk.org/wiki/display/AST/PJSIP+Transport+Selection
[16] https://wiki.asterisk.org/wiki/display/AST/PJSIP+Configuration+Wizard
[17] https://wiki.asterisk.org/wiki/display/AST/ARI+Feature+Wish-list
[18] https://wiki.asterisk.org/wiki/display/AST/Asterisk+14+Projects
[19] http://lists.digium.com/pipermail/asterisk-dev/2015-February/072748.html
[20] http://lists.digium.com/pipermail/asterisk-dev/2015-March/073217.html

-- 
Matthew Jordan
Digium, Inc. | Director of Technology
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] send DTMF not Detected on SIP/XXXX using AMI +AGI+EXEC+SendDTMF

[Matthew Jordan]

On Wed, Apr 22, 2015 at 6:56 AM, HKC323 hkc...@gmail.com wrote:
 This following setting has been configured.
 dtmfmode=rfc2833 has been set .
 set (Agi:async)
 sip client : jisti sip soft phone
 ==
 issue :
 When Agent A1 and Agent A2 are on call
 DTMF must be Passed and Feature must be exeute .
 here DTMF detect but feaure not extecuted .
 in case of local channnel DTMF and Feayure Both Worked.

 BUT in SIP/xxx-XXXxxx not worked ??
 ==
 AMI +playDTMF tried but did not work .
 ==

 so tied with AGI+AMI+EXEX+SendDTMF but still not working
 ==
 Action: AGI
 Channel: SIP/1120-0006
 Command: EXEC senddtmf *1
 CommandID: 0MyCommandSIP/1120-0006

 -- Unregistered SIP '1121'
 [Apr 22 03:55:10] -- Registered SIP '1121' at 192.168.0.106:5060
 [Apr 22 03:55:10] -- Added extension '1121' priority 1 to dundiextens
 [Apr 22 03:55:10]  Saved useragent Jitsi2.4.4997Windows 7 for peer
 1121
 [Apr 22 03:55:10] NOTICE[3388]: chan_sip.c:27924
 handle_request_subscribe: Received SIP subscribe for peer without
 mailbox: 1121
 [Apr 22 03:55:14] -- Unregistered SIP '1121'
 [Apr 22 03:55:14] -- Unregistered SIP '1120'
 [Apr 22 03:55:16] -- Registered SIP '1120' at 192.168.0.106:5060
 [Apr 22 03:55:16] -- Added extension '1120' priority 1 to dundiextens
 [Apr 22 03:55:16] -- Registered SIP '1121' at 192.168.0.106:5060
 [Apr 22 03:55:16] -- Added extension '1121' priority 1 to dundiextens
 [Apr 22 03:55:16] NOTICE[3388]: chan_sip.c:27924
 handle_request_subscribe: Received SIP subscribe for peer without
 mailbox: 1121
 [Apr 22 03:55:16] NOTICE[3388]: chan_sip.c:27924
 handle_request_subscribe: Received SIP subscribe for peer without
 mailbox: 1120
 [Apr 22 03:55:21] == Using SIP RTP CoS mark 5
 [Apr 22 03:55:21] -- Executing [1121@agent:1] NoOp(SIP/1120-0006,
 EXTEN:1121) in new stack
 [Apr 22 03:55:21] -- Executing [1121@agent:2] AGI(SIP/1120-0006,
 agi:async) in new stack
 [Apr 22 03:56:08] -- AGI Script Executing Application: (senddtmf)
 Options: (4)
 [Apr 22 03:56:55] -- AGI Script Executing Application: (senddtmf)
 Options: (*8)
 localhost*CLI



 r 22 04:14:26] -- AGI Script Executing Application: (senddtmf) Options:
 (*1)
 [Apr 22 04:14:26] DEBUG[3401]: manager.c:4831 match_filter: Examining
 event:
 Event: AGIExec


 ==


 Any Help 


This question is not appropriate for the asterisk-dev list. The
asterisk-dev list for discussing the actual source code of Asterisk;
this appears to be a configuration issue. Please ask this question on
the asterisk-users mailing list.

-- 
Matthew Jordan
Digium, Inc. | Director of Technology
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] A Week with GIT/Gerrit

[Matthew Jordan]

On Sat, Apr 18, 2015 at 8:26 PM, Matthew Jordan mjor...@digium.com wrote:
 On Thu, Apr 16, 2015 at 5:00 PM, George Joseph
 george.jos...@fairview5.com wrote:

 The Emails:

 Overall I think they're too verbose.
 Change in asterisk[master]: bridge.c: NULL app causes crash during attended
 transfer
 might be better as
 bridge.c: NULL app causes crash during attended transfer
 (asterisk[master])
 It's not a lot shorter but it has the most valuable info at the front.

 That's pretty easy.

This should now be fixed.

 Also, the mail generated by ReplacePatchSet which gets sent on a rebase,
 doesn't tell you why you're getting the message but it does have the entire
 original commit message which doesn't really help.  I'd remove the commit
 message and add the text of the last change. I.E.  Foo Bar: Patch Set 8:
 Patch Set 7 was rebased.  That'll at least tell reviewers not to worry
 about it.

 I think that makes some assumptions about why a patch set was
 replaced. It doesn't just occur during a rebase - it could just as
 easily occur due to a decrease/increase in the patch scope from
 comments on the previous patch set, in which case reading the text of
 the new commit message may be useful.

 Reading through your suggestion, I'm not sure what in the e-mail
 templates would give what you're looking for. The ReplacePatchSet does
 include the number of the new patch set, as well as the change subject
 - but inferring why a patch set was updated doesn't feel possible.

 Removing (Code Review) from the sender would be good as well.

 I can do that.

This should now be fixed as well.

 Cherry-picking:

 I think there are some issues we still need to figure out about the process
 and the system.  Process first...

 While having all the reviews up at the same time is a good thing, I think we
 need to always start with the lowest branch the patch is expected to apply
 to and merge up towards master.   I think the wiki says merge down for
 features and merge up for bugs.  It should be up always.  You don't want to
 start a feature in master only to discover that it can't go into 13 because
 some other feature is only in master.  Same for review process.  Start in
 the lowest branch and work up.  This will hopefully minimize where different
 people are starting from different directions.  It's hard to follow feedback
 and ensure you've got all the comments covered like that.

 Generally, I agree with starting the review on the lowest branch and
 working up. If a patch is substantially different enough between major
 versions that may not always work, but I could see people focussing on
 master and forgetting to properly review the release branches - which
 is where the most attention should generally be spent.

 Like Corey, I'm not sure we can always say cherry-pick up. New
 features feel like they *must* be written for master first, then
 cherry-picked back as appropriate.

 Something I've noticed though is that dependencies get messed up when
 cherry-picking a series of dependent patches.   Look at my patches 46, 47,
 48 for master.  If I cherry-pick 48 to my local repo, I get all 3 which is
 good because I can't test any without all 3.  BUT now look at 43, 44, 45 for
 13.  When I check out 45, I get only 45 which is an issue.  Maybe this is
 just an artifact of this being the first time with this scenario but it's
 something to look out for.

 Other things:

 There's a rebase button on reviews which need it but if you click it, you
 lose you're votes.  :(  We probably need a policy around rebasing reviews.

 The +1's may go away on the current review, but they do still show
 up in the history. If someone has a +1 and has to rebase for the final
 merge, I don't think we need to go through another cycle.

 I've noticed a couple of times where doing a 'git review' regenerated the
 Change ID and I can't figure out why.  I've resorted to running 'git review
 -n' to see the commands and just running the 'git push' part.  I'm still
 investigating.

 If you move between major releases you'll find various orphaned files and
 directories that are part of one release but not antother.  Use 'git clean
 -fd' to clean them up.  BEWARE:  this will remove all files/directories that
 aren't part of the current branch or in the .gitignore files.   If you have
 local scripts or other stuff you want to keep between checkouts, add them to
 .git/info/exclude.

 If you're a Google Apps/Gmail user use the filter
 list:gerrit.asterisk.org to filter all messages regardless of repo.

 If you're switching between branches with the same major version a lot,
 install ccache!  You're compiles will go a lot faster.

 When doing a 'git review' to update a review, you don't have to specify the
 topic branch again but you DO have to specify the target branch if it's not
 master.

 We could still use the links to the specific git/gerrit wiki pages on the
 gerrit menu.


 I'll get that taken care of this weekend as well.


This is now the first link

Re: [asterisk-dev] A Week with GIT/Gerrit

[Matthew Jordan]

On Fri, Apr 17, 2015 at 3:42 PM, Corey Farrell g...@cfware.com wrote:
 My additions to the list:
 1) Procedure for 'git review' of security related patches.  I think this
 could be done with an asterisk-security mirror repository setup in gerrit
 with restricted access.  I know this is already being thought about, just
 wanted to make sure it on the list.

I think there's a lot of things to think through with this, since
Gerrit - being a Git repo - tends to expose all patches in some form
or fashion. We could set up a completely separate server with
extremely limited access, but then we would need a separate review
server as well.

In the meantime, we might be able to use review board for this,
although it will mean porting it over to look at the Git repos.

It's certainly on the list to think through more.

 2) Is there a command similar to 'git show-branch 13 master' that will
 operate on Change-Id's?  Something to show me the first line of all commits
 with change-id's that hit one branch but not the other.
 3) It would be great if gerrit had the ability to detect the string
 ASTERISK-# in commit messages and review comments, convert it to a
 JIRA link.

Apparently this is possible and is actually just a configuration issue:

http://gerrit.googlecode.com/svn/documentation/2.2.1/config-gerrit.html#_a_id_commentlink_a_section_commentlink

I'll try to get that set up this week.

 4) 'git review -D' should not generate emails or allow the review to be seen
 on the web UI by anyone except the submitter.  I know this is probably a bug
 in gerrit, but still worth having on the list.

I will say that the last time there was a draft, it did show on the UI
as a Draft. I upgraded to 2.10.3.1 this weekend - maybe we'll get
lucky and it got fixed? :-)

 5) We should add instructions for squashing commits before review somewhere
 on the Git or Gerrit usage page.


Ack. I'll try to get to that today. Maybe on the Git usage or Commit
message page, since it isn't explicitly tied to using Gerrit?

-- 
Matthew Jordan
Digium, Inc. | Director of Technology
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] s?rtp via SIP/TLS/TCP

[Matthew Jordan]

On Mon, Apr 20, 2015 at 10:41 AM, James Cloos cl...@jhcloos.com wrote:
 I'm not sure whether this is a bug, so I'm starting here.

 My remote asterisk (debian's compile of 13, currently 13.1.0) and my
 snom had been unable to rtp for some time.  I still use chan_sip.

 It took a few hours of testing, but I determined that when the phone
 registers and/or invites over tls, asterisk refuses to do either un-
 encrypted rtp or srtp unless force_avp=yes.

 The symptom was a hangup w/ unknown cause as soon as it was time to
 start rtp.  Ie, right after the OK.  Even with verbose and debug set
 to 9 no explanation was logged.  When I tried adding force_avp=yes
 everything started working again.

 I don't know when it stopped working (I don't get enough calls and
 send outgoing via a different asterisk); I presume that it stopped
 working when force_avp was added, but cannot confirm that.

 Is force_avp supposed to be required for non-dtls rtp when sip is
 secure?

Without a trace showing the SIP message traffic, any answer is going
to be a guess.

Guessing at what is occurring here: your phone is probably offering
optional/optimistic encryption. While optimistic encryption is
supported by chan_pjsip, currently, an offer with RTP/AVPF with crypto
attributes is currently rejected by chan_sip. See
https://issues.asterisk.org/jira/browse/ASTERISK-23989.

-- 
Matthew Jordan
Digium, Inc. | Director of Technology
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] Branches

[Matthew Jordan]

On Sun, Apr 19, 2015 at 4:42 AM, Olle E. Johansson o...@edvina.net wrote:
 How do I push changes to my branches? If I try a git push my gerrit 
 username/password doesn't work.


Hi Olle -

I hadn't yet updated the Gerrit Usage wiki page with instructions on
manipulating the team branches. I've gone ahead and updated it now
with a section on working with team branches:

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

While I've tested doing direct pushes with my account to a team
branch, it'd be good to have someone else test it out as well. If you
have a permissions problem, please paste the full command + error so I
can help track it down.

Thanks -

Matt

-- 
Matthew Jordan
Digium, Inc. | Director of Technology
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] A Week with GIT/Gerrit

[Matthew Jordan]

On Thu, Apr 16, 2015 at 5:00 PM, George Joseph
george.jos...@fairview5.com wrote:

 The Emails:

 Overall I think they're too verbose.
 Change in asterisk[master]: bridge.c: NULL app causes crash during attended
 transfer
 might be better as
 bridge.c: NULL app causes crash during attended transfer
 (asterisk[master])
 It's not a lot shorter but it has the most valuable info at the front.

That's pretty easy.

 Also, the mail generated by ReplacePatchSet which gets sent on a rebase,
 doesn't tell you why you're getting the message but it does have the entire
 original commit message which doesn't really help.  I'd remove the commit
 message and add the text of the last change. I.E.  Foo Bar: Patch Set 8:
 Patch Set 7 was rebased.  That'll at least tell reviewers not to worry
 about it.

I think that makes some assumptions about why a patch set was
replaced. It doesn't just occur during a rebase - it could just as
easily occur due to a decrease/increase in the patch scope from
comments on the previous patch set, in which case reading the text of
the new commit message may be useful.

Reading through your suggestion, I'm not sure what in the e-mail
templates would give what you're looking for. The ReplacePatchSet does
include the number of the new patch set, as well as the change subject
- but inferring why a patch set was updated doesn't feel possible.

 Removing (Code Review) from the sender would be good as well.

I can do that.

 Cherry-picking:

 I think there are some issues we still need to figure out about the process
 and the system.  Process first...

 While having all the reviews up at the same time is a good thing, I think we
 need to always start with the lowest branch the patch is expected to apply
 to and merge up towards master.   I think the wiki says merge down for
 features and merge up for bugs.  It should be up always.  You don't want to
 start a feature in master only to discover that it can't go into 13 because
 some other feature is only in master.  Same for review process.  Start in
 the lowest branch and work up.  This will hopefully minimize where different
 people are starting from different directions.  It's hard to follow feedback
 and ensure you've got all the comments covered like that.

Generally, I agree with starting the review on the lowest branch and
working up. If a patch is substantially different enough between major
versions that may not always work, but I could see people focussing on
master and forgetting to properly review the release branches - which
is where the most attention should generally be spent.

Like Corey, I'm not sure we can always say cherry-pick up. New
features feel like they *must* be written for master first, then
cherry-picked back as appropriate.

 Something I've noticed though is that dependencies get messed up when
 cherry-picking a series of dependent patches.   Look at my patches 46, 47,
 48 for master.  If I cherry-pick 48 to my local repo, I get all 3 which is
 good because I can't test any without all 3.  BUT now look at 43, 44, 45 for
 13.  When I check out 45, I get only 45 which is an issue.  Maybe this is
 just an artifact of this being the first time with this scenario but it's
 something to look out for.

 Other things:

 There's a rebase button on reviews which need it but if you click it, you
 lose you're votes.  :(  We probably need a policy around rebasing reviews.

The +1's may go away on the current review, but they do still show
up in the history. If someone has a +1 and has to rebase for the final
merge, I don't think we need to go through another cycle.

 I've noticed a couple of times where doing a 'git review' regenerated the
 Change ID and I can't figure out why.  I've resorted to running 'git review
 -n' to see the commands and just running the 'git push' part.  I'm still
 investigating.

 If you move between major releases you'll find various orphaned files and
 directories that are part of one release but not antother.  Use 'git clean
 -fd' to clean them up.  BEWARE:  this will remove all files/directories that
 aren't part of the current branch or in the .gitignore files.   If you have
 local scripts or other stuff you want to keep between checkouts, add them to
 .git/info/exclude.

 If you're a Google Apps/Gmail user use the filter
 list:gerrit.asterisk.org to filter all messages regardless of repo.

 If you're switching between branches with the same major version a lot,
 install ccache!  You're compiles will go a lot faster.

 When doing a 'git review' to update a review, you don't have to specify the
 topic branch again but you DO have to specify the target branch if it's not
 master.

 We could still use the links to the specific git/gerrit wiki pages on the
 gerrit menu.


I'll get that taken care of this weekend as well.

-- 
Matthew Jordan
Digium, Inc. | Director of Technology
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
Check us out at: http://digium.com  http://asterisk.org

Re: [asterisk-dev] Git Migration update

[Matthew Jordan]

On Tue, Apr 14, 2015 at 9:24 AM, Russell Bryant
russ...@russellbryant.net wrote:
 On Mon, Apr 13, 2015 at 6:52 PM, Matthew Jordan mjor...@digium.com wrote:

 For *right now*, we are going to try cherry-picking the changes to the
 affected branches when the change is first up for review. This is
 clearly a pretty big change in process, as the act of merging into
 other branches was (a) always done by those with commit access and (b)
 never reviewed. There's at least two good reasons to give this a try:

 (1) There isn't anyone with commit access. Anyone can post a review
 up to Gerrit. The plus side is that there are far fewer barriers to
 getting a patch into Asterisk. The downside is that there isn't a
 select group of people who have been trusted to do the merges. The
 only way to ensure that patches actually do get merged into all the
 branches is to require people to put the patches up with the initial
 review.

 (2) Gerrit really, really wants to review things. That's a good thing:
 we've had plenty of bad merges take out branches in the past - either
 from compilation issues, subtle bugs that creep in due to API
 compatibility problems, etc. We've had even more that get merged
 upstream and fail to take advantage of APIs that exist in later
 versions of Asterisk. Reviews will help to catch that.

 This is a trial. We'll re-evaluate how things are working at the end
 of the week.

So, tentatively, I think the model of cherry-picking changes to all
affected branches (including master) is working out okay. This does
mean the volume of code reviews has gone up, but we appear to be
keeping reasonable pace with the changes.

One of the benefits of Gerrit is that while the volume of code reviews
is greater, it is:
(1) FAR easier to get changes merged in, particularly when the entire
change is now reviewed for all branches.
(2) Much more collaborative, as anyone can address findings and/or fix
up commits and update reviews.

As such, I've gone ahead and updated the various wiki pages (with some
help from Corey and George) to note the Git related policies. The
major pages are:

* Patch Contribution Process
(https://wiki.asterisk.org/wiki/display/AST/Patch+Contribution+Process)
  A very high level page that details for new(er) developers how to
submit a patch to the project. It's also a good overview for everyone,
and links to many of the pages below.

* Git Usage (https://wiki.asterisk.org/wiki/display/AST/Git+Usage)
  This brief page lists out the various Git repositories (mirrors and
the like), and specific recommendations for how the -2+2 reviews
should be handled.

* Gerrit Usage (https://wiki.asterisk.org/wiki/display/AST/Gerrit+Usage)
  This rather detailed page contains instructions for using Gerrit and
git review.

* Commit Messages (https://wiki.asterisk.org/wiki/display/AST/Commit+Messages)
  Details proper formatting of commit messages. Since the commit
messages are also reviewed, this is important for everyone.

* Software Configuration Management Policies
(https://wiki.asterisk.org/wiki/display/AST/Software+Configuration+Management+Policies)
  Details the types of branches in Asterisk (Standard vs LTS), new
feature/bug fix policies, as well as the currently supported branches.
Most of this should be familiar to long-time developers of Asterisk,
and not much has changed here.

I'm sure there is information that is still missing or unclear. If you
have any questions about the content on the pages above, please feel
free to ask here on the mailing list or in #asterisk-dev, and I (or
others) will work to get them cleared up.

Thanks!

Matt

-- 
Matthew Jordan
Digium, Inc. | Director of Technology
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 1.8/12 build system changes

[Matthew Jordan]

Hello!

As you know, 1.8 and 12 are in security fix only mode. Generally, that
would normally mean that releases made from those branches would only
ever be made from the previous tag, ensuring that the only changes in
the versions are specific to the security issues being resolved.

However, since we've moved to Git, there are a few things that needed
to be merged into those branches for them to be useful. That includes
a minimum amount of Git support (.gitignore files, for example). More
generally, that also included menuselect, as those branches previously
relied on svn:externals to pull menuselect in.

That begs the question: the next time we make a release of 1.8/12 for
security reasons, what is the release? And what should it be called?

I can see a few different options:

* The next release is 1.8.32.4/12.8.3, but is made from the branch and
contains the menuselect/git changes.

* We make a special, one-time only, bug fix release of 1.8/12
containing the menuselect/git changes, with a note of why it was made.
Those releases would go out as 1.8.33.0 and 12.9.0.

* We don't make a special bug-fix release, but instead the next
security release is made as 1.8.33.0/12.9.0 and contains both the
menuselect/Git changes as well as the security release changes.

Note that in any of the cases mentioned above, the UPGRADE notes will
clearly state what has changed in the version, including the
menuselect alterations.

Thoughts? Suggestions? Flames?

-- 
Matthew Jordan
Digium, Inc. | Director of Technology
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] 4490: astdb: Allow clustering of the Asterisk Database between multiple Asterisk servers

[Matthew Jordan]

On Wed, Apr 8, 2015 at 1:03 PM, Mark Michelson reviewbo...@asterisk.org wrote:

Before I repost the AstDB Clustering review from Review Board onto
Gerrit, I wanted to address Mark's concerns below. Depending on what
people think, it may be worth just shelving the idea.



 The only things I can think of that are issues here are based on theoretical 
 usage of shared DB families, especially global ones.

 Say that someone is sharing /foo/key between Asterisk 1 and Asterisk 2. A 
 user on Asterisk 1 sets /foo/key = bar at the same time that a user on 
 Asterisk 2 sets /foo/key = baz. What may happen is that the local Asterisk 
 boxes will set the values locally and then publish the updated values 
 near-simultaneously to the other Asterisk box. The result may be that they 
 both have /foo/key = bar, they both might have /foo/key = baz, or Asterisk 1 
 may end up with /foo/key = baz and Asterisk 2 ends up with /foo/key = bar. 
 Essentially, there is nothing in place to guarantee the synchronization of 
 globally shared values.

That is correct. There is no implicit synchronization.

Using a 'global shared family' implies some level of knowledge about
how the keys are used on the respective systems. Where this is useful
is places like registration, where you know that the devices
registering to a cluster of Asterisk servers are all unique, but you
want the knowledge of the registration to be shared globally. In that
respect, this is very much like clustering of MWI. There is no
aggregation of MWI IDs between Asterisk instances, nor is there
synchronization of values. If someone configures identical mailbox IDs
on two Asterisk systems and updates the mailbox state to different
states on different servers, a discontinuity will occur.

 So what's the best way to deal with this? I can think of several answers:
 * The AstDB may not be the right tool for this use case and you should be 
 using a key-value store that is built for this instead.

Possibly. In that case, you'd simply have the AstDB pass through to
some other mechanism (redis/RabbitMQ/etc.) In the long run this may be
better. It would be interesting to have the AstDB act as a facade on
top of some other technology, defaulting to SQLite3.

 * You may be able to satisfy your use case with unique shared keys instead of 
 global shared keys.

I think they are separate use cases. If you don't know whether or not
you will have collisions, unique shared keys is clearly the answer,
but you have to aggregate the duplicates yourself. If you have global
keys, you're either not caring about the synchronization, or you
'know' that all keys will be unique across all Asterisk instances.

 * We may want to make global shared keys one-way. In other words, there is an 
 owner of the key and listeners for changes in the key's value. Listeners 
 on a global shared key cannot update their local DB with new values; only the 
 owner can push new values to it. Listeners on a global shared key cannot 
 share the value with other listeners; only owners may push changes to 
 listeners.

I think if we went down that road, I'd personally rather scrap the
change and have the AstDB sit in front of other technologies.

 While I'm thinking about it, there's also the possibility that the underlying 
 AstDB implementation could be replaced with a key-value store that has the 
 concept of replication built into it. If that were done, then presumably, 
 there would be no need to involve Stasis or SIP PUBLISH in the process of 
 sharing values between Asterisk boxes.


Yup.

SO!

The question is: is this change worth having, or should it be scrapped
in favour of some alternate approach that makes use of other
technology? My feelings won't be hurt if the answer is ditch it and
do something else - this was a fun piece of code to right on some
plane flights. On the other hand, I don't have any real interest in
writing an alternative approach, so if the expectation is that an
AstDB wrapper around RabbitMQ or Redis will magically appear if I hit
the delete key, that expectation is likely to be wrong.

-- 
Matthew Jordan
Digium, Inc. | Director of Technology
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] Subjects for e-mails

[Matthew Jordan]

On Tue, Apr 14, 2015 at 9:43 AM, Dan Jenkins dan.jenkin...@gmail.com wrote:

 On Tue, Apr 14, 2015 at 3:18 PM, Russell Bryant russ...@russellbryant.net
 wrote:

 On Tue, Apr 14, 2015 at 8:47 AM, Matthew Jordan mjor...@digium.com
 wrote:

 On Tue, Apr 14, 2015 at 2:15 AM, Olle E. Johansson o...@edvina.net
 wrote:
  Can we possibly have different Subject: lines in e-mails for a commit
  and for a review. Seems like
  everything is a change in asterisk now. I would like to be able to
  prioritize reading the
  commits.
 

 I took a look at the Gerrit settings, and it doesn't appear to support
 that:

 https://gerrit-review.googlesource.com/Documentation/user-notify.html

 and:


 https://gerrit-review.googlesource.com/Documentation/config-gerrit.html#sendemail

 It does support having commits go to a separate list than reviews;
 that should already be set up for the asterisk-commits list (although
 the last tweaks on it just went in yesterday).


 With gerrit it's actually pretty easy to subscribe to the messages you
 want.  You can get notified for new reviews, when patches are updated, when
 patches merge, or when people make comments (all optionally on a per
 repository basis).  So, another option would be to drop sending to the list
 completely and let people configure their own notifications that suit their
 needs and interests.

 --
 Russell Bryant

 --
 _
 -- 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


 I like this idea Russell

Given that the e-mails are now only going to the asterisk-commits and
asterisk-code-review lists - and not the asterisk-dev list - I think a
combination of both options is probably okay.

* If you want to see the spam, subscribe to the lists
* If you want personalized e-mail notifications, set it up through Gerrit

-- 
Matthew Jordan
Digium, Inc. | Director of Technology
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] Subjects for e-mails

[Matthew Jordan]

On Tue, Apr 14, 2015 at 2:15 AM, Olle E. Johansson o...@edvina.net wrote:
 Can we possibly have different Subject: lines in e-mails for a commit and for 
 a review. Seems like
 everything is a change in asterisk now. I would like to be able to 
 prioritize reading the
 commits.


I took a look at the Gerrit settings, and it doesn't appear to support that:

https://gerrit-review.googlesource.com/Documentation/user-notify.html

and:

https://gerrit-review.googlesource.com/Documentation/config-gerrit.html#sendemail

It does support having commits go to a separate list than reviews;
that should already be set up for the asterisk-commits list (although
the last tweaks on it just went in yesterday).

-- 
Matthew Jordan
Digium, Inc. | Director of Technology
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] Git Migration update

[Matthew Jordan]

On Mon, Apr 13, 2015 at 5:52 PM, Matthew Jordan mjor...@digium.com wrote:
 On Sun, Apr 12, 2015 at 1:57 AM, George Joseph
 george.jos...@fairview5.com wrote:


 On Sat, Apr 11, 2015 at 10:15 PM, Matthew Jordan mjor...@digium.com wrote:


snip

Further updates after Day 2 (3?):

1. Due to popular request, the code review e-mails (which were nearing
spam levels) are going to be redirected to a new mailing list. The new
mailing lists is asterisk-code-review - see
http://lists.digium.com/cgi-bin/mailman/listinfo/asterisk-code-review

2. All branches should have .gitignore/.gitreview files, including 1.8/12

3. Versions should be reported correctly in Git branches. A review is
up now to get the Test Suite understanding things.

Items on the short-list to figure out:

1. Backport menuselect into 1.8, 11, and 12

2. Fix (or investigate) build failures that occur when switching
between branches. I'm not sure if anyone else has run into this yet,
but ./configure  make tends to get stuck on menuselect rather
hard, and I'll have to run a 'make clean' to get things moving again,
which is weird.

3. Fix 'make update'

4. Document how to push to team branches, and make sure that works as expected

5. Update the Gerrit web links module to point to our instructions on Git/Gerrit

6. Tackle the repotools release-summary scripts

There's plenty more after that, but that's on my short-term punch
list. If anyone would like to look at any of those items (apart from
the muck with Gerrit modules item, at any rate), feel free to help
yourself :-)

-- 
Matthew Jordan
Digium, Inc. | Director of Technology
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] Gerrit plugin suggestions

[Matthew Jordan]

On Sun, Apr 12, 2015 at 7:04 PM, George Joseph
george.jos...@fairview5.com wrote:

 menuextender:  Allows the creation of additional menu items.  I'd suggest
 using this for adding links to various wiki pages, git.asterisk.org, etc.

 reviewers-by-blame:  This might be a little too much but it automatically
 adds reviewers to a change based on who last changed the affected lines.

 wip:  Allows changes to be maked as Work-In-Progress.  Would be good for RFC
 changes.

wip plugin installed. You should now see a Work in Progress button
on reviews. Pressing that will cause the review to be marked as not
ready for review, and not show up in reviewers list of reviews.
Updating the patch set or setting it back to Ready for Review causes
it to show back up.

-- 
Matthew Jordan
Digium, Inc. | Director of Technology
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] Git Migration update

[Matthew Jordan]

On Sun, Apr 12, 2015 at 1:57 AM, George Joseph
george.jos...@fairview5.com wrote:


 On Sat, Apr 11, 2015 at 10:15 PM, Matthew Jordan mjor...@digium.com wrote:


 I'm wondering if we can do this...

 You submit a review on the lowest target branch, using 13 as an example.
 The review gets reviewed and merged into 13.  Once the review is closed
 gerrit won't allow a cherry-pick but git of course has no problems with it.
 So maybe we can write/obtain a hook/plugin that allows the submitter to
 cherry-pick the change directly into the target branch, say master,
 bypassing the review process, assuming a clean merge.

 Alternative...  We normally don't have access to commit to refs/head
 directly but what if we had a hook that allowed a commit to be merged
 directly IF the commit-id/change-id matched a review already approved and
 merged to the original branch.

As an update to everyone:

For *right now*, we are going to try cherry-picking the changes to the
affected branches when the change is first up for review. This is
clearly a pretty big change in process, as the act of merging into
other branches was (a) always done by those with commit access and (b)
never reviewed. There's at least two good reasons to give this a try:

(1) There isn't anyone with commit access. Anyone can post a review
up to Gerrit. The plus side is that there are far fewer barriers to
getting a patch into Asterisk. The downside is that there isn't a
select group of people who have been trusted to do the merges. The
only way to ensure that patches actually do get merged into all the
branches is to require people to put the patches up with the initial
review.

(2) Gerrit really, really wants to review things. That's a good thing:
we've had plenty of bad merges take out branches in the past - either
from compilation issues, subtle bugs that creep in due to API
compatibility problems, etc. We've had even more that get merged
upstream and fail to take advantage of APIs that exist in later
versions of Asterisk. Reviews will help to catch that.

This is a trial. We'll re-evaluate how things are working at the end
of the week.

Instructions for cherry-picking changes are on a draft wiki page here:

https://wiki.asterisk.org/wiki/display/AST/Git+Usage

-- 
Matthew Jordan
Digium, Inc. | Director of Technology
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] How to get peer review for patch to deprecated module

[Matthew Jordan]

On Sun, Apr 12, 2015 at 11:26 AM, Alex Villací­s Lasso
a_villa...@palosanto.com wrote:
 El 11/04/15 a las 22:59, Matthew Jordan escribió:

 On Sat, Apr 11, 2015 at 4:31 PM, Alex Villacís Lasso
 a_villa...@palosanto.com wrote:

snip

 I'd recommend doing the following:

 * Re-open ASTERISK-20347 and attach the patch to the issue after
 signing a CLA [1]. Regardless of the state of the source control for
 Asterisk, your patch will at least be tracked in the project. Again,
 I'll be happy to re-open the issue once you've confirmed you're
 willing to sign a CLA and/or have already done so.

 I have already signed a license agreement for user a_villacis on JIRA. I
 have also uploaded the patch (against 11.17.0) on ASTERISK-20347. How do I
 proceed to get the bug reopened?

I've re-opened the bug. Thanks for attaching the patch.

I'd highly recommend posting the patch for review on Gerrit. While
things are a bit in a state of flux - in fact, we're fleshing out some
policy ideas right now - you should be able to post the patch for
review against the Asterisk 11 branch at a minimum.

To do that, please follow the instructions on the wiki:

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

Note that since you are posting this against the 11 branch, you'll
want to invoke git review with that branch:

git review -t ASTERISK-20347 11

-- 
Matthew Jordan
Digium, Inc. | Director of Technology
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] Gerrit plugin suggestions

[Matthew Jordan]

On Sun, Apr 12, 2015 at 7:04 PM, George Joseph
george.jos...@fairview5.com wrote:

 menuextender:  Allows the creation of additional menu items.  I'd suggest
 using this for adding links to various wiki pages, git.asterisk.org, etc.

Added. Right now I've just got it linking to the issue tracker and the
wiki. I'll add git.asterisk.org next.

Any other suggestions? Maybe the specific Gerrit usage page on the wiki?

 reviewers-by-blame:  This might be a little too much but it automatically
 adds reviewers to a change based on who last changed the affected lines.

If the project had less history, I think this would be a great idea.
As it is, I think we have a few people who would be ... surprised? ...
if they received an e-mail that they were a reviewer on an Asterisk
code review.

 wip:  Allows changes to be maked as Work-In-Progress.  Would be good for RFC
 changes.

I'll take a look at this one next.

-- 
Matthew Jordan
Digium, Inc. | Director of Technology
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] How to get peer review for patch to deprecated module (was: Re: [asterisk-users] Help debugging a possible SIP channel leak in 11.17.0, possible race condition)

[Matthew Jordan]

On Sat, Apr 11, 2015 at 4:31 PM, Alex Villacís Lasso
a_villa...@palosanto.com wrote:
 El 10/04/15 a las 14:16, Alex Villací­s Lasso escribió:

 El 08/04/15 a las 08:22, Vinicius Fontes escribió:

 Have you tried Asterisk 13? The bridging mechanism has been completely
 rewritten on Asterisk 12, so there's no longer channel masquerading and
 zombie channels. Might be worth a try.

 Sorry, this client is very hard to talk into stopping its operations long
 enough to install changes, let alone a major Asterisk version change. I
 already had trouble convincing him of the need to install a debugging
 version with DEBUG_THREADS enabled.

 After reviewing a core show locks output, I am very sure I have hit an
 Asterisk bug involving a deadlock in cdr_mysql . When doing a core reload
 on the CLI, cdr_mysql calls ast_cdr_unregister() with its internal lock held
 (mysql_lock). However, writing a CDR involves adquiring the cdr lock and
 then the internal lock. Therefore, deadlock. None of the other cdr modules
 does that.

 However, I know that cdr_mysql is currently deprecated for Asterisk 11. I
 have a patch to fix the issue mentioned above (attached), but I want to know
 how to get it reviewed, if only to see whether the fix is sane.


First, regardless of the module support state, if the module exists in
Asterisk, it can be patched. The module support state only reflects
the way in which support of a module is handled; if you write a patch
for a module and would like to contribute it, that's always welcomed.

Second, I suspect you are hitting this bug:

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

If you would like to have it re-opened, I'd be happy to do so.

Third, patches via e-mail are typically not viewed (although your
mileage may vary). Part of the CLA stipulates that, when submitting a
patch to Asterisk, you are verifying that you are either the author of
the patch, or have the permission of the authors to contribute the
patch back to Asterisk. Over e-mail, it is difficult to ascertain if
someone has (a) signed a CLA, and (b) wants to contribute a patch back
to Asterisk under the CLA. As such, you'll need to submit the patch
via one of the project mechanisms.

Normally, that would mean attaching the patch to an issue in JIRA
and/or submitting it to Review Board. Alas, this is a bit of an
awkward weekend, as the Asterisk project is in the middle of moving
from Subversion to Git. As a result, things are in a bit of a state of
flux.

I'd recommend doing the following:

* Re-open ASTERISK-20347 and attach the patch to the issue after
signing a CLA [1]. Regardless of the state of the source control for
Asterisk, your patch will at least be tracked in the project. Again,
I'll be happy to re-open the issue once you've confirmed you're
willing to sign a CLA and/or have already done so.
* If you'd like, after signing a CLA, you can submit the patch for
review on Gerrit [2]. Clone the 'asterisk' repo on Gerrit [3], apply
the patch to 'master', and submit it using 'git review'. Draft
instructions for using Gerrit can also be found on the wiki [4].

If you'd like immediate feedback, I'd highly suggest posting the patch
to Gerrit. Code reviews are a normal part of the Asterisk developer
workflow, and we typically look for patches on tools that support
that.

[1] https://issues.asterisk.org/jira/secure/DigiumLicense.jspa
[2] https://gerrit.asterisk.org/#/
[3] https://gerrit.asterisk.org/#/admin/projects/asterisk
[4] https://wiki.asterisk.org/wiki/display/AST/Gerrit+Usage

-- 
Matthew Jordan
Digium, Inc. | Director of Technology
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] Git Migration update

[Matthew Jordan]

Hey everyone -

As an update on the Git migration, here is the current state of the world:

1. The SVN repos have been marked read-only. While you will still be
able to checkout from SVN, you shouldn't commit to any of the
branches. Note that even if you do, those commits won't make it into
the Git repos - so it's not really a good idea to try :-)

2. The project has been moved over to a Git repo under Gerrit
(https://gerrit.asterisk.org). You can clone the project using the
instructions on the 'asterisk' repo project page:
https://gerrit.asterisk.org/#/admin/projects/asterisk  Thanks goes to
George Joseph for quickly getting a .gitignore/.gitreview file up for
review and included in the repo.

3. Mirrors for the project have been set up on git.asterisk.org and
Github. These mirrors are particularly useful for providing source
browsing of the repo.

4. A patch has been put up against 'master' to rework the source file
version macros. By rework, I mostly mean remove, although the macro
itself could not be fully removed due to other features relying on the
file name being registered. See https://gerrit.asterisk.org/#/c/54/
for more details.

So what are some immediate next steps?

1. We need to determine the best way to handle maintaining the long
running branches. While rebasing is appropriate for topic branches
(team branches) that closely track a mainline branch, the mainline
branches are a bit different. They not only don't have ever commit
merged into them (either going 'up' from 11 = 13 = master or 'down'
from master = 13 = 11), but patches are highly likely to merge
cleanly. ABI issues in 11/13 are a bigger concern than those in
master; APIs will have changed; etc.

As a result, my initial plan was to have developers cherry-pick to the
mainline branches as appropriate, with the initial commit being done
to 'master'. There are some downsides to this approach:
  a) Each cherry-pick has to be reviewed. This can make it difficult
to track the reviews, as each review is completely separate from the
others.
  b) Cherry-picks through the Gerrit UI will not always work. Folks
will need to be careful when cherry-picking back to a branch that
requires fixing merge conflicts, as getting the Change ID correct in
such a case is important to keep all of the Gerrit reviews tied
together.
  c) We'll be changing our process from merging 'up' branches to
'down' branches. Change is scary.

I think we're going to need some time to work through the implications
of how we handle the mainline branches. I suggest hanging out in
#asterisk-dev over the next few days as we work through the details.
In the meantime, I've restored the TEST-Asterisk repo so folks can
play around with the cherry-picking, and/or other models of branch
maintenance. I certainly welcome any suggestions on the best way to
make the process work.

2. Russell noted in George's .gitreview/.gitignore review
(https://gerrit.asterisk.org/#/c/42/) that we may want to include the
fullname of contributors/users along with their e-mail address. I
think that's a good idea, but that would mean updating our commit
message template, script, and our process. Comments/suggestions
welcome here on that proposal.

3. The 'make update' Makefile target needs to be updated. If you have
some Makefile-foo and git-foo and would like to look at that, that'd
be awesome.

Over the next few days, I'll be updating the Asterisk wiki pages with
more information. I'll reply to this thread as that happens. If you
have any questions, please don't hesitate to reply here or jump in
#asterisk-dev.

Thanks!

Matt

-- 
Matthew Jordan
Digium, Inc. | Director of Technology
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] Git Migration update

[Matthew Jordan]

On Sat, Apr 11, 2015 at 11:15 PM, Matthew Jordan mjor...@digium.com wrote:


 1. We need to determine the best way to handle maintaining the long
 running branches. While rebasing is appropriate for topic branches
 (team branches) that closely track a mainline branch, the mainline
 branches are a bit different. They not only don't have ever commit
 merged into them (either going 'up' from 11 = 13 = master or 'down'
 from master = 13 = 11), but patches are highly likely to merge
 cleanly. ABI issues in 11/13 are a bigger concern than those in
 master; APIs will have changed; etc.

Ugh. This is what I get for writing this at 23:15.

The gist of this paragraph is: I don't think 'git merge' will work
well on mainline branches, regardless of the order in which we merge.
I suspect we're going to want to cherry-pick.

-- 
Matthew Jordan
Digium, Inc. | Director of Technology
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 is moving to Git (next week)

[Matthew Jordan]

Hey all -

Since there hasn't been much feedback on the TEST-Asterisk repo that
is currently in gerrit [1] [2], I'm going to take that as a sign that
all is well and start the migration of Asterisk to Git next week.
We've already summarized some of the steps that will need to happen
for this to conclude [3]; expect to start seeing that happen early
next week.

The largest implication of this is that on Monday, April 13th, commit
access to the SVN repos will be disabled. Since we'll have most things
ready to go, I don't expect there to be much more than a day of
downtime as we push the branches up to Gerrit, but things could always
go sideways. In any case, patience with the process will be
appreciated :-)

If there's anything you'd like to help out with, please jump in
#asterisk-dev on Monday so we can coordinate effectively between
everyone.

Thanks!

Matt

[1] http://lists.digium.com/pipermail/asterisk-dev/2015-April/074129.html
[2] https://gerrit.asterisk.org/#/admin/projects/TEST-Asterisk
[3] http://lists.digium.com/pipermail/asterisk-dev/2015-March/074026.html

-- 
Matthew Jordan
Digium, Inc. | Director of Technology
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