similar to: meetme + jitter buffer

Hello. I'm having Asterisk 1.6.0.x and trying to solve the issue concerning with a bad quality of voice for incoming SIP calls into the app_meetme. As I know, in my case of calls, jitter buffer is NOT executed on anyone channel. So, after reading Russell Bryant's post ( http://www.russellbryant.net/blog/2007/10/09/asterisk-jitterbuffer-support-for-applications/) I added following scheme

Hi, I've got different customers that may use the same asterisk. Each user can blind-transfer a call to whatever place they want. But of course the transferring side should be billed for it. What can I do to see the difference between the channels here? If there is an A->B call going on, I'd like to know which side did the transfer - but whichever side does it, I get back to context

Hi list I've written a tool that works as a lightweight (standalone - no asterisk) balancer for IAX servers. It's in early development now, but seems to be stable enough and handles couple hundred simultaneous calls with not much latency (SIPp + asterisks tested). It's configurable by listing servers' IPs in iaxproxy-servers file loaded at startup and will keep track of load on

Hi, I've got a problem with rtp keepalives. I'm using basically the same config on 2 hosts, but one of them sends rtp comfort noise when it's on hold, the other doesn't. The only difference I can think of now is that one of the machines is multihomed, but that might be unrelated. rtpkeepalive is set to 2 and I can confirm is by doing `sip show settings`. I've tried all

Hi, I'm having problems with sip remote attended transfer using 2 asterisk boxes (same version, latest 1.4.X). Whenever I transfer from a call from box A to a call on box B, one call leg of the transferring phone is not disconnected (the one that is normally dropped by server side, phone disconnects the other one). The same situation works perfectly with local attended transfer. Is anyone

Hi, I'm trying to access audionativeformat / other codec variables in the hangup handler of a call (with ${CHANNEL(audioreadformat)}), but I get no response. Also 'core show channel ...' doesn't list those variables. Are they always set by asterisk, or only in some scenarios? It's a simple SIP-SIP call with audio passing through asterisk, same codecs on both sides. I see that

Jean-Marc Valin wrote: >>In particular, (I'm not really sure, because I don't thorougly >>understand it yet) I don't think your jitterbuffer handles: >> >>DTX: discontinuous transmission. >> >> > >That is dealt with by the codec, at least for Speex. When it stops >receiving packets, it already knows whether it's in DTX/CNG mode.

[This email is either empty or too large to be displayed at this time]

Jean-Marc Valin wrote: >>OK, I'm actually about ready to start working on this now. >> >>If people in the speex community are interested in working with me on >>this, I can probably start with the speex buffer, but I imagine >>there's going to be a lot more work needed to get this where I'd like >>it to go. >> >> > >And where

> Heh. I guess after playing with different jitter buffers long enough, > I've realized that there's always situations that you haven't properly > accounted for when designing one. For example? :-) > I think the only difficult part here that you do is dealing with > multiple frames per packet, without that information being available > to the jitter buffer. If

Hi, I've been trying to encode a live audio input from the microphone on iOS device using opus. Uncompressed audio recording works fine with http://theamazingaudioengine.com/ Then, when I tried to do encoding, I'm stuck at figuring out why the buffer is empty: static int ec_write_byte(ec_enc *_this,unsigned _value){ if(_this->offs+_this->end_offs>=_this->storage)return

Hi all, I'm trying to get IAX2 trunking between two * boxes and am having extreme difficulty :) What happens is when the sending * server (the one initiating the call) receives the ACCEPT back from the receiving server it immediately replies with INVAL. I've checked the code and it seems to be not matching the accept packet with the relevant item in the iaxs array due to the following

David Feurle wrote: > Thanks for your reply Jean-Marc! > > this was what I had before. > But I decided to restructure it since the thread that plays the sound is > a callback from the sound hardware, more or less an interrupt handler. > For me it seems more reasonable to waste some memory for to save the > decompressed Packet. While I write this I begin to think that it is

On May 3, 2006, at 7:40 PM, Jean-Marc Valin wrote: > >> Yes. Jean-Marc has made the API more similar. >> >> Jean-Marc: Have you looked at the API we have for the >> asterisk/iaxclient jitterbuffer? > > Just did. > >> It's pretty close to what you have now -- the major difference is >> that >> your jb still assumes it can

(Sorry about the delay -- currently attending ICASSP) Hi, Haven't looked at all the details, but what's clearly wrong is that you need to put the *compressed* packets in the jitter buffer and decode them only when you _get() them. Jean-Marc David Feurle wrote: > Hi, > > I am using the JitterBuffer. Since there is not so much documentation I > think I dont use it in a

Are these things possible? 1) Set the local Asterisk jitterbuffer size, but only for a particular connection. I'd like to force Asterisk to use a particularly large buffer in certain cases. Should I expect this to work? [general] jitterbuffer=no register => username:password@parcelfarce.domain.net ;parcelfarce register => username:password@iaxtel.com ;iaxtel [parcelfarce]

Jean-Marc Valin wrote: >>Heh. I guess after playing with different jitter buffers long enough, >>I've realized that there's always situations that you haven't properly >>accounted for when designing one. >> >> > >For example? :-) > > I have a bunch of examples listed on the wiki page where I had written initial specifications:

On May 3, 2006, at 9:54 PM, Jean-Marc Valin wrote: >> Perhaps, but then you need to assume that the jitterbuffer can just >> throw away the data, and that limits how you can use it. In object- >> oriented terms, you might want to pass objects to the JB, and then >> call a destructor on them. In C terms, you may want to allocate >> frames via malloc(), and then call

On May 3, 2006, at 9:12 PM, Jean-Marc Valin wrote: >> We just return a frame with the return value JB_DROP, which tells the >> caller to drop this frame, and call jb_get again. >> >> When the caller is done with the jitterbuffer, it calls jb_getall() >> repeatedly, until it's empty, and then it can discard all the frames. > > Hmm, looks a bit error-prone to

> In particular, (I'm not really sure, because I don't thorougly > understand it yet) I don't think your jitterbuffer handles: > > DTX: discontinuous transmission. That is dealt with by the codec, at least for Speex. When it stops receiving packets, it already knows whether it's in DTX/CNG mode. > clock skew: (see discussion, though) Clock skew is one of the main