Re: [asterisk-dev] Gerrit offline?

[Sean Bright]

On 8/17/2023 9:04 PM, aster...@phreaknet.org wrote:

> Would it be at all possible to extend that possibly at least a couple days, 
> perhaps through Wednesday at least?

Shouldn't be necessary, I opened two PRs in your repo that remove the 
references to gerrit so you should be good to go.

Kind regards,
Sean-- 
_
-- 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] Deprecating users.conf

[Sean Bright]

Hi,

On 6/30/2023 8:19 AM, Sean Bright wrote:
> I and my users are using users.conf for nearly every install and removing 
> support for it would be disruptive to 100s of installs.

After some internal discussion I think we can be migrated away from users.conf 
by the time that Asterisk 23 is generally available. No objection to 
deprecating it in Asterisk 21.

Kind regards,
Sean


-- 
_
-- 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] Deprecating users.conf

[Sean Bright]

Hi,

On 6/30/2023 7:45 AM, aster...@phreaknet.org wrote:
> I've put up a PR to deprecate users.conf[1], following a
> discussion earlier this year about this, but I think that was on IRC so
> wanted to discuss here as well.

Apologies - I realized after initially commenting on the PR that I could have 
stated my objection immediately rather than direct you here.

I and my users are using users.conf for nearly every install and removing 
support for it would be disruptive to 100s of installs. I've also had some 
people reach out to me off-list expressing their concerns with it being 
removed. I am willing to take over all support for users.conf going forward. I 
can update the module deprecation page¹ indicating I am the maintainer.

If the deprecation warning remains I would need to be able to silence it with a 
command line flag or an option in asterisk.conf.

Kind regards,
Sean


1. https://docs.asterisk.org/latest/Development/Asterisk-Module-Deprecations/


-- 
_
-- 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] C API Deprecation proposal: ast_gethostbyname()

[Sean Bright]

Hi,

Per the C API Deprecation policy¹ I am proposing the deprecation of
ast_gethostbyame() in favor of the ast_sockaddr family of functions. No
in-tree code currently uses this function. Assuming the function is
deprecated in Asterisk 21 it will be removed in Asterisk 23.

There is already an issue² and PR³ for this deprecation.

Please raise any concerns you have here for discussion.

Kind regards,
Sean


1. https://wiki.asterisk.org/wiki/display/AST/C+API+Deprecation
2. https://github.com/asterisk/asterisk/issues/78
3. https://github.com/asterisk/asterisk/pull/79



-- 
_
-- 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] Infrastructure move to GitHub

[Sean Bright]

On 4/3/2023 11:11 AM, George Joseph wrote:
> Last year we announced we were planning to move away from the Atlassian 
> products (Jira, Confluence, etc), Gerrit and Jenkins to GitHub.  That time is 
> upon us.

This is great news. Thanks to you and everyone else who's been working on this!

Kind regards,
Sean


-- 
_
-- 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] chan_sip realtime port with host dynamic and defaultip

[Sean Bright]

On 3/15/2023 9:43 AM, Marcin Groszek wrote:
> Recently I discovered  that when realtime is used the port  is ignored
> when used with host=dynamic and defaultip=x.x.x.x.
>
>      if (port && !realtime && peer->host_dynamic) {
>      ast_sockaddr_set_port(&peer->defaddr, port);
>      } else if (port) {
>      ast_sockaddr_set_port(&peer->addr, port);
>      }
>
> Is there a reason why port value is ignored if the peer is setup in
> realtime?

The `!realtime` check was added in 2005¹, the commit message is fairly
vague, and I am not able to find bug #3286 it refers to.

Kind regards,
Sean

[1]: 
https://github.com/asterisk/asterisk/commit/e7cb9750213a8a88de1818f2d5b2b928c2661afd#diff-b46867aafe8df97c4c3e15a223f26dde97354b72e649bf6cb73215ac657364a2R8886


-- 
_
-- 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] OpenAPI 3.1 API description for ARI

[Sean Bright]

On 6/24/2022 4:36 PM, James Finstrom wrote:

> I did convert and manually clean up the spec once.  This obviously
> isn't  maintained

Ugh. Same. My intentions were good though:

https://github.com/seanbright/asterisk-ari-openapi-spec

PRs welcome? Maybe?-- 
_
-- 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 doesn't seem to process tokens with percent characters correctly

[Sean Bright]

On 9/21/2021 1:36 PM, Dan Cropp wrote:
> There seem to be two different issues with PJSIP processing of headers
> with the % character in tokenized fields.

If you could collect some debug information[1] and create a new issue on
the issue tracker[2] that would go a long way towards getting this resolved.

Kind regards,
Sean

1. https://wiki.asterisk.org/wiki/display/AST/Collecting+Debug+Information
2. https://issues.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] External scripts for parsing the security logs

[Sean Bright]

On 11/23/2020 4:09 AM, Mohit Dhiman wrote:
can anyone please recommend any existing external scripts that can 
parse the Asterisk security logs and possibly take appropriate actions 
like IP blocking.


Fail2ban 
-- 
_
-- 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] Pain Points For Large Scale Instance Provisioning

[Sean Bright]

On 10/20/2020 5:32 PM, Michael Cargile wrote:

* Reliable module reloading without core restarts
 Example: Client lets their SSL certificate lapse on an Asterisk 
server and they only figure this out when their
 agents attempting to log in using WebRTC clients. They have 
dozens or even hundreds of customer calls in queue,
 but their agents cannot login. On Asterisk 13 we cannot fix the 
SSL certs without a full restart of Asterisk
 which drops these calls. A reload of the http module does not fix 
this.


FWIW - This particular issue was fixed in Asterisk 13.24 (released 
2018-12-11): https://gerrit.asterisk.org/c/asterisk/+/10395




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

[Sean Bright]

On 10/1/2020 7:56 AM, Joshua C. Colp wrote:
Around this time each year a discussion always spurs (be it on IRC or 
at AstriDevCon) about deprecating modules, and removing them. I always 
find myself asking "what is our real process for doing this?" in my 
head and end up trying to piece it together based on some information 
here and there on the wiki plus past experience. I'd like to better 
document this and put something more concrete into place. To that end 
I'd like to propose the following:


Thanks for putting these thoughts on paper.

No matter what is ultimately decided, I would like to propose that we 
have some kind of scheduled x-number-of-months-before-release discussion 
where we can propose that a module be deprecated. It's good to have 
process around it, but I feel like we always end up discussing it _just 
after_ a new major version is released and it is too late to do anything 
about.


Kind regards,
Sean


--
_
-- 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] res_calendar_exchange: anyone using it?

[Sean Bright]

Hi,

The res_calendar_exchange module currently relies on a library 
(libiksemel) that is abandoned and is being dropped from recent distros. 
I've converted it over to use libxml2 (which is already a required 
dependency of Asterisk), but I don't have an environment in which to test.


Would anyone be willing and/or able to help me test? If so, the review 
and patch is here:


    https://gerrit.asterisk.org/c/asterisk/+/13124

If I don't hear back in a couple days, I will try on the asterisk-users 
list.


Kind regards,
Sean

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

[Sean Bright]

On 10/3/2019 10:17 AM, Michael Maier wrote:

This is not a FreePBX issue


OK. Thank you for clarifying.


  provided by asterisk (take a look at the source code)


That's a good idea. I'll take a look, thanks.

Kind regards,
Sean

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

[Sean Bright]

On 10/3/2019 9:52 AM, Michael Maier wrote:

I think this should be enough - just install FreePBX and you will see it. You 
don't need any special configuration - it's the default configuration provided 
by FreePBX.


Great. Hopefully someone on the FreePBX team also follows the Asterisk 
issue tracker.


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).


Kind regards,
Sean

--
_
-- 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.5.x / SIPS / SRTP / pjsip 4.9 - one more memory leak

[Sean Bright]

On 10/3/2019 9:42 AM, Michael Maier wrote:

Sorry, but there is one more memory leak even in asterisk 16.6.0-rc2, which 
can't be seen with pjsip 4.8 instead of 4.9. It can be seen on inbound calls 
(not sure if it's
on outbound calls, too) using SIPS and SRTP.


Examples:
1 Call, duration about 1 h: ~ +1,2 MB
5 short calls (< 1 minute): ~ +1 MB


Please file an issue[1] with a configuration that exhibits this.

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

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

[Sean Bright]

On 10/2/2019 4:02 PM, Michael Maier wrote:
I found one more problem regarding the configuration options, provided 
by FreePBX, which should be supported by asterisk.
I'm referring to the possibility, to add additional options not 
supported by FreePBX using special config files like
pjsip.registration_custom_post.conf or pjsip.aor_custom_post.conf and 
pjsip.endpoint_custom_post.conf or pjsip.transports_custom_post.conf.
The last two files are working pretty fine as expected, but the first 
two just don't work.


I'm configuring in pjsip.registration_custom_post.conf for example:

[extName](+)
key=value

Asterisk reads it (asterisk complains if it doesn't know the key), but 
asterisk doesn't apply the provided value for a known key - it's 
always the default value. That's strange, too. 


Please file an issue[1] with a configuration that exhibits this.

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


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

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

Re: [asterisk-dev] res_config_sqlite3 segfault?

[Sean Bright]

On 7/11/2019 6:11 AM, Dennis Buteyn wrote:
Asterisk seems to crash consistently on startup if you don't 
explicitly define "dbfile => ... " in res_config_sqlite3.conf. (Not 
having the config file at all is fine).


I've been unable to reproduce this with Asterisk 13. If you aren't able 
to open an issue for whatever reason, you can send me your 
res_config_sqlite3.conf directly at sean.bri...@gmail.com.


Kind regards,
Sean
-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

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

Re: [asterisk-dev] res_config_sqlite3 segfault?

[Sean Bright]

On 7/11/2019 6:11 AM, Dennis Buteyn wrote:
Asterisk seems to crash consistently on startup if you don't 
explicitly define "dbfile => ... " in res_config_sqlite3.conf. (Not 
having the config file at all is fine).


At a glance, I don't see how this is possible with res_config_sqlite3 
from Asterisk 13. When you create an issue, please attach the 
res_config_sqlite3.conf file you are using.


Kind regards,
Sean
-- 
_
-- 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] Fwd: Bug#925760: libss7: ftbfs with GCC-9

[Sean Bright]

A fix has been merged:

https://gerrit.asterisk.org/c/libss7/+/11206

I don’t know if/when it will be released.

Kind regards,
Sean

On Fri, Mar 29, 2019 at 3:39 AM Tzafrir Cohen  wrote:

> Hi,
>
>
> I wanted to report this as a bug on the libss7 component, but I failed
> to do so: there are no versions there and thus I can't set a version.
>
> Basically it seems gcc does not like strncpy with size same as the
> buffer size, as in case the source is not null-terminated, the target
> won't be.
>
>
>
>  Forwarded Message 
> Subject:Bug#925760: libss7: ftbfs with GCC-9
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> Package: src:libss7
> Version: 2.0.0-2
> Severity: normal
> Tags: sid bullseye
> User: debian-...@lists.debian.org
> Usertags: ftbfs-gcc-9
>
> Please keep this issue open in the bug tracker for the package it
> was filed for. If a fix in another package is required, please
> file a bug for the other package (or clone), and add a block in this
> package. Please keep the issue open until the package can be built in
> a follow-up test rebuild.
>
> The package fails to build in a test rebuild on at least amd64 with
> gcc-9/g++-9, but succeeds to build with gcc-8/g++-8. The
> severity of this report will be raised before the bullseye release,
> so nothing has to be done for the buster release.
>
> The full build log can be found at:
>
> http://people.debian.org/~doko/logs/gcc9-20190321/libss7_2.0.0-2_unstable_gcc9.log
> The last lines of the build log are at the end of this report.
>
> To build with GCC 9, either set CC=gcc-9 CXX=g++-9 explicitly,
> or install the gcc, g++, gfortran, ... packages from experimental.
>
> apt-get -t=experimental install g++
> Common build failures are new warnings resulting in build failures with
> -Werror turned on, or new/dropped symbols in Debian symbols files.
> For other C/C++ related build failures see the porting guide at
> http://gcc.gnu.org/gcc-9/porting_to.html
>
> GCC 9 also passes the linker option --as-needed by default; typical
> build issues are passing libraries before object files to the linker,
> or underlinking of convenience libraries built from the same source.
>
> [...]
> | ^~
> In function 'strncpy',
> inlined from 'isup_event_iam' at isup.c:4337:2:
> /usr/include/x86_64-linux-gnu/bits/string_fortified.h:106:10: error:
> '__builtin_strncpy' output may be truncated copying 50 bytes from a
> string of length 63 [-Werror=stringop-truncation]
> 106 | return __builtin___strncpy_chk (__dest, __src, __len, __bos
> (__dest));
> | ^~
> In function 'strncpy',
> inlined from 'isup_event_iam' at isup.c:4341:2:
> /usr/include/x86_64-linux-gnu/bits/string_fortified.h:106:10: error:
> '__builtin_strncpy' output may be truncated copying 50 bytes from a
> string of length 63 [-Werror=stringop-truncation]
> 106 | return __builtin___strncpy_chk (__dest, __src, __len, __bos
> (__dest));
> | ^~
> In function 'strncpy',
> inlined from 'isup_event_iam' at isup.c:4347:2:
> /usr/include/x86_64-linux-gnu/bits/string_fortified.h:106:10: error:
> '__builtin_strncpy' output may be truncated copying 50 bytes from a
> string of length 63 [-Werror=stringop-truncation]
> 106 | return __builtin___strncpy_chk (__dest, __src, __len, __bos
> (__dest));
> | ^~
> In function 'strncpy',
> inlined from 'isup_event_iam' at isup.c:4350:2:
> /usr/include/x86_64-linux-gnu/bits/string_fortified.h:106:10: error:
> '__builtin_strncpy' output may be truncated copying 50 bytes from a
> string of length 63 [-Werror=stringop-truncation]
> 106 | return __builtin___strncpy_chk (__dest, __src, __len, __bos
> (__dest));
> | ^~
> In function 'strncpy',
> inlined from 'isup_event_iam' at isup.c:4353:2:
> /usr/include/x86_64-linux-gnu/bits/string_fortified.h:106:10: error:
> '__builtin_strncpy' output may be truncated copying 50 bytes from a
> string of length 63 [-Werror=stringop-truncation]
> 106 | return __builtin___strncpy_chk (__dest, __src, __len, __bos
> (__dest));
> | ^~
> In function 'strncpy',
> inlined from 'isup_event_iam' at isup.c:4361:2:
> /usr/include/x86_64-linux-gnu/bits/string_fortified.h:106:10: error:
> '__builtin_strncpy' output may be truncated copying 50 bytes from a
> string of length 63 [-Werror=stringop-truncation]
> 106 | return __builtin___strncpy_chk (__dest, __src, __len, __bos
> (__dest));
> | ^~
> In function 'strncpy',
> inlined from 'isup_event_iam' at isup.c:4362:2:
> /usr/include/x86_64-linux-gnu/bits/string_fortified.h:106:10: error:
> '__builtin_strncpy' output may be truncated copying 50 bytes from a
> string of length 63 [-Werror=stringop-trun

Re: [asterisk-dev] Asterisk 16 Parking Lot Full behavior.

[Sean Bright]

On 12/26/2018 2:58 PM, Steve Sether wrote:

Jira seems to be closed to outsiders opening bug reports.  I'm happy to open 
one, but I don't have access.  Is there some other way I can open a bug report? 
 IIRC Jira charges per user, so if that's the case I can certainly see why they 
don't want to create an account for one user creating a bug.


It's open to everyone[1].

Kind regards,
Sean

[1]: 
https://wiki.asterisk.org/wiki/display/AST/Asterisk+Issue+Guidelines#AsteriskIssueGuidelines-Submittingthebugreport
-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

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

Re: [asterisk-dev] Adding a Key/Value Store mechanism to Asterisk

[Sean Bright]

Hi,

On 12/22/2017 7:22 AM, Nir Simionovich wrote:
  Every, and I do mean every, Asterisk application requires a 
key/value store of some form. Most developers will
basically butcher (would have used stronger words, but refraining from 
doing so) AstDB in the process, which will
then result in a performance toll - specifically when dealing with a 
high capacity systems.


If you are implementing high capacity systems and decided to use AstDB 
as your KV store, you're going to have a bad time. That is not the 
use-case for AstDB. AstDB is an 
always-there-does-not-require-configuration-general-purpose-data-store 
used primarily by internal Asterisk modules themselves. I would say any 
use of AstDB beyond that (whether it was with BDB in the old days or 
SQLite today) and expecting high throughput is ill advised.


  Initially, I was under the impression this should be done as a 
sorcery module, but I'm not sure this is the

correct approach or the required use case.


None of the Sorcery modules today implement data access themselves, they 
simply leverage one of Asterisk's existing data access providers (AstDB, 
config files, or Realtime). If you go down this path, I would suggest a 
res_redis module that provides user-facing functionality (dialplan 
functions, etc.) as well as an API for the rest of Asterisk. Then a 
res_sorcery_redis or res_sorcery_kv could be built to consume that API. 
Alternatively you could just build the Sorcery module and still provide 
the user-facing functionality from that. Either way, a Sorcery module 
should definitely be on the radar, as that is the future in terms of 
configuration.


Kind regards,
Sean

--
_
-- 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] Weirdness-- intermittent loss of recordings w/ 13.5.0

[Sean Bright]

On 11/14/2017 3:10 PM, Steve Murphy wrote:
This is a preliminary cry for help... We are seeing a 51.2% 'loss' of 
recordings
on one of our 13.5.0 systems. All calls are are in u-law format. The 
incoming calls are offered
gsm and 729, among others,  but we restrict to only u-law. We only 
offer ulaw on outgoing calls.


To confirm - you are talking about 13.5 and not 13.15, correct?
-- 
_
-- 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] One sip stack to rule them all....

[Sean Bright]

On 10/8/2017 10:55 AM, James Finstrom wrote:
So one of the things that is needed to finally put Chan sip to bed is 
feature parody.  Someone brought up CCSS.


What features do you feel you would lose going from chan_sip to pjsip.

Are there any bugs in pjsip that keep you from migrating?


FWIW, I created a tracking bug for chan_pjsip feature parity with chan_sip:

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

If anyone feels like taking a crack at this related bugs, go for it.

Kind regards,
Sean

--
_
-- 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 15 RC1 and RTP/RTCP leak ?

[Sean Bright]

On 9/26/2017 12:37 PM, sean darcy wrote:

Are there any RTP/RTCP leak issues with 15 RC1 ?


What kind of leak? Memory leak?

--
_
-- 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] Have you seen me? "Alertpipe on channel X lost O_NONBLOCK?!!"

[Sean Bright]

Hi,

Could those of you on the list grep your error logs looking for the message:

lost O_NONBLOCK

(The full line would be "Alertpipe on channel X lost O_NONBLOCK?!!" 
where "X" is a channel name). There is a code comment indicating that 
this is "occasionally" a problem and I would like to determine how much 
of a problem this really is in the wild.


Kind regards,
Sean

--
_
-- 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.14.0-rc2 Now Available

[Sean Bright]

On 2/8/2017 5:23 PM, Steve Edwards wrote:
I was hoping to see something like 'And now that the patents on g.729 
have expired, Digium has contributed their codec to the open source 
project -- license and fee free' :)


Same here. Luckily the licenses are still available for purchase on the 
website:


https://www.digium.com/products/software/g729-codec

Kind regards,
Sean

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

[Sean Bright]

On 7/19/2016 4:00 PM, Bruce Ferrell wrote:

On 07/19/2016 10:59 AM, Sean Bright wrote:

On 7/19/2016 10:35 AM, Matt Fredrickson wrote:

Response below.

On Mon, Jul 18, 2016 at 7:18 AM, Dennis Guse
 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?

Kind Regards,
Sean


Just for clarification, why?  speex is included.  similar if not the same 
license?


The last update I've seen on Digium's position in regards to the 
inclusion of Opus support in the core is here:


http://lists.digium.com/pipermail/asterisk-dev/2013-May/060419.html

I don't believe they have publicly changed their stance on the topic 
since then, but I'd be happy to be proven wrong.


Kind regards,
Sean



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

[Sean Bright]

On 7/19/2016 10:35 AM, Matt Fredrickson wrote:

Response below.

On Mon, Jul 18, 2016 at 7:18 AM, Dennis Guse
 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?


Kind Regards,
Sean

--
_
-- 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] [BOUNTY] Bug Fixes

[Sean Bright]

On 7/7/2016 8:22 AM, Ross Beer wrote:


Currently, there are a few open issues with the Asterisk project which 
require urgent fixes:



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

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

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

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

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

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


I am therefore offering $500 USD for these to be resolved.



Is that $500 each or $500 total?

Kind Regards,
Sean

-- 
_
-- 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] [RTP] Detecting that a packet is SRTP

[Sean Bright]

On 4/29/2015 11:20 AM, Yousf Ateya wrote:
In res_rtp_asterisk.c, to detect that a packet is SRTP (not RTP), this 
check is done (link to gitweb 
):


if ((*in >= 20) && (*in <= 64)) {

Although in the Datagram Transport Layer Security (DTLS) Extension to 
Establish Keys for the Secure Real-time Transport Protocol (SRTP), 
section 5.1.2  it 
is stated that it should be between 20 and 63 (not 64).


Is this a bug?


Certainly appears to be.

Kind regards,
Sean
-- 
_
-- 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] Re: [BOUNTY] FATAL: unhandled exception PJLIB/No memory!

[Sean Bright]

On 3/19/2015 6:38 AM, Ross Beer wrote:

We are getting the following error with asterisk 12 and 13:

[Mar 19 10:14:08] ERROR[40185]: pjsip:0 :  except.c .!!!FATAL: 
unhandled exception PJLIB/No memory!


Ross,

Is there an associated issue in Jira?  https://issues.asterisk.org/

Kind Regards,
Sean

--
_
-- 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] 4389: Memory leak cleanups

[Sean Bright]

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



/branches/13/main/manager.c
<https://reviewboard.asterisk.org/r/4389/#comment24872>

You're missing a leading tab here.


- Sean Bright


On Jan. 29, 2015, 6:04 p.m., Mark Michelson wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/4389/
> ---
> 
> (Updated Jan. 29, 2015, 6:04 p.m.)
> 
> 
> Review request for Asterisk Developers.
> 
> 
> Bugs: ASTERISK-24736
> https://issues.asterisk.org/jira/browse/ASTERISK-24736
> 
> 
> Repository: Asterisk
> 
> 
> Description
> ---
> 
> John Hardin of Digium did some investigation into memory leaks he was seeing 
> and created a set of patches that fixes them. I've already given these 
> patches a look and have made a few small adjustments to them where necessary 
> for coding guidelines reasons. Most of the leak fixes are pretty 
> straightforward, but one of these bears a bit of explanation:
> 
> Prior to Asterisk 12, originating calls with channel variables required that 
> you transfer ownership of the created ast_variables structure away when 
> calling ast_pbx_outgoing_exten() or ast_pbx_outgoing_app(). This was 
> presumably because these functions could spawn threads that required these 
> variables to not be freed yet. However, in Asterisk 12, 
> ast_pbx_outgoing_exten() and ast_pbx_outgoing_app() were rewritten to not use 
> the variables in the spawned threads. However, we also stopped actually 
> destroying the variables there, too. So with this patch, responsibility for 
> freeing the variables lies with the original creator of the variables.
> 
> 
> Diffs
> -
> 
>   /branches/13/res/res_pjsip_refer.c 431302 
>   /branches/13/pbx/pbx_spool.c 431302 
>   /branches/13/main/xmldoc.c 431302 
>   /branches/13/main/stasis_channels.c 431302 
>   /branches/13/main/pbx.c 431302 
>   /branches/13/main/manager.c 431302 
>   /branches/13/main/bridge_after.c 431302 
>   /branches/13/channels/chan_pjsip.c 431302 
> 
> Diff: https://reviewboard.asterisk.org/r/4389/diff/
> 
> 
> Testing
> ---
> 
> John Hardin's testing with valgrind has shown that the memory leaks it had 
> been reported are no longer present.
> 
> 
> Thanks,
> 
> Mark Michelson
> 
>

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

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

Re: [asterisk-dev] [Code Review] 4371: Update res_format_attr_opus & res_format_attr_silk to new media formats architecture

[Sean Bright]

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

(Updated Jan. 28, 2015, 2:33 p.m.)


Status
--

This change has been marked as submitted.


Review request for Asterisk Developers.


Repository: Asterisk


Description
---

In r419044, we changed how formats were handled, but the return value of the 
format_parse_sdp_fmtp functions in res_format_attr_opus and 
res_format_attr_silk were not updated, causing calls to fail.  Ran into this 
when getting codec_opus working with Asterisk 13.

Once the return value was corrected, we were crashing in opus_getjoint because 
of NULL format attributes.  I've fixed this as well in this patch.  There may 
be a similar issue with SILK, but I don't have access to codec_silk for 
Asterisk 13 so I cannot test.


Diffs
-

  /branches/13/res/res_format_attr_silk.c 431089 
  /branches/13/res/res_format_attr_opus.c 431089 

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


Testing
---

Ran a test call with codec_opus.


Thanks,

Sean Bright

-- 
_
-- 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] OT: Opus & Asterisk 13

[Sean Bright]

On 1/26/2015 8:16 AM, Olle E. Johansson wrote:

Hi,
>
>I've just finished updating codec_opus for Asterisk 13. Unfortunately it still 
requires a small patch to the core of Asterisk, but the size of that patch is 
getting smaller with each new major version of Asterisk.  You can download the 
codec implementation and patch file here:
>
>https://github.com/seanbright/asterisk-opus
>
>If you have any problems with it, please open an issue on Github, do not 
useasterisk-...@lists.digium.com.
>

Thank you Sean!

Does this patch use variable bitrates in Opus - adapting based on RTCP 
feedback? Or is it fixed?


Olle,

It is fixed.  PRs welcome of course.

Regards,
Sean

--
_
-- 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] OT: Opus & Asterisk 13

[Sean Bright]

Hi,

I've just finished updating codec_opus for Asterisk 13. Unfortunately it 
still requires a small patch to the core of Asterisk, but the size of 
that patch is getting smaller with each new major version of Asterisk.  
You can download the codec implementation and patch file here:


https://github.com/seanbright/asterisk-opus

If you have any problems with it, please open an issue on Github, do not 
use asterisk-dev@lists.digium.com.


Regards,
Sean

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

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

[asterisk-dev] [Code Review] 4371: Update res_format_attr_opus & res_format_attr_silk to new media formats architecture

[Sean Bright]

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

Review request for Asterisk Developers.


Repository: Asterisk


Description
---

In r419044, we changed how formats were handled, but the return value of the 
format_parse_sdp_fmtp functions in res_format_attr_opus and 
res_format_attr_silk were not updated, causing calls to fail.  Ran into this 
when getting codec_opus working with Asterisk 13.

Once the return value was corrected, we were crashing in opus_getjoint because 
of NULL format attributes.  I've fixed this as well in this patch.  There may 
be a similar issue with SILK, but I don't have access to codec_silk for 
Asterisk 13 so I cannot test.


Diffs
-

  /branches/13/res/res_format_attr_silk.c 431089 
  /branches/13/res/res_format_attr_opus.c 431089 

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


Testing
---

Ran a test call with codec_opus.


Thanks,

Sean Bright

-- 
_
-- 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] 4106: configure: Add autoconf check for libopus

[Sean Bright]

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

(Updated Oct. 27, 2014, 12:54 p.m.)


Status
--

This change has been marked as submitted.


Review request for Asterisk Developers.


Changes
---

Committed in revision 426234


Repository: Asterisk


Description
---

Because opus transcoding support cannot be included in the standard Asterisk 
distribution, a few codec_opus implementations have popped up.  To make it 
easier for people to drop in opus support in their own installations, this 
patch adds configure checks for libopus.

I don't see why this wouldn't be safe for 13, but I will defer to the reviewers 
on that decision.


Diffs
-

  /trunk/makeopts.in 426095 
  /trunk/include/asterisk/autoconfig.h.in 426095 
  /trunk/configure.ac 426095 
  /trunk/configure UNKNOWN 
  /trunk/build_tools/menuselect-deps.in 426095 

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


Testing
---


Thanks,

Sean Bright

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

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

[asterisk-dev] [Code Review] 4106: configure: Add autoconf check for libopus

[Sean Bright]

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

Review request for Asterisk Developers.


Repository: Asterisk


Description
---

Because opus transcoding support cannot be included in the standard Asterisk 
distribution, a few codec_opus implementations have popped up.  To make it 
easier for people to drop in opus support in their own installations, this 
patch adds configure checks for libopus.

I don't see why this wouldn't be safe for 13, but I will defer to the reviewers 
on that decision.


Diffs
-

  /trunk/makeopts.in 426095 
  /trunk/include/asterisk/autoconfig.h.in 426095 
  /trunk/configure.ac 426095 
  /trunk/configure UNKNOWN 
  /trunk/build_tools/menuselect-deps.in 426095 

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


Testing
---


Thanks,

Sean Bright

-- 
_
-- 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] 3988: res_pjsip: Don't require a password when doing userpass authentication

[Sean Bright]

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

(Updated Sept. 18, 2014, 2:29 p.m.)


Status
--

This change has been marked as submitted.


Review request for Asterisk Developers.


Changes
---

Committed in revision 423481


Repository: Asterisk


Description
---

An empty password is valid for username/password authentication so we shouldn't 
barf on it.


Diffs
-

  /branches/12/res/res_pjsip/config_auth.c 422963 

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


Testing
---

Compiles.  Registered a device with auth_type=userpass and no password set.  
Tested registration with a password which failed, and again without a password 
(an empty password) and it succeeds.


Thanks,

Sean Bright

-- 
_
-- 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] 3988: res_pjsip: Don't require a password when doing userpass authentication

[Sean Bright]

> On Sept. 10, 2014, 6:25 p.m., Joshua Colp wrote:
> > /branches/12/res/res_pjsip/config_auth.c, line 116
> > <https://reviewboard.asterisk.org/r/3988/diff/1/?file=67303#file67303line116>
> >
> > Test this and make sure that the PJSIP digest authentication doesn't 
> > freak. :P

Confirmed that no freaking occurs.


- Sean


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


On Sept. 15, 2014, 7:27 p.m., Sean Bright wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/3988/
> ---
> 
> (Updated Sept. 15, 2014, 7:27 p.m.)
> 
> 
> Review request for Asterisk Developers.
> 
> 
> Repository: Asterisk
> 
> 
> Description
> ---
> 
> An empty password is valid for username/password authentication so we 
> shouldn't barf on it.
> 
> 
> Diffs
> -
> 
>   /branches/12/res/res_pjsip/config_auth.c 422963 
> 
> Diff: https://reviewboard.asterisk.org/r/3988/diff/
> 
> 
> Testing
> ---
> 
> Compiles.  Registered a device with auth_type=userpass and no password set.  
> Tested registration with a password which failed, and again without a 
> password (an empty password) and it succeeds.
> 
> 
> Thanks,
> 
> Sean Bright
> 
>

-- 
_
-- 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] 3988: res_pjsip: Don't require a password when doing userpass authentication

[Sean Bright]

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

(Updated Sept. 15, 2014, 7:27 p.m.)


Review request for Asterisk Developers.


Repository: Asterisk


Description
---

An empty password is valid for username/password authentication so we shouldn't 
barf on it.


Diffs
-

  /branches/12/res/res_pjsip/config_auth.c 422963 

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


Testing (updated)
---

Compiles.  Registered a device with auth_type=userpass and no password set.  
Tested registration with a password which failed, and again without a password 
(an empty password) and it succeeds.


Thanks,

Sean Bright

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

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

[asterisk-dev] [Code Review] 3988: res_pjsip: Don't require a password when doing userpass authentication

[Sean Bright]

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

Review request for Asterisk Developers.


Repository: Asterisk


Description
---

An empty password is valid for username/password authentication so we shouldn't 
barf on it.


Diffs
-

  /branches/12/res/res_pjsip/config_auth.c 422963 

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


Testing
---

Compiles.


Thanks,

Sean Bright

-- 
_
-- 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] 3830: Fix build when pjproject is installed in non-standard location

[Sean Bright]

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

(Updated July 21, 2014, 9:49 a.m.)


Status
--

This change has been marked as submitted.


Review request for Asterisk Developers.


Changes
---

Committed in revision 419077


Repository: Asterisk


Description
---

When configuring Asterisk to build against a version of pjproject installed in 
a non-standard location, the checks for "PJSIP Transaction Group Lock Support" 
and "PJSIP Media Stream Replacement Support" fail.  This is because the 
secondary checks are not taking the CFLAGS and LIBS returned by the pkg-config 
check into account.

Given an install of pjproject at /opt/pjsip, the following calls to configure 
fail:

$ ./configure --with-pjproject=/opt/pjsip
$ PKG_CONFIG_PATH=/opt/pjsip/lib/pkgconfig ./configure

The first fails because the only check we do for pjproject is with pkg-config 
and the two related checks will not be run because the first fails.  The second 
incorrectly determines that the two optional features are not present when they 
are, causing a failure at compile time.  This works:

$ PKG_CONFIG_PATH=/opt/pjsip/lib/pkgconfig ./configure 
--with-pjproject=/opt/pjsip

Because the primary check succeeds with pkg-config and the optional features 
succeed using the PJPROJECT_DIR variable setup by the --with-pjproject argument.

While the included diff is certainly not the cleanest, it allows me to 
configure and compile Asterisk using:

$ PKG_CONFIG_PATH=/opt/pjsip/lib/pkgconfig ./configure


Diffs
-

  /trunk/configure.ac 418979 
  /trunk/configure UNKNOWN 

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


Testing
---

Configured, compiled.


Thanks,

Sean Bright

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

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

[asterisk-dev] [Code Review] 3830: Fix build when pjproject is installed in non-standard location

[Sean Bright]

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

Review request for Asterisk Developers.


Repository: Asterisk


Description
---

When configuring Asterisk to build against a version of pjproject installed in 
a non-standard location, the checks for "PJSIP Transaction Group Lock Support" 
and "PJSIP Media Stream Replacement Support" fail.  This is because the 
secondary checks are not taking the CFLAGS and LIBS returned by the pkg-config 
check into account.

Given an install of pjproject at /opt/pjsip, the following calls to configure 
fail:

$ ./configure --with-pjproject=/opt/pjsip
$ PKG_CONFIG_PATH=/opt/pjsip/lib/pkgconfig ./configure

The first fails because the only check we do for pjproject is with pkg-config 
and the two related checks will not be run because the first fails.  The second 
incorrectly determines that the two optional features are not present when they 
are, causing a failure at compile time.  This works:

$ PKG_CONFIG_PATH=/opt/pjsip/lib/pkgconfig ./configure 
--with-pjproject=/opt/pjsip

Because the primary check succeeds with pkg-config and the optional features 
succeed using the PJPROJECT_DIR variable setup by the --with-pjproject argument.

While the included diff is certainly not the cleanest, it allows me to 
configure and compile Asterisk using:

$ PKG_CONFIG_PATH=/opt/pjsip/lib/pkgconfig ./configure


Diffs
-

  /trunk/configure.ac 418979 
  /trunk/configure UNKNOWN 

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


Testing
---

Configured, compiled.


Thanks,

Sean Bright

-- 
_
-- 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] 3773: Add menuselect to Asterisk, remove mxml

[Sean Bright]

> On July 14, 2014, 8:37 p.m., Sean Bright wrote:
> > Looks fine to me.  Should probably throw libmxml-dev into 
> > contrib/scripts/install_prereq while you're at it.  This also might be a 
> > good opportunity to dump mxml altogether as we already use libxml2 in 
> > asterisk itself.  One less dependency to install.
> > 
> > I'd be happy to take a crack at it if you don't have the bandwidth.
> 
> Matt Jordan wrote:
> That'd be awesome. I'd love to only depend on a single XML library :-)
> 
> We would have to make libxml2 a hard dependency at that point, but that 
> feels like a small price to pay.

http://svn.digium.com/svn/menuselect/team/seanbright/libxml2/


- Sean


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


On July 14, 2014, 9:21 p.m., Matt Jordan wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/3773/
> ---
> 
> (Updated July 14, 2014, 9:21 p.m.)
> 
> 
> Review request for Asterisk Developers.
> 
> 
> Bugs: ASTERISK-20703
> https://issues.asterisk.org/jira/browse/ASTERISK-20703
> 
> 
> Repository: Asterisk
> 
> 
> Description
> ---
> 
> This patch removes menuselect as a subversion external repo and adds it 
> directly to the Asterisk source. This makes Asterisk substantially more git 
> friendly.
> 
> Asterisk is (I think) the only thing that uses menuselect still, as such, 
> keeping menuselect in a separate repository isn't strictly necessary any 
> longer. This patch also goes ahead and makes mxml a required library, 
> removing the need for the mxml repo.
> 
> Changes to menuselect were kept at a minimum - however, I opted to copy and 
> add the source files directly rather than attempting any particular svn 
> operation. That does mean we would lose the menuselect history for trunk (13) 
> onwards. I'm not sure how big of a loss that is, given the relative 
> infrequency with which changes are made (and the menuselect history isn't 
> gone, just disconnected...)
> 
> The only functional change with this patch: the menuselect UI is no longer 
> run automatically the first time around. I'm not sure how needed (or desired) 
> that is, since make menuselect is always available to configure settings.
> 
> Note that menuselect/mxml will continue to exist as separate repos for 
> existing Asterisk branches. We can always choose to backport this patch at 
> some future time to other branches, if the need arises.
> 
> 
> Diffs
> -
> 
>   /trunk/menuselect/test/menuselect-tree PRE-CREATION 
>   /trunk/menuselect/test/build_tools/menuselect-deps PRE-CREATION 
>   /trunk/menuselect/strcompat.c PRE-CREATION 
>   /trunk/menuselect/missing PRE-CREATION 
>   /trunk/menuselect/menuselect_stub.c PRE-CREATION 
>   /trunk/menuselect/menuselect_newt.c PRE-CREATION 
>   /trunk/menuselect/menuselect_gtk.c PRE-CREATION 
>   /trunk/menuselect/menuselect_curses.c PRE-CREATION 
>   /trunk/menuselect/menuselect.c PRE-CREATION 
>   /trunk/menuselect/menuselect.h PRE-CREATION 
>   /trunk/menuselect/makeopts.in PRE-CREATION 
>   /trunk/menuselect/makeopts PRE-CREATION 
>   /trunk/menuselect/make_version PRE-CREATION 
>   /trunk/menuselect/linkedlists.h PRE-CREATION 
>   /trunk/menuselect/install-sh PRE-CREATION 
>   /trunk/menuselect/example_menuselect-tree PRE-CREATION 
>   /trunk/menuselect/contrib/menuselect-dummy PRE-CREATION 
>   /trunk/menuselect/contrib/Makefile-dummy PRE-CREATION 
>   /trunk/menuselect/configure.ac PRE-CREATION 
>   /trunk/menuselect/configure PRE-CREATION 
>   /trunk/menuselect/config.sub PRE-CREATION 
>   /trunk/menuselect/config.log PRE-CREATION 
>   /trunk/menuselect/config.guess PRE-CREATION 
>   /trunk/menuselect/bootstrap.sh PRE-CREATION 
>   /trunk/menuselect/autoconfig.h.in PRE-CREATION 
>   /trunk/menuselect/autoconfig.h PRE-CREATION 
>   /trunk/menuselect/aclocal.m4 PRE-CREATION 
>   /trunk/menuselect/acinclude.m4 PRE-CREATION 
>   /trunk/menuselect/README PRE-CREATION 
>   /trunk/menuselect/Makefile PRE-CREATION 
>   /trunk/include/asterisk/autoconfig.h.in 418565 
>   /trunk/configure.ac 418565 
>   /trunk/configure UNKNOWN 
> 
> Diff: https://reviewboard.asterisk.org/r/3773/diff/
> 
> 
> Testing
> ---
> 
> 
> 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] 3773: Add menuselect to Asterisk, remove mxml

[Sean Bright]

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

Ship it!


Looks fine to me.  Should probably throw libmxml-dev into 
contrib/scripts/install_prereq while you're at it.  This also might be a good 
opportunity to dump mxml altogether as we already use libxml2 in asterisk 
itself.  One less dependency to install.

I'd be happy to take a crack at it if you don't have the bandwidth.

- Sean Bright


On July 14, 2014, 1:56 a.m., Matt Jordan wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/3773/
> ---
> 
> (Updated July 14, 2014, 1:56 a.m.)
> 
> 
> Review request for Asterisk Developers.
> 
> 
> Repository: Asterisk
> 
> 
> Description
> ---
> 
> This patch removes menuselect as a subversion external repo and adds it 
> directly to the Asterisk source. This makes Asterisk substantially more git 
> friendly.
> 
> Asterisk is (I think) the only thing that uses menuselect still, as such, 
> keeping menuselect in a separate repository isn't strictly necessary any 
> longer. This patch also goes ahead and makes mxml a required library, 
> removing the need for the mxml repo.
> 
> Changes to menuselect were kept at a minimum - however, I opted to copy and 
> add the source files directly rather than attempting any particular svn 
> operation. That does mean we would lose the menuselect history for trunk (13) 
> onwards. I'm not sure how big of a loss that is, given the relative 
> infrequency with which changes are made (and the menuselect history isn't 
> gone, just disconnected...)
> 
> The only functional change with this patch: the menuselect UI is no longer 
> run automatically the first time around. I'm not sure how needed (or desired) 
> that is, since make menuselect is always available to configure settings.
> 
> Note that menuselect/mxml will continue to exist as separate repos for 
> existing Asterisk branches. We can always choose to backport this patch at 
> some future time to other branches, if the need arises.
> 
> 
> Diffs
> -
> 
>   /trunk/menuselect/test/menuselect-tree PRE-CREATION 
>   /trunk/menuselect/test/build_tools/menuselect-deps PRE-CREATION 
>   /trunk/menuselect/strcompat.c PRE-CREATION 
>   /trunk/menuselect/missing PRE-CREATION 
>   /trunk/menuselect/menuselect_stub.c PRE-CREATION 
>   /trunk/menuselect/menuselect_newt.c PRE-CREATION 
>   /trunk/menuselect/menuselect_gtk.c PRE-CREATION 
>   /trunk/menuselect/menuselect_curses.c PRE-CREATION 
>   /trunk/menuselect/menuselect.c PRE-CREATION 
>   /trunk/menuselect/menuselect.h PRE-CREATION 
>   /trunk/menuselect/makeopts.in PRE-CREATION 
>   /trunk/menuselect/makeopts PRE-CREATION 
>   /trunk/menuselect/make_version PRE-CREATION 
>   /trunk/menuselect/linkedlists.h PRE-CREATION 
>   /trunk/menuselect/install-sh PRE-CREATION 
>   /trunk/menuselect/example_menuselect-tree PRE-CREATION 
>   /trunk/menuselect/contrib/menuselect-dummy PRE-CREATION 
>   /trunk/menuselect/contrib/Makefile-dummy PRE-CREATION 
>   /trunk/menuselect/configure.ac PRE-CREATION 
>   /trunk/menuselect/configure PRE-CREATION 
>   /trunk/menuselect/config.sub PRE-CREATION 
>   /trunk/menuselect/config.log PRE-CREATION 
>   /trunk/menuselect/config.guess PRE-CREATION 
>   /trunk/menuselect/bootstrap.sh PRE-CREATION 
>   /trunk/menuselect/autoconfig.h.in PRE-CREATION 
>   /trunk/menuselect/autoconfig.h PRE-CREATION 
>   /trunk/menuselect/aclocal.m4 PRE-CREATION 
>   /trunk/menuselect/acinclude.m4 PRE-CREATION 
>   /trunk/menuselect/README PRE-CREATION 
>   /trunk/menuselect/Makefile PRE-CREATION 
>   /trunk/include/asterisk/autoconfig.h.in 418565 
>   /trunk/configure.ac 418565 
>   /trunk/configure UNKNOWN 
> 
> Diff: https://reviewboard.asterisk.org/r/3773/diff/
> 
> 
> Testing
> ---
> 
> 
> 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] Bridge/0XXXXXX-in Bridge/0XXXXXX-out channels did not hanguped after call hanguped .

[Sean Bright]

https://issues.asterisk.org/

On 6/25/2014 5:50 AM, hkc323 wrote:

==
Centos 6
Asterisk 11.5.1
app:Confbridge
file:app_confbridge.c
===
issue :
Bridge/0xb75254f channels did not hanguped after call hanguped .

note1:After call hangup ast_bridge_change_state :2 which means Hangup
note2:Patch also note working

steps:
1)Nornal user Join
2)Hangup the Call.

kick_conference_participant(struct conference_bridge *bridge, const char
*channel)

myhost*CLI> confbridge kick 585261 SIP/500-
===
//---After 1st call start and join conference bridge ---//
myhost*CLI> core show channels
Channel  Location State   Application(Data)
Bridge/0xb75254f4-in s@default:1  Up  (None)
SIP/500- s@confbrindge-room:60 Up
MyConfbridge(585261,,adminuser
ConfBridgeRecorder/c s@default:1  Up  (None)
Bridge/0xb75254f4-ou s@default:1  Up  (None)
4 active channels
1 active call
1 call processed

//---log//
Inside bridge_bridgedchannel [2014-06-25 14:59:51] NOTICE[24968][C-
0001]:

  chan_bridge.c:82 bridge_bridgedchannel: Inside bridge_bridgedchannel
�
--  Playing 'confbridge-leave.slin' (language
'en')
 --
   inside handle_conf_user_leave  : USER_OPT_WAITMARKED
  �--
   CONF_STATE_INACTIVE.c insidsec  leave_waitmarked
 --
  # inside  conf_change_state
  �--
  Changing conference '585261' state from INACTIVE to EMPTY
bridging.c:1227 ast_bridge_remove: ===remove bridge channel using func
ast_bridge_change_state ===�

  -- inside  ast_bridge_change_state : arg1cursteat:0 arg2newstate:2 �--
   final  ast_bridge_change_state :2 �--
 -- Stopped music on hold on SIP/500-
 --  Playing 'conf-kicked.ulaw' (language 'en')
//--//

myhost*CLI> confbridge list
Conference Bridge Name   Users  Marked Locked?
 == == 
585261   1  1 unlocked

//---log of After Call Hangup//
myhost*CLI> confbridge list
Conference Bridge Name   Users  Marked Locked?
 == == 
myhost*CLI> core show channels
Channel  Location State   Application(Data)
Bridge/0xb75254f4-in s@default:1  Up  (None)
Bridge/0xb75254f4-ou s@default:1  Up  (None)
2 active channels
0 active calls
1 call processed





--
_
-- 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] libpri 1.4.15 Now Available

[Sean Bright]

On 6/16/2014 4:07 PM, Yves A. wrote:
Maybe the development team of libpri could remove the 35 char 
maxlength constraint when using USERUSERINFO
in the next release so I don´t have to patch it always... Or is there 
a specific reason for it? 


According to the Q.931 recommendation, user-user has a maximum length of 
either 35 or 131 octets.  The value is described as "network dependent" 
so 35 is probably the safer of the two.


--
_
-- 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] 3439: chan_sip: Support a=rtcp attribute in SDP

[Sean Bright]

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



/trunk/res/res_rtp_asterisk.c
<https://reviewboard.asterisk.org/r/3439/#comment21785>

Should this be an 'else if?'  If not it should be on its own line.


- Sean Bright


On May 16, 2014, 12:36 p.m., Olle E Johansson wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/3439/
> ---
> 
> (Updated May 16, 2014, 12:36 p.m.)
> 
> 
> Review request for Asterisk Developers.
> 
> 
> Repository: Asterisk
> 
> 
> Description
> ---
> 
> the A=rtcp attribute in SDP points out a different port than the mediaport+1 
> to receive RTCP on. This patch adds a new api to rtpengine and 
> res_rtp_asterisk and updates chan_sip to use it.
> 
> This patch needs to be modified to handle the IP address argument too.
> 
> 
> Diffs
> -
> 
>   /trunk/res/res_rtp_asterisk.c 412166 
>   /trunk/main/rtp_engine.c 412166 
>   /trunk/include/asterisk/rtp_engine.h 412166 
>   /trunk/channels/chan_sip.c 412166 
> 
> Diff: https://reviewboard.asterisk.org/r/3439/diff/
> 
> 
> Testing
> ---
> 
> A massive amount of testing with a test tool for interoperability.
> 
> 
> 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] 3491: res_pjsip: Allow cipher to be specified by name

[Sean Bright]

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

Ship it!


Ship It!

- Sean Bright


On April 29, 2014, 3:21 p.m., Joshua Colp wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/3491/
> ---
> 
> (Updated April 29, 2014, 3:21 p.m.)
> 
> 
> Review request for Asterisk Developers.
> 
> 
> Bugs: ASTERISK-23498
> https://issues.asterisk.org/jira/browse/ASTERISK-23498
> 
> 
> Repository: Asterisk
> 
> 
> Description
> ---
> 
> The "cipher" option in res_pjsip currently requires that the cipher be 
> specified using the OpenSSL identifier instead of the name. This change makes 
> it so that the name is turned into the respective identifier, allowing the 
> cipher option to accept the name instead!
> 
> 
> Diffs
> -
> 
>   /branches/12/res/res_pjsip/config_transport.c 413101 
> 
> Diff: https://reviewboard.asterisk.org/r/3491/diff/
> 
> 
> Testing
> ---
> 
> Before patch:
> 
> Configured cipher using name, received "Unsupported" log message.
> 
> After patch:
> 
> Configured cipher using name, received no log message.
> 
> 
> Thanks,
> 
> Joshua Colp
> 
>

-- 
_
-- 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] 3439: chan_sip: Support a=rtcp attribute in SDP

[Sean Bright]

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



/trunk/res/res_rtp_asterisk.c
<https://reviewboard.asterisk.org/r/3439/#comment21399>

Should this be an 'else if?'  If not it should be on its own line.


- Sean Bright


On April 11, 2014, 1:46 p.m., Olle E Johansson wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/3439/
> ---
> 
> (Updated April 11, 2014, 1:46 p.m.)
> 
> 
> Review request for Asterisk Developers.
> 
> 
> Repository: Asterisk
> 
> 
> Description
> ---
> 
> the A=rtcp attribute in SDP points out a different port than the mediaport+1 
> to receive RTCP on. This patch adds a new api to rtpengine and 
> res_rtp_asterisk and updates chan_sip to use it.
> 
> 
> Diffs
> -
> 
>   /trunk/res/res_rtp_asterisk.c 412166 
>   /trunk/main/rtp_engine.c 412166 
>   /trunk/include/asterisk/rtp_engine.h 412166 
>   /trunk/channels/chan_sip.c 412166 
> 
> Diff: https://reviewboard.asterisk.org/r/3439/diff/
> 
> 
> Testing
> ---
> 
> A massive amount of testing with a test tool for interoperability.
> 
> 
> 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] 3391: ARI: Don't complain about missing ARI users when we aren't enabled

[Sean Bright]

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

(Updated March 25, 2014, 1:44 p.m.)


Status
--

This change has been marked as submitted.


Review request for Asterisk Developers.


Changes
---

Committed in revision 411173


Repository: Asterisk


Description
---

Currently, if ARI is not enabled it will still complain that there are no 
configured users.  This patch checks to see if ARI is enabled before logging 
and error or iterating the container to validate the users.


Diffs
-

  /branches/12/res/ari/config.c 411084 

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


Testing
---

Basic runtime tests with ARI enabled and disabled.


Thanks,

Sean Bright

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

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

[asterisk-dev] [Code Review] 3391: ARI: Don't complain about missing ARI users when we aren't enabled

[Sean Bright]

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

Review request for Asterisk Developers.


Repository: Asterisk


Description
---

Currently, if ARI is not enabled it will still complain that there are no 
configured users.  This patch checks to see if ARI is enabled before logging 
and error or iterating the container to validate the users.


Diffs
-

  /branches/12/res/ari/config.c 411084 

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


Testing
---

Basic runtime tests with ARI enabled and disabled.


Thanks,

Sean Bright

-- 
_
-- 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] 3372: Allow local ICE candidates to be overridden with specified address

[Sean Bright]

On 3/19/2014 6:41 AM, Olle E. Johansson wrote:

On 19 Mar 2014, at 11:34, Sean Bright  wrote:


On 3/19/2014 6:30 AM, Olle E. Johansson wrote:

The major one being that ICE was create so that we don't have to mess around 
like this. The external IP is just a server-reflexive address. You may want to 
make a decision on what you prefer in the C-line depending on the old logic - 
what's the most likely address we're going to end up with?

With externaddr/externhost in chan_sip you are effectively hiding the fact that 
Asterisk is behind a NAT device.  Creating the ICE candidate list using the 
local interfaces leaks information that you might not want getting leaked.  The 
goal of this patch was to make Asterisk appear to be sitting on the public 
internet.  I've been running it successfully for a few months, but it's not 
ready for public consumption in it's current state.


That's a point. I've always been complaining to soft phone guys that the add a 
lot of useless ICE candidates from various strange interfaces on my OS/X 
created by Pararells, VMware and strange bridges I play with. I should be able 
to choose what to expose, as a long list affects call set up time.


Yes, call setup time from a client on my local workstation takes a good 
10-12 seconds because of VMWare workstation virtual interfaces.



What you are going to miss is the ability to set up media in the best possible 
way with a local phone that still use STUN and use a server reflexive address 
in SIP.


Right, but in my environment all of the clients are on the other side of 
the NAT, so knowing the host address is useless.  Are host candidates 
specifically required by ICE?  If not, a cleaner approach might be to 
simply exclude them altogether and use only the reflexive and relayed 
candidates.


--
_
-- 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] 3372: Allow local ICE candidates to be overridden with specified address

[Sean Bright]

On 3/19/2014 6:30 AM, Olle E. Johansson wrote:
The major one being that ICE was create so that we don't have to mess 
around like this. The external IP is just a server-reflexive address. 
You may want to make a decision on what you prefer in the C-line 
depending on the old logic - what's the most likely address we're 
going to end up with?


With externaddr/externhost in chan_sip you are effectively hiding the 
fact that Asterisk is behind a NAT device.  Creating the ICE candidate 
list using the local interfaces leaks information that you might not 
want getting leaked.  The goal of this patch was to make Asterisk appear 
to be sitting on the public internet.  I've been running it successfully 
for a few months, but it's not ready for public consumption in it's 
current state.


--
_
-- 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] 3372: Allow local ICE candidates to be overridden with specified address

[Sean Bright]

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

(Updated March 19, 2014, 10:27 a.m.)


Status
--

This change has been discarded.


Review request for Asterisk Developers.


Repository: Asterisk


Description
---

When Asterisk's public IP address is known, such as in a static NAT topology, 
it still uses the machine's local interfaces as host candidates for ICE 
negotiation.  This patch introduces a new configuration option to rtp.conf - 
externaddr - that allows the user to configure their external IP address, 
similar to externaddr in sip.conf.  res_rtp_asterisk will then use this address 
as the host candidate rather than using the local interfaces and STUN.


Diffs
-

  /trunk/res/res_rtp_asterisk.c 410875 
  /trunk/CHANGES 410875 

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


Testing
---

Ran in a static NAT environment with externaddr set and media setup succeeded 
as expected.


Thanks,

Sean Bright

-- 
_
-- 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] 3372: Allow local ICE candidates to be overridden with specified address

[Sean Bright]

> On March 18, 2014, 5:33 p.m., Sean Bright wrote:
> > I hadn't considered multihomed machines when I wrote this patch, so that 
> > might throw a wrench in this.

There are a log of things wrong with this.  Going to re-think it some.


- Sean


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


On March 18, 2014, 5:04 p.m., Sean Bright wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/3372/
> ---
> 
> (Updated March 18, 2014, 5:04 p.m.)
> 
> 
> Review request for Asterisk Developers.
> 
> 
> Repository: Asterisk
> 
> 
> Description
> ---
> 
> When Asterisk's public IP address is known, such as in a static NAT topology, 
> it still uses the machine's local interfaces as host candidates for ICE 
> negotiation.  This patch introduces a new configuration option to rtp.conf - 
> externaddr - that allows the user to configure their external IP address, 
> similar to externaddr in sip.conf.  res_rtp_asterisk will then use this 
> address as the host candidate rather than using the local interfaces and STUN.
> 
> 
> Diffs
> -
> 
>   /trunk/res/res_rtp_asterisk.c 410875 
>   /trunk/CHANGES 410875 
> 
> Diff: https://reviewboard.asterisk.org/r/3372/diff/
> 
> 
> Testing
> ---
> 
> Ran in a static NAT environment with externaddr set and media setup succeeded 
> as expected.
> 
> 
> Thanks,
> 
> Sean Bright
> 
>

-- 
_
-- 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] 3372: Allow local ICE candidates to be overridden with specified address

[Sean Bright]

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


I hadn't considered multihomed machines when I wrote this patch, so that might 
throw a wrench in this.

- Sean Bright


On March 18, 2014, 5:04 p.m., Sean Bright wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/3372/
> ---
> 
> (Updated March 18, 2014, 5:04 p.m.)
> 
> 
> Review request for Asterisk Developers.
> 
> 
> Repository: Asterisk
> 
> 
> Description
> ---
> 
> When Asterisk's public IP address is known, such as in a static NAT topology, 
> it still uses the machine's local interfaces as host candidates for ICE 
> negotiation.  This patch introduces a new configuration option to rtp.conf - 
> externaddr - that allows the user to configure their external IP address, 
> similar to externaddr in sip.conf.  res_rtp_asterisk will then use this 
> address as the host candidate rather than using the local interfaces and STUN.
> 
> 
> Diffs
> -
> 
>   /trunk/res/res_rtp_asterisk.c 410875 
>   /trunk/CHANGES 410875 
> 
> Diff: https://reviewboard.asterisk.org/r/3372/diff/
> 
> 
> Testing
> ---
> 
> Ran in a static NAT environment with externaddr set and media setup succeeded 
> as expected.
> 
> 
> Thanks,
> 
> Sean Bright
> 
>

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

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

[asterisk-dev] [Code Review] 3372: Allow local ICE candidates to be overridden with specified address

[Sean Bright]

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

Review request for Asterisk Developers.


Repository: Asterisk


Description
---

When Asterisk's public IP address is known, such as in a static NAT topology, 
it still uses the machine's local interfaces as host candidates for ICE 
negotiation.  This patch introduces a new configuration option to rtp.conf - 
externaddr - that allows the user to configure their external IP address, 
similar to externaddr in sip.conf.  res_rtp_asterisk will then use this address 
as the host candidate rather than using the local interfaces and STUN.


Diffs
-

  /trunk/res/res_rtp_asterisk.c 410875 
  /trunk/CHANGES 410875 

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


Testing
---

Ran in a static NAT environment with externaddr set and media setup succeeded 
as expected.


Thanks,

Sean Bright

-- 
_
-- 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] mjordan: branch 11 r409990 - /branches/11/res/res_fax_spandsp.c

[Sean Bright]

On 3/17/2014 9:48 AM, Matthew Jordan wrote:

Ugh. That stinks - there was no g711_free in 0.0.5.

Looks like we're going to need a patch for this that examines the
libspandsp version and uses one or the other.


This has been fixed:

http://svnview.digium.com/svn/asterisk?view=revision&revision=410829

Sean

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

[Sean Bright]

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

Ship it!


Ship It!

- Sean Bright


On March 17, 2014, 1:15 p.m., Joshua Colp wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/3343/
> ---
> 
> (Updated March 17, 2014, 1:15 p.m.)
> 
> 
> Review request for Asterisk Developers.
> 
> 
> Bugs: ASTERISK-23435
> https://issues.asterisk.org/jira/browse/ASTERISK-23435
> 
> 
> Repository: Asterisk
> 
> 
> Description
> ---
> 
> This change adds a configuration option for setting nameservers to be used by 
> the PJSIP DNS client. If this option is not set then the system nameservers 
> are retrieved and used instead.
> 
> This also allows the nameservers to be changed by doing a reload.
> 
> In case others are wondering as Olle was:
> 
> PJLIB-Util (part of pjproject) provides a DNS client which can optionally 
> (but is highly suggested) to be used with PJSIP. It provides asynchronous 
> DNS, SRV lookups, multiple record support, etc. Right now this isn't enabled 
> so we are simply doing A/ record lookups. The reason it's not enabled is 
> that explicit nameservers *must* be provided to it when enabling it. It will 
> not use the system ones by itself. The change up on reviewboard enables it by 
> default using the system nameservers it finds, but with the ability to 
> override or completely disable it if a user wants. The reason I also provide 
> reload functionality is that people in #asterisk-dev expressed a concern that 
> users may change nameservers but don't want to restart Asterisk, which is 
> understandable. 
> 
> 
> Diffs
> -
> 
>   /branches/12/res/res_pjsip/include/res_pjsip_private.h 410470 
>   /branches/12/res/res_pjsip/config_system.c 410470 
>   /branches/12/res/res_pjsip/config_global.c 410470 
>   /branches/12/res/res_pjsip.c 410470 
>   /branches/12/main/dns.c 410470 
>   /branches/12/include/asterisk/dns.h 410470 
>   /branches/12/CHANGES 410470 
> 
> Diff: https://reviewboard.asterisk.org/r/3343/diff/
> 
> 
> Testing
> ---
> 
> Explicitly set nameservers and confirmed they were used by PJSIP. Disabled it 
> and confirmed that the DNS client was disabled. Set to auto (explicitly and 
> by default) and confirmed that the system nameservers were used.
> 
> 
> Thanks,
> 
> Joshua Colp
> 
>

-- 
_
-- 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] DNS & PJSIP

[Sean Bright]

On 3/17/2014 5:47 AM, Olle E. Johansson wrote:

- We are still in control of our own product and make our own decisions about Asterisk 
architecture. Any arguments like "PJSIP has it so we have to enable it" falls 
to the ground as not valid and disappear in a cloud of smoke.


Those that are in control of the project are those that contribute and 
move the project forward.  No one has used the phrase "PJSIP has it so 
we have to enable it."  PJSIP's resolver being enabled is better for 
users.  Full stop.



- No one has given any reasons why we should be able to configure DNS servers 
in the PJSIP channel configuration, apart from Jared who wanted to let users 
shoot themself in the feet. That is not the way I treat my users. I think most 
of us now agree that we don't want to have that configuration item.


res_init/res_ninit have not been identified as being available across 
all of the platforms that Asterisk currently supports. Providing users 
the ability to specify the name servers _when they can not be 
automatically discovered_ is a Good Thing (tm).



- In the long run, having a DNS resolver embedded in a module is not a good 
thing. Due to the PJSIP architecture, it's very hard to avoid. I've spoken with 
several non-asterisk developers using PJSIP that have partly succeeded, but not 
fully. We need to stress this to pjsip so that they can separate this code in 
the future.

- Having PJSIP parse /etc/resolv.conf is not a good thing. If that can't be 
avoided, we need to monitor the file for updates from Asterisk and reconfigure.


PJSIP does not parse /etc/resolv.conf.


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

[Sean Bright]

On 3/14/2014 10:02 AM, Olle E. Johansson wrote:
It would mean continuing to maintain Asterisk's pjproject fork until 
those changes were (hopefully) accepted upstream, released, and then 
waiting for the rpm/deb packages to catch up.  Not to mention that 
someone would actually have to _do_ all of this work.  Could all 
volunteers please raise their hands? ;-)


If this is how we are going to manage our product then I'm getting 
really worried. Are we controlling our own software?


I'm not sure why you are getting worried.  If you would like to improve 
the DNS resolver within Asterisk are you not free to do so?


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

[Sean Bright]

On 3/14/2014 2:41 AM, Olle E. Johansson wrote:


On 13 Mar 2014, at 22:13, Sean Bright <mailto:sean.bri...@gmail.com>> wrote:



On 3/13/2014 4:42 PM, Paul Belanger wrote:

+1 with Dan.  Comments aside on DNS functionality (I have opinions but
sitting this one out). Any functionality should be channel agnostic.
I too am a little concern'd that statement seems to have changed.


In order to make this "channel agnostic" you have three (equally bad) 
options:


 1. Replace Asterisk's internal DNS facilities with PJLIB's, creating
a mandatory dependency on PJSIP.
 2. Roll a shiny new DNS API into Asterisk that supports all address
types (multiple results, weighting, etc.). Bear in mind that
PJSIP would not use this new API at all, you would still need to
create a PJLIB DNS resolver and feed it the nameservers to use.
 3. Use PJLIB's DNS interface if it is available, otherwise fall back
to Asterisk's current DNS interface.  This means that you are now
maintaining two separate interfaces and have to throw a layer of
abstraction in while you're at it.  In fact, by adding an
abstraction layer you would force res_pjsip to then unwrap and
then re-wrap the abstraction just to get at the necessary PJLIB
data structures.

Frankly, I don't see what all the hubbub is about.  99.9% of users 
will never touch the nameservers configuration option and it will 
behave exactly as if the system resolver was being used.



If there is a configuration people will teach it and people will use 
it. Later on, the sysadmin change /etc/resolv.conf since the DNS 
servers used change and PJsip stops working. This is not a good 
solution. There's no reason for that configuration option at all. No 
one has stepped forward to explain a situation where it would be 
needed, right?


Even if the 'nameservers' configuration option is removed and Asterisk 
defaults to using the results of res_[n]init, an administrator changing 
the name servers in /etc/resolv.conf will not automatically be picked up 
by PJLIB's resolver.  A reload of some kind would still be required to 
pick up the changes.


Regarding the resolver issue, I have no clear indication on where to 
go. I only know I don't want to support a product with multiple 
resolvers in it. I'm currently working on adding proper SRV support to 
the old SIP driver and have been digging through a lot of the DNS 
code. If you ask me today, anything will be better, even a core 
dependency on PJSIP. ;-)


That's a bit like rearranging the deck chairs on the Titanic.  Why would 
anyone continue to use chan_sip when chan_pjsip is available?


There are other options for asynch DNS too - like C-ARES. It's used in 
a lot of products and embedded in Resiprocate.


Regarding changing PJSIP - it's just code, right? Why can't you change 
PJSIP to use another API? That's a very strange statement.


You certainly could do that, but it's a lot of work for very little 
gain.  It would mean continuing to maintain Asterisk's pjproject fork 
until those changes were (hopefully) accepted upstream, released, and 
then waiting for the rpm/deb packages to catch up. Not to mention that 
someone would actually have to _do_ all of this work.  Could all 
volunteers please raise their hands? ;-)


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

[Sean Bright]

On 3/13/2014 4:42 PM, Paul Belanger wrote:

+1 with Dan.  Comments aside on DNS functionality (I have opinions but
sitting this one out). Any functionality should be channel agnostic.
I too am a little concern'd that statement seems to have changed.


In order to make this "channel agnostic" you have three (equally bad) 
options:


1. Replace Asterisk's internal DNS facilities with PJLIB's, creating a
   mandatory dependency on PJSIP.
2. Roll a shiny new DNS API into Asterisk that supports all address
   types (multiple results, weighting, etc.).  Bear in mind that PJSIP
   would not use this new API at all, you would still need to create a
   PJLIB DNS resolver and feed it the nameservers to use.
3. Use PJLIB's DNS interface if it is available, otherwise fall back to
   Asterisk's current DNS interface.  This means that you are now
   maintaining two separate interfaces and have to throw a layer of
   abstraction in while you're at it.  In fact, by adding an
   abstraction layer you would force res_pjsip to then unwrap and then
   re-wrap the abstraction just to get at the necessary PJLIB data
   structures.

Frankly, I don't see what all the hubbub is about.  99.9% of users will 
never touch the nameservers configuration option and it will behave 
exactly as if the system resolver was being used.


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

[Sean Bright]

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

Ship it!


Looks good to me.  Now if only we could have it automatically update with 
/etc/resolv.conf is changed...


/branches/12/res/res_pjsip/config_global.c
<https://reviewboard.asterisk.org/r/3343/#comment20797>

The comment and function name are stale, but this was already resolved in 
your development branch.  Just pointing it out.


- Sean Bright


On March 13, 2014, 10:42 a.m., Joshua Colp wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/3343/
> ---
> 
> (Updated March 13, 2014, 10:42 a.m.)
> 
> 
> Review request for Asterisk Developers.
> 
> 
> Bugs: ASTERISK-23435
> https://issues.asterisk.org/jira/browse/ASTERISK-23435
> 
> 
> Repository: Asterisk
> 
> 
> Description
> ---
> 
> This change adds a configuration option for setting nameservers to be used by 
> the PJSIP DNS client. If this option is not set then the system nameservers 
> are retrieved and used instead.
> 
> This also allows the nameservers to be changed by doing a reload.
> 
> In case others are wondering as Olle was:
> 
> PJLIB-Util (part of pjproject) provides a DNS client which can optionally 
> (but is highly suggested) to be used with PJSIP. It provides asynchronous 
> DNS, SRV lookups, multiple record support, etc. Right now this isn't enabled 
> so we are simply doing A/ record lookups. The reason it's not enabled is 
> that explicit nameservers *must* be provided to it when enabling it. It will 
> not use the system ones by itself. The change up on reviewboard enables it by 
> default using the system nameservers it finds, but with the ability to 
> override or completely disable it if a user wants. The reason I also provide 
> reload functionality is that people in #asterisk-dev expressed a concern that 
> users may change nameservers but don't want to restart Asterisk, which is 
> understandable. 
> 
> 
> Diffs
> -
> 
>   /branches/12/res/res_pjsip/pjsip_configuration.c 410470 
>   /branches/12/res/res_pjsip/include/res_pjsip_private.h 410470 
>   /branches/12/res/res_pjsip/config_global.c 410470 
>   /branches/12/res/res_pjsip.c 410470 
>   /branches/12/main/dns.c 410470 
>   /branches/12/include/asterisk/dns.h 410470 
>   /branches/12/configs/pjsip.conf.sample 410470 
>   /branches/12/CHANGES 410470 
> 
> Diff: https://reviewboard.asterisk.org/r/3343/diff/
> 
> 
> Testing
> ---
> 
> Explicitly set nameservers and confirmed they were used by PJSIP. Disabled it 
> and confirmed that the DNS client was disabled. Set to auto (explicitly and 
> by default) and confirmed that the system nameservers were used.
> 
> 
> Thanks,
> 
> Joshua Colp
> 
>

-- 
_
-- 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] 2723: Add pass through support for both VP8 and Opus

[Sean Bright]

> On Jan. 16, 2014, 5:16 p.m., Sean Bright wrote:
> > /trunk/channels/chan_sip.c, lines 13419-13421
> > <https://reviewboard.asterisk.org/r/2723/diff/5/?file=44381#file44381line13419>
> >
> > Shouldn't this be &a_audio instead of &a_text, or does it matter?
> 
> Matt Jordan wrote:
> Good catch - feel free to patch away

Committed in r405877 (12)/r405878 (trunk)


- Sean


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


On Aug. 23, 2013, 3:42 p.m., Matt Jordan wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/2723/
> ---
> 
> (Updated Aug. 23, 2013, 3:42 p.m.)
> 
> 
> Review request for Asterisk Developers, Joshua Colp and Mark Michelson.
> 
> 
> Bugs: ASTERISK-21981
> https://issues.asterisk.org/jira/browse/ASTERISK-21981
> 
> 
> Repository: Asterisk
> 
> 
> Description
> ---
> 
> Note: This patch was written by Lorenzo Miniero. I know he's at the IETF this 
> week, but I figured we could get the formal code review going for him :-)
> 
> This patch adds pass through support for Opus and VP8. That includes:
> * Format attribute negotiation for Opus. Note that unlike some other codecs, 
> the draft RFC specifies having spaces delimiting the attributes in addition 
> to ';', so you have "attra=X; attrb=Y". This broke the attribute parsing in 
> chan_sip, so a small tweak was also included in this patch for that.
> * A format attribute negotiation module for Opus
> * Fast picture update for VP8. Since VP8 uses a different RTCP packet number 
> than FIR, this really is specific to VP8 at this time. Ideally this would be 
> more generic and flexible for user preferences and other video codecs, but 
> that could be done at a latter date.
> 
> The only part of this work that I did was port over the fast picture update 
> code to chan_pjsip. I *think* that chan_pjsip will still suck out the 
> attributes in res_pjsip_sdp_rtp, but I could be mistaken (Josh?)
> 
> 
> Diffs
> -
> 
>   /trunk/res/res_rtp_asterisk.c 397424 
>   /trunk/res/res_pjsip_sdp_rtp.c 397424 
>   /trunk/res/res_format_attr_opus.c PRE-CREATION 
>   /trunk/main/rtp_engine.c 397424 
>   /trunk/main/frame.c 397424 
>   /trunk/main/format.c 397424 
>   /trunk/main/channel.c 397424 
>   /trunk/include/asterisk/opus.h PRE-CREATION 
>   /trunk/include/asterisk/format.h 397424 
>   /trunk/channels/chan_sip.c 397424 
>   /trunk/channels/chan_pjsip.c 397424 
> 
> Diff: https://reviewboard.asterisk.org/r/2723/diff/
> 
> 
> Testing
> ---
> 
> 
> 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] 2723: Add pass through support for both VP8 and Opus

[Sean Bright]

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



/trunk/channels/chan_sip.c
<https://reviewboard.asterisk.org/r/2723/#comment20096>

Shouldn't this be &a_audio instead of &a_text, or does it matter?


- Sean Bright


On Aug. 23, 2013, 3:42 p.m., Matt Jordan wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://reviewboard.asterisk.org/r/2723/
> ---
> 
> (Updated Aug. 23, 2013, 3:42 p.m.)
> 
> 
> Review request for Asterisk Developers, Joshua Colp and Mark Michelson.
> 
> 
> Bugs: ASTERISK-21981
> https://issues.asterisk.org/jira/browse/ASTERISK-21981
> 
> 
> Repository: Asterisk
> 
> 
> Description
> ---
> 
> Note: This patch was written by Lorenzo Miniero. I know he's at the IETF this 
> week, but I figured we could get the formal code review going for him :-)
> 
> This patch adds pass through support for Opus and VP8. That includes:
> * Format attribute negotiation for Opus. Note that unlike some other codecs, 
> the draft RFC specifies having spaces delimiting the attributes in addition 
> to ';', so you have "attra=X; attrb=Y". This broke the attribute parsing in 
> chan_sip, so a small tweak was also included in this patch for that.
> * A format attribute negotiation module for Opus
> * Fast picture update for VP8. Since VP8 uses a different RTCP packet number 
> than FIR, this really is specific to VP8 at this time. Ideally this would be 
> more generic and flexible for user preferences and other video codecs, but 
> that could be done at a latter date.
> 
> The only part of this work that I did was port over the fast picture update 
> code to chan_pjsip. I *think* that chan_pjsip will still suck out the 
> attributes in res_pjsip_sdp_rtp, but I could be mistaken (Josh?)
> 
> 
> Diffs
> -
> 
>   /trunk/res/res_rtp_asterisk.c 397424 
>   /trunk/res/res_pjsip_sdp_rtp.c 397424 
>   /trunk/res/res_format_attr_opus.c PRE-CREATION 
>   /trunk/main/rtp_engine.c 397424 
>   /trunk/main/frame.c 397424 
>   /trunk/main/format.c 397424 
>   /trunk/main/channel.c 397424 
>   /trunk/include/asterisk/opus.h PRE-CREATION 
>   /trunk/include/asterisk/format.h 397424 
>   /trunk/channels/chan_sip.c 397424 
>   /trunk/channels/chan_pjsip.c 397424 
> 
> Diff: https://reviewboard.asterisk.org/r/2723/diff/
> 
> 
> Testing
> ---
> 
> 
> 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] Bug #9650 - no ringing on transfer

[Sean Bright]

Not sure if you saw or not, but file updated the issue in mantis:

"Fixed in 1.4 as of revision 90548 and trunk as of revision 90550."

On Dec 5, 2007 4:08 PM, Nic Bellamy <[EMAIL PROTECTED]> wrote:

> This bug has been closed by "file" with the comment "This has been fixed
> in 1.4 and trunk."
>
> There's no indication of what SVN revision it was fixed in, and nothing
> about bug #9650 in the SVN logs for either branches/asterisk-1.4 or trunk.
>
> Can someone please elaborate? I'd like to fix this for a customer of
> ours, but I'm not in the business of upgrading production customers
> willy-nilly (ie. I actually want to read the diff).
>
> Cheers,
>Nic.
>
> --
> Nic Bellamy,
> Head Of Engineering, Vadacom Ltd - http://www.vadacom.co.nz/
>
>
> ___
> --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] Need help regarding G.729 Codec purchase

[Sean Bright]

Um...

http://store.digium.com/productview.php?category_id=5&product_code=8G729CODEC&main_category_id=5

On Nov 15, 2007 10:59 AM, Lokesh Agrawal <[EMAIL PROTECTED]> wrote:

> Hi All,
>
> I want to purchase commercial license of G.729 Codec through Digium. Can
> anyone help me for the same and tell me the price of it.
>
> Thanx in advance.
>
>
> --
> Regards
> Lokesh Agrawal
>
>
> ---
> "Dream is not what you see in sleep, is the the thing which does not let
> you sleep"
> ---
>
> ___
> --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] Difference between trunk and branch/1.4

[Sean Bright]

The trunk version of chan_mobile is designed to work with the trunk version
of asterisk, not the 1.4 branch of asterisk.  You can try an older revision
of chan_mobile and see if that works for you:

http://svn.digium.com/view/asterisk-addons/trunk/chan_mobile.c?revision=425

Try that one.

On 10/22/07, Tony Plack <[EMAIL PROTECTED]> wrote:
>
> I am wondering what the difference in the svn between trunk and branch/1.4
>
> I am trying to compile the addons for the chan_mobile.  This is only in
> trunk.
>
> I currently run the 86755 version of branch/1.4 on my test system (just
> did the update) and I just pulled the trunk version of asterisk-addons.
>
> I am getting an error:
> chan_mobile.c:1846: error: too many arguments to function
> `ast_config_load'
>
> This usually means to me that the asterisk version I have is not up to
> date with the other version.
>
> Guess the real question becomes if this is just a bug in the chan_mobile.c
> code.  I would hate to go back to an older version if trunk is older than
> branch/1.4 and not sure I want to be as current as trunk if it newer.
>
> Thanks.
>
> ___
> --Bandwidth and Colocation Provided by http://www.api-digital.com--
>
> asterisk-dev mailing list
> To UNSUBSCRIBE or update options visit:
>   http://lists.digium.com/mailman/listinfo/asterisk-dev
>
___
--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 retry value

[Sean Bright]

Hi Steve,

Thank you for the tips, but I think you may have misunderstood my original
e-mail.

My original question had nothing to do with not liking the rationale behind
why that design decision was made, but simply not actually _knowing_ the
reason behind that decision.

Obviously, I have already changed app_queue to allow the 'retry' value to be
0, and have tested it successfully in my local development environment (If
you'd like a patch against trunk or one of the release branches, I would be
happy to share.  Its just a one-liner.).  So far, I have experienced no
notable side effects.  That being said, it _is_ simply a development
environment that isn't under any significant load, so I can't be sure
without testing in a production environment.

And that is the reason I asked here.  There was a reason that the original
author decided not to allow 'retry' values of 0, and that may be because it
causes problems elsewhere in the PBX.  That is the information I was after,
so I can avoid pushing code into production that might bring the PBX down.

Once I get that information (or I am at least satisfied that my change will
not adversely affect the production environment) I will be happy to submit a
patch to the bug tracker.  My disclaimer has been on file for months, so
that won't be a problem.

Thanks again for your response!
Sean

On 7/18/07, Steve Totaro <[EMAIL PROTECTED]> wrote:


Sean,

The beauty of open source software is the ability to change it.   If you
do not like the "rationale", you can sign a disclaimer and submit a
patch to bugtracker for consideration of inclusion.

I am sure you will get much more feedback in that forum from developers
and bug marshals (unless of course they just close it with no
explanation ;-)

Thanks,
Steve Totaro

Sean Bright wrote:
> Awesome.  Thanks a bunch.
>
> On 7/17/07, *Sean Bright* <[EMAIL PROTECTED]
> <mailto:[EMAIL PROTECTED]>> wrote:
>
> Hey guys,
>
> I know this is the "wrong" list, but I'm more interested in the
> rationale behind this decision...
>
> Why is the 'retry' value in queues.conf limited to values > 0?  I
> am using rrmemory with a queue, and I am forced to wait at least 1
> second between attempts to contact the next agent in line.  I can
> take this question to the -users list if necessary, but I doubt
> I'll get a satisfactory response there.
>
> Thanks,
> Sean
>
>
> 
>
> ___
> --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

___
--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 retry value

[Sean Bright]

Awesome.  Thanks a bunch.

On 7/17/07, Sean Bright <[EMAIL PROTECTED]> wrote:


Hey guys,

I know this is the "wrong" list, but I'm more interested in the rationale
behind this decision...

Why is the 'retry' value in queues.conf limited to values > 0?  I am using
rrmemory with a queue, and I am forced to wait at least 1 second between
attempts to contact the next agent in line.  I can take this question to the
-users list if necessary, but I doubt I'll get a satisfactory response
there.

Thanks,
Sean

___
--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] Re: [asterisk-commits] oej: branch group/astridevcon2007 r65399 - /team/group/astridevcon2007/

[Sean Bright]

(And I have a disclaimer on file ;-)

On 5/22/07, Sean Bright <[EMAIL PROTECTED]> wrote:



+Meetings in small groups to cover one topic, in the afternoon - propably
> in the autrium outside of the
> +lab room



Sure you didn't mean "...probably in the atrium...?" :-)


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

[asterisk-dev] Re: [asterisk-commits] oej: branch group/astridevcon2007 r65399 - /team/group/astridevcon2007/

[Sean Bright]

+Meetings in small groups to cover one topic, in the afternoon - propably
in the autrium outside of the
+lab room




Sure you didn't mean "...probably in the atrium...?" :-)
___
--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] Transfer a call

[Sean Bright]

We got it the first time you sent it, thanks :)

You're more likely to get a timely response if you direct this to the
correct mailing list.  Specifically the asterisk-users mailing list.

Good luck,
Sean

On 5/22/07, Ram Narayan Mishra <[EMAIL PROTECTED]> wrote:


 Dear All,

I have installed Asterisk 1.2 on a server pc and I have created three
extensions 111,142,150. I have installed X-Lite soft phone on three separate
pcs on LAN. I have configured these extensions on these pcs. Communication
is possible successfully.Now I want to transfer a call from one soft phone
to other and I have written a AGI in perl (test.plx) as

#! usr/bin/perl
use Asterisk::AGI;
my %agi = new Asterisk::AGI;
$agi->setcallback(/&callback);
$agi->answer();
$agi->exec('Playback','ss-noservice');
$agi->exec('Transfer','SIP/111');
sub callback()
{
warn "Line droped";
exit;
}

I have changed the extensions.conf in [incoming] section
exten=>142,1,AGI(test.plx)
exten=>142,2,Hangup()

When I dial 142 from 150 soft phone then 'ss-noservice' file played
successfully but transfer failed. Can any body help to transfer the call
from one soft phone to another. Thanks in advance.

Thanks & Regards,
Ram Narayan Mishra


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


___
--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] RTP bridiging optimization

[Sean Bright]

I wonder if you considered sending the same message to the same mailing list
3 times in a row?

(Yes, I know I am not helpful.)

On 5/10/07, Vadim Lebedev <[EMAIL PROTECTED]> wrote:


Hello

I wonder if somebody considered to optimize rtp bridging using Linux
splice and tee syscalls?

Thanks
Vadim
___
--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

___
--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] compile asterisk in arm-linux

[Sean Bright]

This type of question should be directed to the asterisk-users list from now
on...

That being said, a search for "asterisk termcap support not found" on google
yields plenty of results.  All suggesting that installing ncurses and
ncurses-devel will resolve this problem.

On 5/10/07, lizhong zhu <[EMAIL PROTECTED]> wrote:


hello, all asteriskers:
i want to compile asterisk under arm-linux. i make a change in Makefile.
some errors came out. i have an other asterisk in my system, it works, which
means all support should be ready. anyone knows this problem?
checking for gcc... /usr/local/arm-linux/bin/arm-linux-gcc
checking whether the C compiler (/usr/local/arm-linux/bin/arm-linux-gcc  )
works... yes
checking whether the C compiler (/usr/local/arm-linux/bin/arm-linux-gcc  )
is a cross-compiler... yes
checking whether we are using GNU C... yes
checking whether /usr/local/arm-linux/bin/arm-linux-gcc accepts -g... yes
checking how to run the C preprocessor...
/usr/local/arm-linux/bin/arm-linux-gcc -E
checking host system type... i686-pc-linux-gnu
checking for a BSD compatible install... install
checking for ranlib... /usr/local/arm-linux/bin/arm-linux-ranlib
checking for ar... /usr/local/arm-linux/bin/arm-linux-ar
checking for tgetent in -ltermcap... no
checking for tgetent in -ltinfo... no
checking for tgetent in -lcurses... no
checking for tgetent in -lncurses... no
configure: error: termcap support not found
make: *** [editline/libedit.a] Error 1
thanks!
zhulizhong

--
抢注雅虎免费邮箱3.5G容量，20M附件！ 


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


___
--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] Error while setup asterisk

[Sean Bright]

This is a known bug in GNU make.  You need to upgrade.

On 4/23/07, Mahmoud Shouman <[EMAIL PROTECTED]> wrote:


 Dear All,



Kindly note that I have the below error while setup asterisk



make[2]: Leaving directory `/usr/local/src/asterisk-1.4.0/menuselect'

make[1]: Leaving directory `/usr/local/src/asterisk-1.4.0/menuselect'

Generating input for menuselect ...

menuselect/menuselect --check-deps   menuselect.makeopts

Generating embedded module rules ...

   [CC] astman.c -> astman.o

   [CC] md5.c -> md5.o

   [LD] astman.o md5.o -> astman

   [CC] smsq.c -> smsq.o

   [CC] strcompat.c -> strcompat.o

   [LD] smsq.o strcompat.o -> smsq

   [CC] stereorize.c -> stereorize.o

   [CC] frame.c -> frame.o

   [LD] stereorize.o frame.o -> stereorize

   [CC] streamplayer.c -> streamplayer.o

   [LD] streamplayer.o -> streamplayer

make: expand.c:489: allocated_variable_append: Assertion

`current_variable_set_list->next != 0' failed.

make: *** [utils] Aborted





so please advice



Thanks & best regards,

Mahmoud Shouman



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


___
--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] LDAPget in Asterisk

[Sean Bright]

Sravana,

You'll want to direct this question to the correct people, the
asterisk-users mailing list.  The asterisk-dev list has to do with the
development _of_ Asterisk, not developing _with_ Asterisk.  Good luck.

Sean

On 4/2/07, sravana <[EMAIL PROTECTED]> wrote:


Hi All,
Anybody have experience on LDAPget in Asterisk? Is it authentication
mechanism or not? After getting the details from LDAP, how can use those
details in Asterisk? Can anyone explain mail purpose of LDAPget in
Asterisk?

Thanks in advance
--
Sravana
___
--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

___
--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] please tell me

[Sean Bright]

Hello Mehul,

This is not the correct mailing list for this type of question.  If you post
this message to the asterisk-users list, you are much more likely to receive
a helpful response.

Good luck,
Sean

On 3/21/07, mehul shah <[EMAIL PROTECTED]> wrote:


Hello ,
 i installed astrisk 1.4.1 , but i want to add user in
sip.conf file and number in  extension.conf file . but there is no such
file  given . can anybody tell me , what to do ?




regards
mehul

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





--
sean
___
--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

[asterisk-dev] Re: [asterisk-commits] russell: trunk r53047 - in /trunk: ./ apps/ channels/ main/ pbx/

[Sean Bright]

FYI,

You're adding redundant calls to pthread_attr_destroy in apps/app_rpt.c in
that patch (see below).

Sean


Modified: trunk/apps/app_rpt.c

URL:
http://svn.digium.com/view/asterisk/trunk/apps/app_rpt.c?view=diff&rev=53047&r1=53046&r2=53047

==
--- trunk/apps/app_rpt.c (original)
+++ trunk/apps/app_rpt.c Wed Jan 31 15:35:15 2007
@@ -3188,6 +3188,7 @@
pthread_attr_setdetachstate(&attr, PTHREAD_CREATE_DETACHED);
ast_pthread_create(&myrpt->rpt_call_thread, &attr, rpt_call, (void
*) myrpt);
pthread_attr_destroy(&attr);
+   pthread_attr_destroy(&attr);
return DC_COMPLETE;
}

@@ -5540,6 +5541,7 @@
pthread_attr_init(&attr);
pthread_attr_setdetachstate(&attr,
PTHREAD_CREATE_DETACHED);
ast_pthread_create(&myrpt->rpt_call_thread, &attr,
rpt_call, (void *)myrpt);
+   pthread_attr_destroy(&attr);
pthread_attr_destroy(&attr);
return;
}
@@ -6736,6 +6738,7 @@
pthread_attr_setdetachstate(&attr,
PTHREAD_CREATE_DETACHED);
ast_pthread_create(&rpt_vars[i].rpt_thread, &attr, rpt,
(void *) &rpt_vars[i]);
pthread_attr_destroy(&attr);
+   pthread_attr_destroy(&attr);
}
usleep(50);
for (;;) {
@@ -6764,6 +6767,7 @@
pthread_attr_init(&attr);
pthread_attr_setdetachstate(&attr,
PTHREAD_CREATE_DETACHED);
ast_pthread_create(&rpt_vars[i].rpt_thread,
&attr, rpt, (void *) &rpt_vars[i]);
+   pthread_attr_destroy(&attr);
pthread_attr_destroy(&attr);
ast_log(LOG_WARNING, "rpt_thread restarted
on node %s\n", rpt_vars[i].name);
}




sean
___
--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

[asterisk-dev] Problem with configure and FreeTDS

[Sean Bright]

Howdy,

I was building 1.4 earlier today and ran into a problem with
./configure --with-tds=/usr/local.  I resolved it by changing line 787
of configure.ac from:

   case `grep TDS_VERSION_NO ${FREETDS_DIR:-/usr/include}/tdsver.h` in

to:

   case `grep TDS_VERSION_NO ${FREETDS_DIR:-/usr}/include/tdsver.h` in

Or I suppose you could change FREETDS_DIR to FREETDS_INCLUDE and that
should still work.  It looks like this hasn't been fixed in trunk.

Thanks,
Sean
___
--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