search for: 13.16

Send CentOS-announce mailing list submissions to centos-announce at centos.org To subscribe or unsubscribe via the World Wide Web, visit http://lists.centos.org/mailman/listinfo/centos-announce or, via email, send a message with subject or body 'help' to centos-announce-request at centos.org You can reach the person managing the list at centos-announce-owner at centos.org When

CentOS Errata and Security Advisory 2005:396 https://rhn.redhat.com/errata/RHSA-2005-396.html The following updated files have been uploaded and are currently syncing to the mirrors: s390: updates/s390/RPMS/xorg-x11-6.8.2-1.EL.13.16.s390.rpm updates/s390/RPMS/xorg-x11-Mesa-libGL-6.8.2-1.EL.13.16.s390.rpm updates/s390/RPMS/xorg-x11-Mesa-libGLU-6.8.2-1.EL.13.16.s390.rpm

CentOS Errata and Security Advisory 2005:396 https://rhn.redhat.com/errata/RHSA-2005-396.html The following updated files have been uploaded and are currently syncing to the mirrors: x86_64: xorg-x11-6.8.2-1.EL.13.16.x86_64.rpm xorg-x11-deprecated-libs-6.8.2-1.EL.13.16.i386.rpm xorg-x11-deprecated-libs-6.8.2-1.EL.13.16.x86_64.rpm xorg-x11-deprecated-libs-devel-6.8.2-1.EL.13.16.x86_64.rpm

CentOS Errata and Security Advisory 2005:396 https://rhn.redhat.com/errata/RHSA-2005-396.html The following updated files have been uploaded and are currently syncing to the mirrors: i386: xorg-x11-6.8.2-1.EL.13.16.i386.rpm xorg-x11-deprecated-libs-6.8.2-1.EL.13.16.i386.rpm xorg-x11-deprecated-libs-devel-6.8.2-1.EL.13.16.i386.rpm xorg-x11-devel-6.8.2-1.EL.13.16.i386.rpm

CentOS Errata and Security Advisory 2005:396 https://rhn.redhat.com/errata/RHSA-2005-396.html The following updated files have been uploaded and are currently syncing to the mirrors: files: updates/ia64/RPMS/xorg-x11-6.8.2-1.EL.13.16.ia64.rpm updates/ia64/RPMS/xorg-x11-Mesa-libGL-6.8.2-1.EL.13.16.ia64.rpm updates/ia64/RPMS/xorg-x11-Mesa-libGLU-6.8.2-1.EL.13.16.ia64.rpm

How can I resolve a yum conflict? A lot of other packages depend on the conflicting file. Thanks. Morten [root at machine ~]# yum install xorg-x11-deprecated-libs Setting up Install Process Setting up Repos update 100% |=========================| 951 B 00:00 base 100% |=========================| 1.1 kB 00:00 addons 100%

On Fri, Jun 16, 2017, at 02:13 AM, Michael Maier wrote: > Has anybody any idea why asterisk drops the media stream in the 200 OK? > The channel has been T38_ENABLED before! Or is it necessary to add more > debug code? Who does the negotiating? > Only asterisk or is pjsip doing some parts, too? Asterisk does the T.38 negotiation and produces the answer SDP, PJSIP does the SDP

Hello! I'm still trying to get a working t.38 configuration w/ pjsip. I'm now able to send t.38 faxes to my own extension: hylafax -> t38modem -> extension -> extension -> t38modem -> hylafax. The fax is sent by t38modem. The receiving part of t38modem accepts the call, sends ReInvite for t.38 and things are working as expected. Now, let's do the nearly same

On 06/04/2017 at 01:41 PM Telium Technical Support wrote: > Just a guess (without knowing about your network), but are the two ends > points on public networks and visible to one another? If not the reinvite > may be passing an internal (nat'ed) address to the other and the connection > will fail...just a though t38modem -tt -o /var/log/t38modem.log --no-h323 -u 91 --sip-listen

On Mon, Jun 5, 2017, at 01:22 PM, Michael Maier wrote: > > Do you have any idea where to start to look at? Adding additional output > in the source code? Which functions could be interesting? I may add own > debug code to see why things are happening as they happen here. The logic for T.38 negotiation lives all in the res_pjsip_t38 module and the request to negotiate works using a

On 06/11/2017 at 06:51 PM Joshua Colp wrote: > On Sun, Jun 11, 2017, at 01:47 PM, Joshua Colp wrote: >> The distributor is in res/res_pjsip/pjsip_distributor.c, the distributor >> function being the entry point. That function returning PJ_TRUE >> indicates to PJSIP that it has been handled and no subsequent modules >> should be called by that running thread. The

On Sun, Jun 11, 2017, at 11:34 AM, Michael Maier wrote: <snip> > > > > PJSIP uses a dispatch model. The request is queued up, acted on, and > > then that's it. The act of acting on it removes it from the queue. > > That's the *expected* behavior ... . I rechecked again and again. All > existing tcpdumps. The "resent" package isn't part of

On Mon, Jun 5, 2017, at 12:00 PM, Joshua Colp wrote: > On Mon, Jun 5, 2017, at 11:49 AM, Michael Maier wrote: > > On 06/05/2017 at 11:30 AM, Joshua Colp wrote: > > > On Sun, Jun 4, 2017, at 10:40 AM, Michael Maier wrote: > > >> On 06/04/2017 at 01:41 PM Telium Technical Support wrote: > > >>> Just a guess (without knowing about your network), but are

On Fri, Jun 16, 2017, at 10:49 AM, Michael Maier wrote: <snip> > > t38modem and asterisk are using > > m=image 35622 udptl t38 > ^^^^^ > > Provider uses > > m=image 35622 UDPTL t38 > ^^^^^ > > Could this be a problem? If I'm sending internal only, it's always > lowercase. Looking at the tests we have we

On Sun, Jun 11, 2017, at 08:16 AM, Michael Maier wrote: <snip> > I did some further investigations and fixed a local problem. Now, > asterisk is able to successfully activate T.38 - unfortunately just for > very shot time because of a phantom package it receives! What was the local problem? > Let's go into details: > I'm starting at the point where asterisk / fax

Hello! unchanged asterisk crashes during udptl / t.38 negotiation with telekom - they do not support t.38 / udptl. In detail: fax client -> asterisk -> telekom -> easybell -> asterisk -> fax server Fax server sends t.38 reinvite via asterisk to easybell. Session Description Protocol Version (v): 0 Owner/Creator, Session Id (o): - 2447581897 4 IN IP4 46.17.15.23

On Sun, Jun 11, 2017, at 01:31 PM, Michael Maier wrote: > On 06/11/2017 at 04:39 PM Joshua Colp wrote: > > On Sun, Jun 11, 2017, at 11:34 AM, Michael Maier wrote: > > > > <snip> > > > >>> > >>> PJSIP uses a dispatch model. The request is queued up, acted on, and > >>> then that's it. The act of acting on it removes it from

On Thu, 9 May 2019 22:25:59 +0200, Admin via dovecot stated: >> Am 09.05.2019 um 22:15 schrieb Jerry via dovecot <dovecot at dovecot.org>: >> >> I am trying to find out if Dovecot supports "smtputf8". Obviously, I >> am looking in the wrong places, but I just cannot find a definitive >> answer. >Have a look at this recent discussion: >

Hola compañeros de la lista, qué tal. Estoy haciendo un análisis de componentes principales utilizando las funciones "dudi.pca" (paquete "ade4") y "PCA" (paquete "FactoMineR"). Sucede que al comparar las coordenadas de cada individuo que obtiene cada función, las que corresponden al segundo componente principal tienen idéntica magnitud pero con

On 06/05/2017 at 11:30 AM, Joshua Colp wrote: > On Sun, Jun 4, 2017, at 10:40 AM, Michael Maier wrote: >> On 06/04/2017 at 01:41 PM Telium Technical Support wrote: >>> Just a guess (without knowing about your network), but are the two ends >>> points on public networks and visible to one another? If not the reinvite >>> may be passing an internal (nat'ed)