Re: [asterisk-dev] PJSIP signalling issue
On Tue, Oct 9, 2018, at 9:11 AM, Abhay Gupta wrote: > Hi, > > We are having problem with Airtel service provider in India . > > Asterisk sends SIP 200OK —> Airtel responds with ACK but asterisk does > not recognises the same . Though the same works with chan_sip I see no problem with this. It's not a retransmission, those are two separate calls. You can tell based on the Call-ID being different. The first is "asbcwnc0a1gca6padwqawgqpwv8gqplbn...@b.5.268.ims.airtel.in" the second is "asbcjhwwc6h5slz6hjlr5coi74j46ozwh...@b.5.140.ims.airtel.in". It appears as though the ACKs were handled appropriately. If there is something else then you'd need to be more specific about what is happening. -- Joshua Colp Digium - A Sangoma Company | Senior Software Developer 445 Jan Davis Drive NW - Huntsville, AL 35806 - US Check us out at: www.digium.com & www.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] No Audio and ICE negotiation logs
On Mon, Oct 8, 2018, at 5:11 PM, Balraj Singh wrote: > Hi, > We have Asterisk Installed on AWS with following configs: > Asterisk Version: 15.4.0 with NAT and Gateway. > OS: CentOS. > > The problem we are facing is that we are getting Audio while calling using > a SIP Phone connected to our Asterisk using our Local IP. But, we are > facing no Audio issue on both sides when calling from an External IP. By > External IP I mean, calling from a connection outside of our Infrastructure. > > So for that, we have configured NAT settings and stun server in pjsip.conf > and rtp.conf respectively. But even then we are facing the same problem, NO > AUDIO!. > By turning on rtp debug on we can see the following logs: I'd suggest getting a packet capture of a failing case and looking at the ICE negotiation itself to understand why it fails. You also need to look at the ICE candidates to understand the possible paths. As well this message really belongs on the asterisk-users list or the community forums[1]. [1] https://community.asterisk.org/ -- Joshua Colp Digium - A Sangoma Company | Senior Software Developer 445 Jan Davis Drive NW - Huntsville, AL 35806 - US Check us out at: www.digium.com & www.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] PJSIP and RTP address selection
On Thu, Sep 13, 2018, at 7:16 PM, Joshua Colp wrote: > On Thu, Sep 13, 2018, at 7:00 PM, Matt Fredrickson wrote: > > > > > > I have two potential fixes (and two that aren't practical options I > > > don't think but might be with knowledge I don't have) both with > > > advantages and disadvantages: I gave some further thought over this weekend to any other alternative approaches which would have less of an impact but sadly came up empty. I think the list you provided is indeed the available options. -- Joshua Colp Digium - A Sangoma Company | Senior Software Developer 445 Jan Davis Drive NW - Huntsville, AL 35806 - US Check us out at: www.digium.com & www.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] doxygen offline
On Fri, Sep 14, 2018, at 3:15 PM, i...@magnussolution.com wrote: > hello, anyone know why the DEV doc is unavailable? > http://doxygen.asterisk.org/trunk/index.html > <http://doxygen.asterisk.org/trunk/index.html> > > Was migrated to another domain? It hasn't been migrated and is on Matt Fredrickson's list to look at. Even before now it was not updated in quite a few years. If you need it immediately then it can be locally generated using the "make progdocs" target. -- Joshua Colp Digium - A Sangoma Company | Senior Software Developer 445 Jan Davis Drive NW - Huntsville, AL 35806 - US Check us out at: www.digium.com & www.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] PJSIP and RTP address selection
een SDP for the conversation > > already, those addresses, otherwise for the remote address of the SIP > > communication - this would break a number of things potentially, thus > > likely not a serious option. For example, if we're sending an INVITE to > > a web-socket transport, then potentially the web-socket connection has > > been proxied and the remote address of the web socket connection isn't > > actually where the remote side is, for example, if proxying via > > httpd/apache to localhost:8088 then asterisk sees 127.0.0.1 as the > > "rermote". > > > > I'm tending towards option 2. This would perhaps also have a side > > effect of minimizing attack surface for things like RTP bleed. > > It might be the lowest friction way forward (without rewriting the > RTP/ICE/STUN/TURN layers). It would be. > > > I suspect this has not come to light before since most setups is likely > > to only have a single IPv4 and single IPv6 global address, or in the > > case of multi-homing would have one on each interface with the kernel > > RPF filter getting rid of traffic from a source other than where it > > would route back to, basically forcing an IP match based on route-based > > address selection. > > Multiple IPv4 address are not very common among non-carriers. > > > Joshua suggested that before coding on this is started all use-cases > > should be explored and documented, which I think is a good idea. I'd be > > happy to drive that process, I'd however need to understand where this > > should be documented. So in this respect this email servers as a > > request for pointers. > > +1 We could grant you wiki access if you'd like to make a wiki page there to organize things in an easier fashion. As for an over all response I've been seeing if I could come up with any other alternative options which are less invasive but would still be effective. I'm continuing to research and look. Cheers, -- Joshua Colp Digium - A Sangoma Company | Senior Software Developer 445 Jan Davis Drive NW - Huntsville, AL 35806 - US Check us out at: www.digium.com & www.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] ContactStatus AMI Event on PJSIP Reregistration
On Thu, Aug 16, 2018, at 4:37 AM, Olivier wrote: > Hello Joshua, > > I can think of a RegistrationExpiredWithoutRenewal event that is quite > independant of Qualify settings and still can be useful. I believe this should already occur. My original question wasn't about refining ContactStatus or changing it substantially directly, the fact that I'm asking my original question is just because I'd like to remove that code which consumes extra resources for something which I personally think is redundant. -- Joshua Colp Digium, Inc. | Senior Software Developer 445 Jan Davis Drive NW - Huntsville, AL 35806 - US Check us out at: www.digium.com & www.asterisk.org -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] ContactStatus AMI Event on PJSIP Reregistration
On Wed, Aug 15, 2018, at 11:54 AM, Leandro Dardini wrote: > While you work on the AMI events for PJSIP endpoints, don't forget the > issue with no AMI events issued when a PJSIP endpoint loses completely the > connectivity. If it de-registers, an event is fired, if you just pull the > plug, no events are generated. If properly configured (qualify is enabled) then an event will be generated that it has become unreachable[1]. Without qualify there is no way for Asterisk to know this. [1] https://wiki.asterisk.org/wiki/display/AST/Asterisk+13+ManagerEvent_ContactStatus -- Joshua Colp Digium, Inc. | Senior Software Developer 445 Jan Davis Drive NW - Huntsville, AL 35806 - US Check us out at: www.digium.com & www.asterisk.org -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
[asterisk-dev] ContactStatus AMI Event on PJSIP Reregistration
Kia ora, I currently have a code review up[1] which removes the ContactStatus AMI event when a PJSIP endpoint re-registers. I removed it as I believed the ContactStatus event was redundant (as the status has not changed from the last event that would have been sent). Does anyone currently rely on this behavior? Cheers, [1] https://gerrit.asterisk.org/#/c/asterisk/+/9822/ -- Joshua Colp Digium, Inc. | Senior Software Developer 445 Jan Davis Drive NW - Huntsville, AL 35806 - US Check us out at: www.digium.com & www.asterisk.org -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] NET::ERR_CERT_SYMANTEC_LEGACY: Re-issue your RapidSSL certificate!
On Sun, Aug 5, 2018, at 3:39 PM, Dan Jenkins wrote: > Ha! Already informed them on Friday via other means. I'm told there is now > an IT ticket open Indeed, I have brought it up with them and it is on their side to get new ones issued and deployed. I don't have a time frame on when they will be doing it, though. -- Joshua Colp Digium, Inc. | Senior Software Developer 445 Jan Davis Drive NW - Huntsville, AL 35806 - US Check us out at: www.digium.com & www.asterisk.org -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] Trigger chan_pjsip NOTIFY via ARI
On Thu, Jul 26, 2018, at 5:29 AM, Floimair Florian wrote: > I did a quick search, but so far haven't found anything aside from > triggering notify via Asterisk CLI. > > > > So my question is: Is there any way to trigger a NOTIFY via ARI? There is no mechanism to do this in ARI. -- Joshua Colp Digium, Inc. | Senior Software Developer 445 Jan Davis Drive NW - Huntsville, AL 35806 - US Check us out at: www.digium.com & www.asterisk.org -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] JIRA: 15.4 and 13.21 still tagged as unreleased.
On Fri, May 11, 2018, at 8:43 AM, Alexander Traud wrote: > Not sure where to report this elsewhere. Updated. > By the way, when I know when a bug was introduced, should I > * selected the latest release version = tested, or > * select the version(s) when the bug was introduced? At a minimum the latest version that it impacts, but the version where it was introduced can additionally be mentioned. -- Joshua Colp Digium, Inc. | Senior Software Developer 445 Jan Davis Drive NW - Huntsville, AL 35806 - US Check us out at: www.digium.com & www.asterisk.org -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] The "Busy" App.... isn't.
On Wed, Apr 4, 2018, at 8:04 PM, Steve Murphy wrote: > On Wed, Apr 4, 2018 at 3:20 PM, Matt Fredrickson <cres...@digium.com> wrote: > > > On Mon, Apr 2, 2018 at 9:40 PM, Steve Murphy <m...@parsetree.com> wrote: > > > Someone complained about errant behavior of the Busy and Hangup apps... > > > and I see some strangenesses that might make them credible. > > > > > > > > > > > I cut off the rest of the debug, but the call lasts the full 15 seconds > > > after busy() is called, and then hangs up. It's interesting to see what > > the > > > trunk provider does on top of all this. > > > > > > So, my question is: Did I do the best thing? It seems to work, but I > > have no > > > idea if I'm creating bugs galore in other usages. > > > > There is an assumption (for asterisk C level applications, like > > Busy()) when using ast_read that if it ever returns NULL that the > > underlying channel has been hung up and the application should quickly > > exit. Busy() is honoring that assumption. It looks like in > > sip_indicate() of chan_sip.c, when a AST_CONTROL_BUSY is queued on a > > SIP channel, it sets the soft hangup flag on the channel. That's why > > you're seeing this behavior. The timeout from Busy() is invalidated > > if the underlying channel wants to be hung up. > > > > I would be highly concerned about breaking that assumption, as you are > > doing in your proposed patch. Is there a particular reason you want > > to keep the call up for 15 seconds before releasing the channel? > > > > I was tempted so say: > > Mainly for the sake of that "Busy Here" SIP message I'd like to see go > back to the > trunk provider. With my patch, it goes out. Without it, nada. > > But... incoming calls can come from either of two IP's, and "sip set debug > ip xx" > can only monitor one. So, what I thought was happening may not be! > > But, really if the Busy app takes an arg, but never honors it... why > does it take the > argument at all? Legacy purposes where it's not signaled I'd bet. Specifically, when the busy tone itself is generated locally. -- Joshua Colp Digium, Inc. | Senior Software Developer 445 Jan Davis Drive NW - Huntsville, AL 35806 - US Check us out at: www.digium.com & www.asterisk.org -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] Weirdness-- intermittent loss of recordings w/ 13.5.0
On Sat, Mar 24, 2018, at 12:44 PM, Steve Murphy wrote:
> More news--
>
> I demonstrated that this problem still exists in 13.19.0, although we are
> still
> probing/debugging this problem with 13.5.0; if we find a solution, we hope
> it will apply to all
> versions of 13, as well as those more recent releases also.
>
> As I described in a recent letter to asterisk-dev, we have a separate
> daemon that
> opens an AMI connection to asterisk. When it spots both channels are joined
> to a bridge,
> it issues a StartMonitor AMI action, which invokes res_monitor on Asterisk.
> It kinda looked
> like those times when the AMI action arrived in less than a millisecond
> were more successful
> than those which came slightly later. To test this theory, I added a
> millisecond wait to the
> issuance of the StartMonitor, and roughly doubled the probablility of an
> empty recording file.
> I upped it to 2 msec, and the probability got even higher.
>
> The failed recordings are done with the bridge technology of native_rtp;
> the successful ones
> switch from native_rtp to simple_bridge. There appears to be a vanishing
> opportunity to
> switch the bridge tech, after which the call to __ast_monitor_start is
> ineffective. It would appear that
> the native_rtp tech doesn't honor the monitor structure attached to the
> channel.
It's up to what changes the channel (such as Monitor) to indicate that
conditions have changed, which results in the bridge re-evaluating the
situation and potentially changing the underlying technology. As Monitor is
quite old it's entirely possible that it doesn't have the call to do that.
The code is the following:
if (ast_channel_is_bridged(chan)) {
ast_channel_set_unbridged_nolock(chan, 1);
}
--
Joshua Colp
Digium, Inc. | Senior Software Developer
445 Jan Davis Drive NW - Huntsville, AL 35806 - US
Check us out at: www.digium.com & www.asterisk.org
--
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] Dual contact entries in "pjsip show contacts"
On Thu, Mar 22, 2018, at 8:43 AM, Floimair Florian wrote: > Thanks Joshua for your quick answer. > > I am indeed referring to outgoing calls. > > The contacts are created as a result of an inbound registration. > Before the first registration I only have dual entries for the > endpoints. > After the first registration I see the 2 contacts, which are in fact > identical. > The database itself only contains a single entry for all entities, which > would explain why it > works after a restart. > > The workflow is as follows. > > 1 - Create endpoint/auth/aor for Alice using ARI push configuration > 2 - Create endpoint/auth/aor for Bob using ARI push configuration >I see two entries for each of them when issuing "pjsip show endpoints" > > 3 - A registers and a contact is created > 2 (identical) contacts are shown as "Available", since there are also > two endpoints shown > > 4 - B registers and a contact is created > 2 (identical) contacts are shown as "Available", since there are also > two endpoints shown > > 5 - Alice tries to call Bob > Asterisk refuses with > res_pjsip.c: Endpoint 'Bob': Could not create dialog to invalid URI > 'Bob'. Is endpoint registered and reachable? > chan_pjsip.c: Failed to create outgoing session to endpoint 'Bob' > app_dial.c: Unable to create channel of type 'PJSIP' (cause 3 - No > route to destination) > app_dial.c: Everyone is busy/congested at this time (1:0/0/1) > pbx.c: Auto fallthrough, channel 'PJSIP/Bob-0814' status is > 'CHANUNAVAIL' > > I have seen this already more than a year ago with 13.x and 14.x as well > (currently I'm using the latest 15.3.0). > I was not able to reproduce it since as everything works flawlessly > after a restart. > It was only now that I realized that the issue is related to creating > the endpoint/auth/aor objects on a running system with no restarts > since. It sounds almost as if there are two backends for the objects, one in memory and one database... but your configuration certainly doesn't show that. Have you bumped up core debug (debug to console in logger.conf and core set debug 9) and looked to see if anything stands out? There is no cache or memory mechanism built into sorcery that is always there, so I'm not sure where it'd have two objects stored or where to look. The "pjsip show endpoints" command just asks the sorcery backends to return the data they have, for example. -- Joshua Colp Digium, Inc. | Senior Software Developer 445 Jan Davis Drive NW - Huntsville, AL 35806 - US Check us out at: www.digium.com & www.asterisk.org -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] Dual contact entries in "pjsip show contacts"
On Thu, Mar 22, 2018, at 7:22 AM, Floimair Florian wrote: > Hi! > > I am currently using an Asterisk setup with a realtime-db as backend. > We create endpoints/aors/auths using ARI Push configuration and when > that happens we see 2 contact entries when executing "pjsip show > contacts" in the CLI. > This also sporadically leads to calls being refused by Asterisk even > though the called endpoint registered successfully and is idle. I should also add - are you creating the contacts, or are you referring to contacts as a result of inbound registration? -- Joshua Colp Digium, Inc. | Senior Software Developer 445 Jan Davis Drive NW - Huntsville, AL 35806 - US Check us out at: www.digium.com & www.asterisk.org -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] Dual contact entries in "pjsip show contacts"
On Thu, Mar 22, 2018, at 7:22 AM, Floimair Florian wrote: > Hi! > > I am currently using an Asterisk setup with a realtime-db as backend. > We create endpoints/aors/auths using ARI Push configuration and when > that happens we see 2 contact entries when executing "pjsip show > contacts" in the CLI. > This also sporadically leads to calls being refused by Asterisk even > though the called endpoint registered successfully and is idle. If you are referring to inbound calls from the endpoint then that would be unrelated to your Contact issue. Inbound registration isn't consulted or used for incoming calls. Are you actually referring to outgoing calls to the endpoint? As well - is there anything different between the contacts? > > > > As soon as I restart Asterisk the dual entries are gone and everything > is working normal. > > This leads me to believe, that this must be a bug in Asterisk for the > "Push Configuration + Realtime-DB" scenario. > Can you give me any hints on what to check and where to look at in the > code to verify this situation? > I am willing to fix it myself but would need a little guidance. I don't know if anyone has tested the use of ARI push configuration with a database backed realtime, albeit there is nothing to say it shouldn't work. What do you see in the actual database? -- Joshua Colp Digium, Inc. | Senior Software Developer 445 Jan Davis Drive NW - Huntsville, AL 35806 - US Check us out at: www.digium.com & www.asterisk.org -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] SFU and screen sharing
On Wed, Mar 7, 2018, at 6:16 AM, Luca Pradovera wrote: > Hello, > unrelated to ur other issues with SFU media, is there any documentation or > starting point regarding screen sharing in the Asterisk SFU? > It is mentioned in the initial release notes, but not really explained. > > Thanks! To Asterisk it's just another video stream, there's nothing different within the SDP itself. The only change that was done was to trigger another renegotiation when a stream changed within an SFU conference which happens automatically. The rest of the work is all client side. -- Joshua Colp Digium, Inc. | Senior Software Developer 445 Jan Davis Drive NW - Huntsville, AL 35806 - US Check us out at: www.digium.com & www.asterisk.org -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] SDP interop on SFU
On Wed, Mar 7, 2018, at 5:24 AM, Luca Pradovera wrote: > Hello, > that is a good starting point, thanks. > We are using SIP.js, and actually our client is just a modified version of > CyberMegaPhone2k. > > What happens is that video stream sent from a Chrome user, when received on > Firefox, behave in an inconsistent way. Very rarely, they work. Most of the > times, we get either: > - No video at all > - A few frames at the start, then freeze > - Working video with very bad quality Then I'd suggest also using about:webrtc to examine the receive stream, as well as low level Firefox debug[1]. As the browsers are a black box problems may not end up appearing on the Asterisk side, or even the Javascript console leaving you to guess what is going on (and sometimes guessing wrongly). [1] https://gist.github.com/ibc/3a10b27812d99c8abd1b -- Joshua Colp Digium, Inc. | Senior Software Developer 445 Jan Davis Drive NW - Huntsville, AL 35806 - US Check us out at: www.digium.com & www.asterisk.org -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] SDP interop on SFU
On Fri, Mar 2, 2018, at 12:59 PM, Luca Pradovera wrote: > Hello, > we are seeing some unexpected behavior when a SFU conference contains both > a Chrome and a Firefox user. It looks like the SDP is not being generated > or translated correctly. > > SDP Chrome - Chrome > https://gist.github.com/edolix/75850d5cef44beae01d6f5076d6722c3 > > SDP Chrome - Firefox > https://gist.github.com/edolix/9bdfaa007272d8be275b4f2940fa11d5 > > SDP Firefox - Firefox > https://gist.github.com/edolix/a5ee0db0d7e1620d3de5b72bc4e3475e > > We have been trying to track down the source of this for a while. Any > pointers on where to start? I'd suggest using the latest release candidate of Asterisk. It includes a fix for Firefox that caused streams to not appear as expected. As for what's going on - you'll need to clarify further on what exactly "unexpected behavior" means. What is the scenario? What are you doing? What are you expecting to happen versus what happens? What are you using for Javascript? At a high level, though, Asterisk doesn't translate the SDP - it generates independent SDP for everyone in the unified plan format. In the case of Chrome this has to be translated to/from plan B to work. Have you examined the Javascript console to see if the SDP is complained about at all? -- Joshua Colp Digium, Inc. | Senior Software Developer 445 Jan Davis Drive NW - Huntsville, AL 35806 - US Check us out at: www.digium.com & www.asterisk.org -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] Asterisk 14 doesn't cache media, really
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. -- Joshua Colp Digium, Inc. | Senior Software Developer 445 Jan Davis Drive NW - Huntsville, AL 35806 - US Check us out at: www.digium.com & www.asterisk.org -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] Jira: Create issue: Required field: Component
On Sun, Jan 28, 2018, at 7:59 AM, Joshua Colp wrote: > On Sun, Jan 28, 2018, at 5:00 AM, Alexander Traud wrote: > > In Jira, when I create a new issue, the fields Summary and Description > > are marked with a red asterisk. I guess, that indicates a required > > field. However, for an external contributor like me, the fields > > Component, Affects Version, Severity, and Issue Guidelines are required > > as well. This is inconsistent usage of this red asterisk and therefore > > confusing. > > > > What about > > A) asterisk the remaining required fields as well or > > B) if there are several user groups with different required fields, what > > about removing the existing two asterisks? > > The red asterisk is from JIRA itself and indicates it is a required > field for it to work. There's no way that I found to mark the other > fields as required to make them appear like the JIRA ones. Instead they > use a validator in JIRA which runs before the issue is created to verify > they exist. I can't add my own non-red asterisk either because > Components is a JIRA field, not a custom field that can be edited. > > They either have to be as they are now, or they aren't required. So far > I haven't seen any complaints across the various places about it and the > quality of issue reports has actually gone up as a result (generally the > only back and forth now seems to be to get backtraces, config > information, or environment information). Actually I was able to find the right stuff in JIRA to make them marked the same way. This is now done! -- Joshua Colp Digium, Inc. | Senior Software Developer 445 Jan Davis Drive NW - Huntsville, AL 35806 - US Check us out at: www.digium.com & www.asterisk.org -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] Jira: Create issue: Required field: Component
On Sun, Jan 28, 2018, at 5:00 AM, Alexander Traud wrote: > In Jira, when I create a new issue, the fields Summary and Description > are marked with a red asterisk. I guess, that indicates a required > field. However, for an external contributor like me, the fields > Component, Affects Version, Severity, and Issue Guidelines are required > as well. This is inconsistent usage of this red asterisk and therefore > confusing. > > What about > A) asterisk the remaining required fields as well or > B) if there are several user groups with different required fields, what > about removing the existing two asterisks? The red asterisk is from JIRA itself and indicates it is a required field for it to work. There's no way that I found to mark the other fields as required to make them appear like the JIRA ones. Instead they use a validator in JIRA which runs before the issue is created to verify they exist. I can't add my own non-red asterisk either because Components is a JIRA field, not a custom field that can be edited. They either have to be as they are now, or they aren't required. So far I haven't seen any complaints across the various places about it and the quality of issue reports has actually gone up as a result (generally the only back and forth now seems to be to get backtraces, config information, or environment information). -- Joshua Colp Digium, Inc. | Senior Software Developer 445 Jan Davis Drive NW - Huntsville, AL 35806 - US Check us out at: www.digium.com & www.asterisk.org -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] Webpage Downloads
On Sun, Jan 21, 2018, at 2:04 PM, Alexander Traud wrote: > <http://www.asterisk.org/downloads/asterisk/all-asterisk-versions> > > 2) Test Release: Is it possible to remove the part about test releases > > when the final release is newer? Or link to that final release instead? > > Some users might scroll all the way down and install the "latest" test > > release although there is a newer "test" release already - the final > > release. They might overlook that the Final area is newer then the Test > > area. At least this happened to me several times already. > > Same again. I've disabled that panel and updated the internal instructions for publishing a full release to include that step. > > By the way, there are orphans in > <http://www.asterisk.org/downloads/asterisknow> > because Asterisk 11 is out of support, AsteriskNOW 5 should be out of > support. Consequently, everything below "What versions are available?" > can be removed, not to confuse novice users. Furthermore, I do not > understand the state of AsteriskNOW-10.13.66*17* because FreePBX is on > 10.13.66*22* already: > - <http://www.freepbx.org/downloads/> > - <http://wiki.freepbx.org/display/PPS/10.13.66+Release+Notes>. I can't speak on this, but Matt can probably provide input on things next week. -- Joshua Colp Digium, Inc. | Senior Software Developer 445 Jan Davis Drive NW - Huntsville, AL 35806 - US Check us out at: www.digium.com & www.asterisk.org -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] Report a regression?
On Sun, Jan 21, 2018, at 10:29 AM, Alexander Traud wrote: > > FreeBSD is not a platform that we really support. > > That means, this issue is not a regression, right? > That leads me to another question: > <http://lists.digium.com/pipermail/asterisk-dev/2018-January/076765.html>. > > >> How does an external contributor report a regression in general: > >> A) do I re-triage the issue report and flag it as regression? Or > >> B) do I create a new report and link the causing issue? Or > >> C) in another way? > > found in an [release candidate] rc or should block an upcoming rc. > > OK, bad example then. Anyway to conclude this and for the possible > future: How does one report a regression? It should be reported as a new issue with information. It'll get triaged through the normal process. If you think it's a regression you can say so on the issue, otherwise it's up to the person doing the triage whether they think it's a regression or not based on the information provided. If it's iffy then it can be discussed on the mailing list. -- Joshua Colp Digium, Inc. | Senior Software Developer 445 Jan Davis Drive NW - Huntsville, AL 35806 - US Check us out at: www.digium.com & www.asterisk.org -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] Report a regression?
On Sat, Jan 20, 2018, at 5:16 PM, Alexander Traud wrote: > Because of commit c2850bf (ASTERISK-26563, Gerrit-7673), I am not able > to compile Asterisk on the platform FreeBSD anymore. For example in > FreeBSD 11.1, the compiler clang fails because of freeswap = (totalswap > - usedswap). > > How does an external contributor like me report a regression in general: > A) do I re-triage the issue report and flag it as regression? Or > B) do I create a new report and link the causing issue? Or > C) in another way? > > What is considered a regression by the Asterisk team anyway: Is it a bug > recently introduced which is not in a release, yet? Generally yes, it's something that has been found in an rc or should block an upcoming rc. What exactly constitutes a regression is complicated though - in this case FreeBSD is not a platform that we really support. We accept contributions and changes which help to make Asterisk work there but we don't test on it and can end up accidentally breaking it. -- Joshua Colp Digium, Inc. | Senior Software Developer 445 Jan Davis Drive NW - Huntsville, AL 35806 - US Check us out at: www.digium.com & www.asterisk.org -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] PJSIP Subscription Handler
On Thu, Jan 4, 2018, at 3:56 AM, Simon Hohberg wrote: > Hi, > > I am trying to implement a PJSIP subscription handler for a custom event > where one endpoint sends a subscribe to another endpoint registered on > Asterisk. > I have the basic structure and can receive the subscription from one > endpoint in the "new_subscribe" and "subscription_established" callbacks > (ast_sip_notifier). > However, I don't see how I can create a new subscribe that is then send > out to the other endpoint. If you mean having Asterisk set up its own outgoing subscription and act on NOTIFY requests, there is currently no API or support for doing such a thing. It only supports receiving a subscribe and acting on it. -- Joshua Colp Digium, Inc. | Senior Software Developer 445 Jan Davis Drive NW - Huntsville, AL 35806 - US Check us out at: www.digium.com & www.asterisk.org -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] Problems with the ASTERISK-27206 patch.
On Wed, Jan 3, 2018, at 3:53 PM, Richard Mudgett wrote: > On Wed, Jan 3, 2018 at 5:08 AM, Joshua Colp <jc...@digium.com> wrote: > > > On Wed, Jan 3, 2018, at 12:03 AM, Richard Mudgett wrote: > > > On Tue, Jan 2, 2018 at 5:41 PM, Joshua Colp <jc...@digium.com> wrote: > > > > > > > On Tue, Jan 2, 2018, at 7:14 PM, Richard Mudgett wrote: > > > > > The patch for https://issues.asterisk.org/jira/browse/ASTERISK-27206 > > > > which > > > > > is committed in 7385d1e017e562afe64431606e857e704f86a16d causes a > > > > > configuration regression by requiring the endpoint and identifier > > method > > > > > to agree to match the endpoint. Doing so is redundant for methods > > that > > > > > explicitly specify which endpoints they match. The redundancy allows > > > > > configuration errors that cannot be caught when the configuration is > > > > > loaded. > > > > > > > > Can you clarify what the precise regression you are referring to is? > > Even > > > > after reading this email I'm still unclear. > > > > > > > > > > The regression is the new requirement for the endpoint identify_by option > > > to list ip in order for > > > the type=identify method to be accepted by the endpoint. This new > > > requirement is unnecessary > > > as the type=identify section must specify an endpoint name to know which > > > endpoint it recognizes. > > > > > > More specifically, the change to > > > res/res_pjsip_endpoint_identifier_ip.c:ip_identify() enforces this > > > new requirement. > > > > > > I should have used the term complexity instead of redundancy. > > > > > > The new requirement adds configuration complexity because the endpoint > > > identify_by option and > > > the type=identify method must agree to match the endpoint. The added > > > complexity doesn't add any > > > value, can needlessly break existing installations regardless of the note > > > in CHANGES saying it will, > > > makes match by ip configuration more error prone, and the error is not > > > recognizable on configuration > > > load. > > > > > > In addition, as I pointed out, I think the entire ASTERISK-27206 patch > > was > > > unnecessary. Before > > > the patch, setting the identify_by option to an empty string would > > disable > > > the username > > > identification method from matching the endpoint. > > > > I disagree that those are a regression. Those are certainly valid findings > > and comments, but I don't see a specific regression based on what you've > > said. If you are trying to state that the regression is "we now require ip > > to be listed in identify_by in order to match using the IP endpoint > > identifier" then that was the purpose of the patch itself and is not a > > regression. I also don't think that the option to set it to an empty string > > would have been user friendly, that's more of a side effect of how it was > > coded. Having a specific option for IP only based matching is explicit. > > > > I accept that defining the identify_by option to list the methods the > endpoint should be identified by is easy to document and conceptually > simple. To comply with that definition, for now, we can just add the "ip" > value, the "header" value, and any other widget name down the road as > needed. Later we need to re-implement it to support dynamically added > widget names. I do not accept the unnecessary requirement that the > type=identify method must be listed in the identify_by value when the user > must explicitly specify the endpoint name for the type=identify method to > even work. The "ip" value in identify_by should just be documentation in > this case. Adding a needless source of configuration error by requiring > the "ip" value to be listed does not help the user experience at all. That > requirement is the regression. Yes, I think having it be dynamic based on the registration of the endpoint identifier would be a nice thing to have long term. I continue to disagree that the requirement is a regression. It's a behavior change and generally the PJSIP configuration is driven around being explicit in things. > The ASTERISK-27206 reporter's problem was to somehow stop the username > identification method from recognizing the endpoint. Setting the > identify_by value to something that does not include "username" is all that > is necessary. Adding th
Re: [asterisk-dev] Problems with the ASTERISK-27206 patch.
On Wed, Jan 3, 2018, at 12:03 AM, Richard Mudgett wrote: > On Tue, Jan 2, 2018 at 5:41 PM, Joshua Colp <jc...@digium.com> wrote: > > > On Tue, Jan 2, 2018, at 7:14 PM, Richard Mudgett wrote: > > > The patch for https://issues.asterisk.org/jira/browse/ASTERISK-27206 > > which > > > is committed in 7385d1e017e562afe64431606e857e704f86a16d causes a > > > configuration regression by requiring the endpoint and identifier method > > > to agree to match the endpoint. Doing so is redundant for methods that > > > explicitly specify which endpoints they match. The redundancy allows > > > configuration errors that cannot be caught when the configuration is > > > loaded. > > > > Can you clarify what the precise regression you are referring to is? Even > > after reading this email I'm still unclear. > > > > The regression is the new requirement for the endpoint identify_by option > to list ip in order for > the type=identify method to be accepted by the endpoint. This new > requirement is unnecessary > as the type=identify section must specify an endpoint name to know which > endpoint it recognizes. > > More specifically, the change to > res/res_pjsip_endpoint_identifier_ip.c:ip_identify() enforces this > new requirement. > > I should have used the term complexity instead of redundancy. > > The new requirement adds configuration complexity because the endpoint > identify_by option and > the type=identify method must agree to match the endpoint. The added > complexity doesn't add any > value, can needlessly break existing installations regardless of the note > in CHANGES saying it will, > makes match by ip configuration more error prone, and the error is not > recognizable on configuration > load. > > In addition, as I pointed out, I think the entire ASTERISK-27206 patch was > unnecessary. Before > the patch, setting the identify_by option to an empty string would disable > the username > identification method from matching the endpoint. I disagree that those are a regression. Those are certainly valid findings and comments, but I don't see a specific regression based on what you've said. If you are trying to state that the regression is "we now require ip to be listed in identify_by in order to match using the IP endpoint identifier" then that was the purpose of the patch itself and is not a regression. I also don't think that the option to set it to an empty string would have been user friendly, that's more of a side effect of how it was coded. Having a specific option for IP only based matching is explicit. Having a non-explicit option like you mentioned previously for identify_by becomes a free for all on the other endpoint identifiers. If we encounter a scenario where two "other" endpoint identifiers could match but only want to match one then boom - we're back to the same scenario. You've just enforced that two endpoint identifiers that are configurable in some way can never match the same request even if for some reason they did if they fall under the "other" option. If the answer is "don't configure things them that way" then perhaps it isn't possible, we don't know. As well even with your "none" or "other" you'd still need to list it in the identify_by list, so I don't see how that's different than requiring "ip" to be there except being less specific. Approaching this from an end-user perspective who knows NOTHING of this stuff having "ip" in the identify_by also makes logical sense. It's explicit, you can understand what it means and you can understand what it does. The use of "other" is vague and requires more thought and investigation. The use of "none" is just downright confusing at first glance unless you dive deeper into things. > > > > > > > > > Relevant endpoint 101 configuration values: > > > > > > [global] > > > ; The order by which endpoint identifier methods are given priority. > > > ; The endpoint_identifier_order default is > > > ;endpoint_identifier_order=ip,username,anonymous > > > > > > [101] > > > type=endpoint > > > ; The identify_by default is > > > ;identify_by=username > > > > > > [identify_me] > > > type=identify > > > endpoint=101 > > > ; Match by some IP address > > > match=127.0.0.1/24 > > > > > > Before the patch, the 101 endpoint above would identify by either the > > > username endpoint identifier method or the > > > res_pjsip_endpoint_identifier_ip endpoint identifier method's > > > [identify_me] section. > > > > > > Af
Re: [asterisk-dev] Problems with the ASTERISK-27206 patch.
On Tue, Jan 2, 2018, at 7:14 PM, Richard Mudgett wrote: > The patch for https://issues.asterisk.org/jira/browse/ASTERISK-27206 which > is committed in 7385d1e017e562afe64431606e857e704f86a16d causes a > configuration regression by requiring the endpoint and identifier method > to agree to match the endpoint. Doing so is redundant for methods that > explicitly specify which endpoints they match. The redundancy allows > configuration errors that cannot be caught when the configuration is > loaded. Can you clarify what the precise regression you are referring to is? Even after reading this email I'm still unclear. > > Relevant endpoint 101 configuration values: > > [global] > ; The order by which endpoint identifier methods are given priority. > ; The endpoint_identifier_order default is > ;endpoint_identifier_order=ip,username,anonymous > > [101] > type=endpoint > ; The identify_by default is > ;identify_by=username > > [identify_me] > type=identify > endpoint=101 > ; Match by some IP address > match=127.0.0.1/24 > > Before the patch, the 101 endpoint above would identify by either the > username endpoint identifier method or the > res_pjsip_endpoint_identifier_ip endpoint identifier method's > [identify_me] section. > > After the patch, the 101 endpoint is still matched by either method. > However, the identify_by default had to change to "username,ip" and the > option meaning had to change slightly do it. I think this is wrong. If > you went to the trouble to create an [identify_me] section which must > explicitly specify the endpoint it matches then the endpoint should not > need to also specify in the identify_by value that it is identified by the > res_pjsip_endpoint_identifier_ip method. Doing so is redundant and will > cause unnecessary configuration errors. I think removing the redundant requirement is a nice improvement for the future, but that comes at a cost to do it in a way that is user friendly and automatic. > The goal of ASTERISK-27206 is to prevent the endpoint from being > identified by the username identification method so it could only be > identified by the res_pjsip_endpoint_identifier_ip method. The key > difference between the two methods is the username identification method > has no other configuration than the endpoint's identify_by value available > to specify to which endpoint the method applies. > > I think the previous and current identify_by documentation is a bit > misleading in any case. The identify_by option historically specified > which identification methods that have no other configuration requirements > can match the endpoint. i.e., The username and auth_username > identification methods. To satisfy ASTERISK-27206, what is needed for the > identify_by option is a value to prevent methods that have no other > configuration requirements from matching the endpoint. The identify_by option was originally an option which listed the endpoint identifiers that an endpoint could be identified by. That was its original goal. It later evolved slightly with the addition of auth_username to also influence how. The addition of "ip" goes back to its original goal. Over all the option has muddied meaning. I disagree that whether an endpoint identifier is configurable or not has a bearing on its naming or meaning in identify_by. The configuration may imply that it should only be matched using that identifier, but that is not currently something that is done and is of a greater scope. I think having a global identify_by option which could actually mean multiple endpoint identifiers by itself is also confusing and hard to define the behavior of. Really what this just illustrates is that the option itself has evolved and hasn't been clearly defined with a strict purpose. I don't think now is the right time to solve that particular problem. If there is a defined use case which is currently broken by the change though, that is something we need to fix. -- Joshua Colp Digium, Inc. | Senior Software Developer 445 Jan Davis Drive NW - Huntsville, AL 35806 - US Check us out at: www.digium.com & www.asterisk.org -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] Can someone please review something
On Mon, Nov 27, 2017, at 08:55 AM, Nir Simionovich wrote: > @corey, > > I've been looking into res_sorcery_astdb, but I think I'm missing > something in here. > If I would create a a redis backend for sorcery, the functionality is > fairly limited in the scope > of Redis usage. Mainly due to the fact that sorcery is meant as a CRUD > interface. > > Have I got it correct? It ultimately depends on the use case and what exactly is trying to be achieved. As with any general interface (like sorcery) the result is that you are somewhat limited to what the interface provides, but the benefit being it can be used by anything that uses the interface. Is it worth it? Could be as Corey mentioned. If your goal, however, is to provide all the knobs and possibilities that redis can do - then it obviously wouldn't be a good fit. -- Joshua Colp Digium, Inc. | Senior Software Developer 445 Jan Davis Drive NW - Huntsville, AL 35806 - US Check us out at: www.digium.com & www.asterisk.org -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] Processing .conf files
On Sun, Nov 19, 2017, at 01:18 PM, Nir Simionovich wrote: > Hi All, > > Ok, this email may be totally pointless to some, but I'm having some > conceptual difficulties with the methodology of processing .conf files. > > Allow me to explain my current issues in ramping up on this one. As > part > of the > beanstalk work I've done, I would like to create either an app_beanstalk > or > func_beanstalk or to be better, a res_beanstalk. > > In my mind, I see a configuration file works something like the > following: > > ; > ; Beanstalk job queue resourcing application > ; > > [general] > ttr = 60; an integer number of seconds to allow a worker to > run > a job > delay = 0 ; an integer number of seconds to wait before marking > a > job as ready. > ; A job will be set as "delayed" in this period of > time > > > [tube1] > enabled = no > ;host = 127.0.0.1; Specify the remote IP address of the Beanstalkd > server > ;port = 11300; Specify the remote PORT of the the Beanstalkd > server > ;tube = asterisk-cdr ; Specify the default job queue to use > ;priority = 99 ; Specify the default job priority for the queue. > The > lower the number, > ; the higher the priority. > > > [tube2] > enabled = no > ;host = 127.0.0.1; Specify the remote IP address of the Beanstalkd > server > ;port = 11300; Specify the remote PORT of the the Beanstalkd > server > ;tube = asterisk-cdr ; Specify the default job queue to > ;priority = 99 ; Specify the default job priority for the queue. > The > lower the number, > ; the higher the priority. > > Now, I've trying to figure out how the configuration parser works with > "free form" data. I've tried looking > into app_voicemail.c, as that uses a fairly similar concept, however, > that > didn't provide much help. > > From what I gathered, there are two main functions that I need to > understand how they work: > ast_category_browse and ast_variable_browse. Now, the basic methodology > of > the various Asterisk > config files is fairly static, namely, a configuration for a singular > function - very much like cdr_beanstalkd.conf. > However, for my new tool to work, I need to be able to create dynamically > allocated "tube contexts". I couldn't find > any specific sample that would describe this kind of methodology of > operation in a coherent manner. You need to use the ast_category_browse function you've mentioned to iterate the parsed categories of the .conf file - these being the general, tube1, tube2, etc. What happens with those categories and what meaning they have is up to you. The ast_variable_browse function can then be used to iterate the set options inside of the category, or you can directly get values for things. The core config parser just presents the data in categories/variables, nothing more. New code though should use either ACO (Asterisk config options) or Sorcery (ACO + Sorcery + other features). Which one should be used really depends on the use case. These sit on top of the config parser and map things into C structures automatically and atomically. You define how a category maps to a C structure (for example requires a type=tube option being set), and then each option can be mapped to a field in the C structure or can execute arbitrary code. -- Joshua Colp Digium, Inc. | Senior Software Developer 445 Jan Davis Drive NW - Huntsville, AL 35806 - US Check us out at: www.digium.com & www.asterisk.org -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] Adding a call preemption feature
On Wed, Nov 15, 2017, at 05:45 PM, Jean Aunis wrote: > Le 13/11/2017 à 23:17, Phil Mickelson a écrit : > > Jean, > > > > You should know that I wrote something very similar to what you are > > asking for. Slightly different reasons and I use ARI which makes it > > very easy. However, the result is the same. The inbound call gets > > terminated. > > > I also considered the ARI option, but it does not fit my needs because > channels go through several ARI applications, and may eventually go back > to the dialplan, so it will not be possible to shut them down with ARI. The DELETE operation in ARI on a channel works on any channel, including those not in ARI. -- Joshua Colp Digium, Inc. | Senior Software Developer 445 Jan Davis Drive NW - Huntsville, AL 35806 - US Check us out at: www.digium.com & www.asterisk.org -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] PJSIP endpoints created via ARI do not transfer some values into Realtime Database
On Thu, Nov 9, 2017, at 10:53 AM, Floimair Florian wrote: > Joshua, > > I'm pretty sure I have found the problem, and actually I'm not the first > to encounter it. > The solution is to use OPT_YESNO_T in pjsip_configuration.c instead of > OPT_BOOL_T for the respective values. > I had a look in commit b6bd97eea2d which introduced the OPT_YESNO_T type > and the commit description clearly resembles what I have encountered. > However changing only the values that I have encountered seems a bit > short-sighted. > Therefore I want to clarify beforehand: > > 1.) Shouldn't all configuration values that map to a YESNO-Enum type in > the database be of the type OPT_YESNO_T in pjsip_configuration.c? Seems like it, yes. > 2.) The commit introducing OPT_YESNO_T is included in 14, 15 and master > but not in 13. Should it be backported? 13 does not have push so I don't think it would really have an impact there or need to be backported. -- Joshua Colp Digium, Inc. | Senior Software Developer 445 Jan Davis Drive NW - Huntsville, AL 35806 - US Check us out at: www.digium.com & www.asterisk.org -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] Regression: iax2-problems since 13.18.0 - frequently unreachable
On Wed, Nov 8, 2017, at 02:43 PM, Michael Maier wrote: > On 11/08/2017 at 06:14 PM Joshua Colp wrote: > > On Wed, Nov 8, 2017, at 12:57 PM, Michael Maier wrote: > >> Hello, > >> > >> since asterisk 13.18.0, I'm facing frequent disconnects like these each > >> day: > > > > What version previously worked? > > It was 13.17.2 The chan_iax2 module is identical between 13.17.2 and 13.18.0, there's no code changes between 'em. -- Joshua Colp Digium, Inc. | Senior Software Developer 445 Jan Davis Drive NW - Huntsville, AL 35806 - US Check us out at: www.digium.com & www.asterisk.org -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] Regression: iax2-problems since 13.18.0 - frequently unreachable
On Wed, Nov 8, 2017, at 12:57 PM, Michael Maier wrote: > Hello, > > since asterisk 13.18.0, I'm facing frequent disconnects like these each > day: What version previously worked? The chan_iax2 module is not something that is commonly touched these days. The last remotely substantial change was in July and before that November 24, 2015. -- Joshua Colp Digium, Inc. | Senior Software Developer 445 Jan Davis Drive NW - Huntsville, AL 35806 - US Check us out at: www.digium.com & www.asterisk.org -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] PJSIP endpoints created via ARI do not transfer some values into Realtime Database
On Wed, Nov 8, 2017, at 08:13 AM, Floimair Florian wrote:
> Hi guys!
>
> In my lab environment I ran into an issue with PJSIP endpoints created
> via ARI with a realtime database as backend.
> I'm using a MySQL database in my lab setup.
> I noticed that some of the values of the endpoint object do not find
> their way into the database.
>
> When creating the endpoint (and auth and aor before that) using cURL I
> get the following JSON reply indicating that the attributes I set in the
> request are successfully accepted by Asterisk:
>
> curl -X PUT -H "Content-Type: application/json" -u asterisk:asterisk -d
> '{"fields": [{"attribute": "send_pai", "value": "yes"}, {"attribute":
> "send_rpid", "value": "yes"}, { "attribute": "allow", "value":
> "!all,g722,ulaw,alaw,h264"}, {"attribute": "ice_support", "value":
> "yes"}, {"attribute": "force_rport", "value": "yes"}, {"attribute":
> "rewrite_contact", "value": "yes"}, {"attribute": "rtp_symmetric",
> "value": "yes"}, {"attribute": "context", "value": "default" },
> {"attribute": "auth", "value": "snom820" }, {"attribute": "aors",
> "value": "snom820"} ] }'
> http://localhost:8088/ari/asterisk/config/dynamic/res_pjsip/endpoint/snom820
>
> I get the following JSON response (shortened to just show the attributes
> set in the request):
>
> [...,
> {"attribute":"send_rpid","value":"true"},
> {"attribute":"aors","value":"snom820"},
> {"attribute":"context","value":"default"},
> {"attribute":"rtp_symmetric","value":"true"},
> {"attribute":"force_rport","value":"true"},
> {"attribute":"ice_support","value":"true,
> {"attribute":"allow","value":"(g722|ulaw|alaw|h264)"},
> {"attribute":"rewrite_contact","value":"true"},
> {"attribute":"auth","value":"snom820,
> {"attribute":"send_pai","value":"true"},...]
>
> So at first glance everything seems to be OK.
> However when looking at the database everything that is not a string
> (namely all yes/no ENUMs) comes up empty, which in turn causes Asterisk
> to use the default values for these settings.
>
> So the only rows correctly set in the dabase in case of the above values
> are aors ,context, auth & allow. All the other rows come up empty.
>
> Verifying in the Asterisk CLI shows these values (again shortened):
>
> asterisk*CLI> pjsip show endpoint snom820
>
> Endpoint:
>
> I/OAuth:
>
>
> Aor:
>
> Contact:
><RTT(ms)..>
> Transport:
>
>Identify:
>
>
> Match:
> Channel:
>
> Exten: CLCID:
> ==
>
> Endpoint: snom820/unknown
> Unavailable 0 of inf
> InAuth: snom820/snom820
> Aor: snom820 10
>
>
> ParameterName : ParameterValue
> ==
> allow : (g722|ulaw|alaw|h264)
> aors : snom820
> auth : snom820
> context: default
> force_rport: true
> ice_support: false
> rewrite_contact: false
> rtp_symmetric : false
> send_pai : false
> send_rpid : false
>
> After correlating these empty values in the database with their default
> setting in the Asterisk code, I saw that only force_rport defaults to
> true.
> This leads me to believe that Asterisk at runtime takes the default
> values for empty rows in the database as they do not reflect the values
> that were in the JSON response.
>
> Finally, this leads me to my question:
>
> Is this a bug, or is there something wrong in my method of creating these
> endpoints and the assumption that they should be properly transferred to
> the database?
>
> If it is a bug I will file an issue, If it is not can someone please
> point out what is wrong here.
I don't think anyone has used this with a realtime database like that. I
only know of people using astdb itself. I'd consider it a bug though,
probably in the realtime interaction.
--
Joshua Colp
Digium, Inc. | Senior Software Developer
445 Jan Davis Drive NW - Huntsville, AL 35806 - US
Check us out at: www.digium.com & www.asterisk.org
--
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] Adding a new module to Asterisk
On Mon, Oct 16, 2017, at 10:03 AM, Nir Simionovich wrote: > ok, managed to pass that hurdle - I'm basically using a fairly old piece > of > code to base my module on - namely, cdr_manager.c, > so the configuration parser in there is slightly different. > > Minor question, is there a "safe" asterisk method of doing a "sprintf"? There is no Asterisk wrapper for it, but snprintf should be used instead generally. -- Joshua Colp Digium, Inc. | Senior Software Developer 445 Jan Davis Drive NW - Huntsville, AL 35806 - US Check us out at: www.digium.com & www.asterisk.org -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] Gerrit: Draft » Cherry-Pick » Publish = no check
On Mon, Oct 16, 2017, at 07:22 AM, Alexander Traud wrote: > Issue 1: > When I > 1) git review --draft ... on the command line of my computer, > 2) cherry pick that change to other branches via the Web interface, and > 3) publish those changes via the Web interface, > I have to reply with "recheck" on the initial review, the one I submitted > as draft via the command line, always. Could somebody look into that, so > the check is done automatically when a review is published = leaves the > draft mode? Or is there any other trick? The configuration for this is actually itself kept in Gerrit[1] so anyone can look and make changes. George would probably be the one who could most quickly do such a thing. > Issue 2: > When I cherry pick a draft via the Web interface, it is public visible > (published) right away. I would have expected the cherry pick to stay a > draft. Is that a configuration thing in Gerrit or an issue of the Web > interface of Gerrit? It's the web interface of Gerrit. I haven't found an option to make the draft status preserved. > Issue 3: > When I cherry pick via the Web interface, the branch is appended to the > topic automatically, for example ASTERISK-x gets ASTERISK-x-13. I > have to edit that manually. Is there any other trick instead of cherry > picking via the command line? It's Gerrit doing it, and there's no option I've found to change it. Manually doing it is the only way to ensure it doesn't get appended. > Issue 4: > When an identical change is cherry picked to several branches, reviewers > comment sometimes in branch 13 and sometimes in the branch master. Is it > possible to streamline this, and always use one specific branch for > example the oldest LTS or the master branch? We could certainly ask people to do this but there's no enforcement possible of it. > Issue 5: > When I edit a commit message via the Web interface, there is a (red) hair > line after 72 columns. However according to > <http://wiki.asterisk.org/wiki/display/AST/Commit+Messages>, wrapping > should happen after 80 columns. This is confusing. Could somebody > configure this in Gerrit? Or is this a static value which is not > changeable? Gerrit is already set to 80 for both the subject length and max line length of the commit message itself. The web editor is fairly new, so it may have some sort of fixed size in it for warning. > Issue 6: > As with the previous Reviewboard software, I see many changes submitted > to Gerrit without any issue in Jira. That is allowed, I know. However, > Jira allows me to link issues. This linking helps the original author to > be aware of missed corner cases or defects of his change. Because some > changes go through without any issue report, I do not know how to link > those in Jira so their authors learn. Is there any trick, I am missing? Not really. Everything gets linked based on the topic of the change matching a JIRA issue number. Without that there's no link. > Issue 7: > The guidelines for commit messages state: "end the first sentence (and > any subsequent sentences) with punctuation." Even Digium employees do not > do that. That guideline is still in effect, isn't it? Technically yes but it's a comparatively small thing in the grand scheme of things so it doesn't see much enforcement. [1] https://gerrit.asterisk.org/#/admin/projects/infrastructure -- Joshua Colp Digium, Inc. | Senior Software Developer 445 Jan Davis Drive NW - Huntsville, AL 35806 - US Check us out at: www.digium.com & www.asterisk.org -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] Adding a new module to Asterisk
On Mon, Oct 16, 2017, at 06:45 AM, Nir Simionovich wrote: > Ok, that helped - looks like I'm linking correctly now. > > Different question, I remember their used to be a "safe string copy" > function that I'm supposed to use, > instead of using strcpy. Mainly, I want to parse my configuration file > correctly, but I can't find any > specific methodology for doing this in a uniform asteriskish manner. >From a configuration perspective there's two APIs: If only .conf files are needed then there is the Asterisk Config Options API, include/asterisk/config_options.h, which is used by the skeleton application apps/app_skel.c for configuration parsing, storing, and usage. If realtime is needed then there is the Asterisk Sorcery API, include/asterisk/sorcery.h, which is used by PJSIP and other things - with the simplest being res/res_mwi_external.c It's highly recommended to use one of them instead of rolling your own configuration parsing. They take care of things (such as safe atomic reloads). The "safe string copy" you are thinking of is probably ast_copy_string. -- Joshua Colp Digium, Inc. | Senior Software Developer 445 Jan Davis Drive NW - Huntsville, AL 35806 - US Check us out at: www.digium.com & www.asterisk.org -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] Asterisk 14 Security Fix Only Mode
On Tue, Oct 10, 2017, at 02:01 PM, Matt Fredrickson wrote: > Hey all, > > For those who may not be aware Asterisk 14 transitioned from bug fix mode > to security-fix-only mode a few weeks ago (Sept 26th). For those of you > that are still on this release, it's a good time to consider building an > upgrade plan for moving to 15.x.x. I sincerely apologize for the late > notification. Somehow, this was overlooked in the push to get 15.0.0 > released. > > You can read more about this process and the relevant dates on the wiki > at > https://wiki.asterisk.org/wiki/display/AST/Asterisk+Versions > > Best wishes, and sorry again about the confusion on this. Kia ora all, This is just a reminder that changes should no longer be cherry picked into the 14 branch. Right now the supported branches are 13, 15, and master. Cheers, -- Joshua Colp Digium, Inc. | Senior Software Developer 445 Jan Davis Drive NW - Huntsville, AL 35806 - US Check us out at: www.digium.com & www.asterisk.org -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
[asterisk-dev] AstriDevCon 2017
Greetings all, For those who are physically attending AstriDevCon the room has been changed to Colonial A & B. If you would like to participate remotely we will be in the #astridevcon IRC channel on Freenode and there are audio conference and streaming details on the wiki[1]. Cheers, [1] https://wiki.asterisk.org/wiki/display/AST/AstriDevCon -- Joshua Colp Digium, Inc. | Senior Software Developer 445 Jan Davis Drive NW - Huntsville, AL 35806 - US Check us out at: www.digium.com & www.asterisk.org -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] Asterisk 15 RC1 and RTP/RTCP leak ?
On Tue, Sep 26, 2017, at 06:19 PM, sean darcy wrote: > On 09/26/2017 03:04 PM, Sean Bright wrote: > > On 9/26/2017 12:37 PM, sean darcy wrote: > >> Are there any RTP/RTCP leak issues with 15 RC1 ? > > > > What kind of leak? Memory leak? > > > Should have been more precise: > > Asterisk Project Security Advisory - AST-2017-008 RC1 does not include the fixes, as RC1 was released before the security advisory. The change itself, though, has been put into the 15.0 branch and will go into the release. -- Joshua Colp Digium, Inc. | Senior Software Developer 445 Jan Davis Drive NW - Huntsville, AL 35806 - US Check us out at: www.digium.com & www.asterisk.org -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] AstDB mySQL implementation
On Fri, Sep 22, 2017, at 02:12 PM, Ryan Wagoner wrote: > I've been scaling out FreePBX horizontally with Kamailio and custom > FreePBX > modules mainly to handle call center outbound dialing (around 20k calls > per > day). One of the issues I ran into was FreePBX uses the AstDB extensively > and will write changes to it from the dialplan or the FreePBX user > control > panel. > > To overcome this I either needed to scrap FreePBX and build a new GUI > using > Asterisk realtime, heavily modify FreePBX (not an option), or rewrite > AstDB > to use a database like mySQL. I choose the last option and have had the > code in production for just over a month. I'm backing it with a two node > MariaDB Galera cluster with HAProxy providing failover for the client DB > connections. > > I realize that SQLite was chosen for AstDB for performance reasons. > However > mySQL seems to perform just fine in the above scenario. Right now I have > a > db.c file that just has the mySQL code. Does anybody else have any > interest > in using mySQL for the AstDB backend? I'm debating if it would make sense > to have the option to select your AstDB backend. It was chosen not just because of that but also because to a user there's nothing they need to do to set it up or have it work - you just run Asterisk and off it goes. I'm more curious over why they didn't use func_odbc instead but chose to use AstDB. Perhaps for similar reasons. -- Joshua Colp Digium, Inc. | Senior Software Developer 445 Jan Davis Drive NW - Huntsville, AL 35806 - US Check us out at: www.digium.com & www.asterisk.org -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
[asterisk-dev] Stream Support In Asterisk
Kia Ora, For those who are unaware stream support now exists within the Asterisk core. This includes a representation of streams on a channel as well as the ability to to request changes (such as adding another stream). PJSIP is currently the only channel driver that supports multiple streams, with bridging being the main API that has been updated to also take advantage of it. This means that there is a lot of Asterisk that can be updated to take advantage of things and better improve the experience. To that end I've created a wiki page[1] which describes what can be done and in some cases how it needs to behave. This page is ordered from easiest to most difficult. If anyone is interested in getting their feet wet in the world of multiple streams this would be a great place to start. If you decide to venture in and have any questions don't hesitate to post on the mailing list and start a discussion. Cheers, [1] https://wiki.asterisk.org/wiki/display/AST/Stream+Support+Across+Asterisk -- Joshua Colp Digium, Inc. | Senior Software Developer 445 Jan Davis Drive NW - Huntsville, AL 35806 - US Check us out at: www.digium.com & www.asterisk.org -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] LI handling in asterisk
On Fri, Aug 4, 2017, at 02:00 AM, Holger Freyther wrote:
>
> What is done by the customer right now:
>
> There is an AMI command to register interest in a SIP Call-Id (the mime
> header value). If there is an active call with this id LI will be
> activated and if a call is incoming the id will be checked against
> pending requests.
>
> For the actual LI part the RTP is wrapped in a small header including a
> sessionId (registered by the command), the direction (e.g. in, out, end,
> start), the peer ip and port followed by the rtp packet.
>
> The actual leak implementation is done by modifying the rtp_engine
> interface like...
>
> struct ast_rtp_engine {
> ...
> int (*leak_rtp)(int fd, const struct ast_sockaddr *sa);
>
> and then modifying the asterisk rtp_engine to duplicate the payload
> before it is sent out and after it was received from a socket. It is
> triggered from within chan_sip/pjsip (but that would have to move
> somewhere else)
>
>
>
> Hpw to move forward here? Could the framehooks be extended to include the
> on-wire received/sent messages as well? Could the ast_frame be extended
> to hold more information? Is the modification of the rtp_engine a first
> step (as this would allow to build a module like app_chanspy).
There's nothing really built in to do such a thing, and modifying the
RTP engine would be the easiest like you've mentioned above. Frames
passing through the core were never designed or written to include
protocol specific information like the RTP header itself, extending
frames to include this could be difficult - specifically ensuring
everything can handle it (or that it's done in such a way that it's
hidden). They'd also increase the size of frames, which is something
else to consider.
I've heard other people doing this outside of Asterisk instead, to avoid
having to do any modifications.
--
Joshua Colp
Digium, Inc. | Senior Software Developer
445 Jan Davis Drive NW - Huntsville, AL 35806 - US
Check us out at: www.digium.com & www.asterisk.org
--
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] Building Asterisk 14.6.0 fails with pjproject 2.6
On Thu, Jul 20, 2017, at 04:41 PM, Brian Capouch wrote: > Asterisk requires pjsip_tsx_layer_find_tsx2 and fails to find it in > the latest release of pjproject, 2.6. > > So I tried to build pjproject from SVN trunk, but it appears to have > problems with its use of uuid. > > Machine is a Digital Ocean droplet running CentOS 7.1. The bundled version of PJSIP with 14.6.0 is 2.6, so it does build. Did you manually update your own install? If so did you configure it the same as the previous install? If not then you may have two installs of PJSIP on the system of differing versions. This can cause problems where the configure script detects one version, but the paths of the system result in the other version being used causing it to improperly use things. If you look on the system for "libpjsip.so" and it exists in multiple places, then that's likely the case. -- Joshua Colp Digium, Inc. | Senior Software Developer 445 Jan Davis Drive NW - Huntsville, AL 35806 - US Check us out at: www.digium.com & www.asterisk.org -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] Pjsip segfault
On Fri, Jun 16, 2017, at 11:37 AM, Tomec Martin wrote: > On Fri, Jun 16, 2017, at 11:10 AM, Tomec Martin wrote: > > Hi, > > I am looking at issue > > https://issues.asterisk.org/jira/browse/ASTERISK-27037 and so far I have > > found that: > > In asterisk function ast_sip_send_stateful_response, we receive message > > via pjsip_tsx_recv_msg then prepare answer and send answer via > > pjsip_tsx_send_msg. > > Before we send the answer, the pjsip_transaction structure can be deleted > > by some pjsip callbacks. So the pjsip_tsx_send_msg is called with invalid > > pjsip_transaction. > > > > Is anybody aware of correct way how to prevent pjsip_transaction from > > being deleted? Or is there a way to determine that transaction was > > deleted (by some callback)? > > Have you determined what callbacks will occur that can cause it to > happen? Are you referring to timer entries for example? > > I can't tell exactly. We suspect that it could be caused by some bad > implemented webrtc client. > From the log it seems to some "transport error" while receiving message. > And the terminated transaction is then destroyed by timer: > [Jun 13 12:45:18] DEBUG[8093] pjproject: tsx0x7fe4bc0631a8 > ..Transaction created for Request msg REGISTER/cseq=2 > (rdata0x7fe494118e18) > [Jun 13 12:45:18] DEBUG[8093] pjproject: tsx0x7fe4bc0631a8 > .Incoming Request msg REGISTER/cseq=2 (rdata0x7fe494118e18) in state Null > [Jun 13 12:45:18] DEBUG[8093] pjproject: tsx0x7fe4bc0631a8 > ..State changed from Null to Trying, event=RX_MSG > [Jun 13 12:45:18] DEBUG[8092] pjproject: tsx0x7fe4bc0631a8 > State changed from Trying to Terminated, event=TRANSPORT_ERROR > [Jun 13 12:45:18] DEBUG[8092] pjproject: tsx0x7fe4bc0631a8 > Timeout timer event > [Jun 13 12:45:18] DEBUG[8092] pjproject: tsx0x7fe4bc0631a8 > .State changed from Terminated to Destroyed, event=TIMER > [Jun 13 12:45:18] DEBUG[8092] pjproject: tsx0x7fe4bc0631a8 > Transaction destroyed! > [Jun 13 12:45:19] DEBUG[8093] pjproject: tsx0x7fe4bc0631a8 > .Sending Response msg 200/REGISTER/cseq=2 (tdta0x7fe4bc1e5aa8) in state > Destroyed > We can replicate this only in production environment, but it is possible > to add some logging if needed... I think in order to determine the proper path forward we need to understand the specific scenario, the threads involved, and the specific interaction that caused it to happen. For example I wouldn't expect the above to happen, that is I don't know what would cause it to transition to a TRANSPORT_ERROR in that case if a message hasn't been sent yet (and it doesn't look one has yet). -- Joshua Colp Digium, Inc. | Senior Software Developer 445 Jan Davis Drive NW - Huntsville, AL 35806 - US Check us out at: www.digium.com & www.asterisk.org -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] Pjsip segfault
On Fri, Jun 16, 2017, at 11:10 AM, Tomec Martin wrote: > Hi, > I am looking at issue > https://issues.asterisk.org/jira/browse/ASTERISK-27037 and so far I have > found that: > In asterisk function ast_sip_send_stateful_response, we receive message > via pjsip_tsx_recv_msg then prepare answer and send answer via > pjsip_tsx_send_msg. > Before we send the answer, the pjsip_transaction structure can be deleted > by some pjsip callbacks. So the pjsip_tsx_send_msg is called with invalid > pjsip_transaction. > > Is anybody aware of correct way how to prevent pjsip_transaction from > being deleted? Or is there a way to determine that transaction was > deleted (by some callback)? Have you determined what callbacks will occur that can cause it to happen? Are you referring to timer entries for example? -- Joshua Colp Digium, Inc. | Senior Software Developer 445 Jan Davis Drive NW - Huntsville, AL 35806 - US Check us out at: www.digium.com & www.asterisk.org -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] Opus documentation
On Fri, Jun 9, 2017, at 07:36 AM, Sylvain Boily wrote: > Hello, > > It missed in this documentation[1] the entry: > > max_bandwidth with possible values narrow, medium, wide, super_wide, > full (default full) > > * [1] https://wiki.asterisk.org/wiki/display/AST/Codec+Opus I've updated the wiki page with this. > > And there is a typo in the asterisk code source samples. > configs/samples/codecs.conf.sample (max_bandwitdth to max_bandwidth) Can you create an issue[1] for this? [1] https://issues.asterisk.org/jira -- Joshua Colp Digium, Inc. | Senior Software Developer 445 Jan Davis Drive NW - Huntsville, AL 35806 - US Check us out at: www.digium.com & www.asterisk.org -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] "telephone-event" at rates other than 8000?
On Thu, Jun 8, 2017, at 11:35 AM, Stephen Davies wrote: > Hi, > > Reviewing rtp_engine.c it appears that we only support telephone-event > rtp > with a sample rate of 8000? > > JSSIP using Opus offers Opus as "opus/48000/2" and then (by necessity, I > think), telephone-event/48000. > > > In rtp_engine.c there is only: > > set_next_mime_type(NULL, AST_RTP_DTMF, "audio", "telephone-event", 8000); > > Has this come up before? Not that I can remember. > Can any other developer point me as to where I'd need to look to try to > add > 48000 too? Things really aren't written at all to handle this case. You'd like need to change code in rtp_engine.c to add it as 48000, and then also in the channel driver (or res_pjsip_sdp_rtp in the case of PJSIP) to handle it. You'd also need to add logic to determine when exactly to use it. It's uncharted territory for the DTMF support in RTP in Asterisk. -- Joshua Colp Digium, Inc. | Senior Software Developer 445 Jan Davis Drive NW - Huntsville, AL 35806 - US Check us out at: www.digium.com & www.asterisk.org -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] Configuring multistream in chan_pjsip
On Mon, Jun 5, 2017, at 04:21 PM, Mark Michelson wrote: > Hi folks, > > For those of you following along at home, I recently published review > https://gerrit.asterisk.org/#/c/5760/ , which is step one towards making > chan_pjsip multistream, i.e. supporting more than one stream of a given > media type. This initial review does not actually introduce multistream > support so much as it just makes use of multistream structures under the > hood to ease the transition. > > Continuing on, one of the next steps we need to determine is how a user > of chan_pjsip should configure a channel that supports multiple streams > of a particular type. > > To refresh everyone on how things currently work in pjsip.conf, you set > an "allow" option in order to determine what codecs a particular > endpoint supports. > > [Alice] > type = endpoint > allow = ulaw,opus,h264 > > > I propose the following configuration options to move forward. > > offered_audio_streams = 1 > offered_video_streams = 2 My only question is why, in a scenario where we don't have a hint, would we want to make the number of offered streams configurable by the user? Ultimately it's up to the application that is handling the channel to decide what it wants and that is decided in the moment, not ahead of time based on configuration. I think maximum and minimum are useful for enforcing some constraints though. -- Joshua Colp Digium, Inc. | Senior Software Developer 445 Jan Davis Drive NW - Huntsville, AL 35806 - US Check us out at: www.digium.com & www.asterisk.org -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] hangup handlers & unwanted cdr
On Fri, Jun 2, 2017, at 11:15 AM, marek cervenka wrote: > hi, > > i'm using hangup handlers on Asterisk13 > > with standard answered calls i have 1 CDR per call > > with scenario call from voip->mobile, call rejected on mobile i have 2 > CDRs > > > i dont want the second CDR > > without hangup handlers i have 1 CDR > > > do you think its bug or its feature of hangup handlers? CDRs in Asterisk 12 and above were changed such that information isn't lost. This can result in multiple CDR records for each path of communication. In this case what have you set for "endbeforehexten" in the cdr.conf file? -- Joshua Colp Digium, Inc. | Senior Software Developer 445 Jan Davis Drive NW - Huntsville, AL 35806 - US Check us out at: www.digium.com & www.asterisk.org -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] ASTERISK-26978 - rtp: Crash in ast_rtp_codecs_payload_code()
On Wed, May 24, 2017, at 12:12 PM, Ross Beer wrote:
> >>
>
> >> Therefore I have added the following code to check for this:
> >>
> >>
> >> if (format1->codec == NULL || format2->codec == NULL) {
> >> return AST_FORMAT_CMP_NOT_EQUAL;
> >> }
> >>
> >> The question is, should 'codec' be NULL if 'format1' and 'format2' are
> .> not NULL? Is adding the above check, the correct fix?
>
> >A format can't be created and remain valid without a codec being present
> >on it. A format itself is a codec + extra data about it. Identifying how
> >it became NULL and why the format is no longer valid would uncover the
> >real fix.
>
> Does the format object need locking so that anything acting on it doesn't
> have the object pulled from under it?
>
> My theory is that a channel is attempting to unallocated the 'format'
> object while it is trying to be compared. It, therefore, makes it through
> the NULL checks on 'format1' and 'format2' but is in the process of being
> freed.
Once created a format is considered immutable - it can't be changed.
Only a new one based on it can be created. The only reason it would be
destroyed is if the reference count is not correct. Anything having a
pointer to it should hold a reference.
>
> There are quite a few backtraces on this and the linked issue. Would
> anyone be willing to take a look, my C skills are not that good?
The issue is in queue to be looked at by us (Digium). I have no
timeframe on that. Perhaps someone else in the community will take a
look.
--
Joshua Colp
Digium, Inc. | Senior Software Developer
445 Jan Davis Drive NW - Huntsville, AL 35806 - US
Check us out at: www.digium.com & www.asterisk.org
--
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] ASTERISK-26978 - rtp: Crash in ast_rtp_codecs_payload_code()
On Wed, May 24, 2017, at 11:13 AM, Ross Beer wrote:
>
> Therefore I have added the following code to check for this:
>
>
> if (format1->codec == NULL || format2->codec == NULL) {
> return AST_FORMAT_CMP_NOT_EQUAL;
> }
>
> The question is, should 'codec' be NULL if 'format1' and 'format2' are
> not NULL? Is adding the above check, the correct fix?
A format can't be created and remain valid without a codec being present
on it. A format itself is a codec + extra data about it. Identifying how
it became NULL and why the format is no longer valid would uncover the
real fix.
--
Joshua Colp
Digium, Inc. | Senior Software Developer
445 Jan Davis Drive NW - Huntsville, AL 35806 - US
Check us out at: www.digium.com & www.asterisk.org
--
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] Doxygen docs update ?
On Wed, May 10, 2017, at 10:14 AM, Ludovic Gasc wrote: > Hi, > > The Doxygen documentation: http://doxygen.asterisk.org/ seems not updated > since a long time. > Is it in your plans to re-enable the Doxygen automatic upgrade, based on > Git commits ? > > Thanks for your answer. I've created an issue[1] to track this but I do not know when it will get worked. [1] https://issues.asterisk.org/jira/browse/ASTERISK-26991 -- Joshua Colp Digium, Inc. | Senior Software Developer 445 Jan Davis Drive NW - Huntsville, AL 35806 - US Check us out at: www.digium.com & www.asterisk.org -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] Timers in pjsip
On Tue, May 2, 2017, at 07:07 PM, Steve Murphy wrote: > > I notice that pjsip in asterisk seems to follow the same pattern of > retries: > first, a half-second wait, then a retry, then a full second wait, then > a retry, then a 2 second wait, and several 4-second waits until half a > minute or so, > and after 60 seconds, (61 seconds?) the cycle starts over. > > I have spent hours looking for this algorithm first in the asterisk code, > then in pjproject. > The docs for pjproject say: > > (section 8.1.2: Timers and Retransmissions) > > "Application can change the interval value of timers only on a > global > basis > (perhaps even only during compilation)." > > Any hints as to where this code is located? The code itself is in the transaction layer of PJSIP at pjsip/src/pjsip/sip_transaction.c - specifically the tsx_resched_retransmission function. -- Joshua Colp Digium, Inc. | Senior Software Developer 445 Jan Davis Drive NW - Huntsville, AL 35806 - US Check us out at: www.digium.com & www.asterisk.org -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] chan_sip and early media
On Tue, May 2, 2017, at 06:47 PM, Valter Nogueira wrote:
> I am originating call using early media option.
>
> Whe I issue a hangup (like in hangup request sip/...) before the b-leg
> answer, it don't send a SIP CANCEL and the call keeps going on.
>
> I figured out that it is happening due to sip_hangup() checks:
>
> * if (p->invitestate < INV_COMPLETED && ast_channel_state(p->owner) !=
> AST_STATE_UP) {*
>
> * needcancel = TRUE;*
> * ast_debug(4, "Hanging up channel in state %s (not UP)\n",
> ast_state2str(ast_channel_state(ast)));*
> * }*
>
> And *ast_channel_state(p->owner) == AST_STATE_UP*
>
> I guess that early media option puts channel state in AST_STATE_UP
>
> So, is there a way to not set up channel state to *AST_STATE_UP* in early
> media? Or the state check could be removed?
Early media doesn't change the channel state to AST_STATE_UP. This only
occurs if the channel is actually answered. I'd suggest providing more
details about the precise scenario including any dialplan.
--
Joshua Colp
Digium, Inc. | Senior Software Developer
445 Jan Davis Drive NW - Huntsville, AL 35806 - US
Check us out at: www.digium.com & www.asterisk.org
--
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] Problem with PJSIP and Blind Transfers
On Thu, Apr 20, 2017, at 03:34 PM, Dan Cropp wrote: > > > With PJSIP, it seems as though the success/failure of the Transfer dial > plan command occurs when it sends the REFER. It never waits to know if > it succeeds or fails. > Looking at the PJSIP messages, this TRANSFERSTATUS is sent even before > the other side has responded with the 202 Accepted packet. This is correct. TRANSFERSTATUS only reflects our ability to send the message currently, not the actual response of the other side. > > When logging the PJSIP messages, I see the so valid number case sends the > REFER, receives 202 Accepted, but the trace doesn't write the Notify/OK > response with the Verbosity and PJSIP debug enabled. It would be up to the other side to send the NOTIFY, and PJSIP itself may actually request that the implicit subscription (which generates the NOTIFY) not occur. This would explain why you don't see the NOTIFY. > > For failures, I do not even see the 404 Not Found in the log. Asterisk > replies with a TRANSFERSTATUS of SUCCESS when the other end sends the 404 > Not Found. > > Is the correct next step to submit an Issue? Yes, depending on the level of interaction we have it may be possible to make things reflect reality better. We use PJSIP functionality to do this REFER functionality so we have to see what it can do. Cheers, -- Joshua Colp Digium, Inc. | Senior Software Developer 445 Jan Davis Drive NW - Huntsville, AL 35806 - US Check us out at: www.digium.com & www.asterisk.org -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] Porting chan_sip patches res_pjsip
On Mon, Apr 17, 2017, at 02:05 PM, Steve Murphy wrote: > > Many thanks, the above gives me a glimpse into the workings and > organsization in pjsip! > > > I have asked (again) the groups, and the folks that have reported > problems > with pjsip, > > are standing by their claims. The 53i and the 57i (iirc) are not able to > hold registration > on Asterisk 13.5, with either the as-is chan_sip driver, or the as-is > pjsip > driver. > > I am trying, without success so far, to get an old 53i going under pjsip > in > my own > environment. It has been frustrating. > > We have a patch for chan_sip dating back to the 1.6 days, that solves the > problem, > but only for chan_sip (even the one in 13.5). > > If this is a bug in pjsip, and the framework of the existing driver is > truly already checking > the status of the "first" request vs the incoming request, then mayhaps > we > can apply > the same sort of fixesin pjsip. Is this a bug, then? Should I file a bug > report? It would be a different underlying fix as the registrar in PJSIP is actually doing things according to spec. The chan_sip implementation is simpler and basic. This should indeed be filed as a bug[1] with configuration and console output with SIP traffic. [1] https://issues.asterisk.org/jira -- Joshua Colp Digium, Inc. | Senior Software Developer 445 Jan Davis Drive NW - Huntsville, AL 35806 - US Check us out at: www.digium.com & www.asterisk.org -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] Porting chan_sip patches res_pjsip
On Wed, Apr 12, 2017, at 05:53 PM, Steve Murphy wrote: > Hello, I must admit, as a beginner at this, that I have a lot to learn. > > I have written a module to handle some statistics gathering, and it works > fine, > but my next priority patch leaves me quite puzzled. > > If you or anyone will hear my situation, and offer possible solutions or > advice, > I would much appreciate the help. > > My next assignment is a patch that was made to chan_sip some years > back, that overcomes a problem with older aastra phones that are set up > to > turn functions keys into blf lights. > > Such a phone issues two registrations in quick succession. The first > indicates > a normal expire= time, and uses the correct CallerID. But the second > expiration > is presented with a different callerid, but the same sip device, and > gives > an > expires=0, which causes the phone to immediately deregister. > > > I have been studying the code, and have determined that the module in > res/res_pjsip_registrar would be proper spot to make the change, in the > registrar_validate_contacts function. I have but one small problem, > and that is, I need to access either the pjsip endpoint object, or the > asterisk object, to retrieve the expire value from the contact header of > the first > REGISTER request. > > It was easy in the chan_sip code: the peer held the expire value from the > first > request. > > But in the pjsip world, I am not easily finding this value, which is the > expires=x > value from the first REGISTER request. Then in the second request, I hope > to reject the errant registration based on the difference in contact > names > between > the two requests, and the fact the second request has expire=0, etc. > > Again, any help would be appreciated. Conversations like this could be > valuable > to developers needing to work on res_pjsip. The contact and expires is not stored on an endpoint. It's stored in a contact structure (which holds the details of the Contact header from the REGISTER) which is associated with the AOR. In fact I'd expect the code to work already with that Aastra specific usage. When res_pjsip_registrar got the unregister it would look for the associated contact to remove, but as there is none by the given Contact it shouldn't remove any. -- Joshua Colp Digium, Inc. | Senior Software Developer 445 Jan Davis Drive NW - Huntsville, AL 35806 - US Check us out at: www.digium.com & www.asterisk.org -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] CentOS 6 and Ubuntu 12 Testing Support
On Tue, Apr 11, 2017, at 03:28 PM, George Joseph wrote: > Both CentOS 6 and Ubuntu 12 have fallen into the state where we can't > actually create a new instance of either that can run the Asterisk > Testsuite. In order to get it to work I've had to fiddle Python packages > both from the distributions' repositories and directly from pip which > makes > the Python environment fragile FrankenSnake. Also, ODBC packages from > that > era are unreliable so I've had to download and install both UnixODBC and > the postgresql ODBC drivers from source to get a working realtime setup. > Finally, the Ubuntu 12 ISO images contain an /etc/apt/sources.list that > no > longer works right out of the box. > > So what do you folks think the future of testing on CentOS 6 and Ubuntu > 12 > should be? 12.04 is EOL so not testing it is fine to me. CentOS 6 I don't really have a comment on, I'm not in that ecosystem myself. -- Joshua Colp Digium, Inc. | Senior Software Developer 445 Jan Davis Drive NW - Huntsville, AL 35806 - US Check us out at: www.digium.com & www.asterisk.org -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] Asterisk 13.13-cert3, 13.14.1, 14.3.1 Now Available (Security Release)
On Tue, Apr 4, 2017, at 12:23 PM, Joshua Colp wrote: > On Tue, Apr 4, 2017, at 12:11 PM, Gaston Draque wrote: > > These 13.13 links seem 404d > > > > [x] > > http://downloads.asterisk.org/pub/telephony/certified-asterisk/asterisk-certified-13.13-current.tar.gz > > [x] > > http://downloads.asterisk.org/pub/telephony/certified-asterisk/ChangeLog-certified-13.13-current > > [x] > > http://downloads.asterisk.org/pub/telephony/certified-asterisk/releases/ChangeLog-13.13-cert3 > > > > This should be resolved shortly once synchronization occurs. I'll keep > on top of it and post back once it is done. Synchronization complete! They are now there. -- Joshua Colp Digium, Inc. | Senior Software Developer 445 Jan Davis Drive NW - Huntsville, AL 35806 - US Check us out at: www.digium.com & www.asterisk.org -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] Asterisk 13.13-cert3, 13.14.1, 14.3.1 Now Available (Security Release)
On Tue, Apr 4, 2017, at 12:11 PM, Gaston Draque wrote: > These 13.13 links seem 404d > > [x] > http://downloads.asterisk.org/pub/telephony/certified-asterisk/asterisk-certified-13.13-current.tar.gz > [x] > http://downloads.asterisk.org/pub/telephony/certified-asterisk/ChangeLog-certified-13.13-current > [x] > http://downloads.asterisk.org/pub/telephony/certified-asterisk/releases/ChangeLog-13.13-cert3 > This should be resolved shortly once synchronization occurs. I'll keep on top of it and post back once it is done. -- Joshua Colp Digium, Inc. | Senior Software Developer 445 Jan Davis Drive NW - Huntsville, AL 35806 - US Check us out at: www.digium.com & www.asterisk.org -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] [13.14.0] pjsip DNS SRV: missing auto generated match entry if DNS temporarily fails on startup
On Sat, Mar 18, 2017, at 12:09 PM, Michael Maier wrote: > Hello! > > I've got one more issue with the auto generated match entry (see > https://issues.asterisk.org/jira/browse/ASTERISK-26735 ). > > If during start of asterisk DNS fails, the auto generated match entry > won't be generated any more, even hours later. > > Problem: pjsip retries after 60s and establishes the connection if DNS > is working again. But the auto generated match entries stays empty (for > ever). > > This problem sounds like *changed* DNS SRV entries won't be covered, for > sure, too. > > Please check / fix both problems! Auto generated match entries should be > checked regularly to be in sync with pjsip as any inbound call will > silently fail if there are differences between pjsip and auto generated > match entries! > > Should I file a new bug or is it enough to reopen > https://issues.asterisk.org/jira/browse/ASTERISK-26735 ? This would be under a new issue, as it's been that way since the creation of IP based matching in PJSIP and isn't due to the SRV support itself. -- Joshua Colp Digium, Inc. | Senior Software Developer 445 Jan Davis Drive NW - Huntsville, AL 35806 - US Check us out at: www.digium.com & www.asterisk.org -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] Line length restrictions in code changes
On Thu, Mar 16, 2017, at 04:54 PM, Matthew Jordan wrote:
> 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
> }
Agreed.
>
> 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
> }
>
>
> 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?
While we've had a line length rule I don't have any indication of it in
my text editor or count. I personally value readability above all. I
generally start a new line where it feels reasonable and flows best. I
don't think we need to enforce (or have) a line length rule and think
that people could naturally settle on what seems best when they are
working on the code in question.
Cheers,
--
Joshua Colp
Digium, Inc. | Senior Software Developer
445 Jan Davis Drive NW - Huntsville, AL 35806 - US
Check us out at: www.digium.com & www.asterisk.org
--
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] crashes when bridging opus channels
On Tue, Feb 21, 2017, at 12:13 PM, Moritz Maisel wrote: > Hi, > > we experience reproducable crashes of asterisk with codec_opus. While > asterisks successfully processes a couple of calls (about 8-10) when > bridging two OPUS/48000/2 channels before it crashes, it reproducably > crashes on the first call bridging PCMA/8000 to OPUS/48000/2. > > The setup is asterisk 14.3.0 with bundled pjsip and > codec_opus-14.0_1.1.0-x86_64. The environment is debian 8.7 on amd64 > architecture with kernel version 3.16.0-4-amd64. > > To reduce traffic on the list, I only append parts of the backtrace as > well > as the last lines of log output below. I appreciate any suggestions for > debugging this scenario. I'm a bit lost, as the backtrace points into the > codec_opus.so binary blob. Is it recommended to open an issue in the > bugtracker or should we first provide more information on the list? Please file an issue on the issue tracker[1] and use codec_opus as the component. We'll triage and ask for the needed information there. [1] https://issues.asterisk.org/jira -- Joshua Colp Digium, Inc. | Senior Software Developer 445 Jan Davis Drive NW - Huntsville, AL 35806 - US Check us out at: www.digium.com & www.asterisk.org -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] Deadlock GIT 13
On Thu, Feb 16, 2017, at 08:20 AM, Ross Beer wrote: > Unfortunately, the commit did not resolve the issue. > > > This looks related to a lock inversion between channel hang up and the > bridging code. There is an issue open for this > ASTERISK-26445<https://issues.asterisk.org/jira/browse/ASTERISK-26445> > > While writing I have also had the following segfault: > > Should an issue be raised for this? Asterisk shouldn't crash so any time there is one an issue should be filed. The worst case is it is a duplicate and we link/close. -- Joshua Colp Digium, Inc. | Senior Software Developer 445 Jan Davis Drive NW - Huntsville, AL 35806 - US Check us out at: www.digium.com & www.asterisk.org -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] Destroy bridge not working
On Tue, Feb 14, 2017, at 04:23 AM, sven.even...@teletopia.com wrote: > > Hi all, > I am on Asterisk 14.2.1 and I am using ari4java. > I use extensively bridging to connect an incoming call to an outgoing > call. That works well. > When a call is finished, I call "ari.bridges().destroy( bridgeId );" > to clean up. No error message > and events look correct. But I see this : There is currently an issue[1] tracking a problem with create/dial where in some circumstances the bridge may not be deleted. It sounds as though you may be experiencing the same underlying problem. [1] https://issues.asterisk.org/jira/browse/ASTERISK-26718?jql=text%20~%20"ari"%20AND%20status%20!%3D%20closed -- Joshua Colp Digium, Inc. | Senior Software Developer 445 Jan Davis Drive NW - Huntsville, AL 35806 - US Check us out at: www.digium.com & www.asterisk.org -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] Subscription Persistence Issues
On Tue, Feb 7, 2017, at 03: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. I don't trust clients enough to expect that this behavior will work for everything. If we can do the work ourselves in a way that guarantees it works for all clients I usually opt for doing that. -- Joshua Colp Digium, Inc. | Senior Software Developer 445 Jan Davis Drive NW - Huntsville, AL 35806 - US Check us out at: www.digium.com & www.asterisk.org -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] ast_rtp_engine api
On Mon, Feb 6, 2017, at 02:19 PM, Michael Blake wrote: > Hello Asterisk-dev, > > I have made some changes and been tracing through things in ddd but still > can't get the UnicastRTP to process the packets that it receives. > > I then add some debugging for the channel when it gets called. > > Looking at the other channels, I added the rtp glue, mutexes to protect > the channels, expanded the channel_tech, passed the channel off to In unicast_rtp_request have you put the file descriptor from the video RTP instance onto the channel using ast_channel_set_fd? If not then there is nothing polling on the socket, and nothing will be read. An example would be: ast_channel_set_fd(chan, 2, ast_rtp_instance_fd(instance, 0)); This places the file descriptor from instance onto the channel at position 2, which is where the video RTP file descriptor is placed for each channel drivers. -- Joshua Colp Digium, Inc. | Senior Software Developer 445 Jan Davis Drive NW - Huntsville, AL 35806 - US Check us out at: www.digium.com & www.asterisk.org -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] ast_rtp_engine api
On Wed, Feb 1, 2017, at 03:15 PM, Michael Blake wrote: > Hello asterisk-dev list, > > > > I am working on a rtp proxy that essentially takes a mp4 video stream and > converts it into a sip endpoint. > > > > To start I hacked up ekiga to use a text file with a gstreamer pipeline > defined as a video and audio source, demuxing the video and audio and > feeding it into the sip call. > > > > I then modified chan_rtp.c to send both the video and audio streams - > which > is currently working. I can use gstreamer to receive the udp streams and > play back the audio and video. > > > > Now I want to get rid of ekiga and make chan_rtp also listen for an audio > and video incoming udp stream to feed into the call. I have tried adding > the source ports to the channel, but the sockets don't actually get > opened > and listen. > > > > Looking in the other channels I see where sockets are manually opened, > but > I would rather use the rtp engine. > > > > Could someone point me in the direction where a channel defines a rtp > address/port using the ast_rtp_engine and opens the listening socket, or > some guidance to at least identify the api calls to make that happen? > > > > I think I am close, but I am missing something. The UnicastRTP channel driver should already allow the audio portion of this. It puts the local address information on the channel as dialplan variables, but it can be used as a basis. Is that what you modified? -- Joshua Colp Digium, Inc. | Senior Software Developer 445 Jan Davis Drive NW - Huntsville, AL 35806 - US Check us out at: www.digium.com & www.asterisk.org -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] ASTERISK-26699 - res_pjsip: Assertion when sending OPTIONS request to endpoint
On Tue, Jan 31, 2017, at 10:38 AM, Joshua Colp wrote: > > I believe the problem is in Asterisk, not PJSIP. We have our own logic > around the handling of sending outbound requests and in this case it is > not working as it should. It may be a result of a slight behavior change > in PJSIP, but I still think the fix is on our side. I was correct. I did a patch during lunch, it's now up for review. -- Joshua Colp Digium, Inc. | Senior Software Developer 445 Jan Davis Drive NW - Huntsville, AL 35806 - US Check us out at: www.digium.com & www.asterisk.org -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] Wish: adding intelligent codec negotiation to asterisk / pjsip
On Tue, Jan 31, 2017, at 01:29 PM, Michael Maier wrote: > On 01/31/2017 at 05:15 PM Joshua Colp wrote: > > On Tue, Jan 31, 2017, at 12:01 PM, Michael Maier wrote: > > [...] > > >>> We > >>> don't pass the information to the other side, we just adjust our formats > >>> and transcoding. > >> > >> Yes. That's not necessary. But it is necessary, that asterisk is able to > >> identify > >> - that transcoding between two UAs is currently active. > >> - the codec used by the peer UA stream and if this codec is allowed (by > >> configuration) for the other UA, too. If yes: send other UA a reinvite > >> to ensure both UAs are using the same codec as from now and switch off > >> transcoding and all other related stuff, which isn't need any more. > > > > It's not currently possible to know from a configuration perspective. > > The bridging core can know what has been currently negotiated on each > > side only. There is no mechanism to reach across and get the > > configuration information. > > I'm beginning to understand how asterisk works today and why it is not > as easy as I thought. > But the planned stream support for 15 fills this gap, which is necessary > to provide a feature to prevent transcoding if a common codec between > two legs exists. > > Therefore I would be happy if this feature would be provided w/ 15 > instead of adding a lot of time and effort to achieve it by special > adjusts / expansions of the actual code. > Stream support will provide a lot of options for cool functionality. :) -- Joshua Colp Digium, Inc. | Senior Software Developer 445 Jan Davis Drive NW - Huntsville, AL 35806 - US Check us out at: www.digium.com & www.asterisk.org -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] Wish: adding intelligent codec negotiation to asterisk / pjsip
On Tue, Jan 31, 2017, at 12:01 PM, Michael Maier wrote: > > > > There's no current generic mechanism in the core by which you can > > request that a reinvite be sent to do this. PJSIP presents a PJSIP > > specific dialplan function which can do it, and the interface for doing > > remote RTP bridging naturally allows it (but not solely for the purposes > > of changing the media codec). A mechanism for doing this has actually > > been defined as part of the stream support[1] coming in 15. We will > > accept incoming reinvites and act accordingly in a simple manner. > > You're speaking here about *incoming* reinvites to change codec (this is > already working today - I could see it with my C610IP). > To change a codec used by a stream subsequently after the initial > negotiation to prevent existing transcoding, the reinvite must be > started by asterisk itself. Will this be done, too? I'm talking about outgoing reinvites. The stream support includes a way to do this. You request that a stream topology (which includes what streams are present, their type, the formats) be changed. This will result in a reinvite going out and the result being conveyed back. > > > We > > don't pass the information to the other side, we just adjust our formats > > and transcoding. > > Yes. That's not necessary. But it is necessary, that asterisk is able to > identify > - that transcoding between two UAs is currently active. > - the codec used by the peer UA stream and if this codec is allowed (by > configuration) for the other UA, too. If yes: send other UA a reinvite > to ensure both UAs are using the same codec as from now and switch off > transcoding and all other related stuff, which isn't need any more. It's not currently possible to know from a configuration perspective. The bridging core can know what has been currently negotiated on each side only. There is no mechanism to reach across and get the configuration information. > > > A reinvite is also an asynchronous operation, so you would still need to > > set up a translation path to ensure any media flowed in the meantime and > > once accepted (if it is) the translation path could be terminated. > > Yes. But you must have it already today in some way, as changing codec > originated by UA already works fine here. Yes, we accept the incoming reinvite, negotiate it against the configuration, update the formats on the channel, and change the translation paths accordingly. If this results in no translation path then the existing is terminated. -- Joshua Colp Digium, Inc. | Senior Software Developer 445 Jan Davis Drive NW - Huntsville, AL 35806 - US Check us out at: www.digium.com & www.asterisk.org -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] ASTERISK-26699 - res_pjsip: Assertion when sending OPTIONS request to endpoint
On Tue, Jan 31, 2017, at 10:20 AM, Ross Beer wrote: > Hi Guys, > > > I've been trying to track down a problem with Asterisk which is causing a > segfault. I have recently downloaded the latest 13 branch and a lot of > the crashing issues have been resolved due to Richard Mudgett patches > (Thank you, Richard!). > > > Would this issue be related to the PJSIP project or is this caused by > Asterisk directly? > > > I would like to start this bug moving so I am happy to raise this to the > PJSIP team if needed. I believe the problem is in Asterisk, not PJSIP. We have our own logic around the handling of sending outbound requests and in this case it is not working as it should. It may be a result of a slight behavior change in PJSIP, but I still think the fix is on our side. -- Joshua Colp Digium, Inc. | Senior Software Developer 445 Jan Davis Drive NW - Huntsville, AL 35806 - US Check us out at: www.digium.com & www.asterisk.org -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] Wish: adding intelligent codec negotiation to asterisk / pjsip
On Tue, Jan 31, 2017, at 04:22 AM, Michael Maier wrote: > > My first idea was to prevent transcoding already during call setup. But > now I understand, that this is not a trivial thing to do. > > Would it be easier to do it *after* the call has been completely > established (peer has answered and both legs have been finally > established)? > > Start an additional job (if a new extension based option > (prevent_transocding e.g.) is set to true) which first checks, if > transcoding for this extension is active. If it is active, check, if the > target codec is part of the defined codecs for this extension. If yes, > send a reinvite to the extension to place the target codec as new codec. > > I would shrink this feature to extensions. If the call is between two > extensions, do it always for the callers extension. > > This sounds practicable to *me* (but I'm not an asterisk specialist :-)) > as you already today have to be able to change codecs on base of a > reinvite during a running call. There's no current generic mechanism in the core by which you can request that a reinvite be sent to do this. PJSIP presents a PJSIP specific dialplan function which can do it, and the interface for doing remote RTP bridging naturally allows it (but not solely for the purposes of changing the media codec). A mechanism for doing this has actually been defined as part of the stream support[1] coming in 15. We will accept incoming reinvites and act accordingly in a simple manner. We don't pass the information to the other side, we just adjust our formats and transcoding. A reinvite is also an asynchronous operation, so you would still need to set up a translation path to ensure any media flowed in the meantime and once accepted (if it is) the translation path could be terminated. As well the core has no concept of "extensions". It just knows channels. The mechanism and behavior for controlling the above and how it would interact with the core would also need to be defined. For example the request to do the reinvite could always be provided to the channel driver and then it would decide what to do based on configuration. [1] https://wiki.asterisk.org/wiki/display/AST/Stream+Support -- Joshua Colp Digium, Inc. | Senior Software Developer 445 Jan Davis Drive NW - Huntsville, AL 35806 - US Check us out at: www.digium.com & www.asterisk.org -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
[asterisk-dev] Stream Support Wiki Page
Greetings all, Streams are something that have come up many times in the past and I'm sure it is something we'd all like to have. To that end I've published a wiki page[1] which details what streams should be capable of, what behavior should be in the short term/middle term/long term, and an API. This is currently targeted for Asterisk 15. One of the things that was important to me when thinking about the stream problem was that all the existing modules and functionality should behave as they do today with a minimum of modifications (or ideally none). I'd rather not revisit the media format change. The design on the wiki accomplishes this by keeping changes isolated to the core and ensuring behavior for existing interfaces matches what we have today. Existing modules (including channel drivers) will not need any changes done to them. It is only when we want to move that specific module or functionality to supporting streams that code changes have to be made. Some questions to ask when looking at the wiki page though: Are there any additional requirements of streams that have been left out? Does the backwards compatible idea make sense? Does the API feel right? Do any areas need further definition? I look forward to all responses on this exciting subject! You can continue discussion here or add as comments on the wiki page. I will be monitoring both. Cheers, [1] https://wiki.asterisk.org/wiki/display/AST/Stream+Support -- Joshua Colp Digium, Inc. | Senior Software Developer 445 Jan Davis Drive NW - Huntsville, AL 35806 - US Check us out at: www.digium.com & www.asterisk.org -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] ARI Bridge Behavior
On Tue, Jan 10, 2017, at 09:47 AM, Michael Petruzzello wrote: > The following occurs when channels are in a mixing bridge with > dtmf_events > enabled created through the ARI. If a channel supplies enough DTMFs at a > time, Asterisk tries to connect that channel to another extension. Is > there > a way to disable Asterisk from doing this? I still want to collect DTMFs, > but without Asterisk trying to connect to another extension. > > I have tried cleaning up my dial plans and modifying confbridge.conf, but > these seem to be completely unrelated. I am using Asterisk 13.11.2. This shouldn't be happening... can you show an example? -- Joshua Colp Digium, Inc. | Senior Software Developer 445 Jan Davis Drive NW - Huntsville, AL 35806 - US Check us out at: www.digium.com & www.asterisk.org -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] Registration state for SIP over TCP or TLS
On Mon, Jan 9, 2017, at 02:10 PM, Steve Davies wrote: > Hi, > > I believe that the current state of affairs with Asterisk's SIP over TCP > or > TLS registration is that if a connection is dropped or closed, then the > registration is allowed to persist. > > Given that a re-connect will almost certainly not be from the same > IP/port > pair, should a TCP or TLS disconnect result in an under-the-hood > de-register? > > I believe the issue does currently exist because I have seen dropped TCP > or > TLS connections result in an "xmit_error" when the next OPTIONS ping is > attempted. > > Thoughts? Am I missing something, or would this be useful for me to look > into patching? It... depends. In a world with connection reuse you can assume that when the connection is dropped that you can't reach the other side anymore. However, if you are expected to establish an outgoing connection to the remote side then the logic that the connection has dropped and you can't reach them is not true. The Contact in that case should be valid. Cheers, -- Joshua Colp Digium, Inc. | Senior Software Developer 445 Jan Davis Drive NW - Huntsville, AL 35806 - US Check us out at: www.digium.com & www.asterisk.org -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] Asterisk or Jansson issue?
On Wed, Dec 14, 2016, at 09:07 AM, Ross Beer wrote: > Hi, > > Is the below segfault caused by Asterisk or Jansson? Currently using > version 2.9 as packaged with Fedora 23. It is likely in our usage of jansson or memory corruption. An issue should be filed for it if not already done. -- Joshua Colp Digium, Inc. | Senior Software Developer 445 Jan Davis Drive NW - Huntsville, AL 35806 - US Check us out at: www.digium.com & www.asterisk.org -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] Asterisk 13 GIT Deadlock
On Tue, Jan 3, 2017, at 07:56 AM, Ross Beer wrote: > Hi All, > > > I've raised a ticket for a recent deadlock in Asterisk and can't track > down the cause: > > > 1. > ASTERISK-26686<https://issues.asterisk.org/jira/browse/ASTERISK-26686> > (https://issues.asterisk.org/jira/browse/ASTERISK-26686) > > > The issue is happening daily on multiple servers at random times. > > > Can anyone provide assistance on the cause so I can update the ticket > with the correct information? I have already triaged this issue and added the cause. -- Joshua Colp Digium, Inc. | Senior Software Developer 445 Jan Davis Drive NW - Huntsville, AL 35806 - US Check us out at: www.digium.com & www.asterisk.org -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] Subscription behavior when an incoming registration goes away?
On Thu, Dec 22, 2016, at 12:14 PM, Matthew Jordan wrote: > 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. An AoR is only consulted for unsolicited NOTIFY messages, right now those wouldn't happen without any contacts. Subscriptions themselves don't consult the AOR as they already have a target in them. > > 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. Agreed. On the client side each are usually considered separate and only upon initial startup does everything occur (registration/subscriptions). The fact that a re-registration has occurred doesn't itself trigger new subscriptions or refreshes. It may "work" if we still send a NOTIFY saying the subscription is terminated (which you're trying to avoid I believe), the device might then start a new subscription... but we're into client side behavior here. -- Joshua Colp Digium, Inc. | Senior Software Developer 445 Jan Davis Drive NW - Huntsville, AL 35806 - US Check us out at: www.digium.com & www.asterisk.org -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] app_queue: member not removed from pending_members
On Fri, Dec 9, 2016, at 10:56 AM, Tomec Martin wrote: > Hi all, > there are still cases, when member is not removed from pending_members, > for example in this issue: > https://issues.asterisk.org/jira/browse/ASTERISK-26621 > There was patch to prevent this (https://gerrit.asterisk.org/#/c/3744/1) > but it does not cover all cases. > For now I think that the most reliable solution would be to add timestamp > and timeout for pending_members entries. > Before writing patch, I would like to ask - have somebody any better > idea? While this should work eventually, depending on timeout value, I think we need to understand precisely the scenarios where stuff is failing to find the real solution. It may be that the original change just isn't viable and needs to be reverted. -- Joshua Colp Digium, Inc. | Senior Software Developer 445 Jan Davis Drive NW - Huntsville, AL 35806 - US Check us out at: www.digium.com & www.asterisk.org -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] Possible change to the AMI PJSIPShowRegistrationsInbound command
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. -- Joshua Colp Digium, Inc. | Senior Software Developer 445 Jan Davis Drive NW - Huntsville, AL 35806 - US Check us out at: www.digium.com & www.asterisk.org -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] Asterisk goes Spatial Conferencing: the STEAK project
On Fri, Nov 25, 2016, at 10:20 AM, Dennis Guse wrote: > Hey guys, > > we continued working on our largest changeset: https://gerrit. > asterisk.org/#/c/3524/ > Besides the copyright of HRTFs (still under investigation from our side), > the only issue on our side is the introduced `settings_lock` (defined in > bridge.h:254). > This lock is used in addition to the bridge-lock in bridge_softmix:1093. > > The issue the settings_lock solves is that during bridge startup > (actually > `softmix_mixing_thread()`) we need to know the configuration parameters > (is > binaural active or not?). > Since the startup of the mixing thread and parsing the configuration is > asynchronous (at least our understanding: we saw race conditions), we use > the 2nd lock to wait until configuration information is available before > really starting the mixing thread. > We could avoid introducing the settings_lock by repeatedly checking in > the > mixing loop. > However, this doesn't sound like a good idea... > Thus, a bridge now has two locks (ast_bridge_lock and the settings_lock), > which is some overengineering. > > Is there a better solution to addressing this issue? Without changing things such that settings and attributes could be passed in during the bridge creation or making bridge creation a two stage process (both of which are larger changes than I'd like to see) I don't see a way to do this during bridge creation. Is it possible to check in the bridge loop to see that binaural has been enabled but not set up and set it up? This should not impact the mixing loop a large amount during normal operation and overcomes the problem that the settings_lock has right now. It would also allow API control to toggle binaural on/off at a bridge level. -- Joshua Colp Digium, Inc. | Senior Software Developer 445 Jan Davis Drive NW - Huntsville, AL 35806 - US Check us out at: www.digium.com & www.asterisk.org -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] Asterisk goes Spatial Conferencing: the STEAK project
On Fri, Nov 25, 2016, at 10:20 AM, Dennis Guse wrote: > Hey guys, > > we continued working on our largest changeset: https://gerrit. > asterisk.org/#/c/3524/ > Besides the copyright of HRTFs (still under investigation from our side), > the only issue on our side is the introduced `settings_lock` (defined in > bridge.h:254). > This lock is used in addition to the bridge-lock in bridge_softmix:1093. > > The issue the settings_lock solves is that during bridge startup > (actually > `softmix_mixing_thread()`) we need to know the configuration parameters > (is > binaural active or not?). > Since the startup of the mixing thread and parsing the configuration is > asynchronous (at least our understanding: we saw race conditions), we use > the 2nd lock to wait until configuration information is available before > really starting the mixing thread. > We could avoid introducing the settings_lock by repeatedly checking in > the > mixing loop. > However, this doesn't sound like a good idea... > Thus, a bridge now has two locks (ast_bridge_lock and the settings_lock), > which is some overengineering. > > Is there a better solution to addressing this issue? While I don't yet have an answer for this I've poked others and am pondering options myself. -- Joshua Colp Digium, Inc. | Senior Software Developer 445 Jan Davis Drive NW - Huntsville, AL 35806 - US Check us out at: www.digium.com & www.asterisk.org -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] tcptls: Use new certificate on reload
On Sun, Nov 27, 2016, at 11:29 PM, Corey Farrell wrote: > A review [1] has been posted to fix an issue where TLS servers would > not be restarted unless the bind address was changed. This would > prevent use of new certificates if available. Unfortunately this > change does cause an ABI change. Fields are added to public > structures 'struct ast_tls_config' and 'struct > ast_tcptls_session_args'. Within Asterisk itself these structures are > used by app_externalivr, chan_sip, res_http_websocket, http.c and > manager.c. > > tcptls.h does not provide an allocation method for it's structures. > These means it is impossible to add fields to these structures without > breaking the ABI. How does everyone feel about moving forward with > the fix as is? When it comes to ABI compatibility I take what exactly is being changed into account. In the case of the TCP/TLS code it's not something I'd see outside code or developers using (the commercial modules certainly don't use it) which is why I'm personally not opposed to accepting it. Any other thoughts? Do we want to be strict and only allow on master? -- Joshua Colp Digium, Inc. | Senior Software Developer 445 Jan Davis Drive NW - Huntsville, AL 35806 - US Check us out at: www.digium.com & www.asterisk.org -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] Can't build --with-pjproject-bundled on debian 7
On Tue, Nov 22, 2016, at 08:26 AM, Niklas Larsson wrote: > Hi, > > Clean checkout of asterisk 13.13 on debian 7 -> ./configure > --with-pjproject-bundled; make > > gives: > > [snipped] > creating makelist > creating config.h >[LD] abstract_jb.o acl.o adsi.o alaw.o aoc.o app.o ast_expr2.o >ast_expr2f.o asterisk.o astfd.o astmm.o astobj2.o astobj2_container.o >astobj2_hash.o astobj2_rbtree.o audiohook.o autochan.o autoservice.o >backtrace.o bridge.o bridge_after.o bridge_basic.o bridge_channel.o >bridge_roles.o bucket.o callerid.o ccss.o cdr.o cel.o channel.o >channel_internal_api.o chanvars.o cli.o codec.o codec_builtin.o >config.o config_options.o core_local.o core_unreal.o crypt.o data.o >datastore.o db.o devicestate.o dial.o dns.o dnsmgr.o dsp.o endpoints.o >enum.o event.o features.o features_config.o file.o fixedjitterbuf.o >format.o format_cache.o format_cap.o format_compatibility.o frame.o >framehook.o fskmodem.o global_datastores.o hashtab.o heap.o http.o >image.o indications.o io.o jitterbuf.o json.o loader.o lock.o logger.o >manager.o manager_bridges.o manager_channels.o manager_endpoints.o >manager_mwi.o manager_system.o max_forwards.o md5.o media_index.o >message.o mixmonitor.o named_acl.o named_locks.o ne > tsock.o netsock2.o optional_api.o parking.o pbx.o pbx_app.o > pbx_builtins.o pbx_functions.o pbx_hangup_handler.o pbx_switch.o > pbx_timing.o pbx_variables.o pickup.o plc.o poll.o presencestate.o > privacy.o rtp_engine.o say.o sched.o sdp_srtp.o security_events.o sem.o > sha1.o sip_api.o slinfactory.o smoother.o sorcery.o sounds_index.o srv.o > stasis.o stasis_bridges.o stasis_cache.o stasis_cache_pattern.o > stasis_channels.o stasis_endpoints.o stasis_message.o > stasis_message_router.o stasis_system.o stdtime/localtime.o strcompat.o > stringfields.o strings.o stun.o syslog.o taskprocessor.o tcptls.o tdd.o > term.o test.o threadpool.o threadstorage.o timing.o translate.o udptl.o > ulaw.o uri.o utils.o uuid.o version.o xml.o xmldoc.o editline/libedit.a > -> asterisk > ./libasteriskpj.so: undefined reference to `clock_gettime' > collect2: error: ld returned 1 exit status > make[1]: *** [asterisk] Error 1 > make: *** [main] Error 2 > > Same on debian 8 compiles/links without problems > > Skipping --with-pjproject-bundled does make it compile on debian 7. This was found already and fixed[1]. [1] https://gerrit.asterisk.org/#/c/4481/ -- Joshua Colp Digium, Inc. | Senior Software Developer 445 Jan Davis Drive NW - Huntsville, AL 35806 - US Check us out at: www.digium.com & www.asterisk.org -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] Put Queue in Stasis Application
On Mon, Nov 21, 2016, at 11:18 AM, Salvatore Franco wrote: > Ok, > so the good news is that I'm not completely unable to do this :) > > Well, in your opionion, if ARI is too much high-level, how can i approach > to the problem to manipulate channels that are in "standard" queue? ARI is not too much high level to write a queue application. A few people have done so and it works great. It just doesn't allow you to control existing applications. As for manipulating channels in the standard queue some stuff can be done using AMI, but it may not work well and what you can do may be incomplete. -- Joshua Colp Digium, Inc. | Senior Software Developer 445 Jan Davis Drive NW - Huntsville, AL 35806 - US Check us out at: www.digium.com & www.asterisk.org -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] [channel] get the other peer codec
On Mon, Nov 21, 2016, at 11:16 AM, Aurele Traynard wrote: > thanks for your answer > "set your nativeformats to the negotiated codecs and let Asterisk do the > rest." would be great for me but I could not find how to do this > if transcode is not allowed and one of my codec is compatible with the > other side codec I would like to know which codec it is and then set my > nativeformats... i don't care about the phase my channel (and the > middleware/hardware managed) is flexible. This is not currently possible. Each side is independently negotiated and like I said there is no way to receive this information or to safely query the information. -- Joshua Colp Digium, Inc. | Senior Software Developer 445 Jan Davis Drive NW - Huntsville, AL 35806 - US Check us out at: www.digium.com & www.asterisk.org -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] Put Queue in Stasis Application
On Mon, Nov 21, 2016, at 11:00 AM, Salvatore Franco wrote: > Hi, > my application should: > > * control member status (Online, Offline, Talking, Ringing, Away etc.) > * Send a notification to the member when incoming call arrives > * Answer, Hang up, Park, Transfer, Start Conference call > * Record Call > * Read DTMF to verify security OTP sent through SMS by my WebApp > * Start an Outbound Call > > All of this operation were handled by queue with fewestcalls strategy. > > Can you explain me how to implement my own queue? The primitives ARI exposes are documented on the wiki[1] and have tutorials for a few different sections[2][3]. ARI itself, while some Asteriskisms come through, is really built around higher level concepts. As for explaining how to implement your own queue that's not something that I think anyone can really do. You need to define what the queue should do and then use the primitives to implement it. [1] https://wiki.asterisk.org/wiki/display/AST/Asterisk+13+ARI [2] https://wiki.asterisk.org/wiki/display/AST/ARI+and+Channels%3A+Manipulating+Channel+State [3] https://wiki.asterisk.org/wiki/display/AST/Introduction+to+ARI+and+Bridges -- Joshua Colp Digium, Inc. | Senior Software Developer 445 Jan Davis Drive NW - Huntsville, AL 35806 - US Check us out at: www.digium.com & www.asterisk.org -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] [channel] get the other peer codec
On Mon, Nov 21, 2016, at 11:01 AM, Aurele Traynard wrote: > Hi everyone, > > The main goal of the channel is to make or receive call from another > channel (mainly SIP) > I writing a custom channel I have now something working with codec "alaw" > When I add multiple codecs Asterisk's core "negociate" the good codec and > give it in the "request" function then I can know wich codec I have to > use. > (maybe it is not asterisk's core wich do this?) > When the call comes from my channel, I can'tknwo which codec will be used > by the other channel... > > I tried to read chan_sip and chan_iax2 as I did to write my custom > channel, > but I could'n see what to do... > > thanks for any help and feel free to ask anything about my problem if I > was > not clear enough. There is currently no mechanism to know what the other side when answered has negotiated. It's been talked about previously that it would be good to have such a thing, but it does not exist currently. The only thing you can do is set your nativeformats to the negotiated codecs and let Asterisk do the rest. -- Joshua Colp Digium, Inc. | Senior Software Developer 445 Jan Davis Drive NW - Huntsville, AL 35806 - US Check us out at: www.digium.com & www.asterisk.org -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] Put Queue in Stasis Application
On Mon, Nov 21, 2016, at 10:42 AM, Salvatore Franco wrote:
> Hi,
> I'm trying to implement a web application that can handle inbound calls
> from my queue with 3 members.
> If I use Zoiper (or similar SIP Clients) it's fine but if I try to answer
> using ARI REST channels/{channelId}/answer the response is always:
>
> Channel is not in Stasis Application.
>
> Otherwise, if I change my dialplan to put the incoming channel in Stasis
> before to append to queue, the phone never rings.
>
> Any suggestions?
ARI does not allow you to interact with or control the app_queue
application. It allows you to write your own replacement for app_queue.
ARI provides the primitives required to do so.
What were you looking to do from ARI?
--
Joshua Colp
Digium, Inc. | Senior Software Developer
445 Jan Davis Drive NW - Huntsville, AL 35806 - US
Check us out at: www.digium.com & www.asterisk.org
--
_
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
asterisk-dev mailing list
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] sorcery_memory_cache_delete: Unable to delete object
On Fri, Nov 18, 2016, at 07:54 AM, Ross Beer wrote: > Hi, > > > Should asterisk output the following message if the object isn't in the > cache? > > > [2016-11-18 11:50:25] ERROR[73437]: res_sorcery_memory_cache.c:1558 > sorcery_memory_cache_delete: Unable to delete object '<>' from > sorcery cache > > > In my opinion, this isn't needed and just causes the logs to fill up. > > > If this is actually an error how can this be fixed? The fact that it can't delete the object won't hurt stuff, but it would be nice to know precisely the configuration and scenario that causes it to want to delete something that doesn't exist. An issue would need to be created with the configuration and logs with core debug of level 2. -- Joshua Colp Digium, Inc. | Senior Software Developer 445 Jan Davis Drive NW - Huntsville, AL 35806 - US Check us out at: www.digium.com & www.asterisk.org -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] ARI versioning in 13 and 14
+1 to option 2. -- Joshua Colp Digium, Inc. | Senior Software Developer 445 Jan Davis Drive NW - Huntsville, AL 35806 - US Check us out at: www.digium.com & www.asterisk.org -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] ASTERISK-26589 and ASTERISK-26445
On Wed, Nov 16, 2016, at 11:22 AM, Ross Beer wrote: > Hi All, > > > I have a couple of tickets open related to accessing RTP/SDP which cause > Asterisk to deadlock and stop processing calls. This has the knock-on > effect of task processors exceeding their limits and displaying errors. > There are a few of these bugs now being raised (ASTERISK-26601) and I > wondered if they all related to the two tickets ASTERISK-26589 and > ASTERISK-26445? > > > If they are can I ask if these are being worked on? If not I will most > likely seek a developer to resolve the issue. They remain open, so noone that I am aware of is currently working on them. When they are they get assigned and go to in progress. -- Joshua Colp Digium, Inc. | Senior Software Developer 445 Jan Davis Drive NW - Huntsville, AL 35806 - US Check us out at: www.digium.com & www.asterisk.org -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] ast_sip_session
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. Cheers, -- Joshua Colp Digium, Inc. | Senior Software Developer 445 Jan Davis Drive NW - Huntsville, AL 35806 - US Check us out at: www.digium.com & www.asterisk.org -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] Strategies for handling RTCP feedback in codec modules
On Fri, Nov 11, 2016, at 07:36 PM, Lorenzo Miniero wrote: > > > > > > As a side note, I anticipated the code is ugly in its current form, and I > > > haven't checked if there can be leaks as it is. I've been away from > > > Asterisk coding for a while, so fresh eyes can probably help spot those, > > > if > > > any! :-) > > > > I think there's actually no leaks in it from first glance, so even for > > testing you should be fine. Looks like you're on the right track! > > > > > > Thanks! I'll play a bit with codecs then as soon as I have some time. By > the way, would you rather me open a jira or something like this for this > effort, or is keeping on reporting here fine? It will need a JIRA issue in the future regardless. -- Joshua Colp Digium, Inc. | Senior Software Developer 445 Jan Davis Drive NW - Huntsville, AL 35806 - US Check us out at: www.digium.com & www.asterisk.org -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
Re: [asterisk-dev] Strategies for handling RTCP feedback in codec modules
On Fri, Nov 11, 2016, at 10:09 AM, Lorenzo Miniero wrote: > > Hi all, > > I just completed a tentative patch that implements what we discussed. You > can find it attached (assuming mailman doesn't strip it), and I used the > Asterisk 14.1.2 as a basis if you want to try it. Can you give a look to > see if this is in line with what we discussed, and if as an approach it > is > in line with the architecture philosophy of Asterisk itself? > > To summarize, this is what I did: > > >1. I added a new ast_frame frametype called AST_FRAME_RTCP (I guess we >could re-use AST_FRAME_CONTROL with something like an AST_CONTROL_RTCP >subclass, but that's semantics); >2. I also added a new callback that translators can implement, called >"feedback", that takes a pvt and a frame as parameters just as >"framein"; >as a proof of concept, I implemented a placeholder method for >codec_speex >that prints the incoming feedback; >3. when the RTP stack receives a SR/RR, ast_rtcp_read returns a frame >containing a copy of the ast_rtp_rtcp_report object instead of a null >frame; >4. when __ast_read gets an AST_FRAME_RTCP frame, it checks if a >"write" >translator exists (as we want to notify the encoder, not the decoder) >via >ast_channel_writetrans(chan) and calls ast_translate over it to pass >over >the frame; >5. when ast_translate gets an AST_FRAME_RTCP frame, it checks if the >"feedback" callback exists for the specified translator, and if it >does it >sends the frame there; >6. the feedback callback in the translator can be used by the codec to >parse the ast_rtp_rtcp_report object and handle it accordingly. > > > Not sure if this is exactly what you meant or envisaged but, while > probably > ugly, it seems to work fine, and does not affect codec modules not > interested in or aware of the feature. This is what I envisioned would need to be done and is how I would have approached it so you're good in my book! > > That said, there are probably a few things to think about. For one, the > feedback is "routed" by __ast_read automatically, without involving > channel > modules themselves. Not sure if this is good or not, but I thought it > made > sense to have something that worked automatically no matter the channel, > and without requiring any update on their code either. Nevertheless, > there > may be reasons I'm not aware of for having this go through channel > modules > anyway, so let me know if that's indeed an issue. I don't think it needs to go via them for the purpose of informing the translator. Eventually it would be useful to explore if we can (and how to) pass feedback end to end for cases where we aren't transcoding. > > Another potential issue in the patch in its current form is that I'm not > sure if codec translator chaining can happen in calls and if we should > care. If, for instance, there's a slin->slin16->codecX because codecX > only > has "native" slin16->codecX support but we're bridging to slin, then this > approach may need be extended, namely to make sure the feedback gets to > all > the pieces, or at least to the one that really matters (the last one?) In > fact, I guess ast_channel_writetrans(chan) would pass the feedback to > slin->slin16, and not to slin16->codecX which is where the real deal > should > happen instead. Not exactly sure on how we could handle this: at the > moment, the feedback callback doesn't expect the module to return > anything, > something we might change to see if we can have this feedback crawl up. > Alternatively this could be done automatically within translate.c itself, > who would be aware of such a chain. Again, not even sure this is an issue > but I thought I'd mention it. In the case of some codecs the path will indeed involve a resample before getting to the real codec. I think going through the path (which is just a linked list) and giving the feedback to each would be best and shouldn't harm things. > > To conclude, the patch doesn't currently do anything with the feedback. I > guess that at this stage that's beyond the point, as the main result I > wanted to achieve was putting up some sort of feedback mechanism in the > first place. Should you believe I'm on the right way I'll work a bit on > the > codec stuff itself (and speex here is a good candidate as it does have > many > knobs one can play with). > > As a side note, I anticipated the code is ugly in its current form, and I > haven't checked if there can be leaks as it is. I've been away from > Asterisk coding for a while, so fresh eyes can
Re: [asterisk-dev] Chan_pjsip keep_alive_interval
On Wed, Nov 9, 2016, at 02:22 PM, Ross Beer wrote: > Hi Joshua, > > > Looking at traces, there are packets being sent with length 4. These show > as PSH, ACK in a Wireshark. However, in TLS I don't see any such packets > which I believe is the cause of the TLS connection is being closed. > > > Can you confirm if Asterisk does send these packets on TLS transports? The code itself does not distinguish (or know) that it is TCP or TLS. It only knows that the transport is a reliable one and in that case does the keep alive. -- Joshua Colp Digium, Inc. | Senior Software Developer 445 Jan Davis Drive NW - Huntsville, AL 35806 - US Check us out at: www.digium.com & www.asterisk.org -- _ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
