[asterisk-dev] Stir/Shaken Refactor

[George Joseph]

I have no idea how this email will render in the old asterisk-dev
list but here goes.
If you can't read it, and you're not already subscribed to the
new list, this is your reminder to do so...
https://groups.io/g/asterisk-dev

-- Forwarded message -
From: George Joseph via groups.io 
Date: Tue, Jan 9, 2024 at 1:11 PM
Subject: [asterisk-dev] Stir/Shaken Refactor
To: 


Please review the pull request at Stir/Shaken Refactor
<https://github.com/asterisk/asterisk/pull/524>

You can review this PR locally by running gh pr checkout 524 if you have
the GitHub CLI client installed or by running git fetch upstream
pull/524/head:master-stir-shaken-refactor (assuming "upstream" points to
https://github.com/asterisk/asterisk.git).
It's important that you understand that there are breaking changes to the
Stir/Shaken implementation and that you TEST!!

I'll be updating the documentation at
https://docs.asterisk.org/Deployment/STIR-SHAKEN over the next few days.
Why do we need a refactor?

The original stir/shaken implementation was started over 3 years ago when
little was understood about practical implementation. The result was an
implementation that wouldn't actually interoperate with any other
stir-shaken implementations.

There were also a number of stir-shaken features and RFC requirements that
were never implemented such as TNAuthList certificate validation, sending
Reason headers in SIP responses when verification failed but we wished to
continue the call, and the ability to send Media Key(mky) grants in the
Identity header when the call involved DTLS.

Finally, there were some performance concerns around outgoing calls and
selection of the correct certificate and private key. The configuration was
keyed by an arbitrary name which meant that for every outgoing call, we had
to scan the entire list of configured TNs to find the correct cert to use.
With only a few TNs configured, this wasn't an issue but if you have a
thousand, it could be.

What's changed?

   -

   Configuration objects have been refactored to be clearer about their
   uses and to fix issues.
   - The "general" object was renamed to "verification" since it contains
  parameters specific to the incoming verification process. It also never
  handled ca_path and crl_path correctly.
  - A new "attestation" object was added that controls the outgoing
  attestation process. It sets default certificates, keys, etc.
  - The "certificate" object was renamed to "tn" and had it's key
  change to telephone number since outgoing call attestation needs
to look up
  certificates by telephone number.
  - The "profile" object had more parameters added to it that can
  override default parameters specified in the "attestation" and
  "verification" objects.
  - The "store" object was removed altogether as it was never
  implemented.
   -

   We now use libjwt to create outgoing Identity headers and to parse and
   validate signatures on incoming Identity headers. Our previous custom
   implementation was much of the source of the interoperability issues.
   -

   General code cleanup and refactor.
   - Moved things to better places.
  - Separated some of the complex functions to smaller ones.
  - Using context objects rather than passing tons of parameters in
  function calls.
  - Removed some complexity and unneeded encapsulation from the config
  objects.

Resolves: #351
Resolves: #46

UserNote: Asterisk's stir-shaken feature has been refactored to correct
interoperability, RFC compliance, and performance issues. See
https://docs.asterisk.org/Deployment/STIR-SHAKEN for more information.

UpgradeNote: The stir-shaken refactor is a breaking change but since it's
not working now we don't think it matters. The stir_shaken.conf file has
changed significantly which means that existing ones WILL need to be
changed. The stir_shaken.conf.sample file in configs/samples/ has quite a
bit more information. This is also an ABI breaking change since some of the
existing objects needed to be changed or removed, and new ones added.
_._,_._,_
--
Groups.io Links:

You receive all messages sent to this group.

View/Reply Online (#12) <https://groups.io/g/asterisk-dev/message/12> | Reply
To Group

| Reply To Sender

| Mute This Topic <https://groups.io/mt/103627606/8107472> | New Topic
<https://groups.io/g/asterisk-dev/post>
Your Subscription <https://groups.io/g/asterisk-dev/editsub/8107472> | Contact
Group Owner  | Unsubscribe
<https://groups.io/g/asterisk-dev/leave/12915652/8107472/342978022/xyzzy> [
gjos...@sangoma.com]
_._,_._,_
-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

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

[asterisk-dev] Need testers for updated ast_coredumper

[George Joseph]

I've just pushed up a pull request against ast_coredumper that changes how
it finds the executable
file, libraries and modules, and need testers.  If you have some spare
time, please look at the PR
https://github.com/asterisk/asterisk/pull/446 and/or download the file from
https://raw.githubusercontent.com/asterisk/asterisk/2a6b51257f9029f956f0c7704a197a8c8838e771/contrib/scripts/ast_coredumper

Try it both against a running asterisk instance and against a coredump
produced from a SEGV, etc.
You can induce a SEGV easily with "kill -SEGV `pidof asterisk`".
Don't do either on a production system of course. :)

If you find issues, report them in the PR comments.

Thanks...george

-- 
George Joseph
Asterisk Software Developer
Sangoma Technologies
Check us out at www.sangoma.com and www.asterisk.org
-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

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

Re: [asterisk-dev] DAHDI downloads

[George Joseph]

On Wed, Oct 25, 2023 at 4:27 AM George Joseph  wrote:

>
>
> On Tue, Oct 24, 2023 at 7:46 AM  wrote:
>
>> I noticed last week that 3.3.0-rc1 for DAHDI Linux and DAHDI Tools are
>> available on GitHub, but I don't see them on the downloads server.
>> current is still symlinked to 3.2.0, which is more than a year old.
>>
>> Is DAHDI not using the downloads server anymore? If not, is there any
>> kind of permalink available for the latest current tarball?
>>
>>
> They're working on their GutHub actions for publishing and I don't think
> they're quite ready yet.  Let me check.
>

They're working on it now..
DAHDI questions are best posted on https://community.asterisk.org/c/dahdi/48



>
>
>>
>> --
>> _
>> -- Bandwidth and Colocation Provided 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] DAHDI downloads

[George Joseph]

On Tue, Oct 24, 2023 at 7:46 AM  wrote:

> I noticed last week that 3.3.0-rc1 for DAHDI Linux and DAHDI Tools are
> available on GitHub, but I don't see them on the downloads server.
> current is still symlinked to 3.2.0, which is more than a year old.
>
> Is DAHDI not using the downloads server anymore? If not, is there any
> kind of permalink available for the latest current tarball?
>
>
They're working on their GutHub actions for publishing and I don't think
they're quite ready yet.  Let me check.


>
> --
> _
> -- Bandwidth and Colocation Provided 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

[asterisk-dev] STIR/SHAKEN implementation Update

[George Joseph]

Since we've had some known issues with the current STIR/SHAKEN
implementation and since we discovered a few more during the latest
OpenSIPIt get-together, we've decided to do a re-evaluation and refactor.
Some of that refactor you've already seen in the recent addition of libjwt
to the third-party infrastructure in the source tree.  That addition has
already allowed us to eliminate over 1000 lines of custom code in Asterisk
itself.  We have more to do though and need your help with some of it.

Attestation:

Thanks to libjwt, we now have attestation working to the point where we're
using the correct caller-id TN and other open-source stirt/shaken
implementations can  successfully validate our passport signature and
decode the proper passport fields.  Huzzah!  We still have some plumbing
work to do though since the current method of associating TNs and certs is
neither flexible nor efficient.  There are a number of good
possibilities to make this better and we should have some design ideas to
share later this week.

Verification:

The verification process ultimately depends on two pieces of data...the
orig_tn in the passport received in the incoming Identity header, and the
certificate we retrieve from the URL also in the passport.  Right now, we
have verification working right up to the point where we have to verify
them against each other.  It sounds weird but there's a lot of other
verification that has to happen before we get to the point of actually
verifying the TN against the cert (passport signature validation, passport
dates, cert validity dates, cert trust, etc).  Anyway, there are a number
of ways a certificate can indicate it has authority over the TN...

   1. The cert can contain a TNAuthList X.509 extension containing a single
   TN.  No -brainer.  If the TN in the orig_tn passport field doesn't match
   the TN in the cert, it's a fail.
   2. The cert can contain a TNAuthList X.509 extension containing a TN
   range.  Also a no-brainer.  The orig_tn is either in the range or not.
   3. The cert can contain a URL in an "authorityInfoAccess" X.509
   extension.  From RFC8226...  " A verifier would then follow the URI to
   ascertain whether the TNs in the list are authorized for use by the
   caller".   Since the list is supposed to be in the same form as the
   TNAuthList, that should work fine.
   4. The cert can contain a TNAuthList X.509 extension containing a
   Service Provider Code.  Uhm, OK.  What are we supposed to do with that?  I
   can't find any RFC or ATIS document that describes how you match a TN to an
   SPC.  There are some hints that a trusted-well-known service _might_ be
   made available where you could get a list of TNs by SPC, or better yet, a
   service where you can submit a specific TN and get back the SPC, but I can
   find no actual documentation to that effect.  What's worse,
   ATIS-1080.v005 specifically states that for an end-entity
   certificate... "The TNAuthList shall contain a single SPC value. The SPC
   value shall contain only numbers and uppercase letters. The
   TNAuthList shall *not contain any TNs or TN ranges*. ".  Nice.

OK, here's where we need your help   Does anyone have any real-world
examples of certificates, TNAuthLists, documents, etc.  that would allow us
to actually implement and test items 3, and especially 4, above?   I can
find absolutely none.

-- 
George Joseph
Asterisk Software Developer
Sangoma Technologies
Check us out at www.sangoma.com and www.asterisk.org
-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

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

Re: [asterisk-dev] libjwt is being added to the 'third-party' packages (Attention Asterisk Package Maintainers!)

[George Joseph]

On Tue, Sep 26, 2023 at 8:56 AM Jaco Kroon  wrote:

> Hi George,
>
> Is the default to build STIR/SHAKEN if libjwt is found, or will it fail by
> default?
>
It will build by default if libjwt >= 1.15.3 is found on the build system
or if '--with-libjwt-bundled' is specified on the configure command line.

> In other words, on systems where libjwt is not available, is special
> action required to order to build?  Does this vary based on whether libjwt
> can be found or not?
>
If libjwt >= 1.15.3 is not found on the build system and
'--with-libjwt-bundled' was not specified on the configure command line,
then res_stir_shaken will be disabled.  The build will otherwise proceed
normally.  If you do a 'make cmenuselect' you'll see that res_stir_shaken
has 'XXX' next to it and won't be selectable.

Does that make sense?

> Kind regards,
> Jaco
> On 2023/09/26 16:46, George Joseph wrote:
>
> With our effort to harden Asterisk's STIR/SHAKEN implementation, we're
> adding a new package (libjwt: JSON WebToken) to the third-party directory
> next to jansson and pjproject.  Using libjwt allows us to remove the custom
> code (which isn't reliable) in res_stir_shaken that handles the assembly of
> the JWT and associated signature process that STIR/SHAKEN relies upon and
> delegate that to libjwt.  We're including it in third-party because some
> distros don't include that package and those that do are several releases
> behind the latest.  The minimum supported version will be 1.15.3 which is
> the current libjwt version.
>
> Since libjwt will be only used by res_stir_shaken at this time, it's not a
> hard requirement to build asterisk as a whole and isn't included in the
> install_prereq script.  If you want to build res_stir_shaken however, your
> build system must have libjwt >= 1.15.3 installed or you'll need to specify
> '--with-libjwt-bundled' on the ./configure command line.  As with jansson
> and pjproject, you can pre-download the libjwt tarball (
> https://raw.githubusercontent.com/asterisk/third-party/master/libjwt/1.15.3/libjwt-1.15.3.tar.gz)
> and use the '--with-download-cache' configure option to point to the
> directory containing the tarball.
>
> We are planning this change for the next releases of Asterisk 18 and 20
> and the first release of Asterisk 21.
>
> --
> George Joseph
> Asterisk Software Developer
> Sangoma Technologies
> Check us out at www.sangoma.com and www.asterisk.org
>
> --
> _
> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
>
> asterisk-dev mailing list
> To UNSUBSCRIBE or update options visit:
>http://lists.digium.com/mailman/listinfo/asterisk-dev
-- 
_
-- Bandwidth and Colocation Provided 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] libjwt is being added to the 'third-party' packages (Attention Asterisk Package Maintainers!)

[George Joseph]

With our effort to harden Asterisk's STIR/SHAKEN implementation, we're
adding a new package (libjwt: JSON WebToken) to the third-party directory
next to jansson and pjproject.  Using libjwt allows us to remove the custom
code (which isn't reliable) in res_stir_shaken that handles the assembly of
the JWT and associated signature process that STIR/SHAKEN relies upon and
delegate that to libjwt.  We're including it in third-party because some
distros don't include that package and those that do are several releases
behind the latest.  The minimum supported version will be 1.15.3 which is
the current libjwt version.

Since libjwt will be only used by res_stir_shaken at this time, it's not a
hard requirement to build asterisk as a whole and isn't included in the
install_prereq script.  If you want to build res_stir_shaken however, your
build system must have libjwt >= 1.15.3 installed or you'll need to specify
'--with-libjwt-bundled' on the ./configure command line.  As with jansson
and pjproject, you can pre-download the libjwt tarball (
https://raw.githubusercontent.com/asterisk/third-party/master/libjwt/1.15.3/libjwt-1.15.3.tar.gz)
and use the '--with-download-cache' configure option to point to the
directory containing the tarball.

We are planning this change for the next releases of Asterisk 18 and 20 and
the first release of Asterisk 21.

-- 
George Joseph
Asterisk Software Developer
Sangoma Technologies
Check us out at www.sangoma.com and www.asterisk.org
-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

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

Re: [asterisk-dev] issues-archive.asterisk.org is now available for preview

[George Joseph]

On Sun, Aug 27, 2023 at 11:49 AM  wrote:

> On 8/4/2023 9:48 AM, George Joseph wrote:
> >
> > > We've done a dump of all the ASTERISK-* issues and their
> > attachments
> > > from the issues.asterisk.org <http://issues.asterisk.org>
> > <http://issues.asterisk.org> Jira
> > > instance and made them available at
> > > https://issues-archive.asterisk.org. It'll be a few days before
> > Google
> > > gets around to indexing the entire site so the search bar isn't
> > > working yet but you can browse the issues right now. When the
> > search
> > > is fully working we'll announce it on the asterisk-users list as
> > well.
> >
>
> Something I noticed in the past few days...
> issues.asterisk.org used to redirect to issues-archive.asterisk.org, but
> now redirects to GitHub, so issues.asterisk.org links no longer work
> properly. I'm assuming this wasn't intentional - just wanted to make you
> aware of it! Didn't seem like there was a good GitHub repo for this
> metaissue...
>
> I'm thinking maybe it was intended that the root domain
> issues.asterisk.org itself redirect to GitHub, and anything with a path
> redirect to issues-archive, but that's just speculation on my part.
>

Correct.  Should be fixed now.
-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

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

Re: [asterisk-dev] Gerrit offline?

[George Joseph]

On Wed, Aug 23, 2023 at 9:03 AM  wrote:

> On 8/23/2023 8:30 AM, George Joseph wrote:
> > On Tue, Aug 22, 2023 at 6:03 PM  wrote:
> >> On 8/19/2023 11:19 AM, George Joseph wrote:
> >>> Here's a gist that does all the work. Create a directory to hold the
> >>> patch
> >>> files then run
> >>> the script from a gerrit asterisk clone directory providing the patch
> >>> directory.
> >> Hi George,
> >>  Sorry, just getting to this now. I'm assuming you meant to link a
> >> GitHub gist, but I'm not seeing a link anywhere... didn't find any on
> >> your profile either. Is this available somewhere?
> > Oops...
> > https://gist.github.com/gtjoseph/f98d5a583b0d2977686655a56e28ecff
> Thanks George!
> Does this run successfully for you? I downloaded a fresh Gerrit repo
> and it seems git doesn't like the fetch/checkout combination used:
>
>
That's because there was a typo :)
Grab the gist again.


> root@debian11:/usr/src/gerrit/asterisk# git fetch
> https://gerrit.asterisk.org/asterisk refs/changes/55/17655/25
>  From https://gerrit.asterisk.org/asterisk
>   * branch  refs/changes/55/17655/25 -> FETCH_HEAD
> root@debian11:/usr/src/gerrit/asterisk# git checkout -b change-17655
> FETCH HEAD
> fatal: Cannot update paths and switch to branch 'change-17655' at the
> same time.
>
> It seems to me like only one or the other is necessary, just want to
> make sure I'm not missing something important. If I do this they all
> have names like
> "patches/19467-pbx_dundi-Fix-PJSIP-endpoint-configuration-check.patch"
> but the actual Gerrit patch number is correct, the same name is used for
> all of them, e.g. below. Same if I swap the effective command. I'm not
> concerned about the name as much, but the patches are actually all
> identical (just the first one).
>
> root@debian11:/usr/src/gerrit/asterisk# ls -la patches
> total 140
> drwxr-xr-x  2 root root 4096 Aug 23 10:57 .
> drwxr-xr-x 33 root root 4096 Aug 23 10:56 ..
> -rw-r--r--  1 root root 1047 Aug 23 10:56
> 17655-pbx_dundi-Fix-PJSIP-endpoint-configuration-check.patch
> -rw-r--r--  1 root root 1047 Aug 23 10:56
> 17719-pbx_dundi-Fix-PJSIP-endpoint-configuration-check.patch
> -rw-r--r--  1 root root 1047 Aug 23 10:57
> 17948-pbx_dundi-Fix-PJSIP-endpoint-configuration-check.patch
> -rw-r--r--  1 root root 1047 Aug 23 10:57
> 18186-pbx_dundi-Fix-PJSIP-endpoint-configuration-check.patch
> -rw-r--r--  1 root root 1047 Aug 23 10:57
> 18369-pbx_dundi-Fix-PJSIP-endpoint-configuration-check.patch
> -rw-r--r--  1 root root 1047 Aug 23 10:57
> 18574-pbx_dundi-Fix-PJSIP-endpoint-configuration-check.patch
> -rw-r--r--  1 root root 1047 Aug 23 10:56
> 18577-pbx_dundi-Fix-PJSIP-endpoint-configuration-check.patch
> -rw-r--r--  1 root root 1047 Aug 23 10:56
> 18829-pbx_dundi-Fix-PJSIP-endpoint-configuration-check.patch
> -rw-r--r--  1 root root 1047 Aug 23 10:57
> 19211-pbx_dundi-Fix-PJSIP-endpoint-configuration-check.patch
> -rw-r--r--  1 root root 1047 Aug 23 10:56
> 19264-pbx_dundi-Fix-PJSIP-endpoint-configuration-check.patch
> -rw-r--r--  1 root root 1047 Aug 23 10:57
> 19447-pbx_dundi-Fix-PJSIP-endpoint-configuration-check.patch
> -rw-r--r--  1 root root 1047 Aug 23 10:57
> 19467-pbx_dundi-Fix-PJSIP-endpoint-configuration-check.patch
> -rw-r--r--  1 root root 1047 Aug 23 10:57
> 19534-pbx_dundi-Fix-PJSIP-endpoint-configuration-check.patch
> -rw-r--r--  1 root root 1047 Aug 23 10:57
> 19572-pbx_dundi-Fix-PJSIP-endpoint-configuration-check.patch
> -rw-r--r--  1 root root 1047 Aug 23 10:57
> 19655-pbx_dundi-Fix-PJSIP-endpoint-configuration-check.patch
> -rw-r--r--  1 root root 1047 Aug 23 10:56
> 19718-pbx_dundi-Fix-PJSIP-endpoint-configuration-check.patch
> -rw-r--r--  1 root root 1047 Aug 23 10:56
> 19740-pbx_dundi-Fix-PJSIP-endpoint-configuration-check.patch
> -rw-r--r--  1 root root 1047 Aug 23 10:56
> 19741-pbx_dundi-Fix-PJSIP-endpoint-configuration-check.patch
> -rw-r--r--  1 root root 1047 Aug 23 10:56
> 19748-pbx_dundi-Fix-PJSIP-endpoint-configuration-check.patch
> -rw-r--r--  1 root root 1047 Aug 23 10:56
> 19749-pbx_dundi-Fix-PJSIP-endpoint-configuration-check.patch
> -rw-r--r--  1 root root 1047 Aug 23 10:56
> 19793-pbx_dundi-Fix-PJSIP-endpoint-configuration-check.patch
> -rw-r--r--  1 root root 1047 Aug 23 10:56
> 19797-pbx_dundi-Fix-PJSIP-endpoint-configuration-check.patch
> -rw-r--r--  1 root root 1047 Aug 23 10:56
> 19921-pbx_dundi-Fix-PJSIP-endpoint-configuration-check.patch
> -rw-r--r--  1 root root 1047 Aug 23 10:56
> 19979-pbx_dundi-Fix-PJSIP-endpoint-configuration-check.patch
> -rw-r--r--  1 root root 1047 Aug 23 10:56
> 20033-pbx_dundi-Fix-PJSIP-endpoint-configuration-check.

Re: [asterisk-dev] Gerrit offline?

[George Joseph]

On Tue, Aug 22, 2023 at 6:03 PM  wrote:

> On 8/19/2023 11:19 AM, George Joseph wrote:
> > Here's a gist that does all the work. Create a directory to hold the
> > patch
> > files then run
> > the script from a gerrit asterisk clone directory providing the patch
> > directory.
>
> Hi George,
> Sorry, just getting to this now. I'm assuming you meant to link a
> GitHub gist, but I'm not seeing a link anywhere... didn't find any on
> your profile either. Is this available somewhere?
>

Oops...
https://gist.github.com/gtjoseph/f98d5a583b0d2977686655a56e28ecff
-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

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

Re: [asterisk-dev] Gerrit offline?

[George Joseph]

On Fri, Aug 18, 2023 at 1:25 PM  wrote:

> On 8/18/2023 9:15 AM, Sean Bright wrote:
> > 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.
>
> Thanks Sean, that helped a lot!
>
> On 8/18/2023 9:51 AM, George Joseph wrote:
> > I  can leave it up until Wednesday 1900Z.
>
> Thanks George, appreciate the flexibility!
>
> > Just what you have.   You can pull them down yourself easily with the
> > following...
> >
> > curl -s 'https://gerrit.asterisk.org/changes/
> > <https://gerrit.asterisk.org/changes/%5C>?q=is:open=CURRENT_REVISION=DOWNLOAD_COMMANDS'
>
> > \
> > | tail -n +2 | jq -r '.[] | .revisions[].fetch[].commands.Branch' \
> > > /tmp/get_reviews.sh  ; chmod a+x /tmp/get_reviews.sh ;
> > /tmp/get_reviews.sh
> >
>
> I guess the idea here is you checkout each change, and then can export
> the diff into a file or something like that? I guess it should be
> straightforward to generate the patches from that, and then discard the
> repo, thanks for the code.
>

Here's a gist that does all the work.  Create a directory to hold the patch
files then run
the script from a gerrit asterisk clone directory providing the patch
directory.

Sean's work simplified this a good bit, but there are a few I may go and
> manually track down for safe keeping over the weekend (mostly some of
> Mark's stuff that hasn't been migrated to GitHub yet... or may not be
> soon, not sure what the status is on those).
>
> git fetch https://gerrit.asterisk.org/asterisk refs/changes/55/17655/25
> && git checkout -b change-17655 FETCH_HEAD
> git fetch https://gerrit.asterisk.org/asterisk refs/changes/79/19979/3
> && git checkout -b change-19979 FETCH_HEAD
> git fetch https://gerrit.asterisk.org/asterisk refs/changes/69/20069/1
> && git checkout -b change-20069 FETCH_HEAD
> git fetch https://gerrit.asterisk.org/asterisk refs/changes/38/20038/3
> && git checkout -b change-20038 FETCH_HEAD
> git fetch https://gerrit.asterisk.org/asterisk refs/changes/68/20068/1
> && git checkout -b change-20068 FETCH_HEAD
> git fetch https://gerrit.asterisk.org/asterisk refs/changes/58/20058/1
> && git checkout -b change-20058 FETCH_HEAD
> git fetch https://gerrit.asterisk.org/asterisk refs/changes/59/20059/1
> && git checkout -b change-20059 FETCH_HEAD
> git fetch https://gerrit.asterisk.org/asterisk refs/changes/33/20033/3
> && git checkout -b change-20033 FETCH_HEAD
> git fetch https://gerrit.asterisk.org/asterisk refs/changes/40/19740/3
> && git checkout -b change-19740 FETCH_HEAD
> git fetch https://gerrit.asterisk.org/testsuite refs/changes/83/20083/1
> && git checkout -b change-20083 FETCH_HEAD
> git fetch https://gerrit.asterisk.org/asterisk refs/changes/80/20080/1
> && git checkout -b change-20080 FETCH_HEAD
> git fetch https://gerrit.asterisk.org/asterisk refs/changes/19/17719/11
> && git checkout -b change-17719 FETCH_HEAD
> git fetch https://gerrit.asterisk.org/asterisk refs/changes/37/20037/2
> && git checkout -b change-20037 FETCH_HEAD
> git fetch https://gerrit.asterisk.org/asterisk refs/changes/41/19741/15
> && git checkout -b change-19741 FETCH_HEAD
> git fetch https://gerrit.asterisk.org/asterisk refs/changes/97/19797/3
> && git checkout -b change-19797 FETCH_HEAD
> git fetch https://gerrit.asterisk.org/asterisk refs/changes/21/19921/16
> && git checkout -b change-19921 FETCH_HEAD
> git fetch https://gerrit.asterisk.org/asterisk refs/changes/93/19793/7
> && git checkout -b change-19793 FETCH_HEAD
> git fetch https://gerrit.asterisk.org/asterisk refs/changes/29/18829/25
> && git checkout -b change-18829 FETCH_HEAD
> git fetch https://gerrit.asterisk.org/asterisk refs/changes/77/18577/4
> && git checkout -b change-18577 FETCH_HEAD
> git fetch https://gerrit.asterisk.org/asterisk refs/changes/64/19264/9
> && git checkout -b change-19264 FETCH_HEAD
> git fetch https://gerrit.asterisk.org/asterisk refs/changes/18/19718/4
> && git checkout -b change-19718 FETCH_HEAD
> git fetch https://gerrit.asterisk.org/asterisk refs/changes/49/19749/3
> && git checkout -b change-19749 FETCH_HEAD
> git fetch https://gerrit.asterisk.org/asterisk refs/changes/48/19748/1
> && git checkout -b change-19748 FETCH_HEAD
> git fetch https://gerrit.asterisk.org/asterisk refs/changes/67/19467/1
> && git checkout -b cha

Re: [asterisk-dev] Gerrit offline?

[George Joseph]

On Thu, Aug 17, 2023 at 7:05 PM  wrote:

> On 8/17/2023 8:09 AM, George Joseph wrote:
> > On Wed, Aug 16, 2023 at 5:58 PM George Joseph  > <mailto:gjos...@sangoma.com>> wrote:
> >
> > I'll bring it back up in the morning.
> >
> >
> > Gerrit is back up but will be permanently disabled on Monday at 1200Z.
>
> Thanks George,
>Would it be at all possible to extend that possibly at least a couple
> days, perhaps through Wednesday at least?
>

I  can leave it up until Wednesday 1900Z.


> I'm going to be out of the office and on the road a lot into early next
> week, I don't think I'm going to be able to get much done migration-wise
> by then. Wednesday at least I think I can plan to have things fully
> migrated. It's just a lot that's catching us off guard here without any
> advance warning beforehand. I think through Wednesday at least provides
> a good window for folks.
> Additionally, is there any kind of archive of any of the stuff on Gerrit
> that is publicly accessible, or just what people have or will manually
> migrate by such time?
>

Just what you have.   You can pull them down yourself easily with the
following...

curl -s 'https://gerrit.asterisk.org/changes/
<https://gerrit.asterisk.org/changes/%5C>?q=is:open=CURRENT_REVISION=DOWNLOAD_COMMANDS'
\
| tail -n +2 | jq -r '.[] | .revisions[].fetch[].commands.Branch' \
> /tmp/get_reviews.sh  ; chmod a+x /tmp/get_reviews.sh ;
/tmp/get_reviews.sh



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

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

Re: [asterisk-dev] Gerrit offline?

[George Joseph]

On Wed, Aug 16, 2023 at 5:58 PM George Joseph  wrote:

> I'll bring it back up in the morning.
>

Gerrit is back up but will be permanently disabled on Monday at 1200Z.



>
> On Wed, Aug 16, 2023, 5:23 PM  wrote:
>
>> It seems like some time in the past day or so, Gerrit has gone offline,
>> which is causing build failures and other issues since some patches are
>> inaccessible.
>>
>> Is this just temporary? I don't recall any announcement going out that
>> Gerrit would be going offline imminently. The communication earlier this
>> year was that it would remain online for some time and there would be
>> communication ahead of any changes to allow people to prepare for this.
>> Has there been any change with this?
>>
>>
>> --
>> _
>> -- Bandwidth and Colocation Provided 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] Gerrit offline?

[George Joseph]

I'll bring it back up in the morning.

On Wed, Aug 16, 2023, 5:23 PM  wrote:

> It seems like some time in the past day or so, Gerrit has gone offline,
> which is causing build failures and other issues since some patches are
> inaccessible.
>
> Is this just temporary? I don't recall any announcement going out that
> Gerrit would be going offline imminently. The communication earlier this
> year was that it would remain online for some time and there would be
> communication ahead of any changes to allow people to prepare for this.
> Has there been any change with this?
>
>
> --
> _
> -- Bandwidth and Colocation Provided 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] [External] Re: Final Preview: docs.asterisk.org

[George Joseph]

On Wed, Aug 9, 2023 at 10:41 PM Martin McCarthy <
martin.c.mccar...@outlook.com> wrote:

> Good morning guys, I hope you're well. I've had a chance to preview the
> new Asterisk Docs page and it's looking good. However, there are a few
> points I would like to note and direct at the developer in order to improve
> the current layout of the site;
>
> --snip--

>
> I'm happy to assist with the code and design if needed. You can reach me
> on here or you can reach me on Libera.Chat in #asterisk. Thanks guys.
>
> Martin.
>
Hi Martin,

While we really appreciate the effort it took to do the review, the goal
of the documentation re-hosting was to get it off of the ancient Atlassian
Confluence infrastructure into a low maintenance environment that can
provide basic usability for the majority of our users.  We believe we've
reached that goal.   Sure, there are things that could be tweaked but given
the size of our team it's difficult for us to justify the resources that
would be required for many of them.   Your offer of assistance is also much
appreciated as would any issues and pull requests you might submit but
please keep in mind that the more customizations made to mkdocs and the
Material theme the more resources it takes to maintain them, especially
when we need to upgrade those tools.

Going forward if there are issues please file them as Github issues[1] so
they are properly tracked.

Thanks!
george

[1] https://github.com/asterisk/documentation/issues
-- 
_
-- Bandwidth and Colocation Provided by http://www.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] Re: Final Preview: docs.asterisk.org

[George Joseph]

On Wed, Aug 9, 2023 at 4:05 PM George Joseph  wrote:

> On Wed, Aug 9, 2023 at 2:30 PM  wrote:
>
>> On 8/9/2023 11:12 AM, George Joseph wrote:
>>
>>
>> > Yeah, create an issue.  I can take a look in the coming weeks.  If you
>> > constrict the width of your browser, at some point, the left nav bar
>> > will collapse and you can get it back by clicking on the "hamburger"
>> > button that then appears in the top-left of the page.  There's no way
>> > to collapse it manually though so maybe we can find a way to add that.
>> > Maybe we can also make the page table of contents collapsible.  Both
>> > should give more space to the content.  I think we can also override
>> > the viewport width of the content.A tweak to the dynamic
>> > documentation generator might also help.
>>
>> I don't think the issue here is collapsing the navigation. In fact, I
>> really hate when you're on a large monitor and websites collapse menus
>> like that, catering to mobile devices only is pure insanity, making life
>> more difficult for everyone else by requiring yet more clicks to do
>> anything. The issue is that the site seems to max out at a certain
>> viewport; on a large monitor, the middle portion could take up more
>> room, but there is vast whitespace to the left and right margins. It's
>> possible that the style is assuming a max-width that it will use for
>> presentation. Ideally, the middle content should expand to take up the
>> space it can so it can use the full width of any monitor.
>>
>
>
> Yeah I get it.  I was just throwing out some additional ideas as well.
>
>

Simple change.  Check now.  You may have to clear your cache or at least
look at a page that's not currently in your cache.
-- 
_
-- Bandwidth and Colocation Provided by http://www.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] Re: Final Preview: docs.asterisk.org

[George Joseph]

On Wed, Aug 9, 2023 at 2:30 PM  wrote:

> On 8/9/2023 11:12 AM, George Joseph wrote:
> >
> >
> > On Wed, Aug 9, 2023 at 8:39 AM Joshua C. Colp  > <mailto:jc...@sangoma.com>> wrote:
> >
> > On Wed, Aug 9, 2023 at 11:37 AM Floimair Florian
> > mailto:f.floim...@commend.com>> wrote:
> >
> > Thanks Josh!
> >
> > I went the same path actually but gave up, as CSS to me is
> > something completely out of my knowledge domain.
> >
> > I also had a look at the other teams but so far Material for
> > mkdocs does still look like the best option out there readily
> > available.
> >
> >
> > Then I'd suggest filing an issue on the Github repo with your
> > comments so they don't get lost. No guarantee anything can be
> > done, but the docs repo is where issues should go.
> >
> >
> > Yeah, create an issue.  I can take a look in the coming weeks.  If you
> > constrict the width of your browser, at some point, the left nav bar
> > will collapse and you can get it back by clicking on the "hamburger"
> > button that then appears in the top-left of the page.  There's no way
> > to collapse it manually though so maybe we can find a way to add that.
> > Maybe we can also make the page table of contents collapsible.  Both
> > should give more space to the content.  I think we can also override
> > the viewport width of the content.A tweak to the dynamic
> > documentation generator might also help.
>
> I don't think the issue here is collapsing the navigation. In fact, I
> really hate when you're on a large monitor and websites collapse menus
> like that, catering to mobile devices only is pure insanity, making life
> more difficult for everyone else by requiring yet more clicks to do
> anything. The issue is that the site seems to max out at a certain
> viewport; on a large monitor, the middle portion could take up more
> room, but there is vast whitespace to the left and right margins. It's
> possible that the style is assuming a max-width that it will use for
> presentation. Ideally, the middle content should expand to take up the
> space it can so it can use the full width of any monitor.
>


Yeah I get it.  I was just throwing out some additional ideas as well.
-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

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

[asterisk-dev] Asterisk 21 branch is now available

[George Joseph]

We've just cut the 21 branches for both the asterisk and testsuite repos.
All new pull requests should now be cherry-picked to that branch as well as
the existing 18 and 20 branches and *don't forget to update any open pull
requests to include 21!*


-- 
George Joseph
Asterisk Software Developer
Sangoma Technologies
Check us out at www.sangoma.com and www.asterisk.org
-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

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

Re: [asterisk-dev] [External] Re: Final Preview: docs.asterisk.org

[George Joseph]

On Wed, Aug 9, 2023 at 8:39 AM Joshua C. Colp  wrote:

> On Wed, Aug 9, 2023 at 11:37 AM Floimair Florian 
> wrote:
>
>> Thanks Josh!
>>
>>
>>
>> I went the same path actually but gave up, as CSS to me is something
>> completely out of my knowledge domain.
>>
>> I also had a look at the other teams but so far Material for mkdocs does
>> still look like the best option out there readily available.
>>
>
> Then I'd suggest filing an issue on the Github repo with your comments so
> they don't get lost. No guarantee anything can be done, but the docs repo
> is where issues should go.
>

Yeah, create an issue.  I can take a look in the coming weeks.  If you
constrict the width of your browser, at some point, the left nav bar will
collapse and you can get it back by clicking on the "hamburger" button that
then appears in the top-left of the page.  There's no way to collapse it
manually though so maybe we can find a way to add that.  Maybe we can also
make the page table of contents collapsible.  Both should give more
space to the content.  I think we can also override the viewport width of
the content.A tweak to the dynamic documentation generator might also
help.




>
> --
> Joshua C. Colp
> Asterisk Project Lead
> Sangoma Technologies
> Check us out at www.sangoma.com and www.asterisk.org
> --
> _
> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
>
> asterisk-dev mailing list
> To UNSUBSCRIBE or update options visit:
>http://lists.digium.com/mailman/listinfo/asterisk-dev
-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

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

Re: [asterisk-dev] Final Preview: docs.asterisk.org

[George Joseph]

On Fri, Aug 4, 2023 at 11:50 AM  wrote:

> On 8/4/2023 9:42 AM, George Joseph wrote:
> > Well, I've made a few more changes and pushed them up.  I think this
> > is as good as it's going to get for now.
>
> I think it's perfect. Down from 230 MB to 140 MB for the same build. 40%
> size reduction just by removing whitespace I guess! Looking at a few
> pages manually, the HTML looks perfect. No visible issues.
>
> Only thing I noticed when building this time around was warnings like
> these:
> INFO-  Doc file
> 'Asterisk_20_Documentation/API_Documentation/Dialplan_Functions/SMDI_MSG_RETRIEVE.md'
>
> contains an absolute link
> '/Asterisk_20_Documentation/API_Documentation/Dialplan_Functions/SMDI_MSG',
>
> it was left as is. Did you mean 'SMDI_MSG.md'?
> INFO-  Doc file
> 'Asterisk_20_Documentation/API_Documentation/Dialplan_Functions/STREAM_SILENCE.md'
>
> contains an absolute link
> '/Asterisk_20_Documentation/API_Documentation/Dialplan_Applications/ChanSpy',
>
> it was left as is. Did you mean
> '../Dialplan_Applications/ChanSpy.md'?
>
>
Since I don't get those errors I assume they're your own added
documentation?  I can't really help there.  All I can say is to look at how
the standard documentation references other pages.  To make sure the links
work in different versions of asterisk, they need to be relative, like the
last error message above.


> However I tested the site and things seem to work fine. The build did
> take longer, possibly due to the above checks, 90 seconds vs 18, but
> that's not really an issue. The links do appear to be relative to me -
> I'm not putting this in a domain root, but in a subfolder, and the links
> all seem to work correctly for me. So I don't think there's an issue and
> it seems like this can be ignored - perhaps it went ahead and converted
> it on the fly. Just wanted to point that out in case I'm wrong.
>
> Everything seems to work well, I don't see any further issues with
> anything here. Thanks a lot George for looking into these issues, I'm
> looking forward to porting documentation over to this new generation
> method.
>
-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

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

Re: [asterisk-dev] issues-archive.asterisk.org is now available for preview

[George Joseph]

On Fri, Aug 4, 2023 at 11:38 AM  wrote:

> On 8/4/2023 9:48 AM, George Joseph wrote:
> > We've done a dump of all the ASTERISK-* issues and their attachments
> > from the issues.asterisk.org <http://issues.asterisk.org> Jira
> > instance and made them available at
> > https://issues-archive.asterisk.org. It'll be a few days before Google
> > gets around to indexing the entire site so the search bar isn't
> > working yet but you can browse the issues right now.  When the search
> > is fully working we'll announce it on the asterisk-users list as well.
> >
> > Take a look.
> Looks good on the surface to me. My main concern was patch attachments
> being preserved and it looks like they are.
>
> Just curious, how large is the export exactly? Certain things in JIRA
> were helpful like being able to filter issues by a keyword to "open",
> i.e. things which had and have not yet been resolved. The Google Search
> will help with indexing content but not with filtering,


Actually I may be able to customize the search results to be just a list.
If I have time next week, I'll take a look.


> I'd think. If
> it's not too large, do you think this would be better suited to allowing
> folks to download an archive and then be able to use tools like grep to
> find the issues they want?
>

235M uncompressed without attachments
41M in tarball
https://issues-archive.asterisk.org/asterisk-issue-archive.tar.gz

4.7G uncompressed attachments
They will not be made available as an archive.
If you want, you can simply munge the links to them in your local copy of
the html to point to the online versions.


>
> I don't know that the hosted archives needs to do this, I suspect very
> few people would have any need for being able to do that, and I don't
> want to add any work for anyone here.
>
> Side question, more on the legal side. When everything was on JIRA, I
> think the policy was that any patches on JIRA could be taken through
> code review by anyone else, so long as the uploader had signed the CLA.
> Now that it is on GitHub, and there is a new CLA, and most people have
> not resigned the CLA for patches from the past ~20 years, how does this
> affect patches in the JIRA archive? Since the CLA was valid when they
> were provided to the project, can they still be taken through code
> review by anyone else? What is the status of such patches? Thanks.
>

I'll have to let Josh answer that one.
-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

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

Re: [asterisk-dev] Important!: Personal spaces on wiki.asterisk.org

[George Joseph]

On Fri, Aug 4, 2023 at 10:44 AM Fred Posner  wrote:

> Has there been a post on what is replacing this?
>

Nothing is replacing the personal spaces unless you create something
yourself.

Documentation is now hosted at https://docs.asterisk.org




>
>
> Regards,
>
> Fred Posner
>
>
>
> > On Aug 4, 2023, at 12:41 PM, George Joseph  wrote:
> >
> > When wiki.asterisk.org goes away (soon), any personal spaces you may
> have created will also be going away.  If you want the content, either grab
> it yourself or email me directly and I'll export it for you and send you a
> link to a tarball.  Either way, you should do this before next Friday
> August 11th.
> >
> > --
> > George Joseph
> > Asterisk Software Developer
> > Sangoma Technologies
> > Check us out at www.sangoma.com and www.asterisk.org
> > --
> > _
> > -- Bandwidth and Colocation Provided by http://www.api-digital.com --
> >
> > asterisk-dev mailing list
> > To UNSUBSCRIBE or update options visit:
> >   http://lists.digium.com/mailman/listinfo/asterisk-dev
>
>
>
> --
> _
> -- Bandwidth and Colocation Provided 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

[asterisk-dev] Important!: Personal spaces on wiki.asterisk.org

[George Joseph]

When wiki.asterisk.org goes away (soon), any personal spaces you may have
created will also be going away.  If you want the content, either grab it
yourself or email me directly and I'll export it for you and send you a
link to a tarball.  Either way, you should do this before next Friday
August 11th.

--
George Joseph
Asterisk Software Developer
Sangoma Technologies
Check us out at www.sangoma.com and www.asterisk.org
-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

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

[asterisk-dev] issues-archive.asterisk.org is now available for preview

[George Joseph]

We've done a dump of all the ASTERISK-* issues and their attachments from
the issues.asterisk.org Jira instance and made them available at
https://issues-archive.asterisk.org.  It'll be a few days before Google
gets around to indexing the entire site so the search bar isn't working yet
but you can browse the issues right now.  When the search is fully working
we'll announce it on the asterisk-users list as well.

Take a look.


-- 
George Joseph
Asterisk Software Developer
Sangoma Technologies
Check us out at www.sangoma.com and www.asterisk.org
-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

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

Re: [asterisk-dev] Final Preview: docs.asterisk.org

[George Joseph]

Well, I've made a few more changes and pushed them up.  I think this is as
good as it's going to get for now.

On Fri, Jul 28, 2023 at 6:56 PM  wrote:

> On 7/28/2023 8:48 PM, George Joseph wrote:
> > On Fri, Jul 28, 2023 at 1:52 PM  > <mailto:aster...@phreaknet.org>> wrote:
> >
> >
> > It's at the very bottom of the README:
> > > If you're always going to build just 1 branch's dynamic
> > documentation,
> > > you can skip the Makefile..inc file and just place everything in
> > the
> > > main Makefile.inc:
> >
> > The first Makefile..inc has an extra period world's least
> > important
> > typo.
> >
> >
> > Ahha!   It's 'Makefile..inc' in the source README.md but the
> > '' is getting stripped. :)
>
> Ah, probably should've noticed that, actually, Makefile.inc twice in a
> row doesn't make any sense, if I was actually thinking about it...
>
> > Circling back to one other thing now that this seems good to go, what
> > exactly did you change for reducing the file sizes / is that
> > included in
> > the current iteration, without mike?
> >
> >
> > The addition of "navigation.prune" under features in mkdocs.yml did
> > most of it, and yes, it's currently included.
> >
> > I'm still seeing a lot of
> > extraneous whitespace in the pages. 244 KB per page isn't huge,
> > but just
> > at a cursory glance,
> >
> >
> > Can you give me an example of an html page that's that big?  Most I
> > see are in the 80-100k range
>
> I think all of them - for example:
>
> https://docs.asterisk.org/Asterisk_20_Documentation/API_Documentation/Dialplan_Applications/ADSIProg/
>
> This one is "only" 131 KB, but if you go and view source, you can scroll
> down a bit and see often hundreds of newlines, tabs, and spaces at a
> time in a row. I can't work how that's creeping in from the markdown, so
> I don't think it's from the markdown. That's why I thought we might need
> to do it manually, e.g. using tr or something like that. So regardless
> of page size, I think we could likely prune all the pages down just by
> eliminating whitespace.
>
> >
> > I think we could probably cut the size 10-20% just
> > by getting rid of the whitespace. In some places, there are just
> > hundreds of newlines in a row for no reason.
> >
> >
> > Give me an example page.
> >
> > If this is just what the
> > tool generates, I understand that, we don't have any control over
> > that,
> > just wanted to know. We could remove it all pretty easily with sed
> > probably, and think could be a final "post processing" step in the
> > Makefile, run recursively on all files. What do you think?
> >
> >
> > I tried to do exactly that but it didn't result in much savings and I
> > got nervous about accidentally deleting multiple "blank" lines without
> > knowing whether you might be in a "" block or not.   I was going
> > to try html-minifier but just haven't got to it yet.
>
> Yeah, I guess that could be tricky. But how much is the  tag
> actually used? On the page linked above, for example, I only see it
> once, and, ironically, there isn't any extraneous whitespace in it.  I
> took a look at a few different types of pages and this appears to be the
> case for all of them. So in our particular case, it seems like it might
> be okay to do a simple delete, since  shouldn't be affected by
> consecutive whitespace.
>
-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

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

Re: [asterisk-dev] Final Preview: docs.asterisk.org

[George Joseph]

On Fri, Jul 28, 2023 at 6:48 PM George Joseph  wrote:

>
>
> On Fri, Jul 28, 2023 at 1:52 PM  wrote:
>
>>
>> It's at the very bottom of the README:
>> > If you're always going to build just 1 branch's dynamic documentation,
>> > you can skip the Makefile..inc file and just place everything in the
>> > main Makefile.inc:
>>
>> The first Makefile..inc has an extra period world's least important
>> typo.
>>
>
> Ahha!   It's 'Makefile..inc' in the source README.md but the
> '' is getting stripped. :)
>
>
>
>> Circling back to one other thing now that this seems good to go, what
>> exactly did you change for reducing the file sizes / is that included in
>> the current iteration, without mike?
>
>
> The addition of "navigation.prune" under features in mkdocs.yml did most
> of it, and yes, it's currently included.
>
>
>> I'm still seeing a lot of
>> extraneous whitespace in the pages. 244 KB per page isn't huge, but just
>> at a cursory glance,
>
>
> Can you give me an example of an html page that's that big?  Most I see
> are in the 80-100k range
>
>
>> I think we could probably cut the size 10-20% just
>> by getting rid of the whitespace. In some places, there are just
>> hundreds of newlines in a row for no reason.
>
>
> Give me an example page.
>
>
>> If this is just what the
>> tool generates, I understand that, we don't have any control over that,
>> just wanted to know. We could remove it all pretty easily with sed
>> probably, and think could be a final "post processing" step in the
>> Makefile, run recursively on all files. What do you think?
>>
>
> I tried to do exactly that but it didn't result in much savings and I got
> nervous about accidentally deleting multiple "blank" lines without knowing
> whether you might be in a "" block or not.   I was going to
> try html-minifier but just haven't got to it yet.
>

Oh, there's a mkdocs plugin called "minify".  I can give that a try.



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

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

Re: [asterisk-dev] Final Preview: docs.asterisk.org

[George Joseph]

On Fri, Jul 28, 2023 at 1:52 PM  wrote:

>
> It's at the very bottom of the README:
> > If you're always going to build just 1 branch's dynamic documentation,
> > you can skip the Makefile..inc file and just place everything in the
> > main Makefile.inc:
>
> The first Makefile..inc has an extra period world's least important
> typo.
>

Ahha!   It's 'Makefile..inc' in the source README.md but the
'' is getting stripped. :)



> Circling back to one other thing now that this seems good to go, what
> exactly did you change for reducing the file sizes / is that included in
> the current iteration, without mike?


The addition of "navigation.prune" under features in mkdocs.yml did most of
it, and yes, it's currently included.


> I'm still seeing a lot of
> extraneous whitespace in the pages. 244 KB per page isn't huge, but just
> at a cursory glance,


Can you give me an example of an html page that's that big?  Most I see are
in the 80-100k range


> I think we could probably cut the size 10-20% just
> by getting rid of the whitespace. In some places, there are just
> hundreds of newlines in a row for no reason.


Give me an example page.


> If this is just what the
> tool generates, I understand that, we don't have any control over that,
> just wanted to know. We could remove it all pretty easily with sed
> probably, and think could be a final "post processing" step in the
> Makefile, run recursively on all files. What do you think?
>

I tried to do exactly that but it didn't result in much savings and I got
nervous about accidentally deleting multiple "blank" lines without knowing
whether you might be in a "" block or not.   I was going to
try html-minifier but just haven't got to it yet.
-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

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

Re: [asterisk-dev] Final Preview: docs.asterisk.org

[George Joseph]

>
>
> >
> > TBH, I haven't looked at that stuff in years.  It could probably be
> > simplified quite a bit.
>
> Thanks, I'll play with these further and see if I can solve the include
> omission I had before. Simplification aside, I think this type of stuff
> has been historically underdocumented, so maybe we could have a wiki
> page delving into these? If I come up with any useful notes, I could
> share there as well.
>

Good idea.


>
> > Only one??   Fixed.
>
> Only one at the time... I just found an extra period in Makefile..inc in
> the latest README, but haven't noticed anything else.
>
> Not seeing it.  Probably fixed already.


> > Makefile.inc:
> > ASTERISK_XML_FILE := /core-en_US.xml
> > SKIP_ARI := yes
> > BRANCHES := 20
>
> Got it - this makes a lot more sense now! And yes, you read my mind, I
> don't care about ARI so that did the trick. I noticed the no-mike branch
> no longer exists, but looks like it was merged into main now, so I gave
> that a go and it got much further (sorry, I know it's been a while and I
> wasn't able to test this quickly).
>
> Couldn't have asked for an easier process! It seems like I can just
> clone the repo, copy my Makefile.inc in there, and run make. The above
> was on a relatively fast CPU, but it seems it shouldn't take longer than
> maybe 2 minutes.
>
> The result is a 1.6 GB directory,


Eh what?  When I build everything, temp/site is only 574M.  Maybe need to
clean everything out or is your own stuff just that big?


> but it looks like there are 555M for
> latest_api and 511M for Asterisk 20. I guess I really only need "latest"
> (which I'm assuming is master) for the purposes of an application
> reference, since that should be a superset of everything (except stuff
> that's been removed obviously, which I don't care about).
>

In docs, latest_api is a symlink to 20 but when mkdocs creates the site, it
doesn't preserve that symlink.   Will eventually fix that.


>
> It's also still generating the static docs, not just the dynamic docs,
> which is most of the other space.


See below.


> It looks like from the latest README,
> I can just use Makefile directly instead of Makefile.inc since I only
> need 1 branch, although I kind of like the Makefile.inc now to keep my
> stuff separate from the rest of the repo, and it doesn't look like that
> should make a difference. But if I do "make BRANCH=master" (with
> Makefile.20.inc duplicated to Makefile.master.inc), it doesn't seem to
> work:
>
> root@debian11:/usr/src/documentation# make BRANCH=master
> Creating ./temp/build-master
> Setting Up Core Dynamic Documentation for branch 'master'
>Generating markdown from Asterisk XML
> ln: failed to create symbolic link
> './temp/docs/Asterisk_master_Documentation/API_Documentation': No such
> file or directory
> make: *** [Makefile:105: dynamic-core-setup] Error 1
>

One of the reasons for needing the static docs is that's what creates the
directory structure including the subdirectories for each branch's API
documentation.  Since we don't build documentation for master there's no
directory for it.

See below...


>
>  From what I tried initially, I should be able to solve this by deleting
> everything in the docs directory except index.md and the favicon, which
> ensures that there simply is no static content to build. That should
> bring down both the size and the build time. I don't mind doing that at
> all, just wondering is there a good way to not build the static content,
> or would that be the best way?
>

Do a git pull :)
You should now be able to do...
"make BRANCH=master NO_STATIC=yes"

You can add NO_STATIC=yes to your makefile.inc instead.


> This is already great by the way, for what I need to it to do - none of
> this is super important though, but if you have any thoughts I'll give
> it another go and see if I can get a more optimized build.
>
-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

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

Re: [asterisk-dev] Final Preview: docs.asterisk.org

[George Joseph]

On Tue, Jul 11, 2023 at 3:28 PM  wrote:

> On 7/11/2023 4:34 PM, George Joseph wrote:
> > On Sat, Jul 8, 2023 at 4:24 PM  > <mailto:aster...@phreaknet.org>> wrote:
> >
> > Hi, Geroge,
> >  Just had a chance to look at this this afternoon. The
> > instructions
> > for the dynamic doc generation definitely made my head hurt a little
> > bit, but I have a few thoughts after putzing around a little bit.
> >
> >
> > Your head should be much better now. :)
>
> Much better... the A/C repairman just left too, which helps :)
>

I'll bet.  It was over 102F/39C here in Denver yesterday.


>
> >
> > My initial thought was that some of the make targets in the Makefile
> > could be split up a little bit. The version-dynamic target both
> > downloads documentation source and does the actual build of the
> > documentation. They could be split into different targets:
> >
> >   * In my case, I don't want to download the upstream Asterisk
> > documentation, I want to use the local core-en-us.xml, which is a
> > superset of the documentation available upstream.
> >
> >
> > Uhm are you sure??   The core XML document generated during a build
> > doesn't have the xinclude references de-referenced.  I'd be interested
> > to know what you're seeing.
>
> Mm... yes, you're right about that. I remember encountering that
> limitation when I wrote my converter. I planned to do something about
> it, but never did :)
> My core-en_US.xml and full-en_US.xml files are very similar in size so I
> don't think which one I use would make any difference with this.
>
> As far as "what I'm seeing", this is an example of what I get when I
> take my built XML file at the end of compiling and run it through my
> conversion script: https://asterisk.phreaknet.org/
>
> 

>
> I could keep using this, of course, since nothing has changed with the
> XML and there's no Confluence involved, but what you've done with the
> dynamic docs is way better (and the search capability is really nice),
> so I'd like to migrate to that for internal documentation.
>
> How are the includes *supposed* to be handled, by the way i.e. what's
> supposed to dereference the xincludes? Is it one of the Asterisk build
> scripts for the docs piecing everything together, or is it expected that
> whatever consumes the XML files is able to handle those?
>

XML processing is kinda spread out all over
* build_tools/get_documentation.py
* build_tools/make_xml_documentation
* loader.c:load_modules().

TBH, I haven't looked at that stuff in years.  It could probably be
simplified quite a bit.


>
> > There are now facilities in the Makefile to get the dynamic sources
> > from your
> > local system.   In that case, gh is not required. Details in the README.
>
> Found a typo in the new README, seems to be just on that branch so I
> guess I can't submit a PR: "CreteDocs"
>

Only one??   Fixed.



>
> > You don't need to avoid the Makefile.  You can specify where to get
> > the dynamic sources from and which branches to build.  Details in the
> > README.
>
> I'm a little confused about the BRANCHES variable in Makefile.inc. I
> presume this is irrelevant if using a local XML doc? If only because
> there's only one version of Asterisk compiled (and from which the XML
> doc is sourced). It does specifically say if I'm using local sources I
> need separate Makefile.branch.inc's though so I think I'm not
> understanding something here.
>

> I think I understand why the branches are needed - because now it's
> building all the docs for all the versions into the same site. I think
> my point of confusion is the dynamic doc builder only sees an XML file,
> it can't even possibly know what version of Asterisk that's for without
> being told, can it? I was thinking that make BRANCHES=XX just needs to
> match Makefile.XX.inc, but wasn't sure if there's any other significance
> to these values.
>

You're on the right track.  If you want to do a full build for multiple
branches and wanted to use local documentation for each, you'd need a
Makefile..inc  file for each branch whose ASTERISK_XML_FILE
and ASTERISK_ARI_DIR variables point to different sets of source
documentation.  So yes, you'd need a Makefile..inc file for each
entry in BRANCHES that you want to use local documentation for.  If you
wanted to, you _could_ use local documentation for only a subset of
branches and retrieve the rest from the Asterisk nightly job.  The trigger
is whether those 2 variables are defined ro a branch or not.

If you only want to build 1 branch, say 20, with local docs, the solution
is even s

Re: [asterisk-dev] Final Preview: docs.asterisk.org

[George Joseph]

Comments in line ...

On Sat, Jul 8, 2023 at 4:24 PM  wrote:

> Hi, Geroge,
>  Just had a chance to look at this this afternoon. The instructions
> for the dynamic doc generation definitely made my head hurt a little
> bit, but I have a few thoughts after putzing around a little bit.
>

Your head should be much better now. :)


>
> My initial thought was that some of the make targets in the Makefile
> could be split up a little bit. The version-dynamic target both
> downloads documentation source and does the actual build of the
> documentation. They could be split into different targets:
>
>   * In my case, I don't want to download the upstream Asterisk
> documentation, I want to use the local core-en-us.xml, which is a
> superset of the documentation available upstream.
>

Uhm are you sure??   The core XML document generated during a build doesn't
have the xinclude references de-referenced.  I'd be interested to know what
you're seeing.


>   * Since I'm not downloading the docs, I don't think I need the "gh"
> tool, and so it doesn't need to be installed for purely generating
> documentation. (Also, could be documented as a pre-req, if doing the
> download step)
>

There are now facilities in the Makefile to get the dynamic sources from
your
local system.   In that case, gh is not required.  Details in the README.


>
> Then again, when you boil it down to that, it seems like it really comes
> down to just:
>
>   * utils/astxml2markdown.py
>   * mike deploy
>
> So it seems I'm better off avoiding the makefile and just running the
> individual commands needed. I'll end up wrapping it in a script anyways,
> but just wondering if there's anything else about the process here I've
> missed that wouldn't be conducive to that?
>

You don't need to avoid the Makefile.  You can specify where to get the
dynamic sources from and which branches to build.  Details in the README.


>
> In particular, it doesn't seem that finagling with Git repositories is
> necessary at all to build the dynamic docs. I was able to get it to work
> with just this:
>

No more git repo finagling.


>
> git clone https://github.com/asterisk/documentation.git --depth 1
> cd documentation
> pip3 install -r requirements.txt
> mv docs/favicon.ico docs/index.md .
> rm -rf docs/*
> mv favicon.ico index.md docs
> utils/astxml2markdown.py
> --file=/usr/src/asterisk-20.3.0/doc/core-en_US.xml
> --xslt=utils/astxml2markdown.xslt --directory=docs/ --branch=20
> --version=20.3.0
> mike deploy -F mkdocs.yml 20
> rm -rf /var/www/html/asterisk && mv site /var/www/html/asterisk
> cd .. && rm -rf documentation
>
> It seems to work really well. There were just a couple surprises or
> annoying aspects:
>
>   * Even with --depth 1, the documentation repo takes a hot minute to
> clone, due to all the large PDF artifacts in it, though a tarball of
> the repo wouldn't help either if it came with all the static
> artifacts anyways. Could probably work around that by cloning it
> using svn instead of git, but I was too lazy to do that today.
>

No longer needed.


>   * For just turning markdown into HTML, mike is pretty slow, it takes
> over half a minute just for the dynamic docs (compared to ~1 second
> for my previous method, though that was from the original XML to
> HTML, not from intermediate markdown)
>

mike has bene eliminated.


>   * Most significantly, the webpages are *huge*. Even just the dynamic
> docs are a whopping 228 MB. On average, a documentation page is
> almost 250 KB (compared to 1.2 MB the old way for all the
> applications, functions, AMI/AGI, and configs on a single webpage -
> granted it's not a fair comparison since the menu and what not isn't
> repeated that way). Taking a look at the page source of an
> application[1], much of the page is whitespace. I know that docs
> hosted on GitHub don't need to worry about disk consumption, but for
> folks building the docs themselves, I think it might be worth trying
> to clean this a little bit. Bloated webpages are obviously also
> going to be slower to load as well.
>

File sizes have been significantly reduced by updating mkdocs and using the
new navigation.prune option.  I tried removing all of the extra whitespace
but after the prune option was applied it made very little difference
overall.  We can keep looking at it.


>
> I haven't yet figured out what's introducing all the extraneous
> whitespace. The markdown files seem okay, but things seem to blow up
> somewhere in the middle. Ideally we could prevent it from happening in
> the first place, but if not, then maybe some fancy recursive
> post-processing could strip it all out.
>
> [1] https://docs.asterisk.org/20/_Dialplan_Applications/ADSIProg/
>
>
-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

asterisk-dev mailing list
To UNSUBSCRIBE or 

[asterisk-dev] Documentation: The Next Generation

[George Joseph]

I've just pushed up a new branch to the asterisk/documentation  repo named
'main-no-mike'.  If you've been paying attention you'll know that 'mike'
was the package we were using to handle the dynamic version-specific
documentation.  It kinda worked but was also a royal pain so this new
branch contains the following:

* 'mike' has been eliminated from the build process.  The site now
  looks much like the original wiki with the version-specific
  documentation listed in the left nav bar.

* The latest version of mkdocs is now used which enables the
  navigation.prune option.  This option reduces the site of the
  static pages from 420M to 185M and the total site from well over
  4G to 570M.

* A new plugin 'awesome-pages' has been added which, among other
  things, allows us to set the order of items in the left nav bar.

* The Makefile has been substantially overhauled.

* The README.md has been substantially updated.

* The 'What's New" and "Upgrading to " pages have been
  retrieved from the old wiki are now available.

That branch isn't live yet so if you want to see what's going on before it
does, check that branch out and read the README.

I'll also be replying in the "other" email thread.
-- 
George Joseph
Asterisk Software Developer
Sangoma Technologies
Check us out at www.sangoma.com and www.asterisk.org
-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

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

[asterisk-dev] The Cherry-Pick pull request reminder has been adjusted

[George Joseph]

I made an update this morning that will suppress the cherry-pick reminder
message on pull requests if it determines that there are already
'cherry-pick-to" entries.  To help with cases where no cherry-picking is
needed, the special branch 'none' is also checked for and if found, will
also suppress the message.

So if you don't need cherry-picking, add a comment with
'cherry-pick-to: none' to the pull request.


-- 
George Joseph
Asterisk Software Developer
Sangoma Technologies
Check us out at www.sangoma.com and www.asterisk.org
-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

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

Re: [asterisk-dev] Final Preview: docs.asterisk.org

[George Joseph]

On Mon, Jul 10, 2023 at 1:06 PM  wrote:

> On 7/10/2023 10:09 AM, George Joseph wrote:
> > I'm digesting this.  It may be a while. :)
>
> Sorry, didn't mean to dump a novel on you there. Let me know if there's
> anything I should clarify.
>

No worries.  I've managed to eliminate 'mike' completely and
restructured things so the left nav bar looks much like the original wiki
with an entry for each branch's API documentation.  The site is also now
built as one complete site and it's much easier to just build the static
docs then add in the dynamic docs.  The makefile also has a dependency on
./temp/build-XX/source/asterisk-docs.xml so if it already exists (say if
you pre-copied core-en_US.xml to it) it won't do the download and extract.
 I just need to update the README and I'll push this up as a new branch so
you can take a look without disturbing the existing stuff.


>
> On another note, after a couple months of being in the GitHub workflow,
> here's another suggestion for improvement, if it's an easy change to make:
>
> The workflow that reminds people to post a cherry pick comment is
> obviously helpful. However, I've noticed that this runs on issues,
> regardless of whether or not a comment already exists on the issue for
> cherry picks. I usually post that comment before the bot kicks in, but
> it comments nonetheless. GitHub sends a voluminous amount of email,
> which isn't necessarily bad per se, but at this point, I find I've been
> conditioned to ignore these emails and notices, though every now and
> then I will forget and then it ends up being harder to keep track of due
> to all the "noise" mixed in.
>
>
Actually, I thought I did this already but it must have escaped my mind.
I'll get to it this week.


> Instead of "crying wolf" all the time, would it be possible to have
> these comment on issues only if there isn't already an existing comment?
> If that wouldn't be trivial to do, no biggie, just one (minor) painpoint
> I've noticed.
>
> Other than the well known problem of the tests constantly failing to the
> point where I'm just ignoring test failures as well, no other issues
> I've noticed; everything has been pretty smooth. Kudos to George and
> everyone else for making this a really smooth transition.
>

Thanks!


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

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

Re: [asterisk-dev] Final Preview: docs.asterisk.org

[George Joseph]

I'm digesting this.  It may be a while. :)


On Sat, Jul 8, 2023 at 4:24 PM  wrote:

> On 6/29/2023 3:14 PM, George Joseph wrote:
> > I think we're at a point where the new documentation site can go
> > live.  The dynamic documentation is integrated and the README file has
> > been expanded greatly with information on how the site is built and
> > how you can build it yourself.
>
> Hi, Geroge,
>  Just had a chance to look at this this afternoon. The instructions
> for the dynamic doc generation definitely made my head hurt a little
> bit, but I have a few thoughts after putzing around a little bit.
>
> My initial thought was that some of the make targets in the Makefile
> could be split up a little bit. The version-dynamic target both
> downloads documentation source and does the actual build of the
> documentation. They could be split into different targets:
>
>   * In my case, I don't want to download the upstream Asterisk
> documentation, I want to use the local core-en-us.xml, which is a
> superset of the documentation available upstream.
>   * Since I'm not downloading the docs, I don't think I need the "gh"
> tool, and so it doesn't need to be installed for purely generating
> documentation. (Also, could be documented as a pre-req, if doing the
> download step)
>
> Then again, when you boil it down to that, it seems like it really comes
> down to just:
>
>   * utils/astxml2markdown.py
>   * mike deploy
>
> So it seems I'm better off avoiding the makefile and just running the
> individual commands needed. I'll end up wrapping it in a script anyways,
> but just wondering if there's anything else about the process here I've
> missed that wouldn't be conducive to that?
>
> In particular, it doesn't seem that finagling with Git repositories is
> necessary at all to build the dynamic docs. I was able to get it to work
> with just this:
>
> git clone https://github.com/asterisk/documentation.git --depth 1
> cd documentation
> pip3 install -r requirements.txt
> mv docs/favicon.ico docs/index.md .
> rm -rf docs/*
> mv favicon.ico index.md docs
> utils/astxml2markdown.py
> --file=/usr/src/asterisk-20.3.0/doc/core-en_US.xml
> --xslt=utils/astxml2markdown.xslt --directory=docs/ --branch=20
> --version=20.3.0
> mike deploy -F mkdocs.yml 20
> rm -rf /var/www/html/asterisk && mv site /var/www/html/asterisk
> cd .. && rm -rf documentation
>
> It seems to work really well. There were just a couple surprises or
> annoying aspects:
>
>   * Even with --depth 1, the documentation repo takes a hot minute to
> clone, due to all the large PDF artifacts in it, though a tarball of
> the repo wouldn't help either if it came with all the static
> artifacts anyways. Could probably work around that by cloning it
> using svn instead of git, but I was too lazy to do that today.
>   * For just turning markdown into HTML, mike is pretty slow, it takes
> over half a minute just for the dynamic docs (compared to ~1 second
> for my previous method, though that was from the original XML to
> HTML, not from intermediate markdown)
>   * Most significantly, the webpages are *huge*. Even just the dynamic
> docs are a whopping 228 MB. On average, a documentation page is
> almost 250 KB (compared to 1.2 MB the old way for all the
> applications, functions, AMI/AGI, and configs on a single webpage -
> granted it's not a fair comparison since the menu and what not isn't
> repeated that way). Taking a look at the page source of an
> application[1], much of the page is whitespace. I know that docs
> hosted on GitHub don't need to worry about disk consumption, but for
> folks building the docs themselves, I think it might be worth trying
> to clean this a little bit. Bloated webpages are obviously also
> going to be slower to load as well.
>
> I haven't yet figured out what's introducing all the extraneous
> whitespace. The markdown files seem okay, but things seem to blow up
> somewhere in the middle. Ideally we could prevent it from happening in
> the first place, but if not, then maybe some fancy recursive
> post-processing could strip it all out.
>
> [1] https://docs.asterisk.org/20/_Dialplan_Applications/ADSIProg/
>
>
-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

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

Re: [asterisk-dev] Final Preview: docs.asterisk.org

[George Joseph]

On Fri, Jun 30, 2023 at 9:36 AM Andrew Latham  wrote:

> George
>
> I just had an idea. We could disable the github plugin by not setting a
> repo and then just add the links to a custom footer or `About` page. Just a
> thought
>

Actually, changing that plugin to point to the actual asterisk repo makes
more sense and seems to show the correct release, number of stars and forks.


>
> On Fri, Jun 30, 2023 at 9:33 AM Andrew Latham  wrote:
>
>> Ack, thanks George
>>
>> * As best I can tell in the JS [1] it needs a release to generate the
>> version. I do agree with you that there is no real need for releases.
>> However to enable the JS to work a release may be required.
>> * I can see how the double Asterisk logos at the bottom would be
>> confusing. I just get a cringe factor when I see the wordpress logo and
>> that is just a me thing.
>>
>> 1.
>> https://github.com/squidfunk/mkdocs-material/blob/55fb2e335e04df5b206f2058ba4b706d930b496f/src/assets/javascripts/components/source/facts/github/index.ts#L67C1-L75
>>
>> On Fri, Jun 30, 2023 at 5:23 AM George Joseph 
>> wrote:
>>
>>>
>>>
>>> On Thu, Jun 29, 2023 at 2:06 PM Andrew Latham  wrote:
>>>
>>>> Good Work George and crew. It looks really good, it is snappy, looks
>>>> nice on mobile.
>>>>
>>>
>>> Thanks!
>>>
>>>
>>>>
>>>> All boxes checked!!!
>>>>
>>>> Nits
>>>>
>>>> 1. I get a 404 on
>>>> https://api.github.com/repos/asterisk/documentation/releases/latest
>>>> because there is no release yet I guess
>>>>
>>>
>>> Correct.  We're not going to do actual releases here because the site is
>>> live off the gh-pages branch and whatever is in the main branch.  Do you
>>> think we need to?
>>>
>>>
>>>> 2. I am thinking the Asterisk Logo would be good at the bottom instead
>>>> of the wordpress icon for the blog. Thinking outloud
>>>>
>>>
>>> Then it'd look no different than the website icon.  Maybe we can make
>>> the background asterisk-orange or something but keep the wordpress logo.
>>>
>>>
>>>>
>>>> On Thu, Jun 29, 2023 at 1:14 PM George Joseph 
>>>> wrote:
>>>>
>>>>> I think we're at a point where the new documentation site can go
>>>>> live.  The dynamic documentation is integrated and the README file has 
>>>>> been
>>>>> expanded greatly with information on how the site is built and how you can
>>>>> build it yourself.
>>>>>
>>>>> Please give it a final look:  https://docs.asterisk.org
>>>>>
>>>>> --
>>>>> George Joseph
>>>>> Asterisk Software Developer
>>>>> Sangoma Technologies
>>>>> Check us out at www.sangoma.com and www.asterisk.org
>>>>> --
>>>>> _
>>>>> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
>>>>>
>>>>> asterisk-dev mailing list
>>>>> To UNSUBSCRIBE or update options visit:
>>>>>http://lists.digium.com/mailman/listinfo/asterisk-dev
>>>>
>>>>
>>>>
>>>> --
>>>> - Andrew "lathama" Latham -
>>>> --
>>>> _
>>>> -- Bandwidth and Colocation Provided 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
>>
>>
>>
>> --
>> - Andrew "lathama" Latham -
>>
>
>
> --
> - Andrew "lathama" Latham -
> --
> _
> -- Bandwidth and Colocation Provided 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] Final Preview: docs.asterisk.org

[George Joseph]

On Fri, Jun 30, 2023 at 8:30 AM Shloime Rosenblum <
shloimerosenb...@gmail.com> wrote:

> Is the double bullets on purpose?
>

Nope.  I thought I fixed those.  Added to the list.


>
> [image: image.png]
>
> On Fri, Jun 30, 2023 at 10:03 AM Niklas Larsson  wrote:
>
>> Hi,
>>
>> On
>> https://docs.asterisk.org/20/Configuration/Channel-Drivers/SIP/Configuring-res_pjsip/
>> the link to "Core res_pjsip configuration options" points to
>> https://docs.asterisk.org/latest/Asterisk-12-Configuration_res_pjsip -
>> and that is a 404
>>
>> /niklas
>>
>> On 2023-06-29 21:14, George Joseph wrote:
>>
>> I think we're at a point where the new documentation site can go live.
>> The dynamic documentation is integrated and the README file has been
>> expanded greatly with information on how the site is built and how you can
>> build it yourself.
>>
>> Please give it a final look:  https://docs.asterisk.org
>>
>> --
>> George Joseph
>> Asterisk Software Developer
>> Sangoma Technologies
>> Check us out at www.sangoma.com and www.asterisk.org
>>
>>
>> --
>> _
>> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
>>
>> asterisk-dev mailing list
>> To UNSUBSCRIBE or update options visit:
>>http://lists.digium.com/mailman/listinfo/asterisk-dev
>
> --
> _
> -- Bandwidth and Colocation Provided 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] Final Preview: docs.asterisk.org

[George Joseph]

On Fri, Jun 30, 2023 at 8:03 AM Niklas Larsson  wrote:

> Hi,
>
> On
> https://docs.asterisk.org/20/Configuration/Channel-Drivers/SIP/Configuring-res_pjsip/
> the link to "Core res_pjsip configuration options" points to
> https://docs.asterisk.org/latest/Asterisk-12-Configuration_res_pjsip -
> and that is a 404
>
>
Yeah, there are a bunch of those that still need to be fixed.
Adding to the list for this afternoon.



> /niklas
>
> On 2023-06-29 21:14, George Joseph wrote:
>
> I think we're at a point where the new documentation site can go live.
> The dynamic documentation is integrated and the README file has been
> expanded greatly with information on how the site is built and how you can
> build it yourself.
>
> Please give it a final look:  https://docs.asterisk.org
>
> --
> George Joseph
> Asterisk Software Developer
> Sangoma Technologies
> Check us out at www.sangoma.com and www.asterisk.org
>
>
> --
> _
> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
>
> asterisk-dev mailing list
> To UNSUBSCRIBE or update options visit:
>http://lists.digium.com/mailman/listinfo/asterisk-dev
-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

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

Re: [asterisk-dev] Final Preview: docs.asterisk.org

[George Joseph]

On Thu, Jun 29, 2023 at 2:07 PM Andrew Latham  wrote:

> More testing, I notice the logo is missing on the versions in the top left
> corner eg https://docs.asterisk.org/19/
>

Oh yeah.  I probably need to copy it somewhere.  I'll do that later today.


>
> On Thu, Jun 29, 2023 at 2:05 PM Andrew Latham  wrote:
>
>> Good Work George and crew. It looks really good, it is snappy, looks nice
>> on mobile.
>>
>> All boxes checked!!!
>>
>> Nits
>>
>> 1. I get a 404 on
>> https://api.github.com/repos/asterisk/documentation/releases/latest
>> because there is no release yet I guess
>> 2. I am thinking the Asterisk Logo would be good at the bottom instead of
>> the wordpress icon for the blog. Thinking outloud
>>
>> On Thu, Jun 29, 2023 at 1:14 PM George Joseph 
>> wrote:
>>
>>> I think we're at a point where the new documentation site can go live.
>>> The dynamic documentation is integrated and the README file has been
>>> expanded greatly with information on how the site is built and how you can
>>> build it yourself.
>>>
>>> Please give it a final look:  https://docs.asterisk.org
>>>
>>> --
>>> George Joseph
>>> Asterisk Software Developer
>>> Sangoma Technologies
>>> Check us out at www.sangoma.com and www.asterisk.org
>>> --
>>> _
>>> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
>>>
>>> asterisk-dev mailing list
>>> To UNSUBSCRIBE or update options visit:
>>>http://lists.digium.com/mailman/listinfo/asterisk-dev
>>
>>
>>
>> --
>> - Andrew "lathama" Latham -
>>
>
>
> --
> - Andrew "lathama" Latham -
> --
> _
> -- Bandwidth and Colocation Provided 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] Final Preview: docs.asterisk.org

[George Joseph]

On Thu, Jun 29, 2023 at 2:06 PM Andrew Latham  wrote:

> Good Work George and crew. It looks really good, it is snappy, looks nice
> on mobile.
>

Thanks!


>
> All boxes checked!!!
>
> Nits
>
> 1. I get a 404 on
> https://api.github.com/repos/asterisk/documentation/releases/latest
> because there is no release yet I guess
>

Correct.  We're not going to do actual releases here because the site is
live off the gh-pages branch and whatever is in the main branch.  Do you
think we need to?


> 2. I am thinking the Asterisk Logo would be good at the bottom instead of
> the wordpress icon for the blog. Thinking outloud
>

Then it'd look no different than the website icon.  Maybe we can make the
background asterisk-orange or something but keep the wordpress logo.


>
> On Thu, Jun 29, 2023 at 1:14 PM George Joseph  wrote:
>
>> I think we're at a point where the new documentation site can go live.
>> The dynamic documentation is integrated and the README file has been
>> expanded greatly with information on how the site is built and how you can
>> build it yourself.
>>
>> Please give it a final look:  https://docs.asterisk.org
>>
>> --
>> George Joseph
>> Asterisk Software Developer
>> Sangoma Technologies
>> Check us out at www.sangoma.com and www.asterisk.org
>> --
>> _
>> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
>>
>> asterisk-dev mailing list
>> To UNSUBSCRIBE or update options visit:
>>http://lists.digium.com/mailman/listinfo/asterisk-dev
>
>
>
> --
> - Andrew "lathama" Latham -
> --
> _
> -- Bandwidth and Colocation Provided 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

[asterisk-dev] Final Preview: docs.asterisk.org

[George Joseph]

I think we're at a point where the new documentation site can go live.  The
dynamic documentation is integrated and the README file has been expanded
greatly with information on how the site is built and how you can build it
yourself.

Please give it a final look:  https://docs.asterisk.org

-- 
George Joseph
Asterisk Software Developer
Sangoma Technologies
Check us out at www.sangoma.com and www.asterisk.org
-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

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

Re: [asterisk-dev] New Asterisk Documentation website is available for preview

[George Joseph]

On Tue, Jun 20, 2023 at 7:20 PM Andrew Latham  wrote:

> Maybe file an issue at https://github.com/asterisk/documentation/issues
>
> I just tested and it works on localhost for me. It also prompted me for
> cookies so I will do a PR for that.
>

PR to disable cookies has been merged.


>
> On Tue, Jun 20, 2023 at 6:53 PM  wrote:
>
>> On 6/20/2023 8:33 PM, George Joseph wrote:
>> > On Tue, Jun 20, 2023 at 5:06 PM Joshua C. Colp > > <mailto:jc...@sangoma.com>> wrote:
>> >
>> > On Tue, Jun 20, 2023 at 3:51 PM > > <mailto:aster...@phreaknet.org>> wrote:
>> >
>> > On 6/20/2023 10:32 AM, George Joseph wrote:
>> > > The one exception is the auto-generated documentation for
>> > > AMI/ARI/Dialplan.  That I'm starting to work on now.
>> > Thanks, George - I see from the README that one can run this
>> > on a local
>> > webserver. Will the auto-generated documentation aspect tie in
>> > with this
>> > as well? I wrote my own xmldoc to HTML generator a while back
>> > so I can
>> > view documentation for out of tree modules. If this can do
>> > that out of
>> > the box, then that would certainly be nice functionality to take
>> > advantage of. Will it just be sourcing from a core xml file,
>> > that we can
>> > point elsewhere if we want, or is that going to remain more
>> > upstream
>> > specific like it was with Confluence?
>> >
>> >
>> > I don't know how George plans to approach it fully, but ultimately
>> > the reference documentation will also end up as markdown and
>> > consumed with mkdocs. I do not expect those markdown files to be
>> > checked into the tree but generated as part of the deploy process.
>> > Any tooling to consume the XML and produce the markdown files will
>> > be available, so if someone wanted it locally they could.
>> >
>> >
>> > Each version of Asterisk generates between 800 and 900 pages of
>> > dynamic docs so it's going to take a bit of thought on how to
>> > integrate them.  As Josh noted, we don't want those markdown files
>> > checked into the repo but we do want mkdocs to integrate them
>> > seamlessly into the main docs site, including the search indexing.
>> >  We could run a full site build once a night to convert the static and
>> > dynamic pages into html and index them all BUT we don't have
>> > server-side searching available so it's done in the browser and right
>> > now, even without the dynamic pages, the search_index.json file is
>> > 4.1MB.  This might make it prudent to create a "virtual" site with its
>> > own index just for the dynamic docs and link to it from the main
>> > site.   Maybe even a separate virtual site for each Asterisk version.
>> >  In fact, there are tools to create a versioned API site already
>> > available. Kind of like how Python does it with a drop down at the top
>> > of every page to select the Python version you want to see the
>> > documentation for.
>>
>> Thanks, George - that helps!
>> I was a bit surprised by how fast the search results were on the new
>> site. It seems to be a lot better than the old wiki (which doesn't seem
>> to work anymore, either...)
>>
>> There does seem to be an issue with the web hosting. It seems to be
>> running:
>> root@debian11:/usr/src/documentation# mkdocs serve
>> INFO -  Building documentation...
>> INFO -  Cleaning site directory
>> INFO -  Documentation built in 16.96 seconds
>> INFO -  [20:42:02] Watching paths for changes: 'docs', 'mkdocs.yml'
>> INFO -  [20:42:02] Serving on http://127.0.0.1:8000/
>>
>> But if I navigate to port 8000 on that machine in my browser, I get
>> nothing... nothing even seems to be listening on that port.
>> It works if I curl localhost on that server, so it seems to be listening
>> on just the loopback address. I don't really see how that's helpful - it
>> should probably be listening on all interfaces, so one can see what it
>> looks like graphically, no?
>>
>> Realistically though, I wouldn't want to run a separate python server
>> anyways, I just want static webpages I can serve in an Apache
>> virtualhost, like my current doc generation process. It seems if I run
>> "mkbuild docs" it does that. So if the dynamic docs have a 

Re: [asterisk-dev] New Asterisk Documentation website is available for preview

[George Joseph]

On Tue, Jun 20, 2023 at 5:06 PM Joshua C. Colp  wrote:

> On Tue, Jun 20, 2023 at 3:51 PM  wrote:
>
>> On 6/20/2023 10:32 AM, George Joseph wrote:
>> > The one exception is the auto-generated documentation for
>> > AMI/ARI/Dialplan.  That I'm starting to work on now.
>> Thanks, George - I see from the README that one can run this on a local
>> webserver. Will the auto-generated documentation aspect tie in with this
>> as well? I wrote my own xmldoc to HTML generator a while back so I can
>> view documentation for out of tree modules. If this can do that out of
>> the box, then that would certainly be nice functionality to take
>> advantage of. Will it just be sourcing from a core xml file, that we can
>> point elsewhere if we want, or is that going to remain more upstream
>> specific like it was with Confluence?
>>
>
> I don't know how George plans to approach it fully, but ultimately the
> reference documentation will also end up as markdown and consumed with
> mkdocs. I do not expect those markdown files to be checked into the tree
> but generated as part of the deploy process. Any tooling to consume the XML
> and produce the markdown files will be available, so if someone wanted it
> locally they could.
>

Each version of Asterisk generates between 800 and 900 pages of dynamic
docs so it's going to take a bit of thought on how to integrate them.  As
Josh noted, we don't want those markdown files checked into the repo but we
do want mkdocs to integrate them seamlessly into the main docs site,
including the search indexing.   We could run a full site build once a
night to convert the static and dynamic pages into html and index them all
BUT we don't have server-side searching available so it's done in the
browser and right now, even without the dynamic pages, the
search_index.json file is 4.1MB.  This might make it prudent to create a
"virtual" site with its own index just for the dynamic docs and link to it
from the main site.   Maybe even a separate virtual site for each Asterisk
version.   In fact, there are tools to create a versioned API site already
available.  Kind of like how Python does it with a drop down at the top of
every page to select the Python version you want to see the documentation
for.

Stay tuned!

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

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

Re: [asterisk-dev] New Asterisk Documentation website is available for preview

[George Joseph]

On Tue, Jun 20, 2023 at 8:50 AM Sylvain Boily  wrote:

> Hello,
>
> On 2023-06-20 10:42 a.m., George Joseph wrote:
>
>
>
> On Tue, Jun 20, 2023 at 8:41 AM Andrew Latham  wrote:
>
>> Geroge, it looks and feels good. Grumpy old person would ask why cookies
>> are needed for a documentation site but I have not dug in deep enough yet.
>>
>
> It's just to persist the light/dark theme setting.
>
>
> What i see, it's for google analytics, theme setting is in localstorage.
>

Hmmm.  We don't have any analytics turned on.  I wonder if it has something
to do with the GitHub integration. Let me check.  It's still needed for
localstorage though.




>
> Nice website, thx.
> Sylvain
> --
> _
> -- Bandwidth and Colocation Provided 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] New Asterisk Documentation website is available for preview

[George Joseph]

On Tue, Jun 20, 2023 at 8:41 AM Andrew Latham  wrote:

> Geroge, it looks and feels good. Grumpy old person would ask why cookies
> are needed for a documentation site but I have not dug in deep enough yet.
>

It's just to persist the light/dark theme setting.


>
> On Tue, Jun 20, 2023 at 8:33 AM George Joseph  wrote:
>
>> One of the last tasks in the great Asterisk migration of 2023 is the move
>> of the documentation hosted on the Atlassian Confluence wiki to its new
>> home at https://docs.asterisk.org.   It's a GitHub Pages backed site
>> sourced from a  repo at https://github.com/asterisk/documentation.  We
>> did our best to convert all of the existing documentation but some of the
>> formatting may still be sub-optimal and a small minority of the links might
>> not work but it should be mostly functional.  The one exception is the
>> auto-generated documentation for AMI/ARI/Dialplan.  That I'm starting to
>> work on now.
>>
>> Give the new site a look and feel free to start submitting pull requests
>> for updates.
>>
>> --
>> George Joseph
>> Asterisk Software Developer
>> Sangoma Technologies
>> Check us out at www.sangoma.com and www.asterisk.org
>> --
>> _
>> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
>>
>> asterisk-dev mailing list
>> To UNSUBSCRIBE or update options visit:
>>http://lists.digium.com/mailman/listinfo/asterisk-dev
>
>
>
> --
> - Andrew "lathama" Latham -
> --
> _
> -- Bandwidth and Colocation Provided 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

[asterisk-dev] New Asterisk Documentation website is available for preview

[George Joseph]

One of the last tasks in the great Asterisk migration of 2023 is the move
of the documentation hosted on the Atlassian Confluence wiki to its new
home at https://docs.asterisk.org.   It's a GitHub Pages backed site
sourced from a  repo at https://github.com/asterisk/documentation.  We did
our best to convert all of the existing documentation but some of the
formatting may still be sub-optimal and a small minority of the links might
not work but it should be mostly functional.  The one exception is the
auto-generated documentation for AMI/ARI/Dialplan.  That I'm starting to
work on now.

Give the new site a look and feel free to start submitting pull requests
for updates.

-- 
George Joseph
Asterisk Software Developer
Sangoma Technologies
Check us out at www.sangoma.com and www.asterisk.org
-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

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

Re: [asterisk-dev] GitHub: One Month Update

[George Joseph]

On Tue, Jun 6, 2023 at 5:59 AM Ross Beer  wrote:

> Hi George,
>
> First time using GitHub here and it looks like I need to re-sign the
> contributor license agreement. This is approved in Jira, how do we go about
> signing this in GitHub?
>

If you look in the status section of the PR and scroll to the "license/cla"
entry, you can click "Details" and it'll take you to the CLA manager where
you can sign.  Acceptance is immediate.



>
> I'm sure others will have the same issue so thought it was pertinent to
> reply to this thread.
>
> Regards,
>
> Ross
> ------
> *From:* asterisk-dev  on behalf of
> George Joseph 
> *Sent:* 06 June 2023 12:22
> *To:* Asterisk Developers Mailing List 
> *Subject:* [asterisk-dev] GitHub: One Month Update
>
> It's been a month now since we transitioned over to GitHub so I thought
> I'd give you guys an update but I'd also like to hear your thoughts on the
> transition and new process.
>
> First...A Policy Change...
> When we started, we said "one commit per pull request" to keep things as
> close to Gerrit as possible.  After some discussions and additional
> thinking however, it looks like we can allow multiple commits per pull
> request under the following condition:  The commits MUST be for a single
> functional change and must be able to stand on their own, in sequence from
> first to last commit.  For example, a commit that adds some core capability
> to JSON processing, then a second commit that updates an app or function to
> use it.  In this case, the first commit can stand on its own and the second
> depends on it so having both commits in the same PR would make sense.
> Another good example might be a large scale change required by a new gcc
> version where the files changed in the apps directory might be in one
> commit and the files changed in funcs in another.
>
> What's not acceptable are commits added to a PR that fix issues in other
> commits in the same PR.  This would result in a commit that we know to
> be broken making it into the git history.  An unknowing person might
> checkout that commit and not realize that the following commit is also
> required.  It would also make git-bisects troublesome.  Also not acceptable
> are merge or other housekeeping commits.  I've seen a few merge commits
> just in the past week.
>
> Second...A Reminder...
> Please keep an eye on your commit messages.  Don't put anything extraneous
> after the Fixes/Resolves, UserNote or UpgradeNote trailers.  Keep all
> legacy ASTERISK- mentions, Gerrit links, Reported-by and other stuff  above
> all the new trailers.  It would also help me a great deal if you could
> update the pull request description to match the commit message if you
> happen to fix any of these issues after the PR is created.  We don't parse
> the PR description at all but if I see issues in it I'll have to keep
> drilling down to the commits to see if you've fixed them there.
>
> Third...Merges...
> We had some issues yesterday where two PRs were merged that both updated
> Alembic scripts.  Each PR on its own passed all the tests and merge
> conflict detection but when actually merged broke the previous/next links
> between Alembic scripts.  This happened because we do most of the merge
> checks when PRs are submitted and none just before they're actually
> merged.  GitHub isn't really set up to do pre-merge checks like Gerrit did
> and assumes that if a PR could be merged without git conflict, it must be
> good.  We're looking at ways to solve this issue which may include a new
> "Merge Queue" feature GitHub has in beta testing.  It might take a few
> weeks to iron the kinks out though.  In the mean time, we might
> automatically add an "ALEMBIC CHANGE!" flag to any PR that touches the
> Alembic scripts just to make us aware that there might be a conflict.
>
> Finally...Your Thoughts?
> How's everything working from your perspective?  Anything we should change?
>
> --
> George Joseph
> Asterisk Software Developer
> Sangoma Technologies
> Check us out at www.sangoma.com and www.asterisk.org
> --
> _
> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
>
> asterisk-dev mailing list
> To UNSUBSCRIBE or update options visit:
>http://lists.digium.com/mailman/listinfo/asterisk-dev
>
-- 
_
-- Bandwidth and Colocation Provided 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] GitHub: One Month Update

[George Joseph]

It's been a month now since we transitioned over to GitHub so I thought I'd
give you guys an update but I'd also like to hear your thoughts on the
transition and new process.

First...A Policy Change...
When we started, we said "one commit per pull request" to keep things as
close to Gerrit as possible.  After some discussions and additional
thinking however, it looks like we can allow multiple commits per pull
request under the following condition:  The commits MUST be for a single
functional change and must be able to stand on their own, in sequence from
first to last commit.  For example, a commit that adds some core capability
to JSON processing, then a second commit that updates an app or function to
use it.  In this case, the first commit can stand on its own and the second
depends on it so having both commits in the same PR would make sense.
Another good example might be a large scale change required by a new gcc
version where the files changed in the apps directory might be in one
commit and the files changed in funcs in another.

What's not acceptable are commits added to a PR that fix issues in other
commits in the same PR.  This would result in a commit that we know to
be broken making it into the git history.  An unknowing person might
checkout that commit and not realize that the following commit is also
required.  It would also make git-bisects troublesome.  Also not acceptable
are merge or other housekeeping commits.  I've seen a few merge commits
just in the past week.

Second...A Reminder...
Please keep an eye on your commit messages.  Don't put anything extraneous
after the Fixes/Resolves, UserNote or UpgradeNote trailers.  Keep all
legacy ASTERISK- mentions, Gerrit links, Reported-by and other stuff  above
all the new trailers.  It would also help me a great deal if you could
update the pull request description to match the commit message if you
happen to fix any of these issues after the PR is created.  We don't parse
the PR description at all but if I see issues in it I'll have to keep
drilling down to the commits to see if you've fixed them there.

Third...Merges...
We had some issues yesterday where two PRs were merged that both updated
Alembic scripts.  Each PR on its own passed all the tests and merge
conflict detection but when actually merged broke the previous/next links
between Alembic scripts.  This happened because we do most of the merge
checks when PRs are submitted and none just before they're actually
merged.  GitHub isn't really set up to do pre-merge checks like Gerrit did
and assumes that if a PR could be merged without git conflict, it must be
good.  We're looking at ways to solve this issue which may include a new
"Merge Queue" feature GitHub has in beta testing.  It might take a few
weeks to iron the kinks out though.  In the mean time, we might
automatically add an "ALEMBIC CHANGE!" flag to any PR that touches the
Alembic scripts just to make us aware that there might be a conflict.

Finally...Your Thoughts?
How's everything working from your perspective?  Anything we should change?

-- 
George Joseph
Asterisk Software Developer
Sangoma Technologies
Check us out at www.sangoma.com and www.asterisk.org
-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

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

Re: [asterisk-dev] PLEASE CHECK THE RC RELEASE ARTIFACTS!!

[George Joseph]

On Thu, May 18, 2023 at 11:28 AM Michael Maier  wrote:

> Hello George,
>
> On 18.05.23 at 19:04 George Joseph wrote:
> > We've sorted the announcement issue and you should have just gotten the
> > ones for the RCs.  Since they didn't go out on time, we'll hold off on
> > the GA releases until next Tuesday.
>
> yes, I got them now. I'll take a look how the new tar files are working
> here regarding my existing build process based on a RPM spec file.
>
> I would be glad if there would be URLs to the corresponding git changes.
> This would help to find the code changes belonging to each entry faster.
>

The issue I think is space.  Since the log has to be reasonably readable in
plain text I'm not sure where we'd place the link without making it very
busy.  I'm open to options though so could you maybe mock something up and
post it back to the list so everyone can comment?




>
>
> Thanks
> Michael
>
> --
> _
> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
>
> asterisk-dev mailing list
> To UNSUBSCRIBE or update options visit:
>http://lists.digium.com/mailman/listinfo/asterisk-dev
-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

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

Re: [asterisk-dev] Test HTML version of...Asterisk Release 20.3.0-rc1

[George Joseph]

On Thu, May 18, 2023 at 12:12 PM Fred Posner  wrote:

> Is this type of message going to be common now?
>

> Asking as it’s a departure from the lists general traffic.
>

I sent the test to see what it'd look like and to see what folks thought.
The original is written in markdown which looks reasonably good when sent
as a text email.  The GitHub Action we use to send the email has a "convert
markdown to html" option though so I thought I'd try it out.   It messed up
some of the rendering though so we'll give it a miss.


>
>
> Regards,
>
> Fred Posner
>
>
> > On May 18, 2023, at 2:07 PM, Asterisk Development Team <
> asterisktea...@sangoma.com> wrote:
> >
> > The Asterisk Development Team would like to announce
> > release candidate 1 of Asterisk 20.3.0.
> > The release artifacts are available for immediate download at
> > https://github.com/asterisk/asterisk/releases/tag/20.3.0-rc1 and
> https://downloads.asterisk.org/pub/telephony/asterisk
> > This release resolves issues reported by the community
> > and would have not been possible without your participation.
> > Thank You!
> > Change Log for Release 20.3.0-rc1 Summary:
> > • Set up new ChangeLogs directory
> > • .github: Add AsteriskReleaser
> > • chan_pjsip: also return all codecs on empty re-INVITE for late
> offers
> > • cel: add local optimization begin event
> > • core: Cleanup gerrit and JIRA references. (#57)
> > • .github: Fix CherryPickTest to only run when it should
> > • .github: Fix reference to CHERRYPICKTESTINGINPROGRESS
> > • .github: Remove separate set labels step from new PR
> > • .github: Refactor CP progress and add new PR test progress
> > • res_pjsip: mediasec: Add Security-Client headers after 401
> > • .github: Add cherry-pick test progress labels
> > • LICENSE: Update link to trademark policy.
> > • chan_dahdi: Add dialmode option for FXS lines.
> > • .github: Update issue templates
> > • .github: Remove unnecessary parameter in CherryPickTest
> > • Initial GitHub PRs
> > • Initial GitHub Issue Templates
> > • pbx_dundi: Fix PJSIP endpoint configuration check.
> > • Revert "app_queue: periodic announcement configurable start time."
> > • respjsipstir_shaken: Fix JSON field ordering and disallowed TN
> characters.
> > • pbx_dundi: Add PJSIP support.
> > • install_prereq: Add Linux Mint support.
> > • chan_pjsip: fix music on hold continues after INVITE with replaces
> > • voicemail.conf: Fix incorrect comment about #include.
> > • app_queue: Fix minor xmldoc duplication and vagueness.
> > • test.c: Fix counting of tests and add 2 new tests
> > • res_calendar: output busy state as part of show calendar.
> > • loader.c: Minor module key check simplification.
> > • ael: Regenerate lexers and parsers.
> > • bridgebuiltinfeatures: add beep via touch variable
> > • res_mixmonitor: MixMonitorMute by MixMonitor ID
> > • format_sln: add .slin as supported file extension
> > • res_agi: RECORD FILE plays 2 beeps.
> > • func_json: Fix JSON parsing issues.
> > • app_senddtmf: Add SendFlash AMI action.
> > • app_dial: Fix DTMF not relayed to caller on unanswered calls.
> > • configure: fix detection of re-entrant resolver functions
> > • cli: increase channel column width
> > • app_queue: periodic announcement configurable start time.
> > • make_version: Strip svn stuff and suppress ref HEAD errors
> > • reshttpmedia_cache: Introduce options and customize
> > • main/iostream.c: fix build with libressl
> > • contrib: rc.archlinux.asterisk uses invalid redirect.
> > User Notes:
> > • cel: add local optimization begin event
> > The new ASTCELLOCALOPTIMIZEBEGIN can be used by itself or in conert with
> the existing ASTCELLOCAL_OPTIMIZE to book-end local channel optimizaion.
> > • chan_dahdi: Add dialmode option for FXS lines.
> > A "dialmode" option has been added which allows specifying, on a
> per-channel basis, what methods of subscriber dialing (pulse and/or tone)
> are permitted. Additionally, this can be changed on a channel at any point
> during a call using the CHANNEL function.
> > • app_senddtmf: Add SendFlash AMI action.
> > The SendFlash AMI action now allows sending a hook flash event on a
> channel.
> > • res_mixmonitor: MixMonitorMute by MixMonitor ID
> > It is now possible to specify the MixMonitorID when calling the manager
> action: MixMonitorMute. This will allow an individual MixMonitor instance
> to be muted via ID. The MixMonitorID can be stored as a channel variable
> using the 'i' MixMonitor option and is returned upon creation if this
> option is used. As part of this change, if no MixMonitorID is specified in
> the manager action MixMonitorMute, Asterisk will set the mute flag on all
> MixMonitor audiohooks on the channel. Previous behavior would set the flag
> on the first MixMonitor audiohook found.
> > • bridgebuiltinfeatures: 

Re: [asterisk-dev] PLEASE CHECK THE RC RELEASE ARTIFACTS!!

[George Joseph]

On Thu, May 18, 2023 at 8:30 AM Joshua C. Colp  wrote:

> On Thu, May 18, 2023 at 11:19 AM Michael Maier 
> wrote:
>
>> On 08.05.23 at 20:22 George Joseph wrote:
>> > This is the first release after the GitHub migration so PLEASE
>> > check all the release artifacts to make sure there are no surprises.
>>
>> I'm missing the "Asterisk ... now available mails"
>>
>
> I've added the email address that they may come in as to the mailman
> config as an allowed sender, we'll see if that works.
>

We've sorted the announcement issue and you should have just gotten the
ones for the RCs.  Since they didn't go out on time, we'll hold off on the
GA releases until next Tuesday.
-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

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

Re: [asterisk-dev] PLEASE CHECK THE RC RELEASE ARTIFACTS!!

[George Joseph]

Since we did RC releases last Monday, we would have normally done the GA
releases of 18.18.0 and 20.3.0 yesterday.  However, since these are the
first releases post-migration, we're delaying those until this Thursday to
give more time for feedback.  We haven't received any so far so please, if
you haven't already done so, review the RC tarballs and the releases/18 and
releases/20 branches to make sure you understand the changes and let us
know if you see any issues.

Also, the following wiki documentation has been updated to incorporate the
migration changes:
https://wiki.asterisk.org/wiki/display/AST/Code+Contribution
https://wiki.asterisk.org/wiki/display/AST/Commit+Messages
https://wiki.asterisk.org/wiki/display/AST/Release+Management


On Mon, May 8, 2023 at 12:22 PM George Joseph  wrote:

> This is the first release after the GitHub migration so PLEASE
> check all the release artifacts to make sure there are no surprises.
>
>
> --
> George Joseph
> Asterisk Software Developer
> Sangoma Technologies
> Check us out at www.sangoma.com and www.asterisk.org
>
-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

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

Re: [asterisk-dev] Considering changes to the Change Logs

[George Joseph]

On Tue, May 9, 2023 at 3:07 AM Joshua C. Colp  wrote:

> On Mon, May 8, 2023 at 8:47 PM George Joseph  wrote:
>
>> Thinking of a few things...
>>
>> Look at...
>>
>> https://downloads.asterisk.org/pub/telephony/asterisk/ChangeLog-18.18.0-rc1.md
>> This file is WAY too big (over 700 lines) because it contains the full
>> commit descriptions.  I'm thinking of shortening it down to be the same as
>> the email announcements.  If you really want the details, you should be
>> doing a `git log` anyway.
>>
>
> I disagree on the use of "git log" because that is thinking about this
> from the perspective of a developer, not a user/deployer of Asterisk. They
> may not even have git or have checked Asterisk out from git. I think it's
> perfectly fine and even valuable for the ChangeLog to contain the full
> commit description. The announcement provides high level, if you're
> interested in more then you go to the ChangeLog. Why is it a problem?
>

Just seemed overkill but you're right. It'll stay.


>
>
>>
>> Check out 'releases/18' or 'releases/20'.
>> First, I forgot to add the specific change log for the release (
>> ChangeLog-18.18.0-rc1.md).  I'll fix that before releasing 18.18.0/
>> 20.3.0.
>> Second, I should NOT have updated the ChangeLog and CHANGES files in the
>> tarballs for release candidates.  I'll be backing those updates out.
>> And speaking of ChangeLog and CHANGES... 'ChangeLog' has the full commit
>> description for every commit since August 2013 (over 100K lines) and the
>> CHANGES file has the highlights for every release since version 1.4.
>> Because we always have multiple simultaneous releases in process, the files
>> have large time/release gaps in them and aren't accurate.  They're also a
>> pain to maintain.  Do we really need to keep them?  Going forward they're
>> both just going to have the new release-specific ChangeLogs prepended to
>> them anyway.
>>
>> Thoughts?
>>
>
> The ChangeLog and CHANGES files probably not. Personally I just use them
> as an easier way to build up a first draft of what's gone on over the past
> year.
>
>
We could create a ChangeLogs directory in the releases branches that simply
has the change log for each release added to it.  That way the release
process can add ChangeLog-18.18.0-rc1.md which would have the changes since
18.17.1, then ChangeLog-18.18.0-rc2 which would have  changes since rc1,
etc.  Then when 18.18.0 GA is cut, it can add ChangeLog-18.18.0 with
changes since 18.17.1 and delete the intervening RCs.



> --
> Joshua C. Colp
> Asterisk Project Lead
> Sangoma Technologies
> Check us out at www.sangoma.com and www.asterisk.org
> --
> _
> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
>
> asterisk-dev mailing list
> To UNSUBSCRIBE or update options visit:
>http://lists.digium.com/mailman/listinfo/asterisk-dev
-- 
_
-- Bandwidth and Colocation Provided 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] Considering changes to the Change Logs

[George Joseph]

Thinking of a few things...

Look at...
https://downloads.asterisk.org/pub/telephony/asterisk/ChangeLog-18.18.0-rc1.md
This file is WAY too big (over 700 lines) because it contains the full
commit descriptions.  I'm thinking of shortening it down to be the same as
the email announcements.  If you really want the details, you should be
doing a `git log` anyway.

Check out 'releases/18' or 'releases/20'.
First, I forgot to add the specific change log for the release (
ChangeLog-18.18.0-rc1.md).  I'll fix that before releasing 18.18.0/20.3.0.
Second, I should NOT have updated the ChangeLog and CHANGES files in the
tarballs for release candidates.  I'll be backing those updates out.
And speaking of ChangeLog and CHANGES... 'ChangeLog' has the full commit
description for every commit since August 2013 (over 100K lines) and the
CHANGES file has the highlights for every release since version 1.4.
Because we always have multiple simultaneous releases in process, the files
have large time/release gaps in them and aren't accurate.  They're also a
pain to maintain.  Do we really need to keep them?  Going forward they're
both just going to have the new release-specific ChangeLogs prepended to
them anyway.

Thoughts?

-- 
George Joseph
Asterisk Software Developer
Sangoma Technologies
Check us out at www.sangoma.com and www.asterisk.org
-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

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

[asterisk-dev] PLEASE CHECK THE RC RELEASE ARTIFACTS!!

[George Joseph]

This is the first release after the GitHub migration so PLEASE
check all the release artifacts to make sure there are no surprises.


-- 
George Joseph
Asterisk Software Developer
Sangoma Technologies
Check us out at www.sangoma.com and www.asterisk.org
-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

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

Re: [asterisk-dev] GitHub Cherry-Pick issues

[George Joseph]

On Wed, May 3, 2023 at 7:29 AM George Joseph  wrote:

> There's an issue with the cherry-pick test job running when it's
> not supposed to.  This is resulting in false cherry-pick labels being
> applied to pull requests.   I'm working on it.
>
>
Should now be fixed.



>
> --
> George Joseph
> Asterisk Software Developer
> Sangoma Technologies
> Check us out at www.sangoma.com and www.asterisk.org
>
-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

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

[asterisk-dev] GitHub Cherry-Pick issues

[George Joseph]

There's an issue with the cherry-pick test job running when it's
not supposed to.  This is resulting in false cherry-pick labels being
applied to pull requests.   I'm working on it.


-- 
George Joseph
Asterisk Software Developer
Sangoma Technologies
Check us out at www.sangoma.com and www.asterisk.org
-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

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

[asterisk-dev] IMPORTANT: GitHub Cherry-Pick Policy Change

[George Joseph]

After thinking about it over the weekend, we've decided to reverse the
order of cherry-picks.  Instead of creating PRs for the lowest branch and
cherry-picking upwards, create them for the master branch and cherry-pick
downwards.   There were a few good reasons brought up on IRC but there are
also some GitHub automations that only run on a repository's master /main
branch.  The few existing PRs can remain as they are.

-- 
George Joseph
Asterisk Software Developer
Sangoma Technologies
Check us out at www.sangoma.com and www.asterisk.org
-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

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

Re: [asterisk-dev] Sign the new CLA at any time...

[George Joseph]

On Fri, Apr 28, 2023 at 2:40 PM James Cloos  wrote:

> now it worked.
>
> too much malicious ecmascript...
>

Is something getting flagged?


>
> -JimC
> --
> James Cloos  OpenPGP: 0x997A9F17ED7DAEA6
>
> --
> _
> -- Bandwidth and Colocation Provided 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

[asterisk-dev] GitHub is open for Pull Requests

[George Joseph]

https://github.com/asterisk/asterisk/pulls

Please refresh yourself by reading
https://wiki.asterisk.org/wiki/display/AST/Code+Contribution
again.  There have been a few minor changes.


-- 
George Joseph
Asterisk Software Developer
Sangoma Technologies
Check us out at www.sangoma.com and www.asterisk.org
-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

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

Re: [asterisk-dev] Sign the new CLA at any time...

[George Joseph]

The issue seems to be with unauthenticated requests.  Try signing into
GitHub first, then open another tab and try to sign the CLA.


On Fri, Apr 28, 2023 at 9:35 AM George Joseph  wrote:

> On Fri, Apr 28, 2023 at 9:32 AM Shloime Rosenblum <
> shloimerosenb...@gmail.com> wrote:
>
>> [image: image.png]
>>
>>
> It's always something.  Let me see if I can increase the limits.
>
>
>
>> On Fri, Apr 28, 2023 at 11:19 AM George Joseph 
>> wrote:
>>
>>> Sorry about this guys.  It appears that the cla-assistant GitHub app has
>>> an issue if you try to sign using just the organization.  If you sign for a
>>> specific repository, it'll work and it'll be valid for the entire
>>> organization.  So use...
>>> https://oss-cla.sangoma.com/asterisk/asterisk
>>>
>>> If that doesn't work, I'm going home. :)
>>>
>>>
>>> On Fri, Apr 28, 2023 at 8:57 AM Joshua C. Colp 
>>> wrote:
>>>
>>>> On Fri, Apr 28, 2023 at 11:47 AM Joshua C. Colp 
>>>> wrote:
>>>>
>>>>> On Fri, Apr 28, 2023 at 11:44 AM Henning Westerholt 
>>>>> wrote:
>>>>>
>>>>>> Hello,
>>>>>>
>>>>>>
>>>>>>
>>>>>> to save me (and probably other people) trying to parse that agreement
>>>>>> again some time:
>>>>>>
>>>>>>
>>>>>>
>>>>>> Is this an identical agreement as the one signed in the old process
>>>>>> (on gerrit/Jira etc..)? Or were some changes here done.
>>>>>>
>>>>>
>>>>> It is not identical. It is based on the old one, but has been changed
>>>>> some. As with any agreement it should be reviewed before signing.
>>>>>
>>>>
>>>> If you aren't already logged into Github and try to use the "Sign in
>>>> with Github" this may fail. George is looking into it.
>>>>
>>>> --
>>>> Joshua C. Colp
>>>> Asterisk Project Lead
>>>> Sangoma Technologies
>>>> Check us out at www.sangoma.com and www.asterisk.org
>>>> --
>>>> _
>>>> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
>>>>
>>>> asterisk-dev mailing list
>>>> To UNSUBSCRIBE or update options visit:
>>>>http://lists.digium.com/mailman/listinfo/asterisk-dev
>>>
>>> --
>>> _
>>> -- Bandwidth and Colocation Provided 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] Sign the new CLA at any time...

[George Joseph]

On Fri, Apr 28, 2023 at 9:32 AM Shloime Rosenblum <
shloimerosenb...@gmail.com> wrote:

> [image: image.png]
>
>
It's always something.  Let me see if I can increase the limits.



> On Fri, Apr 28, 2023 at 11:19 AM George Joseph 
> wrote:
>
>> Sorry about this guys.  It appears that the cla-assistant GitHub app has
>> an issue if you try to sign using just the organization.  If you sign for a
>> specific repository, it'll work and it'll be valid for the entire
>> organization.  So use...
>> https://oss-cla.sangoma.com/asterisk/asterisk
>>
>> If that doesn't work, I'm going home. :)
>>
>>
>> On Fri, Apr 28, 2023 at 8:57 AM Joshua C. Colp  wrote:
>>
>>> On Fri, Apr 28, 2023 at 11:47 AM Joshua C. Colp 
>>> wrote:
>>>
>>>> On Fri, Apr 28, 2023 at 11:44 AM Henning Westerholt 
>>>> wrote:
>>>>
>>>>> Hello,
>>>>>
>>>>>
>>>>>
>>>>> to save me (and probably other people) trying to parse that agreement
>>>>> again some time:
>>>>>
>>>>>
>>>>>
>>>>> Is this an identical agreement as the one signed in the old process
>>>>> (on gerrit/Jira etc..)? Or were some changes here done.
>>>>>
>>>>
>>>> It is not identical. It is based on the old one, but has been changed
>>>> some. As with any agreement it should be reviewed before signing.
>>>>
>>>
>>> If you aren't already logged into Github and try to use the "Sign in
>>> with Github" this may fail. George is looking into it.
>>>
>>> --
>>> Joshua C. Colp
>>> Asterisk Project Lead
>>> Sangoma Technologies
>>> Check us out at www.sangoma.com and www.asterisk.org
>>> --
>>> _
>>> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
>>>
>>> asterisk-dev mailing list
>>> To UNSUBSCRIBE or update options visit:
>>>http://lists.digium.com/mailman/listinfo/asterisk-dev
>>
>> --
>> _
>> -- Bandwidth and Colocation Provided 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] Sign the new CLA at any time...

[George Joseph]

Sorry about this guys.  It appears that the cla-assistant GitHub app has an
issue if you try to sign using just the organization.  If you sign for a
specific repository, it'll work and it'll be valid for the entire
organization.  So use...
https://oss-cla.sangoma.com/asterisk/asterisk

If that doesn't work, I'm going home. :)


On Fri, Apr 28, 2023 at 8:57 AM Joshua C. Colp  wrote:

> On Fri, Apr 28, 2023 at 11:47 AM Joshua C. Colp  wrote:
>
>> On Fri, Apr 28, 2023 at 11:44 AM Henning Westerholt 
>> wrote:
>>
>>> Hello,
>>>
>>>
>>>
>>> to save me (and probably other people) trying to parse that agreement
>>> again some time:
>>>
>>>
>>>
>>> Is this an identical agreement as the one signed in the old process (on
>>> gerrit/Jira etc..)? Or were some changes here done.
>>>
>>
>> It is not identical. It is based on the old one, but has been changed
>> some. As with any agreement it should be reviewed before signing.
>>
>
> If you aren't already logged into Github and try to use the "Sign in with
> Github" this may fail. George is looking into it.
>
> --
> Joshua C. Colp
> Asterisk Project Lead
> Sangoma Technologies
> Check us out at www.sangoma.com and www.asterisk.org
> --
> _
> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
>
> asterisk-dev mailing list
> To UNSUBSCRIBE or update options visit:
>http://lists.digium.com/mailman/listinfo/asterisk-dev
-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

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

Re: [asterisk-dev] Sign the new CLA at any time...

[George Joseph]

OK, sorry.  You have to add the slash at the end :)
https://oss-cla.sangoma.com/asterisk/
Stupid reverse proxy.


On Fri, Apr 28, 2023 at 8:16 AM George Joseph  wrote:

> You can get a head start and sign the new Contributor License Agreement at
> any time...
> https://oss-cla.sangoma.com/asterisk
>
> --
> George Joseph
> Asterisk Software Developer
> Sangoma Technologies
> Check us out at www.sangoma.com and www.asterisk.org
>
-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

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

Re: [asterisk-dev] Sign the new CLA at any time...

[George Joseph]

Yeah sorry.  One minute.


On Fri, Apr 28, 2023 at 8:19 AM Sylvain Boily  wrote:

> Hello,
>
> It's 404.
>
> Sylvain
>
> On 2023-04-28 10:16 a.m., George Joseph wrote:
>
> You can get a head start and sign the new Contributor License Agreement at
> any time...
> https://oss-cla.sangoma.com/asterisk
>
> --
> George Joseph
> Asterisk Software Developer
> Sangoma Technologies
> Check us out at www.sangoma.com and www.asterisk.org
>
>
>
-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

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

[asterisk-dev] Sign the new CLA at any time...

[George Joseph]

You can get a head start and sign the new Contributor License Agreement at
any time...
https://oss-cla.sangoma.com/asterisk

-- 
George Joseph
Asterisk Software Developer
Sangoma Technologies
Check us out at www.sangoma.com and www.asterisk.org
-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

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

[asterisk-dev] GitHub Code Contribution Process

[George Joseph]

Greetings all,

I've just made the Code Contribution process available at
https://wiki.asterisk.org/wiki/display/AST/Code+Contribution

Please take a look and give me your feedback.  We can change the process as
needed, and we probably will, if there are any issues.


-- 
*George Joseph*
*Asterisk Software Developer*
-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

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

[asterisk-dev] Asterisk Infrastructure Move to GitHub

[George Joseph]

You guys already know this but I figured i'd post it here as well as the
asterisk-users and asterisk-announce email lists.

--

In order to reduce the amount of system maintenance and administration that
needs to be done by the Asterisk team at Sangoma, we've decided to move
capabilities such as issue tracking, code management/review and
documentation/wiki to hosted solutions. Last year, we compared GitHub and
GitLab and while the evaluation of documentation/wiki alternatives is still
ongoing, we've decided that GitHub offers the best alternative for issues
and code management/review.

The [Asterisk Community Forums](https://community.asterisk.org/) are
already hosted by Discourse and are not moving but you can now also use
your GitHub account to log into the forums. Make sure the email you use for
the forums is also listed under your account Settings/Emails in GitHub.

So...

Over the weekend of April 29-30 2023, GitHub will become the official and
sole platform for issue tracking and code management.  IT IS NOT POSSIBLE
FOR US TO MIGRATE EITHER ISSUES OR CODE REVIEWS TO THE NEW PLATFORMS but
the existing Jira issue tracker and Gerrit code management systems will be
placed in read-only mode for historical reference.  At some point in the
future, the historical issues in Jira will be exported to a searchable
format and the system deactivated.  The Gerrit system will be deactivated
at the same time but since the most important historical data is already
captured as part of the commit history, there's no need to create a
searchable archive.

More detailed information, especially concerning release tarballs,
changelogs, etc are at
https://wiki.asterisk.org/wiki/display/AST/Release+Management

NOTE:  If you're an Asterisk contributor, stay tuned.  There will be more
info about the code management/review process in the next day or so.

-- 
*George Joseph*
*Asterisk Software Developer*
-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

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

Re: [asterisk-dev] GitHub: Side Note: What makes us "special"?

[George Joseph]

On Wed, Apr 5, 2023 at 2:19 AM Dennis Buteyn 
wrote:

> On 4/4/23 21:53, George Joseph wrote:
>
> Every open source project, CI/CD system and SCM system has its own
> quirks.  Asterisk and GitHub are no exception. :)Here's some
> background, most of which is just informational for you but caused us some
> head scratching and will probably continue to do so.
>
>1. Very few GitHub projects have multiple simultaneous release
>branches as we do and GitHub has no built-in cherry-picking functionality.
>2. For very valid security reasons, GitHub limits the permissions of
>workflows triggered by PRs submitted from forked repositories to
>read-only.  Otherwise anyone could fork the Asterisk repo and submit a pull
>request that changes the workflow that's about to run for thiat PR.   OK,
>it's not quite as easy as that but it is a concern.
>3. Some of the automations we need, like simply reporting
>test completion status on the PR, require write access to the PR.
>4. We could add Asterisk community developers as collaborators to the
>repos which would give them additional permissions but that becomes an
>administrative overhead for the core team.  Besides...
>5. GitHub's most restrictive level of collaborator access (Triager)
>allows a user to manipulate the PRs and issues belonging to other users
>which is probably not a good idea.
>6. You know how you can add a "regate" or "recheck" comment to Gerrit
>today and have Jenkins re-run the tests?  Well, GitHub doesn't need that
>because it has the ability to re-run jobs right from the UI.  However, when
>we were thinking about the cherry-pick process we thought we could trigger
>it using the same mechanism...just add the comment and the process would
>kick off.  Unfortunately, unlike Gerrit/Jenkins, if you have a job trigger
>on a comment, it'll trigger on EVERY comment even if the keyword isn't
>present in it.  That's just a waste of resources and it would flood the job
>history with crap.  Then we thought...
>7. In my earlier email I mentioned an Asterisk core team member having
>to add a label to kick off the cherry-pick process.  Well, that started
>with "Let's have the user add labels to kick the cherry-pick process off".
>Except...  A user who is not a member of the organization can't add labels
>even to their own PRs and issues.
>
> That's just some of the background that's driving the process and
> development of the workflows.
>
> Speaking of workflows...  If you want to see the workflows and
> actions we've written so far, check out the asterisk/asterisk-gh-test (the
> .github/workflows directory) and asterisk/asterisk-ci-actions repos.   If
> you're experienced with GitHub workflows, feedback is appreciated.
>
> I've noticed quite a few GitHub projects use bots aka apps to perform a
> variety of tasks such as automatic tagging, triggering builds, adding test
> results and so forth. GitHub provides a fairly rich API which should cover
> most of the issues mentioned. Aside from the usual automation, I've also
> seen bots perform specific actions by writing instructions as comments.
> Hundreds of existing apps can be found on the GitHub marketplace, which
> should give some ideas as to what can or cannot be done.
>
> The Gopherbot seen here <https://github.com/golang/go/issues/59450> for
> example is adding tags and mentions to related issues. And this pull
> request <https://github.com/golang/go/pull/59301> was automatically
> imported into Gerrit for code review and closed after being successfully
> merged. Source of this bot can be found here:
> https://github.com/golang/build/tree/master/cmd/gopherbot
>
> References:
>
> https://docs.github.com/en/apps/creating-github-apps/creating-github-apps/about-apps
> https://docs.github.com/en/rest?apiVersion=2022-11-28
> https://github.com/marketplace
>
> Yeah apps are certainly more powerful but they have to run somewhere and
we were trying to avoid having to add an AWS, gcloud, Azure, etc.
component to the process, at least at first.  We'll keep it in mind though
and if we find a situation where something we really want/need to do can
only be done with an app, we'll reconsider.




> --
> Dennis Buteyn
> Xorcom Ltd
>
> --
> _
> -- Bandwidth and Colocation Provided 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] GitHub: Side Note: What makes us "special"?

[George Joseph]

On Tue, Apr 4, 2023 at 3:03 PM Joshua C. Colp  wrote:

> On Tue, Apr 4, 2023 at 5:27 PM George Joseph  wrote:
>
>>
>>
>> On Tue, Apr 4, 2023 at 1:16 PM  wrote:
>>
>>> On 4/4/2023 2:53 PM, George Joseph wrote:
>>> > 
>>> >
>>> > Speaking of workflows...  If you want to see the workflows and
>>> > actions we've written so far, check out the asterisk/asterisk-gh-test
>>> (the
>>> > .github/workflows directory) and asterisk/asterisk-ci-actions repos.
>>>  If
>>> > you're experienced with GitHub workflows, feedback is appreciated.
>>> Thanks, George, et al, for all this amazing work. I admit Gerrit has
>>> grown on me a little over the years, but other developers I've discussed
>>> with do prefer GitHub and I'm eager to give this a try when it's all
>>> ready.
>>>
>>> One question from looking through some of the workflows that are up now:
>>>
>>> https://github.com/asterisk/asterisk-gh-test/blob/master/.github/workflows/CloseStaleIssues.yml
>>>
>>> I'm a bit curious about the auto-closing functionality:
>>>
>>
>>>   * Do you think 14-21 days is a sufficient threshold for most issues?
>>> It seems potentially a bit low to me. For example, once an issue is
>>> triaged and opened, will it just be closed automatically 3 weeks
>>> later if it hasn't been resolved by then? Or are issues in the
>>> 'open' state exempt from this, this is purely for triage to weed out
>>> junk issues?
>>>
>>   * Case in point: one vendor I deal with frequently has this annoying
>>> auto-close functionality in their system which triggers after about
>>> 2 weeks or so. Often more time is required on one of our ends just
>>> to follow up on the last thing, so there is a lot of inevitable
>>> "commenting to avoid auto closure" and this just adds a lot of noise
>>> into the tickets.
>>>   * Is there any connection with reviews/PRs in progress? Suppose an
>>> issue is open and maybe on the verge of being stale, but someone has
>>> submitted a PR against. Changes can often take much longer than 3
>>> weeks to merge, so it wouldn't make sense for an issue to close
>>> itself in that case. So I'm concerned perhaps that might not be
>>> sufficient time.
>>>
>>
>> We're still thinking about the issues process but...
>>
>> The action allows you to specify labels that make an issue exempt from
>> auto-closure.  I was thinking that when a PR gets submitted, we'd look for
>> the "Resolves: #issuenum" tag in the commit message, then add an
>> "InProgress" label to the issue to prevent it from being auto closed.  The
>> issue would then get closed when the PR is closed.
>>
>> I'm also thinking it would only close issues that have been inactive and
>> assigned to the submitter.  Like the "Waiting for Feedback" status in Jira.
>>
>> Does that make sense?
>>
>
> I think issues should only be closed if we are waiting for feedback from
> the reporter during the triage process. Once accepted the issue should
> remain open until either automatically closed through PR, or someone else
> closes it. Same as now.
>
> Ack.



> --
> Joshua C. Colp
> Asterisk Project Lead
> Sangoma Technologies
> Check us out at www.sangoma.com and www.asterisk.org
> --
> _
> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
>
> asterisk-dev mailing list
> To UNSUBSCRIBE or update options visit:
>http://lists.digium.com/mailman/listinfo/asterisk-dev
-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

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

Re: [asterisk-dev] GitHub: Side Note: What makes us "special"?

[George Joseph]

On Tue, Apr 4, 2023 at 1:16 PM  wrote:

> On 4/4/2023 2:53 PM, George Joseph wrote:
> > 
> >
> > Speaking of workflows...  If you want to see the workflows and
> > actions we've written so far, check out the asterisk/asterisk-gh-test
> (the
> > .github/workflows directory) and asterisk/asterisk-ci-actions repos.   If
> > you're experienced with GitHub workflows, feedback is appreciated.
> Thanks, George, et al, for all this amazing work. I admit Gerrit has
> grown on me a little over the years, but other developers I've discussed
> with do prefer GitHub and I'm eager to give this a try when it's all ready.
>
> One question from looking through some of the workflows that are up now:
>
> https://github.com/asterisk/asterisk-gh-test/blob/master/.github/workflows/CloseStaleIssues.yml
>
> I'm a bit curious about the auto-closing functionality:
>

>   * Do you think 14-21 days is a sufficient threshold for most issues?
> It seems potentially a bit low to me. For example, once an issue is
> triaged and opened, will it just be closed automatically 3 weeks
> later if it hasn't been resolved by then? Or are issues in the
> 'open' state exempt from this, this is purely for triage to weed out
> junk issues?
>
  * Case in point: one vendor I deal with frequently has this annoying
> auto-close functionality in their system which triggers after about
> 2 weeks or so. Often more time is required on one of our ends just
> to follow up on the last thing, so there is a lot of inevitable
> "commenting to avoid auto closure" and this just adds a lot of noise
> into the tickets.
>   * Is there any connection with reviews/PRs in progress? Suppose an
> issue is open and maybe on the verge of being stale, but someone has
> submitted a PR against. Changes can often take much longer than 3
> weeks to merge, so it wouldn't make sense for an issue to close
> itself in that case. So I'm concerned perhaps that might not be
> sufficient time.
>

We're still thinking about the issues process but...

The action allows you to specify labels that make an issue exempt from
auto-closure.  I was thinking that when a PR gets submitted, we'd look for
the "Resolves: #issuenum" tag in the commit message, then add an
"InProgress" label to the issue to prevent it from being auto closed.  The
issue would then get closed when the PR is closed.

I'm also thinking it would only close issues that have been inactive and
assigned to the submitter.  Like the "Waiting for Feedback" status in Jira.

Does that make sense?



>
> I guess this will answer itself after the migration when we see how
> people interact with it, but curious if these were just defaults or if
> these were customized for the project.
>
> Thanks again for all this heavy lifting!
>
>   NA
>
>
-- 
_
-- Bandwidth and Colocation Provided 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] GitHub: Side Note: What makes us "special"?

[George Joseph]

Every open source project, CI/CD system and SCM system has its own quirks.
Asterisk and GitHub are no exception. :)Here's some background, most of
which is just informational for you but caused us some head scratching and
will probably continue to do so.

   1. Very few GitHub projects have multiple simultaneous release branches
   as we do and GitHub has no built-in cherry-picking functionality.
   2. For very valid security reasons, GitHub limits the permissions of
   workflows triggered by PRs submitted from forked repositories to
   read-only.  Otherwise anyone could fork the Asterisk repo and submit a pull
   request that changes the workflow that's about to run for thiat PR.   OK,
   it's not quite as easy as that but it is a concern.
   3. Some of the automations we need, like simply reporting
   test completion status on the PR, require write access to the PR.
   4. We could add Asterisk community developers as collaborators to the
   repos which would give them additional permissions but that becomes an
   administrative overhead for the core team.  Besides...
   5. GitHub's most restrictive level of collaborator access (Triager)
   allows a user to manipulate the PRs and issues belonging to other users
   which is probably not a good idea.
   6. You know how you can add a "regate" or "recheck" comment to Gerrit
   today and have Jenkins re-run the tests?  Well, GitHub doesn't need that
   because it has the ability to re-run jobs right from the UI.  However, when
   we were thinking about the cherry-pick process we thought we could trigger
   it using the same mechanism...just add the comment and the process would
   kick off.  Unfortunately, unlike Gerrit/Jenkins, if you have a job trigger
   on a comment, it'll trigger on EVERY comment even if the keyword isn't
   present in it.  That's just a waste of resources and it would flood the job
   history with crap.  Then we thought...
   7. In my earlier email I mentioned an Asterisk core team member having
   to add a label to kick off the cherry-pick process.  Well, that started
   with "Let's have the user add labels to kick the cherry-pick process off".
   Except...  A user who is not a member of the organization can't add labels
   even to their own PRs and issues.

That's just some of the background that's driving the process and
development of the workflows.

Speaking of workflows...  If you want to see the workflows and
actions we've written so far, check out the asterisk/asterisk-gh-test (the
.github/workflows directory) and asterisk/asterisk-ci-actions repos.   If
you're experienced with GitHub workflows, feedback is appreciated.
-- 
_
-- Bandwidth and Colocation Provided 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] GitHub: Proposed Pull Request Process

[George Joseph]

I think publishing this on the dev list before the wiki will make it easier
for people to read, quote and respond,so here goes...

Since most of you have used GitHub, the first part of this process should
be familiar.   Before we get into it though, you should install the GitHub
CLI (gh).  Most distributions have a package for it.  Although not strictly
required, it'll make life easier.

I'm using "asterisk" as the example but the same applies to the "testsuite"
repo as well.

   1. Fork the asterisk/asterisk repo into your own account.
   2. Clone the forked repo to your local dev environment:
   `gh repo clone you/asterisk`
   The gh tool will automatically create an "upstream" remote that
   points back to asterisk/asterisk as well as the "origin" remote pointing to
   your fork.
   3. Set the default remote repository:
   `gh repo set-default`
   When prompted, select "asterisk/asterisk" which should be the default
   choice.
   4. Checkout a branch, do some work and commit as usual.  I'll use
   "master" as an example.  We've got some additional commit message
   formatting rules that do away with the need to create entries in the
   doc/CHANGES-staging and doc/UPGRADE-staging directories.  More on this
   later.
   5. Create a pull request with:
   `gh pr create --fill --base master`
   Do NOT cherry-pick to any other branches at this time.
   6. When you submit your first pull request, you'll need to open the PR
   in a browser, scroll down to the checks area, click the "details" link for
   the "license/cla" entry and complete a new license agreement.

At this point, things become a bit "special" because of the way GitHub
operates and the fact that we maintain multiple simultaneous release
branches.

Testing:

With Gerrit, when you submit a new review, the unit tests run but the gate
tests don't run until we do a '+2'.  With the new process, we have more
resources at our disposal so we run both the unit and gate tests
immediately.  You'll notice a whole bunch of entries in the PR checks area
for them and you can easily click through to see the details.  Right now,
the output is overly verbose but we'll pare that down over time.

Addressing test failures or review feedback:

I'll cover the actual review process later but if you need to make changes,
the process will be much like it is today (at first).  While Gerrit has a
one-to-one relationship between commit and review, GitHub allows a PR to
contain multiple commits.  For the time being though, we'd like to keep the
one-to-one relationship to keep things simple.  This means making your
changes locally and doing a `git commit --amend` as you do today but then
doing a `git push --force` to update the PR instead of a `git review`.
There's one exception to this rule though.  See below.

Cherry-picking:

This is where things really get "special".  If you've worked with GitHub
you know that, unlike Gerrit, they have no built-in support for
cherry-picking but we've come with a way to automate most of the process:

   1. Once your PR is created, simply add a comment indicating which other
   branches you'd like the PR cherry-picked to.  If the PR was submitted
   against the master branch and you'd like it cherry-picked to the 18 and 20
   branches, you'd add a comment as follows:
   Comment:
   cherry-pick-to: 18
   cherry-pick-to: 20
   2. When you get your first "+1" review, a core team member will add a
   label to the PR that will trigger test cherry-picks to the branches you
   indicated and run the unit and gate tests on each.
   3. If there are no merge conflicts or test failures then when the base
   PR merges, the cherry-picks will automatically merge to their respective
   branches.
   4. If code changes are required for a specific branch, you'll need to
   edit the comment listing the cherry-pick branches and remove the offending
   entry, then submit a completely separate PR for that branch.

The exception to the one-to-one rule:

When you have a series of patches that depend on each other, Gerrit detects
this and only creates new reviews for the new commits and uses the earlier
in-progress reviews as the base for them.  GitHub does things a bit
different depending on how you push up the new work.  If you create a new
commit in the same branch as the first one and do a simple `git push`, the
new commit will be added to the existing PR.  If you instead do a `gh pr
create`, a new PR will be created that has both the new and earlier
commits.  This can make things a bit confusing and we're not quite sure how
to deal with it yet.  Stay tuned.

Comments?  Questions?  Despite everything written above, I think that for
the majority of contributions, the GitHub process will actually be easier
than the current Gerrit process.

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

asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
   

[asterisk-dev] Infrastructure move to GitHub

[George Joseph]

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.  We've been working hard over the past few months getting
familiar with the GitHub ecosystem, writing and re-writing GitHub actions,
working out potential issue, pull request and review processes and now
believe we have enough in place to put a stake in the ground.  So, we're
currently targeting the last weekend in April as the cutover date.  On that
Friday, Jira and Gerrit will go into read-only mode and GitHub will be the
exclusive issue and source code management system.

We know there will be bumps and bruises as we all learn how to work with
the new process just as we know you'll all have valuable feedback.  As a
result, the  process we start with probably won't be the process we end up
with.

Over the next few days, we'll be publishing a lot more information and
documentation about the migration but feel free to fire away with any
questions or concerns you have at any time.

-- 
*George Joseph*
*Asterisk Software Developer*

Email: gjos...@sangoma.com
Website: www.sangoma.com www.asterisk.org
[image: Facebook] <https://www.facebook.com/sangoma> [image: Linkedin]
<https://www.linkedin.com/company/sangoma/> [image: Twitter]
<https://www.twitter.com/sangoma> [image: Youtube]
<https://www.youtube.com/user/SangomaTechnologies/>
-- 
_
-- Bandwidth and Colocation Provided by http://www.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_geolocation wIki is missing the suppress_empty_ca_elements setting

[George Joseph]

On Thu, Sep 29, 2022 at 1:29 PM Dan Cropp  wrote:

> I see there are some code reviews for some res_geolocation wiki changes.
>
>
>
> Just wanted to mention the suppress_empty_ca_elements is missing from the
> profile settings list.
>

Ah.  Good catch.  I've updated the reviews and fixed the wiki itself.

Thanks.


>
>
> Dan
> --
> _
> -- Bandwidth and Colocation Provided 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

[asterisk-dev] The Asterisk 20 branch has been created

[George Joseph]

It's that time of year again...
The Asterisk 20 branch has been cut from the master branch as of 1100 UTC
today.   This makes the 16, 18, 19, 20 and master branches valid for
cherry-picking changes.  Going forward, don't forget 20 when you're given
the OK to cherry-pick reviews.


-- 
George Joseph
Asterisk Software Developer
direct/fax +1 256 428 6012
Check us out at www.sangoma.com and www.asterisk.org
[image: image.png]
-- 
_
-- Bandwidth and Colocation Provided by http://www.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_VERSION_NUM

[George Joseph]

On Mon, Nov 1, 2021 at 1:44 AM Alexander Traud 
wrote:

> Not at runtime but at compile-time, how does the compiler of a module
> detect which version is used? Before Asterisk 11, I included
>  and the preprocessor macro ASTERISK_VERSION_NUM was
> available, see [1]. How do I solve that today?
>
> My workaround, because I build in-tree anyway, I patched its Makefile as
> well: _ASTCFLAGS+=-DASTERISK_VERSION_NUM=$(ASTERISKVERSIONNUM).
>
>
I was thinking about calling build_tools/make_version from configure.ac and
having it exported to autoconfig.h but it could get stale if you did a git
pull on the same branch and didn't re-run ./configure.  The issue I have
with the -DASTERISK_VERSION_NUM is that IDEs won't detect that and will
probably show the code as if it weren't defined.   I think the best way to
do this may be to have configure.ac run make_version but then have the
Makefile also run it and if it's different, just run sed on autoconfig.h to
replace the version.

You'd have to update:
configure.ac
autoconfig.h.in
makeopts.in
Makefile.in

Should be fairly easy though.











> [1] 
>
>
>
> --
> _
> -- Bandwidth and Colocation Provided 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] SIP subscription with expires=0

[George Joseph]

On Mon, Oct 25, 2021 at 1:32 AM Nikša Baldun  wrote:

> According to the RFC, yes:
>
>   In addition to being a request to unsubscribe, a SUBSCRIBE message
>   with "Expires" of 0 also causes a fetch of state; see section
>   3.3.6.
>
> I'll report a bug. Thanks for your reply.
>

Just FYI...  The code snippet quoted is in pubsub_on_rx_subscribe_request()
which only gets called on new dialogs. We do erroneously treat the
expires=0 as a failure when we should send a NOTIFY but not create a
persistent subscription.   We handle expires=0 on *in-dialog* SUBSCRIBE
termination requests correctly in pubsub_on_rx_refresh().


> On 25. 10. 2021. 09:25, Olle E. Johansson wrote:
>
> A subscription with expire:0 should get at least ONE notify, right? I’ve
> just that to check the status without setting up a dialog.
>
> It is not invalid. Report this as a bug.
>
> /O
>
> 25 okt. 2021 kl. 09:22 skrev Nikša Baldun :
>
> Hello,
>
> I see the following in res_pjsip_pubsub.c:
>
> if (expires_header->ivalue == 0) {
> ast_debug(1, "Subscription request from endpoint %s rejected.
> Expiration of 0 is invalid\n",
> ast_sorcery_object_get_id(endpoint));
> pjsip_endpt_respond_stateless(ast_sip_get_pjsip_endpoint(),
> rdata, 400, NULL, NULL, NULL);
> return PJ_TRUE;
> }
>
> However, according to RFC 2365, value 0 is perfectly valid, and should
> have the effect of ending the subscription.
>
>A natural consequence of this scheme is that a SUBSCRIBE with an
>"Expires" of 0 constitutes a request to unsubscribe from an event.
>
>
> Or is my understanding wrong? Is there some other way to unsubscribe?
>
> Best regards,
>
> Nik
> --
> _
> -- Bandwidth and Colocation Provided 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] Opening issues in Jira if you're going to work them

[George Joseph]

On Fri, Sep 3, 2021 at 1:40 PM Rodrigo Ramírez Norambuena <
decipher...@gmail.com> wrote:

>
>
> On Fri, Sep 3, 2021 at 9:28 AM George Joseph  wrote:
>
>>
>>
>> On Fri, Sep 3, 2021 at 7:16 AM George Joseph  wrote:
>>
>>> If you open, or come across, an issue in Jira that you plan to work
>>> yourself, it would help us a lot if you clicked the "Acknowledge" button at
>>> the top of the issue to open it then assign it to yourself.  This helps us
>>> out by removing it from our triage queue.
>>>
>>>
>> Oops.  Josh just pointed out that users might not have permission to do
>> this themselves.  I'm checking.
>>
>>
> Hi!
>
> I can confirm this. The "Acknowledge" button is not appear on this side
>

Yep.  My fault.  We may be able to do this automatically in our Gerrit
hooks.  When a patchset is created we can get the issue id from the commit
message and open it and assign it to the user .  We're investigating.




> --
> Rodrigo Ramírez Norambuena
> http://www.rodrigoramirez.com/
> --
> _
> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
>
> asterisk-dev mailing list
> To UNSUBSCRIBE or update options visit:
>http://lists.digium.com/mailman/listinfo/asterisk-dev
-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

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

Re: [asterisk-dev] Opening issues in Jira if you're going to work them

[George Joseph]

On Fri, Sep 3, 2021 at 7:16 AM George Joseph  wrote:

> If you open, or come across, an issue in Jira that you plan to work
> yourself, it would help us a lot if you clicked the "Acknowledge" button at
> the top of the issue to open it then assign it to yourself.  This helps us
> out by removing it from our triage queue.
>
>
Oops.  Josh just pointed out that users might not have permission to do
this themselves.  I'm checking.



> Thanks!
>
> --
> George Joseph
> Asterisk Software Developer
> direct/fax +1 256 428 6012
> Check us out at www.sangoma.com and www.asterisk.org
> [image: image.png]
>
-- 
_
-- Bandwidth and Colocation Provided 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] Opening issues in Jira if you're going to work them

[George Joseph]

If you open, or come across, an issue in Jira that you plan to work
yourself, it would help us a lot if you clicked the "Acknowledge" button at
the top of the issue to open it then assign it to yourself.  This helps us
out by removing it from our triage queue.

Thanks!

-- 
George Joseph
Asterisk Software Developer
direct/fax +1 256 428 6012
Check us out at www.sangoma.com and www.asterisk.org
[image: image.png]
-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

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

Re: [asterisk-dev] Gerrit ssh host key changed again :(

[George Joseph]

On Thu, Aug 26, 2021 at 8:54 AM George Joseph  wrote:

>
>
> On Thu, Aug 26, 2021 at 8:38 AM Olle E. Johansson  wrote:
>
>>
>>
>> > On 26 Aug 2021, at 16:32, George Joseph  wrote:
>> >
>> > During the upgrade of Gerrit today, it decided to regenerate its ssh
>> host key again,  The good news is that Jira issues will now list the active
>> reviews associated with an issue again.  The bad news is that 'gerrit
>> review' and other ssh git actions will complain about the key changing
>> again.  Sorry about that.   Just delete the old key from ~/.ssh/known_hosts
>> and let ssh re-add the new one.
>> >
>> And how should we trust the new one? George, please make sure that the
>> key fingerprint is available
>> on the wiki or somewhere where it can be validated properly. Encouraging
>> blind trust is not a good thing.
>>
>
> Oops, I meant to do that this time and forgot.  Sorry about that.  Give me
> a few minutes and I'll add it to the wiki and send out a link.
>

The new ssh host key fingreprint can be viewed at
https://wiki.asterisk.org/wiki/display/AST/Gerrit+Usage





>
>
>>
>> Cheers
>> /O
>> --
>> _
>> -- Bandwidth and Colocation Provided 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] Gerrit ssh host key changed again :(

[George Joseph]

On Thu, Aug 26, 2021 at 8:38 AM Olle E. Johansson  wrote:

>
>
> > On 26 Aug 2021, at 16:32, George Joseph  wrote:
> >
> > During the upgrade of Gerrit today, it decided to regenerate its ssh
> host key again,  The good news is that Jira issues will now list the active
> reviews associated with an issue again.  The bad news is that 'gerrit
> review' and other ssh git actions will complain about the key changing
> again.  Sorry about that.   Just delete the old key from ~/.ssh/known_hosts
> and let ssh re-add the new one.
> >
> And how should we trust the new one? George, please make sure that the key
> fingerprint is available
> on the wiki or somewhere where it can be validated properly. Encouraging
> blind trust is not a good thing.
>

Oops, I meant to do that this time and forgot.  Sorry about that.  Give me
a few minutes and I'll add it to the wiki and send out a link.


>
> Cheers
> /O
> --
> _
> -- Bandwidth and Colocation Provided 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

[asterisk-dev] Gerrit ssh host key changed again :(

[George Joseph]

During the upgrade of Gerrit today, it decided to regenerate its ssh host
key again,  The good news is that Jira issues will now list the active
reviews associated with an issue again.  The bad news is that 'gerrit
review' and other ssh git actions will complain about the key changing
again.  Sorry about that.   Just delete the old key from ~/.ssh/known_hosts
and let ssh re-add the new one.

I'm going to open an issue against Gerrit itself asking that they NOT
automatically regenerate host keys every time there;s a config change.

-- 
George Joseph
Asterisk Software Developer
direct/fax +1 256 428 6012
Check us out at www.sangoma.com and www.asterisk.org
[image: image.png]
-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

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

Re: [asterisk-dev] Detecting B-leg channels

[George Joseph]

On Tue, Aug 24, 2021 at 1:27 PM Nikša Baldun  wrote:

> The thing is, when attended transfer happens, Asterisk connects previously
> unrelated channels without going to the dialplan. I keep a number of
> variables which help me track call state on both channels, and their values
> become obsolete on attended transfer, as channels are now in a completely
> new call. My idea was to gosub both sides to a dialplan context so I can
> refresh call state variables. But that has proven difficult if one of the
> calls is not answered. I am certain this can't be solved by straight
> dialplan, not without modifying Asterisk code. I haven't delved into ARI
> yet. I'd rather avoid it, unless it is the only option.
>
I'm not sure this would work for you but ...  Have app_dial create a
channel variable on the incoming channel that has the list of channels
being dialed.

You  could also use the DB functions to store key value pairs and have
pre-dial-handlers on the outgoing channels store their IDs there keyed by
the incoming channel.




> On 24. 08. 2021. 20:51, Kevin Harwell wrote:
>
> What's the overall scenario you are trying to solve? Perhaps there is
> another way to do what you want to do without even modifying Asterisk code?
> For example, maybe this is something an ARI application could handle, or
> even straight dialplan using a combination of app_dial, pre-dial handlers,
> and such.
>
> On Mon, Aug 23, 2021 at 5:29 AM Nikša Baldun  wrote:
>
>> Hello,
>>
>> I am trying to modify bridge.c (function ast_bridge_transfer_attended)
>> in order to send channels involved in SIP attended transfer to the
>> dialplan. If both transferee and transfer target are bridged, that is
>> relatively easy. However, if transfer target is ringing, I don't know
>> how to find B-leg channels (there could be multiple, I suppose). So the
>> question is, having a reference to A-leg channel, how to obtain a list
>> of B-leg channels?
>>
>> Best regards,
>>
>>
>> --
>> _
>> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
>>
>> asterisk-dev mailing list
>> To UNSUBSCRIBE or update options visit:
>>http://lists.digium.com/mailman/listinfo/asterisk-dev
>
>
> --
> _
> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
>
> asterisk-dev mailing list
> To UNSUBSCRIBE or update options visit:
>http://lists.digium.com/mailman/listinfo/asterisk-dev
-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

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

Re: [asterisk-dev] Detecting B-leg channels

[George Joseph]

On Tue, Aug 24, 2021 at 12:20 PM Nikša Baldun  wrote:

> I have checked it, and that led me to bridge.c. Perhaps I wasn't clear
> enough. These are the channels involved in attended transfer:
>
> (transferee) <> (transferer1) (transferer2) <> (transfer target)
>
> Transferee and transfer target are not readily available in
> res_pjsip_refer.c, but I can get them in bridge.c, as long as both calls
> are bridged. But transfer target may be in ringing state, and in that case
> there is no bridge whose members I can check. Also, there could be multiple
> ringing channels. So in that case, I need a way to get all ringing channels
> which belong to transferrer2 channel. I was wondering if there is an
> existing method for that, or do I have to devise my own.
>
The only idea which comes to mind is to iterate over all channels in the
> system and compare their LinkedId to transferer2 UniqueId.
>
Please don't do that. :)

So, Alice (transferee) is on an existing call (channel transferer1), she
transfers to Bob (transfer target), Asterisk sets up channel transferer2 to
call Bob and Bob is ringing but hasn't answered yet.  Right?   Optionally,
Alice transfers to a "ring group" which causes Asterisk to create multiple
outbound channels, correct?The only place I can think of that knows
about this is app_dial.



> On 24. 08. 2021. 19:38, George Joseph wrote:
>
>
>
> On Tue, Aug 24, 2021 at 11:22 AM Nikša Baldun  wrote:
>
>> Hello,
>>
>> I am using chan_pjsip.
>>
> Check res_pjsip_refer.c  you may be able to intercept both channels there.
>
>
>
>> On 24. 08. 2021. 18:55, George Joseph wrote:
>>
>>
>>
>> On Mon, Aug 23, 2021 at 4:29 AM Nikša Baldun  wrote:
>>
>>> Hello,
>>>
>>> I am trying to modify bridge.c (function ast_bridge_transfer_attended)
>>> in order to send channels involved in SIP attended transfer to the
>>> dialplan. If both transferee and transfer target are bridged, that is
>>> relatively easy. However, if transfer target is ringing, I don't know
>>> how to find B-leg channels (there could be multiple, I suppose). So the
>>> question is, having a reference to A-leg channel, how to obtain a list
>>> of B-leg channels?
>>>
>>> Best regards,
>>>
>>>
>> Which channel driver are you using?
>>
>>
>>
>>>
>>> --
>>> _
>>> -- Bandwidth and Colocation Provided 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
-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

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

Re: [asterisk-dev] Detecting B-leg channels

[George Joseph]

On Tue, Aug 24, 2021 at 11:22 AM Nikša Baldun  wrote:

> Hello,
>
> I am using chan_pjsip.
>
Check res_pjsip_refer.c  you may be able to intercept both channels there.



> On 24. 08. 2021. 18:55, George Joseph wrote:
>
>
>
> On Mon, Aug 23, 2021 at 4:29 AM Nikša Baldun  wrote:
>
>> Hello,
>>
>> I am trying to modify bridge.c (function ast_bridge_transfer_attended)
>> in order to send channels involved in SIP attended transfer to the
>> dialplan. If both transferee and transfer target are bridged, that is
>> relatively easy. However, if transfer target is ringing, I don't know
>> how to find B-leg channels (there could be multiple, I suppose). So the
>> question is, having a reference to A-leg channel, how to obtain a list
>> of B-leg channels?
>>
>> Best regards,
>>
>>
> Which channel driver are you using?
>
>
>
>>
>> --
>> _
>> -- Bandwidth and Colocation Provided 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] Detecting B-leg channels

[George Joseph]

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

> Hello,
>
> I am trying to modify bridge.c (function ast_bridge_transfer_attended)
> in order to send channels involved in SIP attended transfer to the
> dialplan. If both transferee and transfer target are bridged, that is
> relatively easy. However, if transfer target is ringing, I don't know
> how to find B-leg channels (there could be multiple, I suppose). So the
> question is, having a reference to A-leg channel, how to obtain a list
> of B-leg channels?
>
> Best regards,
>
>
Which channel driver are you using?



>
> --
> _
> -- Bandwidth and Colocation Provided 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

[asterisk-dev] Gerrit Commit Message Line Length

[George Joseph]

Gerrit's commit message line length validator has been changed to only
allow 72 characters per line where previously it was 80.  Most reviews
have been <= 72 characters anyway but every once in a while we get a review
with longer lines and they wrap in the Gerrit commit message widget.


-- 
George Joseph
Asterisk Software Developer
direct/fax +1 256 428 6012
Check us out at www.sangoma.com and www.asterisk.org
[image: image.png]
-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

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

Re: [asterisk-dev] Stir Shaken

[George Joseph]

On Thu, Jun 24, 2021 at 10:55 AM Jared Smith 
wrote:

> On Thu, Jun 24, 2021 at 4:04 AM John T. Bittner  wrote:
>
>> As a voip provider we are in the process of getting our own token and
>> cert.
>>
>> We got our OCN and did all the other FCC requirements.
>>
>> We are at the point of working with iconectiv to get our token.
>>
>> Based on the info we have after we get the token we go to neustar to get
>> our cert.
>>
>
> That all seems correct.
>
>
>>
>>
>> Iconectiv are asking a lot of questions on how we are going to get certs
>> out of there api’s ? This is confusing me, I was under impression that we
>> get the cert from neustar.
>>
>
> iConectiv is the Policy Administrator -- they don't give you the actual
> cert, but they do certify that you've got your OCN and are authorized to
> get a cert, etc.  Neustar is one of the Certificate Authorities that is
> authorized to give out Stir/Shaken certs.
>
>
>> I have spent hours reading many things about stir shaken and a lot of it
>> is contradicting. I also can’t find anything on the asterisk setup were we
>> would even configure api information to connect to iconectiv.
>>
>
> You don't do this from within Asterisk -- you'd have to do this outside of
> Asterisk, and the configure Asterisk for the cert that you get from Neustar.
>
>
>> Our SBC’s are asterisk based so we would like to implement this directly
>> on these servers.
>>
>>
>>
>> Do I need middleman software to get this to work.
>>
>
> Yes -- Asterisk doesn't handle this directly, at least at this point.
> Please be aware that you'll likely need to interact with the APIs from both
> the PA and the CA (iConectiv and Neustar, in your case).
>
>
>>
>> Last question…  We do a lot of call forwarding and passthrough caller id.
>>
>> Is there any method to allow this with Stir Shaken ?
>>
>
> You can -- but it's complicated, depending on your relationship with the
> customers and numbers you're forwarding.  The major point of Stir/Shaken is
> that the recipient of a call can know that the caller ID on the call
> actually belongs to someone authorized to use that number.  If you as a
> middleman know that the number presented belongs to your customer, then you
> can give them an "A" level attestation.  If you know the customer but not
> that they're authorized to use that particular number, you can give the
> calls a "B" level attestation.  If you don't know the customer or the
> number, you give them a "C" level attestation.
>

Now let's say that I own DID 8885551212 and my upstream provider send a
call to me for that DID from "someuser" at 7775551212 with a valid A level
attestation.  I need to forward (not route) that call back to an upstream
provider (maybe not the same one), say to a cell phone.  I want the caller
ID to be that of the original caller.  What do I do?


>
> --
> Jared Smith
> --
> _
> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
>
> asterisk-dev mailing list
> To UNSUBSCRIBE or update options visit:
>http://lists.digium.com/mailman/listinfo/asterisk-dev
-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

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

Re: [asterisk-dev] Stir Shaken

[George Joseph]

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

> Hello All,
>
>
>
> As a voip provider we are in the process of getting our own token and cert.
>
> We got our OCN and did all the other FCC requirements.
>
> We are at the point of working with iconectiv to get our token.
>
> Based on the info we have after we get the token we go to neustar to get
> our cert.
>
>
>
> Iconectiv are asking a lot of questions on how we are going to get certs
> out of there api’s ? This is confusing me, I was under impression that we
> get the cert from neustar.
>
> I have spent hours reading many things about stir shaken and a lot of it
> is contradicting. I also can’t find anything on the asterisk setup were we
> would even configure api information to connect to iconectiv.
>
> Our SBC’s are asterisk based so we would like to implement this directly
> on these servers.
>

>
> Do I need middleman software to get this to work.
>

It's hard to tell.  With only a first glance at iconectiv's web pages, it
doesn't look like they're involved on a call-by-call basis so I'm not sure
what APIs they're talking about.  Can you point us to any specific
documentation?


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

It's funny but only yesterday we were complaining to each other internally
about support for this being not well defined.  The incoming Identity
header contains the destination telephone number so you can't just forward
that header on to another destination so we're not sure what to do.  We'll
be having more discussions about this in the future I'm sure.


>
> In the past we were told we cannot do this anymore but I read that they
> changed some rules to allow this but the article didn’t go into detail on
> how.
>

Do you have a link?


> In the interim we have a workaround via android and ios apps that will
> send notification of the passthrough callerid info before there phone rings.
>

Yeah that works when you have control over the destination user agent.  I'm
not sure what we're going to do in the other case.


>
>
> Any help with this is much appreciated and if anyone wants to do some
> consulting work please contact me off this list at j...@xaccel.net
>
>
>
> Thanks
>
>
>
> John Bittner
>
> CTO
>
> [image: cid:image001.png@01D0B33B.24285610]
>
> 380 US Highway 46, Suite 500
>
> Totowa, NJ 07512
>
> Phone: 201.806.2602 x2405
>
> Fax:   201.806.2604
>
> Cell:   973.390.1090
>
> www.xaccel.net
>
>
>
>
>
>
> *CONFIDENTIALITY NOTICE: This e-mail message, including any attachments,
> is for the sole use of the intended recipient(s) and may contain
> confidential and privileged information which should not be shared or
> forwarded. Any unauthorized review, use, disclosure or distribution is
> prohibited. If you are not the intended recipient, please contact the
> sender by reply e-mail and destroy all copies of the e-mail.*
>
>
> --
> _
> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
>
> asterisk-dev mailing list
> To UNSUBSCRIBE or update options visit:
>http://lists.digium.com/mailman/listinfo/asterisk-dev
-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

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

Re: [asterisk-dev] Asterisk crash

[George Joseph]

On Tue, Jun 15, 2021 at 7:44 AM George Joseph  wrote:

>
>
> On Mon, Jun 14, 2021 at 1:16 PM Dan Cropp  wrote:
>
>> I think you are onto something with the system time being slewed
>> backwards.
>>
>> Logs showed this happened at the same time things went down
>>
>>
>>
>> systemd-timesyncd[684]: Synchronized to time server …..
>>
>
> We have a winner!!
>
>
>>
>>
>>
>>
>> I’m looking at the coredump from my own box (same executable, just
>> different box).
>>
>> Here is the output from the coredump you asked for.
>>
>>
>>
>> If it needs to be on the customer box, let me know.  Pretty sure I can
>> have someone with permissions access the box and do the same work I did.
>>
>
> As long as the binaries and distro are the same, examining a coredump on a
> different box is fine.  We do it all the time.
>
>
>>
>>
>> (gdb) frame 6
>>
>> #6  0x5588eef3a392 in hook_event_cb (chan=,
>> frame=, event=, data=0x7f017411f4e0) at
>> abstract_jb.c:1127
>>
>> 1127abstract_jb.c: No such file or directory.
>>
>> (gdb) p now
>>
>> $1 = 18446744073709550143
>>
>
> Yeah that's -1473.
>
> Could you open an ASTERISK issue for this?  Something like "Negative time
> differences causes an abort in fixedjitterbuffer.c".
> We should just pass through any frame with a negative interval and remove
> that ASSERT statement.
>

I opened ASTERISK-29480
<https://issues.asterisk.org/jira/browse/ASTERISK-29480> for you.


>
>
>
>> (gdb) p now_tv
>>
>> $2 = 
>>
>> (gdb) p *framedata
>>
>> $3 = {jb_impl = 0x5588ef40b3e0 , jb_conf = {flags = 0,
>> max_size = 200, resync_threshold = 1000, impl = "fixed\000\000\000䚗@",
>> target_extra = 40}, start_tv = {tv_sec = 1623549920, tv_usec = 123464},
>> last_format = 0x0,
>>
>>   timer = 0x7f0174150fc0, timer_interval = 20, timer_fd = 379, first = 0,
>> audio_stream_id = -1, audio_stream_sync = {timestamp = 0, ntp = {tv_sec =
>> 0, tv_usec = 0}}, video_stream_id = -1, video_stream_sync = {timestamp = 0,
>> ntp = {
>>
>>   tv_sec = 0, tv_usec = 0}}, early_frames = {first = 0x0, last =
>> 0x0}, early_frame_count = 0, last_audio_ntp_timestamp = {tv_sec = 0,
>> tv_usec = 0}, audio_flowing = 0, jb_obj = 0x7f01741b1990}
>>
>>
>>
>> Dan
>>
>>
>>
>> *From:* asterisk-dev  *On Behalf
>> Of *George Joseph
>> *Sent:* Monday, June 14, 2021 1:58 PM
>> *To:* Asterisk Developers Mailing List 
>> *Subject:* Re: [asterisk-dev] Asterisk crash
>>
>>
>>
>> That's pretty weird.   The ASSERT in frame 4 makes sure that the time
>> difference between the frame's timestamp and the current time is positive
>> so a negative value will cause the assert.   Actually, I think there's a
>> bug there.  Most asserts in Asterisk are enabled only when it's built with
>> --enable-dev-mode.  This assert seems to trigger even without
>> --enable-dev-mode.
>>
>>
>>
>> Anyway, if you still have the actual coredump, it'd be interesting to do
>> the following in gdb...
>>
>>
>>
>> gdb> frame 6
>>
>> gdb> p now
>>
>> gdb> p now_tv
>>
>> gdb> p *framedata
>>
>>
>>
>> I'm wondering if the system time is being slewed backwards by ntpd,
>> chronyd, systemd-timesyncd, etc.
>>
>>
>>
>>
>>
>> On Mon, Jun 14, 2021 at 10:49 AM Dan Cropp  wrote:
>>
>> We have a customer with asterisk 16.17.0 installed.  Every once in a
>> while, we have been seeing a crash.  We have upgraded the version a couple
>> times, but this random crashing issue has been going on for some time.
>>
>>
>>
>> Over the weekend, it happened again.  This time, I have a .crash file
>> from it.
>>
>> Put it through apport-unpack and think I have a good CoreDump from it.
>>
>> Running asterisk 16.17.0 here is what the gdb backtrace is showing.
>>
>>
>>
>> Program terminated with signal SIGABRT, Aborted.
>>
>> #0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51
>>
>> 51  ../sysdeps/unix/sysv/linux/raise.c: No such file or directory.
>>
>> [Current thread is 1 (Thread 0x7f014097d700 (LWP 20262))]
>>
>> (gdb) bt
>>
>> #0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51
>>
>> #1  0x7f027877a921 in __GI_abort () at abort.c:79
>>
>> #2 

Re: [asterisk-dev] PJSIP messaging : specifying the user portion of the request-URI

[George Joseph]

On Wed, Jun 16, 2021 at 6:27 AM George Joseph  wrote:

>
>
> On Wed, Jun 16, 2021 at 12:50 AM Jean Aunis  wrote:
>
>> Le 15/06/2021 à 15:28, George Joseph a écrit :
>>
>> [2021-06-15 10:42:49.885] WARNING[5163]: res_pjsip_messaging.c:247
>>
>>> insert_user_in_contact_uri: Dest: 'PJSIP/3200@linphone' MSG SEND FAIL:
>>> There's already a username in endpoint linphone's contact URI
>>> 'sip:linphone@127.0.0.1:5063;line=068b0910396d2ed'.
>>> [2021-06-15 10:42:49.885] ERROR[5163]: res_pjsip_messaging.c:1240
>>
>>
>>
>> Yeah that's the expected behavior although I guess I can change it.  I
>> figured that if there was a user already specified in the contact uri that
>> overwriting it with something else was probably not a good idea.Now
>> that I think of it though, I was thinking more from sending messages
>> upstream to a provider not downstream to a client.
>>
>> So what should the behavior be?  To construct the Request URI replace any
>> user in the contact URI with the user or number specified in the
>> MessageSend call?
>>
>> I would be in favour of trusting the dialplan. If someone wants to send a
>> message to an endpoint with a specific number, that should be possible.
>> That looks more flexible to me.
>>
> I should have a patch up for that in a few hours.
>


Changes up in gerrit...

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



>
>
>> By the way, I'm fine with the modification of MessageSend you describe.
>> What about applying the same modification to the MessageSend AMI action and
>> to the sendMessage / sendMessageToEndpoint requests in ARI ?
>>
> The Message related AMI and ARI stuff call the same core functions so
> they automatically support the "PJSIP/" form of the destination as well as
> the refactored parsing code for the rest of the destination forms.   Adding
> the third "to" parameter that was added to the dialplan app is a little
> more problematic for AMI and ARI.  Dialplan apps don't have named
> parameters so adding the third one was no problem.  Both the AMI and ARI
> calls have named parameters and the first one is already named "to" so
> renaming that one to "destination" and adding "to" would break the contract
> in Asterisk 16 and 18.   I can, and will, make that change for For Asterisk
> 19 however,
>
>
>> --
>> _
>> -- Bandwidth and Colocation Provided 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] PJSIP messaging : specifying the user portion of the request-URI

[George Joseph]

On Wed, Jun 16, 2021 at 12:50 AM Jean Aunis  wrote:

> Le 15/06/2021 à 15:28, George Joseph a écrit :
>
> [2021-06-15 10:42:49.885] WARNING[5163]: res_pjsip_messaging.c:247
>
>> insert_user_in_contact_uri: Dest: 'PJSIP/3200@linphone' MSG SEND FAIL:
>> There's already a username in endpoint linphone's contact URI
>> 'sip:linphone@127.0.0.1:5063;line=068b0910396d2ed'.
>> [2021-06-15 10:42:49.885] ERROR[5163]: res_pjsip_messaging.c:1240
>
>
>
> Yeah that's the expected behavior although I guess I can change it.  I
> figured that if there was a user already specified in the contact uri that
> overwriting it with something else was probably not a good idea.Now
> that I think of it though, I was thinking more from sending messages
> upstream to a provider not downstream to a client.
>
> So what should the behavior be?  To construct the Request URI replace any
> user in the contact URI with the user or number specified in the
> MessageSend call?
>
> I would be in favour of trusting the dialplan. If someone wants to send a
> message to an endpoint with a specific number, that should be possible.
> That looks more flexible to me.
>
I should have a patch up for that in a few hours.


> By the way, I'm fine with the modification of MessageSend you describe.
> What about applying the same modification to the MessageSend AMI action and
> to the sendMessage / sendMessageToEndpoint requests in ARI ?
>
The Message related AMI and ARI stuff call the same core functions so
they automatically support the "PJSIP/" form of the destination as well as
the refactored parsing code for the rest of the destination forms.   Adding
the third "to" parameter that was added to the dialplan app is a little
more problematic for AMI and ARI.  Dialplan apps don't have named
parameters so adding the third one was no problem.  Both the AMI and ARI
calls have named parameters and the first one is already named "to" so
renaming that one to "destination" and adding "to" would break the contract
in Asterisk 16 and 18.   I can, and will, make that change for For Asterisk
19 however,


> --
> _
> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
>
> asterisk-dev mailing list
> To UNSUBSCRIBE or update options visit:
>http://lists.digium.com/mailman/listinfo/asterisk-dev
-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

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

Re: [asterisk-dev] Asterisk crash

[George Joseph]

On Mon, Jun 14, 2021 at 1:16 PM Dan Cropp  wrote:

> I think you are onto something with the system time being slewed backwards.
>
> Logs showed this happened at the same time things went down
>
>
>
> systemd-timesyncd[684]: Synchronized to time server …..
>

We have a winner!!


>
>
>
>
> I’m looking at the coredump from my own box (same executable, just
> different box).
>
> Here is the output from the coredump you asked for.
>
>
>
> If it needs to be on the customer box, let me know.  Pretty sure I can
> have someone with permissions access the box and do the same work I did.
>

As long as the binaries and distro are the same, examining a coredump on a
different box is fine.  We do it all the time.


>
>
> (gdb) frame 6
>
> #6  0x5588eef3a392 in hook_event_cb (chan=,
> frame=, event=, data=0x7f017411f4e0) at
> abstract_jb.c:1127
>
> 1127abstract_jb.c: No such file or directory.
>
> (gdb) p now
>
> $1 = 18446744073709550143
>

Yeah that's -1473.

Could you open an ASTERISK issue for this?  Something like "Negative time
differences causes an abort in fixedjitterbuffer.c".
We should just pass through any frame with a negative interval and remove
that ASSERT statement.



> (gdb) p now_tv
>
> $2 = 
>
> (gdb) p *framedata
>
> $3 = {jb_impl = 0x5588ef40b3e0 , jb_conf = {flags = 0,
> max_size = 200, resync_threshold = 1000, impl = "fixed\000\000\000䚗@",
> target_extra = 40}, start_tv = {tv_sec = 1623549920, tv_usec = 123464},
> last_format = 0x0,
>
>   timer = 0x7f0174150fc0, timer_interval = 20, timer_fd = 379, first = 0,
> audio_stream_id = -1, audio_stream_sync = {timestamp = 0, ntp = {tv_sec =
> 0, tv_usec = 0}}, video_stream_id = -1, video_stream_sync = {timestamp = 0,
> ntp = {
>
>   tv_sec = 0, tv_usec = 0}}, early_frames = {first = 0x0, last = 0x0},
> early_frame_count = 0, last_audio_ntp_timestamp = {tv_sec = 0, tv_usec =
> 0}, audio_flowing = 0, jb_obj = 0x7f01741b1990}
>
>
>
> Dan
>
>
>
> *From:* asterisk-dev  *On Behalf
> Of *George Joseph
> *Sent:* Monday, June 14, 2021 1:58 PM
> *To:* Asterisk Developers Mailing List 
> *Subject:* Re: [asterisk-dev] Asterisk crash
>
>
>
> That's pretty weird.   The ASSERT in frame 4 makes sure that the time
> difference between the frame's timestamp and the current time is positive
> so a negative value will cause the assert.   Actually, I think there's a
> bug there.  Most asserts in Asterisk are enabled only when it's built with
> --enable-dev-mode.  This assert seems to trigger even without
> --enable-dev-mode.
>
>
>
> Anyway, if you still have the actual coredump, it'd be interesting to do
> the following in gdb...
>
>
>
> gdb> frame 6
>
> gdb> p now
>
> gdb> p now_tv
>
> gdb> p *framedata
>
>
>
> I'm wondering if the system time is being slewed backwards by ntpd,
> chronyd, systemd-timesyncd, etc.
>
>
>
>
>
> On Mon, Jun 14, 2021 at 10:49 AM Dan Cropp  wrote:
>
> We have a customer with asterisk 16.17.0 installed.  Every once in a
> while, we have been seeing a crash.  We have upgraded the version a couple
> times, but this random crashing issue has been going on for some time.
>
>
>
> Over the weekend, it happened again.  This time, I have a .crash file from
> it.
>
> Put it through apport-unpack and think I have a good CoreDump from it.
>
> Running asterisk 16.17.0 here is what the gdb backtrace is showing.
>
>
>
> Program terminated with signal SIGABRT, Aborted.
>
> #0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51
>
> 51  ../sysdeps/unix/sysv/linux/raise.c: No such file or directory.
>
> [Current thread is 1 (Thread 0x7f014097d700 (LWP 20262))]
>
> (gdb) bt
>
> #0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51
>
> #1  0x7f027877a921 in __GI_abort () at abort.c:79
>
> #2  0x7f027876a48a in __assert_fail_base (fmt=0x7f02788f1750
> "%s%s%s:%u: %s%sAssertion `%s' failed.\n%n", 
> assertion=assertion@entry=0x5588ef1864a9
> "now >= 0",
>
> file=file@entry=0x5588ef18645a "fixedjitterbuf.c", line=line@entry=293,
> function=function@entry=0x5588ef1864f8 <__PRETTY_FUNCTION__.9166>
> "fixed_jb_get")
>
> at assert.c:92
>
> #3  0x7f027876a502 in __GI___assert_fail 
> (assertion=assertion@entry=0x5588ef1864a9
> "now >= 0", file=file@entry=0x5588ef18645a "fixedjitterbuf.c",
>
> line=line@entry=293, function=function@entry=0x5588ef1864f8
> <__PRETTY_FUNCTION__.9166> "fixed_jb_get") at assert.c:101
>
>

Re: [asterisk-dev] PJSIP messaging : specifying the user portion of the request-URI

[George Joseph]

On Tue, Jun 15, 2021 at 2:49 AM Jean Aunis  wrote:

> Le 09/06/2021 à 16:18, George Joseph a écrit :
> > Hi Guys,
> >
> > The change for allowing a dialstring-like destination in MessageSend
> > (pjsip only) is now committed in the 16, 18 and master branches.  You
> > can now use MessageSend(pjsip:PJSIP/@) and
> > the request URI will be composed of the endpoint's contact uri with
> > the number inserted as the user portion of the uri. Please give it a
> test.
> >
> > For Asterisk 19 (not an LTS release) what would you guys think of
> > changing the MessageSend application to accept discrete parameters for
> > destination uri, endpoint, user, etc.?  This would remove about 400
> > lines of fuzzy parsing code and give you the most flexibility in
> > constructing a destination.
>
> Hi George,
>
> I've just tested this with the latest version on branch 16.
>
> I have a SIP phone "linphone" performing an inbound registration, and I
> try to send a message to it with the following dialplan:
>
> exten = 800,1,Set(MESSAGE(body)=test)
> same  = n,MessageSend(pjsip:PJSIP/3200@linphone,8000)
>
> The test fails. The SIP MESSAGE is not sent and the following errors are
> displayed:
>
> *CLI> channel originate Local/800@default application Hangup
> *CLI> -- Executing [800@default:1]
> Set("Local/800@default-;2", "MESSAGE(body)=test") in new stack
>  -- Called 800@default
>  -- Executing [800@default:2]
> MessageSend("Local/800@default-;2",
> "pjsip:PJSIP/3200@linphone,8000") in new stack
> [2021-06-15 10:42:49.885] WARNING[5163]: res_pjsip_messaging.c:247
> insert_user_in_contact_uri: Dest: 'PJSIP/3200@linphone' MSG SEND FAIL:
> There's already a username in endpoint linphone's contact URI
> 'sip:linphone@127.0.0.1:5063;line=068b0910396d2ed'.
> [2021-06-15 10:42:49.885] ERROR[5163]: res_pjsip_messaging.c:1240



Yeah that's the expected behavior although I guess I can change it.  I
figured that if there was a user already specified in the contact uri that
overwriting it with something else was probably not a good idea.Now
that I think of it though, I was thinking more from sending messages
upstream to a provider not downstream to a client.

So what should the behavior be?  To construct the Request URI replace any
user in the contact URI with the user or number specified in the
MessageSend call?



>
> msg_send: PJSIP MESSAGE - Could not find endpoint 'PJSIP/3200@linphone'
> and no default outbound endpoint configured
>  -- Auto fallthrough, channel 'Local/800@default-;2' status
> is 'UNKNOWN'
>
> I can provide logs if you need.
>
> Regards,
>
> Jean
>
>
>
>
> --
> _
> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
>
> asterisk-dev mailing list
> To UNSUBSCRIBE or update options visit:
>http://lists.digium.com/mailman/listinfo/asterisk-dev
-- 
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --

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

Re: [asterisk-dev] Asterisk crash

[George Joseph]

That's pretty weird.   The ASSERT in frame 4 makes sure that the time
difference between the frame's timestamp and the current time is positive
so a negative value will cause the assert.   Actually, I think there's a
bug there.  Most asserts in Asterisk are enabled only when it's built with
--enable-dev-mode.  This assert seems to trigger even without
--enable-dev-mode.

Anyway, if you still have the actual coredump, it'd be interesting to do
the following in gdb...

gdb> frame 6
gdb> p now
gdb> p now_tv
gdb> p *framedata

I'm wondering if the system time is being slewed backwards by ntpd,
chronyd, systemd-timesyncd, etc.


On Mon, Jun 14, 2021 at 10:49 AM Dan Cropp  wrote:

> We have a customer with asterisk 16.17.0 installed.  Every once in a
> while, we have been seeing a crash.  We have upgraded the version a couple
> times, but this random crashing issue has been going on for some time.
>
>
>
> Over the weekend, it happened again.  This time, I have a .crash file from
> it.
>
> Put it through apport-unpack and think I have a good CoreDump from it.
>
> Running asterisk 16.17.0 here is what the gdb backtrace is showing.
>
>
>
> Program terminated with signal SIGABRT, Aborted.
>
> #0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51
>
> 51  ../sysdeps/unix/sysv/linux/raise.c: No such file or directory.
>
> [Current thread is 1 (Thread 0x7f014097d700 (LWP 20262))]
>
> (gdb) bt
>
> #0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:51
>
> #1  0x7f027877a921 in __GI_abort () at abort.c:79
>
> #2  0x7f027876a48a in __assert_fail_base (fmt=0x7f02788f1750
> "%s%s%s:%u: %s%sAssertion `%s' failed.\n%n", 
> assertion=assertion@entry=0x5588ef1864a9
> "now >= 0",
>
> file=file@entry=0x5588ef18645a "fixedjitterbuf.c", line=line@entry=293,
> function=function@entry=0x5588ef1864f8 <__PRETTY_FUNCTION__.9166>
> "fixed_jb_get")
>
> at assert.c:92
>
> #3  0x7f027876a502 in __GI___assert_fail 
> (assertion=assertion@entry=0x5588ef1864a9
> "now >= 0", file=file@entry=0x5588ef18645a "fixedjitterbuf.c",
>
> line=line@entry=293, function=function@entry=0x5588ef1864f8
> <__PRETTY_FUNCTION__.9166> "fixed_jb_get") at assert.c:101
>
> #4  0x5588eeffe999 in fixed_jb_get (jb=,
> frame=frame@entry=0x7f01409785c0, now=, interpl= out>) at fixedjitterbuf.c:293
>
> #5  0x5588eef39ee2 in jb_get_fixed (jb=,
> fout=0x7f0140978628, now=, interpl=) at
> abstract_jb.c:675
>
> #6  0x5588eef3a392 in hook_event_cb (chan=,
> frame=, event=, data=0x7f017411f4e0) at
> abstract_jb.c:1127
>
> #7  0x5588ef008935 in framehook_list_push_event
> (framehooks=0x7f01741bca40, frame=frame@entry=0x5588ef416aa0
> ,
>
> event=event@entry=AST_FRAMEHOOK_EVENT_READ) at framehook.c:116
>
> #8  0x5588ef009177 in ast_framehook_list_read_event
> (framehooks=, frame=frame@entry=0x5588ef416aa0
> ) at framehook.c:320
>
> #9  0x5588eefbb1b1 in __ast_read (chan=chan@entry=0x7f016c1abf30,
> dropaudio=dropaudio@entry=0, dropnondefault=dropnondefault@entry=1) at
> channel.c:3779
>
> #10 0x5588eefbd40c in ast_read (chan=chan@entry=0x7f016c1abf30) at
> channel.c:4285
>
> #11 0x7f01cbf77b9c in async_agi_read_frame (chan=0x7f016c1abf30) at
> res_agi.c:1763
>
> #12 launch_asyncagi (efd=0x0, argv=0x7f0140978ae8, argc=,
> chan=0x7f016c1abf30) at res_agi.c:1960
>
> #13 launch_script (opid=, efd=0x0, fds=0x7f0140978a30,
> argv=0x7f0140978ae8, argc=, script=,
> chan=0x7f016c1abf30)
>
> at res_agi.c:2213
>
> #14 agi_exec_full (chan=0x7f016c1abf30, data=,
> enhanced=, dead=0) at res_agi.c:4521
>
> #15 0x5588ef04bf92 in pbx_exec (c=c@entry=0x7f016c1abf30,
> app=app@entry=0x5588efbed4b0, data=data@entry=0x7f014097ac00 "agi:async")
> at pbx_app.c:492
>
> #16 0x5588ef03d062 in pbx_extension_helper (c=c@entry=0x7f016c1abf30,
> context=0x7f016c1ac8f0 "IS", exten=exten@entry=0x7f016c1ac940 "1234",
>
> priority=priority@entry=15, label=label@entry=0x0,
> callerid=callerid@entry=0x0, action=E_SPAWN, found=0x7f014097ccac,
> combined_find_spawn=1, con=0x0) at pbx.c:2947
>
> #17 0x5588ef041143 in ast_spawn_extension (combined_find_spawn=1,
> found=0x7f014097ccac, callerid=0x0, priority=15, exten=0x7f016c1ac940
> "1234",
>
> context=, c=0x7f016c1abf30) at pbx.c:4206
>
> #18 __ast_pbx_run (c=c@entry=0x7f016c1abf30, args=args@entry=0x0) at
> pbx.c:4380
>
> #19 0x5588ef04282b in pbx_thread (data=data@entry=0x7f016c1abf30) at
> pbx.c:4704
>
> #20 0x5588ef0cf41f in dummy_start (data=) at
> utils.c:1299
>
> #21 0x7f02793216db in start_thread (arg=0x7f014097d700) at
> pthread_create.c:463
>
> #22 0x7f027885b71f in clone () at
> ../sysdeps/unix/sysv/linux/x86_64/clone.S:95
>
>
>
>
>
> Any suggestions of what I could try?
>
>
>
> Dan
> --
> _
> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
>
> asterisk-dev mailing list
> To UNSUBSCRIBE or update options visit:
>

Re: [asterisk-dev] Jira / Gerrit Integration Issue

[George Joseph]

Oh, If you want to build the plugin, you'll need the Atlassian Plugin SDK
that matches our Jira version (6.2.6)
You can get it from here...
https://marketplace.atlassian.com/apps/1210993/atlassian-plugin-sdk-tgz/version-history

Untar it in /opt, then prepend "/opt/atlassian-plugin-sdk-6.2.6/bin" to
your path.

You have to use the atlas-* tools to build, most of which are just wrappers
around maven.
atlas-compile and atlas-package will do it.





On Thu, Jun 10, 2021 at 10:37 AM George Joseph  wrote:

>
>
> On Thu, Jun 10, 2021 at 10:00 AM BJ Weschke  wrote:
>
>> I’d be willing to take a look at it for you George.
>>
>
> A Volunteer!!!  THANKS!  I didn't think anyone would respond so soon. :)
>
>
> Basically, the plugin uses the
> com.sonyericsson.hudson.plugins.gerrit.gerrit-events package to communicate
> with Gerrit.  That in turn uses the com.jcraft.jsch library both through
> gerrit-events and directly.   The gerrit-events package has since been
> split out of the old hudson/jenkins  space
> into com.sonymobile.tools.gerrit.gerrit-events and that's actively
> maintained and is what Jenkins currently uses.  I _think_, _possibly_, that
> moving the jira-gerrit-plugin from the old gerrit-events to the new
> gerrit-events might just fix the issue but I can't be sure.The plugin
> also has the capability to update Gerrit but we don't use that bit.  It may
> then be easier to just change the plugin to use the Gerrit REST interface
> for the query stuff.  The plugin already has configuration settings for
> gerrit url, username and password so why it doesn't use the REST interface
> already I'm not sure.   Anyway, take a look and let me know what you think.
>
> https://github.com/MeetMe/jira-gerrit-plugin
>
>
>
>>
>> Sent from my iPhone
>>
>> On Jun 10, 2021, at 11:31 AM, George Joseph  wrote:
>>
>> 
>>
>> You already know about the SSH host key issue related to the upgrade of
>> Gerrit we did on May 28th.That issue we knew about in advance so we
>> gave everyone advance notice.  Well, we discovered another issue related to
>> SSH but this one was after the fact...
>>
>> We use a Jira plugin to display open Gerrit reviews for issues.  This
>> plugin is quite old and we discovered last Tuesday that it was using SSH
>> Key Exchange Algorithms (kex) that are also quite old and known to be
>> insecure.  With the Gerrit upgrade, those older kex algorithms were removed
>> so Jira was no longer able to log into gerrit via ssh and retrieve the
>> reviews.
>>
>> So we actually have two issues...  First Gerrit really messed up with
>> their release notes because there was absolutely no mention of the
>> implications of their upgrading their SSH backend.  I've taken that up with
>> them.   Second, the Gerrit plugin for Jira really needs an update but it's
>> not well maintained and although we could fix it, we're not exactly
>> overstaffed right now.   The Gerrit team did agree to re-enable the older
>> kex algorithms in their 3.4.1 release but that only helps us in the short
>> term as they will eventually be deprecated for good.
>>
>> So while we should have the integration working again shortly, we're
>> still not sure what to do in the long term.   Would any of you with Java
>> experience be able to take a look at the jira-gerrit-plugin[1]?  It's
>> actually not that complex but it needs its SSH backend (com.jcraft.jsch)
>> replaced.   If any of you are interested, let me know and I can give you
>> the details.
>>
>> [1] https://github.com/MeetMe/jira-gerrit-plugin
>>
>>
>>
>>
>> --
>> George Joseph
>> Asterisk Software Developer
>> direct/fax +1 256 428 6012
>> Check us out at www.sangoma.com and www.asterisk.org
>> 
>> --
>> _
>> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
>>
>> asterisk-dev mailing list
>> To UNSUBSCRIBE or update options visit:
>>   http://lists.digium.com/mailman/listinfo/asterisk-dev
>>
>> --
>> _
>> -- Bandwidth and Colocation Provided 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] Jira / Gerrit Integration Issue

[George Joseph]

On Thu, Jun 10, 2021 at 10:00 AM BJ Weschke  wrote:

> I’d be willing to take a look at it for you George.
>

A Volunteer!!!  THANKS!  I didn't think anyone would respond so soon. :)

Basically, the plugin uses the
com.sonyericsson.hudson.plugins.gerrit.gerrit-events package to communicate
with Gerrit.  That in turn uses the com.jcraft.jsch library both through
gerrit-events and directly.   The gerrit-events package has since been
split out of the old hudson/jenkins  space
into com.sonymobile.tools.gerrit.gerrit-events and that's actively
maintained and is what Jenkins currently uses.  I _think_, _possibly_, that
moving the jira-gerrit-plugin from the old gerrit-events to the new
gerrit-events might just fix the issue but I can't be sure.The plugin
also has the capability to update Gerrit but we don't use that bit.  It may
then be easier to just change the plugin to use the Gerrit REST interface
for the query stuff.  The plugin already has configuration settings for
gerrit url, username and password so why it doesn't use the REST interface
already I'm not sure.   Anyway, take a look and let me know what you think.

https://github.com/MeetMe/jira-gerrit-plugin



>
> Sent from my iPhone
>
> On Jun 10, 2021, at 11:31 AM, George Joseph  wrote:
>
> 
>
> You already know about the SSH host key issue related to the upgrade of
> Gerrit we did on May 28th.That issue we knew about in advance so we
> gave everyone advance notice.  Well, we discovered another issue related to
> SSH but this one was after the fact...
>
> We use a Jira plugin to display open Gerrit reviews for issues.  This
> plugin is quite old and we discovered last Tuesday that it was using SSH
> Key Exchange Algorithms (kex) that are also quite old and known to be
> insecure.  With the Gerrit upgrade, those older kex algorithms were removed
> so Jira was no longer able to log into gerrit via ssh and retrieve the
> reviews.
>
> So we actually have two issues...  First Gerrit really messed up with
> their release notes because there was absolutely no mention of the
> implications of their upgrading their SSH backend.  I've taken that up with
> them.   Second, the Gerrit plugin for Jira really needs an update but it's
> not well maintained and although we could fix it, we're not exactly
> overstaffed right now.   The Gerrit team did agree to re-enable the older
> kex algorithms in their 3.4.1 release but that only helps us in the short
> term as they will eventually be deprecated for good.
>
> So while we should have the integration working again shortly, we're still
> not sure what to do in the long term.   Would any of you with Java
> experience be able to take a look at the jira-gerrit-plugin[1]?  It's
> actually not that complex but it needs its SSH backend (com.jcraft.jsch)
> replaced.   If any of you are interested, let me know and I can give you
> the details.
>
> [1] https://github.com/MeetMe/jira-gerrit-plugin
>
>
>
>
> --
> George Joseph
> Asterisk Software Developer
> direct/fax +1 256 428 6012
> Check us out at www.sangoma.com and www.asterisk.org
> 
> --
> _
> -- Bandwidth and Colocation Provided by http://www.api-digital.com --
>
> asterisk-dev mailing list
> To UNSUBSCRIBE or update options visit:
>   http://lists.digium.com/mailman/listinfo/asterisk-dev
>
> --
> _
> -- Bandwidth and Colocation Provided 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

[asterisk-dev] Jira / Gerrit Integration Issue

[George Joseph]

You already know about the SSH host key issue related to the upgrade of
Gerrit we did on May 28th.That issue we knew about in advance so we
gave everyone advance notice.  Well, we discovered another issue related to
SSH but this one was after the fact...

We use a Jira plugin to display open Gerrit reviews for issues.  This
plugin is quite old and we discovered last Tuesday that it was using SSH
Key Exchange Algorithms (kex) that are also quite old and known to be
insecure.  With the Gerrit upgrade, those older kex algorithms were removed
so Jira was no longer able to log into gerrit via ssh and retrieve the
reviews.

So we actually have two issues...  First Gerrit really messed up with their
release notes because there was absolutely no mention of the implications
of their upgrading their SSH backend.  I've taken that up with them.
 Second, the Gerrit plugin for Jira really needs an update but it's not
well maintained and although we could fix it, we're not exactly overstaffed
right now.   The Gerrit team did agree to re-enable the older kex
algorithms in their 3.4.1 release but that only helps us in the short term
as they will eventually be deprecated for good.

So while we should have the integration working again shortly, we're still
not sure what to do in the long term.   Would any of you with Java
experience be able to take a look at the jira-gerrit-plugin[1]?  It's
actually not that complex but it needs its SSH backend (com.jcraft.jsch)
replaced.   If any of you are interested, let me know and I can give you
the details.

[1] https://github.com/MeetMe/jira-gerrit-plugin




-- 
George Joseph
Asterisk Software Developer
direct/fax +1 256 428 6012
Check us out at www.sangoma.com and www.asterisk.org
[image: image.png]
-- 
_
-- Bandwidth and Colocation Provided by http://www.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 messaging : specifying the user portion of the request-URI

[George Joseph]

Hi Guys,

The change for allowing a dialstring-like destination in MessageSend (pjsip
only) is now committed in the 16, 18 and master branches.  You can now use
MessageSend(pjsip:PJSIP/@) and the request URI
will be composed of the endpoint's contact uri with the number inserted as
the user portion of the uri.  Please give it a test.

For Asterisk 19 (not an LTS release) what would you guys think of changing
the MessageSend application to accept discrete parameters for destination
uri, endpoint, user, etc.?  This would remove about 400 lines of fuzzy
parsing code and give you the most flexibility in constructing a
destination.

On Tue, May 4, 2021 at 12:30 PM George Joseph  wrote:

>
>
> On Tue, May 4, 2021 at 8:49 AM Jean Aunis  wrote:
>
>> Hi,
>>
>> I'm trying to send a SIP MESSAGE to a PJSIP endpoint, while specifying a
>> destination number (that is, the "user" portion of the request URI in
>> sip:u...@domain.com).
>>
>> Currently, this is only possible by specifying the full request URI. For
>> example, someone could use:
>>
>>  > MessageSend(pjsip:endpoint/sip:1000@12.0.0.1)
>>
>> to send a SIP MESSAGE to number 1000.
>>
>> But to do this, one needs to know the contact associated to the
>> endpoint. This is a problem if the endpoint is dynamically registering
>> to Asterisk: the contact information may change over time.
>>
>> When using the dialplan, there is a straightforward solution: using
>> PJSIP_DIAL_CONTACTS.
>>
>> Things become tricky when using ARI or AMI. Retrieving the contact
>> information requires sending an AMI request each time a SIP MESSAGE has
>> to be sent... this can create a lot of overhead.
>>
>> chan_sip used to solve this problem this way: when calling
>> MessageSend(sip:user@endpoint), "endpoint" was at first searched in the
>> endpoints list before being used as a FQDN or an IP address.
>>
>
> The format that PJSIP_DIAL_CONTACTS returns is
> PJSIP/user@endpoint/contact_uri
> For example
> PJSIP/8005551212@provider/sip:sip.provider.com:5060
>
> Dial() doesn't need the contact_uri  but it can be supplied.
>
> I think the easiest way to solve this is to just allow MessageSend take
> the same format as a simple dial string like so
>
> MessageSend(pjsip:PJSIP/8005551212@provider)
> "pjsip:" routes the request to the pjsip channel driver.
> "PJSIP/" tells the pjsip channel driver that what follows is formatted as a
> dial string.
>
> If you wanted to supply the contact_uri as well, you could do
> MessageSend(pjsip:PJSIP/8005551212@provider/sip:sip.provider.com:5060)
> If not, we'd take the first contact of the first aor and use that.
>
>
>>
>> I understand this is more complex with PJSIP because there may be
>> multiple AOR/ contacts for a single endpoint...
>>
>
> Yep, there's the issue and I'm not sure how to get around that other than
> the caller specifying a specific contact uri or us trying every contact for
> every aor associated to an endpoint and stopping when we get a
> 202 Message Accepted.
>
> If we can stick to the first contact on the first aor or specifying
> the specific contact uri, that's a quick  modification to my current
> patch up on gerrit.  If we have to go down the route of trying
> in turn, that's something that will need more thought.
>
>
>
>
>>
>> Any ideas ?
>>
>> Regards,
>>
>> Jean
>>
>>
>>
>> --
>> _
>> -- Bandwidth and Colocation Provided 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