YATE for CEntOS x86_64

Hi to everyone.

I found the x86 packages for CEntOS 5 here:
http://voip.null.ro/tarballs/yate2/centos5/i386/?C=M;O=D

But somebody knows where I can find the x86_64 packages for CEntOS 5 ?.

Regards.

Maxwell Draven
--
I don't receive/deliver information developed in/for M$-Word,
M$-Excel, M$-PowerPoint, M$-Outlook or similar proprietary formats. I
invite you to read my reasons:
http://www.gnu.org/philosophy/no-word-attachments.html

Re: YATE for CEntOS x86_64

Re: t38 and h323

Hello White Wind,

Not working in H323-SIP ASFAIK because when protocol conversion yate must
know the codec before the conversation and cannot change in midcall.

Cheers

Flying Squirrel

----- Original Message ----- 
From: "WhiteWind" <whitearchey@...>
To: <yate@...>
Sent: Thursday, April 22, 2010 2:49 PM
Subject: [yate] t38 and h323

>
> Does h323chan support fax? I'm trying to send fax from h323 to SIP or vice
> versa but having no success. I see reINVITE from SIP and following
> chan.rtp messages, so Yate replies to reINVITE and sets up new image
> stream, but on h323 side I do dot see any events.

Re: fixed ? codec negotiation media.cpp

Paul,

> We're fixing this on Thursday 22nd.

I cant see it in SVN yet. Or did you mean Thursday 22nd July 2010 ?

Gerry

----- Original Message ----- 
From: "Paul Chitescu" <paulc@...>
To: <yate@...>
Sent: Monday, April 19, 2010 6:26 PM
Subject: Re: [yate] fixed ? codec negotiation media.cpp

> Hi!
>
> We're fixing this on Thursday 22nd.
>
> We don't intend yet to implement cost ordering as the costs set in the
codec
> modules are not correct.
>
> Paul
>
>
> On Wednesday 14 April 2010 05:46:14 am Gerrit Jacobsen wrote:
> > Hello yate team,
> >
> > has the codec negotiation issue been fixed? I cant identify it in SVN.
> >
> > Thanks for your great work.
> >
> > Gerry
> >
> >
> >
> >
> >
> > ________________________________
> > From: Gerrit Jacobsen <g_jacobsen@...>
> > To: Paul Chitescu <paulc@...>; yate@...
> > Sent: Tue, 6 April, 2010 8:35:22
> > Subject: Re: [yate] Bug: codec negotiation media.cpp
> >
> >
> > Paul,
> >
> > "What do you think about creating an intersect between the INVITEd
codecs
> and
> > those set in routing? If the resulting set is not empty that
> > set would be
> > replaced in the answer."
> >
> > Yes, but because there is only one codec chosen for connecting the
incoming
> leg. Yate should take into account the order.
> >
> > IMVHO there should be these steps:
> > 1. Determine the intersect between codecs from the INVITE and those set
in
> formats during routing, ordered by the order of the formats set in
routing.
> > 2. Remove all codecs from the intersect where there is no transcoding
> possible from the already connected outgoing call leg.
> > 3a). In case the intersect is not empty, the top ordered codec from the
> intersect should be used for connecting the incoming leg.
> > 3b) If the intersect is empty then the logic should follow the same as
if
> there was no codec set in formats, ideally picking the same codec as the
> outgoing call leg to minimize transcoding.
> >
> > Also I would consider to hardcode "oformats" as the currently proposed
> > method with setting manually in "call.execute" is hard to
> > understand. I think that formats which are manually set should act as
> filters / intersect for incoming call legs and determine the
> > order of codecs. oformats should determine offered formats in outgoing
legs.
> >
> > Regarding transcoding. There is one more point regarding the transcode
> function in regexroute. Currently transcode orders the codecs in the order
as
> possible transcodings were found,"originating codec1, possible
transcoding1 of
> codec1, possible transcoding2 of codec1, originating codec2, possible
> transcoding1 of codec2, possible
> > transcoding2 of codec2"
> >
> > This function would be more useful if it would order the codecs by
computing
> costs, first the orginal input codecs where there is no transcoding
necessary,
> then codecs with only one transcoding necessary and then double
transcodings.
> >
> >
> > Thank you for your work on the formats issue.
> >
> > Cheers,
> >
> > Gerry

Re: t38 and h323

Yate can change codec in the midcall, because it does so for the sip leg  
of the call, according to logs.

On Mon, 03 May 2010 17:20:31 +1000, G.Jacobsen
<g_jacobsen@...>  
wrote:

> Hello White Wind,
>
> Not working in H323-SIP ASFAIK because when protocol conversion yate must
> know the codec before the conversation and cannot change in midcall.
>
> Cheers
>
> Flying Squirrel
>
>
> ----- Original Message -----
> From: "WhiteWind" <whitearchey@...>
> To: <yate@...>
> Sent: Thursday, April 22, 2010 2:49 PM
> Subject: [yate] t38 and h323
>
>
>>
>> Does h323chan support fax? I'm trying to send fax from h323 to SIP or  
>> vice
>> versa but having no success. I see reINVITE from SIP and following
>> chan.rtp messages, so Yate replies to reINVITE and sets up new image
>> stream, but on h323 side I do dot see any events.
>

--

-- 
Написано в почтовом клиенте браузера Opera: http://www.opera.com/mail/

Re: Core dump

RE: Sangoma Windows Passive recording

Hi Guys,

Does anybody know if Yate 3 supports Sangoma hardware yet?

Thanks

Alec

________________________________________
From: Diana Cionoiu [diana-liste@...]
Sent: 24 March 2010 15:08
To: Alec Glassford
Cc: yate@...
Subject: Re: [yate] Sangoma Windows Passive recording

Hello Alec,

We are just fixing the drivers. You will be able to use Yate 3 from SVN
to do that.

Diana

Alec Glassford wrote:
>
> Hi,
>
>
>
> I am having problems connecting a Sangoma A102 card (6.0.19.0) to YATE
> (2.2), I am trying to build a windows based passive recorder.
>
>
>
> Can you confirm that YATE on Windows will work with Sangoma A102
> cards?  If so do you have any sample configurations?
>
>
>
> Many thanks
>
>
>
>
>
>
>
> *Alec Glassford*
>
> *efuse*
>
> Tel:  0844 847 9707
>
> Mob: 07540 417395
>
> Fax: 0844 847 9708
>
> www.efuse.co.uk <http://www.efuse.co.uk/>
>
>
>
> This is an email from efuse, IT Solutions providers: www.efuse.co.uk
> <http://www.efuse.co.uk/>
>
>
>
> P Save a tree...please don't print this e-mail/ unless you really need
> to/
>
> Its contents are confidential and legally privileged and it is
> intended only for the use of the addressees named above.  If you are
> not an addressee you must not read it and must not use any information
> contained in it nor copy it nor inform any person other than Efuse
> Solutions or the addressees of its existence or contents.
>
> If you have received this email and are not a named addressee please
> delete it and notify support@... <mailto:helpdesk@...>
>
> Please note that Efuse Solutions nor the sender accepts any
> responsibility for viruses and that it is your responsibility to scan
> any attachments.  No contractual obligations may be established on
> behalf of Efuse Solutions by means of email communication.
>
>
>
>
>

Re: Sangoma Windows Passive recording

No Ringback on ISDN incoming

Steps for compiling Yate in windows