Re: [asterisk-dev] ARI events order
On Wed, Sep 5, 2018 at 5:23 PM Seán C. McCord wrote: > As to the events should have a deterministic order or not, I cannot speak, > but this is definitely normal behaviour. > > > On Wed, Sep 5, 2018 at 12:22 PM Jean Aunis wrote: > >> Hello, >> >> It looks like the ARI events ordering during channel destruction is not >> deterministic. I noticed this for ChannelLeftBridge and ChannelDestroyed >> events : given a channel is in a bridge and is hanged up, sometimes >> ChannelLeftBridge is raised before ChannelDestroyed, sometimes it's the >> contrary. Test conditions are exactly the same in both cases. >> >> Is this non-deterministic behaviour normal, or should it be considered as >> a bug ? >> >> To my mind, ChannelDestroyed should always be the very last event raised >> for a given channel. From a developper point of view, it would give a clear >> indication that the resources associated to the channel can be freed. >> >> Regards >> > The events regarding a Channel entering and leaving a Bridge are deterministic with respect to the Bridge's lifetime, but are not deterministic with respect to the Channel's lifetime. While it's a bit different, this is discussed somewhat on the AMI specification page: https://wiki.asterisk.org/wiki/display/AST/AMI+v2+Specification#AMIv2Specification-Bridging While AMI and ARI are two different APIs, both are built on top of a shared internal abstraction layer inside Asterisk that determines that event ordering. In the case of channels, channel event ordering is guaranteed when those events are published to what is known as the 'channel' topic for that channel. The act of entering / leaving a bridge is published to the bridge's topic, which is technically independent of the channel's topic. As such, the ordering of those events as they are presented to the AMI / ARI topics is not guaranteed. An example can be seen in publishing the bridge leave message: void ast_bridge_publish_leave(struct ast_bridge *bridge, struct ast_channel *chan) { struct stasis_message *msg; if (ast_test_flag(&bridge->feature_flags, AST_BRIDGE_FLAG_INVISIBLE)) { return; } msg = ast_bridge_blob_create(ast_channel_left_bridge_type(), bridge, chan, NULL); if (!msg) { return; } /* state first, then leave blob (opposite of enter, preserves nesting of events) */ bridge_publish_state_from_blob(bridge, stasis_message_data(msg)); stasis_publish(ast_bridge_topic(bridge), msg); ao2_ref(msg, -1); } Note that we're publishing that message to the bridge topic - ast_bridge_topic(bridge) - as opposed to the channel topic (which would be ast_channel_topic(chan)). (To be pedantic, if you really wanted to preserve event ordering for both the bridge and the channel's respective lifetimes, you'd have to make a new aggregation topic for each channel / bridge and publish their messages to those aggregation topics, but that's a lot of overhead.) You could argue that it *should* be ordered with respect to both the channel and bridge's lifetime, but generally enforcing that ordering imposes a penalty on the system, as it requires more synchronization. If someone went down that path, it'd require some careful testing to ensure it doesn't bog things down in some massive way. -- Matthew Jordan Digium, Inc. | CTO 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA Check us out at: http://digium.com & http://asterisk.org -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- Astricon is coming up October 9-11! Signup is available at: https://www.asterisk.org/community/astricon-user-conference asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] Asterisk 14 doesn't cache media, really
On Thu, Feb 22, 2018 at 12:06 PM, Joshua Colp wrote: > On Wed, Feb 21, 2018, at 7:42 PM, Gaurav Khurana wrote: > > Does anyone know about how caching of media actually happens in Asterisk > > 14? What I observe is that in the case of a media uri being presented to > > Asterisk to play to the caller, Asterisk fetches the media, stores it > > in /tmp and plays it back. Now, when the same media uri is presented to > > Asterisk again whether in the same Call (SIP session with a given > > caller) or a new call, Asterisk makes a web request to fetch the media > > file again and replaces the existing file under /tmp with the new one. > > This is kinda fine but what doesn't seem right is that when Media server > > serving the media files is down, Asterisk fails to play it instead of > > using the cached media file. > > I don't think that scenario was targeted for the support when it was > written. It may have just been written to not download the file if it > hasn't changed which would explain the behavior you are seeing. I think > it'd be reasonable to add support for the scenario and shouldn't be too bad > depending on the code. > > Well sort of. It caches it *if* the HTTP response from the upstream provider indicates that it *can* be cached. That's a complex topic, but it boils down to a few things: - Does it have an ETag? If so, we store that in the metadata in the media cache layer. If the ETag changes (which we check with a HEAD request), we have to get a new version. - Does it have a 'cache-control' header? If so, does it tell us to not cache it? If so, we get a new version of the file each time. - Is there an expiration time? (cache-control header value of max-age or s-maxage, or an expires header value). If it expired, we get a new version of the file. So - you'll need to check the HTTP responses from your server to determine why we would get a new version each time. Having an expiration value, no ETag, or cache-control values that indicate that we shouldn't cache the file would explain why we get it each time. -- Matthew Jordan Digium, Inc. | CTO 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA Check us out at: http://digium.com & http://asterisk.org -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] Help with AOC (Advice Of Charge) - price info on outbound calls
On Wed, Nov 22, 2017 at 2:46 AM, Marin Odrljin wrote: > > Yes, that’s the way my app works all the time, there is no any AOC event sent > to ARI. I was also expecting such events are sent to Stasis since I have > found in ‘stasis.conf’ possibility to decline them: > > > > ; decline=aoc_s_type > > ; decline=aoc_d_type > > ; decline=aoc_e_type > > > > Other configuration files where AOC is mentioned are: > > - ‘manager.conf’ for AMI which probably works, but I didn’t try it > till now and would like to avoid it if possible > > - ‘chan-dahdi.conf’ where I have enabled them > > - ‘sip.conf’ for snom endpoints which I don’t need > > Unfortunately, AOC events don't have a JSON representation and aren't published to a Stasis topic that goes to ARI applications. In aoc_publish_blob, you can see that we only publish the various AOC events to the Manager topic (via ast_manager_get_topic): msg = stasis_message_create(msg_type, aoc_event); ao2_ref(aoc_event, -1); stasis_publish(ast_manager_get_topic(), msg); That pretty much limits AOC events to AMI today. If you wanted this in ARI, you could pretty easily provide a patch to do so. You'd need to: * Change the topic that the messages are published to one that is received by ARI. Assuming there is a channel involved, the easiest of these is the channel topic. If there is no channel, you could publish it to the generic 'all channels' topic. (Not all AOC events have a channel, so you'd need to make sure it goes to some topic that makes sense when that's the case.) * Provide a JSON representation of the message. That means defining a .to_json callback here which formats the message into JSON: STASIS_MESSAGE_TYPE_DEFN( aoc_s_type, .to_ami = aoc_s_to_ami); STASIS_MESSAGE_TYPE_DEFN( aoc_d_type, .to_ami = aoc_d_to_ami); STASIS_MESSAGE_TYPE_DEFN( aoc_e_type, .to_ami = aoc_e_to_ami); * Add the JSON representation of the message to the Swagger specification (events.json) so that things get validated correctly. For what it's worth, the data models wiki page shows the various events that can be received: https://wiki.asterisk.org/wiki/display/AST/Asterisk+13+REST+Data+Models -- Matthew Jordan Digium, Inc. | CTO 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA Check us out at: http://digium.com & http://asterisk.org -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
[asterisk-dev] Line length restrictions in code changes
Warning: bike shedding. On several code reviews, comments have been left along with a -1 on the review - indicating that it is not acceptable for merging - due to line length restrictions. While this is technically correct per our coding guidelines, it doesn't always result in the most readable code. Personally, I find this: if (a_good_variable_name->another_good_name && do_something_to_it(a_good_variable_name->another_good_name)) { // Do things } To be preferable to: if (a_good_variable_name->another_good_name && do_something_to_it(a_good_variable_name->another_good_name)) { // Do things } This is typically because the indentation of the second part of the boolean test lines up with the code that is to be executed if both conditions is true, which is more visually jarring than just reading the first line. I'll grant this is probably a personal preference, but we have certainly opted for the former over the latter in many places in the code. While I know that we aren't all sitting around with dual screens, we also aren't living in 1979 with dumb terminals. The line length restriction of 90 columns seems reasonable until you end up with long function names, which - since we live in a land of void * - is generally something that we should encourage. I'd like to say that some common sense about when to apply the line length rule and when not to would "work for us", but that doesn't appear to be the case. Questions than: (1) Should there even be a line length rule? (2) If there is a line length, what is a reasonable length given some of our function names? (Looking at things like ast_sip_get_mwi_disable_initial_unsolicited) (3) Should we simply advocate for readability, with examples of what is readable and what is not? Matt -- Matthew Jordan Digium, Inc. | CTO 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA Check us out at: http://digium.com & http://asterisk.org -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] Asterisk goes Spatial Conferencing: the STEAK project
On Thu, Mar 2, 2017 at 3:46 AM, Dennis Guse wrote: > Since all patches are now merged, this will be the last eMail from me on > this thread. > Here are just the steps to setup the binaural synthesis and the required > stereo-capable OPUS module: > > ``` > git clone http://gerrit.asterisk.org/asterisk > git clone https://github.com/SteakConferencing/asterisk-opus > > cp asterisk-opus/codec/* asterisk/codec > > cd asterisk > > ./configure > > make menuconfig > #Enable "Bridging modules"/binaural_rendering_in_bridge_softmix > #Enable "Codec Translators"/codec_opus_open_source > #Disable "Channel Drivers"/chan_sip - might avoid some issues if WebRTC is > desired ;) > > make > ``` > > Tested with Asterisk (comit-id 00d1c7ddd28557aa845c3522956852a60310df96). > > Enjoy! > --- > Dennis Guse Thank you Dennis for all your hard work on this feature! Matt -- Matthew Jordan Digium, Inc. | CTO 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA Check us out at: http://digium.com & http://asterisk.org -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] asterisk-dev Digest, Vol 151, Issue 14
On Wed, Feb 22, 2017 at 1:20 AM, Dương Nguyễn Văn wrote: > > Re: Contents of asterisk-dev digest... > Thanks for pointing that individual out. They've been unsubscribed. -- Matthew Jordan Digium, Inc. | CTO 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA Check us out at: http://digium.com & http://asterisk.org -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] Subscription Persistence Issues
On Tue, Feb 7, 2017 at 1:16 PM, George Joseph wrote: > Greetings All, > > I've been working on the (many) issues with recreating inbound > subscriptions after an asterisk restart. I have an approach that works but > has a drawback: We can recreate the subscription on startup from the data > we persist and can even send a NOTIFY to each subscriber BUT with the > current version of pjproject, we can't actually set the expiration timer. > I have a pjproject patch ready that allows us to set tie timer but the > drawback is that this approach will only work with bundled pjproject or a > patched version of your own. > > There's an alternative though... When asterisk restarts, instead of > sending 'active' NOTIFYs to each subscriber, we could send > 'terminate,probation' instead. The RFCs say that a "client SHOULD retry at > some later time". While this approach will work with any version of > pjproject there are issues here as well. The first issue is the word > 'SHOULD'. There's no guarantee that the client will actually resubscribe. > The second issue is the extra SUBSCRIBE/OK/NOTIFY/OK exchange between > asterisk and the client at startup. We can tell the client to retry not > before a random interval similar to how we stagger sending OPTIONS messages > at startup but it's still an extra 4 packets per subscription. > > Neither approach is harder or easier than the other to implement. It's > just a matter of backwards compatibility vs extra traffic and the 'SHOULD' > uncertainty. > > Thoughts? > > If you go with the first approach, do the changes to pjproject to fix the expiration timer issues cause any API changes? Or is it merely fixing a bug in pjproject? -- Matthew Jordan Digium, Inc. | CTO 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA Check us out at: http://digium.com & http://asterisk.org -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] Wish: adding intelligent codec negotiation to asterisk / pjsip
On Mon, Jan 30, 2017 at 4:44 PM, George Joseph wrote: > > > On Mon, Jan 30, 2017 at 3:32 PM, Matthew Jordan > wrote: > >> >> >> On Mon, Jan 30, 2017 at 3:22 PM, Matt Fredrickson >> wrote: >> >>> Hey Michael, >>> >>> First off, thanks for taking the time to express some of your thoughts >>> and concerns to the asterisk-dev list. I'll keep my reply to your >>> email inline below. >>> >>> On Mon, Jan 30, 2017 at 4:13 AM, Michael Maier >>> wrote: >>> > Dear developers, >>> > >>> > I've been redirected to this mailing list by Joshua Colp during fixing >>> a >>> > one way audio bug[1] to discuss another solution as provided in the >>> fix. >>> > >>> > Background: >>> > - A lot of people complain about bad VoIP call quality compared to the >>> > old POTS / ISDN devices. What do they mean from a technical point of >>> > view: High latencies (resulting in echo), digital sound because of >>> "bad" >>> > codecs, general quality loss during transcoding and many other reasons >>> more. >>> > - In Europe, HD audio is being adopted slowly. This means, more and >>> more >>> > UAs can natively handle HD codecs like g722. But they must be downward >>> > compatible at the same time for older UAs, which just speak alaw (like >>> > the old POTS devices e.g. or UAs which are not yet HD capable). >>> > Therefore, they advertise at least two codecs: g722 and alaw (mostly >>> > plus some more like ulaw or some other codecs). >>> >>> So there are multiple reasons why you could be seeing reportedly bad >>> call quality that come to my mind: >>> >>> 1. Transcoding - changes the audio, but typically doesn't make things >>> sound *too* bad. Obviously it is codec dependent as to how bad it >>> sounds afterwards, but most modern codecs aren't terrible for speech >>> replication and encoding. Usually this is not where call quality >>> problems are noticed. >>> >>> 2. Packet loss and jitter related problems. In an ISDN network, there >>> is a guaranteed real time audio channel for transporting media. As >>> long as the data pumps on the transmit and receive side are working >>> properly, you should hear almost no audio quality issues. VoIP tries >>> to transport real time audio over a non-guaranteed transport channel. >>> This sometimes causes bad audio quality issues due to packet loss, >>> packet reordering, or extreme packet delays. Enabling Asterisk's >>> jitter buffers typically improves many problems that arise due to >>> this. They are typically *not* enabled by default and so must be >>> explicitly enabled. >>> >>> I'm hoping you already have dived into your problem to look at both >>> the above elements, and have confirmed that you are not dealing with >>> the second problem instead of voice mutation due to the first problem. >>> Usually you can track the second problem by doing packet captures of >>> the voice conversations in question as well as look at RTCP >>> statistics. >>> >>> > What does this mean to Asterisk? >>> > My conviction is, that Asterisk shouldn't make things even worse when >>> > handling calls / codecs by forcing unnecessary transcoding, which >>> > unnecessarily harms call quality. Next point of unnecessary >>> transcoding: >>> > it unnecessarily steals system resources from the machine asterisk is >>> > running on. >>> > Asterisk should harm each call it handles and the underlying machine as >>> > little as possible. >>> > >>> > Therefore I would like to see a (switchable) feature, that asterisk / >>> > pjsip always tries to primarily advertise codecs, which are supported >>> by >>> > both UAs and remove those codecs, which are not supported by one of the >>> > UAs. This prevents unnecessary transcoding. >>> >>> This actually would be a really neat thing for Asterisk to be able to >>> do. Last time I looked at it, there are quite a few challenges in >>> making it happen. Asterisk is designed to be a back to back user >>> agent, and it inherently is designed to terminate media and codecs >>> individually with each leg in question, but not necessarily together. >>> It "makes things work" on each leg separately, bas
Re: [asterisk-dev] Wish: adding intelligent codec negotiation to asterisk / pjsip
s several times. The last time I gave that a shot I more or less had it working, and then broke myself (and my patch) on the rocks of Local channels. Trying to get Local channel chains to respect the codecs down a chain (generally 3+ is enough to trip errors) is a non-trivial operation. When setting up the call you more or less can control the situation - the codec preferences are passed down the chain via ast_request. However, when things are coming back in the other direction, you don't have an easy reference to the channel that created you. It can involve reaching across bridges and local channel bridges, which is dangerous. Both are prone to error and deadlocks. Holding a reference to your creator isn't safe, as the creator can be masqueraded away (in really weird situations). The other option is to pass the information down in a frame, but now you can't guarantee much, as that's an asynchronous operation. In transcoding situations, you also have to pick where in that chain you choose to do transcoding - which is not always easy to figure out. Things get challenging as well when you have a multi-party bridge involved at all - either when a dialed party has to be placed into a multi-party bridge or when you have a chain of Local channels dialing someone and the far end of the Local channel chain is already in a multi-party bridge. Generally, this is an architectural limitation of Asterisk that - while not impossible to craft a solution for - is far harder than it may seem when you're only thinking of two-party calling with non-Local channels. -- Matthew Jordan Digium, Inc. | CTO 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA Check us out at: http://digium.com & http://asterisk.org -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] Subscription behavior when an incoming registration goes away?
On Thu, Dec 22, 2016 at 9:32 AM, George Joseph wrote: > When an incoming registration goes away, either because it expires or it > was explicitly expired, what should we do with subscriptions the contact > may have? Right now we do nothing which means that activity for those > subscriptions will trigger NOTIFYs which will time out and retry until > timer_b expires. Only then will they be deleted. > > Should we: > >- Leave the behavior as is? >- Automatically remove the subscriptions for a contact that has been >deleted? >- Create a global option to control auto deletion? >- Create an aor option to control auto deletion? > > Opinions? > > If an AoR only has dynamic contacts, and those dynamic contacts are no longer valid (or the AoR no longer has any contacts), then at the very least I would think we wouldn't want to send the NOTIFY requests until the AoR has valid contacts. There's certainly no reason to use memory/CPU cycles on something that will never succeed. You may or may not want to actually remove the underlying subscription. I could see a scenario in which a phone's REGISTER request goes "missing", and so the registration drops - maybe for just a short period of time. When the new REGISTER request does succeed, the phone may or may not send a new SUBSCRIBE request (which may have a very different timer). If we auto-deleted the underlying subscription, we could have a situation where the phone is re-registered but no longer receives state updates. I'll grant the above scenario is pretty unlikely, but it is plausible. Matt -- Matthew Jordan Digium, Inc. | CTO 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA Check us out at: http://digium.com & http://asterisk.org -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] app_queue missed calls per agent - caller hangup before timeout
On Thu, Dec 15, 2016 at 10:17 AM, marek cervenka wrote: > i think i foud possible solution. can you confirm if i'm on correct path? > > sql data looks > > +-++-+-- > -+---+-+---+---+---+---+---+ > | id | time | callid | queuename | agent | > event | data1 | data2 | data3 | data4 | data5 | > | 165913 | 2016-12-14 11:01:20.965839 | 1481709660.56899 | queue1 | > NONE | ABANDON | 1 | 1 | 9 | | | > > data3 contains ringtime but agent is filled as "NONE" > > > in app_queue there are 2 places which fills ABANDON > > > function queue_exec > > stop: > if (res) { > if (res < 0) { > if (!qe.handled) { > record_abandoned(&qe); > *ast_queue_log(args.queuename, ast_channel_uniqueid(chan), > "NONE", "ABANDON", "%d|%d|%ld", qe.pos, qe.opos, (long) (time(NULL) - > qe.start));* > res = -1; > } else if (qcontinue) { > reason = QUEUE_CONTINUE; > res = 0; > } > } else if (qe.valid_digits) { > ast_queue_log(args.queuename, ast_channel_uniqueid(chan), > "NONE", "EXITWITHKEY", > "%s|%d|%d|%ld", qe.digits, qe.pos, qe.opos, (long) > (time(NULL) - qe.start)); > } > > > BUT > > in try_calling function > > there is member filled > > } else if (ast_check_hangup(qe->chan)) { > /* Caller must have hung up just before being connected */ > ast_log(LOG_NOTICE, "Caller was about to talk to agent on > %s but the caller hungup.\n", ast_channel_name(peer)); > *ast_queue_log(queuename, ast_channel_uniqueid(qe->chan), > member->membername, "ABANDON", "%d|%d|%ld", qe->pos, qe->opos, (long) > (time(NULL) - qe->start));* > record_abandoned(qe); > ast_channel_publish_dial(qe->chan, peer, > member->interface, ast_hangup_cause_to_dial_status(ast_channel_ > hangupcause(peer))); > ast_autoservice_chan_hangup_peer(qe->chan, peer); > ao2_ref(member, -1); > return -1; > } > > > why isnt used the try_calling to fill ABANDON? > > is it safe fill member (if exist) in queue_exec? > > These two locations are fulfilling two different purposes. The first, in queue_exec, handles the case where the caller abandons the queue prior to any queue member being selected. The second, as the comment suggests, handles the case where the caller abandons the queue after the queue member has been selected but before the two parties have been connected. As such, no, you cannot get a queue member name in queue_exec, as there is no queue member that has been chosen. > > Přeposlaná zpráva > Předmět: app_queue missed calls per agent - caller hangup before timeout > Datum: Wed, 14 Dec 2016 14:26:21 +0100 > Od: marek cervenka > Komu: Asterisk Users Mailing List - Non-Commercial Discussion > > > > hi, > > i'm trying get report about missed calls per agent. i'm using queue_log > and RINGNOANSWER event > but i found problem described here > > ---https://www.thirdlane.com/forum/queue-log-problem > > RINGNOANSWER only happens if the call TIMES OUT ringing the agent and it > returns to the queue. If your agent has a 30 second timeout and the > caller ABANDONS the call in 5 seconds it will log an ABANDON not a > RINGNOANSWER. > > This is the only time ast_queue_log is executed with RINGNOANSWER. The > subsequent code of this function goes on to autopause the agent/member > if autopause is enabled. Not something that happens when callers hang up > when ringing the agents. > > /*! \brief RNA == Ring No Answer. Common code that is executed when we > try a queue member and they don't answer. */ > static void rna(int rnatime, struct queue_ent *qe, char *interface, char > *membername) > { > if (option_verbose > 2) > ast_verbose( VERBOSE_PREFIX_3 "Nobody picked up in %d ms\n", rnatime); > ast_queue_log(qe->parent->name, qe->chan->uniqueid, membername, > "RINGNOANSWER", "%d", rnatime); > --- > > > any tips howto detect missed calls where caller hangup before timeout? > tnx > Marek > > > -- > _ > -- Bandwidth and Colocation Provided by http://www.api-digital.com -- > > asterisk-dev mailing list > To UNSUBSCRIBE or update options visit: >http://lists.digium.com/mailman/listinfo/asterisk-dev > -- Matthew Jordan Digium, Inc. | CTO 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA Check us out at: http://digium.com & http://asterisk.org -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] Possible change to the AMI PJSIPShowRegistrationsInbound command
On Tue, Dec 6, 2016 at 4:27 PM, Matt Fredrickson wrote: > On Tue, Dec 6, 2016 at 12:30 PM, Joshua Colp wrote: > > On Tue, Dec 6, 2016, at 10:43 AM, George Joseph wrote: > >> We just discovered that the PJSIPShowRegistrationsInbound command really > >> only dumps all aors regardless of whether there's an inbound > registration > >> associated with it or not. Fixing this would mean a change to what this > >> command returns so I'm trying to get some feedback. There are 2 > solution > >> alternatives... > >> > >> 1. We could replace the current InboundRegistrationDetail event (which > >> isn't even registered) with a ContactStatusDetail event. Obviously this > >> is > >> a change for anyone who uses this command. > >> > >> 2. We could send a ContactStatusDetail event along with the existing > >> InboundRegistrationDetail event. This would double the number of events > >> sent and therefore increase the total data sent. > >> > >> Honestly I'm not sure how this command was ever useful to anybody so I'm > >> leaning towards option 1 but we need feedback. > >> > >> This would be a change to 13, 14 and master. > > > > Since it was not really useful I'm okay with 1. > > Just as something to consider: > > If we make breaking changes to AMI, this would require a major number > version bump, right? > > Yes, it would. -- Matthew Jordan Digium, Inc. | CTO 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA Check us out at: http://digium.com & http://asterisk.org -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] ast_sip_session
On Tue, Nov 15, 2016 at 6:17 AM, Joshua Colp wrote: > On Mon, Nov 14, 2016, at 03:46 AM, Kelvin Chua wrote: > > playing around chan_pjsip/res_pjsip > > > > i have some data i want to pass from upstream to downstream on reponse > > for > > example, P-Associated-URI > > > > i figured that datastore on ast_sip_session only handles either the > > upstream channel or the downstream channel. I can already parse the > > header > > on upstream but stuck on how to write > > this to the reply downstream. any pointers? > > There is no generic mechanism for doing this currently: specifically > passing data back on a response or answer. The closest thing would be to > add a new frame type (frame.h) to Asterisk, put data on it (in an > ast_frame), propagate it through, and have it read/handled on the other > side. If you end up with specific questions you can respond back with > them, but you are sort of venturing into uncharted territory unless > someone else has an idea on how to better do it. > > I'd throw out there as well that this _may_ not be worth doing, particularly automatically. As a B2BUA, you're always going to be fighting against Asterisk's model of channels and bridges if you want to automatically propagate information from an inbound channel to an outbound channel. Things you have to think through: (1) What happens when there are Local channels? (2) What happens if there are multiple outbound channels (parallel dial)? (3) What happens if I'm in a bridge with multiple channels (conference)? (4) If the information can be provided in a re-INVITE, what occurs if I pass this information along before or after an answer? One of the safer ways of handling the notion of passing things from an inbound to an outbound channel is to have the dialplan do it. You can use functions like PJSIP_HEADER to read values off of an inbound channel, store them in a channel variable with inheritance, then use a pre-dial handler with PJSIP_HEADER (or CHANNEL, etc.) to modify the outbound channel(s) prior to dialing. Doing that gives you more control over exactly _when_ you pass information along, and helps you avoid the many, many edge cases that can occur. -- Matthew Jordan Digium, Inc. | CTO 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA Check us out at: http://digium.com & http://asterisk.org -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] group video calling
On Mon, Nov 14, 2016 at 4:56 AM, ZAIN AFTAB wrote: > Hi All, > > I have posted this question in the asterisk forum, and they > asked me to contact the asterisk-development forum. > > > I want to call ring group where 2 monitors will ring simultaneously, and I > want pre video feature for it( that is video before answering the call). I > am surprised that it works when I dial one SIP video monitor ( I get the > video before answering the call), but when I dial the ring group (with two > sip extensions), I dont get the video before answering the call. I only get > video once the call is answered. > > > 3CX supports this feature by default, we dont need to configure anything, > I believe there must be some options for asterisk as well. > > I need this feature for my video door entry system, it is a big project, > and I want to solve it for my customers > Is there anyone who has worked on this kind of project before ? Any help > would be much appreciated > > thanks in advance > Asterisk does not mix media during an early bridge situation, regardless of the media type. In a situation where a parallel dial is occurring, Asterisk will simply pick a winner and forward the media on to the caller. Assuming Asterisk was modified to mix early media, Asterisk would still not forward two or more video streams. Asterisk does not mix or transcode video, nor does it support forwarding multiple video sources in a single stream (in a selective forwarding unit fashion). Changing the behavior of the previous two points would require relatively large and substantial changes in Asterisk. I would expect Asterisk to forward a single video stream in an early bridge; if that's not happening, I would suspect that's something that could be fixed relatively easily in app_dial. -- Matthew Jordan Digium, Inc. | CTO 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA Check us out at: http://digium.com & http://asterisk.org -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] Proposed Working Group Guidelines
On Mon, Nov 7, 2016 at 5:00 AM, Dan Jenkins wrote: > > On Fri, Nov 4, 2016 at 2:07 PM, Matt Fredrickson > wrote: > >> Hey All, >> >> I've been thinking a lot about how working groups might work within >> the context of the Asterisk project. Here are a few guidelines that I >> have come up with governing working groups. Some of these guidelines >> come from the Node project, as they have a lot of pre-existing >> material on doing this. I deliberately avoided comprehensively >> importing their structure and guidelines, but pulled from some of >> their more essential core principles. >> >> 1. There is no explicit or implicit commitment that a working group’s >> output will actually be turned into code/patches by Digium or anybody >> else outside of the working group. >> >> 2. Some working group topics might include: documentation, feature >> request list, benchmarking, debug-ability, bug tracker triaging and >> replication, migration efforts from SIP to PJSIP (and more?) >> >> 3. They need somewhere to “work” - so a section of the asterisk.org >> wiki and probably a mailing list. This can be a work item for me to >> get taken care of. >> >> 4. Need a regular (weekly?) meeting time and “place” (an Asterisk >> conference call, IRC, a google hangout, etc). >> >> 5. Need a charter of some sort - a charter would be a clearly defined >> mission statement determining the subject matter of the group’s >> efforts. >> >> 6. Need at least three initial members (pulled from node.js guidelines) >> >> 7. Need to follow a consensus seeking process for any decisions >> (https://en.wikipedia.org/wiki/Consensus-seeking_decision-making) >> >> 8. Membership cannot be changed (added or removed) without unanimous >> consensus of the members of the group (pulled from node.js guidelines) >> >> 9. In order to create one, talk to me and I can see about getting >> infrastructure (mailing list, wiki, git access) setup. >> >> Let me know if you have any thoughts, questions, or qualms with the >> above guidelines. I'll wiki-fy the results of any discussion here. >> >> -- >> Matthew Fredrickson >> Digium, Inc. | Engineering Manager >> 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA >> >> -- >> _ >> -- Bandwidth and Colocation Provided by http://www.api-digital.com -- >> >> asterisk-dev mailing list >> To UNSUBSCRIBE or update options visit: >>http://lists.digium.com/mailman/listinfo/asterisk-dev > > > > Hi Matt, > > Firstly, thanks for compiling all of this. > > Some comments around having the discussions etc. > > Please, no more mailing lists. Please? I'd rather not use the wiki for > working groups - the wiki doesn't encourage conversation; instead its a > place to go to document something and maybe write some comments on it - its > really not the best place to have a conversation - I guess this is where > the mailing lists come in but I'd love to get away from mailing lists - we > have discourse now for example which is a MUCH better environment to have > these conversations. I'd personally like to just replicate the node.js > environment on github, with github issues and labels etc but its been made > clear that isn't really an option unfortunately. > > There was talk of needing at least one core contributor (doesn't need to > be a digium employee in my mind) to be one of the 3 initial members - is > this still true? > > I mentioned that I thought it would be a good idea to have an Asterisk Developer involved in any working group, simply as they can help to validate the feasibility of an idea. Whether or not that should be a requirement is up for debate. -- Matthew Jordan Digium, Inc. | CTO 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA Check us out at: http://digium.com & http://asterisk.org -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
[asterisk-dev] Remote media playback mea culpa
Hey all - At AstriDevCon this year, I noted that while we implemented remote media playback in Asterisk 14 [1], it didn't yet work with ARI. I was looking at finishing off this feature for a slightly later release of Asterisk 14, but as I was playing around with it, I realized that it actually *does* work, although the way in which you invoke the remote playback is admittedly a little funky. When posting a /play operation on a bridge or channel resource, providing an HTTP or HTTPS URI to a media identifier of type 'sound:' will cause the Asterisk core to go ahead and pull the media from the provided HTTP/HTTPS URI. That is, something like this will work: POST /channels/my_unique_id/play?media=sound: http://remote_ip_address/foo.wav (Note that you'd obviously want to URL encode the URI of the media to be retrieved) This works as well, of course, with JSON bodies POSTed. I've updated the feature description accordingly [2]. Note that I do think Ben Langfeld's comments about supporting text/uri-list is reasonable, and would be useful in the long run. In the short term, at least, this feature does work from ARI. Matt [1] https://wiki.asterisk.org/wiki/display/AST/Asterisk+14+Documentation [2] https://wiki.asterisk.org/wiki/display/AST/Asterisk+14+Project+-+URI+Media+Playback -- Matthew Jordan Digium, Inc. | CTO 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA Check us out at: http://digium.com & http://asterisk.org -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] ARI StasisEnd event vs. channel variables
On Tue, Oct 18, 2016 at 4:02 PM, Joshua Colp wrote: > Matthew Jordan wrote: > > > > >> There are a few wrinkles with emitting channel variables with >> arbitrary events (of which StasisEnd would qualify). >> >> When an event is emitted out of the APIs, it's typically being done so >> as a result of a message having been published on the Stasis message >> bus. The messages on the bus don't contain a reference to a channel, >> but rather a snapshot of the channel. Those snapshots, by default, >> don't contain any channel variables, primarily for performance >> reasons. Additionally, since dialplan functions can be freely >> interchanged with channel variables, it's impossible (or very costly) >> to evaluate dialplan function expressions on each snapshot creation. >> >> Unfortunately, you really do need to rely on the messages coming >> across the bus. By the time code is processing the sending of a >> StasisEnd event, the ast_channel itself may already be gone. As such, >> the variables have to be stored on the snapshot in some fashion. >> >> AMI accomplished this by creating a core concept known as 'manager >> variables'. These are set directly on the ast_channel structure, and - >> when a snapshot is created - are evaluated and copied onto the >> snapshot. Again, this is a rather costly operation, but it does limit >> the impact of including variables on messages, as you have to >> explicitly tell Asterisk which state you want transmitted along with >> the channel. >> >> If we wanted a similar concept in ARI, the manager variables could be >> reused. I would note that you absolutely will take a performance hit >> when using them - building and conveying that much state in every >> event is not cheap. Because StasisEnd is rather 'special' - often the >> channel core isn't aware of it - I'm not sure how you would convey >> variables only on that event and not on all the rest. > > > The actual raising of StasisEnd is explicitly done inside of Stasis and > lives there. When raised the channel is there and valid. It currently uses a > channel blob as the payload but this could be changed to something else that > would allow channel variables (only channel variables explicitly set on the > channel) to also be added. This would scope the channel variables addition > to only StasisEnd. Now... if we wanted channel variables on every message... > then yeah, it would be difficult. > Two thoughts: (1) I wonder if anyone needs the state conveyed on events other than StasisEnd? If Asterisk is maintaining all of your state for you, and you need to know some part of the state in your external application, how do you ask for it? (2) Even if we emit variable state on StasisEnd, how would we know which state to emit? Would we want to require users to provide it up front in ari.conf, or through some more dynamic mechanism? -- Matthew Jordan Digium, Inc. | CTO 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA Check us out at: http://digium.com & http://asterisk.org -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] ARI StasisEnd event vs. channel variables
On Tue, Oct 18, 2016 at 9:26 AM, Joshua Colp wrote: > Matt Fredrickson wrote: > > > >> >> First off, sorry about the delayed response. Your proposal sounds >> reasonable to me - that is to say, I can't see anything wrong with >> adding that behavior. Perhaps making channel variable dumping on >> StasisEnd optional instead of mandatory would be better, but other >> than that everything seems sane. Maybe Josh or Mark might want to >> weigh in on it. > > > I don't think that channel variables are substantial enough in the case > where this isn't being used to really need to adding a knob to turn it > on/off. That's just me, though. > There are a few wrinkles with emitting channel variables with arbitrary events (of which StasisEnd would qualify). When an event is emitted out of the APIs, it's typically being done so as a result of a message having been published on the Stasis message bus. The messages on the bus don't contain a reference to a channel, but rather a snapshot of the channel. Those snapshots, by default, don't contain any channel variables, primarily for performance reasons. Additionally, since dialplan functions can be freely interchanged with channel variables, it's impossible (or very costly) to evaluate dialplan function expressions on each snapshot creation. Unfortunately, you really do need to rely on the messages coming across the bus. By the time code is processing the sending of a StasisEnd event, the ast_channel itself may already be gone. As such, the variables have to be stored on the snapshot in some fashion. AMI accomplished this by creating a core concept known as 'manager variables'. These are set directly on the ast_channel structure, and - when a snapshot is created - are evaluated and copied onto the snapshot. Again, this is a rather costly operation, but it does limit the impact of including variables on messages, as you have to explicitly tell Asterisk which state you want transmitted along with the channel. If we wanted a similar concept in ARI, the manager variables could be reused. I would note that you absolutely will take a performance hit when using them - building and conveying that much state in every event is not cheap. Because StasisEnd is rather 'special' - often the channel core isn't aware of it - I'm not sure how you would convey variables only on that event and not on all the rest. -- Matthew Jordan Digium, Inc. | CTO 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA Check us out at: http://digium.com & http://asterisk.org -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] Retransmission timeout reached on transmission
On Fri, Oct 14, 2016 at 12:11 AM, Prakash Agrawal wrote: > Hi, > > I am not able to make a call from OriginateAction using Asterisk AMI for > first time. > > I am trying to call usiing Zoiper, AMI and Asterisk.I am using > OriginateAction of AMI to call. > I make a first call from Zoiper(Softphone) and disconnect the call. Then i > call using OriginateAction and the call is connecting. > But when I leave my system idle for sometime and again try to connect using > OriginateAction it is throwing the error. > > chan_sip.c:4059 retrans_pkt: Retransmission timeout reached on transmission > 0d8153c274a41616484168e3180f9fbf@192.168.230.128:5060 for seqno 102 > (Critical Request) -- See > https://wiki.asterisk.org/wiki/display/AST/SIP+Retransmissions > Packet timed out after 32000ms with no response > The asterisk-dev list is used for discussion regarding the development of Asterisk, not for assistance in its usage. Please ask your question on the asterisk-users mailing list [1] or on the community forums [2]. [1] http://lists.digium.com/mailman/listinfo/asterisk-users [2] https://community.asterisk.org/ -- Matthew Jordan Digium, Inc. | CTO 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA Check us out at: http://digium.com & http://asterisk.org -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] Viva Chan_Sip, may it rest in peace
der audience. So let's discuss. >> >> Currently, Asterisk is running dual sip stacks. The argument is that to >> deprecate PJSIP there must be broader adoption. There is currently nothing >> motivating adoption but much slowing it. >> >> What are some of the hurdles to adoption? >> 1. Apathy. If it ain't broke don't fix it. Many would argue chan_sip is >> broke but it is the "devil you know". A decade of documentation and a broad >> user base allows people to be pretty forgiving of flaws. Almost any issue >> has some sort of work around or generally accepted idea of I guess we can >> live with it. >> >> 2. One Ring to rule them all!! PJSIP requires up to 6 sections of >> configuration. Once you dig in, this method makes sense. But at a glance, >> you have just multiplied the workload to 6 times that of chan_sip's single >> blob config. Though it is not really 600% more effort it may be enough to >> scare some away >> >> 3. Mo Adoption, Mo problems! >> The only way to clean up all the edge cases and weird bugs is to hit them >> in the first place. Dogfooding only gets you so far. You can make anything >> working clean in a single environment and single use case. But what happens >> when people start flinging wrenches. Things break. 100 wrenches may break 10 >> things. 1000 wrenches may break 100 things. In the ladder case, you have >> 100 people saying pjsip sucks, and pjsip is crap. As with all things the 900 >> assume all is good and move on with their lives telling no one of their >> glory. So you have 10% of the voices running unopposed. You fix the 100 >> issues and that is great but those 100 people have gone back to the comfort >> of chan_sip and are stuck at point 1. >> >> Escaping the cycle. >> >> So how do we dredge through this mess and get high adoption? >> >> You have to make #1 not an option. This means potentially breaking the >> universe. This is why I think there is a tendency to be gunshy. No one wants >> to be the guy who broke the universe. But breaking the universe gets us to >> #3 without falling back into #1. Once The universe breaks and we are in #3 >> many of the edges will be found and fixed. Suddenly PJSIP becomes usable in >> most, if not all situations. The issues in #2 will automatically resolve as >> there is more information and it becomes the "accepted way" of doing things. >> The old dogs will have to refactor how they do configuration but I am >> confident once they do a few they will figure out the bark is bigger than >> the bite. >> >> tl;dr to get adoption you have to force it. There will be blood, but >> nothing that can't be cleaned up with a little bleach and some elbow grease >> >> -- >> James >> >> -- >> _ >> -- Bandwidth and Colocation Provided by http://www.api-digital.com -- >> >> asterisk-dev mailing list >> To UNSUBSCRIBE or update options visit: >>http://lists.digium.com/mailman/listinfo/asterisk-dev > > > > -- > _ > -- Bandwidth and Colocation Provided by http://www.api-digital.com -- > > asterisk-dev mailing list > To UNSUBSCRIBE or update options visit: >http://lists.digium.com/mailman/listinfo/asterisk-dev -- Matthew Jordan Digium, Inc. | CTO 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA Check us out at: http://digium.com & http://asterisk.org -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] Working Groups
oper in the community can use as a guide. That isn't to say that I think the output of working groups would be ignored - far from it, as I think everyone would benefit from this process - but the more ambitious the recommendation, the more difficult it is to build consensus and resources to accomplish the goal. Having expectations be set would be good to avoid disappointment. Matt -- Matthew Jordan Digium, Inc. | CTO 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA Check us out at: http://digium.com & http://asterisk.org -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] [asterisk-commits] format ogg opus: New format (asterisk[master])
On Tue, Oct 4, 2016 at 4:41 PM, ApexVitality wrote: > unsubscribe me from this list or any other list pls > Instructions are at the bottom of every e-mail: > asterisk-dev mailing list > To UNSUBSCRIBE or update options visit: >http://lists.digium.com/mailman/listinfo/asterisk-dev -- Matthew Jordan Digium, Inc. | CTO 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA Check us out at: http://digium.com & http://asterisk.org -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] BRIDGEPEER on multi-party conferences: Thoughts?
On Wed, Aug 10, 2016 at 10:42 AM, Richard Mudgett wrote: > > > On Tue, Aug 9, 2016 at 6:01 PM, Mark Michelson > wrote: >> >> Hi folks, >> >> I've been looking into a Digium customer issue where ConfBridge audio has >> been dropping out. The main issue there had to do with DNS, and there is >> currently a review [1] up to fix that. >> >> A secondary issue, though, is that there would be brief audio cutouts when >> participants joined and left the conference. Looking into it, I believe the >> problem is that when a participant enters or leaves the bridge, the >> BRIDGEPEER channel variable is updated for every remaining participant in >> the bridge. The basic algorithm is like this: >> >> * Lock the bridge >> * Iterate through the channels in the bridge (a maximum of 11 of them) >> * Lock the channel >> * Append the channel to an array of channel names >> * Unlock the channel >> * Iterate through the channels in the bridge again (no upper limit this >> time) >> * Lock the channel >> * Set the BRIDGEPEER channel variable using the names in the generated >> array from before (comma-separated) >> * Unlock the channel >> * Unlock the bridge >> >> In addition, this same process occurs every time an announcement is played >> into a bridge, such as join/leave beeps. Playing an announcement involves >> pushing an announcer channel into the bridge and then removing the announcer >> channel when the playback completes. >> >> My question to the list is this: do you find value in having the >> participants in a multi-party bridge packaged into the BRIDGEPEER channel >> variable? I know that for two-party bridges, there are probably lots of >> scripts and dialplans out there that rely on that variable to be set; my >> question specifically is for bridges with more than two parties. >> >> My thoughts on the matter are that since bridges are query-able now >> directly, getting the list of participants from the bridge makes more sense >> than trying to get the participants based on a single channel in that >> bridge. In addition, the code places a hard limit on the number of channel >> names it will actually put in the BRIDGEPEER variable. The code currently >> has a #define that makes it so that only the first 11 channels in the bridge >> will have their names in BRIDGEPEER. Because of the hard-coded maximum, if >> you have more than 11 channels in the bridge, you can't get the full list of >> participants using BRIDGEPEER. > > > Relying on BRIDGEPEER for only two party bridges will break down when you > consider that > ad-hock multi-party bridges are now allowed. A bridge may start out being > two party but wind up > with multiple participants due to the DTMF transfer feature allowing ad-hock > multi-party bridges. > > The upper limit of 11 is bowing to reality that BRIDGEPEER is not a good way > to get participants > for larger multi-party bridges. > I know ad-hoc multi-party bridges are why we ended up going with the approach that we did. I think the issue that Mark outlines, however, shows that the implications of the approach in large multi-party bridges - ad-hoc or otherwise - becomes prohibitive. Corey's suggestion of having the same behavior, but only calculating it when someone asks for BRIDGEPEER - seems like a reasonable middle ground. The downside is just that there won't be any events fed to people, which means people who have built systems looking for those events are going to be broken. I suppose we could do the 'unfortunate' thing of having an asterisk.conf (or some other relatively low level configuration file) that sets whether or not BRIDGEPEER is evaluated on the fly or all the time in 13/14, and in master, simply change it to a request-only variant. -- Matthew Jordan Digium, Inc. | CTO 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA Check us out at: http://digium.com & http://asterisk.org -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] BRIDGEPEER on multi-party conferences: Thoughts?
On Wed, Aug 10, 2016 at 10:11 AM, Corey Farrell wrote: > It might be a problem if BRIDGEPEER is being compared to an empty string to > see if a channel is alone. > > What if you made BRIDGEPEER into a built-in channel variable (like > ${EPOCH}). This would mean that you wouldn't be setting any channels, you'd > only do a lookup when requested. One side-effect is that VarSet events > would never be produced for this variable, not sure how much this would > matter given better events to monitor ConfBridge joins/parts? > I think fixing this is going to be a breaking change no matter what we do. Having a 'pull' mechanism that still results in the same output is nice, in that if someone *were* relying on getting some form of list of the participants, they can still do so. I will say that removing the VarSet for BRIDGEPEER would break a fair number of testsuite tests, although that shouldn't be a reason not to do the change. It is evidence, however, that we ourselves relied on the setting of BRIDGEPEER to get an indication of who the channel was in a bridge with. -- Matthew Jordan Digium, Inc. | CTO 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA Check us out at: http://digium.com & http://asterisk.org -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] Asterisk goes Spatial Conferencing: the STEAK project
Hi Dennis: Apologies for not responding quicker to your e-mail - I've been on vacation the last week and a half. Some comments inline below. On Sat, Jul 23, 2016 at 3:50 AM, Dennis Guse wrote: > Then lets get started. > Due to the relatively large number of changes, we will split them up > into individual patches: Individual patches are great! Smaller changes are always easier to review. > 1) Support for interleaved stereo (mainly softmix and struct channel) > 2) Extension of confbridge with binaural synthesis via convolution (if > channel supports stereo) > > For the patches, we will remove the hard dependency to OPUS (although > we will stick to using it) and also enable L16 with stereo. > > Nevertheless, there are still some open questions: > > 1. Storage and description of HRTFs > Impulse responses are at the moment compiled into Asterisk as a header file. > This header file is generated using a custom C-program converting a > multi-channel wave file into a float-array - hrirs_fabian.wav was > taken from the SoundScapeRenderer > https://github.com/SoundScapeRenderer/ssr/tree/master/data/impulse_responses/hrirs > > For positioning a sound source, the HRTFs for the left and for the > right ear need to be selected according to the desired angle. > This information is at the moment hard-coded as we use a 720-channel > wave (interleaved: left, right) to cover 360 degrees completely. > > Would you prefer to compile the HRTFs into Asterisk (incl. the > hard-coded description) or rather make this configurable? > For the second option, we would need some support in terms of how to > add configuration options. For an initial implementation, I would recommend hard-coding it. If a different data set is needed for different listeners, that would be an improvement that someone could make at a latter time. > 2. Configuration of positioning of conference participants > The positioning of individual participants is at the moment hard-coded > (compiled via header-file). > This is basically an array containing the angles at which participant > _n_ is going to be seated. > This could also be made configurable via configuration file. > > Furthermore, all participants of a conference receive the _same_ > acoustical environment (i.e., participant 1 always sits in front of > the listener etc.). > This limits the computational requirements while individual listeners > cannot configure their desired seating order. > In fact, the own signal of a participant is subtracted after rendering > the whole environment before sending the signals back. Again, I would punt on making this configurable. If the default experience is "good enough", effort put into making this configurable will be wasted. If it is not "good enough", then effort could be expended into making it configurable. > 3. Internal sampling rate of Confbridge > The binaural synthesis is at the moment conducted at 48kHz. > This is actually due to our use of OPUS, which always uses 48kHz for > the decoded signals. > Is this ok? I'm not sure I have a good answer to this. I think it depends on what the experience is like if a lower sampling rate is used. What happens if the sampling rate used in the conference is 8kHz or 16kHz? > 4. Is the dependency to libfftw3 an issue? libfftw3 if GPLv2, so no, it should not be an issue. https://github.com/FFTW/fftw3/blob/master/COPYING That being said, it should not be a hard dependency. If libfftw3 is not installed, the feature should simply not be available. -- Matthew Jordan Digium, Inc. | CTO 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA Check us out at: http://digium.com & http://asterisk.org -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] Asterisk goes Spatial Conferencing: the STEAK project
On Tue, Jul 19, 2016 at 4:59 PM, Matt Fredrickson wrote: > On Tue, Jul 19, 2016 at 12:59 PM, Sean Bright > wrote: > > On 7/19/2016 10:35 AM, Matt Fredrickson wrote: > >> > >> Response below. > >> > >> On Mon, Jul 18, 2016 at 7:18 AM, Dennis Guse > >> wrote: > >>> > >>> Technical Details (at the moment the modifications are based upon > >>> 13.6.0): > >>> * Enabled OPUS (with incoming stereo and outgoing stereo [interleaved]) > >>> * Extended softmix for stereo support (downmixing) > >>> * Extended the default confbridge (basically added a convolution > engine) > > > > > > If Opus is a required part of the implementation - and from reading the > > description of the work being done it appears to be - wouldn't that make > > this ineligible for inclusion? > > My hope is that there is a large amount of core Asterisk work which > does not explicitly require Opus for it to be merged. I'm hoping that > our current Opus legal impasses will not go on forever, but until > things clear up with regards to it, this is the best response I can > give. > > The only thing that we can't include at this time is the codec module itself, which - if implemented correctly - should be a separate shared object library. That means that all the rest can be put up for code review, and anyone who wants to take advantage of the new feature(s) can simply load an externally available codec_opus. So - if you're interested - please do contribute the patches back upstream. -- Matthew Jordan Digium, Inc. | CTO 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA Check us out at: http://digium.com & http://asterisk.org -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] Development of asterisk 1.4.23 Can we please get some development?
On Thu, Jul 14, 2016 at 5:25 PM, Loren Tedford wrote: > I have only been using the project since 2013 I had no idea at the time > what version of asterisk was being used to install the modules needed.. > > Forgotten or not this is where we stand with it now.. > > Even if a developer donated 20 minutes on it a week that adds up to > roughly 17 hrs of possible improvement from what we got.. > > I have experimented with trying to cobble things together on older > versions of asterisk what i generally find is it literally barfs all over > the place.. It really seems like they have changed some thing in the way > asterisk handles the transmit and receive sides of everything.. To my > knowledge I do not see any developers with in the app_rpt actually posting > any work or upgrades to the project.. I figured since asterisk was asterisk > at one point in time developers might at least be interested in helping out > or donating some time.. > > Their is alot of cool things that could be done with it if it was > integrated with asterisk phone system today even in the commercial world.. > > I wonder what exact core changes occurred to create the problem we have > today and is it reversible or do we need to completely redesign asterisk.. > > The modules you are referring to were removed quite awhile ago due to not having an active maintainer contributing to the project [1]. Since no one active in the project used the modules, or could verify their functionality, and those who were using them had forked Asterisk completely, we opted to remove them rather than ship broken or vulnerable code. I do not think that anyone in Digium is interested in maintaining these modules, nor is anyone here interested in doing the port of the old 1.4 modules to the existing code base. I think all of us would be happy to answer questions, but someone else in the greater Asterisk community would have to do the work and commit to being the maintainer of those modules. Asterisk is an open source project. As an open source project, anyone - absolutely *anyone* - can step up, modify the existing app_rpt/chan_usbradio/core of Asterisk, and submit the patches back to the project. We have a lot of resources to help with that: (1) Coding guidelines so that your submission fits within the standards of the rest of the project [2] (2) A well defined process for submitting patches to the project [3], participating in code review [4], and understanding the kinds of things reviewers will look for in submissions [5] (3) An automated test suite for verifying functionality [6], with a Jenkins based open source infrastructure definition [7] that trigger on patch submission (4) This mailing list, for when you have questions about the code and get stuck (5) The #asterisk-dev IRC channel, for when you want your questions answered in real-time If you're interested, you may want to review the resources mentioned above and linked below, and familiarize yourself with the major changes in Asterisk from 1.4 to now. The most influential of those would be: (1) The API changes made in DAHDI, which - if I understand correctly - were never adopted by the modules and were the first breaking change (2) The adoption of reference counted semantics for ast_channel done in Asterisk 1.8 (3) The opaquification of the ast_channel structure done in Asterisk 11 (4) If any native bridging is used anywhere, the bridging framework introduced in Asterisk 12 (5) The stasis message bus as a mechanism to raise information to reporting systems (CDR, CEL, AMI), introduced in Asterisk 12 Matt [1] https://reviewboard.asterisk.org/r/1764/ [2] https://wiki.asterisk.org/wiki/display/AST/Coding+Guidelines [3] https://wiki.asterisk.org/wiki/display/AST/Patch+Contribution+Process [4] https://wiki.asterisk.org/wiki/display/AST/Code+Review [5] https://wiki.asterisk.org/wiki/display/AST/Code+Review+Checklist [6] https://wiki.asterisk.org/wiki/display/AST/Asterisk+Test+Suite+Documentation [7] http://git.asterisk.org/gitweb/?p=asterisk/infrastructure.git;a=summary -- Matthew Jordan Digium, Inc. | CTO 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA Check us out at: http://digium.com & http://asterisk.org -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] Asterisk Load Performance
On Wed, Jul 6, 2016 at 2:20 PM, Michael Petruzzello < michael.petruzze...@civi.com> wrote: > On Tue, Jul 5, 2016 at 4:03 PM, Jonathan Rose motorolasolutions.com> wrote: > > > If you don't need all of your participants actually to be speaking at a > > time (and I hope not with that kind of volume), you could use holding > > bridges for the vast majority of the partipants. Link the bridges using a > > local channel with the Hold bridge side being set to use the 'announcer' > > bridge role and the hold bridge will effectively just be voiceless > > conference participants. If you want, you can listen for DTMF events to > > move the participants back and forth between the different bridges. > > Doing the conference this way results in the same kind of long voice queue > warnings/errors as before and eventually the DNS lookup for the server > fails. All 5,000 callers were able to get in though, which is a bit better > than before. > > On Tue, Jul 5, 2016 at 5:09 PM, *Richard Mudgett <http://digium.com>*> wrote: > > > The exceptionally long voice queue length messages can be a symptom of > > thread > > starvation as the Local channels frame queue has developed an excessive > > backlog. > > > > The forthcoming v13.10.0 release should indirectly take care of the > EEXISTS > > messages > > as part of the https://issues.asterisk.org/jira/browse/ASTERISK-26088 > fix. > > Working on > > that issue I saw the EEXISTS messages for REGISTER and SUBSCRIBE message > > processing. The issue was a result of the original message and > > retransmissions getting > > backlogged in the serializer/taskprocessor and responses sent using > another > > serializer. > > > > Looks like your system's DNS resolver has gotten overwhelmed. > > Is there any configuration changes I can make to help alleviate the thread > starvation on the Local channels frame queue? > > It does not make sense to me that the system's DNS resolver is getting > overwhelmed. When I have 10,000 calls in one bridge, this does not occur. > When I have multiple bridges with locally originated channels bridging them > then the DNS errors occur. > > > Wow. Thanks Jonathan. I hadn't thought of doing it that way. That > should > > really drop the mixing load. > > Probably should allow only ulaw or alaw (pick one) for all participants > to > > minimize translation costs. > > One additional thing I should add is that those linking Local channel > > bridges should just allow the > > chosen alaw/ulaw to reduce translation to each participant in the holding > > bridge. The forthcoming > > v13.10.0 adds the ability to specify formats when ARI originates a > channel > > (Local in this case) and > > an originator channel is not available. (See CHANGES file) > > I have only been allowing ulaw. That is very interesting to note about the > Local channels. I'll keep that in mind. > > Well, thank you Jonathan, Richard, and Matthew. You have all been really > helpful. This has been really interesting trying to get 10,000 callers on > one Asterisk server. As Asterisk is not capable on one server for what I am > trying to do, I am going to design a scalable, multi-server architecture > instead. > While that's definitely a more sustainable approach, it has been awfully entertaining/interesting to see how far you were able to take it. I think everyone was pretty impressed when you hit 5000 channels in a single bridge. Thanks for giving it a shot! As an aside, what were you using to simulate the callers? SIPp + a pcap file, or something else? Matt -- Matthew Jordan Digium, Inc. | CTO 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA Check us out at: http://digium.com & http://asterisk.org -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] ASTERISK-26145 - Task Process Issues possibly caused by HEP
On Tue, Jun 28, 2016 at 9:48 AM, Matt Fredrickson wrote: > On Tue, Jun 28, 2016 at 8:54 AM, Ross Beer wrote: >> Hi, >> >> >> I am still facing a task processor issue on subm:rtp_topic-00de, looking >> at the backtrace it looks to be related to HEP. > > Sounds like you're having some good luck sleuthing :-) > >> HEP is enabled by default and sends packets to 192.168.1.1:9061, shouldn't >> this be disabled by default and not enabled in Asterisk 13? It makes no >> sense to send packets if you can't be sure that a HEP server exists at the >> default server location. > > I'd tend to agree with that logic. I haven't done much work with HEP, > but if HEP is enabled by default, we should probably change that > behavior. HEP should only be enabled if you "opt in" by setting it > up. > > Just my .02. > > Anybody else have any thoughts? > I don't really care if they are enabled by default or not. For the most part, most modules in Asterisk are 'opt-out', not 'opt-in', but it doesn't really matter to me. Alternatively, instead of disabling the modules from building, the HEP modules can be disabled by setting the 'enabled' option to 'no' - which could also be changed in the sample config file. I will say that if you're installing the sample config files and not updating them - particularly for things that you aren't interfacing to - then you're setting up your systems poorly. The sample config files have long been used for documentation purposes - running 'make samples' and walking away is going to give you a bad time, and not just because of the HEP modules. Since these are just config file modifications we're talking about, a patch should be provided and submitted to Gerrit. This is a patch that anyone - including the issue reporter - could write. To echo what Josh said, this doesn't really merit a lengthy discussion on the mailing list, nor does it require 'poking' developers. Matt -- Matthew Jordan Digium, Inc. | CTO 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA Check us out at: http://digium.com & http://asterisk.org -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] Asterisk Load Performance
;> processing time and the CDR taskprocessor queue backlog can take >> >> minutes to >> >> clear. >> >> >> > >> >To echo what Richard said, because Asterisk is now sharing state >> >across the Stasis message bus, turning off subscribers to that bus >> >will help performance. Some easy ones to disable, if you aren't using >> >them, are CDRs, CEL, and AMI. Those all do a reasonable amount of >> >processing, and you can get some noticeable improvement by disabling >> >them. >> > >> >Once you get past that, you can start fiddling with some of the lower >> >level options. To start, you can throttle things back further by >> >disabling certain internal messages in stasis.conf. As stasis.conf >> >notes, functionality within Asterisk can break (or just not happen) if >> >some messages are removed. For example, disabling >> >'ast_channel_snapshot_type' would break ... most things. You may >> >however be able to streamline your application by looking at what ARI >> >messages it cares about, what messages it doesn't, inspecting the >> >code, and disabling those that you don't care about. Lots of testing >> >should occur before doing this, of course. >> > >> >You may also be able to get some different performance characteristics >> >by changing the threadpool options for the message bus in stasis.conf. >> >This may make a difference, depending on the underlying machine. >> >> Thank you for the suggestions. >> >> I'm running Asterisk on 40 vCPUs with 120 GB of RAM. Changing the thread >> pool options to many more threads is not increasing performance, and at a >> certain point it decreases performance. >> >> With further testing and having implemented your suggestions, I am >> realizing the subm:devService-test-0038 task processor is a major >> bottleneck. I have always read that Asterisk can handle as many calls as the >> hardware allows, but I'm not seeing that. >> >> I can go with a different architecture of multiple Asterisk servers >> working together, but I would prefer one server to reduce complexity. >> >> What I am doing is not really a stress test because I really need Asterisk >> to handle 1000s of callers calling in within a few minutes. > > > The subm:devService-test-0038 taskprocessor is servicing the stasis > message bus > communication with your devService-test ARI application. Since each > taskprocessor is > executed by one thread, that is going to be a bottleneck. One thing you can > try is to > register multiple copies of your ARI application and randomly spread the > calls to the > different copies of the application. (devService-test1, > devService-test2,...) > To follow up with Richard's suggestion: Events being written out (either over a WebSocket in ARI or over a direct TCP socket in AMI) have to be fully written before the next event is written. That means that the client application processing the events can directly slow down the rate at which events are sent if the process that is reading the event does not keep reading from the socket as quickly as possible. You may already be doing this - in which case, disregard the suggestion - but you may want to have one thread/process read from the ARI WebSocket, and farm out the processing of the events to some other thread/process. -- Matthew Jordan Digium, Inc. | CTO 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA Check us out at: http://digium.com & http://asterisk.org -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] Asterisk Load Performance
On Fri, Jun 17, 2016 at 1:37 PM, Richard Mudgett wrote: > > > On Fri, Jun 17, 2016 at 12:36 PM, Michael Petruzzello > wrote: >> >> Hello, >> >> I am currently working on determining bottlenecks in Asterisk and a Stasis >> App. I'm currently trying to handle 83.3 calls/second. For the most part, >> Asterisk and the Stasis APP handle that well, but there is a 60+ second >> delay in response time. >> >> On the Asterisk side, I am seeing the following warnings. [Jun 17 >> 12:00:16] WARNING[23561]: taskprocessor.c:803 taskprocessor_push: The >> 'subm:cdr_engine-0003' task processor queue reached 500 scheduled tasks. >> [Jun 17 12:00:18] WARNING[25477][C-0068]: taskprocessor.c:803 >> taskprocessor_push: The 'subm:devService-test-0038' task processor queue >> reached 500 scheduled tasks. >> [Jun 17 12:00:21] WARNING[26298][C-00a3]: taskprocessor.c:803 >> taskprocessor_push: The 'subp:PJSIP/sippeer-0022' task processor queue >> reached 500 scheduled tasks. >> [Jun 17 12:00:23] WARNING[27339][C-010d]: taskprocessor.c:803 >> taskprocessor_push: The 'subm:ast_channel_topic_all-cached-0032' task >> processor queue reached 500 scheduled tasks. >> [Jun 17 12:01:32] WARNING[31697][C-03b2]: taskprocessor.c:803 >> taskprocessor_push: The 'subm:ast_channel_topic_all-0036' task processor >> queue reached 500 scheduled tasks. >> [Jun 17 12:05:55] WARNING[23280]: taskprocessor.c:803 taskprocessor_push: >> The 'SIP' task processor queue reached 500 scheduled tasks. >> >> I have not seen a configuration setting on Asterisk to prevent these >> warnings from occurring (I'm trying to avoid modifying Asterisk source code >> if possible). Looking at the task processors, I see the queue to the stasis >> app bottlenecks: >> subm:devService-test-00384560990 0 >> 1041689. It does clear up relatively quickly. The CDR engine also bottle >> necks (extremely badly), but I don't use that. Nothing else comes close to >> having a large queue. >> >> The stasis app itself is extremely streamlined and is very capable of >> handling a large number of messages at a time. The app runs with the JVM so >> I am also researching into that as well as the netty library I am using for >> the websocket connections. >> >> Any insight into Asterisk's side of the equation and how it scales on 40 >> vCPUs would be greatly appreciated. > > > There are no options to disable those taskprocessor queue size warnings. > They are a > symptom of the system being severely stressed. If the stress continues it > is possible > that the system could consume all memory in those taskprocessor queues. > > Recent changes to the Asterisk v13 branch were made to help throttle back > incoming > SIP requests on PJSIP when the taskprocessors become backlogged like you are > seeing. > These changes will be in the forthcoming v13.10.0 release. If you want, you > can test with > the current v13 branch to see how these changes affect your stress testing. > > If you don't need CDR's then you really need to disable them as they consume > a lot of > processing time and the CDR taskprocessor queue backlog can take minutes to > clear. > To echo what Richard said, because Asterisk is now sharing state across the Stasis message bus, turning off subscribers to that bus will help performance. Some easy ones to disable, if you aren't using them, are CDRs, CEL, and AMI. Those all do a reasonable amount of processing, and you can get some noticeable improvement by disabling them. Once you get past that, you can start fiddling with some of the lower level options. To start, you can throttle things back further by disabling certain internal messages in stasis.conf. As stasis.conf notes, functionality within Asterisk can break (or just not happen) if some messages are removed. For example, disabling 'ast_channel_snapshot_type' would break ... most things. You may however be able to streamline your application by looking at what ARI messages it cares about, what messages it doesn't, inspecting the code, and disabling those that you don't care about. Lots of testing should occur before doing this, of course. You may also be able to get some different performance characteristics by changing the threadpool options for the message bus in stasis.conf. This may make a difference, depending on the underlying machine. -- Matthew Jordan Digium, Inc. | CTO 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA Check us out at: http://digium.com & http://asterisk.org -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] Help for developing a channel driver module
On Mon, May 23, 2016 at 2:23 AM, Gilles Mazoyer wrote: > Hi > > Thank you for the information. > That's what i already do so no need to change my module. Good !!! > Hi Gilles - One other hopefully useful comment I could make is to follow the models of the newer channel drivers, as opposed to some of the older ones. Over time, the developer community has moved towards splitting channel drivers up into components, as opposed to lumping all of the functionality into a single monolithic file/module. This greatly aids maintainability. While it is somewhat an extreme example of this, the PJSIP channel driver consists of: - The channel driver (chan_pjsip), which acts as a bridge between the Asterisk channel core and the rest of the protocol stack - The basic protocol stack (res_pjsip), which interfaces with the PJSIP library and provides major functionality for the SIP protocol - Specific modules that build on aspects of the SIP protocol, such as res_pjsip_session for requests the create media sessions, res_pjsip_registrar for handling registrations, etc. - And even more specific modules for very specific SIP features, such as dialog info bodies I'd encourage anyone writing a new channel driver to think of splitting the functionality up into - at a minimum - separate files. Keeping the Asterisk channel core integration separate from the protocol handling itself generally keeps things a lot cleaner. Hope this helps - Matt -- Matthew Jordan Digium, Inc. | Director of Technology 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA Check us out at: http://digium.com & http://asterisk.org -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
[asterisk-dev] Asterisk 14 Feature Freeze Reminder
Hello everyone! As you may or may not be aware, today is the feature free reminder [1] for the next version of Asterisk. This is a notice that Asterisk 14 will be feature frozen on July 20th, 2016. Having the branch be feature frozen gives the Asterisk Developer Community time to test out the new features and improvements that have been made to master since the last major release, Asterisk 13. "But wait," you may ask yourself. "What does 'feature freeze' even mean if we are adding new features to Asterisk 13?" Good question! On July 20th, the Asterisk team will create the Asterisk 14 branch, along with a branch specifically for the first release of Asterisk 14, 14.0.0. As new features are developed, they can be proposed both for Asterisk 13 as well as for the Asterisk 14 mainline branch, subject to the 'you must have tests for release branches' policy [2]. Meanwhile, the Asterisk 14.0.0 branch will remain frozen, and the first beta/release candidates will be cut from it. When Asterisk 14.1.0 is released, it will contain any minor new features or improvements that were made in the meantime and were merged into the Asterisk 14 mainline branch. This policy balances the need to test out the new changes in master in a version that is not a moving target, while allowing the Asterisk Developer Community to continue to improve and enhance Asterisk. Happy Coding - Matt [1] https://wiki.asterisk.org/wiki/display/AST/Asterisk+Versions [2] https://wiki.asterisk.org/wiki/display/AST/Software+Configuration+Management+Policies#SoftwareConfigurationManagementPolicies-NewFeatures -- Matthew Jordan Digium, Inc. | Director of Technology 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA Check us out at: http://digium.com & http://asterisk.org -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] Plan for updating the ARI Swagger Version
On Tue, Feb 9, 2016 at 3:56 AM, Dan Jenkins wrote: > Hi Everyone, > > I've been looking at how we can add proxy support (1) to the Node.js ARI > Client for the past couple of days and have hit a few issues which I'm sure > we'll be able to work out. But this has led me down the path of looking > into the current status of swagger. > > Swagger recently donated it's specification to the OpenAPI initiative and > so the specification is now called the OpenAPI specification. It was also > bumped to version 2.0 (2). While updating a dependency for no real gain > isn't always seen as a good thing. In this case, I feel we are going to get > to a point (and are already nearing it) where tools that we want to use > around swagger will become obsolete for the version of swagger we are using > within Asterisk. > > I've been looking at generating libraries from the swagger specification > and came across many many issues because we're using version 1.1 - the > swagger team were surprised I was even attempting it. The other code > generator I was looking at has a minimum of specification version 1.2. I > fear this issue will only get worse as time goes on. > I do think it would be good for us to upgrade our version of Swagger we're using. We're really using a strange hybrid of 1.1 and 1.2 (mostly 1.1), due to the state of flux the 1.2 specification was in when we added the ARI API to Asterisk. That aside, I will note a few personal issues I have with Swagger: (1) Their version bumps are all major. 1.1 to 1.2 is a massive change; 1.2 to 2.0 is another massive change. They don't adhere to semantic versioning, and you can expect pedantic changes that add little value but break compatibility horribly to be in any version change. Since we wrote our own Swagger generator to build the C code for ARI, this is a major project for Asterisk. (2) As a project, they are absolutely terrible at backwards compatibility; their recent statement of deprecating swagger-tools [1] does not fill me with confidence that they are going to get better at supporting the users of their specification/libraries. We absolutely will be chasing a moving target if we try to keep compatibility with them. (3) This doesn't just impact Asterisk; any client library that works with ARI has to accommodate multiple schema versions. For the ari-py library, that's going to be inherently destructive, as it only understands the 1.1 schema. It also means we can't update our Swagger support without breaking existing applications. All of my griping aside, I do think it is good to update our Swagger version when doing so makes the lives of Asterisk developers better, but I think updating for the sake of staying in lock-step with Swagger is not going to end well for the project. (It honestly feels like chasing Google Talk/Voice and their never-ending changes to their "spec".) > > Now, I'm not saying we need to change it right now, and I know there are > inherent difficulties with upgrading the version of the specification that > we use, as it then ruins libraries that expect to work with swagger version > 1.1 etc, however, I think we do need a plan to update the version - whether > that's with Asterisk 14 or whatever; as long as its on the roadmap then I'm > happy, currently I don't think it is. > > What are people's thoughts? > > I think it would be good to put it on the list of things that would be nice to see in Asterisk 14. I will say that this is one of the very few places in Asterisk where someone without C experience could contribute! The generators are all written in Python, using mustache templates to build out the wiki documentation and C implementation/header files. So long as you don't change the structure of what is fed to the mustache templates, you could conceivably update the JSON and Python interpreters and not have to know a single line of C code. [1] https://github.com/apigee-127/swagger-tools/issues/335 -- Matthew Jordan Digium, Inc. | Director of Technology 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA Check us out at: http://digium.com & http://asterisk.org -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] Proposal to bring pjproject back into the fold
On Wed, Jan 20, 2016 at 11:04 AM, Tzafrir Cohen wrote: > On Wed, Jan 20, 2016 at 09:49:32AM -0600, Matthew Jordan wrote: > > On Wed, Jan 20, 2016 at 8:22 AM, Jared Smith > > > So why is pjproject such a pain? > > > > There's probably a number of reasons, and I'm probably forgetting some, > but > > I'd boil the top ones down to the following: > > > > * pjproject embeds third party libraries. > > > > Some of those third party libraries are also libraries that Asterisk can > > use; if Asterisk needs to use them, you have to tell pjproject to not use > > its embedded version. While it is easy to say that pjproject should "just > > not do that", that misses the original - and still one of the most > common - > > use cases of pjproject; namely, as an embedded systems library. For > people > > building SIP devices on embedded platforms, having embedded versions of > > GSM, SRTP, and other useful libraries is actually advantageous. Packages > > are not usually available for, say, VxWorks, and if I know pjproject can > be > > built using my esoteric toolchain, I don't have to try and make libsrtp > > build as well with it. > > > > As a result, pjproject is highly unlikely to ever remove their embedding > of > > third party libraries, despite our attempts at convincing them to do > that. > > They serve *more* than just the Asterisk project, and our needs are not > > always going to match 100% with theirs. > > > > The implications of that are that we're going to need to work around > and/or > > deal with the third party libraries they embed in some fashion. > > I'm not sure what your exact issue is here. > > Is there any specific library that pjproject currently embeds that can't > be trivially disabled? Do you think there is an issue with pjproject not > defaulting enough to using system libraries where possible? > > > * pjproject static/shared libraries is confusing for many people > > > > It is not uncommon for people to build static libraries of pjproject the > > first time around (missing the instructions to not do that), install > them, > > and run Asterisk. Asterisk then will crash or do something terrible. They > > will then attempt to install the shared object libraries, not removing > the > > static libraries. Asterisk will still run, and now crash in a different > > fashion. They will then attempt to remove the static libraries, and now > > Asterisk will complain that it can't find pjproject because you're using > > RHEL and your pkg-config path isn't set up correctly. > > Hang on. This is RHEL. A stable platform. Why can't they just use > pjproject packages and be done with it? > > The same question could be asked of why they choose to build Asterisk from source. I won't get into why a user may choose to build from source versus install from packages, nor am I going to blame a user for choosing to do so. The user experience in that situation is sub-optimal. Matt -- Matthew Jordan Digium, Inc. | Director of Technology 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA Check us out at: http://digium.com & http://asterisk.org -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] Proposal to bring pjproject back into the fold
t to install the shared object libraries, not removing the static libraries. Asterisk will still run, and now crash in a different fashion. They will then attempt to remove the static libraries, and now Asterisk will complain that it can't find pjproject because you're using RHEL and your pkg-config path isn't set up correctly. Is this all user error? Of course. But this happens *a lot*, and it is signals that there is a problem with the environment that we're expecting people to operate under. Can all of the above issues be alleviated in some fashion via various technical changes? I'd hazard a guess and say "yes". However, I think that even if we alleviate them, we're going to still be left with a situation where the most important functionality in Asterisk - its SIP stack - is more challenging to get configured and set up than what users feel it should be. That's a bad situation for users. I know the packagers feel that having anything embedded or statically linked is worse for users; unfortunately, after witnessing where we're at after nearly three years with the current model, I disagree with that feeling. I think a number of developers in the Asterisk project are frustrated by this situation. There has been a lot of time and energy invested into trying to make the current model work, and we still see a lot of users frustrated by the current requirements we're levying on them. Continuing to throw more development time at a problem to satisfy a small group of people who categorically refuse to brook any compromise is a difficult proposition for me. I'll go so far as to say that in my time on the Asterisk project, I personally feel that the single worst technical decision I've made was in making it so that the only way to use pjproject was via shared object libraries. The pain to users, and the impact this has had on adoption of the PJSIP stack in Asterisk, isn't something I can even begin to calculate. [1] https://wiki.asterisk.org/wiki/display/AST/Building+and+Installing+pjproject -- Matthew Jordan Digium, Inc. | Director of Technology 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA Check us out at: http://digium.com & http://asterisk.org -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] Proposal to bring pjproject back into the fold
On Tue, Jan 19, 2016 at 6:04 AM, Joshua Colp wrote: > George Joseph wrote: > >> I'm VERY frustrated with pjproject right now. Not the software itself >> (well maybe a little) but the fact that troubleshooting is a nightmare >> because we can't control what version of pjproject was installed along >> with Asterisk and we can't control what options it was compiled with. >> This leads to issue where we're getting great debugging from Asterisk >> but nothing at all from pjproject because the user installed from their >> distro and it has no debugging info. So now we have to walk them though >> getting pjproject from source, etc, etc. This can also cause issues >> should Teluu change an API or some behavior that we're not prepared for >> and the user just does a 'yum update pjproject' and Asterisk dies. Then >> there's the issue where even though the verison is the same, the >> compiled-in options differ, some of them quite fatally. That unleashes >> a whole other mess. >> > > There is the middle ground which is keep the ability to link against a > shared system library if present but also bundle a pjproject and use it if > the system library is not present (or you force the bundled version). > I'd certainly still like a packaged pjproject to take precedence if available. This allows package maintainers to meet the guidelines of their distros, and eases their burden. > > pjproject was deeply embedded in 11 and I don't think that was right but >> I think we went too far in 13 by taking the hands-off approach. Maybe >> at the start of 13 it was ok, but we've since put chan_sip into >> "extended" support so we're pushing chan_pjsip as the supported stack, >> instead of it just being optional. Not to mention that chan_sip needs >> res_rtp_asterisk which is also dependent on pjproject. Can you see >> where I'm going? :) >> > > In the current shared library method it is not a hard dependency. > > >> I propose that we bring pjproject into a new 'third-party' directory and >> statically link our res_pjsip* modules to it. We should NOT check it >> into the Asterisk repository however. Instead we should use scripts >> like get_mp3_source to get a specific pjproject version and a 'patches' >> directory that IS checked in that has things we've discovered we need. >> The patches should always be proposed upstream. >> >> It's a lot of work but I'm willing to dig in and I'll bet I could get a >> few volunteers to help. >> > > From a technical perspective you can not statically link each module to > PJSIP, each module will end up with its own isolated running copy. You need > to statically link it into one module (res_pjsip, or res_pjproject for > example) and have it export all of the symbols to everything else. > Additionally because all the symbols aren't actually being used the linker > also likes to remove them unless you do magic to force them to be present > regardless. This is how the PJSIP support was originally developed before > shared library support was added to pjproject. If you go back in time > almost everything needed to make it work in a bundled configuration is > there already. > Would we automatically download and link pjproject when someone runs 'make', or would it require some different make target? -- Matthew Jordan Digium, Inc. | Director of Technology 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA Check us out at: http://digium.com & http://asterisk.org -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] Asterisk - 13.6.0 - While bring up Asterisk seeing error "undefined symbol":
On Thu, Dec 31, 2015 at 6:20 AM, Boobalan M wrote: > Hi Team, > > > > We are encountering below issue often when try to make asterisk up. > > > > " > > [Dec 31 13:31:35] WARNING[17782]: loader.c:553 load_dynamic_module: Error > loading module 'app_voicemail.so': > /usr/lib64/asterisk/modules/app_voicemail.so: undefined symbol: > ast_say_date_with_format > > " > > > > This issue we can able to solve rebuilding whole asterisk only. But some > times, rebuild also doesn't work. > > > > Both Asterisk logs and symbols details of one of the modules( > app_voicemail.so) from error list are attached. > > > > We could see “ast_say_date_with_format” is marked as undefined . This we > are saying from “nm --demangle app_voicemail.so” output. But I am not > sure why it often comes. > > > > Can you please suggestion on this to sort it out since we are facing this > issue very often. > > > ast_say_date_with_format is a function pointer, defined in say.h: SAY_EXTERN int (* ast_say_date_with_format)(struct ast_channel *chan, time_t t, const char *ints, const char *lang, const char *format, const char *timezone) SAY_INIT(ast_say_date_with_format); As the documentation in that header file explains, a module must assign these function pointers if they wish to change the default functionality from the internal implementation in say.c. You'll note that this is done by a constructor function in say.c: /*! \brief * remap the 'say' functions to use those in this file */ static void __attribute__((constructor)) __say_init(void) { ast_say_number_full = say_number_full; ast_say_enumeration_full = say_enumeration_full; ast_say_digit_str_full = say_digit_str_full; ast_say_character_str_full = say_character_str_full; ast_say_phonetic_str_full = say_phonetic_str_full; ast_say_datetime = say_datetime; ast_say_time = say_time; ast_say_date = say_date; ast_say_datetime_from_now = say_datetime_from_now; ast_say_date_with_format = say_date_with_format; } As well, if loaded, app_playback will override this in its say_init_mode function. This allows it to change the hardcoded 'say' functions in the core with the functionality provided by say.conf. All of this is to say: ast_say_date_with_format is absolutely a defined function pointer. I'm not sure what compiler you're using, what you've modified, or how you're building Asterisk, but in all the tens of thousands of builds I've seen done with both gcc and clang, I've never seen either compiler have a problem finding the declaration of this function pointer. The fact that your Errors.txt file is littered with many other symbol resolution issues makes me think that you have 'tweaked' something, attempted to build on a very non-standard platform, or are otherwise operating outside the bounds of the usual build system. Matt -- Matthew Jordan Digium, Inc. | Director of Technology 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA Check us out at: http://digium.com & http://asterisk.org -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] Asterisk - 13.6.0 - Registering OWN Module(Application):
On Tue, Dec 29, 2015 at 11:50 PM, Kirill Marchuk <62...@mail.ru> wrote: > Hi Boobalan > > Can you check your code against this one ? (pretty old, but still > relevant, I guess) > http://blog.russellbryant.net/2008/06/19/how-to-write-an-asterisk-module-part-1/ > > Especially, did you use one of the AST_MODULE_INFO macros ? > > Luck ! > > and Happy New Year! > > Kirill Marchuk > That blog post is still pretty accurate - we haven't changed the semantics of loading/registering a module much over the years. The code in loader.c tells you why this WARNING message is being raised: /* the dlopen() succeeded, let's find out if the module registered itself */ /* note that this will only work properly as long as ast_module_register() (which is called by the module's constructor) places the new module at the tail of the module_list */ if (resource_being_loaded != (mod = AST_DLLIST_LAST(&module_list))) { ast_log(LOG_WARNING, "Module '%s' did not register itself during load\n", resource_in); /* no, it did not, so close it and return */ logged_dlclose(resource_in, lib); /* note that the module's destructor will call ast_module_unregister(), which will free the structure we allocated in resource_being_loaded */ return NULL; } The module's constructor attributes are automatically added by the aforementioned AST_MODULE_INFO macros. Failure to add those will cause your module to not be registered, and hence not be loaded. -- Matthew Jordan Digium, Inc. | Director of Technology 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA Check us out at: http://digium.com & http://asterisk.org -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] Implementing Native Bridging in a DAHDI kernel driver
On Wed, Dec 23, 2015 at 10:27 PM, Fábio Urquiza wrote: > Hi Matthew. I'm current working on the last 11 version. > > Assuming you want to create a two-party 'native' bridge at the Asterisk level, then you'll want to look into the 'bridge' channel driver callback in chan_dahdi as an example to follow. Asterisk will call this channel driver callback with the two channels that are bridged together. In Asterisk 11, chan_dahdi performs the reads on the DAHDI channels and - when a FD on one channel indicates there is data - directly writes the received data from DAHDI out to the other DAHDI channel with no decoding. Note that in Asterisk 12+, this mechanism changed. Instead of using a channel driver callback, a bridging framework is used. That bridging framework has a pluggable interface, allowing a native bridging technology to be written in a separate module (outside of the channel driver) and selected based on criteria it presents to the core. The DAHDI native bridging is now implemented in the bridge_native_dahdi module. Matt -- Matthew Jordan Digium, Inc. | Director of Technology 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA Check us out at: http://digium.com & http://asterisk.org -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] Implementing Native Bridging in a DAHDI kernel driver
On Tue, Dec 22, 2015 at 4:49 PM, Fábio Urquiza wrote: > Hi All, > > I have a PABX hardware composed of several FXO, FXS and E1 cards and a > Digital Matrix IC that commutes TDM between it's channels. The software > that runs the PABX CPU is a embedded linux distribution and I'm planning > using Asterisk as the Softswitch. I've already have developed a driver with > basic functions to detect phone off the hook and dial tones, do ringing and > to commute channels of different cards but now I need to figure out how to > interface that with Asterisk. > > I imagine that I have to implement some DAHDI functions and structures in > order to the Asterisk dahdi_chan detect the cards and map all to spans. The > problem is that the natural flow of a DAHDI call consists getting the TDM > from a channel using dahdi_receive() and sending the TDM to another channel > using dahdi_transmit(), and I need the TDM to be commuted internally in the > driver using the Digital Matrix IC. > > Browsing the Asterisk documentation I came along a concept called "Native > bridging" in which all bridging are done internally, with no TDM going > through the Asterisk. I like to ask you if that is the best approach to > take on that matter and if you have some pointers of how to implement that > concept in the DAHDI driver that I'm writing for this particular hardware. > > Thanks and best regards, > > -Fabio Urquiza > Hi Fabio: The answer to this depends on which version of Asterisk you're targeting. Which version did you have in mind? Matt -- Matthew Jordan Digium, Inc. | Director of Technology 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA Check us out at: http://digium.com & http://asterisk.org -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] Lock inversion deadlock in asterisk-11.21.0-rc1 and probably 12.x and 13.x
On Wed, Dec 23, 2015 at 10:16 AM, Steve Davies wrote: > Thanks Joshua, > > I think I knew that, but felt that it might not be seen in a timely > fashion if that was what I did. > > In hindsight, raising both the email and the ticket would have been best. > My bad - I must be slowing down for Xmas. > > > Better to make sure everyone knows before a release gets made than to let it slip through. Thanks Steve! -- Matthew Jordan Digium, Inc. | Director of Technology 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA Check us out at: http://digium.com & http://asterisk.org -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] app_queue: wrapuptime is intermittently disregarded
On Wed, Dec 16, 2015 at 3:18 AM, Tomec Martin wrote: > Hi all, > > > > I am solving issue ASTERISK-19820 and want to write patch, but I am not > sure if I am on good way. Let me explain the issue: > > When agent in queue hangs up, his status is updated immediately, but the > queue member lastcall time is updated after a while (after some logging > etc.) in function update_queue. So when another caller wants to ring this > agent, it gets new member status (not_inuse) and old queue member data > (with old lastcall time). So wrapuptime is compared to wrong (old) lastcall > time. > > > > My supposed solution is: > > Add new variable „is_in_call“ to struct member > > Set „is_in_call“ to true, when the call starts. > > Set „is_in_call“ to false on hangup callback (in function update_queue). > > Together with wrapuptime check also if „is_in_call“ is set to true. > > > > I don’t know how to determine call start and I am not sure if the variable > should be named „is_in_call“. Any opinions are welcome. > > > > Thanks, > > Martin Tomec > > > Hi Martin: Most of my thoughts on this come from Asterisk 13. Looking at the issue, it appears as if the situation hasn't changed between when that issue was filed and now, so hopefully this line of thinking is applicable to whatever version you're looking at. I can definitely see how this could be a bit racey. We essentially have two things competing here: * The updating of the queue member status in update_status. This is, interestingly enough, updated via a device state change or extension state change. Even all the way back in 1.8 - and earlier - this would be handled by some kind of asynchronous message mechanism, which would certainly be happening on a different thread of execution than the channel threads sitting in the queue. * The update of the 'queue' - which is really updating the member's state in the queue, followed by updating various statistics of the queue - happens in 13 when we detect one of three things happening: (1) A blind transfer away from the member (2) An attended transfer away from the member (3) A hangup of the member In all of these cases, these again are handled asynchronously off the message bus. That wouldn't be the case in 11 and earlier - in those versions, we'd be looking directly at either a masquerade occurring or soft hangup flags on the member channel. Either way, it's certainly out of band with the calls to update_status - and it is the same again in 13. I've tried to think of another solution other than what you're proposing. Essentially, we'd ideally like to rely on status to know if the member is on a call or not; however, given the race condition occurring between the changing of the member state (which should tell us that) and the "clean up of the member in the queue" logic that is called via update_queue, I don't think that's quite possible. I don't think we can also easily combine update_queue with update_status. update_status is called whenever a device/extension state changes, and applies in situations other than just termination of a call. update_queue, on the other hand, only happens on call end, and has certain logic that it needs. So: adding something to track the boolean state of whether or not a member is on a call or not is probably the best approach. As a cautionary point, I would be careful to test this logic here: static int is_member_available(struct call_queue *q, struct member *mem) { int available = 0; switch (mem->status) { case AST_DEVICE_INVALID: case AST_DEVICE_UNAVAILABLE: break; case AST_DEVICE_INUSE: case AST_DEVICE_BUSY: case AST_DEVICE_RINGING: case AST_DEVICE_RINGINUSE: case AST_DEVICE_ONHOLD: if (!mem->ringinuse) { break; } /* else fall through */ case AST_DEVICE_NOT_INUSE: case AST_DEVICE_UNKNOWN: if (!mem->paused) { available = 1; } break; } /* Let wrapuptimes override device state availability */ if (mem->lastcall && q->wrapuptime && (time(NULL) - q->wrapuptime < mem->lastcall)) { available = 0; } return available; } As it would be prone to the race condition you're describing. -- Matthew Jordan Digium, Inc. | Director of Technology 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA Check us out at: http://digium.com & http://asterisk.org -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] Transcoding: Codec 2, iLBC 20, SILK, GSM-EFR, AMR(-WB)
negotiation, if appropriate There's some good examples of these tests currently in the Asterisk Test Suite. Most of these tests simply use SIPp to send/receive an offer from Asterisk and receive/send a corresponding answer: * tests/channels/SIP/SDP_offer_answer * tests/channels/SIP/SDP_attribute_passthrough * tests/channels/pjsip/sdp_offer_answer/incoming/nominal/single-media-stream/audio/basic * tests/channels/pjsip/sdp_offer_answer/attribute_passthrough/speex_h263_h264 Clearly, additional tests could be written beyond pass through/negotiation, but it's a good starting point. -- Matthew Jordan Digium, Inc. | Director of Technology 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA Check us out at: http://digium.com & http://asterisk.org -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] Transcoding: Codec 2, iLBC 20, SILK, GSM-EFR, AMR(-WB)
figuration mechanisms for those media formats. I'd have to look more closely to determine if they are still needed. Keep in mind you can have pass through support with the format modules - you don't need necessarily need a format module to pass media from one channel through a bridge to another, the core merely has to know that the format exists. That also explains why the media format attribute modules exist - they provide assistance during negotiation. SILK and CELT have commercial but free modules offered by Digium - although due to time constraints, versions of those modules have not been released for Asterisk 13. > Final Sentence > > Although it would be nice to see at least some of this work in Asterisk, I > am mainly interested in a code-review. Is it possible to submit everything > for code-review even if there is no chance to pass? > Code posted to Gerrit really does need to be licensed back to the project - in fact, that's why we require a CLA to be assigned to log into Gerrit. It makes it a lot simpler for everyone participating in the project to know what rules they are playing by. That being said, everything you've proposed sounds like it would be admissible. Codec modules are the only thing to be careful with, and both codec2 and ilbc are fine. Thanks for the contributions - and please keep them coming! Matt -- Matthew Jordan Digium, Inc. | Director of Technology 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA Check us out at: http://digium.com & http://asterisk.org -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
[asterisk-dev] Bridges, T.38, and other good times
ndard way of informing a channel when it has joined or - more importantly - left a bridge. Direct media has its own mechanism managed by the RTP engine - so it works around this. However, we have a number of scenarios where "things happen" in a bridge that involves state on a channel and - right now - we don't have a unified way of handling it. In addition to T.38, we also have channels being put on hold, DTMF traversing a channel, and more. Often, the channel driver has this state - but instead, we have a lot of 'clean up' logic being added to the bridging core to handle these situations. As I see it, we really only have two options here: (1) Add code to the bridging framework to clean up T.38 on a channel when it leaves. This is kind of annoying, as it will happen on every channel when it leaves, regardless of whether or not the channel even supports T.38. (2) Add a new channel technology callback that a bridge can use to inform a channel driver that it is being ejected from a bridge. This would give us a single place to put cleanup logic that has to happen in a channel driver when it is no longer bridged. I'm not sure those two options will work, exactly, but it's the best options that I can think of after exhausting lots of other code changes in the bridging core. If someone has other suggestions, I'd be more than happy to entertain them. Matt [1] https://jenkins.asterisk.org/ [2] https://jenkins.asterisk.org/jenkins/job/periodic-asterisk-master/75/testReport/junit/%28root%29/AsteriskTestSuite/tests_fax_pjsip_directmedia_reinvite_t38/ [3] https://gerrit.asterisk.org/#/c/1761/ [4] https://jenkins.asterisk.org/jenkins/job/periodic-asterisk-master/80/testReport/junit/%28root%29/AsteriskTestSuite/tests_masquerade/ -- Matthew Jordan Digium, Inc. | Director of Technology 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA Check us out at: http://digium.com & http://asterisk.org -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] SIP channel X Local Channel
On Tue, Dec 1, 2015 at 3:00 PM, Gabriel Ortiz Lour wrote: > > Hi all, > > Having trouble with understanding how chan_sip relates with chan_local. > I know I'm using a very old asterisk version (1.8.19.0) but here is what > I'm trying to do: > > I'm using "use_q850_reason" to transport de HANGUPCAUSE from one * box > to another, as I can see in the 2nd * log: > > ">> Using Reason header for cause code: 50" > > This number (50) came from the HANGUPCAUSE i've set on the 1st * box. > > The thing is that I used the AMI to generate a call using a Local channel, > and I would like to receive that number in the "Reason" field of the > OriginateResponse, so I would know the HANGUPCAUSE of the 1st * box. > > The problem is that the SIP channel in the case is never answered, I'm > fighting with the code on chan_sip function "handle_response" and in the > channel.c "__ast_request_and_dial", but I can't find where the two channels > relate, where to get the "50" that I need...! > > Anyone could help me with some pointers on that? > > You can't reach across channels from one channel driver to another in any kind of safe fashion. That is, code in chan_sip cannot call or set code in chan_local directly. If one channel needs to inform another channel about some piece of information, then it needs to do so using one of the built-in mechanisms that pass information between channels. In your version, you're best off modifying the control frame AST_CONTROL_HANGUP to pass the chan_sip specific Reason code along with it. You'd do something like the following: * Update ast_queue_hangup_with_cause to have a new reason parameter set by chan_sip, and pass not just the hangup cause code but also the reason code along with it. That would make f.data point to a structure containing both cause codes, and have the datalen value be set in the frame to the size of the struct. * Update everyone who handles AST_CONTROL_HANGUP and extracts the cause code out of it to get it from the new structure * Update the origination routines to extract the Reason code out of its handling of AST_CONTROL_HANGUP That's probably your best path, anyway. It's important to note that another way of doing this was implemented in Asterisk 11. There's a separate control frame that handles cause code information that all channel drivers can use to pass that information along to the core, and potentially further if desired. That mechanism has a reasonable amount of work associated with it, so it wouldn't backport well. If, however, Asterisk 11 is an option, you may want to look into that functionality. The control frame that handles cause code propagation (which could reasonably be extended for more information) is AST_CONTROL_PVT_CAUSE_CODE. -- Matthew Jordan Digium, Inc. | Director of Technology 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA Check us out at: http://digium.com & http://asterisk.org -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] Bug marshals back !
On Wed, Nov 18, 2015 at 6:58 AM, Olle E. Johansson wrote: > Yay! > > I notice in a bug report that the response talks about a Bug Marshal. I > am very happy that we have bug marshals back in the process. Is there a > document somewhere outlining the process of becoming one and what they do > nowadays? > > Cheers, > /O > > Hey Olle! I don't think the term bug marshal ever went away. If that was unclear, then I'm sorry about that. As long as I've been around, there's always been special settings set up for JIRA users who are in the "Asterisk Developers" group (such as the ability to see reported security vulnerabilities, etc.). People who generally help solve problems in JIRA are always put in that group. The Asterisk wiki documents what a Bug Marshal does in the Issue Tracker Workflow page: https://wiki.asterisk.org/wiki/display/AST/Issue+Tracker+Workflow Additional guidelines for what constitutes a "good" bug report can be found on the Asterisk Issue Guidelines page (which is linked from the previously mentioned page as well): https://wiki.asterisk.org/wiki/display/AST/Asterisk+Issue+Guidelines Let me know if there's anything you think might be missing on those wiki pages - we're always trying to improve the documentation of the project! Thanks - Matt -- Matthew Jordan Digium, Inc. | Director of Technology 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA Check us out at: http://digium.com & http://asterisk.org -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] Asterisk Docker Containers: Phase 1
> On Mon, Nov 16, 2015 at 4:31 PM, Steve Edwards > wrote: > >> On Mon, Nov 16, 2015 at 4:31 PM, Steve Edwards >>> wrote: >>> > >>> > On Mon, 16 Nov 2015, Leif Madsen wrote: >>> > >>> >> I wrote up a lengthy blog post that likely borders on ranting: >>> >> >>> >> >>> http://blog.leifmadsen.com/blog/2015/11/10/asterisk-docker-container-phase-1/ >>> > >>> > >>> >> Great blog post :-) Would it be appropriate to summarize the current state of things as "we need a spec file for Asterisk"? > > I've only read the first x paragraphs (I'll read more later), and I hope >>> I'm not flying off the handle. >>> > >>> > I used to make source level changes for some of my projects. >>> Fortunately, all the functionality I now need is provided by the RPMs. >>> > >>> > All of my current clients are 'from packages' and I'd hate for the >>> results of the referenced poll to lead to the demise of the packages. >>> >> >> On Mon, 16 Nov 2015, Leif Madsen wrote: >> >> I'm not sure what "demise" you're talking about. >>> >> >> This is why I prefaced my post with 'I hope I'm not flying off the >> handle.' >> >> The potential 'demise' I referred to would be for someone to read your >> post and apply the results from a single poll with a specific demographic >> to the general demographic. >> >> There is also no "poll" going on... >>> >> >> 'Referenced' is past tense -- referring to the poll you referenced. >> >> Nothing that I'm doing will stop people from building packages, so I'm >>> really confused by your statement. >>> >> >> I get that containers do not preclude people from building packages. I >> was not commenting on your work, only on the statement 'no one really uses >> packages.' >> >> Not one thing I am proposing will change your workflow. >>> >> >> I look forward to reading your post in depth when I have the time. >> >> Sorry for the kerfuffle. >> <http://lists.digium.com/mailman/listinfo/asterisk-dev> >> > Just to address Steve's point: Packages aren't going anywhere. I do think we can all agree that the state of Asterisk packaging could use some improvement, but that's a separate discussion. Docker is another way to deploy Asterisk, that may or may not use packages. (And as Chad pointed out, we're using Docker here at Digium for that purpose.) As Leif mentioned in his blog post, there's definitely benefits to using packages with Docker, as it reduces the size of the Docker images. If the goal is to have a universally accepted Docker file for the Asterisk project, then it probably make sense to use packages; that would necessitate either having dependable packages for a variety of distros, or include a .spec file with the project. Leif: Does that sound correct? Matt -- Matthew Jordan Digium, Inc. | Director of Technology 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA Check us out at: http://digium.com & http://asterisk.org -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] Asterisk 1.8 deadlock with Kernel 4.1
On Wed, Nov 18, 2015 at 2:01 PM, Stefan Priebe wrote: > Am 18.11.2015 um 19:46 schrieb Matthew Jordan: > >> >> >> On Wed, Nov 18, 2015 at 12:37 PM, Stefan Priebe > <mailto:s.pri...@profihost.ag>> wrote: >> >> Hello, >> >> since Upgrading our Asterisk System from Kernel 3.18.17 to 4.1.13 it >> deadlocks every few hours (kill -9 is the only thing working). Booting >> with 3.18 again let it run smooth again. >> >> I've now also two gdb backtraces from two crashes: >> http://pastebin.com/raw.php?i=yih5jNt8 >> >> http://pastebin.com/raw.php?i=kGEcvH4T >> >> The kernel guys forwarded me to asterisk to find out where it hangs. >> >> >> Your pastebin links don't appear to be working. >> > > Pastebin is down for raw links. It's up for the normal links. > > http://pastebin.com/yih5jNt8 > and > http://pastebin.com/kGEcvH4T > > >> Please either attach the backtraces, or send them along in the text of >> the e-mail. (Plus, that way we'll have them for posterity.) >> > > Sure here it comes: > Thread 35 (Thread 0x7f295e945700 (LWP 26637)): > #0 pthread_cond_wait@@GLIBC_2.3.2 () at > ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:162 > #1 0x004e51ad in __ast_cond_wait (filename=0x5d3c04 > "taskprocessor.c", lineno=310, > func=0x5d4320 "tps_processing_function", cond_name=0x5d3f71 > "&i->poll_cond", mutex_name=0x5d3f5a "&i->taskprocessor_lock", > cond=0x19e9ad0, t=0x19e9b08) at lock.c:565 > #2 0x00555e9a in tps_processing_function (data=0x19e9ac8) at > taskprocessor.c:310 > #3 0x00569280 in dummy_start (data=0x19eb300) at utils.c:1173 > #4 0x7f295d5dcb50 in start_thread (arg=) at > pthread_create.c:304 > #5 0x7f295de3195d in clone () at > ../sysdeps/unix/sysv/linux/x86_64/clone.S:112 > #6 0x in ?? () > > Thread 34 (Thread 0x7f295e8c9700 (LWP 26638)): > #0 0x7f295de26d13 in *__GI___poll (fds=, > nfds=, timeout=-1) > at ../sysdeps/unix/sysv/linux/poll.c:87 > #1 0x0043e5e4 in listener (unused=0x0) at asterisk.c:1393 > #2 0x00569280 in dummy_start (data=0x19ec150) at utils.c:1173 > #3 0x7f295d5dcb50 in start_thread (arg=) at > pthread_create.c:304 > #4 0x7f295de3195d in clone () at > ../sysdeps/unix/sysv/linux/x86_64/clone.S:112 > #5 0x in ?? () > > Thread 33 (Thread 0x7f295e84d700 (LWP 26639)): > #0 pthread_cond_wait@@GLIBC_2.3.2 () at > ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:162 > #1 0x004e51ad in __ast_cond_wait (filename=0x5bcdf4 "logger.c", > lineno=1072, func=0x5bdc02 "logger_thread", > cond_name=0x5bd8ae "&logcond", mutex_name=0x5bd8a0 "&logmsgs.lock", > cond=0x826b80, t=0x80e550) at lock.c:565 > #2 0x004ea0fa in logger_thread (data=0x0) at logger.c:1072 > #3 0x00569280 in dummy_start (data=0x19ec1c0) at utils.c:1173 > #4 0x7f295d5dcb50 in start_thread (arg=) at > pthread_create.c:304 > #5 0x7f295de3195d in clone () at > ../sysdeps/unix/sysv/linux/x86_64/clone.S:112 > #6 0x in ?? () > > Thread 32 (Thread 0x7f295c08d700 (LWP 26653)): > #0 pthread_cond_wait@@GLIBC_2.3.2 () at > ../nptl/sysdeps/unix/sysv/linux/x86_64/pthread_cond_wait.S:162 > #1 0x004e51ad in __ast_cond_wait (filename=0x5ae3d4 > "devicestate.c", lineno=549, func=0x5aeb10 "do_devstate_changes", > cond_name=0x5ae687 "&change_pending", mutex_name=0x5ae697 > "&state_changes.lock", cond=0x825ea0, t=0x80b4f0) at lock.c:565 > #2 0x004a0764 in do_devstate_changes (data=0x0) at > devicestate.c:549 > #3 0x00569280 in dummy_start (data=0x1ed7b90) at utils.c:1173 > #4 0x7f295d5dcb50 in start_thread (arg=) at > pthread_create.c:304 > #5 0x7f295de3195d in clone () at > ../sysdeps/unix/sysv/linux/x86_64/clone.S:112 > #6 0x in ?? () > > Thread 31 (Thread 0x7f295c011700 (LWP 26654)): > #0 0x7f295de3287d in recvmsg () at > ../sysdeps/unix/syscall-template.S:82 > #1 0x7f295de52fcc in make_request (fd=35, pid=26631, > seen_ipv4=, seen_ipv6=, > in6ai=, in6ailen=) at > ../sysdeps/unix/sysv/linux/check_pf.c:119 > #2 0x7f295de5344a in __check_pf (seen_ipv4=0x7f295c00e85f, > seen_ipv6=0x7f295c00e85e, in6ai=0x7f295c00e840, > in6ailen=0x7f295c00e838) at ../sysdeps/unix/sysv/linux/check_pf.c:271 > #3 0x7f295de10007 in *__GI_getaddrinfo (name=0x7f295c00e8b0 > "10.12.12.55", service=0x7f295
Re: [asterisk-dev] Asterisk 1.8 deadlock with Kernel 4.1
On Wed, Nov 18, 2015 at 12:37 PM, Stefan Priebe wrote: > Hello, > > since Upgrading our Asterisk System from Kernel 3.18.17 to 4.1.13 it > deadlocks every few hours (kill -9 is the only thing working). Booting > with 3.18 again let it run smooth again. > > I've now also two gdb backtraces from two crashes: > http://pastebin.com/raw.php?i=yih5jNt8 > > http://pastebin.com/raw.php?i=kGEcvH4T > > The kernel guys forwarded me to asterisk to find out where it hangs. > > Your pastebin links don't appear to be working. Please either attach the backtraces, or send them along in the text of the e-mail. (Plus, that way we'll have them for posterity.) -- Matthew Jordan Digium, Inc. | Director of Technology 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA Check us out at: http://digium.com & http://asterisk.org -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] Lockups in Asterisk 11
p.c): MUTEX 28923 handle_request_do &netlock 0xb6190440 (1) main/logger.c:1702 ast_bt_get_addresses() (0x813f3a6+19) main/lock.c:258 __ast_pthread_mutex_lock() (0x8138607+85) channels/chan_sip.c:28926 handle_request_do() channels/chan_sip.c:3045 _sip_tcp_helper_thread() channels/chan_sip.c:2572 sip_tcp_worker_fn() main/tcptls.c:694 handle_tcptls_connection() main/utils.c:1223 dummy_start() :0 start_thread() libc.so.6 clone() (0xb76e60d0+5E) === --- ---> Locked Here: chan_sip.c line 28923 (handle_request_do) === --- === === And this shows that the TCP/TLS thread is waiting on a lock held by the monitor thread; most likely, this is the SIP pvt lock currently held by the thread. Things to investigate: (1) Get a gdb backtrace when this occurs, so you can find out exactly what the AstDB synchronization thread is doing that is blocking for a long period of time. (2) Find out *exactly* what is occurring on your system. If the AstDB synchronization thread is taking a noticeable amount of time to do work, you almost certainly have either a problem in your AstDB; have other I/O problems on the system; or have something occurring here that is outside the control of Asterisk. Either way, nothing above makes me think there is a bug in Asterisk. -- Matthew Jordan Digium, Inc. | Director of Technology 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA Check us out at: http://digium.com & http://asterisk.org -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] Asterisk-11 Trying to get Channel Name related to RTP/SIP Private
On Fri, Oct 30, 2015 at 11:46 AM, Mark Murawski wrote: > Howdy All, > > I'm working on trying to output the channel related to an rtp stream. I > found this line in ast_rtp_read()/res_rtp_asterisk.c and this pointed me to > a starting position: > > ast_verb(4, "%p -- Probation passed - setting RTP source address to %s\n", > rtp, ast_sockaddr_stringify(&addr)) > > I figured to tried this: > { > struct ast_channel *chan = ast_rtp_instance_get_chan(instance); > ast_verb(4, "<%s> %p -- Probation passed - setting RTP source address to > %s\n", chan ? ast_channel_name(chan) : "NoChannel", rtp, > ast_sockaddr_stringify(&addr)); > } > > Sometimes this works, and sometimes this doesn't and I'm not sure why. > > If media is setup "slowly", i'll get this: > > [2015-10-30 10:58:04.855] > [C-] 0xb4a94618 -- > Probation passed - setting RTP source address to 192.168.5.125: > > It appears that if the media is setup "fast" I'll get this output: >> [2015-10-30 10:28:54.846]> [C-000a] > 0x89ffda8 -- Probation passed - setting RTP source > address to 192.168.5.123:2224 >> [2015-10-30 10:28:54.846]> [C-000a] > 0x89ec480 -- Probation passed - setting RTP source > address to 192.168.5.129:2250 > > How can I reliably get the channel name here (or pick a better spot to get > the channel name related to rtp ports)? > First, you could just upgrade to 13, which has this feature already. If that's not an option, then you have to do something along the following lines: (1) Inject the channel name into the RTP engine/instance when the RTP instance is first created. It generally isn't safe or reliable to go the other direction. While packet to packet bridging does that, it does so in a very particular way, that I would not recommend doing in Asterisk 11 on every RTCP read (or at other times). (2) Whenever a masquerade occurs, where the SIP pvt gets moved from one channel to another, re-update the RTP instance with the new channel name. Note: this is why you should just move to Asterisk 13, as a masquerade generally does not occur where the new channel owning the SIP pvt is expected to survive for long. (There are exceptions, but FAR fewer than what you'll find in Asterisk 11.) Any other approach is liable to not work. You may want to look at the original patch Jaco Kroon had for this feature on the issue tracker: https://issues.asterisk.org/jira/browse/ASTERISK-20754 If you read the comments however, you'll note again why you should just do this in Asterisk 13+, as you're liable to run into a lot of corner cases where the channel is not around when you think it should be in 11. -- Matthew Jordan Digium, Inc. | Director of Technology 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA Check us out at: http://digium.com & http://asterisk.org -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] PJSIP realtime scalability problem
; > >> > SELECT * FROM pjsip_endpoints_v WHERE id LIKE '%' ORDER BY id > >> > > >> > >> ... which does appear as if that is what we are doing. In pjsip_cli: > >> > >> while ((object = ao2_t_iterator_next(&i, "iterate thru endpoints table"))) >> { > >> const char *id = formatter_entry->get_id(object); > >> if (!strncasecmp(word, id, wordlen) > >> && ++which > state) { > >> result = ast_strdup(id); > >> } > >> ao2_t_ref(object, -1, "toss iterator endpoint ptr before break"); > >> if (result) { > >> break; > >> } > >> } > >> > >> Since the endpoint formatter_entry only has a 'get by id' callback: > >> > >> static void *cli_endpoint_retrieve_by_id(const char *id) > >> { > >> return ast_sorcery_retrieve_by_id(ast_sip_get_sorcery(), "endpoint", id); > >> } > >> > >> That means that for every partial match that you have on an endpoint, > >> we do a separate lookup. > >> > >> Alternatively, we could go pull a partial match in a single query, > >> than iterate over the returned set of matches. Clearly that would be a > >> lot better in this case. > >> > >> > > >> > Why would asterisk need to load the whole list of endpoints more than >> > 300 > >> > times is just completely beyond me. > >> > > >> > >> Hyperbole aside, it's because PJSIP chose a sane, maintainable method > >> to interact with its storage backends and uses a data abstraction > >> layer above its SQL statements - unlike chan_sip, which just embeds > >> the statements willy-nilly in the codebase. The downside of this is > >> that sometimes - in some specific cases - we aren't as efficient as we > >> should be. > >> > >> That's fixable however. Please do file a specific issue for the tab > >> completion case, as that should be improved. > > > > First of all, again, I'd prefer that completion to be performed not against > all the endpoints > > in db, but only those loaded and cached. > > Second, my test environment doesn't have 10K of endpoints, but only > currently 173. > > I imagine that if I did it against all 10K endpoints it would never finish. > > Sure I'll open an issue for that. > Thanks! > >> > > If I boil your issues down, it sounds like the problems are mostly around: (1) CLI commands (or AMI actions, for that matter) that attempt to operate on all endpoints. Generally, options that accessed only the subset of the endpoints that were present in the cache would be desirable. (2) Initial loading of endpoints can take awhile and present a lot of contention on the database. Does that sound right? Matt -- Matthew Jordan Digium, Inc. | Director of Technology 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA Check us out at: http://digium.com & http://asterisk.org -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] PJSIP realtime scalability problem
On Sat, Oct 17, 2015 at 10:03 AM, Michael Ulitskiy wrote: > Matthew, > > > > Thanks for the reply. > > Yes I do have caching enabled. While caching does somewhat help (there are > different problems there) Which problems? > with ongoing load it has nothing to do with initial load that is still done > in the extremely inefficient way > > I described in my original email. I'm not sure why that would be the case. You'll need to be more specific, and provide your sorcery.conf configuration as well as the specific operations/times when there are issues. > Caching also doesn't help at all with CLI commands like "pjsip show > endpoints" in which case asterisk > > reloads the whole list from db instead of showing what it has in-memory. That actually is by design. Say we are caching endpoints. The cache only contains the n most recently requested endpoints, *not* every endpoint that you may have in your system. Hence, if you ask for all endpoints, we have to bypass the cache and get all endpoints in order to accurately fulfill the request. Given that this is a human interaction and not a run-time machine interaction, the fact that you're requesting all endpoints results in going out to the database is not unreasonable. > Also I've noticed another very awkward problem. If I type "pjsip show > endpoint" in the console and then > > press "Tab" then asterisk hangs for over a minute and I register over 300 > queries like this in the db log: So, first, you are asking for name completion against 10k endpoints. Regardless of the number of database queries, that's a large set to complete against. Granted, there's no reason to go get the dataset on every single entry... > > > SELECT * FROM pjsip_endpoints_v WHERE id LIKE '%' ORDER BY id > ... which does appear as if that is what we are doing. In pjsip_cli: while ((object = ao2_t_iterator_next(&i, "iterate thru endpoints table"))) { const char *id = formatter_entry->get_id(object); if (!strncasecmp(word, id, wordlen) && ++which > state) { result = ast_strdup(id); } ao2_t_ref(object, -1, "toss iterator endpoint ptr before break"); if (result) { break; } } Since the endpoint formatter_entry only has a 'get by id' callback: static void *cli_endpoint_retrieve_by_id(const char *id) { return ast_sorcery_retrieve_by_id(ast_sip_get_sorcery(), "endpoint", id); } That means that for every partial match that you have on an endpoint, we do a separate lookup. Alternatively, we could go pull a partial match in a single query, than iterate over the returned set of matches. Clearly that would be a lot better in this case. > > Why would asterisk need to load the whole list of endpoints more than 300 > times is just completely beyond me. > Hyperbole aside, it's because PJSIP chose a sane, maintainable method to interact with its storage backends and uses a data abstraction layer above its SQL statements - unlike chan_sip, which just embeds the statements willy-nilly in the codebase. The downside of this is that sometimes - in some specific cases - we aren't as efficient as we should be. That's fixable however. Please do file a specific issue for the tab completion case, as that should be improved. > > For a long time it was my understanding that "dynamic realtime" means > loading data from db on demand. > > What pjsip does now is not a dynamic realtime. What it does seems like the > mix of both worlds: static realtime in the beginning - > > loading everything from db and dynamic afterwords - issuing queries whenever > it needs endpoint data (caching helps here). > > > > Unless I'm missing something and there's a another/better way to use it, I > think pjsip realtime is not usable now > > at any scale other than very trivial one. > Please leave hyperbole at the door. If you'd like help narrowing down the specific cases that are causing issues, that'd be great. We'd love to help. "I think this sucks" isn't helpful. Right now, you've pointed out one specific case that clearly needs improvement. Please provide specific evidence for each case that you're running into, when caching is enabled, where a run-time operation is substantially less efficient than it should be. And remember: this is an open source project. If you'd like to help fix things, that's always appreciated. Matt -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] PJSIP realtime scalability problem
On Thu, Oct 15, 2015 at 10:58 AM, Michael Ulitskiy wrote: > Hello, > > > > I have a system consisting of OpenSIPS proxy, working as registrar and > outbound proxy for subscribers and multiple > > asterisk systems behind it providing all kind of media services to > subscribers. OpenSIPS proxy dynamically assigns > > which asterisk a particular endpoint should be served at and then forwards > all messages from that endpoint to the > > selected asterisk server. Since this is dynamic process there's no > predefined list of endpoints assigned to each asterisk server. > > Each asterisk server must be prepared to handle requests from any endpoint. > > Currently I'm using chan_sip with dynamic realtime and it works well. > Whenever a request arrives to an asterisk it retrieves that > > endpoint (peer) from db and caches it. chan_sip never attempts to retrieve > the whole list of endpoints. > > > > Now I'm considering migrating to chan_pjsip and immediately I encountered a > problem. Unlike chan_sip, pjsip is retrieving > > the whole list of subscribers multiple times during initial load. Then it > does it again every time you issue "pjsip list/show endpoints/aors" > > CLI commands. Even worse (much worse), after initial load of AORs and > endpoints with the queries that looks like this: > > > > SELECT * FROM pjsip_aors_v WHERE id LIKE '%' ORDER BY id > > SELECT * FROM pjsip_endpoints_v WHERE id LIKE '%' ORDER BY id > > > > it follows on with loading every AOR individually with queries like this: > > > > SELECT * FROM pjsip_aors_v WHERE id = 'ep1' > > SELECT * FROM pjsip_aors_v WHERE id = 'ep2' > > ... > > SELECT * FROM pjsip_aors_v WHERE id = 'epN' > > > > Then it goes on with loading every endpoint individually with queries like > this: > > > > SELECT * FROM pjsip_endpoints_v WHERE id = 'ep1' > > SELECT * FROM pjsip_endpoints_v WHERE id = 'ep2' > > ... > > SELECT * FROM pjsip_endpoints_v WHERE id = 'epN' > > > > I currently have around 10K of endpoints and it's completely unacceptable > even at my scale and I'm sure there are much > > bigger installations out there. > > > > I asked this question on asterisk-users already > (http://lists.digium.com/pipermail/asterisk-users/2015-October/287742.html) > > and was told by Joshua Colp that this is how things stands now and it works > as intended. > > > > So I would like to ask developers if there are any plans to address it and > make it behave more like chan_sip does. If no > > I'd like to know how developers suggest the installations with larger number > of endpoints to handle this. I'm open to any > > suggestions. Right now it looks like show-stopper to me. > Hi Michael: Have you tried sorcery caching yet? https://wiki.asterisk.org/wiki/display/AST/Sorcery+Caching It is new in 13.5.0, and was designed explicitly for this kind of scenario. It probably didn't exist when Josh answered you on the -users list, but I would take a look at putting a cache in sorcery.conf for your PJSIP endpoints. Matt -- Matthew Jordan Digium, Inc. | Director of Technology 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA Check us out at: http://digium.com & http://asterisk.org -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] contrib/realtime sources
On Thu, Oct 15, 2015 at 12:16 PM, James Cloos wrote: >>>>>> "JC" == Joshua Colp writes: > > JC> That's correct, they are produced as part of the release process > JC> itself and not kept under version control. What produces the schemas > JC> is alembic. Alembic can also be used directly against a database. > > Apologies for not completing my thought. > > I meant to add: [Given all of that,] where is the code which uses > alembic to generate the sql files during the release process? > > I don't see any explicit calls when running git grep alembic. And th > wiki page ignores anything other than using alembic to access a db > directly. > > Thanks, > > -JimC > -- Hi James: All of the release scripts are in the repotools repository [1]. The one you're looking for specifically is alembic_creator.py [2], which is invoked by mkrelease.py [3]. Note that the repotools project is also an open source project, so if you see something in there that you'd like to propose for a change, patches are always welcome on Gerrit! Matt [1] http://git.asterisk.org/gitweb/?p=asterisk/repotools.git;a=tree [2] http://git.asterisk.org/gitweb/?p=asterisk/repotools.git;a=blob;f=alembic_creator.py;hb=HEAD [3] http://git.asterisk.org/gitweb/?p=asterisk/repotools.git;a=blob;f=mkrelease.py;hb=HEAD -- Matthew Jordan Digium, Inc. | Director of Technology 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA Check us out at: http://digium.com & http://asterisk.org -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] SIP/SDP: ptime in translation module?
ithin that session. (2) It goes against the contract ast_format tries hard to enforce. You'll either kill performance by requiring a large amount of new ast_format structures when you don't want them, or you'll cause major threading issues. Either channels will be running with a packetization they didn't want, or you may just crash. Or both. If setting it on the ast_frame doesn't work - and that's fair - and packetization is a media session attribute - why not just store it on the ast_translator on the channel? Frankly, it is the closest to something keeping track of the state of the media session that I can think of, and that's really where packetization should probably go. -- Matthew Jordan Digium, Inc. | Director of Technology 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA Check us out at: http://digium.com & http://asterisk.org -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] Asterisk 13.6.0-rc2 Possible CDR Bug
On Wed, Oct 7, 2015 at 2:06 PM, Ross Beer wrote: > Hi, > > I am having an issue setting custom variables in a CDR record for a call > once it has hung up. Setting variables before a dial are inserted into the > CDR correctly. I am using the following hangup_handler as per previous > versions: > > [record-hangupcause] > > exten => s,1,Set(CDR(hangupcause)=${HANGUPCAUSE}) > exten => s,n,Return() > > > Before the dial a hangup handler is registered: > > Set(CHANNEL(hangup_handler_push)=record-hangupcause,s,1) > > > The routine is called and the variables are being set, however not on the > channel's CDR which made the call. > > By changing the cdr option 'endbeforehexten=no' this should keep the CDR > accessible, however all this does is cause another CDR to be created for the > 'h' extension. > > Is there currently a bug with accessing CDR data for a channel that has been > hung-up? It looks to me that the CDR is closed before the hangup_handler is > called. However this shouldn't be the case! > I would be grateful for any feedback you can offer! > > I am happy to open a bug report, but I would prefer to have this > acknowledged before doing so. > Ross > Hey Ross - Sorry I didn't reply sooner. The short answer is that it is working as designed; the long answer is that I think the design is wrong. (As the guy responsible, I feel like I'm only throwing stones at myself.) Keeping a single CDR running after channels have left a bridge was one of those things that was relatively "easy" in 11 and earlier versions, and is a bit more challenging in 13. I think in this case that we probably should revisit the rules around it. I do know this has come up a few times on the mailing lists, but I don't think anyone has made an issue yet. Please do made one, referencing this discussion. Just to summarize what I think should happen: endbeforehexten=no should cause no new CDR to be created in the 'h' extension, and the 'end' time on the CDR should not be set. The CDR should allow manipulation of its properties via the CDR function. Does that sound right? -- Matthew Jordan Digium, Inc. | Director of Technology 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA Check us out at: http://digium.com & http://asterisk.org -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] Discovering Asterisk with consul
On Fri, Oct 9, 2015 at 6:57 AM, Sylvain Boily wrote: > Hello, > > Le 2015-10-04 22:09, Matthew Jordan a écrit : >> >> On Thu, Oct 1, 2015 at 4:11 PM, Sylvain Boily wrote: >>> >>> Hello, >>> >>> I developped a small module to plug asterisk with consul. Also i wrote >>> small >>> documentation, a dockerfile and a docker-compose yaml to play with it >>> easily. >>> >>> code source is here : https://github.com/sboily/asterisk-consul-module >>> >>> My example is only to loadbalance ARI, auto discovery service and >>> autoscaling, but you can imagine what you want. I'm using consul-template >>> to >>> generate the config for haproxy. You can imagine to loadbalance asterisk >>> sip >>> with kamailio automatically if you want. >>> >>> This email is only to sharing my idea with the community ;-) >>> Good and bad feedback is welcome. >>> >> I like the idea for sure, and think it would be a pretty cool >> addition. If you'd like to push the module up for review, I think >> that'd be pretty great - there's a few minor coding guideline [1] >> things you might want to take a look at first, but nothing too major. > > > I did review with my colleague Etienne Lessard, and we follow your > guidelines. I think it's better ;-) > >> >> If you'd like to get it into Asterisk 13 as well as master (which will >> eventually be 14), we can talk about writing automated tests :-) > > > There is automated test now. > Awesome! We should talk about ways to coordinate the automated testing efforts. Probably something to discuss at DevCon, wince we'll all be in a room together next week. -- Matthew Jordan Digium, Inc. | Director of Technology 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA Check us out at: http://digium.com & http://asterisk.org -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] Discovering Asterisk with consul
On Thu, Oct 1, 2015 at 4:11 PM, Sylvain Boily wrote: > Hello, > > I developped a small module to plug asterisk with consul. Also i wrote small > documentation, a dockerfile and a docker-compose yaml to play with it > easily. > > code source is here : https://github.com/sboily/asterisk-consul-module > > My example is only to loadbalance ARI, auto discovery service and > autoscaling, but you can imagine what you want. I'm using consul-template to > generate the config for haproxy. You can imagine to loadbalance asterisk sip > with kamailio automatically if you want. > > This email is only to sharing my idea with the community ;-) > Good and bad feedback is welcome. > I like the idea for sure, and think it would be a pretty cool addition. If you'd like to push the module up for review, I think that'd be pretty great - there's a few minor coding guideline [1] things you might want to take a look at first, but nothing too major. If you'd like to get it into Asterisk 13 as well as master (which will eventually be 14), we can talk about writing automated tests :-) [1] https://wiki.asterisk.org/wiki/display/AST/Coding+Guidelines -- Matthew Jordan Digium, Inc. | Director of Technology 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA Check us out at: http://digium.com & http://asterisk.org -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] SIP/SDP: ptime in translation module?
On Fri, Oct 2, 2015 at 2:13 PM, Alexander Traud wrote: > I am creating a translation module for AMR-WB. In one scenario on the > SIP/SDP layer, a higher ptime was negotiated than the default one. For > example, 60ms were negotiated instead of the AMR default 20ms. Now, Asterisk > should send three frames per RTP packet. I try to play one of the recorded > voices (slin8). Asterisk sends 320 samples to my translation module; the > default for 20ms packetization. My translation module has to wait 960 > samples to create the frames. > > Which structure do I have to query: How do know the ptime, there in such a > transcoding module? This was available in Asterisk 11 via > ast_format->cur_ms. How do I access this information in Asterisk 13|master? > > I am asking asterisk-dev, because all transcoding modules might be affected. > At least with AMR-WB, I have to code/build those frames within the module > because RFC 4867 mandates a special header (section 4.3.5.2 and 4.4.5.1). At > first glance, this could be an architectural issue. Therefore, I am asking > for advice how to approach this: Simply, re-adding "cur_ms" to ast_format? > I don't think we want to add cur_ms back to ast_format, for two reasons. The first is simply that packetization is negotiated at the media level, and applies to all formats negotiated for that media session. Hence why it was removed from the formats themselves - it exists at a "higher" level. Second, formats in 13+ are immutable by convention; this gave Asterisk a big performance improvement as it didn't have to copy the format structs all over the place. Unfortunately, that also means you don't want to change them too often. Generally, once created for a channel, you don't want to put more information in them or otherwise muck with them. Modifying a format during negotiation can be done, but there's a hit you pay for doing it at that point. Currently, packetization is only stored on the RTP instance, as that represents the media session that was negotiated along with all formats in that media session. If you need to get that information into a codec module, there's a few options: 1) Implement an attribute module for the format, such as res_format_amr_wb. You can set arbitrary attributes on any given format, and it will set those attributes in various callbacks into the module. The callbacks are responsible for creating a new cloned format, setting attributes on it in some private data structure, and returning the clone. The format core is smart enough to not impact "normal" formats using this approach. You can look at the existing implementations, such as res_format_attr_opus, to get a hint on how to do that. There are, however, a few issues with this approach: a) By default, the format attribute modules expect to get their attributes out of an 'fmtp' line in an SDP. The ptime attribute won't be passed along with that. That means that you'll have to update parsers of 'ptime' in the various channel drivers to call ast_format_attribute_set with the ptime value, and handle the cloned format appropriately. b) You'll need to pull the format for the RTP instance's codecs out using ast_rtp_codecs_get_payload_format, which may be tricky. Another way of handling this approach would be to implement the call to ast_format_attribute_set in ast_rtp_codecs_set_framing, as it knows how to get at the formats stored in the RTP instance. 2) Another option would be to just store the framing on the frame itself. Frames are not immutable; they are created by the RTP instance (which has the framing for that instance available on it), and could easily be set in ast_rtp_read. Since the framing negotiated is not dependent on the format but on the media session itself, it seems more appropriate to store it on the frames generated by that media session. What's nice about this is that codec modules are fed frames already; that means there's no additional lookups you'll have to do in your codec module. Of the two approaches I like #2 best, but some others may want to chime in on this as well. Matt -- Matthew Jordan Digium, Inc. | Director of Technology 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA Check us out at: http://digium.com & http://asterisk.org -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] Asterisk + WebRTC: No audio on any direction
On Fri, Sep 4, 2015 at 7:51 PM, wrote: > Hello everyone. I'd appreciate a lot your help with this issue. I'm running > a very basic script of JS for subscribing my jsSIP User Agent to my local > Asterisk server and making a voice call. I don't get any warnings or errors > from the Asterisk CLI, but when I make a call to a legacy SIP phone or SIP > trunk well configured, there is no audio on any side although there is > ringing, calls can be answered and they never drop. > > The IP address of the SIP messages is correct both in the header of the > message and in the RTP description, and it succeeds with sending ICE > candidates. My Asterisk 12 was compiled with SRTP and pjproject. I don't get > any error or warning messages on Asterisk, and I suppose that the SIP > messages are ok. > > I read at the Asterisk WebRTC Wiki > (https://wiki.asterisk.org/wiki/display/AST/Asterisk+WebRTC+Support) this: > "Starting with Asterisk 12 you need to have pjproject libraries installed, > otherwise you most likely won't have audio in your WebRTC calls and no > warning whatsoever!" > I properly installed it and selected it for the Asterisk compilation, but I > wonder wether I did it wrong, and how can I check it ... > > These are my files: > > http.conf > [general] > enabled=yes; > bindaddr=0.0.0.0; > bindport=8088; > prefix=asterisk; > tlsenable=yes; > tlsbindaddr=0.0.0.0:8089; > tlscertfile=/etc/asterisk/keys/asterisk.pem; > tlsprivatekey=/etc/asterisk/keys/asterisk.pem; > > rtp.conf > [general] > rtpstart=1; > rtpend=2; > icesupport=true; > stunaddr=stun.l.google.com:19302; > > sip.conf > [general] > context=toSipTrunk > allow=ulaw > allow=alaw > allow=gsm > > [1000] ;legacy softphone (zoiper) > secret=** > type=friend > host=dynamic > dtmfmode=rfc2833 > disallow=all > allow=ulaw > allow=alaw > context=myContext > > [1001] ;jsSIP User Agent > type=friend > username=1001 > host=dynamic > secret=** > encryption=yes > avpf=yes > icesupport=yes > directmedia=no > transport=udp,ws > force_avp=yes > dtlsenable=yes > dtlsverify=no > disallow=all > allow=ilbc > allow=g729 > allow=gsm > allow=g723 > allow=ulaw > dtlscertfile=/etc/asterisk/keys/asterisk.pem > dtlsprivatekey=/etc/asterisk/keys/asterisk.pem > dtlssetup=actpass > context=myContext > > ... Thanks in advance The asterisk-dev mailing list is for discussions regarding the actual source code of Asterisk. Please use the asterisk-users mailing list [1] for deployment, setup, troubleshooting, and other related questions. [1] http://lists.digium.com/mailman/listinfo/asterisk-users -- Matthew Jordan Digium, Inc. | Director of Technology 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA Check us out at: http://digium.com & http://asterisk.org -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
[asterisk-dev] New Features Coming in 13.5.0
e AstDB to a relational database. The next operation inside Asterisk that asks for Alice's endpoint will get the newly pushed information. No reloads necessary! More information on Push Configuration can be found on the wiki: https://wiki.asterisk.org/wiki/display/AST/ARI+Push+Configuration == ARI Module Operations == While Push Configuration is nice, it is only applicable to Sorcery managed configuration. Manipulating modules - load, reload, unload - is a very common operation. Those operations are now supported natively in ARI as well. As an example, to reload chan_sip you would do the following: curl -X PUT -u asterisk:secret https://localhost:8088/ari/asterisk/modules/chan_sip Note that the new module operations were implemented by Benjamin Ford and Scott Emidy, two co-op students here at Digium, as part of their final project as co-op students. They planned the project, wrote the Swagger specification for the new operations, survived withering code reviews, wrote a bevy of tests to cover the new functionality, tweaked the module API in Asterisk, and wrote the ARI commands - and did a great job. == A Few Final New Features == In addition to the previously mentioned features, a few other very nice improvements have been made. These include: * Addition of the 'rtptimeout' option to the PJSIP stack * New AMI events for the PJSIP stack that help to inform of lifecycle changes in Contacts * Support for ';line' functionality for PJSIP outbound registrations A huge thank-you to all the contributors for new features in this release, including George Joseph and Dmitriy Serov. Note that as with all new features in Asterisk, these features have automated tests in the Asterisk Test Suite. However, if something did get missed, please make sure you file an issue and let the developer community know. Thanks! Matt -- Matthew Jordan Digium, Inc. | Director of Technology 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA Check us out at: http://digium.com & http://asterisk.org -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] R: Using the Call Manager events queue to identify incoming calls (from DAHDI)
On Thu, Jul 23, 2015 at 5:19 AM, Domenico DI MIERI wrote: > It could be a solution > > But actually I’ld prefer to understand the sequence of events so that I > can monitor the activities of some users in the office. > > > > Thus I’ld need a more complete comprehnsion of the events that asterisk > generates for different sources and targets: > > > > Channel Created > > Link > > Canellel destroyed > > > > … > > > > Isn’t there something that explains it in details? > > For versions of Asterisk prior to Asterisk 12 - no, there is nothing that explains the full lifetime of a channel in detail. For versions 12 and forward: yes: https://wiki.asterisk.org/wiki/display/AST/AMI+v2+Specification -- Matthew Jordan Digium, Inc. | Director of Technology 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA Check us out at: http://digium.com & http://asterisk.org -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] ARI Snoop
On Sun, Jul 19, 2015 at 4:01 PM, Phil Mickelson wrote: > Thank you for your response. > > Phil Mickelson > > On Sun, Jul 19, 2015 at 4:56 PM, Joshua Colp wrote: > >> Phil Mickelson wrote: >> >>> Hello, >>> >>> I've written a full answering service application with Asterisk at the >>> center. All of my interaction with Asterisk is through ARI. Thank you >>> so much for this feature! Without it I wouldn't have been able to make >>> this work! >>> >>> I've just implemented a new Snoop feature. Without boring you with the >>> details (unless you want them) I am able to Snoop on an operator >>> regardless of whether or not they are on an active call. However, the >>> only way the Whisper option works is if they are on an actual call. The >>> only difference internally is there are two channels connected through a >>> central bridge. Otherwise, the operator's channel is the only one in >>> that bridge. >>> >>> Since I can hear the operator regardless of the current call situation >>> I'm assuming there must be code in the Snoop option to mute the operator >>> if a call is not active? >>> >> >> There is no code to do that. What whispering does require though (for >> both Chanspy and Snoop channels) is a constant media stream out to the >> channel. It's likely that in the specific scenario there is nothing >> generating a stream and thus nothing to whisper into. >> >> There's an open issue[1] to remove this requirement but I know of noone >> currently working on it. >> >> [1] https://issues.asterisk.org/jira/browse/ASTERISK-24397 > > Well nuts. Looks like my theory wasn't right :-) I wonder - as a workaround until that issue is addressed, you *may* be able to force the Whisper by starting Silence on the target channel first: https://wiki.asterisk.org/wiki/display/AST/Asterisk+13+Channels+REST+API#Asterisk13ChannelsRESTAPI-startSilence That *should* start silence frames going to the target of the Snoop channel, at which point, there's at least something flowing through to allow the audiohook to start sending Whispered audio. (If I'm wrong, Josh will tell me why :-) -- Matthew Jordan Digium, Inc. | Director of Technology 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA Check us out at: http://digium.com & http://asterisk.org -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] ARI Snoop
On Fri, Jul 17, 2015 at 10:14 AM, Phil Mickelson wrote: > Hello, > > I've written a full answering service application with Asterisk at the > center. All of my interaction with Asterisk is through ARI. Thank you so > much for this feature! Without it I wouldn't have been able to make this > work! > Thanks! That's really great to hear. A lot of times it's hard to know whether or not a feature is actually making people's lives easier or better - it's always nice to know that it's working well! > > I've just implemented a new Snoop feature. Without boring you with the > details (unless you want them) I am able to Snoop on an operator regardless > of whether or not they are on an active call. However, the only way the > Whisper option works is if they are on an actual call. The only difference > internally is there are two channels connected through a central bridge. > Otherwise, the operator's channel is the only one in that bridge. > I'd definitely be interested in knowing what you've implemented - it's always cool to hear how someone makes use of Asterisk and ARI! I would expect the Whisper option to work regardless of the channel's presence in a bridge. In both cases (snooping/whispering), the Snoop operation works by "hooking" itself onto the target channel using an audiohook. That audiohook feeds audio into/out of the target channel's stream, which means that so long as audio is flowing in the intended direction(s), it should get piped in/out. There could be two things going on here: 1) There's a bug in the Whisper audiohook code or the Snoop code in ARI. That's certainly possible, as it's one of the more complex parts of ARI. 2) The channel isn't answered or - internally - hasn't been told to send a progress (183 w/SDP, etc.) notification. Ideally, we'd handle the latter of those two cases automatically if a Snoop channel is attached to a channel (which means that would be a bug as well) - but I'd be curious to know if the channel is answered or not when you attach the Whispering Snoop channel to it. > Since I can hear the operator regardless of the current call situation I'm > assuming there must be code in the Snoop option to mute the operator if a > call is not active? > > Just to be sure, I setup the entire procedure using Swagger instead of my > program and got the same results. I also used the Delete Mute option to > make sure the operator wasn't muted. > > Once the operator was on a live call I then had to run Snoop again and was > able to Whisper to the operator. I didn't check if I could still Whisper > to the operator after the call ended. I should. > > Am I right about the restriction for Whisper? If not, any suggestions? > And, if I am right, can a new option be added to allow Whisper to work > without an active call? And, if that would be a bounty type change if > someone is interested in making it can you please let me know how much it > would cost? > The wiki page on bug bounties outlines how that process works: https://wiki.asterisk.org/wiki/display/AST/Asterisk+Bug+Bounties I can't really say how much it would cost, as that's something that's negotiated between the person offering the bounty and those who choose to take it. > > Thank you for your time! And, thank you again for ARI!!! > > No problem! Hopefully we can figure out what is going on with your Whisper scenario. If the channel is answered and the Whisper isn't working, please do open up an issue and attach the logs illustrating it so we can't get to the bottom of the problem. Matt -- Matthew Jordan Digium, Inc. | Director of Technology 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA Check us out at: http://digium.com & http://asterisk.org -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] Deadlock in pthread_exit due to lazy binding with libgcc
On Sun, Jul 19, 2015 at 3:28 PM, Sedat Karahancı wrote: Hi everybody > We are looking for freelancers for a Push To Talk Project like Zello and > Voxer. > We still could not decide to choose Asterix or ? And we are looking for > people freelancer or consultant for supporting us on this project ? > Best, > Sedat > > > Hijacking a conversation is not a good way to hire consultants or get help for your project. The asterisk-dev list is for discussion of the Asterisk source code. For commercial related discussions, please use the asterisk-biz list. http://lists.digium.com/mailman/listinfo/asterisk-biz -- Matthew Jordan Digium, Inc. | Director of Technology 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA Check us out at: http://digium.com & http://asterisk.org -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] storing INVITE fmtp and use it to send relay
On Mon, Jun 29, 2015 at 4:36 AM, Kelvin Chua wrote: > Guys, > > just tried asterisk13 and added seanbrights' patch for opus. > > incoming INVITE has fmtp --> > maxplaybackrate=8000;sprop-maxcapturerate=8000 > but INVITE to my registered peer is --> > maxplaybackrate=48000;sprop-maxcapturerate=48000 > > it should not even have to load up the opus patch because it is just a > passthrough > have you changed anything to chan_sip.c to make this work? > Do you have res_format_attr_opus loaded? -- Matthew Jordan Digium, Inc. | Director of Technology 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA Check us out at: http://digium.com & http://asterisk.org -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] To set realm in asterisk
On Fri, Jun 19, 2015 at 1:15 AM, viji iyer wrote: > Hello all, > > I am new to asterisk. And I am trying to change the realm in sip.conf file > to some custom name in the format: > u...@xyz.com > > and domain as xyz.com > > realm = u...@xyz.com > domain = xyz.com > > > But the phones (using x lite phones) doesn't register. > > If we remove the above lines the phones get registered > > I also tried setting > realm=xyz.com > domainasrealm=yes > > Could you please let me know what configuration am I missing. > This question is not appropriate for the asterisk-dev mailing list, which is concerned with discussing the actual implementation of the Asterisk code. Please ask your question on the asterisk-users mailing list. The vast majority of developers exist on both mailing list, and not surprisingly, the asterisk-users mailing list has a large number of talented and industrious users of Asterisk who could also answer your question. -- Matthew Jordan Digium, Inc. | Director of Technology 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA Check us out at: http://digium.com & http://asterisk.org -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] text2wav in ARI
On Wed, Jun 17, 2015 at 4:17 AM, Sumesh M S wrote: > Hi > > I would like to know is there a way to use Festival (text2wav) in ARI with > JavaScript or PHP. Or is there any alternative solution for text to wave > conversion with ARI? > Currently, there isn't a way to do this with ARI. Some discussion about this feature has occurred on the asterisk-app-dev mailing list, as well as at AstriDevCons. It's currently on a list of features that people have expressed an interest in: https://wiki.asterisk.org/wiki/display/AST/ARI+Feature+Wish-list If you'd be interested in writing said feature, folks on the mailing list could certainly help point you in the right direction. Matt -- Matthew Jordan Digium, Inc. | Director of Technology 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA Check us out at: http://digium.com & http://asterisk.org -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] pjsip vs cel
On Wed, Jun 10, 2015 at 11:30 PM, James Cloos wrote: >>>>>> "RM" == Richard Mudgett writes: > > RM> You can specify the dialplan context incoming calls go to when defining > RM> the endpoint. > > Obviously I've done that. The issue is that the CHAN_START cel event > does not reflect the specified context and the INVITE's ruri like > chan_sip's CHAN_START event does, even though the subsequent events do. > > I thought I had explained that clearly; apologies for missing any > ambiguity in my note. It is a bug. When we allocate a channel in chan_pjsip, we are passing empty strings into ast_channel_alloc_with_endpoint for the extension and context parameters. The act of creating the channel in ast_channel_alloc will, when the routine is finished, publish the existence of the channel to the 'world' via Stasis, which will create the CHAN_START event in CEL. We set the context/extension later on in chan_pjsip_new after the channel has been created; it should be trivial to refactor that to pass that information into ast_channel_alloc_with_endpoint. -- Matthew Jordan Digium, Inc. | Director of Technology 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA Check us out at: http://digium.com & http://asterisk.org -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] Asterisk Beacon Module Proposal
e quite long. Each Asterisk with a Server ID gets a unique temporary token, and if an Asterisk with the same Server ID asks for a token but does not present the current token when it does so, it will be rejected. The module should then request a new Server ID. At any point in time, there is only one token associated with one Server ID, not multiples. Really, if this needs substantially more explanation on the wiki page, that's fine, but this is really a mechanism to try and reasonably prevent collisions. It is not meant to be a security mechanism (other than it may frustrate someone who really is bored and tries to spoof random UUIDs). The usage of reporting server assigned UUIDs is probably going to account for 99% of our cases. Hopefully this answers some of the concerns and suggestions. Thanks! Matt -- Matthew Jordan Digium, Inc. | Director of Technology 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA Check us out at: http://digium.com & http://asterisk.org -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] (unreported) uninitialized: struct ast_sockaddr
On Mon, May 11, 2015 at 9:16 AM, Alexander Traud wrote: >>> B) Change my patch not to use a char* but char[128]. >> Your easiest option with less chance of regression elsewhere would be this. > > Yes. Anyway: Is the Asterisk team interested in a patch at least for the 5 > affected files? These are 54 changes. I am not sure if the path via an issue > (Jira) and a commit (Gerrit) is welcome for something like this. > > Furthermore, again there are several options: > I) in those 5 files, report only those 54 changes which I need; or > II) in those 5 files, correct *all* struct inits > The latter is interesting, because there are memsets(.) which get > unnecessary then. This created an additional option/question: > III) shall I remove all - then duplicate - struct inits as well? > > Or shall I stop wasting anyone's time and go for option B, a char[128]? I wouldn't say you're wasting anyone's time. It's a good question. What you're proposing is a change to the semantics of ast_sockaddr in order to accommodate a change in a patch you're making. A few things to keep in mind: 1) Your module/patch, as well as the rest of the Asterisk modules, may not be the only consumers of ast_sockaddr. It is a fundamental data structure in Asterisk; other third party modules may use it. Since your change modifies the semantics of the struct, you will also break them. 2) If the rest of your patch is never pushed back up to the main project, then the change you've made has little positive affect, while breaking most other external modules that use it. That's not good for the project. On the other hand, if you propose your feature for inclusion as well, there's more of a benefit to the change. That aside, if you can make a change with a little bit more work that maintains the existing usage semantics, you get the best of both worlds: your new feature gets what it needs, and the mainline Asterisk project - as well as other third party modules - aren't broken. So yes, I'd just use a char array with a fixed length. -- Matthew Jordan Digium, Inc. | Director of Technology 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA Check us out at: http://digium.com & http://asterisk.org -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] systemd sd_notify() [was: Re: Journald support for Asterisk]
On Sun, May 10, 2015 at 3:03 AM, Tzafrir Cohen wrote: > On Sat, May 09, 2015 at 10:17:24AM +0200, Ludovic Gasc wrote: >> Hi, >> >> Systemd and Journald is now by default on Debian Jessie and Ubuntu 15.04, >> as on RHEL/CentOS. >> Journald supports syslog format, nevertheless, at least for us, the >> structured log system provided with journald helps us to debug the >> production. > > Slightly off-topic: if anybody wants to implement support for > sd_notify(3)[1] in Asterisk, it would be nice. > > Suppose there would be a function called ast_daemon_changed_state()[2] to > notify journald on end of start, start/end of reload and start of end. > Is this information useful to anything else besides notifying systemd > via sd_notify()? > > [1] http://www.freedesktop.org/software/systemd/man/sd_notify.html > > [2] Bad name, I know. I'm not sure I'd create a new C API for this. Asterisk already uses Stasis to convey a lot of this information, although today, it is only consumed by AMI. The right way to do this would be to pull the messages out of the manager topic and make them a bit more publicly consumable. If that is done, you could then have a completely independent external module that interfaces with systemd. Since there isn't a reload start/stop, there'd have to be at least one new message added as well. The messages to look at are: The publishing of Reload in loader.c::publish_reload_message The publishing of FullyBooted in asterisk.c::publish_fully_booted The publishing of Shutdown in asterisk.c::really_quit -- Matthew Jordan Digium, Inc. | Director of Technology 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA Check us out at: http://digium.com & http://asterisk.org -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] Journald support for Asterisk
On Sat, May 9, 2015 at 9:15 AM, Bruce Ferrell wrote: > On 05/09/2015 01:17 AM, Ludovic Gasc wrote: >> Hi, >> >> Systemd and Journald is now by default on Debian Jessie and Ubuntu 15.04, as >> on RHEL/CentOS. >> Journald supports syslog format, nevertheless, at least for us, the >> structured log system provided with journald helps us to debug the >> production. >> >> The idea behind that is to attach metadata with a log line to facilitate the >> search with journalctl, you can write queries to find the errors. >> >> For example, with Apache: >> http://httpd.apache.org/docs/trunk/mod/mod_journald.html >> >> For our Python daemons, for each log line, we store account_id, request_id, >> endpoint and method used to be easy to retrieve quickly interesting logs. >> >> Moreover, not yet used for us, but you can generate statistics about your >> source code real usage based >> on: >> http://www.freedesktop.org/software/systemd/man/systemd.journal-fields.html#CODE_FILE= >> >> For Asterisk, for example with dialplan logging, you should attach the >> context, the extension and the channel. >> >> You can simulate this journald feature with a specific format message for >> your logs, nevertheless, journalctl is more user-friendly to retrieve >> pertinent logs compare to the >> classical grep usage. >> ave no idea if i >> I'm permitted to raise the question about an eventual journald support in >> Asterisk because I don't find anything about that in issues tracker nor >> mailing list. >> >> Moreover, I understand that even if you add the journald support, it's >> certainly necessary to change logging everywhere in Asterisk, however, I >> should help to do that. >> >> Regards >> -- >> Ludovic Gasc (GMLudo) >> http://www.gmludo.eu/ >> >> > systemd and journald SUCK to high heaven. I have no idea if the issues I've > had with them (OpenSUSE) are distro related or inherent. > > I have seen that the implementation of apache with a static systemd/journald > module will no longer correctly serve content. > > Please do NOT do this. It also breaks fail2ban site security. Asterisk > works well now. It integrates easily. Being very honest, my knowledge of systemd and journald is not extensive. I have no real position on systemd/journald one way or the other. I will say that I do not view it as an inevitable conclusion, nor a necessary requirement for Asterisk. As such, I'm viewing this only as a proposal for "we'd like to change the vast majority of log statements in Asterisk." First, as Bruno pointed out, a lot of external systems rely on parsing log messages. Asterisk does not exist in a vacuum, and is often a component in a much larger system. As such, any modification to Asterisk's logging would have to be configurable. Second, the logging system in Asterisk has a measurable impact on performance. Unfortunately, adding a configuration option that is evaluated on every log statement will further degrade performance when logging verbosity is increased. A compile time option is not a pleasant alternative either. Note that we experienced a similar situation in Asterisk 11 with the remote console independent verbosity setting, and spent a lot of time over many point releases getting the performance back in line. It is also telling that Apache's mod_journald states: {quote} Performance warning Currently, systemd-journald is not designed for high-throughput logging and logging access_log to systemd-journald could decrease the performance a lot. {quote} Third, journald seems to be providing structured log data. While some logging statements in Asterisk may benefit from such a system, many may not. Asterisk can be *extremely* chatty. I'm not sure that every log statement in Asterisk should be converted or support such a system. A more concrete proposal over what messages are appropriate for journald would be nice. I'd be curious if another option would be to treat journald as we currently treat syslog - not as a formatting option, but as a destination. If that were possible, support could be added for it without necessarily impacting the existing log statements. Asterisk supports the concept of having dynamic log channels, and support for journald could then also be added as an external module without impacting the core - or impacting users who don't care for it. -- Matthew Jordan Digium, Inc. | Director of Technology 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA Check us out at: http://digium.com & http://asterisk.org -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] Asterisk Beacon Module Proposal
On Thu, May 7, 2015 at 11:40 PM, George Joseph wrote: > On Thu, May 7, 2015 at 8:35 PM, Matthew Jordan wrote: >> >> Hey everyone - >> >> At the past several AstriDevCon events, we've had an open discussion >> about adding a module to Asterisk that would gather anonymous usage >> statistics. Said module would be used to help the Asterisk Developer >> community better support the users of Asterisk, as we would have some >> indication of the modules being used by the reporting segment of the >> Asterisk community. There are, of course, a couple of agreed upon >> stipulations for such a module: >> >> * As noted, all information gathering must be anonymous. No >> information about the sending system should allow for someone viewing >> the data to be able to identify the system in quesiton. >> >> * The module must send all of its data encrypted. >> >> * Users must be notified as the last message on startup that anonymous >> usage statistics are being gathered. >> >> * The module must provide the ability for users to opt out of >> gathering statistics. >> >> * Users must be able to go to asterisk.org and view the statistics >> gathered for their server. The module must provide a unique, >> non-identifying token that users can use to view the gathered >> statistics for their servers. >> >> After some careful thought, we've put together a proposal for such a >> module – called “Beacon” - on the Asterisk wiki [1]. In addition to >> meeting the requirements discussed at previous AstriDevCons, the >> proposal on the wiki outlines a Swagger schema for a REST API that the >> module will talk to. The module configuration will support sending the >> usage statistics to more than just the server at asterisk.org, >> effectively allowing anyone to send statistics from their servers to >> other implementations of the REST API. This can be beneficial for >> people deploying large numbers of Asterisk servers. >> >> As mentioned, the asterisk.org site will be updated to allow for users >> to view the collected statistics. A sample screenshot is attached to >> this e-mail. Note that this is merely a mock up given some fake data, >> but it should hopefully illustrate what this may look like for >> Asterisk users. > > > How about a summary dashboard anyone can view? Sure! I'm not sure I can get the webby folks to create a wireframe for that quickly, but I think it's something we should have. I always liked the Linux Mint community page: http://community.linuxmint.com/ Something similar to that for Asterisk would be pretty cool. > Total number of pbxes by version, global count of modules used, OSes used, > etc. > > Another thing that might be useful is a histogram of peer/endpoint count per > pbx. How many pbxes with 1-50, 51-250, 251-1000, etc. Maybe by technology, > IAX2, SIP, PJSIP, etc. I'd love that information, as it would really help get a feel for how Asterisk is being used. The only issue I have with gathering that data is that channel drivers don't provide an easy API to get at that information (with the exception, of course, of PJSIP. Go sorcery go!) The only option I can think of is to use a config hook, i.e., a config_hook_cb, and process the bare minimum of a config file for the channel drivers when they are loaded/reloaded. That would require a bit more processing when said config files are loaded/reloaded. I don't think we'd want to report much more than counts of peers/friends/users/endpoints. If others are okay with the small overhead of processing config files, I can add it to the spec. -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] Asterisk Beacon Module Proposal
On Fri, May 8, 2015 at 4:54 PM, Rodrigo Ramírez Norambuena wrote: > On Fri, May 08, 2015 at 11:49:39AM -0400, Moises Silva wrote: >> On Thu, May 7, 2015 at 10:35 PM, Matthew Jordan wrote: >> >> > Hey everyone - >> > >> > At the past several AstriDevCon events, we've had an open discussion >> > about adding a module to Asterisk that would gather anonymous usage >> > statistics. Said module would be used to help the Asterisk Developer >> > community better support the users of Asterisk, as we would have some >> > indication of the modules being used by the reporting segment of the >> > Asterisk community. >> >> >> Is there a need for this to be an Asterisk module itself and not an >> external monitoring service/agent collecting (e.g via AMI) and pushing the >> stats? I'm just thinking this is not the kind of thing that *needs* to be >> in a C module. It'd be sad to have your Asterisk system crashing or >> misbehaving because of a bug in the beacon module. There's a few issues with doing it outside of Asterisk: 1) Not all of the data you may want to retrieve may be readily available. Granted, right now, I don't think that's the case, but there's certainly more flexibility if you have access to Asterisk's C APIs. 2) There's no real way to guarantee that someone will run a daemon next to Asterisk, or that said daemon won't have some other interaction that we won't expect. The only way I can think of to reasonably introduce such a daemon is to make it part of the Asterisk 'install' target, and/or add it to packages. I'm not sure if having a separate daemon spin up suddenly on someone's system, with no warnings, would be much better. That being said, I do think there's a few small benefits to making this part of Asterisk: 1) We can give a visual warning that it is enabled. That's not as easy to do via an external process. 2) Disabling it is done in a manner that is similar to other Asterisk modules - don't build it in menuselect, or disable it in a .conf file. 3) Less important, it would have access to the C APIs in Asterisk. With the advent of the Stasis message bus, we have mechanisms that can prevent said module from impacting the critical run-time parts of Asterisk. That gives us a lot of the power/flexibility of the Asterisk APIs, while minimizing risk. Your point is a good one though. No one wants the statistics module to have a negative impact on their system. To that affect, there's a few ways the proposal on the wiki minimizes risk: 1) It's relatively simple, and doesn't try to get a bunch of information out of a lot of modules that may or may not be there. To whit, all of the APIs needed for the information are in the core, and have a reasonably minimal impact on the run-time aspects of Asterisk: - ast_get_version/ast_get_version_num: version.h - ast_active_calls/ast_processed_calls: pbx.h - ast_startuptime/ast_lastreloadtime: global constants in options.h - ast_update_module_list: module.h 2) The project plans outlines tests that should be created for the module. That includes standing up a version of the REST API in the testsuite, and providing both nominial and off-nominal tests. > > Other idea is a create a service/agent using ARI, is really needed add this > module on 11 version?. There are more Asterisk 11 systems out there than Asterisk 13 systems (which is not surprising in the least). If the goal is to get a good picture of what Asterisk systems are out there, having a module that applies to all of the currently supported Asterisk versions makes sense. ARI has no relationship to the server, either one stood up by someone running Asterisk or the proposed community service. For the Asterisk 13+ variant of the module, an ARI resource is proposed for a local Asterisk instance as a way to see what data was last transmitted. > A point i dont saw in the doc is what happens when dont have internet for > notified the stats or have a problem for send the request. There should be a > queue of stats to notify but this could has a conflict with rate limit inbound > request of api server. I disagree. I don't think queueing statistics is a good idea. A lot of things can go wrong; e.g., what happens if the Asterisk server is behind a firewall that blocks HTTPS? We'd never send the data; the data would pile up; Asterisk would consume all of the systems memory, etc. The proposal on the wiki aims for some element of simplicity. Simplicity minimizes errors and risk. To Moises's point, no one wants the anonymous statistics module to impact their service. -- Matthew Jordan Digium, Inc. | Director of Technology 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA Check us out at: http://digium.com & http://asterisk.org -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
[asterisk-dev] Asterisk Beacon Module Proposal
Hey everyone - At the past several AstriDevCon events, we've had an open discussion about adding a module to Asterisk that would gather anonymous usage statistics. Said module would be used to help the Asterisk Developer community better support the users of Asterisk, as we would have some indication of the modules being used by the reporting segment of the Asterisk community. There are, of course, a couple of agreed upon stipulations for such a module: * As noted, all information gathering must be anonymous. No information about the sending system should allow for someone viewing the data to be able to identify the system in quesiton. * The module must send all of its data encrypted. * Users must be notified as the last message on startup that anonymous usage statistics are being gathered. * The module must provide the ability for users to opt out of gathering statistics. * Users must be able to go to asterisk.org and view the statistics gathered for their server. The module must provide a unique, non-identifying token that users can use to view the gathered statistics for their servers. After some careful thought, we've put together a proposal for such a module – called “Beacon” - on the Asterisk wiki [1]. In addition to meeting the requirements discussed at previous AstriDevCons, the proposal on the wiki outlines a Swagger schema for a REST API that the module will talk to. The module configuration will support sending the usage statistics to more than just the server at asterisk.org, effectively allowing anyone to send statistics from their servers to other implementations of the REST API. This can be beneficial for people deploying large numbers of Asterisk servers. As mentioned, the asterisk.org site will be updated to allow for users to view the collected statistics. A sample screenshot is attached to this e-mail. Note that this is merely a mock up given some fake data, but it should hopefully illustrate what this may look like for Asterisk users. Please take a look at the spec on the wiki and the proposed project, and comment here with any suggestions for improvements. Thanks! Matt [1] https://wiki.asterisk.org/wiki/display/AST/Asterisk+Beacon+Module -- Matthew Jordan Digium, Inc. | Director of Technology 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA Check us out at: http://digium.com & http://asterisk.org -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
[asterisk-dev] Asterisk 14 Status and Project Timeline
Scalability = While focusing on scalability was not as high on the list as the aforementioned issues, it has been a topic of conversation on the mailing list a few times [19] [20]. Much of this has centered around better integration between Asterisk and Kamailio. However, with the exception of Daniel's proposal for a new authentication scheme, I think we're still a little muddy on where the real problem areas with scaling Asterisk horizontally lie. In many conversations – both on the asterisk-dev list and in person with various people in the community – I continually get the impression that while there are many areas for improvement, no one is really quite sure what the real, intransigent issues are, much less how to resolve them. To that extent, I'd like to resurrect some of the threads that were going on a few months ago, and try to reach some conclusion about what areas in Asterisk are best to focus on to solve some of the scalability issues people have alluded to over the years. Time is always a limited commodity – and having people in the community thinking about the most important problems will give Asterisk the biggest payoff when features targeting scalability issues are implemented. = Conclusions = So where does this leave us? While we've made a lot of great progress on a number of the items from AstriDevCon, it feels like we're still quite a ways out from the goals outlined in that meeting. We still have a lot of infrastructure improvements to make, we have a lot of features to document and existing documentation to improve on, we have a plethora of ARI features that people would love to have, and we're still not quite sure where we should improve Asterisk to make it scale better. All of that is a lot to cram in the next few months, and cramming things is rarely a good idea. To that extent, I'm proposing that we hold off on the Asterisk 14 deadlines for now. Having a stable release schedule is great for the project and for users, but not at the expense of having a release that doesn't meet its goals. While I don't want to hold users hostage to an unimplemented feature list, I also want to make sure that we take advantage of the Standard release, and that whatever we release moves the Asterisk project substantially forward. If you have any thoughts or comments on the above, I'd love to hear them. And, as always, thanks for supporting the Asterisk project! Matt [1] https://wiki.asterisk.org/wiki/display/AST/Asterisk+Versions [2] https://wiki.asterisk.org/wiki/display/AST/AstriDevCon+2014 [3] http://lists.digium.com/pipermail/asterisk-dev/2014-September/070303.html [4] http://lists.digium.com/pipermail/asterisk-dev/2014-December/072024.html [5] https://gerrit.asterisk.org [6] http://lists.digium.com/pipermail/asterisk-dev/2015-March/073461.html [7] http://lists.digium.com/pipermail/asterisk-dev/2015-April/074129.html [8] http://lists.digium.com/pipermail/asterisk-dev/2015-April/074589.html [9] https://wiki.asterisk.org/wiki/display/AST/Gerrit+Usage [10] https://wiki.asterisk.org/wiki/pages/viewpage.action?pageId=29395573 [11] https://github.com/asterisk/ari-examples [12] https://github.com/asterisk/voicemail-docs [13] https://github.com/asterisk/node-confbridge [14] https://wiki.asterisk.org/wiki/display/AST/res_pjsip+Remote+Attended+Transfers [15] https://wiki.asterisk.org/wiki/display/AST/PJSIP+Transport+Selection [16] https://wiki.asterisk.org/wiki/display/AST/PJSIP+Configuration+Wizard [17] https://wiki.asterisk.org/wiki/display/AST/ARI+Feature+Wish-list [18] https://wiki.asterisk.org/wiki/display/AST/Asterisk+14+Projects [19] http://lists.digium.com/pipermail/asterisk-dev/2015-February/072748.html [20] http://lists.digium.com/pipermail/asterisk-dev/2015-March/073217.html -- Matthew Jordan Digium, Inc. | Director of Technology 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA Check us out at: http://digium.com & http://asterisk.org -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] Git/Gerrit dumb questions
On Mon, Apr 27, 2015 at 12:24 PM, George Joseph wrote: > > > On Mon, Apr 27, 2015 at 12:34 PM, Steve Davies wrote: >> >> I finally found the wiki.asterisk.org pages that I needed to read to get >> started with git and gerrit as configured in these parts. For reference to >> help anyone else trying to migrate from the SVN/reviewboard system: >> >> https://wiki.asterisk.org/wiki/display/AST/Git+Usage >> https://wiki.asterisk.org/wiki/display/AST/Gerrit+Usage >> >> So the question is, I have a couple of SRTP/DTLS related memory leak fixes >> for the v.11 branch - Do I still need to raise a JIRA ticket, then submit >> the patch to both JIRA and to Gerrit, or can I now just submit this change >> to Gerrit and skip the bug report? > > > > I'd create the Jira ticket, create the review making sure to reference the > ticket, then update the ticket with the review URL in the Reviewboard link > field. > > You don't need to attach the patch to the ticket. > > >> >> >> Is there a wiki page describing this process (I failed to find it). >> This page may help as well: https://wiki.asterisk.org/wiki/display/AST/Patch+Contribution+Process -- Matthew Jordan Digium, Inc. | Director of Technology 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA Check us out at: http://digium.com & http://asterisk.org -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] Team branches and gerrit
On Fri, Apr 24, 2015 at 8:42 AM, Russell Bryant wrote: > On Fri, Apr 24, 2015 at 8:31 AM, Joshua Colp wrote: >> >> Olle E. Johansson wrote: >>> >>> Playing around following Matt's wiki page on gerrit usage, I created >>> a team branch and did two commits. When pushing it with "git review >>> {branch}" only the last commit shows up. >>> >>> Is that the way it's supposed to be? I thought the whole branch was >>> the review subject, not just a single commit. >> >> >> Gerrit works on a single commit (what it refers to as a patch set) that >> you want included into a specific branch. As a result you need to squash all >> commits into a single one, and if review feedback warrants further changes >> they also need to be squashed back into a single commit with the original >> changes. The single commit you post for review is what is reviewed and >> merged into the branch. > > > Gerrit can also work on a patch series, and tracks dependencies between > those patches. > I could be mistaken, but in the case where you have a series of patches, each patch is put up for review separately with its own Change-Id, correct? -- Matthew Jordan Digium, Inc. | Director of Technology 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA Check us out at: http://digium.com & http://asterisk.org -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] send DTMF not Detected on SIP/XXXX using AMI +AGI+EXEC+SendDTMF
On Wed, Apr 22, 2015 at 6:56 AM, HKC323 wrote: > This following setting has been configured. > dtmfmode=rfc2833 has been set . > set (Agi:async) > sip client : jisti sip soft phone > == > issue : > When Agent A1 and Agent A2 are on call > DTMF must be Passed and Feature must be exeute . > here DTMF detect but feaure not extecuted . > in case of local channnel DTMF and Feayure Both Worked. > > BUT in SIP/xxx-XXXxxx not worked ?? > == > AMI +playDTMF tried but did not work . > == > > so tied with AGI+AMI+EXEX+SendDTMF but still not working > == > Action: AGI > Channel: SIP/1120-0006 > Command: EXEC senddtmf *1 > CommandID: 0MyCommandSIP/1120-0006 > > -- Unregistered SIP '1121' > [Apr 22 03:55:10] -- Registered SIP '1121' at 192.168.0.106:5060 > [Apr 22 03:55:10] -- Added extension '1121' priority 1 to dundiextens > [Apr 22 03:55:10] > Saved useragent "Jitsi2.4.4997Windows 7" for peer > 1121 > [Apr 22 03:55:10] NOTICE[3388]: chan_sip.c:27924 > handle_request_subscribe: Received SIP subscribe for peer without > mailbox: 1121 > [Apr 22 03:55:14] -- Unregistered SIP '1121' > [Apr 22 03:55:14] -- Unregistered SIP '1120' > [Apr 22 03:55:16] -- Registered SIP '1120' at 192.168.0.106:5060 > [Apr 22 03:55:16] -- Added extension '1120' priority 1 to dundiextens > [Apr 22 03:55:16] -- Registered SIP '1121' at 192.168.0.106:5060 > [Apr 22 03:55:16] -- Added extension '1121' priority 1 to dundiextens > [Apr 22 03:55:16] NOTICE[3388]: chan_sip.c:27924 > handle_request_subscribe: Received SIP subscribe for peer without > mailbox: 1121 > [Apr 22 03:55:16] NOTICE[3388]: chan_sip.c:27924 > handle_request_subscribe: Received SIP subscribe for peer without > mailbox: 1120 > [Apr 22 03:55:21] == Using SIP RTP CoS mark 5 > [Apr 22 03:55:21] -- Executing [1121@agent:1] NoOp("SIP/1120-0006", > "EXTEN:1121") in new stack > [Apr 22 03:55:21] -- Executing [1121@agent:2] AGI("SIP/1120-0006", > "agi:async") in new stack > [Apr 22 03:56:08] -- AGI Script Executing Application: (senddtmf) > Options: (4) > [Apr 22 03:56:55] -- AGI Script Executing Application: (senddtmf) > Options: (*8) > localhost*CLI> > > > > r 22 04:14:26] -- AGI Script Executing Application: (senddtmf) Options: > (*1) > [Apr 22 04:14:26] DEBUG[3401]: manager.c:4831 match_filter: Examining > event: > Event: AGIExec > > > == > > > Any Help > This question is not appropriate for the asterisk-dev list. The asterisk-dev list for discussing the actual source code of Asterisk; this appears to be a configuration issue. Please ask this question on the asterisk-users mailing list. -- Matthew Jordan Digium, Inc. | Director of Technology 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA Check us out at: http://digium.com & http://asterisk.org -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] s?rtp via SIP/TLS/TCP
On Mon, Apr 20, 2015 at 10:41 AM, James Cloos wrote: > I'm not sure whether this is a bug, so I'm starting here. > > My remote asterisk (debian's compile of 13, currently 13.1.0) and my > snom had been unable to rtp for some time. I still use chan_sip. > > It took a few hours of testing, but I determined that when the phone > registers and/or invites over tls, asterisk refuses to do either un- > encrypted rtp or srtp unless force_avp=yes. > > The symptom was a hangup w/ unknown cause as soon as it was time to > start rtp. Ie, right after the OK. Even with verbose and debug set > to 9 no explanation was logged. When I tried adding force_avp=yes > everything started working again. > > I don't know when it stopped working (I don't get enough calls and > send outgoing via a different asterisk); I presume that it stopped > working when force_avp was added, but cannot confirm that. > > Is force_avp supposed to be required for non-dtls rtp when sip is > secure? Without a trace showing the SIP message traffic, any answer is going to be a guess. Guessing at what is occurring here: your phone is probably offering optional/optimistic encryption. While optimistic encryption is supported by chan_pjsip, currently, an offer with RTP/AVPF with crypto attributes is currently rejected by chan_sip. See https://issues.asterisk.org/jira/browse/ASTERISK-23989. -- Matthew Jordan Digium, Inc. | Director of Technology 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA Check us out at: http://digium.com & http://asterisk.org -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] A Week with GIT/Gerrit
On Fri, Apr 17, 2015 at 3:42 PM, Corey Farrell wrote: > My additions to the list: > 1) Procedure for 'git review' of security related patches. I think this > could be done with an "asterisk-security" mirror repository setup in gerrit > with restricted access. I know this is already being thought about, just > wanted to make sure it on the list. I think there's a lot of things to think through with this, since Gerrit - being a Git repo - tends to expose all patches in some form or fashion. We could set up a completely separate server with extremely limited access, but then we would need a separate review server as well. In the meantime, we might be able to use review board for this, although it will mean porting it over to look at the Git repos. It's certainly on the list to think through more. > 2) Is there a command similar to 'git show-branch 13 master' that will > operate on Change-Id's? Something to show me the first line of all commits > with change-id's that hit one branch but not the other. > 3) It would be great if gerrit had the ability to detect the string > "ASTERISK-#" in commit messages and review comments, convert it to a > JIRA link. Apparently this is possible and is actually just a configuration issue: http://gerrit.googlecode.com/svn/documentation/2.2.1/config-gerrit.html#_a_id_commentlink_a_section_commentlink I'll try to get that set up this week. > 4) 'git review -D' should not generate emails or allow the review to be seen > on the web UI by anyone except the submitter. I know this is probably a bug > in gerrit, but still worth having on the list. I will say that the last time there was a draft, it did show on the UI as a Draft. I upgraded to 2.10.3.1 this weekend - maybe we'll get lucky and it got fixed? :-) > 5) We should add instructions for squashing commits before review somewhere > on the Git or Gerrit usage page. > Ack. I'll try to get to that today. Maybe on the Git usage or Commit message page, since it isn't explicitly tied to using Gerrit? -- Matthew Jordan Digium, Inc. | Director of Technology 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA Check us out at: http://digium.com & http://asterisk.org -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] A Week with GIT/Gerrit
On Sat, Apr 18, 2015 at 8:26 PM, Matthew Jordan wrote: > On Thu, Apr 16, 2015 at 5:00 PM, George Joseph > wrote: >> >> The Emails: >> >> Overall I think they're too verbose. >> "Change in asterisk[master]: bridge.c: NULL app causes crash during attended >> transfer" >> might be better as >> "bridge.c: NULL app causes crash during attended transfer >> (asterisk[master])" >> It's not a lot shorter but it has the most valuable info at the front. > > That's pretty easy. This should now be fixed. >> Also, the mail generated by "ReplacePatchSet" which gets sent on a rebase, >> doesn't tell you why you're getting the message but it does have the entire >> original commit message which doesn't really help. I'd remove the commit >> message and add the text of the last change. I.E. "Foo Bar: Patch Set 8: >> Patch Set 7 was rebased". That'll at least tell reviewers not to worry >> about it. > > I think that makes some assumptions about why a patch set was > replaced. It doesn't just occur during a rebase - it could just as > easily occur due to a decrease/increase in the patch scope from > comments on the previous patch set, in which case reading the text of > the new commit message may be useful. > > Reading through your suggestion, I'm not sure what in the e-mail > templates would give what you're looking for. The ReplacePatchSet does > include the number of the new patch set, as well as the change subject > - but inferring why a patch set was updated doesn't feel possible. > >> Removing "(Code Review)" from the sender would be good as well. > > I can do that. This should now be fixed as well. >> Cherry-picking: >> >> I think there are some issues we still need to figure out about the process >> and the system. Process first... >> >> While having all the reviews up at the same time is a good thing, I think we >> need to always start with the lowest branch the patch is expected to apply >> to and merge up towards master. I think the wiki says merge down for >> features and merge up for bugs. It should be up always. You don't want to >> start a feature in master only to discover that it can't go into 13 because >> some other feature is only in master. Same for review process. Start in >> the lowest branch and work up. This will hopefully minimize where different >> people are starting from different directions. It's hard to follow feedback >> and ensure you've got all the comments covered like that. > > Generally, I agree with starting the review on the lowest branch and > working up. If a patch is substantially different enough between major > versions that may not always work, but I could see people focussing on > master and forgetting to properly review the release branches - which > is where the most attention should generally be spent. > > Like Corey, I'm not sure we can always say "cherry-pick up". New > features feel like they *must* be written for master first, then > cherry-picked back as appropriate. > >> Something I've noticed though is that dependencies get messed up when >> cherry-picking a series of dependent patches. Look at my patches 46, 47, >> 48 for master. If I cherry-pick 48 to my local repo, I get all 3 which is >> good because I can't test any without all 3. BUT now look at 43, 44, 45 for >> 13. When I check out 45, I get only 45 which is an issue. Maybe this is >> just an artifact of this being the first time with this scenario but it's >> something to look out for. >> >> Other things: >> >> There's a rebase button on reviews which need it but if you click it, you >> lose you're votes. :( We probably need a policy around rebasing reviews. > > The +1's may "go away" on the current review, but they do still show > up in the history. If someone has a +1 and has to rebase for the final > merge, I don't think we need to go through another cycle. > >> I've noticed a couple of times where doing a 'git review' regenerated the >> Change ID and I can't figure out why. I've resorted to running 'git review >> -n' to see the commands and just running the 'git push' part. I'm still >> investigating. >> >> If you move between major releases you'll find various orphaned files and >> directories that are part of one release but not antother. Use 'git clean >> -fd' to clean them up. BEWARE: this will remove all files/directorie
Re: [asterisk-dev] Branches
On Sun, Apr 19, 2015 at 4:42 AM, Olle E. Johansson wrote: > How do I push changes to my branches? If I try a git push my gerrit > username/password doesn't work. > Hi Olle - I hadn't yet updated the Gerrit Usage wiki page with instructions on manipulating the team branches. I've gone ahead and updated it now with a section on working with team branches: https://wiki.asterisk.org/wiki/display/AST/Gerrit+Usage While I've tested doing direct pushes with my account to a team branch, it'd be good to have someone else test it out as well. If you have a permissions problem, please paste the full command + error so I can help track it down. Thanks - Matt -- Matthew Jordan Digium, Inc. | Director of Technology 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA Check us out at: http://digium.com & http://asterisk.org -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] A Week with GIT/Gerrit
On Thu, Apr 16, 2015 at 5:00 PM, George Joseph wrote: > > The Emails: > > Overall I think they're too verbose. > "Change in asterisk[master]: bridge.c: NULL app causes crash during attended > transfer" > might be better as > "bridge.c: NULL app causes crash during attended transfer > (asterisk[master])" > It's not a lot shorter but it has the most valuable info at the front. That's pretty easy. > Also, the mail generated by "ReplacePatchSet" which gets sent on a rebase, > doesn't tell you why you're getting the message but it does have the entire > original commit message which doesn't really help. I'd remove the commit > message and add the text of the last change. I.E. "Foo Bar: Patch Set 8: > Patch Set 7 was rebased". That'll at least tell reviewers not to worry > about it. I think that makes some assumptions about why a patch set was replaced. It doesn't just occur during a rebase - it could just as easily occur due to a decrease/increase in the patch scope from comments on the previous patch set, in which case reading the text of the new commit message may be useful. Reading through your suggestion, I'm not sure what in the e-mail templates would give what you're looking for. The ReplacePatchSet does include the number of the new patch set, as well as the change subject - but inferring why a patch set was updated doesn't feel possible. > Removing "(Code Review)" from the sender would be good as well. I can do that. > Cherry-picking: > > I think there are some issues we still need to figure out about the process > and the system. Process first... > > While having all the reviews up at the same time is a good thing, I think we > need to always start with the lowest branch the patch is expected to apply > to and merge up towards master. I think the wiki says merge down for > features and merge up for bugs. It should be up always. You don't want to > start a feature in master only to discover that it can't go into 13 because > some other feature is only in master. Same for review process. Start in > the lowest branch and work up. This will hopefully minimize where different > people are starting from different directions. It's hard to follow feedback > and ensure you've got all the comments covered like that. Generally, I agree with starting the review on the lowest branch and working up. If a patch is substantially different enough between major versions that may not always work, but I could see people focussing on master and forgetting to properly review the release branches - which is where the most attention should generally be spent. Like Corey, I'm not sure we can always say "cherry-pick up". New features feel like they *must* be written for master first, then cherry-picked back as appropriate. > Something I've noticed though is that dependencies get messed up when > cherry-picking a series of dependent patches. Look at my patches 46, 47, > 48 for master. If I cherry-pick 48 to my local repo, I get all 3 which is > good because I can't test any without all 3. BUT now look at 43, 44, 45 for > 13. When I check out 45, I get only 45 which is an issue. Maybe this is > just an artifact of this being the first time with this scenario but it's > something to look out for. > > Other things: > > There's a rebase button on reviews which need it but if you click it, you > lose you're votes. :( We probably need a policy around rebasing reviews. The +1's may "go away" on the current review, but they do still show up in the history. If someone has a +1 and has to rebase for the final merge, I don't think we need to go through another cycle. > I've noticed a couple of times where doing a 'git review' regenerated the > Change ID and I can't figure out why. I've resorted to running 'git review > -n' to see the commands and just running the 'git push' part. I'm still > investigating. > > If you move between major releases you'll find various orphaned files and > directories that are part of one release but not antother. Use 'git clean > -fd' to clean them up. BEWARE: this will remove all files/directories that > aren't part of the current branch or in the .gitignore files. If you have > local scripts or other stuff you want to keep between checkouts, add them to > .git/info/exclude. > > If you're a Google Apps/Gmail user use the filter > "list:"gerrit.asterisk.org" to filter all messages regardless of repo. > > If you're switching between branches with the same major version a lot, > install ccache! You're compil
Re: [asterisk-dev] Git Migration update
On Tue, Apr 14, 2015 at 9:24 AM, Russell Bryant wrote: > On Mon, Apr 13, 2015 at 6:52 PM, Matthew Jordan wrote: >> >> For *right now*, we are going to try cherry-picking the changes to the >> affected branches when the change is first up for review. This is >> clearly a pretty big change in process, as the act of merging into >> other branches was (a) always done by those with commit access and (b) >> never reviewed. There's at least two good reasons to give this a try: >> >> (1) There isn't anyone with "commit" access. Anyone can post a review >> up to Gerrit. The plus side is that there are far fewer barriers to >> getting a patch into Asterisk. The downside is that there isn't a >> select group of people who have been trusted to do the merges. The >> only way to ensure that patches actually do get merged into all the >> branches is to require people to put the patches up with the initial >> review. >> >> (2) Gerrit really, really wants to review things. That's a good thing: >> we've had plenty of bad merges take out branches in the past - either >> from compilation issues, subtle bugs that creep in due to API >> compatibility problems, etc. We've had even more that get merged >> upstream and fail to take advantage of APIs that exist in later >> versions of Asterisk. Reviews will help to catch that. >> >> This is a trial. We'll re-evaluate how things are working at the end >> of the week. So, tentatively, I think the model of cherry-picking changes to all affected branches (including master) is working out okay. This does mean the volume of code reviews has gone up, but we appear to be keeping reasonable pace with the changes. One of the benefits of Gerrit is that while the volume of code reviews is greater, it is: (1) FAR easier to get changes merged in, particularly when the entire change is now reviewed for all branches. (2) Much more collaborative, as anyone can address findings and/or fix up commits and update reviews. As such, I've gone ahead and updated the various wiki pages (with some help from Corey and George) to note the Git related policies. The major pages are: * Patch Contribution Process (https://wiki.asterisk.org/wiki/display/AST/Patch+Contribution+Process) A very high level page that details for new(er) developers how to submit a patch to the project. It's also a good overview for everyone, and links to many of the pages below. * Git Usage (https://wiki.asterisk.org/wiki/display/AST/Git+Usage) This brief page lists out the various Git repositories (mirrors and the like), and specific recommendations for how the -2+2 reviews should be handled. * Gerrit Usage (https://wiki.asterisk.org/wiki/display/AST/Gerrit+Usage) This rather detailed page contains instructions for using Gerrit and git review. * Commit Messages (https://wiki.asterisk.org/wiki/display/AST/Commit+Messages) Details proper formatting of commit messages. Since the commit messages are also reviewed, this is important for everyone. * Software Configuration Management Policies (https://wiki.asterisk.org/wiki/display/AST/Software+Configuration+Management+Policies) Details the types of branches in Asterisk (Standard vs LTS), new feature/bug fix policies, as well as the currently supported branches. Most of this should be familiar to long-time developers of Asterisk, and not much has changed here. I'm sure there is information that is still missing or unclear. If you have any questions about the content on the pages above, please feel free to ask here on the mailing list or in #asterisk-dev, and I (or others) will work to get them cleared up. Thanks! Matt -- Matthew Jordan Digium, Inc. | Director of Technology 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA Check us out at: http://digium.com & http://asterisk.org -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
[asterisk-dev] Asterisk 1.8/12 build system changes
Hello! As you know, 1.8 and 12 are in security fix only mode. Generally, that would normally mean that releases made from those branches would only ever be made from the previous tag, ensuring that the only changes in the versions are specific to the security issues being resolved. However, since we've moved to Git, there are a few things that needed to be merged into those branches for them to be useful. That includes a minimum amount of Git support (.gitignore files, for example). More generally, that also included menuselect, as those branches previously relied on svn:externals to pull menuselect in. That begs the question: the next time we make a release of 1.8/12 for security reasons, what is the release? And what should it be called? I can see a few different options: * The next release is 1.8.32.4/12.8.3, but is made from the branch and contains the menuselect/git changes. * We make a special, one-time only, bug fix release of 1.8/12 containing the menuselect/git changes, with a note of why it was made. Those releases would go out as 1.8.33.0 and 12.9.0. * We don't make a special bug-fix release, but instead the next security release is made as 1.8.33.0/12.9.0 and contains both the menuselect/Git changes as well as the security release changes. Note that in any of the cases mentioned above, the UPGRADE notes will clearly state what has changed in the version, including the menuselect alterations. Thoughts? Suggestions? Flames? -- Matthew Jordan Digium, Inc. | Director of Technology 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA Check us out at: http://digium.com & http://asterisk.org -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] [Code Review] 4490: astdb: Allow clustering of the Asterisk Database between multiple Asterisk servers
On Wed, Apr 8, 2015 at 1:03 PM, Mark Michelson wrote: Before I repost the AstDB Clustering review from Review Board onto Gerrit, I wanted to address Mark's concerns below. Depending on what people think, it may be worth just shelving the idea. > > The only things I can think of that are issues here are based on theoretical > usage of shared DB families, especially global ones. > > Say that someone is sharing /foo/key between Asterisk 1 and Asterisk 2. A > user on Asterisk 1 sets /foo/key = bar at the same time that a user on > Asterisk 2 sets /foo/key = baz. What may happen is that the local Asterisk > boxes will set the values locally and then publish the updated values > near-simultaneously to the other Asterisk box. The result may be that they > both have /foo/key = bar, they both might have /foo/key = baz, or Asterisk 1 > may end up with /foo/key = baz and Asterisk 2 ends up with /foo/key = bar. > Essentially, there is nothing in place to guarantee the synchronization of > globally shared values. That is correct. There is no implicit synchronization. Using a 'global shared family' implies some level of knowledge about how the keys are used on the respective systems. Where this is useful is places like registration, where you "know" that the devices registering to a cluster of Asterisk servers are all unique, but you want the knowledge of the registration to be shared globally. In that respect, this is very much like clustering of MWI. There is no aggregation of MWI IDs between Asterisk instances, nor is there synchronization of values. If someone configures identical mailbox IDs on two Asterisk systems and updates the mailbox state to different states on different servers, a discontinuity will occur. > So what's the best way to deal with this? I can think of several answers: > * The AstDB may not be the right tool for this use case and you should be > using a key-value store that is built for this instead. Possibly. In that case, you'd simply have the AstDB pass through to some other mechanism (redis/RabbitMQ/etc.) In the long run this may be better. It would be interesting to have the AstDB act as a facade on top of some other technology, defaulting to SQLite3. > * You may be able to satisfy your use case with unique shared keys instead of > global shared keys. I think they are separate use cases. If you don't know whether or not you will have collisions, unique shared keys is clearly the answer, but you have to aggregate the duplicates yourself. If you have global keys, you're either not caring about the synchronization, or you 'know' that all keys will be unique across all Asterisk instances. > * We may want to make global shared keys one-way. In other words, there is an > "owner" of the key and "listeners" for changes in the key's value. Listeners > on a global shared key cannot update their local DB with new values; only the > owner can push new values to it. Listeners on a global shared key cannot > share the value with other listeners; only owners may push changes to > listeners. I think if we went down that road, I'd personally rather scrap the change and have the AstDB sit in front of other technologies. > While I'm thinking about it, there's also the possibility that the underlying > AstDB implementation could be replaced with a key-value store that has the > concept of replication built into it. If that were done, then presumably, > there would be no need to involve Stasis or SIP PUBLISH in the process of > sharing values between Asterisk boxes. > Yup. SO! The question is: is this change worth having, or should it be scrapped in favour of some alternate approach that makes use of other technology? My feelings won't be hurt if the answer is "ditch it and do something else" - this was a fun piece of code to right on some plane flights. On the other hand, I don't have any real interest in writing an alternative approach, so if the expectation is that an AstDB wrapper around RabbitMQ or Redis will magically appear if I hit the delete key, that expectation is likely to be wrong. -- Matthew Jordan Digium, Inc. | Director of Technology 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA Check us out at: http://digium.com & http://asterisk.org -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] Subjects for e-mails
On Tue, Apr 14, 2015 at 9:43 AM, Dan Jenkins wrote: > > On Tue, Apr 14, 2015 at 3:18 PM, Russell Bryant > wrote: >> >> On Tue, Apr 14, 2015 at 8:47 AM, Matthew Jordan >> wrote: >>> >>> On Tue, Apr 14, 2015 at 2:15 AM, Olle E. Johansson >>> wrote: >>> > Can we possibly have different Subject: lines in e-mails for a commit >>> > and for a review. Seems like >>> > everything is a "change in asterisk" now. I would like to be able to >>> > prioritize reading the >>> > commits. >>> > >>> >>> I took a look at the Gerrit settings, and it doesn't appear to support >>> that: >>> >>> https://gerrit-review.googlesource.com/Documentation/user-notify.html >>> >>> and: >>> >>> >>> https://gerrit-review.googlesource.com/Documentation/config-gerrit.html#sendemail >>> >>> It does support having commits go to a separate list than reviews; >>> that should already be set up for the asterisk-commits list (although >>> the last tweaks on it just went in yesterday). >> >> >> With gerrit it's actually pretty easy to subscribe to the messages you >> want. You can get notified for new reviews, when patches are updated, when >> patches merge, or when people make comments (all optionally on a per >> repository basis). So, another option would be to drop sending to the list >> completely and let people configure their own notifications that suit their >> needs and interests. >> >> -- >> Russell Bryant >> >> -- >> _ >> -- Bandwidth and Colocation Provided by http://www.api-digital.com -- >> >> asterisk-dev mailing list >> To UNSUBSCRIBE or update options visit: >>http://lists.digium.com/mailman/listinfo/asterisk-dev > > > I like this idea Russell Given that the e-mails are now only going to the asterisk-commits and asterisk-code-review lists - and not the asterisk-dev list - I think a combination of both options is probably okay. * If you want to see the spam, subscribe to the lists * If you want personalized e-mail notifications, set it up through Gerrit -- Matthew Jordan Digium, Inc. | Director of Technology 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA Check us out at: http://digium.com & http://asterisk.org -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] Subjects for e-mails
On Tue, Apr 14, 2015 at 2:15 AM, Olle E. Johansson wrote: > Can we possibly have different Subject: lines in e-mails for a commit and for > a review. Seems like > everything is a "change in asterisk" now. I would like to be able to > prioritize reading the > commits. > I took a look at the Gerrit settings, and it doesn't appear to support that: https://gerrit-review.googlesource.com/Documentation/user-notify.html and: https://gerrit-review.googlesource.com/Documentation/config-gerrit.html#sendemail It does support having commits go to a separate list than reviews; that should already be set up for the asterisk-commits list (although the last tweaks on it just went in yesterday). -- Matthew Jordan Digium, Inc. | Director of Technology 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA Check us out at: http://digium.com & http://asterisk.org -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] Gerrit plugin suggestions
On Sun, Apr 12, 2015 at 7:04 PM, George Joseph wrote: > > menuextender: Allows the creation of additional menu items. I'd suggest > using this for adding links to various wiki pages, git.asterisk.org, etc. > > reviewers-by-blame: This might be a little too much but it automatically > adds reviewers to a change based on who last changed the affected lines. > > wip: Allows changes to be maked as Work-In-Progress. Would be good for RFC > changes. wip plugin installed. You should now see a "Work in Progress" button on reviews. Pressing that will cause the review to be marked as not ready for review, and not show up in reviewers list of reviews. Updating the patch set or setting it back to "Ready for Review" causes it to show back up. -- Matthew Jordan Digium, Inc. | Director of Technology 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA Check us out at: http://digium.com & http://asterisk.org -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] Git Migration update
On Mon, Apr 13, 2015 at 5:52 PM, Matthew Jordan wrote: > On Sun, Apr 12, 2015 at 1:57 AM, George Joseph > wrote: >> >> >> On Sat, Apr 11, 2015 at 10:15 PM, Matthew Jordan wrote: >>> Further updates after Day 2 (3?): 1. Due to popular request, the code review e-mails (which were nearing spam levels) are going to be redirected to a new mailing list. The new mailing lists is "asterisk-code-review" - see http://lists.digium.com/cgi-bin/mailman/listinfo/asterisk-code-review 2. All branches should have .gitignore/.gitreview files, including 1.8/12 3. Versions should be reported correctly in Git branches. A review is up now to get the Test Suite understanding things. Items on the short-list to figure out: 1. Backport menuselect into 1.8, 11, and 12 2. Fix (or investigate) build failures that occur when switching between branches. I'm not sure if anyone else has run into this yet, but "./configure && make" tends to get stuck on menuselect rather hard, and I'll have to run a 'make clean' to get things moving again, which is weird. 3. Fix 'make update' 4. Document how to push to team branches, and make sure that works as expected 5. Update the Gerrit web links module to point to our instructions on Git/Gerrit 6. Tackle the repotools release-summary scripts There's plenty more after that, but that's on my short-term punch list. If anyone would like to look at any of those items (apart from the muck with Gerrit modules item, at any rate), feel free to help yourself :-) -- Matthew Jordan Digium, Inc. | Director of Technology 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA Check us out at: http://digium.com & http://asterisk.org -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] Git Migration update
On Sun, Apr 12, 2015 at 1:57 AM, George Joseph wrote: > > > On Sat, Apr 11, 2015 at 10:15 PM, Matthew Jordan wrote: >> > > I'm wondering if we can do this... > > You submit a review on the lowest target branch, using 13 as an example. > The review gets reviewed and merged into 13. Once the review is closed > gerrit won't allow a cherry-pick but git of course has no problems with it. > So maybe we can write/obtain a hook/plugin that allows the submitter to > cherry-pick the change directly into the target branch, say master, > bypassing the review process, assuming a clean merge. > > Alternative... We normally don't have access to commit to refs/head > directly but what if we had a hook that allowed a commit to be merged > directly IF the commit-id/change-id matched a review already approved and > merged to the original branch. As an update to everyone: For *right now*, we are going to try cherry-picking the changes to the affected branches when the change is first up for review. This is clearly a pretty big change in process, as the act of merging into other branches was (a) always done by those with commit access and (b) never reviewed. There's at least two good reasons to give this a try: (1) There isn't anyone with "commit" access. Anyone can post a review up to Gerrit. The plus side is that there are far fewer barriers to getting a patch into Asterisk. The downside is that there isn't a select group of people who have been trusted to do the merges. The only way to ensure that patches actually do get merged into all the branches is to require people to put the patches up with the initial review. (2) Gerrit really, really wants to review things. That's a good thing: we've had plenty of bad merges take out branches in the past - either from compilation issues, subtle bugs that creep in due to API compatibility problems, etc. We've had even more that get merged upstream and fail to take advantage of APIs that exist in later versions of Asterisk. Reviews will help to catch that. This is a trial. We'll re-evaluate how things are working at the end of the week. Instructions for cherry-picking changes are on a draft wiki page here: https://wiki.asterisk.org/wiki/display/AST/Git+Usage -- Matthew Jordan Digium, Inc. | Director of Technology 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA Check us out at: http://digium.com & http://asterisk.org -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] Gerrit plugin suggestions
On Sun, Apr 12, 2015 at 7:04 PM, George Joseph wrote: > > menuextender: Allows the creation of additional menu items. I'd suggest > using this for adding links to various wiki pages, git.asterisk.org, etc. Added. Right now I've just got it linking to the issue tracker and the wiki. I'll add git.asterisk.org next. Any other suggestions? Maybe the specific Gerrit usage page on the wiki? > reviewers-by-blame: This might be a little too much but it automatically > adds reviewers to a change based on who last changed the affected lines. If the project had less history, I think this would be a great idea. As it is, I think we have a few people who would be ... surprised? ... if they received an e-mail that they were a reviewer on an Asterisk code review. > wip: Allows changes to be maked as Work-In-Progress. Would be good for RFC > changes. I'll take a look at this one next. -- Matthew Jordan Digium, Inc. | Director of Technology 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA Check us out at: http://digium.com & http://asterisk.org -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] How to get peer review for patch to deprecated module
On Sun, Apr 12, 2015 at 11:26 AM, Alex Villacís Lasso wrote: > El 11/04/15 a las 22:59, Matthew Jordan escribió: >> >> On Sat, Apr 11, 2015 at 4:31 PM, Alex Villacís Lasso >> wrote: >> I'd recommend doing the following: >> >> * Re-open ASTERISK-20347 and attach the patch to the issue after >> signing a CLA [1]. Regardless of the state of the source control for >> Asterisk, your patch will at least be tracked in the project. Again, >> I'll be happy to re-open the issue once you've confirmed you're >> willing to sign a CLA and/or have already done so. > > I have already signed a license agreement for user a_villacis on JIRA. I > have also uploaded the patch (against 11.17.0) on ASTERISK-20347. How do I > proceed to get the bug reopened? I've re-opened the bug. Thanks for attaching the patch. I'd highly recommend posting the patch for review on Gerrit. While things are a bit in a state of flux - in fact, we're fleshing out some policy ideas right now - you should be able to post the patch for review against the Asterisk 11 branch at a minimum. To do that, please follow the instructions on the wiki: https://wiki.asterisk.org/wiki/display/AST/Gerrit+Usage Note that since you are posting this against the 11 branch, you'll want to invoke git review with that branch: git review -t ASTERISK-20347 11 -- Matthew Jordan Digium, Inc. | Director of Technology 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA Check us out at: http://digium.com & http://asterisk.org -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] Git Migration update
On Sat, Apr 11, 2015 at 11:15 PM, Matthew Jordan wrote: > > 1. We need to determine the best way to handle maintaining the long > running branches. While rebasing is appropriate for topic branches > (team branches) that closely track a mainline branch, the mainline > branches are a bit different. They not only don't have ever commit > merged into them (either going 'up' from 11 => 13 => master or 'down' > from master => 13 => 11), but patches are highly likely to merge > cleanly. ABI issues in 11/13 are a bigger concern than those in > master; APIs will have changed; etc. Ugh. This is what I get for writing this at 23:15. The gist of this paragraph is: I don't think 'git merge' will work well on mainline branches, regardless of the order in which we merge. I suspect we're going to want to cherry-pick. -- Matthew Jordan Digium, Inc. | Director of Technology 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA Check us out at: http://digium.com & http://asterisk.org -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
[asterisk-dev] Git Migration update
Hey everyone - As an update on the Git migration, here is the current state of the world: 1. The SVN repos have been marked read-only. While you will still be able to checkout from SVN, you shouldn't commit to any of the branches. Note that even if you do, those commits won't make it into the Git repos - so it's not really a good idea to try :-) 2. The project has been moved over to a Git repo under Gerrit (https://gerrit.asterisk.org). You can clone the project using the instructions on the 'asterisk' repo project page: https://gerrit.asterisk.org/#/admin/projects/asterisk Thanks goes to George Joseph for quickly getting a .gitignore/.gitreview file up for review and included in the repo. 3. Mirrors for the project have been set up on git.asterisk.org and Github. These mirrors are particularly useful for providing source browsing of the repo. 4. A patch has been put up against 'master' to rework the source file version macros. By rework, I mostly mean "remove", although the macro itself could not be fully removed due to other features relying on the file name being registered. See https://gerrit.asterisk.org/#/c/54/ for more details. So what are some immediate next steps? 1. We need to determine the best way to handle maintaining the long running branches. While rebasing is appropriate for topic branches (team branches) that closely track a mainline branch, the mainline branches are a bit different. They not only don't have ever commit merged into them (either going 'up' from 11 => 13 => master or 'down' from master => 13 => 11), but patches are highly likely to merge cleanly. ABI issues in 11/13 are a bigger concern than those in master; APIs will have changed; etc. As a result, my initial plan was to have developers cherry-pick to the mainline branches as appropriate, with the initial commit being done to 'master'. There are some downsides to this approach: a) Each cherry-pick has to be reviewed. This can make it difficult to track the reviews, as each review is completely separate from the others. b) Cherry-picks through the Gerrit UI will not always work. Folks will need to be careful when cherry-picking back to a branch that requires fixing merge conflicts, as getting the Change ID correct in such a case is important to keep all of the Gerrit reviews tied together. c) We'll be changing our process from merging 'up' branches to 'down' branches. Change is scary. I think we're going to need some time to work through the implications of how we handle the mainline branches. I suggest hanging out in #asterisk-dev over the next few days as we work through the details. In the meantime, I've restored the TEST-Asterisk repo so folks can play around with the cherry-picking, and/or other models of branch maintenance. I certainly welcome any suggestions on the best way to make the process work. 2. Russell noted in George's .gitreview/.gitignore review (https://gerrit.asterisk.org/#/c/42/) that we may want to include the fullname of contributors/users along with their e-mail address. I think that's a good idea, but that would mean updating our commit message template, script, and our process. Comments/suggestions welcome here on that proposal. 3. The 'make update' Makefile target needs to be updated. If you have some Makefile-foo and git-foo and would like to look at that, that'd be awesome. Over the next few days, I'll be updating the Asterisk wiki pages with more information. I'll reply to this thread as that happens. If you have any questions, please don't hesitate to reply here or jump in #asterisk-dev. Thanks! Matt -- Matthew Jordan Digium, Inc. | Director of Technology 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA Check us out at: http://digium.com & http://asterisk.org -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev