Re: [asterisk-dev] AstriCon 2024: February 15th, 2024 - Fort Lauderdale, Florida

[Jared Smith]

On Tue, Sep 5, 2023 at 10:06 AM Joshua C. Colp  wrote:

> The 25th anniversary of Asterisk is upon us! We’ll be celebrating it at
> AstriCon 2024 held on February 15th, 2024 in Fort Lauderdale, Florida as
> part of IT Expo. We’d love it if you would join us. You can register
> here[1], and if you would like to speak you can submit a speaking proposal
> by October 14th here[2]. I look forward to seeing many of you there!
>

Thanks for sharing this, Josh.  Has there been any consideration of not
doing AstriDevCon (and AstriCon itself) around Valentines Day?  I imagine
I'm not the only one who would prefer not to travel that week to help
ensure domestic tranquility.

-Jared
-- 
_
-- 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] Stir Shaken

[Jared Smith]

On Sun, Jun 27, 2021 at 1:43 PM Dovid Bender  wrote:

> I am as equally confused. They sent me a list of questions including what
> IP's we would be connecting from. Has anyone gotten anywhere with them?
>

This is typically just a security thing on the part of the PA or CA, as
they'd like to limit your credentials to only work when coming from your
network, when you interact with their APIs or web portals.  This has
nothing to do with the actual mechanics of STIR/SHAKEN.

-Jared
-- 
_
-- 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] Stir Shaken

[Jared Smith]

On Thu, Jun 24, 2021 at 4:04 AM John T. Bittner  wrote:

> As a voip provider we are in the process of getting our own token and cert.
>
> We got our OCN and did all the other FCC requirements.
>
> We are at the point of working with iconectiv to get our token.
>
> Based on the info we have after we get the token we go to neustar to get
> our cert.
>

That all seems correct.


>
>
> Iconectiv are asking a lot of questions on how we are going to get certs
> out of there api’s ? This is confusing me, I was under impression that we
> get the cert from neustar.
>

iConectiv is the Policy Administrator -- they don't give you the actual
cert, but they do certify that you've got your OCN and are authorized to
get a cert, etc.  Neustar is one of the Certificate Authorities that is
authorized to give out Stir/Shaken certs.


> I have spent hours reading many things about stir shaken and a lot of it
> is contradicting. I also can’t find anything on the asterisk setup were we
> would even configure api information to connect to iconectiv.
>

You don't do this from within Asterisk -- you'd have to do this outside of
Asterisk, and the configure Asterisk for the cert that you get from Neustar.


> Our SBC’s are asterisk based so we would like to implement this directly
> on these servers.
>
>
>
> Do I need middleman software to get this to work.
>

Yes -- Asterisk doesn't handle this directly, at least at this point.
Please be aware that you'll likely need to interact with the APIs from both
the PA and the CA (iConectiv and Neustar, in your case).


>
> Last question…  We do a lot of call forwarding and passthrough caller id.
>
> Is there any method to allow this with Stir Shaken ?
>

You can -- but it's complicated, depending on your relationship with the
customers and numbers you're forwarding.  The major point of Stir/Shaken is
that the recipient of a call can know that the caller ID on the call
actually belongs to someone authorized to use that number.  If you as a
middleman know that the number presented belongs to your customer, then you
can give them an "A" level attestation.  If you know the customer but not
that they're authorized to use that particular number, you can give the
calls a "B" level attestation.  If you don't know the customer or the
number, you give them a "C" level attestation.

--
Jared Smith
-- 
_
-- 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] Video IVR

[Jared Smith]

On Mon, Dec 21, 2020 at 4:36 AM Abhay Gupta  wrote:

> Now that video over LTE is supported by majority of mobile providers do we
> have a plan to enable video in Playback , Record and ARI applications so
> that we have a video IVR (Interactive video response ) ?
>
> Or do we have a way where this functionality can be achieved .
>

At least in theory, Playback() should already support video.  I remember
doing some testing with this many many years ago -- it's probably been at
least 10 years ago now.  Just remember that Asterisk doesn't do any video
transcoding, so you have to use a video format that both Asterisk and the
endpoints support natively.

All that being said, I don't think much effort has been put into video IVR
support over the years, so your experience might be different than mine.

-Jared
-- 
_
-- 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] Module Deprecation, Default Not Building, and Removal

[Jared Smith]

On Mon, Nov 9, 2020 at 8:24 AM Joshua C. Colp  wrote:

> Since this is the first real time formalizing this once all the things are
> in place (process documented on wiki, deprecation list created from
> existing state of things) I'll likely send out an email to -users and also
> post on the community forums so people are aware.
>

This sounds great to me.

-Jared
-- 
_
-- 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] Module Deprecation, Default Not Building, and Removal

[Jared Smith]

On Tue, Oct 6, 2020 at 2:23 PM Joshua C. Colp  wrote:

> As a packager and someone who has been in the community and user world,
> what's your opinion and thoughts on the 2 year strategy?
>

I'm fine with it... for faster-moving distributions (such as Fedora), users
are used to following new releases closely, and fast rate of change with
regards to changes in those major releases.  For slower-moving
distributions (CentOS/RHEL/etc.), people tend to stick with LTS releases,
but understand that there are typically bigger (less granular) changes
between LTS releases than there are between regular releases.

-Jared
-- 
_
-- 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] Module Deprecation, Default Not Building, and Removal

[Jared Smith]

On Fri, Oct 2, 2020 at 11:50 AM Dan Jenkins  wrote:

> sorry, I thought I was agreeing with you :) we need to engage package
> maintainers to potentially help ease the shift - if packages are a
> thing but as far as I'm concerned most package managers have out of
> date versions of Asterisk, or don't have things you want so you end up
> building from source anyway
>

I actively package Asterisk for Fedora and EPEL (CentOS/RHEL), and I work
hard to package the latest versions as they are released.  I'm always open
to additional input on how to make my packages more relevant for consumers
-- either by packaging additional modules, or by having better
sub-packages.  For example, my packages already have chan_sip and pjsip
split off as separate subpackages.

-Jared
-- 
_
-- 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] Module Deprecation, Default Not Building, and Removal

[Jared Smith]

On Thu, Oct 1, 2020 at 10:04 AM Joshua C. Colp  wrote:

> Not really, and I think part of the problem is that this entire thing
> hasn't really been documented, communicated, or been a strict part of the
> release or development process. It's been more organic. Going forward it
> would be explicitly part of the steps when cutting the new branch, for
> example, and part of the announcement.
>

OK, thanks for the clarification.  Consider me in favor of the process as
you outlined it, and also in favor of a more aggressive stance on
deprecation of modules that obviously aren't being heavily used/maintained.

-Jared
-- 
_
-- 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] Module Deprecation, Default Not Building, and Removal

[Jared Smith]

On Thu, Oct 1, 2020 at 9:20 AM Joshua C. Colp  wrote:

> 1. All the changes listed below initially occur in standard releases - in
> my opinion beginning the process to remove a module is a big thing and we
> should gradually introduce it, gaining feedback from those who run standard
> releases first.
> 2. The first step is marking a module as deprecated and occurs for 1
> standard release and 1 LTS release
> 3. The second step is marking a module as defaultenabled no which means it
> will not be built by default. This occurs for 1 standard release and 1 LTS
> release
> 4. The third step is removing the module
> 5. There will be a wiki page to keep track of all modules which are in the
> process of being removed
> 6. When a new LTS branch is created the master branch becomes eligible
> again for changing the state of modules, a reminder can be done as part of
> cutting the LTS branch
>
> Thoughts?
>

I'm fine with the process you propose -- it's roughly the same process
we've discussed each year at AstriDevCon for the past several years.  But
in addition to the process, I think we actually need follow-through as
well.  I feel (for better or for worse) that most Asterisk developers have
been in agreement on the process for years now, but little actual work to
deprecate modules (other the obvious chan_sip and "deprecate the dialplan"
discussions) has been done.

Other than the chan_sip changes, have any other modules been marked as
deprecated, or set to "defaultenabled no"?  Maybe there is a bunch and I've
just missed them...

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

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

Re: [asterisk-dev] Proposal for New Major Version Process Change

[Jared Smith]

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

> 1. It leaves a confusing area for developers where we have to ask "should
> this go into 18.0?"
> 2. It confuses users because if they upgrade to 18.0.0 then it is likely
> the other current releases have bug fixes they don't have, which has caused
> issues for users in the past.
>

I agree with these two points of confusion.

What do people think? Do we believe that a month out is ample enough?
> <http://lists.digium.com/mailman/listinfo/asterisk-dev>


I think somewhere between four and six weeks is more than adequate, given
the maturity of the project.

--
Jared Smith
-- 
_
-- 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_MEDIA_OFFER

[Jared Smith]

On Wed, Jun 24, 2020 at 12:08 PM Kevin Harwell  wrote:

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

That has always been my expectation -- that PJSIP_MEDIA_OFFER completely
overrides the configured codecs -- but that may be a misunderstanding on my
part.  That being said, I can't think of a reason why it wasn't coded that
way.

--
Jared Smith
-- 
_
-- 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 and CentOS 8

[Jared Smith]

On Thu, Oct 17, 2019 at 12:19 PM George Joseph  wrote:

> At the current time, we do not recommend attempting to build Asterisk on
> CentOS 8.  Many packages Asterisk uses are not yet available and would
> require building from their sources.  The Asterisk packages are also not
> available in the EPEL 8 or CentOS 8 repositories yet for the same reason.
>

In my personal time, I've been working on getting my Asterisk 16 package in
Fedora and EPEL (for CentOS/RHEL) ready for EPEL7 and EPEL8.  Since many of
the dependencies aren't yet there, I've built my own little personal repo
at https://copr.fedorainfracloud.org/coprs/jsmith/Asterisk16/ which has
Asterisk 16.6.1 packages (and the missing dependencies) for both EPEL7 and
EPEL8.   (Please note that these are my own personal packages, and not
endorsed or sponsored by my employer.)

These are mostly untested, but please give them a shot and give me
feedback.  Over the next few weeks, I'll try to get these packages pushed
into EPEL proper.

--
Jared Smith
-- 
_
-- 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 16.x / pjsip TLS] Memory leak with core reload

[Jared Smith]

On Thu, Oct 3, 2019 at 10:01 AM Sean Bright  wrote:

> In the future, please feel free to skip the mailing list and submit
> issues directly to https://issues.asterisk.org/jira for any Asterisk
> problems.
>
> FreePBX issues like this one can go directly to their issue tracking
> system (I don't know the URL for that off-hand).
>

The FreePBX issue tracker is at https://issues.freepbx.org

-Jared
-- 
_
-- 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] Unable to compile asterisk12 with MALLOC_DEBUG

[Jared Smith]

You do realize that Asterisk 12.x is past it's End of Life, and is no
longer receiving security updates or bug fixes, right?  You should try with
the latest 13.x or 16.x release.

-Jared

On Sat, May 25, 2019 at 3:34 PM bala murugan  wrote:

> Hi  ,
>
> I am trying to compile asterisk12 with MALLOC_DEBUG , it always fails with
> below
>
> ael.flex: In function 'ael_yyfree':
>
> ael.flex:667: error: lvalue required as left operand of assignment
>
>
>
> ast_expr2.fl: In function 'ast_yyfree':
>
> ast_expr2.fl:255: error: lvalue required as left operand of assignment
>
>[CC] astfd.c -> astfd.o
>
> make[1]: *** [ast_expr2f.o] Error 1
>
> make[1]: *** Waiting for unfinished jobs
>
>
> how to fix this and compile with MALLOC_DEBUG successfully .
>
>
> thanks,
>
> bala
> --
> _
> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
>
> asterisk-dev mailing list
> To UNSUBSCRIBE or update options visit:
>http://lists.digium.com/mailman/listinfo/asterisk-dev
-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

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

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

[Jared Smith]

On Fri, Dec 14, 2018 at 12:34 PM Kevin Harwell  wrote:

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


I don't pretend to be either, but in other REST-like systems I've typically
used POST to create an object, PUT to update a complete object, PATCH to
update just one portion of an object, and DELETE to delete an object.

-Jared
-- 
_
-- 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] The "Busy" App.... isn't.

[Jared Smith]

On Wed, Apr 4, 2018 at 7:17 PM, Richard Mudgett  wrote:

> The argument is used when the channel is already answered.  The channel
> will then send
> the busy tone inband for the specified number of seconds and hangup.  The
> behavior also
> depends upon the channel driver.
>
> exten = _X.,1,NoOp()
> same = n,Answer()
> same = n,Busy(15)
> same = n,Hangup()
>

My understand is, at least for some channel drivers/technologies, that it
should also work when the channel is *not* answered, because answering the
call can mess up your CDR records.  My guess is that's what Steve is trying
to accomplish here... signal that the "line" is busy and can't be answered,
without actually answering the call.

-Jared
-- 
_
-- 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] RPM Repository for Asterisk/Kamailio

[Jared Smith]

On Thu, Nov 16, 2017 at 4:18 PM, Nir Simionovich <nir.simionov...@gmail.com>
wrote:

>   As part of our work, we've noticed that Asterisk doesn't have an updated
> RPM repo, and that the RPM repo for Kamailio is - how shall we put it, not
> providing all the possible modules.
>

As one of the maintainers of the Asterisk and dahdi-tools packages in
Fedora and EPEL and a long time RPM packaging fanatic, I'd really like to
collaborate together on the spec files you're using.

--
Jared Smith
-- 
_
-- 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] Attn: pjproject packagers

[Jared Smith]

On Tue, Feb 23, 2016 at 6:44 PM, George Joseph <george.jos...@fairview5.com>
wrote:

> Which brings me to a question...  Are you guys OK with packaging pjproject
> for server use instead of it's intended client app use?
>


I am, and I'm pushing an updated pjproject RPM to Fedora Rawhide now.  Once
it's got a little more testing, I'll push updates back to earlier releases
and to EPEL.

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

[Jared Smith]

On Tue, Jan 19, 2016 at 1:04 PM, George Joseph <george.jos...@fairview5.com>
wrote:

> If we don't static link, we'll never know what's going on.



I'm going to push back on this as well.  Short of going the route of static
linking, what can we do to improve the current situation with dynamic
linking?  Thoughts?  Ideas?  Improved testing?  More robust code?

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

[Jared Smith]

On Tue, Jan 19, 2016 at 9:30 AM, George Joseph <george.jos...@fairview5.com>
wrote:

> ​I understand the packaging issue and I'd like to hear from packagers like
> Jared Smith.


Not sure what to say here -- bundling pjproject with Asterisk causes me a
world of hurt from a packaging standpoint.  Having them as separate
projects makes my job as a packager much much easier.


> We could simply require a specific version of Asterisk to be statically
> linked to a specific version of pjproject and let the packaging process
> insure it's there.  For rpms, a BuildRequires would do that.  There's be no
> runtime dependency after that.


And a "Requires:" would force that particular version to be present to
install the package -- but you're right -- it doesn't enforce it at *run
time*.


If there are things that I can do from a packaging standpoint to make
things easier (either on the pjproject side or the Asterisk side) of the
Fedora/RHEL/CentOS packages, please don't hesitate to reach out to me.
I've already made one change last week (that George asked me to make), and
I'd be happy to make more.  I just don't play with Asterisk and pjproject
every day like I once could, so I often miss out on the little nuances
these days :-/

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

[Jared Smith]

On Thu, Nov 19, 2015 at 9:24 PM, Leif Madsen <leif.mad...@avoxi.com> wrote:

> The way it works is that major versions of Asterisk (and same with other
> packages) are associated with specific releases of Fedora and RHEL, which
> means the major versions are "stuck" to those releases.



If it's easier, I'd be happy to setup some repositories for newer versions
of Asterisk on RHEL/CentOS 6 and RHEL/CentOS 7.

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

[Jared Smith]

On Thu, Nov 19, 2015 at 10:14 AM, Matthew Jordan <mjor...@digium.com> wrote:

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



At one point, there was an awful .spec file in the Asterisk sources...
hopefully it's not around any more.

That being said, I just took over as the main maintainer/contact for the
Asterisk packages in Fedora/EPEL -- It's one of the most complicated spec
files in Fedora, but that obviously hasn't scared me off.

I'd love feedback on things we can do to make those packages better, and
get a tighter feedback loop between the Asterisk development community and
the packagers in Fedora/RHEL/CentOS/etc.

--
Jared Smith

--
Jared Smith
-- 
_
-- 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] 4573: trunk: Can't touch this

[Jared Smith]

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


I don't think the ASCII art is very representative... Hammer pants have an 
shorter inseam that begins around the knees.

Also, the command contains no XML documentation.

- Jared Smith


On April 1, 2015, 3:59 p.m., Matt Jordan wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://reviewboard.asterisk.org/r/4573/
 ---
 
 (Updated April 1, 2015, 3:59 p.m.)
 
 
 Review request for Asterisk Developers.
 
 
 Repository: Asterisk
 
 
 Description
 ---
 
 This adds a much needed feature: glorious ASCII art of MC Hammer doing his 
 thing in full 1990's apparel.
 
 As a bonus, this will start a 'hammer time' on the channels in Asterisk.
 
 
 Diffs
 -
 
   /trunk/res/res_clihammertime.c PRE-CREATION 
 
 Diff: https://reviewboard.asterisk.org/r/4573/diff/
 
 
 Testing
 ---
 
 https://www.youtube.com/watch?v=otCpCn0l4Wo
 
 
 Thanks,
 
 Matt Jordan
 


-- 
_
-- 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] 4544: clang compiler warning: -Wself-assign

[Jared Smith]

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



/branches/13/formats/format_wav.c
https://reviewboard.asterisk.org/r/4544/#comment25527

Red blob...



/branches/13/formats/format_wav.c
https://reviewboard.asterisk.org/r/4544/#comment25529

Red blob here...



/branches/13/formats/format_wav_gsm.c
https://reviewboard.asterisk.org/r/4544/#comment25530

And here as well...


While most of my comments are about the coding standards, the meat of this 
patch is very straightforward, and shouldn't cause any problems.

- Jared Smith


On March 27, 2015, 12:02 p.m., Diederik de Groot wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://reviewboard.asterisk.org/r/4544/
 ---
 
 (Updated March 27, 2015, 12:02 p.m.)
 
 
 Review request for Asterisk Developers.
 
 
 Bugs: ASTERISK-24917
 https://issues.asterisk.org/jira/browse/ASTERISK-24917
 
 
 Repository: Asterisk
 
 
 Description
 ---
 
 clang's static analyzer will throw quite a number warnings / errors during 
 compilation, some of which can be very helpfull in finding corner-case bugs. 
 clang compiler warning:-Wself-assign
 
 
 Diffs
 -
 
   /branches/13/formats/format_wav_gsm.c 433444 
   /branches/13/formats/format_wav.c 433444 
 
 Diff: https://reviewboard.asterisk.org/r/4544/diff/
 
 
 Testing
 ---
 
 
 Thanks,
 
 Diederik de Groot
 


-- 
_
-- 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] AstriDevCon 2014: Agenda item Deprecate AMI/AGI (Ben Klang)

[Jared Smith]

On Wed, Oct 29, 2014 at 12:31 PM, Paul Albrecht palbre...@glccom.com
wrote:

 None of said “discussion” ever happened on the lists nor was the broader
 Asterisk community involved as far as I can determine. A parallel
 “discussion” was started by a shill at AstiCon this year to begin to get
 the “vast unwashed” onboard with ARI/Stasis, that is, so that Matt could
 come back from AstiCon claiming that the broader Asterisk community is in
 agreement that ARI/Stasis is the future of Asterisk and that the dial plan
 can be deprecated.



I'm not going to take the time to comment on every trivial detail here, but
I'd be remiss if I didn't highight a few things.  First, Asterisk
development (including ARI) happened in the open.  It's been discussed at
the Asterisk Developer Conferences, on the mailing lists, etc. While some
people have suggested that they'd like to move completely to ARI, I
personally don't think that we'll see a complete move away from the
dialplan anytime in the next ten years.  That being said, I'm glad that the
people who *want* to move away from the dialplan are more easily able to do
so now.  Part of that stems from the fact that Asterisk has traditionally
been a PBX, and is now moving to also be a media engine.  For some of my
own personal projects, I'll probably never move away from the dialplan.
For others, the dialplan is something I can live without.  While the
majority of the people in the room at AstriDevCon were in agreement that
ARI/Stasis *is* part of the future of Asterisk, I don't think there was
anywhere close to a majority that thought the dial plan can be deprecated.

Second, let me state that attacking the people in this channel doesn't help
your case -- let's keep things civil here and debate *what* is right, not
*who is right*.  By using inflammatory language, you're just making other
developers in this channel *less* likely to take you seriously, not more
likely.  I'd personally never want this channel to just become an echo
chamber, but it does need to be safe space where people feel like they can
share their opinions and ideas.  If people feel threatened or belittled,
they're much more likely to be hostile to your opinions or ideas.

--
Jared Smith
-- 
_
-- 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] Queue discussion at Astricon

[Jared Smith]

On Fri, Oct 17, 2014 at 9:44 AM, Matthew Jordan mjor...@digium.com wrote:

 I'd love to discuss how things have been going. Maybe after AstriDevCon?



I'd love to discuss things as well, but will only be around on Tuesday,
before I have to fly off for more conferences.  I like the idea of getting
a group together after AstriDevCon on Tuesday.

-Jared
-- 
_
-- 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] 3540: chan_local+app_dial: Propagagate call answered elsewhere over local channels.

[Jared Smith]

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

Ship it!


Looks simple and straightforward to me.

- Jared Smith


On May 14, 2014, 3:19 p.m., wdoekes wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://reviewboard.asterisk.org/r/3540/
 ---
 
 (Updated May 14, 2014, 3:19 p.m.)
 
 
 Review request for Asterisk Developers.
 
 
 Repository: Asterisk
 
 
 Description
 ---
 
 When dialing SIP/account_a + SIP/account_b, and account_b picks up, chan_sip 
 sends
 out a Reason header with SIP;cause=200;text=Call completed elsewhere, 
 signifying
 that the call was picked up.
 
 The SIP phone then does not show 1 missed call.
 
 However, then dialing Local/account_a + Local/account_b, this does not work.
 
 This review addresses that.
 
 
 When hanging up obsolete channels in chan_local, the answered_elsewhere flag 
 is
 propagated to cancelled (parent) channel using the hangupcause.
 
 In app_dial, this hangupcause is checked and passed down to the other calls 
 to be
 cancelled.
 
 
 Diffs
 -
 
   /branches/1.8/channels/chan_local.c 413892 
   /branches/1.8/apps/app_dial.c 413892 
 
 Diff: https://reviewboard.asterisk.org/r/3540/diff/
 
 
 Testing
 ---
 
 Dialplan:
 
 [default]
 exten = 201,1,Dial(SIP/account_bSIP/account_c,5)
 exten = 202,1,Dial(Local/b@dialLocal/c@dial,5)
 ;; also tested with /n for no-local-channel-optimization, behaves the 
 same as without
 
 [dial]
 exten = b,1,Dial(SIP/account_b)
 exten = c,1,Dial(SIP/account_c)
 
 sip.conf held 3 accounts: account_a, account_b and account_c.
 
 
 Before patch:
 
   201 202 -- account_a calls these
   +---+---+
 timeout   | 1 missed call | 1 missed call |
   +---+---+ 
 account_b |   | 1 missed call | -- account_c sees these
 picks up  +---+---+ 
 
 
 After patch:
 
   201 202 -- account_a calls these
   +---+---+
 timeout   | 1 missed call | 1 missed call |
   +---+---+ 
 account_b |   |   | -- account_c sees these
 picks up  +---+---+ 
 
 
 Thanks,
 
 wdoekes
 


-- 
_
-- 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] Dundi library

[Jared Smith]

On Tue, Apr 15, 2014 at 8:08 AM, Matthew Jordan mjor...@digium.com wrote:

 I was curious if anyone would reply with a heretofore unknown Dundi
 library; alas, that appears to not be the case. I'm not aware of any
 Dundi library myself.


Great timing... a co-worker of mine just started a DUNDi library in Perl.
More details at https://github.com/heytensai/dundi and on his blog post at
https://www.zmonkey.org/blog/content/perl-dundi-library.

--
Jared Smith
-- 
_
-- 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] 1164: [patch] Improve debug of ast_hangup

[Jared Smith]

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


Looks fine to me at first glance.  

- Jared Smith


On April 11, 2014, 3 p.m., Olle E Johansson wrote:
 
 ---
 This is an automatically generated e-mail. To reply, visit:
 https://reviewboard.asterisk.org/r/1164/
 ---
 
 (Updated April 11, 2014, 3 p.m.)
 
 
 Review request for Asterisk Developers.
 
 
 Bugs: 19080
 https://issues.asterisk.org/jira/browse/19080
 
 
 Repository: Asterisk
 
 
 Description
 ---
 
 In many cases when I develop crazy code, I get weird hangups. It may only 
 happen to me, but it does happen. I need to know when a hangup process is 
 initiated and by whom. This small patch is a first step towards that goal.
 
 
 Diffs
 -
 
   /trunk/main/channel.c 313005 
   /trunk/include/asterisk/channel.h 313005 
 
 Diff: https://reviewboard.asterisk.org/r/1164/diff/
 
 
 Testing
 ---
 
 Tested in various versions of Asterisk. Seems to give me the output I need.
 
 
 Thanks,
 
 Olle E Johansson
 


-- 
_
-- 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] 3343: res_pjsip: Enable DNS support.

[Jared Smith]

On Thu, Mar 13, 2014 at 3:34 PM, Olle E Johansson
reviewbo...@asterisk.orgwrote:

 For every poorly designed bad feature I can think of I can find a large 
 number of Asterisk users that want it. It's simply not a good argument. We 
 create this software and need some sort of architecture when we do.

 I think you're being a bit extreme here, Olle, and your email sounds (at
least to my ears) as being quite demanding. You could use this same
argument to shoot down *any* new feature or code.  I know you're still
focusing on Asterisk 1.8 and taking care of your paying customers (at least
the last time we talked), but from my vantage point the whole reason we're
going to down the road of pjsip and a new SIP channel driver is to have a
better architecture, and these DNS changes are one part of a whole series
of changes specifically designed to improve the architecture.  What have
the entire Asterisk 12 and 13 development cycles been about if not for
improving our architecture?

 The current DNSmanager is broken in so many ways I can't even begin to 
 describe it and it is not asynch, asterisk still stops if we're not getting 
 an answer.

 I agree one hundred percent.  That's why it surprises me that you're
coming out so vehemently about an improvement -- any improvement -- to the
way we handle DNS.  Now I agree that it's not ideal to have two different
ways to resolve DNS in different parts of Asterisk -- but that being said,
I think *any* improvement is a step in the right direction.  Adding this
code to pjsip doesn't make chan_sip any worse.


 So why don't we continue down this path and include a full blown SIP proxy in 
 chan_pjsip, and a HTTP server in chan_pjsip and much more. Let's add a b2bua 
 to chan_pjsip while we're at it... ;-)


Now you're just being silly... we're not throwing a SIP proxy or a web
server into chan_pjsip.  We're simply trying to improve the way it handles
DNS.  As you have pointed out, DNS is a cruicial part of any SIP
architecture, which is why I'd like to see some improvements in the way
chan_pjsip handles DNS.  Is it perfect?  No.  Is it better than what we
have today?  I think so.  Am I personally willing to wait for perfect
before I start using chan_pjsip?  Nope...


 Even if it can ba done easily, doesn't mean it's right. We do need to manage 
 our product. Adding the ability to configure a different set of DNS servers 
 for a module or even a full server application is a bad thing. That's the 
 first part we should not do. After that, we need to fix our DNS architecture.

 OK, I can't speak about managing a product, because this not a product
to me.  It's a tool that I happen to use.  I leave it to others to
productize it.  On this mailing list, however, I feel we should focus on
development of Asterisk as a toolset, and leave product discussions for
other venues.

If you have suggestions on how to fix our DNS architecture as you say, in
a way that is not only asynchronous, respects TTL (and refreshes results
again once the TTLs have expired), handle SRV records correctly (including
sorting), and solve the happy eyeballs/earballs problems, I'd love to see
the code get incorporated into Asterisk.  In the meantime, the proposal in
front of us seems to be a step closer than what we have today.  It may not
be perfect, but I think there are more serious sins than allowing an end
user to shoot themselves in the foot.  (We already give them plenty of
firearms and ammunition with the wide range of configuration options and
files and modules available today.)

--
Jared Smith
-- 
_
-- 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] CentOS packaging

[Jared Smith]

On Fri, Feb 28, 2014 at 1:09 AM, Tzafrir Cohen tzafrir.co...@xorcom.comwrote:

 Nothing wrong with embedded libraries if the system libraries can be
 used instead (preferably: by default). This is the case with editline
 as of asterisk 11. The system copy of libedit can be used now.


Now if I could just get a patch to have pjproject use the system version of
ilbc instead of the bundled copy, I'd be a happy man.

--
Jared Smith
-- 
_
-- 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] CentOS packaging

[Jared Smith]

On Fri, Feb 28, 2014 at 2:22 PM, Jeffrey Ollie j...@ocjtech.us wrote:

 Yep, it's only a question of someone having the time to do the work,
 which hasn't been me.


Well, I made some time today.  And I've made pretty good progress.   As
always, you can follow along at
https://bugzilla.redhat.com/show_bug.cgi?id=728302, but I've got pjproject
2.2 packaged up and in fairly good shape.  I still need a patch to use the
system copy of ilbc instead of the bundled version, but other than that, I
think we have something that could be approved for Fedora and EPEL.

--
Jared Smith
-- 
_
-- 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] CentOS packaging

[Jared Smith]

On Wed, Feb 26, 2014 at 3:51 PM, Tzafrir Cohen tzafrir.co...@xorcom.comwrote:

 This is funny. In 11 pjproject is bundled (though patching it out is not
 an issue). In 12 it is not included in the tree anymore.


I know, and the humor isn't lost on me. :-)  That being said, I'm hoping to
get the Asterisk fork of pjproject packaged up in Fedora/EPEL shortly, so
that we can begin getting Asterisk 12 packaged.

--
Jared Smith
-- 
_
-- 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] CentOS packaging

[Jared Smith]

On Thu, Feb 27, 2014 at 12:26 PM, Matthew Jordan mjor...@digium.com wrote:

 If the packages were restructured, it could be set up so that Asterisk
 only provides chan_dahdi in a subpackage - although there are
 obviously some issues with subpackages as well. I'm still not sure of
 a good structure for subpackages that lets you pick optional modules
 in an 'ala carte' fashion. For example, I may want chan_dahdi, but I
 may also want PostgreSQL for realtime, IMAP voicemail, and
 chan_ooh323. (The answer is probably 'build from source', but the fact
 that each subpackage has to be independent from others limits their
 usefulness, in my opinion)


The way we've done this in Fedora is to build these sorts of pieces as
subpackages, and tweak the build process to build multiple versions of some
of the packages -- for example, we have asterisk-voicemail-plain,
asterisk-voicemail-odbc, and asterisk-voicemail-imap.  You can choose any
one of those three subpackages (as they each conflict with the other two).

The complete list of subpackages we currently build is below.  (For the
sake of this conversation, chan_dahdi is built as a subpackage as well.)

asterisk-alsa
asterisk-calendar
asterisk-corosync
asterisk-curl
asterisk-dahdi
asterisk-devel
asterisk-fax
asterisk-festival
asterisk-ices
asterisk-jabber
asterisk-jack
asterisk-ldap
asterisk-ldap-389
asterisk-lua
asterisk-minivm
asterisk-misdn
asterisk-mobile
asterisk-mysql
asterisk-odbc
asterisk-ooh323
asterisk-oss
asterisk-portaudio
asterisk-postgresql
asterisk-radius
asterisk-skinny
asterisk-snmp
asterisk-sqlite
asterisk-tds
asterisk-unistim
asterisk-voicemail
asterisk-voicemail-imap
asterisk-voicemail-odbc
asterisk-voicemail-plain

--
Jared Smith
-- 
_
-- 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] CentOS packaging

[Jared Smith]

On Thu, Feb 27, 2014 at 12:56 PM, Matthew Jordan mjor...@digium.com wrote:

 (1) I fully appreciate the annoyance of having embedded libraries in
 Asterisk. While some of those embedded libraries may be difficult to
 extract, some - most likely - could be removed at this point. I would
 love to see patches proposed for Asterisk that removed some of the
 external libraries (editline and mxml are two that come readily to
 mind).


I'm pretty sure we either had or have a patch in Fedora for editline...
I'll look at it a bit later.



 (2) The policy of any distribution is, and should be, set by that
 distribution. If a distribution has a policy that precludes it from
 including packages of Asterisk, I fully respect that. At the same
 time, that does not mean that said policy - even when it is well
 intentioned - will always make the most sense either for the Asterisk
 project or for projects that Asterisk depends on.


I agree wholeheartedly.  It's discussions like these that help us make the
most of the situation when the policies intersect.


 That being said, I have a very difficult time understanding how
 Asterisk 11 can have packages for Fedora but Asterisk 12 cannot.


It's not that Asterisk 12 cannot be packaged for Fedora -- it's that nobody
has done it yet, due to the work of trying to get dependencies like
pjproject packaged up and approved.


Due to the demands of certain members of the Asterisk community [1],
 we spent a considerable amount of effort removing pjproject from
 Asterisk 12. This was a good thing to do: it made the Asterisk build
 system cleaner and resulted in numerous improvements to pjproject that
 have been included in the up stream distribution [2]. Today, we have a
 version of Asterisk that contains fewer embedded libraries, as well as
 a version of pjproject that can be made into packages (even if those
 packages are not suitable for some Linux distributions).


This is definitely a good thing, and if I haven't said it loudly enough
already, thank you very much.  It makes a huge difference.


 Despite this, the decision was made that Asterisk 12 was unsuitable
 for packaging in the Fedora distribution, due to it using (but not
 strictly depending on) pjproject.


Again, I don't think anybody in Fedora (at least that I know of) is
rejecting Asterisk 12 -- we simply need to either package Asterisk 12 up
without pjproject (option 1), or get pjproject packaged up (without it's
third_party directory) appropriately (option 2), and then get Asterisk 12
into Fedora.  I'm trying to find time to work on option 2.  If anybody on
the list wants to help out, you can follow along at
https://bugzilla.redhat.com/show_bug.cgi?id=728302.

--
Jared Smith
-- 
_
-- 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] CentOS packaging

[Jared Smith]

On Tue, Feb 25, 2014 at 2:03 PM, Ben Langfeld b...@langfeld.co.uk wrote:

 After a conversation with Rusty last week, I've become aware that for a
 simple installation of asterisk (11) from the CentOS repositories at
 http://packages.asterisk.org/centos/, the 'current' repo at
 http://packages.digium.com/centos is required to satisfy the dependency
 of the 'asterisk' package on 'asterisk-dahdi'.


Yeah, it's rather unfortunate.  Frankly, though, I think the Asterisk
packages from the EPEL repository (based on the Fedora packages) are a much
better place to start.  I'd love to help with getting better Asterisk
packages available for RPM-based systems, and am willing to put some of my
limited spare time into improving the situation.  (I'd love to help for
dpkg-based systems as well, but I don't know enough about dpkg to code
myself out of a wet paper bag.)

--
Jared Smith
-- 
_
-- 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] measure call quality for performance test

[Jared Smith]

On Mon, 2008-01-28 at 14:41 -0500, Di-Shi Sun wrote:
 We plan to do the performace test again with bi-direction media
 stream. Somebody mention to us that we should measure the call
 quality. Does anybody have ideas about how to do it? Does Asterisk
 provide any support for it?

You may want to go look up RTCP and start looking to see if your
endpoints will send RTCP reports.  I've found this is a first good step
in monitoring call quality.

-- 
Jared Smith
Community Relations Manager
Digium, Inc.


___
--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] Unstable releases lately

[Jared Smith]

On Mon, 2008-01-14 at 08:35 -0500, David Boyd wrote:
 Maybe Digium doesn't care if they lose community support as they have been
 successful in bringing in investment that will carry them forward as they
 deploy more commercial product

Absolutely not.  Digium cares *very deeply* about the open-source
community, and realizes that without the community it wouldn't be
anywhere as successful as it is today.  Russell Bryant leads the
Asterisk development team at Digium, and has about a dozen developers
working for him.  Those dozen or so developers spend almost 100% of
their time working on the open-source version of Asterisk.  Over 90% of
their time is currently spent on bug tracker fixing bugs and handling
the feature requests (or at least the ones that come with code
attached).  There are some more statistics available in the mailing list
archives [1] on the exact nature of the work the development team has
been doing, if you want the nitty-gritty details.

In addition to that, Digium extends a lot of resources to the community
besides just the development team.  There's infrastructure (mailing
lists, forums, and SVN repositories just to name a few), as well as a
lot of adjunct services such as conferences, support for Asterisk users
groups, documentation, etc.  Obviously if Digium had unlimited resources
it could do a lot more... but as it is we're constrained by our current
resources in the number of things we can do.  At the same time, I think
you'd be hard-pressed to find any other company in the open source
telephony space that does more to help the community.

Obviously we're open to suggestions on how to improve the process, and
I'm 100% committed to making sure there's lots of open and honest dialog
between the community and Digium.  That's why I took this job in the
first place.  If you have questions or concerns, drop me an email and
I'll do what I can to help you.

[1]http://lists.digium.com/pipermail/asterisk-biz/2008-January/024819.html

-- 
Jared Smith
Community Relations Manager
Digium, Inc.


___
--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] Implementation of Broadsoft Sip Access in Asterisk to enable SLA for Sipura/Linksys

[Jared Smith]

On Wed, 2008-01-02 at 12:03 -0500, Eugene Grossi wrote:
 However some of my client phones (the Linksys SPA942s)are functioning as SLA
 stations using Subscribe/Notify according to Broadsoft Sip Access
 Extensions. The Specifications Are In Broadworks Sip Access Side Extensions
 Interface  Specifications -Release 13.0. I have attached it.

I'm glad that people are anxious to make Asterisk better, but we need to
make sure we do it in a responsible manner.  We want other people to
respect the licensing of Asterisk, so we need to respect the licensing
of other things as well.  In this case, the item that was sent to list
says it's confidential and can only be distributed under license.  I
hate to imagine the problems it might cause the Asterisk developers to
use it without proper permissions.

In short, the Boy Scout in me is saying Let's be careful and play by
the rules!

-- 
Jared Smith
Community Relations Manager
Digium, Inc.


___
--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] MeetMe DTMF menus

[Jared Smith]

On Wed, 2007-12-05 at 17:43 +, Tony Mountifield wrote:
 I was wondering what people's opinions
 would be on moving the volume options to a separate sub-menu: e.g.
 1 to mute/unmute, 2 to lock/unlock, 3 to eject, 4 to adjust volumes, etc.,
 and after pressing 4, offer 4, 6, 7, 9 and 8 (or perhaps *) for adjusting
 volume as presently.

Personally, I think it's a great idea -- you've got my vote.  But since
I'm not really one of the Asterisk developers, I'm not sure my opinion
counts for much.  

---
Jared Smith
Community Relations Manager
Digium, Inc.


___
--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] Tab-completion borked in trunk

[Jared Smith]

On Sun, 2007-10-14 at 10:59 -0700, John Todd wrote:
 Additionaly, it does cause some functionality problems in an obscure 
 way since I don't know of any way to get a full SIP channel name 
 other than via tab completion - other methods truncate the name (sip 
 show channels doesn't provide a full channel name, so I can't 
 cut/paste to sip show channel blah-320932 for debugging.)

It's not at all obvious, but the output of core show channels concise
may give you the information you're looking for.  At least, it's worked
for me in the past.


-- 
Jared Smith
Community Relations Manager
Digium, Inc.


___
--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] Thoughts on Asterisk release management

[Jared Smith]

On Thu, 2007-09-20 at 09:30 -0500, Power, Paul C. wrote:
 I would like to see some test harnesses exist to really wring out
 various aspects of atserisk code. I would do what I could to donate a
 machine to run regular testing.

I've offered to help coordinate such an effort (run by the community,
not by Digium developers), and have even secured a machine to run the
testing on.  What would be most useful is for people to start donating
*code* that tests various aspects of Asterisk.  I've already had several
people offer to send me some SIPP scripts for testing the SIP channel
driver, but so far nobody has followed through.

-Jared


___

Sign up now for AstriCon 2007!  September 25-28th.  http://www.astricon.net/ 

--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] Xorcom claims

[Jared Smith]

On Mon, 2007-08-06 at 14:36 -0400, Andrew Latham wrote:
 Just for everyone else out there, where does a person buy/get these
 cables or should we just make our own?

You can buy them from Digium.


-- 
Jared Smith
Community Relations Manager
Digium, Inc.


___
--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] AstriCon -- Last chance to speak!

[Jared Smith]

We're getting close to wrapping up the final list of speakers for
AstriCon, but wanted to give the Asterisk community one more chance to
speak up and be heard.  If you're interested in presenting at AstriCon,
please go to http://www.astricon.net/ and click on the Speak at
AstriCon link on the right-hand side of the page.

If you know of someone who we should invite to speak, we're open to
suggestions as well.  Feel free to email me (off the list, please!) with
your recommendations.

I'm looking forward to a great conference, and hope to see you all
there!


-- 
Jared Smith
Community Relations Manager
Digium, Inc.


___
--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 Missed Calls when calling SIP phones parallel

[Jared Smith]

On 6/21/07, Olle E Johansson [EMAIL PROTECTED] wrote:
 Yes, this is my code. But please check out the branch and try it out
 instead of sending
 out random patches. I've worked with Frank Sautter who has been
 helping me test
 this and I have implemented other changes since the code you send out.

For everyone else's benefit, I'll post the URL where people can either
look at the code:

http://svn.digium.com/view/asterisk/team/oej/cancel_answer_elsewhere/

or check it out from Subversion:

http://svn.digium.com/view/asterisk/team/oej/cancel_answer_elsewhere/

Please check it out and give feedback to Olle.

-Jared

___
--Bandwidth and Colocation provided by Easynews.com --

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

Re: [asterisk-dev] Docs converted to TeX?

[Jared Smith]

On 5/22/07, Philipp Kempgen [EMAIL PROTECTED] wrote:

Have you thought about using DocBook?
http://www.docbook.org/whatis


I've advocated using DocBook for quite a while, but it's always turned
into a my favorite is better than your favorite religious war.
Items I can add to the discussion are:

1) I have a lot of experience of DocBook, and am willing to donate
some spare cycles to convert other formats to DocBook and produce
HTML/PDF/TeX versions.

2) There's a possibility we can use some of the documentation that has
already been written for Asterisk: The Future of Telephony, which is
already in DocBook format.  I'll be speaking with the great folks at
O'Reilly and make sure they're OK with us doing that.

-Jared
___
--Bandwidth and Colocation provided by Easynews.com --

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

Re: [asterisk-dev] Enhanced AGI

[Jared Smith]

On 4/16/07, Loic Didelot [EMAIL PROTECTED] wrote:

So my question is do I have access to the sound channel and how can I
debug? I try to open file descriptor 3 but writing to it does not give
me anything.


EAGI only allows you to *read* from file descriptor 3 for inbound
audio, but does not allow you to write any outbound audio.

-Jared
___
--Bandwidth and Colocation provided by Easynews.com --

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

Re: [asterisk-dev] Lost Query with MySQL

[Jared Smith]

On 3/22/07, C. Savinovich [EMAIL PROTECTED] wrote:

   Hello everyone, I am writing a C module that uses a SELECT query to a
mysql server upon starting a phone call...  somehow the query works the
first time or two, afterwards, it doen't, although connection is still
on...  any hints or guesses will be appreciated


It's going to be a little difficult for us to debug your C code, since
we don't have access to it.  Wouldn't it just be easier to use the
func_odbc module in Asterisk (or an AGI script) to query mysql,
instead of writing your own module?

-Jared
___
--Bandwidth and Colocation provided by Easynews.com --

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

Re: [asterisk-dev] Re: [svn-commits] kpfleming: trunk r50538 - /trunk/main/channel.c

[Jared Smith]

On 1/12/07, John Todd [EMAIL PROTECTED] wrote:

While I understand the sentiment here, I'm not sure this is a good
idea.  This builds in a 500ms post-dial delay issue into every call.
I've been building systems for three years now, and everywhere there
is an Answer (which, I believe, should be the only method that
picks up a line and sets up a media channel locally, but that's a
discussion for another thread) there is a Wait(.5) or even a
Wait(1).


Wouldn't this be better served as an argument to the Answer()
application?  We already have one argument for a delay *before*
answering the channel, so why not have one for a delay *after*
answering the channel.  Now the commit log says when a channel gets
automatically answered by an application, so does this take place
only if you don't call the Answer() application and leave it up to
another application to automagicially answer the channel?

-Jared
___
--Bandwidth and Colocation provided by Easynews.com --

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

Re: [asterisk-dev] Re: [svn-commits] kpfleming: trunk r50538 - /trunk/main/channel.c

[Jared Smith]

On 1/12/07, Kevin P. Fleming [EMAIL PROTECTED] wrote:

Note that the Answer() argument was also mis-documented; it was already
a post-answer delay, and I've updated all three branches to reflect that.


I thought it was, but then I went back and looked at the documentation
and it said before, so that's what confused me.  Thanks for clearing
that up!

-Jared
___
--Bandwidth and Colocation provided by Easynews.com --

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

Re: [asterisk-dev] daemonising after possible errors

[Jared Smith]

On 12/7/06, Tzafrir Cohen [EMAIL PROTECTED] wrote:

 Something that I find bothering when I try to debug Asterisk is that it
 deamonizes before most errors can occour. It will fork into background
 before many potential fatal errors occour. Such fatal errors are in the
 module loading time.


Personally, I'm all for this.  One of the most common problems I see
(especially when teaching Asterisk classes) is that people
misconfigure the signalling (or misnumber their channels) in
zapata.conf and Asterisk starts, forks to the background, and then
fails.  It would be quite helpful if it loaded the modules first
(reporting any errors), and then forked to the background.
Unfortunately, I have no idea how hard this would be to implement.

Anybody else feel like commenting?

-Jared
___
--Bandwidth and Colocation provided by Easynews.com --

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

Re: [asterisk-dev] IAX2 very CPU hungry

[Jared Smith]

On 11/22/06, Loic DIDELOT [EMAIL PROTECTED] wrote:

it really is a lot better in 1.4.


One of the things that Asterisk 1.4 added was a multi-threaded IAX
implementation (thanks Mark!).  From the little bit of testing on it
that I've done, it's made a huge improvement on how well IAX works
under load.  Check out the iaxthreadcount setting in iax.conf.

-Jared
___
--Bandwidth and Colocation provided by Easynews.com --

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

Re: [asterisk-dev] OriginateSuccess and OriginateError incomplete (in 1.4 beta3)

[Jared Smith]

On 11/24/06, dmb [EMAIL PROTECTED] wrote:

Is that correction included in the next beta or in the release candidate?


I suggest you file a bug in the bug tracker, so that your request
doesn't get lost.

-Jared
___
--Bandwidth and Colocation provided by Easynews.com --

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

Re: [asterisk-dev] Bug marshals - won't you take a look at 8188

[Jared Smith]

On Thu, 2 Nov 2006, Stephen Davies wrote: I posted up a change that gets chan_iax2 to log jitter buffer stats into the logs regularly during active calls.I've also responded to the bug (#8188), but I'll repost my comments below as they're likely to get a greater audience of developers:
Interesting... John Todd and I were discussing something similar at
AstriCon, but in a more generic sense. What we'd like to see written is
CQDR -- Call Quality Detail Records. Think of them as sitting
side-by-side the CDR records, but showing information about the Call
Quality. 

In the case of IAX, we get all kinds of useful information, which we
don't currently capture (and your patch logs to the verbose log). In
the case of SIP, we have RTCP reports (as well as call quality reports
in the BYE messages of some endpoints). 

Wouldn't it be cool to see all this information logged to a CQDR table?-Jared
___
--Bandwidth and Colocation provided by Easynews.com --

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

Re: [asterisk-dev] Re: SIP to IAX (Jeremy McNamara)

[Jared Smith]

Don't get me wrong -- I like the Wiki too. I see the Wiki and the docs project as being orthogonal to each other in a lot of respects. The wiki as more of a reference, and the docs project as more hand-holding and step-by-step instruction. And you're right -- it's hard to curl up in a comfy chair with the wiki...
-JaredOn 10/6/06, John Lange [EMAIL PROTECTED] wrote:
On Thu, 2006-10-05 at 16:30 -0400, Jared Smith wrote: On 10/5/06, John Lange [EMAIL PROTECTED] wrote: FYI, there's still work being done as part of the Asterisk
 Documentation Project, although a lot of it is going on behind the scenes.I encourage you to help out by joining the mailing list and help us out.Personally I prefer to contribute to the voip-info wiki which seems like
a much better way to do timely documentation rather than text files inan SVN repository.But it is nice to have a hard format book in your hands sometimes so Isee the merits of both approaches.
John___--Bandwidth and Colocation provided by Easynews.com --asterisk-dev mailing listTo UNSUBSCRIBE or update options visit:
 http://lists.digium.com/mailman/listinfo/asterisk-dev
___
--Bandwidth and Colocation provided by Easynews.com --

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

Re: [asterisk-dev] Configuration for recording quality?

[Jared Smith]

On Fri, 2006-08-04 at 13:42 +0200, Jan du Toit wrote:
 I have recently posted a mail on the users mailing list, asking around 
 how to change the quality setting of files that asterisk record for you.
 For instance change the 8kHz for meetme recordings to 32kHz.

Unfortunately, this list isn't the I asked on the -users list, but
nobody answered list.  This is not a court of appeals.  This is the
list the Asterisk developers use to discuss changes to the Asterisk
source code.

 The reply came that you can not configure the recording 
 settings/quality. Is this true?

As far as I know (and I could be wrong here), it's not possible.  Why,
you ask?  First of all, because Asterisk deals with 8kHz audio, because
that's what comes across the PSTN.  While there is certainly VoIP
hardware (and softphones) that support wideband audio, it's not that
mainstream yet. [1]

 I was just wondering if something like this is in the pipeline? Or was 
 thought about?

Yes, the developers have thought about it, and I think you'll see
Asterisk start to support wideband audio more and more once Asterisk 1.4
has been released and has a chance to settle.  In fact, I think at least
one of the developers has a wideband tree in the subversion
repository, although I haven't seen any movement on it in a while, most
likely because the developers are busy trying to get the finishing
touches on 1.4 done. [2]

 I was suprised to see that asterisk, which I regard as a functionality 
 rich product, does not allow you to do this.

At this point, what good would it do to be able to provide a 32kHz
recording of a meetme conference, if the audio coming into it is only
8kHz to begin with?  If you really want 32kHz audio, why not use sox to
convert the file after the fact.

I apologize this this comes off sounding rude -- I don't mean it to be
that way.  I'm just trying to explain things in a way that will help you
understand.

-Jared

[1] See chapter 7 of Asterisk: The Future of Telephony for an
explanation of why it's 8kHz.  The PDF is downloadable for free from
www.asteriskdocs.org
[2] http://svn.digium.com/view/asterisk/team/mattf/asterisk-wideband/

___
--Bandwidth and Colocation provided by Easynews.com --

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

Re: [asterisk-dev] Patch to app_queue to add annoucements to the caller

[Jared Smith]

On Tue, 2006-07-04 at 15:15 +0200, Tristan wrote:
 Hi, here is a patch against 1.2.9.1 to add annoucements to the caller...

Thanks for submitting a patch!  It's always good to have more people
contributing to the code base.  Instead of posting your patches to the
mailing list, please post them to the bug tracker (bugs.digium.com)
instead.  Also, you'll need to send a disclaimer to Digium (as explained
on the bug tracker) so that they're in good legal standing to actually
read your proposed patch.

-Jared

___
--Bandwidth and Colocation provided by Easynews.com --

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

Re: [asterisk-dev] extra parameter for DB read function

[Jared Smith]

On Wed, 2006-05-31 at 14:30 +0100, Julian Lyndon-Smith wrote:
 There are often times that I want to read a DB value from the dialplan, 
 and if this family/key pair does not exist, set it to some default value.
 
 for example:
 
 1234,1 = Set(EMAILADDR=${DB(x/y)}
 1234,2 = GotoIf($[${EMAILADDR} = ]?3:4)
 1234,3 = Set([EMAIL PROTECTED])
 1234,4 = NoOp(${EMAILADDR})
 1234,5 = Hangup()

I hate to burst your bubble, but what's wrong with using the DB_EXISTS
dialplan function?  

exten = 1234,1,Set(EMAILADDR=
${IF($[${DB_EXISTS(x/y)}]?${DB_RESULT}:[EMAIL PROTECTED])})

Obviously it's a little harder to read (especially when all placed on
one line), but it's already quite easy to use without adding more code
to Asterisk.

-Jared

___
--Bandwidth and Colocation provided by Easynews.com --

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

Re: [Asterisk-Dev] Voicemail to email volume change patch

[Jared Smith]

On Fri, 2006-01-13 at 11:15 -0600, Aaron Daniel wrote:
 My boss and I have been working on a patch to the voicemail code, and 
 I'd like to see what everyone thinks of it.  I'd like suggestions and 
 stuff on anything that needs to be changed, as this is the first time 
 we've patched the code, and would like to submit it for use later on in 
 the code.

Thanks for helping out!

Please post your patch to the bug tracker at http://bugs.digium.com/,
and make sure you have a signed disclaimer on file.  This way, it will
be reviewed by the bug marshals, and we can keep track of it.

(If you'd like to post the bug number back here, then it'll probably get
a little more attention.)

-Jared

___
--Bandwidth and Colocation provided by Easynews.com --

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

Re: [Asterisk-Dev] The Zaptel init scripts must die!

[Jared Smith]

On Tue, 2005-12-13 at 12:50 -0500, Greg Boehnlein wrote:
 I may also 
 modify the zaptel Makefile at a later date to allow you to to do make 
 config (same as Asterisk).

I'm shooting from the hip here, so don't quote me on this -- but if I
remember correctly, this is already supported in the Zaptel makefile.

-Jared

___
--Bandwidth and Colocation provided by Easynews.com --

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

Re: [Asterisk-Dev] Patch to allow Dial() to ignore call forward

[Jared Smith]

On Tue, 2005-11-08 at 11:57 -0600, John Lange wrote:
 The following patch applies against 1.0.9 and adds another option to the
 Dial command.

Would you please add this patch to the bug tracker, and if possible,
create one against CVS HEAD?  Asterisk 1.2 is getting quite close to
being released, and new features are no longer being added to the 1.0.x
series.  Note that you'll also need to send in a signed disclaimer if
you want your patch considered for inclusion within Asterisk itself.

-Jared

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

Re: [Asterisk-Dev] Send tone to caller on answer

[Jared Smith]

On Mon, 2005-10-31 at 08:39 -0800, Ed Greenberg wrote:
 I've been asked to configure Asterisk to send a tone back to the caller 
 when the call is answered - to indicate answer supervision.
 
 Has anybody done this before? Is there interest in it?  Am I missing 
 something?

My gut reaction would be to do this with a Dial() macro (the M option to
Dial).

-Jared

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

RE: [Asterisk-Dev] getting started

[Jared Smith]

On Sun, 2005-09-11 at 18:41 -0400, Sherwood McGowan wrote:
 Hey all, I wanted to start getting in there too, but dev.asteriskdocs.org
 does not resolve under my 6 different DNS servers. Is there a mistake here?

Yes, I changed DNS on the asteriskdocs.org domain to point to a new
server until we get the old one up and running, and forgot to add an
entry for dev.asteriskdocs.org.  (It's on a third server, just to
confuse people even more!)

In short, the problem should be resolved as soon as the DNS changes
propagate.

-Jared

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

Re: [Asterisk-Dev] help needed

[Jared Smith]

On Mon, 2005-07-25 at 16:34 +0200, Hoai-Anh Ngo-Vi wrote:
 But Asterisk didn't really launch that a.out programm (I didn't get any 
 message via CLI console, that programm would have put some messages into 
 CLI console via stderr if it ran correctly).
 

Don't be too sure.  In most cases, Asterisk only puts the STDERR output
from an AGI program onto the *FIRST* Asterisk console, which is probably
on TTY9 if you're using the default safe_asterisk.

Is this a bug?  Is this intentional?  I'm not sure...

-Jared

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

Re: [Asterisk-Dev] chan_sip crash w/ Refer [patch]

[Jared Smith]

On Tue, 2005-06-14 at 00:09 -0400, Jared Mauch wrote:
 Index: chan_sip.c
 ===
 RCS file: /usr/cvsroot/asterisk/channels/chan_sip.c,v
 retrieving revision 1.759
 diff -u -r1.759 chan_sip.c
 --- chan_sip.c9 Jun 2005 22:41:18 -   1.759
 +++ chan_sip.c14 Jun 2005 04:01:33 -

[snip]

   IP disclosure is on file :)

Please post this to the bug tracker at http://bugs.digium.com/ so that
it doesn't get lost in the shuffle.  (You'll want to note there that
your disclaimer is on file.)

-Jared (another one!) Smith

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

Re: [Asterisk-Dev] Loss of functionality with depreciation ofDBGet/Put?

[Jared Smith]

On Tue, 2005-05-17 at 10:04 -0500, Matthew Boehm wrote:
 /me raises hands and directs the chorus of angels to sing: Hallelujah!
 
 (geez..its only tuesday?)

While I agree that this is a great idea, I'm a little concerned about
communicating this to the Asterisk community at large -- Is there any
formal plan for how it's going to be handled?

As someone intimately involved with trying to create Asterisk
documentation, I'm having to rewrite major sections due to changes like
this and the recent Set() function variable changes.  Is it worth trying
to communicate some of these changes beforehand, so that we can get them
properly documented?  (Am I asking the impossible, as it seems the
majority of the developers don't give a flying flip about
documentation?)

-Jared

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

Re: [Asterisk-Dev] rfc2833 DTMFs sent with bad timestamps (patch)

[Jared Smith]

On Sat, 2005-02-26 at 18:45 +0100, Frank van Dijk wrote:
 I ran into an issue with the way asterisk sends rfc2833 DTMF events. As 
 my days of experience with asterisk can be counted on one hand I would 
 like to hear your expert opinion on the attached patch that solves the 
 problem for me, or maybe your opinion on other ways to solve the problem.
 

On the non-technical side of things, standard operating procedure is to
add the bug to the bug tracking system (bugs.digium.com), and make sure
you have a disclaimer on file with Digium.  After that's done, then it's
a good idea to announce your patch in this mailing list so that it can
be discussed.

On the technical side, it looks pretty straightforward to me.  Does
anybody with more Asterisk coding experience have anything to say about
this patch?

-Jared Smith

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

Re: [Asterisk-Dev] variable sample period?

[Jared Smith]

On Wed, 2005-02-23 at 16:14 +0100, Peter Svensson wrote:

 For ulaw/alaw on a local connection between machines 10ms or even less may 
 be perfectly acceptable, especially combined with trunking. 

If you're using IAX2 trunking with a codec frequency other than 20ms,
you'll also want to set the trunkfreq setting in iax.conf to match.
Otherwise, your IAX packets will jump in and out of the trunk.  (I know,
it sounds crazy, but that's what happens.  Drove me nuts the first time
I saw it happening.)

-Jared

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

Re: [Asterisk-Dev] Reload crash backtrace

[Jared Smith]

For what it's worth, I've seen a lot of crashes on restart nows as
well.

Jared

On Mon, 2003-08-18 at 13:41, Tilghman Lesher wrote:
 This was an odd crash.  Crashed on a reload.  Current CVS:
 
 #0  __ast_context_destroy (con=0x0, registrar=0x404ad5ad pbx_config, 
 lock=1) at pbx.c:3983
 #1  0x08066905 in ast_context_destroy (con=0x0, registrar=0x404ad5ad 
 pbx_config) at pbx.c:4011
 #2  0x404ad4c0 in reload () at pbx_config.c:1678
 #3  0x08054890 in ast_module_reload () at loader.c:159
 #4  0x08068ca6 in handle_reload (fd=38, argc=1, argv=0xbd9ff62c) at 
 cli.c:105
 #5  0x08068a58 in ast_cli_command (fd=38, s=0xbd9ff80c reload) at 
 cli.c:1006
 #6  0x08079c93 in netconsole (vconsole=0x80bf5a0) at asterisk.c:192
 #7  0x400270ce in pthread_start_thread (arg=0xbd9ffc00) at 
 manager.c:291
 
 -Tilghman
 
 ___
 Asterisk-Dev mailing list
 [EMAIL PROTECTED]
 http://lists.digium.com/mailman/listinfo/asterisk-dev

___
Asterisk-Dev mailing list
[EMAIL PROTECTED]
http://lists.digium.com/mailman/listinfo/asterisk-dev