| Author |
|
will
Junior
Joined: February 07 2005
Location: Canada
Posts: 48
|
| Posted: February 15 2006 at 7:41pm | IP Logged
|
|
|
Hi, support,
we have installed the upgraded engine, it is perfect.
we noticed you have put g729,g729a and iLBC in it, here is a question, do those codecs have to be loaded by the user using the option menu? could the engine detects automatically which codecs to load? and since g729 and iLBC are both low bits codecs, how to determin which one to use when the user is using narrow band.
since DTMF cannot be sent by g729, the application needs to switch from g729 to g711 to send DTMF, but to do switching, the phone line has to be shut down first, so how to handle those things, your idea is appreciated.
regards,
will
|
| Back to Top |
|
| |
support
Administrator
Joined: January 26 2005
Location: United States
Posts: 1666
|
| Posted: February 16 2006 at 10:31am | IP Logged
|
|
|
Hi Will,
Thanks for the feedback regarding your recent upgrade. Those are nice words to hear. I will pass your comments along to the developers.
Codec Selection - Outgoing calls:
Take a look at the new SetAudioMediaFormats() API procedure in the software developer's reference. This proc will allow you to specify what codecs will be offered to the far end of the call when your app makes outgoing phone calls. By calling the SetAudioMediaFormats() proc, you can specify what codecs will be used and in what order.
Of course, the actual codec that gets used for the call will also depend on what codec the far end (receiving end) actually wants to use. The far end will respond with one of the codec types that was specified in the transmitted INVITE. Take a look at the developer's reference. It shows a typical multi-codec INVITE and the "200 OK" SIP response.
Codec Selection - Incoming calls:
Again, the API procedure you want to use is the SetAudioMediaFormats() proc. The order of the codec list you specify to this API proc will indicate to the Media Engine what codecs should be accepted and in what order. When your application (media engine) receives an incoming call, it looks at all the codecs that are offered in the received INVITE. It then uses its configured codec list to locate the preferred codec (highest priority codec).
In General:
The SetAudioMediaFormats() API proc is normally called once during application initialization but can be called prior to making each phone call on a per line basis. Normally what you want to do is to enable all the available codecs and just let the media engine worry about everything. When making a call, the far end will determine what codec will actually be used from the list of codecs that were offered. If the far end is being called through a bandwidth constricted network connection, the far end better have one of its G729 or iLBC codecs enabled so the call takes as little bandwidth as possible.
DTMF:
This issue is a real pain and we are working to come to a unified solution. At this point in time, there are 3 ways DTMF can propagate the network: In-band, using SIP Info Messages (Cisco) and RTP payload type as per RFC2833.
At the moment, all customers that require DTMF must resort to in-band methods using uLaw, aLaw or PCM codecs. We understand the issues associated with an in-band only solution.
The most likely path we will take is to offer a unified API that will eventually encompass all three methods. If we do anything, we will most likely pursue SIP INFO messages for conveying out-of-band DTMF for it appears to be more widely supported by other software and devices. Any customer feedback you want to give regarding DTMF is always welcome.
Excellent questions Will.
Repost as required.
Support
|
| Back to Top |
|
| |
will
Junior
Joined: February 07 2005
Location: Canada
Posts: 48
|
| Posted: February 28 2006 at 2:23pm | IP Logged
|
|
|
Hi, support,
sorry to bother you with this question, this question is actually for our marketing guys to confirm the DTMF infeasibility upon G729 codecs.
what I have tried to confirm to them is: with the upgraded engine, althought the G729 is available, the DTMF cannot be sent by G729, the only way to send DTMF out is using G711 in in-band mode, and if a call has been established upon G729, the engine cannot load the G711 to send DTMF out without shutting down the call connection first, if the call connection has to be shut down, there is no sense at all to send DTMF.
If I understood correctly, pls confirm this then I can show the answer to convience the marketing guys,
thanks,
will
|
| Back to Top |
|
| |
support
Administrator
Joined: January 26 2005
Location: United States
Posts: 1666
|
| Posted: March 01 2006 at 1:18pm | IP Logged
|
|
|
Will,
G729 and In-band DTMF:
G729 is based on conjugate structure-algebraic code exited linear prediction. Also known as CS-ACELP. As with all CELP based algorithms, CELP is a "lossy" compression technique. Any encoder-decoder scheme that is "lossy" introduces distortions in the signal being encoded-decoded.
What this means is that when an input sample block is encoded and then decoded, the output sample block is not the same as the original input sample block we started with. For band limited speech signals, this lossy approach is acceptable and the distortions caused by the CELP encode/decode are not predominant in the perceived speech signal.
When DTMF is transmitted in-band using a "lossy" type codec, the actual frequency content that makes up the DTMF signal gets distorted. This distortion of the DTMF signals can cause DTMF to not be decoded properly by a receiving DTMF decoder.
You>>>
The engine cannot load the G711 to send DTMF out without shutting down the call connection first, if the call connection has to be shut down, there is no sense at all to send DTMF.
<<<Support
You are correct. The VOIP Media engine will not allow you to renegotiate the call's codec once the call has connected.
Support
|
| Back to Top |
|
| |
|
|
Active Topics 
Member List 
Search 
Help 
Register 
Login
LanScape Support Forum -> LanScape VOIP Media Engine™ - Technical Support
Topic: can the engine switch to different codecs by itself?
