In article <R6adncp6R6Hmr8Xb4p2dnA@giganews.com>,
John Miller <johnmiller@nospamplease.com> wrote:
>Let's say person A is using SIP provider A on an ATA, and person B is using
>SIP provider B on another ATA.
>
>Person A calls person B (both using SIP, but with "real" phone numbers, so
>not via ENUM). Which devices are deciding (comparing their codec priority
>list) which codec to use?
>
>- Provider A and provider B? If this is the case, can it be that the link
>between provider B and the ATA of person B can use another codec? Also for
>the link of person A's ATA to provider A?
>
>- Provider A and person's B's ATA? Is this case provider B is
>"transparant"?
>
>- Person A's ATA and person B's ATA? In this case both provider's priority
>list doesn't matter?

coming into this a bit late, but what you'll most likely find is that the
Providers won't let you use any CODEC other than G711 (u or a) and the
reason for that is likely to be down to the CPU horsepower required to
do the transcoding. pA and pB are going to be using the PSTN to talk to
each other (unless they have private peering arrangements) and, as been
pointed out that will almost certainly want to use G711.

I only allow my subscribers to connect in on G711 (a or u as the
conversion between the 2 is negligible), but I also allow G726 which
is half the bandwidth and the conversion CPU usage is very low, and
very occasionally, GSM, but only from PBXs I install at the clients end,
talking to one of my head-end switches, and only then if their Internet
line is anything other than "excellent".

Sipgate don't allow GSM, but I haven't tried others.

I have heard of some US providers using G729 which is patent encumbered,
(the license is $10 per line) but most phones/ata's support that anyway
- good quality and very minimal bandwidth, but how they're handling the
compute required to transcode it to G711 which they (probably) need to
do to connect to the PSTN is anyones guess. (Although it might well be
that the expense of additional CPU/Servers is cheaper than the additional
bandwidth required when dealing with 1000's or more subscribers)

With regard to the original question of "who decides", there is a
negotiation phase during call setup, each end has a list of CODECs they
support and usually the highest quality one will 'win', but it's almost
always going to be the upstream provider that has the final say, not the
end-user - and you can get into situations where you simply can't place
the call because the provider doesn't (or won't) support the CODECs the
end-user has available.

For an example of the CPU time required to do some translations, have a
look at this:

Translation times between formats (in milliseconds)
Source Format (Rows) Destination Format(Columns)

g723 gsm ulaw alaw g726 adpcm slin lpc10 g729 speex ilbc
g723 - - - - - - - - - - -
gsm - - 10 10 32 12 9 43 - 259 173
ulaw - 33 - 1 24 4 1 35 - 251 165
alaw - 33 1 - 24 4 1 35 - 251 165
g726 - 51 20 20 - 22 19 53 - 269 183
adpcm - 34 3 3 25 - 2 36 - 252 166
slin - 32 1 1 23 3 - 34 - 250 164
lpc10 - 57 26 26 48 28 25 - - 275 189
g729 - - - - - - - - - - -
speex - 56 25 25 47 27 24 58 - - 188
ilbc - 64 33 33 55 35 32 66 - 282 -

This is the output from an asterisk box command:
show translation recalc 30

The times are in ms, and as this is running on a 533MHz processor, they
do appear quite large, but it's a good demonstration and highlights the
overheads better than running on a 3GHz processor (where they may be
sub millisecond, but when you're handing 100s of calls, it all adds up!)

And you can also see that speex and ilbc, which, while nice geeky, high
compression CODECS, do require a lot of CPU to do the encoding and
decoding... (and neither of them sound particularly good IMO - unless you
like sounding like a Dalek :)

Gordon