| Author |
|
jmatthewsr
Junior
Joined: April 09 2008
Posts: 40
|
| Posted: April 16 2008 at 10:16am | IP Logged
|
|
|
Using the conference server example app, with 2 UA's in a conference (Aastra and grandstream), the Aastra has silence suppression on (RFC3389). The grandstream hears clicking/popping when the CN packets arrive from the aastra. I have a wireshark trace of the session if needed. Audio formats tested including mulaw to mulaw and g729 to g729.
-justin
|
| Back to Top |
|
| |
support
Administrator
Joined: January 26 2005
Location: United States
Posts: 1666
|
| Posted: April 16 2008 at 1:04pm | IP Logged
|
|
|
Hi Justin,
Thanks for your post. At this moment, the media engine does not support RFC3889 comfort noise RTP payloads. If the conference server sample app receives these RTP payloads, they will be interpreted as normal audio RTP packets and the resulting audio will sound like crap (clicks, pops, etc). The way to remove this noise would be to modify the sample code to filter out all CN RTP packets on a per phone line basis.
We have made a note to support RFC3889 CN in a future release.
One thing that is strange is that the Aastra UA is still using CN when in fact, the media engine will not negotiate the use of CN in the SIP “200 OK” response that is sent back to the Aastra UA. In other words, the Aastra UA “should not be” sending the media engine sample app CN RTP packets… but apparently it still does.
It is our understanding that a UA should not send CN RTP packets unless it gets fully negotiated in the call setup. For example, the Aastra UA should not send CN packets unless the media engine includes an SDP media attribute specifying CN acceptance. See the red SDP line below:
Code:
m=audio 49230 RTP/AVP 101 102
a=rtpmap:101 G7221/16000
a=fmtp:121 bitrate=24000
a=rtpmap:102 CN/16000
|
|
|
If you have a different understanding, we would like to hear your thoughts.
Thanks,
Support
|
| Back to Top |
|
| |
jmatthewsr
Junior
Joined: April 09 2008
Posts: 40
|
| Posted: April 16 2008 at 5:14pm | IP Logged
|
|
|
Thanks. It is commond for UA's to not setup the CN codec in the SDP and just assume that payload 13 is comfort noise.
How does the media engine handle discontinous rtp ( in regards to this CN packet deletion and DTX in general)?
RFC3389 detection is not a complicated process, I would really like to see this included in an upcoming release. Processing the audio packets is what we are trying to avoid in using this engine :-). Thanks.
-justin
|
| Back to Top |
|
| |
jmatthewsr
Junior
Joined: April 09 2008
Posts: 40
|
| Posted: April 16 2008 at 6:04pm | IP Logged
|
|
|
In thinking about this a bit more, what happens if a "bad" UA sends other RTP packets with a different payload type? I would think that the media engine would drop packets for which the payload type was not negotiated in the SDP.
Note that I am not looking for a full-blown CNG generation based on 3389, just detection.
thanks!
|
| Back to Top |
|
| |
support
Administrator
Joined: January 26 2005
Location: United States
Posts: 1666
|
| Posted: April 17 2008 at 4:34pm | IP Logged
|
|
|
Justin,
At the moment, the media engine will process those “bad” RTP packets. You can however filter out anything from the RTP streams you want using the raw RTP packet access.
We have made a note of this and may want to add a new API procedure that gives the app control over what to do with garbage RTP packets.
Support
|
| Back to Top |
|
| |
support
Administrator
Joined: January 26 2005
Location: United States
Posts: 1666
|
| Posted: April 17 2008 at 4:44pm | IP Logged
|
|
|
Justin,
Forgot to answer the other questions….
<<< You
How does the media engine handle discontinuous rtp ( in regards to this CN packet deletion and DTX in general)?
Support >>>
We use simple volume ramping of the audio data if discontinuities are detected. This way pops and other discontinuous noise artifacts are kept low.
<<< You
RFC3389 detection is not a complicated process, I would really like to see this included in an upcoming release. Processing the audio packets is what we are trying to avoid in using this engine.
Support >>>
Agreed. When you get a free moment (is that possible? :) ), maybe you can elaborate a bit more on your requirements. More info is better than none. We have put this on the “to do” list. We like receiving enhancement requests. :)
Good job,
Support
|
| Back to Top |
|
| |
Active Topics 
Member List 
Search 
Help 
Register 
Login
LanScape Support Forum -> LanScape VOIP Media Engine™ - Pre-Sales Technical Support
Topic: clicking sound in conference app with CN
