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…
> 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…
we have 4 asterisk, versions are 1.4.35 1.4.36 126.96.36.199 and 1.4.42 One
GrandStream GXV3000 is used for the tests. He is registered to asterisk
188.8.131.52 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…
On Fri, Jul 1, 2011 at 12:05 PM, Larry Moore
> On 28/06/2011 6:59 PM, Matteo Campana wrote:
> Hi Larry,
> I have the SIP debug taken from asterisk.
> In this debug: 184.108.40.206 ---> IP SIP PROXY
> 220.127.116.11 ---> IP UAC (Linksys SPA 962)
> 18.104.22.168 ---> IP ASTERISK to connect to the
> 22.214.171.124 --> IP PROVIDER
> 126.96.36.199 --> IP ASTERISK
> The SIP debug is available at…
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: UAC ASTERISK UAS | ASTERISK UAC
g711 < ----------------------> g711 | g729
< ---------------------------> g729
rtp After a while, we have the reinvite sent by the SIP provider with g711 in
So asterisk need to change audio codec from g729…
On Fri, May 27, 2011 at 05:30:02PM +0000, firstname.lastname@example.org wrote:
> What is better more cores (eg. 2x quadcore) or more CPU speed for a server
> that handle a lot of of Meetme Concerences with hundreds of concurrent G711
> alaw Channels (no transcoding) ?
> in my opinion, more cores are better, because Asterisk ist multithreded and
> each channel has a good chance to distribute to the cores.
> is that right or what do you think? I don't have an answer for you…
Can anyone let me know how I can enable video (h.263) on SIP, but if a
video call is passed over IAX, it will remove the video and pass the
audio only. What I tried was: SIP - videosupport=yes
- allow=h263 IAX - disallow=all
What appears to occur is that the SIP call negotiates h263 video, and
when passed over IAX, the h263 frames are passed, and are also
accepted at the far end which also does not have a video codec
> My outgoing FXO calls are answered but have no audio in
> either direction if I have callprogress=no in
> chan_dahdi.conf. If I change to callprogress=yes then the
> audio returns. My chan_dahdi.conf file is listed below. Can
> anyone point-out why callprogress=no isn't working?
I'm assuming your telco doesn't support line reversal on answer, you need to
set answeronpolarityswitch=no Hope that helps
My outgoing FXO calls are answered but have no audio in either direction
if I have callprogress=no in chan_dahdi.conf. If I change to
callprogress=yes then the audio returns. My chan_dahdi.conf file is
listed below. Can anyone point-out why callprogress=no isn't working? #cat /tmp/a
sendcalleridafter = 1