[asterisk-dev] Mailing List Move Reminder
Hello, Just a reminder that on February 1st this mailing list will go into a moderated only state meaning new messages will not be accepted. Conversations should move to the new mailing list[1] to continue them. Archives will remain available. Cheers, [1] https://groups.io/g/asterisk-dev -- Joshua C. Colp Director of Engineering | 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
Re: [asterisk-dev] AstriDevCon 2024 Registration
A final reminder on registration! If you haven't registered please remember to do so. If you can't remember if you've signed up or not then I'll manually fix up your entry if it's a duplicate. On Tue, Nov 14, 2023 at 5:34 AM Joshua C. Colp wrote: > Greetings all, > > AstriDevCon 2024 registration is now available[1]. It will be held on > Wednesday, February 14th, 2024 in Fort Lauderdale, Florida the day before > AstriCon as part of ITEXPO. It will also be available virtually, so I ask > that either way you please submit your registration. We will also use the > #asterisk-dev IRC channel on Libera for text chat. Time will be available > if you would like to do a presentation about a subject, just ensure you > select that on the registration form. As the day gets closer an email will > be sent out with any further details including virtual attendance > information. Even if you state that you will be attending physically you > will still receive the virtual attendance information in case you have > changed your mind or something has come up. > > Cheers, > > [1] https://docs.asterisk.org/Development/Roadmap/AstriDevCon/ > > -- > Joshua C. Colp > Asterisk Project Lead > Sangoma Technologies > Check us out at www.sangoma.com and www.asterisk.org > -- Joshua C. Colp Director of Engineering | 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
Re: [asterisk-dev] ChanSpy / ConfBridge limitation
On Sun, Jan 14, 2024 at 9:10 PM Mark Murawski
wrote:
> Howdy -dev,
>
> Looking for a starting point to investigate this issue:
>
> Using the following AEL (and Running straight-dialplan results in the same
> issue)
>
> context services {
> 2802 => {
> Answer();
> Set(GLOBAL(foo)=${CHANNEL});
> ConfBridge(Agent-PJSIP/2802);
> }
>
> 9000 => {
> Answer();
> ChanSpy(${foo},qoSE);
> }
> }
>
> PJSIP/2802-3b18 -> ConfBridge("Agent-PJSIP/2802")
> joined 'softmix' base-bridge
> <56974564-b175-4b6a-93fc-fe4753082213>
> joined 'softmix' base-bridge
> <56974564-b175-4b6a-93fc-fe4753082213>
>
> PJSIP/trunk-bob-3b19 -> ChanSpy("PJSIP/2802-3b18,qoSE")
> Spying on channel PJSIP/2802-3b18
> Attaching spy channel PJSIP/trunk-bob-3b19 to PJSIP/2802-3b18
>
>
> Issue:
> No audio is flowing from Spied-on PJSIP/2802-3b18 to the spy-er
> PJSIP/trunk-bob-3b19
>
>
> If for example, you change 2802 to the following:
>
> 2802 => {
> Answer();
> Set(GLOBAL(foo)=${CHANNEL});
> Dial(PJSIP/2803);
> }
>
>
> Wait for the call to connect/answer
> PJSIP/2802-3b20 -> PJSIP/2803-3b5d (callee answered)
>
> And then run the same ChanSpy with options qoSE, resulting in:
> PJSIP/trunk-bob-3b97 -> ChanSpy("PJSIP/2802-3b20,qoSE")
> Attaching spy channel PJSIP/trunk-bob-3b97 to PJSIP/2802-3b20
>
>
> Result:
> Audio IS flowing from spied-on PJSIP/2802-3b20 to the spy-er on
> PJSIP/trunk-bob-3b97
>
>
>
> One might say: Well, ChanSpy/ConfBridge don't mix... but then if you do the
> following... this DOES work:
>
> context services {
> 2802 => {
> Answer();
> Set(GLOBAL(foo)=${CHANNEL});
> ConfBridge(Agent-PJSIP/2802);
> }
>
> 9000 => {
> Answer();
> ChanSpy(${foo},qwSE);
> }
> }
>
> Changing the option from 'o' to 'w', allows you to whisper to PJSIP/2802
>
>
>
>
> Goal:
> Extract out an individual speaker's audio that's going into a ConfBridge
> (Cannot join the bridge as a member, because then you're getting all
> participants audio)
>
>
> Summary:
> 1) You can whisper to a channel that joined a ConfBridge
> 2) You cannot listen to the audio from a channel that joined a ConfBridge
>
>
> Also:
> I tried ChanSpy()'ing into both CBAnn/...;1 and CBAnn/...;2 and I could
> not get audio from here either
>
>
> Is this a bug or a limitation/missing-feature?
>
>
> What would be a good place to look into for resolving #2 ?
>
>
So what is the actual state of the channel and ConfBridge at that point in
time? You haven't really clarified that in this email at all. Is it
listening to music on hold? Is there no other channel present? Have you
looked at the core debug to see what the audiohooks API is saying?
Ultimately that's what is capturing the audio and making it available for
ChanSpy and it has no idea of ConfBridge or Dial or etc, so narrow down the
issue to either the ChanSpy module itself or audiohooks, and then go from
there. In a general sense from the available information I would say it is
a bug, though I am aware that this has worked for other people without
problem.
--
Joshua C. Colp
Director of Engineering | 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
Re: [asterisk-dev] Allow GET_TRANSFERRER_DATA in chan_pjsip
On Thu, Jan 11, 2024 at 11:07 AM Tomec Martin wrote: > Hi, > I would like to write patch to allow GET_TRANSFERRER_DATA also in pjsip > (to access incoming REFER headers in dialplan). The original patch for > chan_sip is in [1] > Where is the right place to add the code? > I suppose that in res_pjsip_refer.c [2] in function > "refer_incoming_invite_request" I could add headers data to > session->channel. Is it correct place? > That is where such functionality should exist, yes. -- Joshua C. Colp Director of Engineering | 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
Re: [asterisk-dev] Mailing List Future
On Fri, Jan 5, 2024 at 6:48 AM Paul Kudla (SCOM.CA Internet Services Inc.) < p...@scom.ca> wrote: > > yes > > basically all email would come from @asterisk-dev.groups.io > > which would be more main stream and at the same time be unique to > asterisk dev! > Is the test email sufficient, or not? -- Joshua C. Colp Director of Engineering | 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
Re: [asterisk-dev] Mailing List Future
On Fri, Jan 5, 2024 at 6:33 AM Joshua C. Colp wrote: > On Fri, Jan 5, 2024 at 6:21 AM Paul Kudla wrote: > >> >> I think we are getting off track here, >> >> email can come from anywhere >> >> like mine when i send an email it comes from "Paul Kudla " >> which is perfectly normal, if i sent an email from : >> >> "Paul Kudla " >> >> that would be wrong because the email address does not exist and would >> eventually bounce on most system or more importantly get blocked in >> someone's spam filter because it is unknown to the end user. >> >> Again trying to help >> >> >> the issue creeps in when a mail system tries to send with a different >> send email address then what is in the headers. >> >> My or any other system does not block ordinary email, and the tmda (in >> my case) will trap it for approval. I can catch and kinda approve these >> but its one at a time when headers get messed with. >> >> The issues being found here is email from for example >> >> Asterisk Developers Mailing List >> >> is now show as >> >> Asterisk Developers Mailing List >> >> which in its self kinda correct but but group.io should really be a >> proper domain related to asterisk like the >> >> "> >> was >> >> fyi >> >> >> Hope this clarifies, asterisk mailing list really needs to come from an >> asterisk domain (or sub domain) NOT groups.io >> >> can you get n asterisk.groups.io >> (like the digium one? - lists.digium.com) >> >> this would resolve to identy issues. >> > > Possibly? I created a subgroup which moved things to an > asterisk-dev.groups.io subdomain, whether that is sufficient for your > purposes I do not know. > I do not believe it is sufficient based on your comments. -- Joshua C. Colp Director of Engineering | 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
Re: [asterisk-dev] Mailing List Future
On Fri, Jan 5, 2024 at 6:21 AM Paul Kudla wrote: > > I think we are getting off track here, > > email can come from anywhere > > like mine when i send an email it comes from "Paul Kudla " > which is perfectly normal, if i sent an email from : > > "Paul Kudla " > > that would be wrong because the email address does not exist and would > eventually bounce on most system or more importantly get blocked in > someone's spam filter because it is unknown to the end user. > > Again trying to help > > > the issue creeps in when a mail system tries to send with a different > send email address then what is in the headers. > > My or any other system does not block ordinary email, and the tmda (in > my case) will trap it for approval. I can catch and kinda approve these > but its one at a time when headers get messed with. > > The issues being found here is email from for example > > Asterisk Developers Mailing List > > is now show as > > Asterisk Developers Mailing List > > which in its self kinda correct but but group.io should really be a > proper domain related to asterisk like the > > " > was > > fyi > > > Hope this clarifies, asterisk mailing list really needs to come from an > asterisk domain (or sub domain) NOT groups.io > > can you get n asterisk.groups.io > (like the digium one? - lists.digium.com) > > this would resolve to identy issues. > Possibly? I created a subgroup which moved things to an asterisk-dev.groups.io subdomain, whether that is sufficient for your purposes I do not know. -- Joshua C. Colp Director of Engineering | 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
Re: [asterisk-dev] Mailing List Future
On Fri, Jan 5, 2024 at 3:57 AM Jonathan Aquilina wrote: > Morning, > > Where does one subscribe to this new list? > The list is at https://groups.io/g/asterisk-dev -- Joshua C. Colp Director of Engineering | 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
Re: [asterisk-dev] Mailing list messages failing DKIM
On Thu, Jan 4, 2024 at 5:29 PM David Sovereen wrote: > Our mail system is showing that messages from the mailing list are failing > DKIM. As a result, all messages are going to my Junk Mail folder. I even > "trusted" the mailing address list, but because it is failing DKIM and is > therefore suspected to be a fraudulent/faked message, it is going to Junk > Mail anyway. I didn't know I was missing all these messages until now. > > Is anyone else seeing these DKIM failures? Can this be fixed? > Which mailing list are you referring to? The lists.digium.com stuff is going away at the end of the month, so I won't be investing time in trying to fix it up. The new list is here[1] [1] https://groups.io/g/asterisk-dev -- Joshua C. Colp Director of Engineering | 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
Re: [asterisk-dev] Mailing List Future
On Thu, Jan 4, 2024 at 8:28 AM Paul Kudla wrote: > > ok > > i will post examples if/when this happens then for better clarificastion > unless groups.io is uniqe to asterisk ? > > being an isp mailing lists / open systems are the first to get hacked ! > The groups.io platform is not unique to Asterisk, there are numerous groups hosted on it. Directly adding members to groups requires a paying plan, otherwise adding an email address requires someone signing up themselves. -- Joshua C. Colp Director of Engineering | 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
Re: [asterisk-dev] Mailing List Future
On Thu, Jan 4, 2024 at 8:07 AM Paul Kudla wrote: > > because the sender address (what a spam filter or in my case tmda would > use) > > is : bou...@groups.io > > which is a universal email sending address from groups.io (ie their mail > system) > > currently you are using : asterisk-dev@lists.digium.com > > which is unique to Asterisk. > Okay, so you are saying that theoretically because it is a shared domain name someone could theoretically receive spam from that domain name in the future causing a deliverability issue for them for the new asterisk-dev mailing list? I don't foresee that being an issue but if it becomes one then I will investigate. -- Joshua C. Colp Director of Engineering | 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
Re: [asterisk-dev] Mailing List Future
On Thu, Jan 4, 2024 at 6:52 AM Paul Kudla (SCOM.CA Internet Services Inc.) < p...@scom.ca> wrote: > > Good morning > > I got verified however the new mailing list is using > > Asterisk Development Team via groups.io > > note the bou...@groups.io > > should really be an asterisk email address > > if i open up groups.io (like msvc etc) then spam will flow > > i am an isp and apologise for the comments knowing you are doing you > best, just letting you know some difficulties before they become a large > scale issue > Why would spam flow exactly? -- Joshua C. Colp Director of Engineering | 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
Re: [asterisk-dev] Mailing List Future
On Tue, Jan 2, 2024 at 6:41 AM Paul Kudla wrote:
>
> Good morning
>
> Note I am unable to confirm my new email on the group because the email
> is using a blocked server ??
>
> mail19 01-02 05:35:51 {postfix.in} [63603] (1871410360) Jan 02
> 05:35:51 mail19 postfix/smtpd[63603]: NOQUEUE: reject: RCPT from
>
> web01.groups.io[66.175.222.12]: 454 4.7.1 Service unavailable; Client
> host [66.175.222.12] blocked using
>
> bl.spamcop.net; Blocked - see
> https://www.spamcop.net/bl.shtml?66.175.222.12;
>
> from=
> to= proto=ESMTP
>
> helo=
>
> I did get the signup and also set my password but am unable to proceed.
>
> SPAMCOP.NET is super flexible (ie will track and update bad ip's on the
> fly within 24 hours, so to land on this list means a server has been
> very very bad.
>
> let me know if i can help further.
>
I don't think either of us can really help. Looking at groups.io posts this
appears to happen sometimes, be it as a remaining result of a Yahoo
migration that occurred in the past or from group admins adding email
addresses for SpamCop spam traps in some capacity.
InterLinked: You previously stated that most lists you've been on migrated
to groups.io, has this been a problem for them and if so how did they
approach it (if at all)?
--
Joshua C. Colp
Director of Engineering | 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
Re: [asterisk-dev] Mailing List Future
Greetings all, Happy new year! During my vacation I was still working (which is something I'm trying to get better at but that's a 2024 thing) so was able to communicate with legal during such time. Based on the recommendation from aster...@phreaknet.org (you may also know him as InterLinked on GitHub and IRC) I have set up an asterisk-dev group[1] on groups.io. Before actively moving I suggest everyone subscribe, play around with it, start some discussions, etc, to get a feel for it. If there's also feedback on settings I can tweak to make it over all better I can also look at those as it gives much more control over things than the previous solution. I've already done a run through and tweaked settings to fit our usage, but improvements are always nice. I'd also like to extend a thank you to all those who offered hardware and physical hosting even though I did not take you up on it. Cheers, [1] https://groups.io/g/asterisk-dev -- Joshua C. Colp Director of Engineering | 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
Re: [asterisk-dev] Asterisk bridging framework
On Sun, Dec 31, 2023 at 11:37 AM wrote: > > Thanks, Josh, >One other question I have: is there any current mechanism for > retaining a channel's TX audio in the RX audio it gets from the bridge? > I see in bridge_softmix that the channel's audio is removed, but at > least here I don't see any logic to keep the audio: > > https://github.com/asterisk/asterisk/blob/master/bridges/bridge_softmix.c#L199 > > I thought maybe this was related to the binaural setting, but now I > don't think so since both paths subtract. > Interface wise, this is more about the bridging framework as a whole, > but practically speaking, only bridge_softmix is used as the bridging > technology, so I'm more focused on that. > > If the answer is 'no', I'm assuming a bridging option would need to be > added to not subtract the sender's audio from what it gets back from the > bridge? If this was done, would it be fine if only certain technologies, > e.g. bridge_softmix obeyed this? Or does it have to be universally > implemented? There is no current mechanism, because it's counter to how almost everyone expects/needs bridging to work and operate. Hearing yourself never ends well. Why is such a thing needed? Does it have wide applicability? Is it only for your usage/use case? -- Joshua C. Colp Director of Engineering | 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
Re: [asterisk-dev] Asterisk bridging framework
On Wed, Dec 27, 2023 at 5:23 PM wrote: > A few questions about the native bridging framework: > > In contrast to DAHDI conferencing, which still requires manually > servicing each channel in the conference, in whatever arbitrary threads > desired, the bridging API is more "event oriented". I have a couple > questions about the latter: > > * Is there any way to retain control of a channel in a bridge and > service it manually, e.g. call ast_waitfor/ast_read on it? It seems > when a channel is imparted to a bridge, a thread is always created, > with the only difference being you don't need to join it later with > AST_BRIDGE_IMPART_CHAN_INDEPENDENT. I'm pretty sure the answer is > 'no', since that's the entire point of native bridging, but just > want to confirm that... (and that the bridging framework requires 1 > thread per channel) > No. Servicing is yielded to the bridge on being put into a bridge. Control can be temporarily yielded to a different thread using ast_bridge_suspend and returned to the bridge using ast_bridge_unsuspend while in a bridge. > * There are a couple functions for hooking into the bridge, e.g. > ast_bridge_dtmf_hook for DTMF events and ast_bridge_interval_hook > periodically. I don't see anything more generic than this, though. > Say that for certain channels in the bridge I wanted to intercept > the voice frames from the bridge and modify them. I suppose you just > use framehooks as usual on the channel? I'm guessing there's no > difference in behavior, and that ast_bridge_dtmf_hook is purely a > convenience function. > Framehooks would be used for that purpose. DTMF hooks aren't strictly a convenience, because they are aware of the threading model of bridging and can do things within the confines of the bridge without leaving it. > * Is there any current way to detect if a channel is muted in a > bridge? There's an ast_channel_suppress API, but no API to read the > datastore, and I don't see anything else that seems relevant to > determining this. Not sure if I've missed something... would code > need to be added to do this? > There is no explicit API for the bridge level muting to check, but provided the channel lock was held you could probably grab the ast_bridge_channel using ast_channel_get_bridge_channel, and then look at the features, and check mute. If the suppress API method is used instead to mute it and an API doesn't exist for that, then it would have to be extended. -- Joshua C. Colp Director of Engineering | 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
Re: [asterisk-dev] masquerade() Education
On Mon, Dec 18, 2023 at 8:12 PM Steve Murphy wrote: > While my work revolves largely around asterisk, this issue comes up over > and over, especially when it's time to upgrade to a new version of > Asterisk. I keep intending to ask about it, but finally, I have this > chance. Why exactly is masquerade() still necessary? I am asking more > out of curiosity than condemnation or other negative reasons! I would > love to understand the issues, perhaps at some point in time, I may be > able to help. > Because a channel isn't always bridged when you want to swap it with another, and there is no other operation or method to do so except for masquerade. To get rid of masquerade would require a rearchitecture such that bridging is always occurring, or to make everything (applications and other APIs) aware of some kind of swap operation. These days masquerades aren't really a huge thing like they were in the old days because it's mostly been hidden from view and has become an internal detail. Many years ago it would leak out into places such as AMI and be more problematic. -- 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
Re: [asterisk-dev] AstriDevCon 2024 Registration
Hey all, Just a reminder about AstriDevCon. If you haven't registered please remember to do so, even if attending virtually. On Tue, Nov 14, 2023 at 5:34 AM Joshua C. Colp wrote: > Greetings all, > > AstriDevCon 2024 registration is now available[1]. It will be held on > Wednesday, February 14th, 2024 in Fort Lauderdale, Florida the day before > AstriCon as part of ITEXPO. It will also be available virtually, so I ask > that either way you please submit your registration. We will also use the > #asterisk-dev IRC channel on Libera for text chat. Time will be available > if you would like to do a presentation about a subject, just ensure you > select that on the registration form. As the day gets closer an email will > be sent out with any further details including virtual attendance > information. Even if you state that you will be attending physically you > will still receive the virtual attendance information in case you have > changed your mind or something has come up. > > Cheers, > > [1] https://docs.asterisk.org/Development/Roadmap/AstriDevCon/ > > -- > Joshua C. Colp > Asterisk Project Lead > Sangoma Technologies > Check us out at www.sangoma.com and www.asterisk.org > -- 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
Re: [asterisk-dev] PJSIP internal DNS client binding to random sticky ports can look scary
On Fri, Dec 15, 2023 at 5:26 PM C. Maj wrote: > Howdy, > > This came up on the forums and seems appropriate to cross-post to -dev: > > https://community.asterisk.org/t/asterisk-listens-on-ipv6-port/99666 > > OP wrote: > > "Please tell me why asterisk listens to ipv6 interface on random udp > ports? Which module should be disabled or configured so that asterisk > does not do this?" > > Reply mentioned previous discussion: > > https://issues-archive.asterisk.org/ASTERISK-25481 > > Point of concern is in PJSIP pjlib-util resolver: > > > https://github.com/pjsip/pjproject/blob/master/pjlib-util/src/pjlib-util/resolver.c > > Curious if best fix should be placed in third-party/pjproject/patches/ > to address the particular pj_sock_bind_in() functions, allowing both > user-adjustable client binding host and port in /etc/asterisk/pjsip.conf > with appropriate documentation around these new options ? > > Or, would a more developmentally-complicated *but > less-anxiety-inducing-for-end-users* fix involve opening and closing a > socket *as needed* ? > Modern versions of Asterisk don't use the PJSIP resolver. We replace it with our own callback in res/res_pjsip/pjsip_resolver.c and do it on our own using either res_resolver_system, or res_resolver_unbound (which would listen itself). If PJSIP is still listening for DNS responses, then that would most likely be a bug and a patch to disable it when an external resolver (in PJSIP speak) is used should be provided to Teluu on their GitHub to see what they think, and then backported. -- 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
Re: [asterisk-dev] Mailing List Future
On Wed, Dec 13, 2023 at 10:12 AM Henning Westerholt wrote: > Hello, > > > > honestly, I don’t understand the point of this discussion anymore. > Probably all the people that somehow are interested in keeping the mailing > list spoke up by now. Almost all were in favour of keeping the list. Some > people also offered help in hosting the list in the future. > More people have spoken up after I nudged in a previous post. Their input is also welcome, including how they use the list, because that information is also useful in other ways. For example some people were unaware that you could even watch repos on GitHub and have sent me thanks for that information. That's a data point so we can make it clearer in other areas that it can be done for users to be aware of things outside of a mailing list for those who choose it. > > > If it’s your decision as asterisk project manager to shut down this list, > then just do it. If the asterisk project does not care about the opinion of > their independent contributors and developers in this matter to save some > operations costs, that is unfortunate but understandable. In the end it > shows the value of this open-source community for the project. Everyone > must then decide if moving to a proprietary communication solution is > acceptable. > The lists.digium.com instance as it exists now will shut down. Its history and archive will remain available. The mailman instance is not in a state where upgrading or migrating it is feasible. Those are the facts. I have received private communication from an individual who attempted to do so on their own instance in a similar state and was unable to, and they stated that they were aware others had tried with most being failures. Based on the community feedback from those using the list I have chosen to continue through a new mailing list on a hosted solution, thus one will continue to exist. I was hoping to have a plan and also check over aspects that are indirectly involved (for example the release process and how it would get emails to such a thing in a manner that works as well as check with legal about personal information involving an outside vendor) before saying so (and also collect more information on usage), but none of that is done as of yet. I don't know the full details yet but will keep this mailing list updated until such time as we're ready with the details. -- 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
Re: [asterisk-dev] Mailing List Future
On Wed, Dec 13, 2023 at 9:21 AM wrote: > On 12/13/2023 7:55 AM, Joshua C. Colp wrote: > > On Wed, Dec 13, 2023 at 8:45 AM Jonathan Simpson > > mailto:jsimp...@jdsnetwork.com>> wrote: > > > > The mixed content is useful. > > > > Learning about stir shaken updates, useful. Would that have been > > in a github notification? Would the subject line be parsable? > > > > > > My inquiry was strictly regarding release notifications and security > > advisories. If discussions were done in GitHub then it would have been > > a GitHub notification and parseable if you opted to receive them. > > I'll point out another issue with this as well. This assumes we're just > talking about the "asterisk" repo here, and friends, but the > asterisk-dev list has become the catch-all list for most discussion of > anything development related in the entire Asterisk family of software, > particularly as most of the other lists died a long time ago. > Some people have turned it into that, yes. > > For example, in what repo should discussion of wanpipe take place? Some > of us might want to discuss issues with or trade patches[1], but there > isn't a wanpipe repo since it's not an "open source project". Or general > discussions that might cross over into multiple repos at once, like > something that affects both Asterisk and DAHDI Linux, or both DAHDI > Linux and DAHDI Tools? Should everyone now watch the asterisk-test-suite > repo too? There are a lot of edge cases this doesn't handle well. > I think it's also worth pointing out that, while I'm not one of these > individuals, there are a number of people that don't have a GitHub > account (and perhaps might not want one) that would be excluded if all > discussion was happening there. This very point came out when the > project moved away from Atlassian and there were comments to that effect > *on this list*. These people would have been completely unheard if > discussion had also moved to GitHub prior to that. Do you want to > intentionally exclude them now? > > Some people I've noticed also subscribe to the digest version of this > list. I could be wrong but I doubt GitHub discussion has a "digest" > mechanism... because it isn't a real mailing list with all the options > of a real mailing list. > > Sometimes people see something on the mailing list and reply privately > to the OP to continue a specific point of discussion off-list. On GitHub > discussions, where everyone is identified by their GitHub usernames and > not real names or email addresses, getting in touch with someone could > be considerably more difficult, particularly for people who might just > be looking at the discussion online. > > And frankly, I think expecting 2100 people to reply to this thread is > downright unrealistic. On no mailing list ever does everybody > participate. The majority of mailing lists are dominated by the > discussion of a few while the rest sit back and listen (which is > perfectly fine), maybe 5% of posters generating 95% of the posts. Some > people don't want to contribute, but they do want to read. Nobody has > come out and said he or she wants the mailing list to go away or give > way to another format, and lack of a response is *not* tacit approval of > doing so. All the stakeholders that have spoken out are against the > decision. > I'm not expecting 2100 people to reply. What I'm trying to get is more people to respond with how THEY use the mailing lists. Your opinion is yours, and is how you want to use the mailing list and what you want get out of it. It's a factor in things but you don't speak for everyone. Everyone is different and understanding what people are actually expecting out of the mailing lists is important. So far what I'm seeing is people using it for announcement type stuff, with the odd discussion here and there, and as a way to get some insight into development. So hypothetically speaking if a new mailing list were to be created but the existing subscriber list could not be preserved, would people sign up again? -- 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
Re: [asterisk-dev] Mailing List Future
On Wed, Dec 13, 2023 at 8:45 AM Jonathan Simpson wrote: > The mixed content is useful. > > Learning about stir shaken updates, useful. Would that have been in a > github notification? Would the subject line be parsable? > My inquiry was strictly regarding release notifications and security advisories. If discussions were done in GitHub then it would have been a GitHub notification and parseable if you opted to receive them. > > > Notifications from github are more likely to be lost among the many others > I get for my own work. > There's various options for filtering, some are mentioned on the previous link I gave to Jaco but if it helps at all you can also do custom routing[1]. On a per-organization basis you can direct emails to a different email address that's associated on your GitHub account which can make filtering easier. I use it personally for directing Asterisk stuff to Sangoma, and personal stuff to personal. It's handy. [1] https://docs.github.com/en/account-and-profile/managing-subscriptions-and-notifications-on-github/setting-up-notifications/configuring-notifications#customizing-email-routes-per-organization -- 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
Re: [asterisk-dev] Mailing List Future
On Wed, Dec 13, 2023 at 8:40 AM Jaco Kroon wrote: > Hi Joshua, > On 2023/12/13 14:30, Joshua C. Colp wrote: > > On Wed, Dec 13, 2023 at 8:12 AM Floimair Florian > wrote: > >> I agree! >> >> >> >> To me the mailing list is the best source of gathering information, >> especially in terms of announcements of new Release versions. >> >> While there might be more info in the github releases the trigger is >> always the mailing list. >> > > Can you (and others) explain why GitHub can't take the place of that > aspect? You can watch to receive notifications for just releases and > security advisories, which can then trigger an email. Is it the format of > the email? Harder to filter? The list is easier because it's combined with > other stuff? > > I'm going to be the one it seems asking the blunt question: > > How? > While logged in you go to any repository on GitHub, including Asterisk, https://github.com/asterisk/asterisk and and click the "Watch" button to the left of "Fork". There are various options but if you want to be more refined in what you receive notifications for go to "Custom" and you can select which things. "Releases" and "Security alerts" being the best option for most people. GitHub has an entire documentation section on subscriptions/notifications[1] with lots of details. If you use other open source projects on GitHub, this is also useful since you can do the same with them. [1] https://docs.github.com/en/account-and-profile/managing-subscriptions-and-notifications-on-github -- 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
Re: [asterisk-dev] Mailing List Future
On Wed, Dec 13, 2023 at 8:12 AM Floimair Florian wrote: > I agree! > > > > To me the mailing list is the best source of gathering information, > especially in terms of announcements of new Release versions. > > While there might be more info in the github releases the trigger is > always the mailing list. > Can you (and others) explain why GitHub can't take the place of that aspect? You can watch to receive notifications for just releases and security advisories, which can then trigger an email. Is it the format of the email? Harder to filter? The list is easier because it's combined with other stuff? -- 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
Re: [asterisk-dev] Mailing List Future
On Tue, Dec 12, 2023 at 12:10 PM Henning Westerholt wrote: > Hello, > > > > the majority of the responses seems to be against the discontinuation of > the mailing list. > Yes, this is true. It would be nice to have more input though so if other individuals have opinions (including why they want the lists to continue and what they use them for) then that would be beneficial. I'm talking to the over 2100 people who haven't responded to this thread. > > > Has a decision already been made in the last week? Or is this still > discussed internally or with some of the people that offered help in > keeping the mailing lists running? > The only decision that has been made is that the instance of lists.digium.com as it exists today will go away. I don't expect any explicit decision to occur until next year. I'm personally going on vacation for 2 weeks, though others may continue any discussion in my absence to get further insight. -- 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
Re: [asterisk-dev] Mailing List Future
On Mon, Dec 4, 2023 at 10:40 AM Dovid Bender wrote: > Josh, > > IMHO the list has dwindled as most issues are covered. When the project > first started there were a lot of questions that are now available on > Google. However every so often things come up where the list is very > helpful. Also the forums seem to attract a different crowd I feel like the > people on this list may not be the same ones visiting the forum. I am more > than happy to give of my time to help setup fresh boxes, help admin the > email list etc. We also have some 2nd gen boxes (R630 and R730 boxes) that > we would give for the cause. > I have noted your opinion and offer. -- 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
Re: [asterisk-dev] Mailing List Future
On Mon, Dec 4, 2023 at 10:31 AM Olle E. Johansson wrote: > > > On 4 Dec 2023, at 13:38, Joshua C. Colp wrote: > > The mailing lists have remained unchanged since deployed. > > …and the archives for everything is still around. > > Mail is boring but very very long-term stable. > > Forums are cool, sexy and keeps changing so we loose history because the > cost of mirgrating old postings and comments is way too high and the > marketing department that runs the forums seldom understand the need to > keep it persistent… > > Did you mean for new content? And are you referring to just the asterisk-dev mailing list? -- 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
Re: [asterisk-dev] Mailing List Future
On Mon, Dec 4, 2023 at 10:31 AM Olle E. Johansson wrote: > > > On 4 Dec 2023, at 13:38, Joshua C. Colp wrote: > > The mailing lists have remained unchanged since deployed. > > …and the archives for everything is still around. > As mentioned in my original email, the list archives will remain available. They will be in the same format they are now, same location, same look. > > Mail is boring but very very long-term stable. > > Forums are cool, sexy and keeps changing so we loose history because the > cost of mirgrating old postings and comments is way too high and the > marketing department that runs the forums seldom understand the need to > keep it persistent… > > I would encourage keeping a development mailing list. > > /O > > > For self hosting they would need to be completely redone on fresh > infrastructure, fresh distro, fresh software, and hopefully things would > possibly import. They'd also need to be updated to conform to current > standards on sending so that that they don't appear as spam as often. (For > me 25% of emails from the lists go to my spam currently and require manual > involvement) > > For hosted we'd need support for over 2500+ subscribers for the -dev list > if it were to be imported. For commercial entities we could possibly > import, but for something like someone doing that work and effort and > hosting I would not be comfortable providing such information, and people > would need to sign up fresh again. It would also not be something I would > be willing to spend money on due to the low use of the lists. > > Past that - can you explain why it's a bad idea? I've looked at the > interactions for the past few years and while some have existed, they've > been minimal over all. > > On Mon, Dec 4, 2023 at 8:28 AM Jaco Kroon wrote: > >> Hi, >> >> My 5c. Killing the dev list is a bad idea. >> >> Most developers could not care about having to poll forums. It also >> means that stuff that would previously get an audience will now get none. >> >> github discussions are better than forums at least. >> >> May I inquire as to the problem you're having with the ML? Perhaps I >> might be able to assist ... >> >> Kind regards, >> Jaco >> >> On 2023/12/04 14:00, Joshua C. Colp wrote: >> >> Greetings all, >> >> Over the past few years, the use of the Asterisk mailing lists has >> diminished, with far more conversation happening on the Asterisk community >> forums[1]. The state of email, to ensure reliable delivery, has also gotten >> more complicated - emails get caught by spam filters, etc.. To continue the >> mailing lists would require a huge time and resource investment, for >> minimal use. >> >> To that end, we’ve decided to discontinue the mailing lists effective >> February 1st, 2024. >> >> This means the following: >> >> 1. Sending and receiving mailing list emails will no longer be possible. >> 2. The list archives, however, will remain available. >> >> We need to decide the future of the asterisk-dev mailing list; >> specifically, where to hold discussions in the future. There are a few >> options: >> >> 1. A “Development” category exists on https://community.asterisk.org/ >> already that can be used. >> 2. We can use GitHub discussions, which keeps things with the GitHub >> project. >> 3. We can use a hosted mailing list elsewhere. >> >> We suggest option #2, since it keeps things with the GitHub project, >> which is where everything development-related happens now regardless. This >> has been set up and enabled already. >> >> If you have any input, now is the time to state it. >> >> Cheers, >> >> -- >> Joshua C. Colp >> Asterisk Project Lead >> Sangoma Technologies >> Check us out at www.sangoma.com and www.asterisk.org >> >> > > -- > 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 -- 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
Re: [asterisk-dev] Mailing List Future
On Mon, Dec 4, 2023 at 10:24 AM Fred Posner wrote: > > > On Dec 4, 2023, at 9:19 AM, Joshua C. Colp wrote: > > > > No changes have actually occurred as of yet, aside from me sending an > email, and I also gave 2 months of notice on purpose to allow people to > think and respond. > > > > In your original email you wrote: > > > To that end, we’ve decided to discontinue the mailing lists effective > February 1st, 2024. > > > This absolutely gives the impression of a decision/change being made. > Okay, I acknowledge that. In my mind with decisions until things are actually enacted there is always the chance or possibility of change. I will take that into consideration for the future. -- 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
Re: [asterisk-dev] Mailing List Future
On Mon, Dec 4, 2023 at 9:27 AM Fred Posner wrote: > Looks like the majority of responses are negative. > > I’m also disappointed in this decision/ > > > Over the past few years, the use of the Asterisk mailing lists has > diminished, with far more conversation happening on the Asterisk community > forums[1]. The state of email, to ensure reliable delivery, has also gotten > more complicated - emails get caught by spam filters, etc.. To continue the > mailing lists would require a huge time and resource investment, for > minimal use. > > I don’t want to get on a “which is better” argument, but will add that > email is by far the most accessible method of communication available to a > worldwide audience of different means, languages, and abilities. It is not > prohibitive by those with limited sight, easily translated, easily indexed > for searching, and simple for those on even the most basic non-gui systems. > > Of course there are also other benefits that I think would only result in > wasted typing as it seems that this decision done. > > I will say the disappointment comes from making such a change without even > taking the minimal effort of surveying the user/list base/community for > what methods would be most desired. > No changes have actually occurred as of yet, aside from me sending an email, and I also gave 2 months of notice on purpose to allow people to think and respond. > > The complicated argument, in my opinion, is a bit exaggerated and the > issues have been handled by so many other groups, that assistance can > surely be provided if the project having trouble. > Yes, it is possible. People have offered alternative suggestions, and I have made note of them. > > To me personally, this shows how important it is to strengthen the > community as a whole, to check the temperature now and then, and to > consider feedback/audience/goal prior to making top down decisions. > > I remain disappointed; although to be honest, at this point, I’m not > surprised by these decisions. > If you wish to be disappointed, then do so in me - as this is all my work. -- 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
Re: [asterisk-dev] Mailing List Future
On Mon, Dec 4, 2023 at 8:52 AM wrote: > I strongly object to not having an asterisk-dev list. Mailing lists are > essential for FOSS developer discussion. The majority of non-ephemeral > development discussion happens either on IRC or here on the asterisk-dev > list - just check the archives to see that it's still active. Most of us > are not on the community forums and/or couldn't be bothered to use them. > You can go and see now that "Development" on the community forums is > basically dead, because nobody wants to use it, so trying to push that > on everyone is a terrible idea. > The "Development" category was done on a whim and hasn't really been advertised or mentioned a huge amount. I presented it merely as an option, as it was present. > > Even for users, I think the loss of asterisk-users will be a major loss. > Far more *discussion* is happening on the Discourse forum, but far more > *quality* discussion still happens on asterisk-users. Being on a mailing > list seems to be a natural weedout for junk questions. More serious > questions still seem to come through on the mailing list. The community > forums is far fuller of useless postings from people who can't tell a > hard drive from a memory stick. Nobody wants to wade through a bunch of > low-quality posts to find the few that might have some use. Thus, > getting rid of asterisk-users would see a significant drop in the > average quality of user engagement. But at least, even if the -users > list is dropped, the -dev list should stick around in some form. > To be quite blunt, the quality is better on asterisk-users because few actually use it. In the earlier days the quality wasn't as good when it was actually used more. Even then, the quality still varies on the asterisk-users list. > > I know the forums can have emails enabled that you can receive, and no, > that's not a proper replacement for a mailing list. > > GitHub Discussions aren't a proper mailing list, either, so ultimately I > think that will run into the same issue. GitHub has a lot of bells and > whistles but most of them aren't as built out as using the proper tool > they try to emulate. > > I think #3 is the right choice. It's using the right tool for the right > job. If you don't want to maintain the lists, have somebody else do it. > I do a combination of hosted and self-hosted for my own lists. Contrary > to the opinions of some, people, especially technical people, have not > "moved on" from mailing lists; they are widely used, and I get hundreds > of emails a day from them that I have a good workflow for. > > Most lists I'm on that used to be elsewhere (e.g. Yahoo Groups, Google > Groups, mailman, LISTSERV, other custom or independent platforms) have > now migrated to groups.io and are generally highly satisfied with it > compared to other platforms. It used to be completely free; it's now > free for lists under 100 members, or ones that are grandfathered in. As > the maintainer of several lists there and a member of many more, I've > been pretty happy with it. > > I'd suggest creating a list there and letting people on this list > manually opt into it, since there are probably a lot of people on > mailman that aren't active anymore. If it's under 100 members, it's > completely free anyways. If more than 100 people join, that means people > here *really* like mailing lists and find value in them, and I'm sure > Sangoma can afford $20 a month for it, if it really doesn't want to run > mailman lists anymore that badly, and $20 is a small price to keep > developers happy. > Your opinion has been noted. -- 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
Re: [asterisk-dev] Mailing List Future
The mailing lists have remained unchanged since deployed. For self hosting they would need to be completely redone on fresh infrastructure, fresh distro, fresh software, and hopefully things would possibly import. They'd also need to be updated to conform to current standards on sending so that that they don't appear as spam as often. (For me 25% of emails from the lists go to my spam currently and require manual involvement) For hosted we'd need support for over 2500+ subscribers for the -dev list if it were to be imported. For commercial entities we could possibly import, but for something like someone doing that work and effort and hosting I would not be comfortable providing such information, and people would need to sign up fresh again. It would also not be something I would be willing to spend money on due to the low use of the lists. Past that - can you explain why it's a bad idea? I've looked at the interactions for the past few years and while some have existed, they've been minimal over all. On Mon, Dec 4, 2023 at 8:28 AM Jaco Kroon wrote: > Hi, > > My 5c. Killing the dev list is a bad idea. > > Most developers could not care about having to poll forums. It also means > that stuff that would previously get an audience will now get none. > > github discussions are better than forums at least. > > May I inquire as to the problem you're having with the ML? Perhaps I > might be able to assist ... > > Kind regards, > Jaco > > On 2023/12/04 14:00, Joshua C. Colp wrote: > > Greetings all, > > Over the past few years, the use of the Asterisk mailing lists has > diminished, with far more conversation happening on the Asterisk community > forums[1]. The state of email, to ensure reliable delivery, has also gotten > more complicated - emails get caught by spam filters, etc.. To continue the > mailing lists would require a huge time and resource investment, for > minimal use. > > To that end, we’ve decided to discontinue the mailing lists effective > February 1st, 2024. > > This means the following: > > 1. Sending and receiving mailing list emails will no longer be possible. > 2. The list archives, however, will remain available. > > We need to decide the future of the asterisk-dev mailing list; > specifically, where to hold discussions in the future. There are a few > options: > > 1. A “Development” category exists on https://community.asterisk.org/ > already that can be used. > 2. We can use GitHub discussions, which keeps things with the GitHub > project. > 3. We can use a hosted mailing list elsewhere. > > We suggest option #2, since it keeps things with the GitHub project, which > is where everything development-related happens now regardless. This has > been set up and enabled already. > > If you have any input, now is the time to state it. > > Cheers, > > -- > Joshua C. Colp > Asterisk Project Lead > Sangoma Technologies > Check us out at www.sangoma.com and www.asterisk.org > > -- 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
[asterisk-dev] Mailing List Future
Greetings all, Over the past few years, the use of the Asterisk mailing lists has diminished, with far more conversation happening on the Asterisk community forums[1]. The state of email, to ensure reliable delivery, has also gotten more complicated - emails get caught by spam filters, etc.. To continue the mailing lists would require a huge time and resource investment, for minimal use. To that end, we’ve decided to discontinue the mailing lists effective February 1st, 2024. This means the following: 1. Sending and receiving mailing list emails will no longer be possible. 2. The list archives, however, will remain available. We need to decide the future of the asterisk-dev mailing list; specifically, where to hold discussions in the future. There are a few options: 1. A “Development” category exists on https://community.asterisk.org/ already that can be used. 2. We can use GitHub discussions, which keeps things with the GitHub project. 3. We can use a hosted mailing list elsewhere. We suggest option #2, since it keeps things with the GitHub project, which is where everything development-related happens now regardless. This has been set up and enabled already. If you have any input, now is the time to state it. Cheers, -- 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
[asterisk-dev] AstriDevCon 2024 Registration
Greetings all, AstriDevCon 2024 registration is now available[1]. It will be held on Wednesday, February 14th, 2024 in Fort Lauderdale, Florida the day before AstriCon as part of ITEXPO. It will also be available virtually, so I ask that either way you please submit your registration. We will also use the #asterisk-dev IRC channel on Libera for text chat. Time will be available if you would like to do a presentation about a subject, just ensure you select that on the registration form. As the day gets closer an email will be sent out with any further details including virtual attendance information. Even if you state that you will be attending physically you will still receive the virtual attendance information in case you have changed your mind or something has come up. Cheers, [1] https://docs.asterisk.org/Development/Roadmap/AstriDevCon/ -- 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
Re: [asterisk-dev] Permalinks including latest RC releases
On Mon, Oct 9, 2023 at 9:52 AM wrote: > On 10/9/2023 5:11 AM, Joshua C. Colp wrote: > > On Wed, Sep 27, 2023 at 6:31 PM > <mailto:aster...@phreaknet.org>> wrote: > > > > On 9/27/2023 5:26 PM, Andrew Latham wrote: > > > I would have to look deeper again but my kneejerk was this > > sounds like > > > "nightly" to me. Just chiming in quickly > > > > Yeah, it has the right connotation, though it might imply that these > > builds are put out more frequently than they really are... "monthly" > > would be more accurate at that. > > > > > > I would prefer "testing" as the name. Generally we don't refer to > > things as "stable" or "unstable", and involving dates in any way such > > as "monthly" is inviting people to ask "why hasn't this been updated? > > it's been a month". The release process is in Github and the repo, so > > a PR can be made to add such a thing by anyone. Once done we could > > update the website. I would not advise changing things such as sending > > it to Github for download, the bandwidth from the downloads server > > isn't a problem. > > Sounds good, I thought this might have involved more on the backend. I > submitted a PR to the CI repo in the only place I found any reference to > the -current suffix, so hopefully that does the trick. > When you say "update the website", are you referring to the downloads > server or the documentation (which is now also in Git)? > I'm referring to the asterisk.org downloads page which has sections for current releases, release candidates, and some descriptions of what the various things are. -- 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
Re: [asterisk-dev] Permalinks including latest RC releases
On Wed, Sep 27, 2023 at 6:31 PM wrote: > On 9/27/2023 5:26 PM, Andrew Latham wrote: > > I would have to look deeper again but my kneejerk was this sounds like > > "nightly" to me. Just chiming in quickly > > Yeah, it has the right connotation, though it might imply that these > builds are put out more frequently than they really are... "monthly" > would be more accurate at that. > I would prefer "testing" as the name. Generally we don't refer to things as "stable" or "unstable", and involving dates in any way such as "monthly" is inviting people to ask "why hasn't this been updated? it's been a month". The release process is in Github and the repo, so a PR can be made to add such a thing by anyone. Once done we could update the website. I would not advise changing things such as sending it to Github for download, the bandwidth from the downloads server isn't a problem. -- 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
Re: [asterisk-dev] AstriCon 2024: February 15th, 2024 - Fort Lauderdale, Florida
Responding to myself feels a bit odd, but that's fine! Just a reminder that registration is open, and the call for speakers is also still open for anyone who wishes to submit a talk proposal. Cheers, On Tue, Sep 5, 2023 at 10:14 AM Joshua C. Colp wrote: > Greetings all, > > The 25th anniversary of Asterisk is upon us! We’ll be celebrating it at > AstriCon 2024 held on February 15th, 2024 in Fort Lauderdale, Florida as > part of IT Expo. We’d love it if you would join us. You can register > here[1], and if you would like to speak you can submit a speaking proposal > by October 14th here[2]. I look forward to seeing many of you there! > > While not AstriCon specific I'm also doing a webinar next week called "The > Evolution of Asterisk" which will talk about the history, how Asterisk has > changed including philosophy on things, and give a glimpse into future > interests. You can register for that here[3]. I can promise I will say > words and they might mean things. > > For us developers AstriDevCon will be held physically the day before on > February 14th. I aim to have the entire Asterisk development team at > Sangoma present. For those unable to physically attend it will also be > virtually accessible. Details, including a signup page, will be provided > closer to it. Right now it's still months out and if past AstriDevCons have > taught me anything it's that we all forget we were doing it until the last > moment anyway and sometimes forget we even signed up and sign up multiple > times. :D > > Cheers, > > [1] https://www.astricon.net/ > [2] > https://docs.google.com/forms/d/e/1FAIpQLSeECYs1Bltl0wdfEF57ngGiorTAq79l5Du-Uyn_MuvAut57jw/viewform > [3] https://register.gotowebinar.com/register/969603661543016283 > > -- > Joshua C. Colp > Asterisk Project Lead > Sangoma Technologies > Check us out at www.sangoma.com and www.asterisk.org > -- 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
Re: [asterisk-dev] AstriCon 2024: February 15th, 2024 - Fort Lauderdale, Florida
On Mon, Sep 18, 2023 at 5:03 PM Henning Westerholt wrote: > Hello, > > > > quick question related to the "The Evolution of Asterisk" Webinar last > week, thank you for that. It was mentioned during the event that the > Webinar would be available for download later. I did not receive anything > so far, so I just wondered if its will be provided soon. > It's actually available on Youtube[1]. [1] https://www.youtube.com/watch?v=xlWFkVnc0pY -- 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
Re: [asterisk-dev] AstriCon 2024: February 15th, 2024 - Fort Lauderdale, Florida
Glad to hear it, and look forward to seeing you there! On Wed, Sep 13, 2023 at 7:04 AM Nir Simionovich wrote: > Hi All, > > After a relatively long hiatus and a very brief visit last year, Eric and > I are going to be back at ITExpo in full force. > Looking forward to meeting everybody. > > On Tue, Sep 5, 2023 at 7:37 PM Joshua C. Colp wrote: > >> On Tue, Sep 5, 2023 at 12:41 PM Fred Posner wrote: >> >>> +1 regarding valentine’s day… >>> >>> Also, is AstriCon just one day this year? >>> >> >> Yes, AstriCon is a single day this year. We're focusing on a solid base >> of a single day schedule. If all goes well then we'll look at expanding it >> to more days in the future yet again. >> >> -- >> 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 -- 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
Re: [asterisk-dev] AstriCon 2024: February 15th, 2024 - Fort Lauderdale, Florida
On Tue, Sep 5, 2023 at 12:41 PM Fred Posner wrote: > +1 regarding valentine’s day… > > Also, is AstriCon just one day this year? > Yes, AstriCon is a single day this year. We're focusing on a solid base of a single day schedule. If all goes well then we'll look at expanding it to more days in the future yet again. -- 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
Re: [asterisk-dev] AstriCon 2024: February 15th, 2024 - Fort Lauderdale, Florida
On Tue, Sep 5, 2023 at 12:08 PM Jared Smith wrote: > > > On Tue, Sep 5, 2023 at 10:06 AM Joshua C. Colp wrote: > >> The 25th anniversary of Asterisk is upon us! We’ll be celebrating it at >> AstriCon 2024 held on February 15th, 2024 in Fort Lauderdale, Florida as >> part of IT Expo. We’d love it if you would join us. You can register >> here[1], and if you would like to speak you can submit a speaking proposal >> by October 14th here[2]. I look forward to seeing many of you there! >> > > Thanks for sharing this, Josh. Has there been any consideration of not > doing AstriDevCon (and AstriCon itself) around Valentines Day? I imagine > I'm not the only one who would prefer not to travel that week to help > ensure domestic tranquility. > It's been brought up as a point, but for this year those are the dates. Regarding AstriDevCon I have also contemplated having a purely virtual get together a few months afterwards so there's less time in between such things, allowing those unable to physically or virtually attend during that day an opportunity to see others, meet others, talk, etc. -- 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
Re: [asterisk-dev] AstriCon 2024: February 15th, 2024 - Fort Lauderdale, Florida
On Tue, Sep 5, 2023 at 11:19 AM Fred Posner wrote: > Greetings. > > Is there any commitment from Sangoma to: > > 1) Take and upload videos of AstriCon talks? > Everyone involved in AstriCon from Sangoma is in agreement that this is a requirement and is being worked on. > 2) Provide any Asterisk/FreePBX activities/events outside of general > ITEXPO? > I have no commitments on any such things currently, but can certainly bring it up as a request with interest. -- 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
[asterisk-dev] AstriCon 2024: February 15th, 2024 - Fort Lauderdale, Florida
Greetings all, The 25th anniversary of Asterisk is upon us! We’ll be celebrating it at AstriCon 2024 held on February 15th, 2024 in Fort Lauderdale, Florida as part of IT Expo. We’d love it if you would join us. You can register here[1], and if you would like to speak you can submit a speaking proposal by October 14th here[2]. I look forward to seeing many of you there! While not AstriCon specific I'm also doing a webinar next week called "The Evolution of Asterisk" which will talk about the history, how Asterisk has changed including philosophy on things, and give a glimpse into future interests. You can register for that here[3]. I can promise I will say words and they might mean things. For us developers AstriDevCon will be held physically the day before on February 14th. I aim to have the entire Asterisk development team at Sangoma present. For those unable to physically attend it will also be virtually accessible. Details, including a signup page, will be provided closer to it. Right now it's still months out and if past AstriDevCons have taught me anything it's that we all forget we were doing it until the last moment anyway and sometimes forget we even signed up and sign up multiple times. :D Cheers, [1] https://www.astricon.net/ [2] https://docs.google.com/forms/d/e/1FAIpQLSeECYs1Bltl0wdfEF57ngGiorTAq79l5Du-Uyn_MuvAut57jw/viewform [3] https://register.gotowebinar.com/register/969603661543016283 -- 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
Re: [asterisk-dev] Pickup peculiarities
On Sat, Sep 2, 2023 at 7:33 PM wrote: > * Semantically, should the above scenario work with the builtin pickup > functionality, or is it by design that this case is excluded, e.g. > channels with a PBX but not yet answered (I'm guessing no, since how > would one distinguish between valid cases such as these, and most > any other? After all, to the core, it's a channel that's executing > dialplan) > The pickup implementation is not written for such a scenario. It requires a dialed channel to exist so the channel picking up can take its place, otherwise you are essentially doing the ChannelRedirect you mention to rip the calling channel out of its existing flow which the code doesn't do, likely since it predates even having the ability to set up a bridge to allow the exchange of audio. It was written for a particular use case. > * What would be the prototypical "Asterisk way" of doing the above > scenario? Something like ChannelRedirect() should work, but I mean > more within the bounds of the pickup construct (and maybe there > isn't any, just want to confirm I haven't missed something). Put > another way, how would you do the above, in the simplest way > possible? (high level, no code necessary) > There isn't for pickup. > * I'm thinking that one way to accomplish this given the way that > pickup is would be to have some kind of dummy "sink" channel driver, > e.g. something that can be called, but will never actually answer, > and can't do anything useful. This should make the above scenario > function without creating any further additional channels or ringing > any "real" endpoints. Local channels would not suffice, because they > begin executing dialplan immediately. The dummy channel driver > wouldn't do that, or really do anything, it would just be a valid > target for Dial() that would satisfy the properties expected by > pickup.c, to allow a channel currently ringing the dummy channel > driver to be picked up. A toy example: > A Local channel should work, because there are two of them and the one you pick up (;1) should be the one that is not executing dialplan. The dialplan one (;2) just has to do a Wait(360) or something. -- 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
Re: [asterisk-dev] issues-archive.asterisk.org is now available for preview
On Fri, Aug 4, 2023 at 2:38 PM 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, 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? > > 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. > All contributions need to be under the new CLA. The previous signed CLA is no longer valid, even though the changes may have been submitted using it. Original authors can use the archive site to get their old patches if they want and submit under the new CLA. -- 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
Re: [asterisk-dev] Cannot select IMAP storage in make menuselect
On Tue, Aug 22, 2023 at 5:03 PM Hoggins! wrote: > Oh nevermind, it must have been a long time since it doesn't exist > anymore, I just selected the appropriate modules to load in > /etc/asterisk/modules.conf and voilà. > > Though I wonder if it might not be time to refresh the dependencies of > this feature, especially the UW-IMAP libs. They are not maintained > anymore and eg. they don't support SNI for TLS like most IMAP clients do > nowadays. > If someone wanted to take on such a project and submit a PR then it would be reviewed. From a general perspective despite the functionality being in app_voicemail it is not treated as core supported by Sangoma. -- 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
Re: [asterisk-dev] Gerrit offline? -> What about the future of svn?
On Thu, Aug 17, 2023 at 1:35 PM Michael Maier wrote: > Hello George, > > On 17.08.23 at 14:09 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. > > Another question: > During build (of the (older) rpm src packages only?), svn is necessary. > Will > svn.digium.com still be online? > Some source code in contrib is still downloaded using SVN and will remain available, even after we switch that to using Git. If you are referring to other repositories such as asterisk itself, no. It should either be mirrored or the dependency on the repo changed in the build process. -- 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
Re: [asterisk-dev] [External] Re: Final Preview: docs.asterisk.org
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. -- 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
Re: [asterisk-dev] [External] Re: Final Preview: docs.asterisk.org
On Wed, Aug 9, 2023 at 11:12 AM Floimair Florian wrote: > Just to be precise: By “template” I meant the “Material theme” that is > used. > > I honestly don’t like it for exactly that reason. To me it seems this is > optimized for vertical displays rather (e.g. mobiles) rather than being > truly responsive. > I can't find anything quickly within the reference documentation for the material theme[1] or mkdocs[2] for it explicitly, aside from overriding HTML/CSS probably. If someone wanted to explore that then they could locally and propose it as a PR. The same goes for an alternative theme that we should use instead. [1] https://squidfunk.github.io/mkdocs-material/reference/ [2] https://www.mkdocs.org/user-guide/ -- 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
Re: [asterisk-dev] issues-archive.asterisk.org is now available for preview
On Fri, Aug 4, 2023 at 4:14 PM George Joseph wrote: > >> >> 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. > The patches can not be taken as-is, the creator has to sign the new CLA. All old signatures are no longer valid. -- 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
[asterisk-dev] Asterisk 21 Branch Creation Reminder
Greetings all, Just a friendly reminder that the Asterisk 21 branch will be created next week. No release will occur of it yet however changes that would normally be cherry picked into 18 and 20 should also be cherry picked into it. A subsequent email will be sent once the branch creation is complete and it is available. For further information on this process consult the documentation site[1]. [1] https://docs.asterisk.org/About-the-Project/Asterisk-Versions/ -- 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
Re: [asterisk-dev] Final Preview: docs.asterisk.org
On Fri, Jun 30, 2023 at 8:52 AM Olivier wrote: > IMHO, having per-Asterisk-version doc is very useful feature of > current wiki for those maintening an heterogeneous set of Asterisk > instances or wanting to study differences between versions. > The Asterisk Latest (20) at the top of the docs site is a menu that can be used to switch between different versions and display the specific reference documentation for 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
Re: [asterisk-dev] Deprecating users.conf
On Fri, Jun 30, 2023 at 8:45 AM wrote: > Hi folks, > > I've put up a PR to deprecate users.conf[1], following a > discussion earlier this year about this, but I think that was on IRC so > wanted to discuss here as well. > I'm fine with removing 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
Re: [asterisk-dev] Issue with PJSIP contacts being "unavailable"
On Tue, Jun 27, 2023 at 7:33 PM wrote: > Thanks - just to clarify, if such a connection *isn't* found, this won't > help me right now? It would still use the default transport even with > rewrite_contact=yes? > If the transport goes down in that scenario, then the Contact should get removed because it is an ephemeral port and you can't establish an outbound connection to it. > > In that case, I'm thinking the new option would add on to this by > extending that behavior to if there isn't an active connection and it > needs to set up a new one. Basically "use the contact to determine the > transport, unconditionally" is essentially what it would do. > The scenario where this would only work is if rewrite_contact is set to no, and a Contact is bound from a REGISTER. > > I guess for devices that don't register, you wouldn't necessarily have a > contact so maybe that's why this isn't done all the time? But those are > probably the cases where specifying a transport explicitly would > probably make more sense anyways, and I'm not concerned about those, > only things that register and as such a contact would always be available. > -- 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
Re: [asterisk-dev] Issue with PJSIP contacts being "unavailable"
On Tue, Jun 27, 2023 at 7:18 PM wrote: > On 6/27/2023 6:07 PM, Joshua C. Colp wrote: > > > > I'm not sure what exactly you are referring to with "using the > > transport used for registration". If "rewrite_contact" is set to yes > > then the existing active connection should get used. If you are > > referring to Asterisk establishing a new outgoing connection to the > > registered Contact, then as long as it is optional and doesn't break > > other behavior fine. > > Basically, suppose a device registers on a port, associated with some > configured transport. > > The reason I'm doing this now is that initially, calls out *to* devices > would just use the default transport (the first one configured, or > something like that). Specifying a transport= in the endpoint explicitly > ensured they'd only use the appropriate one. The problem still remains > though that we don't necessarily know what transport a device is going > to use in advance, and it could also change at any time. > > I don't know if this would be a "new" outgoing connection to the > contact or not... I was noticing this issue with outbound calls to > devices using the wrong transport (e.g. an ATA registered using TLS, and > Asterisk would call the device using UDP, on a different port). The > description for "rewrite_contact" says "Allow Contact header to be > rewritten with the source IP address-port" which doesn't really clarify > that, but if that means it'll always use the same transport out to the > device that the device initiated a connection on, no matter what, then I > think that will do the trick. I just want Asterisk to go along with > whatever the device wants to do. If there's a gap with "rewrite_contact" > then I guess a new option is still needed to do the other half. > The source IP address, port, and transport type become the Contact. The Contact target is used for requests, and PJSIP looks for an existing active connection meeting that criteria. If such a connection is found then it is reused. -- 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
Re: [asterisk-dev] [asterisk-users] Issue with PJSIP contacts being "unavailable"
On Tue, Jun 27, 2023 at 6:57 PM wrote: > On 6/27/2023 7:29 AM, Joshua C. Colp wrote: > > On Tue, Jun 27, 2023 at 8:22 AM > <mailto:aster...@phreaknet.org>> wrote: > > > > > > > > > > Trace from an "unavailable" ATA (not working correctly): > > https://paste.interlinked.us/iz07sapwrb.txt > > > > Trace from an "available" ATA (working correctly): > > https://paste.interlinked.us/ocutyjslmg.txt > > > > > > The "unavailable" ATA no longer has a working TLS connection to > > Asterisk, resulting in OPTIONS failing, and going unreachable, and > > eventually the Contact going away. Actually examining the TLS side > > would be needed. > > Thanks, Josh. Further troubleshooting supports that as being the problem > as well. I'll have to figure out what's changed with that. > > Replying to the dev list since this is not directly related, but it > reminds me of a previous conversation we had about chan_pjsip > automatically using the transport used for registration. This is not > currently done; what would be your thoughts on perhaps adding an option > to do this automatically? Currently, the provisioning system directs > devices to the proper port based on the security options in the system > and the TLS capabilities of the device. When something registers, I keep > track of the port on which a device registers using AMI, logging it to a > database. We have one port for UDP, one for TLS 1.0, and one for TLS 1.2 > (none for plain TCP at the moment). chan_sip isn't as flexible so the > process is more straightforward there: just use the TLS 1.0 port if TLS > is enabled, but for PJSIP, the transpiler assigns a transport based on > the registration port. In theory, a client can toggle the transport for > registration (TLS vs UDP), but that alone doesn't really work since > pjsip.conf needs to be in agreement with that. It would be slightly more > seamless if it could just sync up somehow, as right now I have to > manually retranspile any time this occurs, and it seems kind of clunky > to have to do all this for transports to work properly. > > Would there be any consideration or problem with potentially doing > something like this? After all, it seems like there's a 1:1 mapping and > it should be fairly straightforward. Kind of like the "line" option for > registrations, it would help in making things "just work" more of the > time... > I'm not sure what exactly you are referring to with "using the transport used for registration". If "rewrite_contact" is set to yes then the existing active connection should get used. If you are referring to Asterisk establishing a new outgoing connection to the registered Contact, then as long as it is optional and doesn't break other behavior fine. -- 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
Re: [asterisk-dev] New documentation web site
On Wed, Jun 21, 2023 at 10:18 AM Olivier wrote: > Hello, > > One very useful feature from previous wiki.asterisk.org is giving top > level/direct access to per version reference doc (see [1 as an > example]). > I hope new site will also bring this feature. > That is what George is working on now. That is automatically generated reference documentation from the XML in Asterisk. Only content written by a person is on the docs site now. -- 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
Re: [asterisk-dev] New Asterisk Documentation website is available for preview
On Tue, Jun 20, 2023 at 9:53 PM wrote: 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...) > It does work, but the upstream provider was having issues last night so from a network perspective it was unreachable sporadically. We haven't touched anything in the old Atlassian stack. -- 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
Re: [asterisk-dev] New Asterisk Documentation website is available for preview
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. -- 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
Re: [asterisk-dev] New Asterisk Documentation website is available for preview
On Tue, Jun 20, 2023 at 11:57 AM Andrew Latham wrote: > Ack, so for everyone we should: > > * add issues at https://github.com/asterisk/documentation/issues > * in a bit after the initial gaps are filled we can do patches at > https://github.com/asterisk/documentation/pulls > * readme at https://github.com/asterisk/documentation/blob/main/README.md > You can immediately do pull requests against the manually written content. -- 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
Re: [asterisk-dev] CLA Update (Requires Resigning)
On Mon, Jun 12, 2023 at 5:37 AM Henning Westerholt wrote: > Hello, > > > > thanks for the update, the old patent phrase was indeed quite broad, > noticed that during review. This should capture the intent better. > > I understand that it needs re-signing. Does this also mean that the old > CLA is now voided for all organisations/people that signed it previously > from a contractual point of view? > No, it is not voided. > > > Just a suggestion, maybe it would be advantageous in case of future major > changes to the CLA to have a quick review session with the community > before, like on this list. Just as a chance to save the different involved > parties some time and effort. > I'll take this into consideration if it occurs. If there are ever concerns regarding the CLA as it stands, send me an email and I can loop in the appropriate party from Sangoma legal to discuss. -- 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
[asterisk-dev] CLA Update (Requires Resigning)
Greetings all, Just a heads up that after discussion with an outside company wanting to contribute I've updated the CLA to include some additional language around patents after discussions between them and the Sangoma legal team. That part now reads: Developer hereby grants Sangoma and its successors and assigns a perpetual, worldwide, royalty-free, irrevocable, non-exclusive, sublicenseable and transferable license under any patent Developer owns or controls, now or in the future, to make, have made, use, sell, offer for sale, or import Submissions or any modifications thereof, including without limitation any combinations of the Submissions or modifications thereof with software, technology or services of Sangoma; but such license shall only apply to those patent claims licensable by Developer that are necessarily infringed by the Submissions alone or by the combination of the Submission(s) with the Project to which the Submission was submitted. This does require re-signing the CLA, but like previously it is automatically accepted. There's no further planned CLA changes on the horizon but if it does occur I'll send an email again. Cheers, -- 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
Re: [asterisk-dev] GitHub: One Month Update
On Tue, Jun 6, 2023 at 8: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? > The code contribution process is documented on the wiki[1] including signing the contributor license agreement[2] which is listed under the PR checks as its own check. [1] https://wiki.asterisk.org/wiki/display/AST/Code+Contribution [2] https://wiki.asterisk.org/wiki/display/AST/Code+Contribution#CodeContribution-NewContributorLicenseAgreement -- 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
Re: [asterisk-dev] DAHDI and Asterisk
On Thu, May 18, 2023 at 12:39 PM wrote: > On 5/18/2023 11:09 AM, Joshua C. Colp wrote: > > On Thu, May 18, 2023 at 12:05 PM > <mailto:aster...@phreaknet.org>> wrote: > > > > Wanted to float a question here for the Asterisk core team, that has > > been discussed amongst several other Asterisk/DAHDI developers a bit. > > > > As we all know, the DAHDI project has been neglected the past few > > years > > and it does not appear that there is any team at Sangoma that is > > actively working on it or cares about it. Sangoma has repeatedly > > failed > > to take responsibility for DAHDI and is not letting the community > > maintain it either, i.e. PRs are not being merged, build failures are > > not addressed. Numerous developers, myself included, have long been > > maintaining external patch sets[1] or forks[2] to address this. > > > > At this point, it is unrealistic to expect the DAHDI project in its > > current form to ever really get back on track. Some distros I'm told > > have already abandoned Sangoma and now use the osmocom fork as their > > upstream for packages. Most people have been using these methods to > > build DAHDI, rather than using the Sangoma tarballs. > > > > Merely maintaining patch sets or forks is not a long term > > solution. Many > > new Asterisk features require DAHDI changes, and thus require > > patches to > > be maintained for multiple projects. Even if the Asterisk side > > could be > > merged in fine, some changes may require or depend on a DAHDI > > change to > > work properly. Over time, patches begin to conflict with or step > > on each > > other. DAHDI does not live in a bubble and has impacts that ripple > > out > > to other things, like Asterisk. > > > > Since DAHDI has no active maintainer currently, I wanted to float a > > couple ideas here to remedy the situation, in order of feasibility (I > > think): > > > > 1. Would it be possible for the DAHDI project to be moved to fall > > under > > the scope of the Asterisk project? e.g. similar to libpri. The > > Asterisk team would not need to actively do anything with it, but > > just merge changes into it as it does for libpri, for example > > (kind > > of like extended support). I think this would make the most sense > > because fundamentally, DAHDI is part of the Asterisk ecosystem. > > Asterisk has a dependence on DAHDI and so bringing that > dependency > > in house makes sense since it eliminates friction. For > > example, this > > change[3] stalled solely because nobody is merging PRs into > DAHDI. > > If the Asterisk team was able to merge DAHDI changes, problem > > solved, and then Asterisk changes aren't stalled because DAHDI is > > stalled. > > > > > > No. This is not something that the Asterisk project or Asterisk team > > will take on. We're trying to reduce the amount of responsibilities > > (such as reducing the amount of infrastructure we maintain and manage) > > we have to be able to focus on Asterisk itself, taking on new ones > > particularly in areas we have no expertise in is not something we will > > be doing. > > Understood. > > In this case, is there any possibility of accepting changes that have > dependencies on DAHDI functionality that may not be present in the most > recent Sangoma tarball, but exist in maintained versions of DAHDI? e.g. > conditionally guarded if needed so that there aren't build issues, > regardless of which version of DAHDI is used underneath. Such changes > would be effective only when they actually exist and are supported by > the underlying DAHDI version. Or is the Asterisk project restricted to > using only the official Sangoma version, even though it's broken and > stagnant? > > For example, this change[1] doesn't even have any build dependencies on > DAHDI. It compiles and runs fine regardless. It will work if the > underlying DAHDI change is present, and do nothing if it is not. Is that > still a blocker on merging this? As Kevin said on the review, "Unless of > course you're thinking the DAHDI changes may be not go in for a very > long time, if at all and ppl will just manually apply patches > themselves." People using this feature are going to do just that, so in > practice there isn't a compatibility issue. Are there any circumstances > under which patches like these may
Re: [asterisk-dev] DAHDI and Asterisk
On Thu, May 18, 2023 at 12:05 PM wrote: > Wanted to float a question here for the Asterisk core team, that has > been discussed amongst several other Asterisk/DAHDI developers a bit. > > As we all know, the DAHDI project has been neglected the past few years > and it does not appear that there is any team at Sangoma that is > actively working on it or cares about it. Sangoma has repeatedly failed > to take responsibility for DAHDI and is not letting the community > maintain it either, i.e. PRs are not being merged, build failures are > not addressed. Numerous developers, myself included, have long been > maintaining external patch sets[1] or forks[2] to address this. > > At this point, it is unrealistic to expect the DAHDI project in its > current form to ever really get back on track. Some distros I'm told > have already abandoned Sangoma and now use the osmocom fork as their > upstream for packages. Most people have been using these methods to > build DAHDI, rather than using the Sangoma tarballs. > > Merely maintaining patch sets or forks is not a long term solution. Many > new Asterisk features require DAHDI changes, and thus require patches to > be maintained for multiple projects. Even if the Asterisk side could be > merged in fine, some changes may require or depend on a DAHDI change to > work properly. Over time, patches begin to conflict with or step on each > other. DAHDI does not live in a bubble and has impacts that ripple out > to other things, like Asterisk. > > Since DAHDI has no active maintainer currently, I wanted to float a > couple ideas here to remedy the situation, in order of feasibility (I > think): > > 1. Would it be possible for the DAHDI project to be moved to fall under > the scope of the Asterisk project? e.g. similar to libpri. The > Asterisk team would not need to actively do anything with it, but > just merge changes into it as it does for libpri, for example (kind > of like extended support). I think this would make the most sense > because fundamentally, DAHDI is part of the Asterisk ecosystem. > Asterisk has a dependence on DAHDI and so bringing that dependency > in house makes sense since it eliminates friction. For example, this > change[3] stalled solely because nobody is merging PRs into DAHDI. > If the Asterisk team was able to merge DAHDI changes, problem > solved, and then Asterisk changes aren't stalled because DAHDI is > stalled. > No. This is not something that the Asterisk project or Asterisk team will take on. We're trying to reduce the amount of responsibilities (such as reducing the amount of infrastructure we maintain and manage) we have to be able to focus on Asterisk itself, taking on new ones particularly in areas we have no expertise in is not something we will be doing. I am aware that such an email has been sent to parties inside of Sangoma, and have given my opinion to them on the situation. I'm not in a position to provide any further insight into that or decide for them. Any decisions has to come from them. -- 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
Re: [asterisk-dev] PLEASE CHECK THE RC RELEASE ARTIFACTS!!
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. -- 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
Re: [asterisk-dev] Removing configure from tree
I have created a Github issue[1] for this effort which strikes a balance between impact to existing users, and the removal of the generated configure script: 'configure' will be removed from the mainline branches (18, 20, master) Documentation will be updated with instructions for running bootstrap.sh in this scenario Makefile will state that configure needs to be run if it has not already been done and is invoked The release process will be updated to run bootstrap.sh and produce the configure script, this configure script will be placed in the tag and release tarball This does not add a "dist" target, and the configure script remains in the tags. This allows us as developers to not have to worry about committing configure or conflicts that may arise in the generated script, but is least impactful to users. [1] https://github.com/asterisk/asterisk/issues/70 -- 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
Re: [asterisk-dev] Considering changes to the Change Logs
On Tue, May 9, 2023 at 8:17 AM George Joseph wrote: > > > 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. > That'd be dandy. -- 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
Re: [asterisk-dev] Considering changes to the Change Logs
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? > > 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. -- 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
Re: [asterisk-dev] Removing configure from tree
On Thu, May 4, 2023 at 7:15 AM Jaco Kroon wrote: > The norm for many/most projects seem to be: > > 1. No generated files in git, ever, even for tags/release branches. In > this case configure.ac yes, configure no. > > 2. Generated files in archives, ie, in the downloadable > asterisk-x.y.z.tar.gz file there should be a ./configure. > > For me this makes sense since MOST users will simply download the tgz and > move on with their lives, thus no change to their workflow. > > For developers (checking out from git), surely running an extra > ./bootstrap.sh prior to ./configure isn't too much to ask? > > Thus there is a change required to the release process for generating the > archive (which is where github seems to have a pitfall in that automated > download archives won't work as expected unless there is an option to first > run a script on the checked out tree) to first run ./bootstrap.sh prior to > creating the archive. > Some users do get tags from git, instead of downloading the tarball. I don't think changing that is really worth it. Adding generation of configure to the release process is minor. It would only be if main branches (18, 20, master) were checked out that you'd need to do it manually. -- 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
Re: [asterisk-dev] Removing configure from tree
On Thu, May 4, 2023 at 6:45 AM Dennis Buteyn wrote: > On 5/3/23 22:48, Joshua C. Colp wrote: > > Greetings all, > > Sean Bright brought up on IRC the removal of configure from git. This may > be impactful since some users (not necessarily developers) may not > understand the build system when building from branches (not tags or > releases) and become confused when configure is not present which is why I > disagreed with doing so on IRC. I'm curious though what others think of > such a change. I think to be acceptable it would need: > > 1. To regenerate configure if configure.ac has been changed, so that > developers don't have a stale configure > 2. To provide instructions if configure is not present and "make" is run, > I'm on the fence on automatically running it > 3. Releases (and tags) would need to have a generated configure in them > > Thoughts? > > Sean is correct that configure should not be present in the source tree > because it contains build-environment specific parameters. For the same > reason, Makefile should also not be present in the source tree. > I'm not sure what build-environment specific parameters you are referring to, unless you mean the version of autoconf on the system. The issue Sean saw was that if developers generated the configure using different autoconf versions, the output would be different and could result in large reviews. >From an actual non-developer people who use Asterisk perspective, to the best of my knowledge we've never seen any issues with either the checked in configure. The logic certainly, but that's not the result of the process of producing the configure script but the backing autoconf logic that was written by someone. As for Makefiles, the Asterisk ones are not generated. They're written manually. Are you also proposing changing the build system so those are now generated? Running make without configure being present would mean Makefile is also > not present. As make is (fortunately) not sentient and does not know that > Makefile is to be generated, it would reasonably state that no Makefile has > been found. I'm not sure how one would convey additional instructions to > users in such a case. > > Many Automake/Autotools projects provide some bootstrap script to generate > configure from configure.ac, with step-by-step instructions on how to > build (bootstrap, configure, make). > > To make building as simple as possible, instructions for building from a > branch, tag or any other source should be identical. > That's a fundamentally breaking change if tags and releases do not contain a configure already. The benefit would need to be large enough to justify it. What additional benefits are there? -- 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
[asterisk-dev] Removing configure from tree
Greetings all, Sean Bright brought up on IRC the removal of configure from git. This may be impactful since some users (not necessarily developers) may not understand the build system when building from branches (not tags or releases) and become confused when configure is not present which is why I disagreed with doing so on IRC. I'm curious though what others think of such a change. I think to be acceptable it would need: 1. To regenerate configure if configure.ac has been changed, so that developers don't have a stale configure 2. To provide instructions if configure is not present and "make" is run, I'm on the fence on automatically running it 3. Releases (and tags) would need to have a generated configure in them Thoughts? -- 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
Re: [asterisk-dev] IMPORTANT: GitHub Cherry-Pick Policy Change
On Mon, May 1, 2023 at 8:47 AM Sebastian Gutierrez wrote: > George, > > Maybe using GitHub discussions is a better way to have this information > and allows everybody to see and comment in a better way than mailing lists. > We're split across the mailing lists and IRC currently, adding GitHub discussions into the mix seems like adding a third option to things and spreading this out even further. It's certainly possible that is where developer stuff will go in the future, but whilst we try to stabilize our GitHub usage I'm hesitant to throw more change into the mix. Does anyone else have any thoughts? >From a user perspective that already lives primarily on the forum already, and that's not going to change. -- 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
Re: [asterisk-dev] Sign the new CLA at any time...
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
Re: [asterisk-dev] Sign the new CLA at any time...
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. -- 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
Re: [asterisk-dev] GitHub: Side Note: What makes us "special"?
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. -- 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
Re: [asterisk-dev] Call transfer (302 Moved temporarily) not working with pjsip
On Tue, Apr 4, 2023 at 2:17 PM Joshua C. Colp wrote: > On Tue, Apr 4, 2023 at 2:11 PM Karsten Wemheuer wrote: > >> >> I filed an issue about this. No one has worked on the issue yet, so I >> would start with this. Can anyone help me get started? >> >> > You'd need to be specific about what you are seeking help with. The 302 > code is in res_pjsip_diversion.c, NAT handling is in res_pjsip_nat.c. There > are instructions on the wiki[1] for Gerrit to put things up for code review. > > Sorry, this is the outgoing 302 case which is in chan_pjsip.c -- 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
Re: [asterisk-dev] Call transfer (302 Moved temporarily) not working with pjsip
On Tue, Apr 4, 2023 at 2:11 PM Karsten Wemheuer wrote: > > I filed an issue about this. No one has worked on the issue yet, so I > would start with this. Can anyone help me get started? > > You'd need to be specific about what you are seeking help with. The 302 code is in res_pjsip_diversion.c, NAT handling is in res_pjsip_nat.c. There are instructions on the wiki[1] for Gerrit to put things up for code review. [1] https://wiki.asterisk.org/wiki/display/AST/Gerrit+Usage -- 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
Re: [asterisk-dev] Infrastructure move to GitHub
On Mon, Apr 3, 2023 at 6:06 PM James Finstrom wrote: > I assume this is asterisk/asterisk on github The about still > reflects it as a mirror > When the move actually occurs that will be updated. It remains a mirror until the move. -- 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
Re: [asterisk-dev] chan_sip realtime port with host dynamic and defaultip
On Wed, Mar 15, 2023 at 11:49 AM Sean Bright wrote:
> On 3/15/2023 9:43 AM, Marcin Groszek wrote:
> > Recently I discovered that when realtime is used the port is ignored
> > when used with host=dynamic and defaultip=x.x.x.x.
> >
> > if (port && !realtime && peer->host_dynamic) {
> > ast_sockaddr_set_port(>defaddr, port);
> > } else if (port) {
> > ast_sockaddr_set_port(>addr, port);
> > }
> >
> > Is there a reason why port value is ignored if the peer is setup in
> > realtime?
>
> The `!realtime` check was added in 2005¹, the commit message is fairly
> vague, and I am not able to find bug #3286 it refers to.
>
It's here[1] which doesn't really help.
[1] https://issues.asterisk.org/jira/browse/ASTERISK-3224
--
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
Re: [asterisk-dev] Call transfer (302 Moved temporarily) not working with pjsip
On Thu, Mar 2, 2023 at 1:00 PM Karsten Wemheuer wrote: > Hi Joshua, > > Am Donnerstag, dem 02.03.2023 um 12:44 -0400 schrieb Joshua C. Colp: > > On Thu, Mar 2, 2023 at 12:37 PM Karsten Wemheuer wrote: > > Hi Joshua, > > thank You, for answering. > > Am Donnerstag, dem 02.03.2023 um 09:17 -0400 schrieb Joshua C. Colp: > > On Thu, Mar 2, 2023 at 9:04 AM Karsten Wemheuer wrote: > > Hi *, > > Maybe I found a small bug or I am doing something wrong. > > When I do a "Transfer" on a call that arrives via PJSIP, Asterisk sends > a "302 Moved Temporarily" to perform the transfer. > > > What version of Asterisk? What is the precise transport configuration? > > As written below it was Version 18. The exact version is 18.16.0. > > > In the future please always provide the precise Asterisk version. It's > important, as code changes. > > What is the precise transport configuration in PJSIP? > > Transport section is below: > > [transport-tcp] > type = transport > protocol = tcp > bind = 0.0.0.0:25060 > external_media_address = 91.2.166.143 > external_signaling_address = 91.2.166.143 > local_net = 10.0.1.0/24 > local_net = 192.168.10.0/24 > local_net = 169.254.0.0/24 > tos = 96 > allow_reload = no > Then the Contact replacement for NAT purposes may not be specific enough. File an issue[1] however ALSO include a full SIP trace. [1] https://issues.asterisk.org/jira -- 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
Re: [asterisk-dev] Call transfer (302 Moved temporarily) not working with pjsip
On Thu, Mar 2, 2023 at 12:37 PM Karsten Wemheuer wrote: > Hi Joshua, > > thank You, for answering. > > Am Donnerstag, dem 02.03.2023 um 09:17 -0400 schrieb Joshua C. Colp: > > On Thu, Mar 2, 2023 at 9:04 AM Karsten Wemheuer wrote: > > Hi *, > > Maybe I found a small bug or I am doing something wrong. > > When I do a "Transfer" on a call that arrives via PJSIP, Asterisk sends > a "302 Moved Temporarily" to perform the transfer. > > > What version of Asterisk? What is the precise transport configuration? > > As written below it was Version 18. The exact version is 18.16.0. > In the future please always provide the precise Asterisk version. It's important, as code changes. What is the precise transport configuration in PJSIP? -- 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
Re: [asterisk-dev] Call transfer (302 Moved temporarily) not working with pjsip
On Thu, Mar 2, 2023 at 9:04 AM Karsten Wemheuer wrote: > Hi *, > > Maybe I found a small bug or I am doing something wrong. > > When I do a "Transfer" on a call that arrives via PJSIP, Asterisk sends > a "302 Moved Temporarily" to perform the transfer. > What version of Asterisk? What is the precise transport configuration? > Unlike chan_sip, the contact header is set different and maybe > incorrectly with PJSIP: > > chan_sip: >Contact: Transfer > > pjsip: >Contact: > > The difference are domain (chan_sip) vs. local IP address (pjsip) and > the additional (wrong?) port number. The IP address is the one of my > router, but the port number should be 25060, because asterisk is > configured to use this port. > > The transfer works with asterisk 11 and chan_sip. It does not work with > pjsip and asterisk 18. My provider does not accept the transfer done > with pjsip. Either the provider expects the domain in the contact > header or the error is in the wrong port number. > > Is this a bugf or how to use transfer application in combination with > pjsip? > For questions like this in the future please use either the asterisk-users mailing list or the community forum[1]. [1] https://community.asterisk.org/ -- 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
Re: [asterisk-dev] Running channels through dialplan on attended transfer
On Thu, Mar 2, 2023 at 7:04 AM Nikša Baldun wrote: > I understand, but autoservice and AGI wouldn't be running on the same > channel at the same time. And I assume that once the transfer is completed, > original AGI call will be terminated. If I am wrong in that assumption, > then I am in trouble. > > It should be noted that, while you say that AGI can't run twice on the > same channel, the the second AGI call does go through and everything works > as intended. I am just worried that this will cause some problem down the > line, and I would like to avoid the debug message. > While it works you are in undefined may or may not work or continue to work territory, as it violates a fundamental aspect of things - so you do indeed need to ensure two threads are not servicing the same channel at the same time. -- 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
Re: [asterisk-dev] Running channels through dialplan on attended transfer
On Thu, Mar 2, 2023 at 5:50 AM Nikša Baldun wrote: > Hi Joshua, > > thanks for the answer. Meanwhile, I've found that the debug message about > competing threads happens because I am using Fast AGI, and two threads call > AGI from the same channel. I assume this could potentially be resolved if I > call ast_app_exec_sub AFTER the attended transfer has already been > completed (and, based on your input, autoservice should be used). This is > trickier to implement, but I'll try. > Fundamentally two threads can't service the same channel at the same time. So autoservice and AGI can't run on the same channel at the same time, just like AGI can't run twice on the same channel at the same time. It's the equivalent of having two people tell you what to do at the same time. -- 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
[asterisk-dev] Mailing Lists
Greetings, As some of you noticed (and likely some didn't) the mailing lists were down for a period of time at the start of this year, and over the past week. We believe we've stabilized things to allow them to continue to run and will continue to monitor. Sometime this year I will explore moving the mailing lists to a different solution for those who still prefer mailing lists, which should also improve deliverability. When this begins and occurs I will start discussions on the existing mailing lists. For user facing questions I do urge people to use the community forums[1] which have effectively taken over for discussions. They are much more active with both questions and answers, and are easier to search and find information on. You can set it up to behave as a mailing list if you want including replying using email. For developer discussion I have created a category there[2] if we decide to use it, but we haven't traditionally and don't have to. It's more a placeholder just in case, and as sometimes developer level questions do appear I will be categorizing them as such. Cheers, [1] https://community.asterisk.org/ [2] https://community.asterisk.org/c/asterisk/development/45 -- 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
Re: [asterisk-dev] Running channels through dialplan on attended transfer
On Tue, Feb 28, 2023 at 9:35 AM Nikša Baldun wrote: > Hello, > > information available on channels involved in attended transfer is > inadequate for my purposes, so I have created a function which sets some > variables on these channels, and also runs transferee and transfer target > through dialplan. It works, but I am unsure that I did it correctly. Two > specific questions of note: > > 1. Do I have to lock channels before setting variables? I've seen it done > in many places, but if I do, I get debug messages like: "Thread LWP 822 is > blocking 'PJSIP/444-004b', already blocked by thread LWP 6204 in > procedure ast_waitfor_nandfds". > The pbx_builtin_setvar_helper function locks the channels underneath. > > 2. Do I have to set autoservice_chan parameter in ast_app_exec_sub? I > don't know what autoservice is. > You don't HAVE to. Autoservice is used when you want to run a potentially long running operation and still properly service (handle received audio, discarding it, amongst things) the channel. Not servicing the channel means stuff would just back up. The parameter exists for cases where 2 channels are being handled by the thread - one should execute the Gosub, one should go to autoservice to be handled. > > The function follows (I call it from two_bridge_attended_transfer and > ast_bridge_transfer_attended functions). > I can't comment on code through this mechanism, someone else may be able to. -- 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
Re: [asterisk-dev] [External] Re: Question regarding http_media_cache and astcachedir setting
On Thu, Feb 9, 2023 at 6:07 AM Floimair Florian wrote: > Well, I totally missed the ‘(!)’ part, that makes sense. > > > > Unfortunately this template is nowhere used in the other documented > example settings (whether they are commented out or not) and also the wiki > is not very verbose about it: > https://wiki.asterisk.org/wiki/display/AST/Asterisk+Main+Configuration+File > . > > Just curious what was the reasoning behind making this a template that is > never used? > That question predates my involvement in the project. I can only guess it's because the default values can be changed as a result of how Asterisk is built, so if it wasn't a template then the user expectation would be confusing because it would override what the user actually built Asterisk to do by default. The file could be potentially generated at build time, but noone has done that or changed it otherwise. -- 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
Re: [asterisk-dev] Question regarding http_media_cache and astcachedir setting
On Wed, Feb 8, 2023 at 2:08 PM Floimair Florian wrote: > Hey there! > > > > I have a question regarding res_http_media_cache module and the > astcachedir setting in asterisk.conf: > > > > We see files are cached by this module in /tmp > (/tmp/bucket-.wav16) regardless of what we set for astcachedir > in asterisk.conf (tried /tmp/asterisk). > > Is this a bug? > Is directories uncommented such that it is applied? By default it is a template, and thus not actually used. -- 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
Re: [asterisk-dev] Using SIP TLS with Mediasec
On Mon, Jan 30, 2023 at 12:58 PM Karsten Wemheuer wrote: > Hi *, > > I am currently testing Asterisk 18.16 with TLS and Mediasec. I am > testing it with Telekom CompanyFlex. The trunk registers and after a > while the request to re-register gets a "403 Forbidden". > I had previously used Asterisk 18.15 with the patch from Michael Maier. > That worked flawlessly. > Why are there two approaches to solving the "Mediasec" problem? What is > the obstacle that prevents to use the working patch from Michael Maier? > In order to be included in Asterisk the author has to sign the contributor license agreement. Without this, a change can not be merged. Michael Maier does not wish to sign the contributor license agreement - which is completely their right - and thus that implementation can not be merged. -- 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
Re: [asterisk-dev] chan_sip deprecation
On Tue, Nov 22, 2022 at 8:39 AM wrote: > On 11/22/2022 7:36 AM, Henning Westerholt wrote: > > Hello, > > > > as said, it's all fine with me, I just wondered. Regarding the quoted > bug https://issues.asterisk.org/jira/browse/ASTERISK-28689: > > maybe I interpret it wrong, but it seems that, after two years from the > opening date, fixes has been integrated into the repositories two weeks ago. > Ah, thanks for pointing that out! It's been so long now that I've been > so used to it just being open, that I totally missed that. > Great to see that and big thank you to Mike for fixing that! That's > really great news, I know lots of people will be thrilled. > (So strike what I said about that stability issue - but my other > comments still apply...) > If in my judgment an issue impacts enough people in the community, then I will bump it to the top of the work queue for the Asterisk team at Sangoma. That is what happened with this and has happened with other issues in the past. -- 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
Re: [asterisk-dev] Adding headers to NOTIFY responses
On Tue, Nov 15, 2022 at 7:12 PM wrote: > On 11/15/2022 9:56 AM, Joshua C. Colp wrote: > > On Tue, Nov 15, 2022 at 10:50 AM > <mailto:aster...@phreaknet.org>> wrote: > > > > > > If res_pjsip_pubsub would need to be extended to support this, > > would it > > reasonable to add a callback to a pubsub module that allows it > > access to > > the pjsip_tx_data, so it can do whatever it needs to with it, > > before the > > response gets sent? Or another preferred method of allowing > > modules to > > add headers? > > > > > > At a surface it is probably fine. > > Thanks, doing that allowed just what I needed to do. > > Next limitation... the new_subscribe callback is supposed to return 200 > (or some other code) to accept or reject the subscription. The only > arguments are the endpoint name and resource name. > This is not really always sufficient; it may be necessary to approve or > reject the subscription using some information present in the > subscription itself (for example, a header). I think this is all > consequent of the very narrow range of scenarios that res_pjsip_pubsub > was written for originally. > > The subscription_established callback is actually perfectly set up for > this. We have a handle on the ast_sip_subscription, and can call > ast_sip_subscription_get_header if needed to get the header. > However, this requires approving all subscriptions with a 200 in the > new_subscribe callback, only to potentially realize it should be > rejected in the subscription_established callback. This is too late > because the 200 OK already gets sent to the endpoint before > subscription_established gets called. > > So, the only good solution is to extend new_subscribe to accept a third > argument: rdata, since a subscription hasn't yet been created at that > point so we could not use ast_sip_subscription_get_header to fetch > headers. Yuck, since it's a public API... there could also be a > new_subscribe_with_rdata callback that gets executed instead if a module > defines one. Or maybe we can break ABI and go master only here if that > would be too inelegant. > Even adding a new callback will break the ABI. I think fundamentally this work should only occur in master where changing ABI is fine. I have concerns that it will cause unintended consequences in some way and I've had enough of those in the past year in release branches. -- 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
Re: [asterisk-dev] Adding headers to NOTIFY responses
On Tue, Nov 15, 2022 at 10:50 AM wrote: > I am working on something where I need to be able to add a custom header > to an outgoing NOTIFY response for a subscription. > > We have the concept of "body generators" for adding stuff to the body of > an outgoing NOTIFY, but I'm not seeing anything akin to "header > generators" that would easily allow doing this. > > I believe typically this is done by adding the header to the tdata pool, > e.g. ast_sip_add_header(tdata, "Expires", buf) as one way of doing it. > To be specific, it allocates a header FROM the tdata pool and sets it on tdata. > > However, res_pjsip_pubsub doesn't generate/initialize a pjsip_tx_data > until after ast_sip_subscription_notify is already called, so it > certainly can't be done before a pubsub module calls on the pubsub core > to send the notify. Is there any way I've missed that allows us to > access the tdata from a pubsub module, so we can add a header to the > NOTIFY response? > No. > > I do see there is an ast_sip_subscription_response_data struct defined > in res_pjsip_pubsub.h. However, this is used literally nowhere in the > code, only defined, so it's not clear to me how this is supposed to be > used, since nothing currently uses it. Was this intended to be used for > this purpose, or something else? > What you see is the information there is. > > If res_pjsip_pubsub would need to be extended to support this, would it > reasonable to add a callback to a pubsub module that allows it access to > the pjsip_tx_data, so it can do whatever it needs to with it, before the > response gets sent? Or another preferred method of allowing modules to > add headers? > At a surface it is probably fine. -- 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
Re: [asterisk-dev] PJSIP Device Feature Key Synchronization architecture
On Wed, Nov 9, 2022 at 11:38 AM wrote: > On 10/21/2022 7:53 AM, Joshua C. Colp wrote: > > On Fri, Oct 21, 2022 at 8:29 AM > <mailto:aster...@phreaknet.org>> wrote: > > > > On 10/21/2022 5:34 AM, Joshua C. Colp wrote: > > > On Thu, Oct 20, 2022 at 8:23 PM > <mailto:aster...@phreaknet.org> > > > <mailto:aster...@phreaknet.org <mailto:aster...@phreaknet.org>>> > > wrote: > > > > > > Hi, all, > > > > > > Something I have been working on recently is adding > > support to > > > PJSIP for device feature key synchronization (the > > as-feature-event > > > Broadworks spec that many common IP phones, e.g. Polycom > > support) to > > > control server-side features from endpoints. It's using the > > PJSIP > > > pub/sub capabilities; I had to add the ability to execute a > > custom > > > module callback when a SUBSCRIBE is refreshed, but with that > > > addition, > > > it works as it's supposed to. > > > > > > > > > You should further elaborate on all of the server-side features you > > > expect to implement, if it extends beyond DND. > > > > The other one is Call Forwarding (Always/Busy/No Answer, with > > number of > > rings) > > > > > > > > I wanted to solicit some input on what an ideal way of > > triggering > > > updates should be. Currently we have hints, which actually work > > > reasonably all right for Do Not Disturb, which is simply a > > boolean > > > on/off, easily represented with a hint and custom device > > state for > > > DND. > > > The PJSIP module emits an AMI event, the user can process it > and > > > change > > > the device state if needed, which will trigger a NOTIFY to > > go out > > > to the > > > endpoint. > > > > > > > > > What user? An outside AMI application? An internal consumer in > > Asterisk? > > > > The administrator of the Asterisk system, who can add AMI logic to > > receive the event and then do something with it. > > The reason this is needed is the phone isn't turning DND on directly, > > for example. It's merely a request. The server can decide to not > > allow > > it, for example if that phone isn't allowed to toggle DND. The server > > will process it, and send it the updated status. This usually > > reflects > > what the phone wanted, but not necessarily. > > (I've elaborated on this more below) > > > > > > Okay, that's not the administrator of an Asterisk system. That's a > > developer using Asterisk who may be the administrator. Those are two > > separate things. As soon as you bring AMI into the mix then it's > > making a solution using Asterisk. That's not a wrong thing, but it's > > important to be clear in the audience. Many average users of Asterisk > > doesn't know or care about AMI, 'nor do they code for it. They may use > > additional solutions that utilize AMI but they themselves haven't the > > foggiest of the details. > > > > > > > > > > This sort of came up about 12 years ago[1]. The actual SIP > stuff > > > is not > > > complicated; it's the user interface to it that requires more > > > thought. > > > For call forwarding, there are more moving pieces and abusing > > > hints/custom device state for that is super clunky. You can't > > > communicate the call forwarding target, # of rings, etc. in > > a device > > > state, so additional hints are then needed for that. It > > works but > > > it's > > > super clunky and I don't think this is a great pipeline. > > > > > > > > > Okay, so this covers call forwarding as well. > > Yes. > > > > > > > > > I'm wondering if people have thoughts on what an ideal > mechanism > > > would > > > be for users, once they process a request to enable/disable > > a feature > > > from the phone, to communicate that to the PJSIP module. The > > problem > > > with abusing hints, es
[asterisk-dev] Asterisk 19 Security Fix Only!
Kia ora, It seems like only yesterday I was writing an email about Asterisk 16 going security fix only. As mentioned in that email 19 was up next, and its day has come. Just like 16 there will be a future final bug fix release. Going forward you don't need to cherry pick to 19 and if you currently have reviews up then you can keep them up, or abandon them. Now that the dust has settled on those the current branches receiving bug fixes are 18, 20, and master. Cheers, -- 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
Re: [asterisk-dev] chan_sip deprecation
On Sat, Oct 29, 2022 at 1:40 PM Michal Rybarik wrote: > Hello all, > > chan_sip has been deprecated in Asterisk 17 and there is a plan to remove > it in 21 (expected next year). > https://issues.asterisk.org/jira/browse/ASTERISK-29567 > > However, we still have many things depending on chan_sip, and its > replacing with chan_pjsip needs significant amount of work and testing, > depending on other parties too. I'm thinking how to continue using chan_sip > in the next years, while keep using latest asterisk source (master branch). > > Would it be possible to postpone the removal from Asterisk by several > versions? > No. The chan_sip module has been deprecated since 17. It's been years. This is not being postponed. > > Or to move chan_sip to a separate repository and let it exist there - like > libpri, libss7, dahdi, etc? > This is not something the project will do. You are free to do it yourself, or bring it back in using some other mechanism such as what was mentioned by the other responder. -- 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
Re: [asterisk-dev] PJSIP Device Feature Key Synchronization architecture
On Fri, Oct 21, 2022 at 8:29 AM wrote: > On 10/21/2022 5:34 AM, Joshua C. Colp wrote: > > On Thu, Oct 20, 2022 at 8:23 PM > <mailto:aster...@phreaknet.org>> wrote: > > > > Hi, all, > > > > Something I have been working on recently is adding support to > > PJSIP for device feature key synchronization (the as-feature-event > > Broadworks spec that many common IP phones, e.g. Polycom support) to > > control server-side features from endpoints. It's using the PJSIP > > pub/sub capabilities; I had to add the ability to execute a custom > > module callback when a SUBSCRIBE is refreshed, but with that > > addition, > > it works as it's supposed to. > > > > > > You should further elaborate on all of the server-side features you > > expect to implement, if it extends beyond DND. > > The other one is Call Forwarding (Always/Busy/No Answer, with number of > rings) > > > > > I wanted to solicit some input on what an ideal way of triggering > > updates should be. Currently we have hints, which actually work > > reasonably all right for Do Not Disturb, which is simply a boolean > > on/off, easily represented with a hint and custom device state for > > DND. > > The PJSIP module emits an AMI event, the user can process it and > > change > > the device state if needed, which will trigger a NOTIFY to go out > > to the > > endpoint. > > > > > > What user? An outside AMI application? An internal consumer in Asterisk? > > The administrator of the Asterisk system, who can add AMI logic to > receive the event and then do something with it. > The reason this is needed is the phone isn't turning DND on directly, > for example. It's merely a request. The server can decide to not allow > it, for example if that phone isn't allowed to toggle DND. The server > will process it, and send it the updated status. This usually reflects > what the phone wanted, but not necessarily. > (I've elaborated on this more below) > Okay, that's not the administrator of an Asterisk system. That's a developer using Asterisk who may be the administrator. Those are two separate things. As soon as you bring AMI into the mix then it's making a solution using Asterisk. That's not a wrong thing, but it's important to be clear in the audience. Many average users of Asterisk doesn't know or care about AMI, 'nor do they code for it. They may use additional solutions that utilize AMI but they themselves haven't the foggiest of the details. > > > > > This sort of came up about 12 years ago[1]. The actual SIP stuff > > is not > > complicated; it's the user interface to it that requires more > > thought. > > For call forwarding, there are more moving pieces and abusing > > hints/custom device state for that is super clunky. You can't > > communicate the call forwarding target, # of rings, etc. in a device > > state, so additional hints are then needed for that. It works but > > it's > > super clunky and I don't think this is a great pipeline. > > > > > > Okay, so this covers call forwarding as well. > Yes. > > > > > > I'm wondering if people have thoughts on what an ideal mechanism > > would > > be for users, once they process a request to enable/disable a feature > > from the phone, to communicate that to the PJSIP module. The problem > > with abusing hints, especially for call forwarding, is it's not a > > good > > way to communicate details into the module. One option perhaps is to > > have dialplan extensions, setup in a manner similar to use with > > EVAL_EXTEN, where it returns the current value needed, as any > > relevant > > function, DB, ODBC, CURL, custom function, etc. could be used to > > retrieve the current feature value. The clunky part is more > > signaling to > > the PJSIP module that it needs to send the phone the updated > > status (by > > checking those extensions, for example). The device state callback > > happens to be convenient for this kind of signaling but not really > > appropriate here. It would be better to push the info into the module > > directly rather than the signaling it and making it retrieve the > > updated > > data in some arbitrary way. > > > > So with this in mind, I'm currently leaning in the direction of a > > dialplan function/AMI action that could be used to set the > > appropriate > > info for a subscription,
Re: [asterisk-dev] PJSIP Device Feature Key Synchronization architecture
example
${EXTENSION_DND(alice)} for retrieving DND status of Alice, and if Asterisk
restarted then that should stay the same.
For developers the same thing could apply except having AMI actions to set
and get.
Functionally this is a simple storage mechanism of data. The AstDB is used
to persist such information. It could use sorcery to then be backed by a
real database. The manipulation could be like I said previously, using
dialplan functions with also AMI actions. To get the information to
consumers it would be a defined API to allow
setting/getting/subscribing/anything else, and for pushing to consumers it
would use stasis which would also give AMI events when things changed. It's
sorta like device state, but with persistent data and simpler.
This would also need explicit configuration to ensure that stale data
doesn't persist in the persistent storage.
--
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
[asterisk-dev] Asterisk 16 Security Fix Only (And 19 Soon!)
Greetings all, Asterisk 16 has now gone security fix only with Asterisk 19 following on November 2nd. There will be a future final bug fix release for each. Going forward you don't need to cherry pick to 16, and then after November 2nd you won't have to do so for 19 either. If you currently have reviews up for 16 you can keep them up, or you can abandon them. Cheers, -- 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
Re: [asterisk-dev] Require Help in Re-Compile of chan_sip.so
On Wed, Oct 12, 2022 at 10:15 AM Paul Kudla (SCOM.CA Internet Services Inc.) wrote: > > History : > > I downloaded and have run Elastix 2.4 x64 for years without any issues > > I have the asterisk 1.8.20 source code loaded and built on a centos > server (same version running) > > Issue is there is a checksum etc built into the chann_sip.so file (along > with all other .so files) unique to the version and how it was compiled > of asterisk. > > As a programmer i can understand the need for checksums etc but there is > NO documentation on how elastix 2.4 x64 was origionally compiled, setup, > make etc ? > Elastix is not part of the Asterisk project, so it's not something that as a project we'd know anything about it. You can potentially guess it based on the output of "core show settings" if that is available. > > aka what i need to make a compatible chann_sip.so (or any other module) > for my production copy of Asterisk currently running > > Basically I am getting "Sending fake auth rejection for" errors without > the ip address ? > > I need to patch the chann_sip.so file to allow for that (already have > the patch) just need a compatible .so file? > > more then happy to pay for it ? (preferably paypal) > The process for doing bounties is on the wiki[1]. [1] https://wiki.asterisk.org/wiki/display/AST/Asterisk+Bug+Bounties -- 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
