similar to: Vorbis vs Opus

>>>>> "JC" == Joshua Colp <jcolp at digium.com> writes: JC> I disagree that it makes it worthless for a large number of JC> users. It's only within the last few days that a few people have run JC> into this particular issue where they have a public IP address that is JC> changing a lot and PJSIP does not support changing it without a JC> restart.

>>>>> "DC" == D'Arcy Cain <darcy at VybeNetworks.com> writes: DC> Perhaps someone can explain what t38timeout is supposed to do A 'git grep t38timeout' on the src leads one to res/res_fax.c, where one case see that it is the number of miliseconds to permit for t38 negotiation to complete once it starts. Ie after both sides select t38, until they

>>>>> "AS" == A J Stiles <asterisk_list at earthshod.co.uk> writes: AS> If you are paying for a business-grade Internet connection, you AS> should get a static IP address -- or a block of them -- as AS> standard. Maybe you need to change your ISP? In some places (including here) static ip is not affordable. -JimC -- James Cloos <cloos at

On Fri, Apr 24, 2015 at 9:59 AM, G?k?en Eraslan <gokcen.eraslan at gmail.com> wrote: [...] > > But "Watch" only notifies when there are new pull requests and issues, > which doesn't make sense for the r-source repository. Following Github Atom > feed[1] sounds better, however the feed only provides commit messages not > the diffs. > Right, sorry, I

When testing chacha20-poly1305, I noticed that aes-gcm is significantly faster than aes-ctr or aes-cbs with umac. Even on systems w/o aes-ni or other recent instruction set additions. And there seems to be consensus in the crypto community that AEAD ciphers are the way forward. As such, it promoting the AEAD ciphers to the head of the preference list looks like a good idea. That would mean

>>>>> "JC" == Joshua Colp <jcolp at digium.com> writes: JC> This stems from PJSIP not being dynamic with transports (it JC> doesn't like its environment changed to that degree while JC> in use). I'm afraid if your IP changes you'd have to restart JC> Asterisk when you are using PJSIP. Wow. I say this having voted for pjsip over the listed

Hi all, There's a good chance that the people who most need to see this won't see it, but here goes anyway. Google is currently dropping a _lot_ of the mail we attempt to deliver to lists.fd.o subscribers. The immediate cause is sending on mail from domains with SPF/DKIM/DMARC policies which explicitly specify that lists.fd.o cannot relay mail on their behalf. Every time we do that, not

>>>>> D'Arcy Cain <darcy at VybeNetworks.com> writes: >> Ie after both sides select t38, until they agree on the t38 terms. > OK, so does that mean that setting it to 25000 should leave time for the > re-invite or does the timeout start after that. As I wrote above, after that. After the sip/sdp. -JimC -- James Cloos <cloos at jhcloos.com>

On Tue, March 3, 2015 13:37, James Cloos wrote: >>>>>> "JBB" == James B Byrne <byrnejb at harte-lyne.ca> writes: > > JBB> tcpenable=yes > JBB> tlsenable=yes > JBB> tlscertfile=/etc/pki/asterisk/ca.harte-lyne.hamilton.asterisk.crt > JBB> tlscafile=/etc/pki/tls/certs/ca-bundle.crt > JBB> tlsdontverifyserver=yes > JBB>

The IANA has pre-allocated id 4 for ed25519. If waiting on the IANA were a reason to delay applying the SSHFP_KEY_ED25519 patch, it needn't be any longer. I've proposed un-reserving hash type 0 to be a "NULL hash", for those who'd rather publish the public key unhashed. Even if zero for unhashed fails to gain traction, I hope to see something allocated for that. But

Given a box with a sip proxy listen(2)ing on 0.0.0.0 and chan_sip or chan_pjsip listen(2)ing on 127.0.0.1, with ast sending rtp directly, will ast negotiate srtp or dtls even ast and the proxy speak sip in the clear over the lo interface? Avoiding encryption over lo can aid debugging, but will doing so also block secure media? -JimC -- James Cloos <cloos at jhcloos.com> OpenPGP:

https://bugzilla.mindrot.org/show_bug.cgi?id=2695 Bug ID: 2695 Summary: inconsistent outout of "ssh.add -l" between ed25519 and rsa keys Product: Portable OpenSSH Version: 7.3p1 Hardware: Other OS: Linux Status: NEW Severity: minor Priority: P5 Component:

Dear All, Is there anyone who is having FastAGI support for C & C++? We do have FastAGI working for the JAVA and rest of the language / script. But I am unable to find FastAGI for C/C++. Please let us know how to write FastAGI using C/C++. Thanks in Advance, Kashyap -------------- next part -------------- An HTML attachment was scrubbed... URL:

On 2017-04-18 08:31 PM, Victor Villarreal wrote: > Maybe excecuting the following command at Asterisk console, will help you: > > asterisk> voicemail show users > > And you will get a list of all mailbox configured in your system. Search > for the user with problems. VoiceMail stocktrans2 Angelica Douglas 12 Definitely there. In fact, I generate all

Dear Martin, Does the work on nchar mean that bugs #16090 and #16091 will be resolved [1,2]? Thanks, Mark [1] https://bugs.r-project.org/bugzilla3/show_bug.cgi?id=16090 [2] https://bugs.r-project.org/bugzilla3/show_bug.cgi?id=16091 On Sat, Apr 25, 2015 at 11:06 PM, James Cloos <cloos at jhcloos.com> wrote: > >>>>> "GC" == G?bor Cs?rdi <csardi.gabor at

Starting with 3.7 rc1, my workstation seems to loose ram. Up until (and including) 3.6, used-(buffers+cached) was roughly the same as sum(rss) (taking shared into account). Now there is an approx 6G gap. When the box first starts, it is clearly less swappy than with <= 3.6; I can''t tell whether that is related. The reduced swappiness persists. It seems to get worse when I update

Hello I get the following error when using our Let's Encrypt ssl certificate for webRTC calls : [Jun 2 14:29:28] == DTLS ECDH initialized (secp256r1), faster PFS enabled [Jun 2 14:29:28] ERROR[27360][C-00000ae5]: res_rtp_asterisk.c:1441 ast_rtp_dtls_set_configuration: Specified certificate file '/etc/letsencrypt/live/ws.mydomain.tld/privkey.pem' for RTP instance

We are seeing something weird we haven't come across before. It seems they are sending us a different IP in the SIP from URI, than the IP they are actually sending us the traffic from. Basically, the traffic is coming from 65.211.180.237 but the header is: f: <sip:+1347545xxx at 199.173.94.80:5060;user=phone>;tag=4-45026-159e4a6-995949f-159e4a6 Does anyone know if this is normal and

The progress metre in scp(1) breaks when the tty is too wide. This patch is the effortless fix: ########################################################################### :; diff -u openssh-2.1.1p2/scp.c openssh-2.1.1p2+jhc/scp.c --- openssh-2.1.1p2+jhc/scp.c Thu Jun 22 07:32:32 2000 +++ openssh-2.1.1p2/scp.c Sat Jul 1 22:15:36 2000 @@ -1176,8 +1176,9 @@ i = barlength *

Hi, This is an early warning: OpenSSH will drop tcpwrappers in the next release. sshd_config has supported the Match keyword for a long time and it is possible to express more useful conditions (e.g. matching by user and address) than tcpwrappers allowed. Removing it reduces the amount of code in the 'hot' pre-authentication path in sshd and rids us of a dependency. -d