Author |
|
support Administrator
Joined: January 26 2005 Location: United States Posts: 1666
|
Posted: December 13 2008 at 11:35am | IP Logged
|
|
|
Hi George,
Forget my last question regarding the wireless network.
IMPORTANT:
What equipment is being used at the test server? If you do not know, please find out. Its very important. Get the name of the server equipment in use and version info for me. Also find out if they have comfort noise generation enabled all the time.
From the RTP log file you sent to us:
I now see what is occurring in the RTP media streams and what is causing the “bobo” noise.
All the G729 calls are being set up properly. No comfort noise (CN) is being negotiated in the call setups. It appears however the equipment at the test server location is on occasion sending ½ frame G729 packets and then immediately sending single octet comfort noise RTP packets. It SHOULD NOT be doing this based on how the calls are being negotiated.
Also, RTP payload 19 is being used for CN RTP packets. This is wrong. CN RTP packets should have a payload type of 13 as per the current RFC. Payload 19 is not in use anymore. Tell the owner of the server to get this fixed or get an equipment upgrade.
Regardless of why the server is sending these ½ frame G729 and CN packets, I do want the media engine to be able to discriminate against the reception of such received data – especially if it goes against what has been negotiated in the call setup.
The rule it this: If specific call characteristics are not specified via the SIP SDP during call setup, then such things like CN and other features should not be in use. If I were you, I would contact whoever the test server belongs to (is it yours?) and tell them to configure it properly or upgrade the equipment. There is no excuse for statically configuring VOIP equipment so that static call settings override per call session setup.
In order to remove any noise issues from your VOIP app, you do not need an update from us immediately. The technique I posted above regarding filtering RTP packets will work and you will have clean received audio. Use the “filtering” technique until we can get you an official update.
Finaly:
For some reason we do not experience the “bobo” noise when I call your server. Any thoughts on why this may be?
I would like to be able to test the media engine changes before we get you an engineering release. I am testing using the IVR server at sw2.sp.ring-fone.com and calling extension 1008.
I will get back to work on this issue Monday.
Thanks for your help,
Randal
|
Back to Top |
|
|
speedvoip Vetran
Joined: August 07 2008 Location: Canada Posts: 156
|
Posted: December 14 2008 at 9:35pm | IP Logged
|
|
|
Hi Randal:
you can try sw3.sp.ring-fong.com for testing. Meanwhile I have not used wireless connection for accessing server.
On the other hand, I have successfully filtered worng packets which result in Bo Bo noise at my application.
|
Back to Top |
|
|
support Administrator
Joined: January 26 2005 Location: United States Posts: 1666
|
Posted: December 15 2008 at 10:39am | IP Logged
|
|
|
George,
IMPORTANT - Please Answer:
What equipment is being used at the test server? If you do not know, please find out. Its very important. Get the name of the server equipment in use and version info for me. Also find out if they have comfort noise generation enabled all the time.
No wireless access being used – OK, understood.
You >>>
On the other hand, I have successfully filtered worng packets which result in Bo Bo noise at my application.
<<< Support
Hmm... That should not be based on the RTP content. I will be working on this more today and should have some answers possibly by the end of the day. Lets wait and see what I come up with.
Thanks,
Randal
|
Back to Top |
|
|
support Administrator
Joined: January 26 2005 Location: United States Posts: 1666
|
Posted: December 18 2008 at 4:19pm | IP Logged
|
|
|
Hi George,
The media engine has been updated to handle bad RTP packets having the wrong payload ID and the wrong number of bytes. With these improvements, audio quality will definitely be improved in the product.
I think at this point the conservative thing to do is to re-evaluate the “bobo” noise issue you reported and move forward from here.
I think this is important because as I analyze the data I have received from your call testing, I still am not 100% sure what exactly the “bobo” noise is. One of the reasons this confusion is occurring on my part is because the raw G729 data for your test call contains other noise artifacts and that is making the analysis difficult.
The best possible thing you did for us was to capture the RTP packet hex dump information from the media engine. With that data in hand, I can actually preload a media engine phone line RTP receiver and use the RTP packets from you as if they were real-time call media. Nice. The result I am experiencing from your data capture is the proper audio behavior/quality.
I have taken your raw RTP G729 frames and have also processed them through other G729 implementations we use for comparison and RTP-inter-op from other vendors. We do this to compare sonic quality of our G729 codec implementation to others that are commercially available. The other tested G729 codecs all process your call data the same way – with the same sonic output quality/behavior.
The reason I am stating all of this is because we do not have time to chase “red herrings” or problems that do not exist.
Another issue is whenever I use your test servers to verify any bad RTP media packets, I do not receive them. I also do not find anything untoward in your call media. Hmmm… strange.
As soon as you overcome your current issues, we can complete this “bobo” issue - last.
However, before we move on, we will need you to use the v6.0.0.5 engineering release media engine for us to test with. We need to test with the latest media engine.
Here is what I need from your group to be able to move forward:
1)
Someone on your team needs to make a test call that experiences the “bobo” noise. The “bobo” noise should be present and easily discernable.
2)
For the above call, I will need a new media engine RTP packet hex dump log. You know how to do this.
3)
I also want corroborating data from Wireshark. That way I can compare a network trace with the media engine’s RTP receiver hex dump data.
4)
I don’t care what tools you use or how you do it, but I need to know where in the call’s “sample time” the “bobo” noise is occurring. If you can get me to within a few seconds either way of where “bobo” occurs, then I can focus on that call data and lower my debug and analysis time.
Finally:
I have asked you other questions in this thread. Why haven’t you answered them?
This thread is getting too long. If you want to repost, start a new thread titled “Bobo Noise” and we can continue from there.
Thanks,
Randal
|
Back to Top |
|
|
speedvoip Vetran
Joined: August 07 2008 Location: Canada Posts: 156
|
Posted: December 19 2008 at 11:56am | IP Logged
|
|
|
Hi Randal:
I will collect your questions carefully and give detailed answers one by one from begin posted at new thread titled "Bo Bo Noise" per what u want.
yesterday it is too late, so go to sleep. Therefore no reply your post ASAP. Sorry about it.
As alternative testing, I will be active to proceed with v6.0.0.5 testing.
Pls give me product image via Email or my FTP server.
Thanks
|
Back to Top |
|
|
support Administrator
Joined: January 26 2005 Location: United States Posts: 1666
|
Posted: December 19 2008 at 12:56pm | IP Logged
|
|
|
Hi George,
Very good. The “bobo” noise issue will be the next item we resolve.
1)
I will upload to your FTP server v6.0.0.5 “Engineering Release” of the media engine. We will use this as the basis for further noise testing. We can’t use an official product image because it has not been built yet. Using the engineering release is easy. Take the LMEVoip.dll, LMEVoip.lib and SipTelephony.h files from the engineering release and replace the ones you currently have.
2)
I will wait for you to create a new support forum thread containing additional info. Then we will be able to solve “bobo”.
Thanks George,
Randal
|
Back to Top |
|
|