Hi Stefan, What we have done is we marked down the MOS scores every 5 seconds and then plotted a graph of MOS vs time. The MOS average value we got for the jitter buffer is around 3.7, we already forgot what's the value we got for adaptive playout, but that should be pretty close. However, our graphs showing the MOS fluctuation for the adaptive playout seems to be a lot larger, where the jitter buffer performs fairly stable. The latency is injected by network simulator, we set it to 100ms. And after all, we still did some human test (i.e. use our mouth and ear) to observe and we think that jitter buffer give the best voice quality. Even with 100ms network latency on each call leg, the overall observed latency is still acceptable (somewhat around 0.5s, but that's subjective, not scientific).
Our deployments always use homogenous DTMF settings. Usually just using RFC2833. As according to our experience, having different UA using multiple DTMF settings is asking for trouble, this is especially true when there is PSTN gateway involved. Because if, for a particular digit, the PSTN gateway got both in-band and 2833 DTMF signals, then the PSTN side will probably detected 2 digits (i.e. a single '3' will become '33'). Another factor is we found that some 3rd party UAs reuse the same timestamp in all the rtpevent packets for a single digit. For example, the rtpevent packets for a single digit '4' would all share the same timestamp, even for the end packets. In that case, if the map is just using the timestamp as key, then the marker packet would be lost. As for the RESYN_THRESHOLD, we believe that's the jitter buffer size. Given the fact that sometimes the network latency could vary as much as 100ms, this is why we change it from 2 to 5. Seamus Stefan Sayer wrote: > Hello, > > o Seamus Huang [09/24/08 04:42]: >> Hi Stefan, >> >> Thanks for the deployment tips. Basically, what we have done is run SEMS >> under valgrind and then fix the problems reported by valgrind. That's >> why most of the fixes are related to memory leak and uninitialized >> member. Just wonder what load balancer are you using? Is that balance, >> LVS or some commercial solution? > we use different solutions, depending on the > application/customer/project/needs; among them hardware loadbalancer, > proxy as loadbalancer and vrrpd for ha, our own (commercial) b2bua as > monitoring loadbalancer (provides ha as well), or application level > load balancing (monitoring and distribution among servers) in case of > calls originated from media server. note that we are not service > provider or telecom ourselves, we provide consulting, solutions and > products (if you are interested in these, you could contact > [EMAIL PROTECTED] or have a look at www.universip.com and www.iptego.com). > > some very simple methods are also described here (but not in details): > http://ftp.iptel.org/pub/sems/fostel_2007_coeffic_sems_load_balancing.pdf > >> >> As for the playout buffer, we read your comment in code and notice that >> you actually recommend the adaptive buffer. We understand how jitter >> buffer works, but not so sure how adaptive buffer works (I meant the >> algorithm). We tried to do some google search on it, but couldn't found >> any material that's in plain English. Therefore, what we decided to do > there is a note in the source: > // > // See: Y. J. Liang, N. Farber, and B. Girod. Adaptive playout scheduling > // and loss concealment for voice communication over IP networks. > Submitted > // to IEEE Transactions on Multimedia, Feb. 2001. > // Online at: > // http://www-ise.stanford.edu/yiliang/publications/ > // http://citeseer.ist.psu.edu/liang02adaptive.html > // > > it predicts the arrival time of coming packets, and scales the voice > if there is too little or too much voice in the buffer. this way the > end to end delay is kept at a very low level, which is important for > conferencing, and b2bua with media relay type of applications. > in SEMS there is an additional algorithm used to keep processing low; > this prevents scaling to be employed too often; this adaptive addition > to the method described by Liang is not documented in english i am > afraid, there is only a german document describing the details. > >> was to run all 3 different playout buffers thru network simulator. The >> simulated network is like the following: >> >> UA <==> SEMS <==> UA >> >> Where the endpoint UAs are actually ixia measuring the MOS. For each >> call leg, we inject a 1-2% packet loss and around 100ms latency on it. >> We also adjust the latency variation (variance) to observe how does the >> MOS vary with it. What we found out is when the network latency is under >> great variance, seems AmJBPlayout is the best. The simulated model is >> based on figures we got from our corporate VPN and our customers (all in >> China). So, this is why we have set our default playout buffer to be >> jitter buffer. Maybe the adaptive buffer is in fact better, if you think >> that we may have missed some steps in setting up the adaptive buffer >> properly, please let us know. > i would be interested in what figures you got for MOS in your tests. > have you also measured the delay? > > Of course you sacrifice some audio quality with the scaling used in > the adaptive playout; the gain is less latency (end to end delay). The > JB buffer does not touch the audio - it is just a fifo buffer with > adapting buffer length. In my tests, I saw that the buffer length only > increased - but maybe I missed something in my test setup. > > I have another question regarding the patch: I see that you changed > the RESYNC_THRESHOLD from 2 to 5 - how did you get to that value? > > Could you explain your patch to the DTMF detector a bit further? I saw > that you removed the arrival time checking of DTMF events. The problem > with this is that DTMF can be sent in multiple ways at the same time > (e.g. in-band + INFO, or in-band + RTP payload etc) - in that case, > with your patch applied, I think you get each key press several times. > > As you can see if you follow the commit logs, I have applied most of > your patches; I have also reworked the shutdown patch quite a bit, so > that now the sessions can handle the server shutdown themselves. That > patch is only applied to trunk version (in 1.0.0 the event handling is > different - I would not like to change that behaviour there). > > Regards > Stefan Sayer > P.S. BTW, we might as well continue discussion about the patch on the > semsdev list >> >> Thanks. >> >> Seamus >> >> >> >> Stefan Sayer wrote: >>> Hello Rui Jin Zheng,hi Seamus, >>> >>> thanks for the patches, this turns out to be quite some fixes :) I will >>> apply them asap. >>> >>> I have never really cared much about stopping the server; normally we >>> run them behind a load balancer, which we can set to send calls to >>> another server, before stopping it. But in other setups it is much >>> better and cleaner with your fixes. >>> >>> About the "AmJBPlayout" jitter buffer: In my tests, this type of buffer >>> always only increased in length, and did not decrease when the network >>> conditions got better. Because of this actually I was about to remove >>> this type of playout buffering; good that you tell me you are using it, >>> so I will not remove it. Have you made test about this, how longthe >>> total end to end delay gets? Adaptive playout buffering is in my >>> opinion a much more sophisticated way, it keeps the playout delay to >>> the >>> minimum, which is a very important factor for perceived connection >>> quality. Of course a little audio quality is sacrificed by shrinking >>> and >>> expanding the voice segments, but after the last fixes in that area, it >>> works quite well in all conditions that we have tested. But of course, >>> everyone should use what suits best their needs. >>> >>> Best Regards >>> Stefan Sayer >>> >>> o Seamus Huang [09/23/08 10:47]: >>> >>>> Hi Stefan, >>>> >>>> Please find the attached patch file. Following is a description of the >>>> changes: >>>> >>>> 1. "connector" member not initialized in AmB2ABSession >>>> 2. Fixed 2 RTP DTMF detection problems: >>>> (i) when quickly punch in same key multiple times, some digits are >>>> lost >>>> (ii) when the network latency variance is large, sometimes one digit >>>> could be deemed as 2 digits >>>> 3. Some members in AmJitterBuffer are uninitialized >>>> 4. Change the default playout buffer from AmPlayoutBuffer to >>>> AmJbPlayout. We did some network simulation test (using netem) and >>>> found >>>> the result of AmJbPlayout performs the best (even better than >>>> AmAdaptivePlayout) in network error conditions (latency, packet loss). >>>> 5. Fix memory leak in AmPlaylist::close() >>>> 6. Fix seg. fault in AmJbPlayout::prepare_buffer() >>>> 7. Fix incorrect handling of rtpevent packet. In AmRtpStream, rtpevent >>>> packets are treated the same as other RTP packets, they are all put >>>> into >>>> a map with timestamp as key. However, some UA may use the same >>>> timestamp >>>> for all rtpevent packets that represents a digit. >>>> 8. Fix memory leak in AmSessionContainer >>>> 9. Fix remote_uri maybe empty out in AmSipDialog >>>> 10. Added support for NOTIFY in BrpcCtrlInterface >>>> 11. Fix memory leak in AmMediaProcessor >>>> 12. Fix memory leak in AmRtpReceiver >>>> 13. Fix memory leak in AmServer >>>> 14. Add synchronization and mutual exclusiveness in sig_usr_un >>>> >>>> I would like to thank my colleague, Rui Jin Zheng for finding out >>>> these >>>> problems and fixing them. He's also the guy who prepare the patch >>>> file. >>>> I am just a translator. ;-) >>>> >>>> Seamus Huang >>>> >>>> >>>> >>>> Stefan Sayer wrote: >>>> >>>>> Hello Seamus, >>>>> >>>>> >>>>> o Huang Seamus [09/22/08 08:54]: >>>>> >>>>>> Hi Stefan, >>>>>> >>>>>> We have did some development work based-on the SEMS engine. >>>>>> During the >>>>>> development, we have fixed some bugs in the SEMS core engine. We >>>>>> would >>>>>> like to contribute these bug fixes back to the community. We have >>>>>> already create a patch (based on SEMS 1.0.0 RC1). What's the >>>>>> proper to >>>>>> do this contribution? Should we just send it to you or what? >>>>>> >>>>> you can send it right to me for review and addition. If oyu want >>>>> you can >>>>> also upload it to the tracker >>>>> (http://tracker.iptel.org/browse/SEMS), or >>>>> post it to semsdev list. >>>>> >>>>> If it is for 1.0.0 RC1 I think it would go into 1.0 branch and trunk. >>>>> >>>>> Thanks a lot >>>>> Stefan Sayer >>>>> >>>>> >>>>>> Seamus Huang >>>>>> >>>>>> >>>>>> >>>>>> ------------------------------------------------------------------------ >>>>>> >>>>>> [EMAIL PROTECTED] We need a name! <http://hk.msn.com/name> >>>>>> >>>>> >>> >> > _______________________________________________ Semsdev mailing list [email protected] http://lists.iptel.org/mailman/listinfo/semsdev
