Quote:
Originally Posted by Cris77
|
If I'm not mistaken, IPKall only did ulaw/G711u for the longest time. And even though they have now added other CODECs, I think IPKall will still always pick ulaw/G711u if/when that is an allowed/supported CODEC on the receiving end (i.e. the IPKall web site doesn't give you any CODEC choice/setting for your IPKall account). You might want to check in their support forum (it's over on Voxilla.com at
IPKall Support Forum - Voxilla VoIP Forum ) to make sure, but I think that's IPKall's behavior.
Now, here's where I think things are getting "interesting":
Even if you have your adapter setup to not support ulaw/G711u (for example, because you don't have enough bandwidth), it's still the case that the voxalot.com proxy (as well as the more specific us.voxalot.com, au.voxalot.com, and eu.voxalot.com addresses) support ulaw/G711u even if/when your adapter has that CODEC turned off (for example, because you don't have enough bandwidth).
So when IPKall connects to VoXaLot, it likely does so via ulaw/G711u (because VoXaLot itself will support those CODECs), and then VoXaLot will see that your adapter doesn't support G711u and "transcode" the CODECs. And since you (currently) have no way to control the CODEC that IPKall uses to contact VoXaLot, you also don't appear to have any way to control the "transcoding" issue.
And the above analysis is assuming my memory is correct, and IPKall still always picks ulaw/G711u, when that CODEC is supported by the remote proxy. If (instead) IPKall were to pick one of the other CODECs that VoXaLot supports, than the situation could be even worse. For example, imagine how lousy of sound you would get if/when IPKall picked G723, forcing VoXaLot to transcode G723 to G729!
Hmmm...
What this situation is really calling for IMHO is a general "CODEC list" for our VoXaLot accounts, that has the same format/purpose as that CODEC list we have for our specific providers. However, in the case of our general (account) provider list, it will control which CODECs VoXaLot responds to (and in which order we "prefer them") when someone makes a call to
our_voxalot_account@voxalot.com (or @us.voxalot.com, or...).
The idea is, we currently have this level of CODEC control for our own "providers". But when we are just "forwarding" the call (or someone is calling us via SIP Broker, etc), than we don't have any say on which CODEC is used for the "1st hop" (the call to VoXaLot). And that can (and apparently does, in practice) result in some unwanted "trnascoding". But if we had a setting on our VoXaLot account to control the CODECs for such calls, than end users would have at least some control over transcoding, by being able to influence the CODEC on the first hop of the call.
What I don't know (since I haven't seen the internals of the code recently), is how easy it would be to add such an (incoming CODEC select) option/feature to our VoXaLot accounts. But IMHO without such a feature, we will continue to get situations where unwanted transcoding is occurring (with little an individual VoXaLot user can do to stop that transcoding when it's causing problems)...