* You are viewing Posts Tagged ‘audio’

Monitor does not work well (little cuts in the audio file)

I have been testing MixMonitor and Monitor to record some calls in Asterisk and I have noticed that MixMonitor works fine whereas in the Monitor files of the 2 separate channels, we can find little cuts of the audio. We are using U law codec and wav files for the recording.
Anyone have suffered the same problems. It is that Monitor does not work well. It is another way to record the 2 legs of the call separately by using MixMonitor?

Este mensaje se dirige exclusivamente a su destinatario. Puede consultar nuestra pol?tica de env?o y recepci?n de correo electr?nico en el enlace situado m?s abajo.
This message is intended exclusively for its addressee. We only send and receive email on the basis of the terms set out at.

strange delay behaviour in SIP call with same codec

> Hello,
> I have a strange audio delay behaviour when placing a call between two
> SIP devices using the same codec.
> In my example, I have two devices forced to use GSM codec.
> When placing a call, the first ~9sec have no audio, then the audio
> starts trasmitting.
> If I force one phone to use GSM and the other ULAW/ALAW, everything
> works fine.

If I had to guess, I’d say that you don’t have canreinvite/directmedia=no in sip.conf and there is possibly a NAT between the phones and Asterisk. When they have the same codec and directmedia is enabled, the phones will try to communicate directly to each other. It sounds like it is taking a while for firewalls to allow this traffic through (since both phones have to send packets out to the other before the whole is opened up in many setups). When the codecs are forced to be different, the media will go through Asterisk to get to the phones instead, alleviating your issue.


Asterisk in the amazon cloud

I’m relatively certain this is a silly question, but is anyone willing
to share their experience with asterisk in the amazon cloud?

Does it work? Or do timing issues mess with audio?


Can’t get video on one server of 4


we have 4 asterisk, versions are 1.4.35 1.4.36 and 1.4.42 One
GrandStream GXV3000 is used for the tests. He is registered to asterisk asa well as 1.4.35. Calling echo test is OK on both servers,
get audio and video. Calling echo test from asterisk 1.4.36 bye a SIP
trunk from both others servers is also working well.

What fail, is video on echo test from asterisk 1.4.42 using SIP trunks:
we have audio but no videobeside the fact that video codec are
negociated as shown below.

All servers are on public IP. Here is a debug from a call from server
running 1.4.35 asterisk to the 1.4.42 one:

< ------------->
[2011-07-05 16:08:14] VERBOSE[11535] logger.c: — (14 headers 18 lines)

No audio after a reinvite changing codec —-> with SIP DEBUG!!

On Fri, Jul 1, 2011 at 12:05 PM, Larry Moore wrote:

> **
> On 28/06/2011 6:59 PM, Matteo Campana wrote:
> Hi Larry,
> I have the SIP debug taken from asterisk.
> In this debug: —> IP SIP PROXY
> —> IP UAC (Linksys SPA 962)
> —> IP ASTERISK to connect to the
> provider
> The SIP debug is available at this link: http://pastebin.com/9DrFDmeC
> You mention you have an SPA962, I expect the configuration will be the same
> if not similar to an SPA942. It would be worth checking what your “Symmetric
> RTP” setting is, you can find it listed in the RTP Parameters section under
> the SIP section of your phone http://
> /admin/advanced.
> If it is set to “no” set it to “yes”.
> Larry.
Hy Larry,
I have tested with “Symmetric RTP = yes” in SPA962, but with same results.


No audio after a reinvite changing codec

Hi all,
we have a problem with a reinvite sent by our SIP provider to change audio
codec due to the recognition of a fax tone.
After that the SIP call session has been established (INVITE and 200 OK) we
have the following codec situation:

g711 < ----------------------> g711 | g729
< ---------------------------> g729

After a while, we have the reinvite sent by the SIP provider with g711 in
the SDP.
So asterisk need to change audio codec from g729 to g711 and correctly we
see on debug the following line:
“Oooh, we need to change our audio formats since our peer supports only
g729″ and asterisk send back 200 OK to the provider.
At this point we have one way rtp audio:

g711 ———————-> g711 | g711