similar to: Transcoding OPUS?

Hi! I'd like to ask whether someone did test Opus in real-world VOIP (SIP). Did someone e.g. some characterization about sending faxes or DTFM through Opus? Does it work and if yes for which bitrates? Thanks! -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.xiph.org/pipermail/opus/attachments/20130518/907c5cbf/attachment.htm

Let's say I have two devices configured and the follow call scenarios occur. [100] disallow=all allow=g722&ulaw Polycom phone with g722,ulaw,alaw,g729 [101] disallow=all allow=ulaw Polycom phone with g722,ulaw,alaw,g729 101 dials 100 -> ulaw to ulaw is chosen 100 dials 101 -> g722 to ulaw is chosen Ideally when 100 dials 101 ulaw would be chosen since it is the common format.

Hello, Anyone? I have hard time to believe this is not possible with chan_pjsip. Anyway, may I ask how people handle the following scenario which I imagine should be quite common: - I have internal extensions talk to each other using g722. so their codec setting (with chan_sip now) is "allow=g722,ulaw" - I have carriers trunks that handle ulaw only (allow=ulaw) - calls between

I am unable to get re-invite to work on a new system. Also, unwanted transcoding is occurring on PSTN calls. The new system (FreePBX 2.11.0.37, Asterisk 11.9.0, CentOS 6.5) will eventually replace an old system (FreePBX 2.8.1, Asterisk 1.8.7.2, CentOS 5.8) currently in production. Both systems are on VPS with public IP addresses. Goals for the new system include: HD (g722) connections on

We are getting the following on 1.8.3 and 1.8.4-rc2, HELP! Why is Asterisk unable to transcode to/from ulaw and g722? [2011-04-21 09:51:34] WARNING[22067]: chan_sip.c:6064 sip_write: Asked to transmit frame type ulaw, while native formats is 0x1000 (g722) read/write = 0x1000 (g722)/0x1000 (g722) [2011-04-21 09:51:34] WARNING[22067]: chan_sip.c:6064 sip_write: Asked to transmit frame type ulaw,

Hi! I'm using the opus-tools package from the current Debian (it says it is 0.1.2). The output of opusinfo is strange: $ opusinfo demo01.opus Processing file "demo01.opus"... New logical stream (#1, serial: 0000456a): type opus Encoded with libopus 1.0.1-rc3 User comments section follows... ENCODER=opusenc from opus-tools 0.1.5 Opus stream 1: Pre-skip: 356 Playback

Hello guys, i have a question about a voip gateway we use. I saw those values typing in cli: core show translation g723 gsm ulaw alaw g726aal2 adpcm slin lpc10 g729 speex ilbc g726 g722 slin16 g723 - - - - - - - - - - - - - - gsm - - 2001 2001 6000 2001 2000 16000 - 34002 - 6000

Hi all, I've an asterisk 1.2.5 running very well for about a 9 months, and suddenly i cannot dial extensions 4XXX from SIP Phones. Now comes the wired stuff... I can dial this extensions from IAX phones as well as from Analogue extensions connected to our legacy pbx, that is installed on front of asterisk. So : Zapata Calls to SIP extensions 4XXX - OK IAX to SIP 4XXX-OK SIP to SIP 4XXX -

Hi All, I am trying to get the opus codec working with linphone. I followed the instructions... This shows me its loaded core show translation paths opus --- Translation paths SRC Codec "opus" sample rate 48000 --- opus:48000 To g723:8000 : No Translation Path opus:48000 To ulaw:8000 : (opus at 48000)->(slin at 48000 )->(slin at

Hello, After I have re-read the "PJSIP Advanced Codec negotiation" document, it occurred to me that the desired behavior should actually happen automatically, just due to the codec negotiation logic, but it looks like asterisk doesn't actually follow the described logic which is likely a bug. Can you please follow with me through a simple sip call and see if I'm missing

Under 1.4.35 I get this message printed MANY times [May 3 21:41:21] WARNING[21567] chan_sip.c: Asked to transmit frame type 4, while native formats is 0x1000 (g722)(4096) read/write = 0x1000 (g722)(4096)/0x1000 (g722)(4096) [May 3 21:41:21] WARNING[21567] chan_sip.c: Asked to transmit frame type 4, while native formats is 0x1000 (g722)(4096) read/write = 0x1000 (g722)(4096)/0x1000

Hello! I'm facing completely choppy sound. The wireshark trace shows, that there are a lot of codec changes without any trigger (means no options or reinvite or any other package). Background: The call is initiated by asterisk and is received by the same asterisk conference room via Phone extension -> asterisk -> provider A -> provider B -> asterisk. Asterisk initially sends

Hi, I was able to use Unsniff to validate that the incoming 20 byte payloads of audio from the downstream IAX2 trunk was definitely G.729a whilst Asterisk 16.13.0 transcodes to G.711a unnecessarily. Media is confirmed as having been negotiated as g729 on all four streams. Nuance with this call is that it's from a WebRTC client which doesn't transmit any audio, could this be influencing

Hi! I want to tell asterisk to simply pass-through any codecs that my phones support. I have to use codecs that are not popular and implemented by a third-party, asterisk has nothing to do with them. I've made a test with g722 (that asterisk doesn't support), i've set all my two snom 300 phones to support only g722 and asterisk declined the sip invitation. That is bad for me. Is it

Hello Michael, you are referring to the following behavior - did I get it correctly?: outbound broken: asterisk offers g722 / g711 to provider (callee), callee answers g711. Asterisk now transcodes between caller and callee (g722 <-> g711). inbound works: call from provider: g711 -> asterisk drops g722 and passes g711 to internal callee -> no transcoding. As far as I know,

Hello, I have some problems to use G722, when my client sent an invite request to asterisk using G722/16000 codec asterisk respond with G722/8000 codec. I dont know exactly if Asterisk supports G722/16000 codec?? If yes how can I activate It?? Thanks. Rachid. Below wireshak trace:

I have Polycom phones that support the g722 codec. Adding allow=g722 to the [general] section of sip.conf works great and I can make calls between the phones using g722. However Asterisk is negotiating g722 for calls going out my voip provider and transcoding these to ulaw. In sip.conf for the provider I have deny=all and allow=ulaw. This can cause potential audio degrading and wastes cpu cycles.

We want to record inbound channels at 16kHz, but send only 8kHz to our peers. I've set our default profile in sip.conf to disallow all but g722, and the peers disallow all but ulaw. We have a proxy in front of Asterisk that is configured to disallow all but G722 also. My test calls show inbound to the proxy is recorded at 16kHz, inbound in Asterisk is only 8kHz, and the peers receive 8kHz. So

Hi Users, I was wondering if someone of you have the same thing on CentOS 64x? asterisk01*CLI> core show translation Translation times between formats (in microseconds) for one second of data Source Format (Rows) Destination Format (Columns) g723 gsm ulaw alaw g726aal2 adpcm slin lpc10 g729 speex ilbc g726 g722 siren7 siren14 slin16 g723

Hello, I am working with several SIP projects that use g722, or are trying to do so, with pjsip library. According to pjsip team's interpretation of g722, it works with 14bits PCM for input/output, so pjsip basically 'converts' the audio sample from 16 bits to 14 when encoding and vice-versa. Some implementations don't do 16<->14 bits conversion, so when pjmedia talks to