On Mon, Jan 30, 2017 at 3:32 PM, Matthew Jordan <mjor...@digium.com> wrote:
> > > On Mon, Jan 30, 2017 at 3:22 PM, Matt Fredrickson <cres...@digium.com> > wrote: > >> Hey Michael, >> >> First off, thanks for taking the time to express some of your thoughts >> and concerns to the asterisk-dev list. I'll keep my reply to your >> email inline below. >> >> On Mon, Jan 30, 2017 at 4:13 AM, Michael Maier <m1278...@allmail.net> >> wrote: >> > Dear developers, >> > >> > I've been redirected to this mailing list by Joshua Colp during fixing a >> > one way audio bug[1] to discuss another solution as provided in the fix. >> > >> > Background: >> > - A lot of people complain about bad VoIP call quality compared to the >> > old POTS / ISDN devices. What do they mean from a technical point of >> > view: High latencies (resulting in echo), digital sound because of "bad" >> > codecs, general quality loss during transcoding and many other reasons >> more. >> > - In Europe, HD audio is being adopted slowly. This means, more and more >> > UAs can natively handle HD codecs like g722. But they must be downward >> > compatible at the same time for older UAs, which just speak alaw (like >> > the old POTS devices e.g. or UAs which are not yet HD capable). >> > Therefore, they advertise at least two codecs: g722 and alaw (mostly >> > plus some more like ulaw or some other codecs). >> >> So there are multiple reasons why you could be seeing reportedly bad >> call quality that come to my mind: >> >> 1. Transcoding - changes the audio, but typically doesn't make things >> sound *too* bad. Obviously it is codec dependent as to how bad it >> sounds afterwards, but most modern codecs aren't terrible for speech >> replication and encoding. Usually this is not where call quality >> problems are noticed. >> >> 2. Packet loss and jitter related problems. In an ISDN network, there >> is a guaranteed real time audio channel for transporting media. As >> long as the data pumps on the transmit and receive side are working >> properly, you should hear almost no audio quality issues. VoIP tries >> to transport real time audio over a non-guaranteed transport channel. >> This sometimes causes bad audio quality issues due to packet loss, >> packet reordering, or extreme packet delays. Enabling Asterisk's >> jitter buffers typically improves many problems that arise due to >> this. They are typically *not* enabled by default and so must be >> explicitly enabled. >> >> I'm hoping you already have dived into your problem to look at both >> the above elements, and have confirmed that you are not dealing with >> the second problem instead of voice mutation due to the first problem. >> Usually you can track the second problem by doing packet captures of >> the voice conversations in question as well as look at RTCP >> statistics. >> >> > What does this mean to Asterisk? >> > My conviction is, that Asterisk shouldn't make things even worse when >> > handling calls / codecs by forcing unnecessary transcoding, which >> > unnecessarily harms call quality. Next point of unnecessary transcoding: >> > it unnecessarily steals system resources from the machine asterisk is >> > running on. >> > Asterisk should harm each call it handles and the underlying machine as >> > little as possible. >> > >> > Therefore I would like to see a (switchable) feature, that asterisk / >> > pjsip always tries to primarily advertise codecs, which are supported by >> > both UAs and remove those codecs, which are not supported by one of the >> > UAs. This prevents unnecessary transcoding. >> >> This actually would be a really neat thing for Asterisk to be able to >> do. Last time I looked at it, there are quite a few challenges in >> making it happen. Asterisk is designed to be a back to back user >> agent, and it inherently is designed to terminate media and codecs >> individually with each leg in question, but not necessarily together. >> It "makes things work" on each leg separately, based on the allowed >> codecs for each endpoint. >> >> This is a needful behavior since many times an Answer() has already >> occurred and negotiated the codec capabilities for a call and most >> dial plan applications assume a call needs to have media fully >> negotiated in order to interact on the channel. >> >> For the simple case where your dial plan doesn't do any intense media >> interaction with a channel and simply Dial()'s out, a significant >> portion that doesn't work right now is that the codec information from >> the 200 OK received from the outbound channel is not passed back >> through to the inbound channel - I'm assuming that's what you're >> referring to. Hopefully Josh or Mark will correct me if my memory is >> off. >> >> > We've looked at doing this several times. > > The last time I gave that a shot I more or less had it working, and then > broke myself (and my patch) on the rocks of Local channels. Trying to get > Local channel chains to respect the codecs down a chain (generally 3+ is > enough to trip errors) is a non-trivial operation. When setting up the call > you more or less can control the situation - the codec preferences are > passed down the chain via ast_request. However, when things are coming back > in the other direction, you don't have an easy reference to the channel > that created you. It can involve reaching across bridges and local channel > bridges, which is dangerous. Both are prone to error and deadlocks. Holding > a reference to your creator isn't safe, as the creator can be masqueraded > away (in really weird situations). The other option is to pass the > information down in a frame, but now you can't guarantee much, as that's an > asynchronous operation. > > In transcoding situations, you also have to pick where in that chain you > choose to do transcoding - which is not always easy to figure out. > > Things get challenging as well when you have a multi-party bridge involved > at all - either when a dialed party has to be placed into a multi-party > bridge or when you have a chain of Local channels dialing someone and the > far end of the Local channel chain is already in a multi-party bridge. > > Generally, this is an architectural limitation of Asterisk that - while > not impossible to craft a solution for - is far harder than it may seem > when you're only thinking of two-party calling with non-Local channels. > How hard do you think it would it be to limit the attempt to the 90% use case of a call coming in on one channel and causing an originate going out on another channel? Simple PBX scenarios? No answer in the middle, no early media, etc. > > -- > Matthew Jordan > Digium, Inc. | CTO > 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA > Check us out at: http://digium.com & http://asterisk.org > > -- > _____________________________________________________________________ > -- Bandwidth and Colocation Provided by http://www.api-digital.com -- > > asterisk-dev mailing list > To UNSUBSCRIBE or update options visit: > http://lists.digium.com/mailman/listinfo/asterisk-dev > -- George Joseph Digium, Inc. | Software Developer 445 Jan Davis Drive NW - Huntsville, AL 35806 - US Check us out at: www.digium.com & www.asterisk.org
-- _____________________________________________________________________ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev