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?
"John Miller" <johnmiller@nospamplease.com> wrote in message
news:R6adncp6R6Hmr8Xb4p2dnA@giganews.com...
> 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?
There are 2 possibilities I believe:
a) Provider A and Provider B have interconnection agreements, and provider A
is able to convert the "real" phone number of person B into a SIP adress.
In this case there is a SIP conncetion between A and B: here I assume Person
A's ATA and person B's ATA will ngotiate the Codec
b) Provider A and Provider B do not "know" each other: Provider A will built
a PSTN connection to Provider B's network.
In this case, there is no link between the codes used.
The connection between person A and provider A will use wathever Codec is
supported by A, and the connection between person B and provider B will use
wathever Codec is supported by B.
John Miller 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?
There are a number of answers to this question depending on how provider
A and B have configured their network and how they interconnect.
As a general rule whatever you are directly conencting to i.e UA, B2BUA,
media relay will negoitate a codec that is common to both you and them.
It is possible that the interconnect, if used, will use a totally
different protocol and will be performing transcoding to enable this.
John Miller 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?
There are a number of answers to this question depending on how provider
A and B have configured their network and how they interconnect.
As a general rule whatever you are directly conencting to i.e UA, B2BUA,
media relay will negoitate a codec that is common to both you and them.
It is possible that the interconnect, if used, will use a totally
different protocol and will be performing transcoding to enable this.
> b) Provider A and Provider B do not "know" each other: Provider A
> will built a PSTN connection to Provider B's network.
> In this case, there is no link between the codes used.
Isn't G.711 (a in Europe, and µ in America) the international standard for
PSTN calls? I just thought so because ISDN is also using this codec, and I
suppose the PSTN operators are avoiding extra conversions on the way.
So I thought if my ATA would negociate G.711a to my SIP provider, that there
would be less conversions needed?
> As a general rule whatever you are directly conencting to i.e UA, B2BUA,
> media relay will negoitate a codec that is common to both you and them. It
> is possible that the interconnect, if used, will use a totally different
> protocol and will be performing transcoding to enable this.
Don't all these codec conversions introduce a degrade in quality?
For instance, some people use a DECT phone which is using G.726. This is
converted to analogue to their ATA. This ATA is using maybe G.729 to the
VOIP provider. This VOIP provider is putting this signal onto the PSTN via
G.711a (I assume). And at the other side a similar conversion could be
done...
It just seems like a quality loss is unavoidable this way.
John Miller wrote:
>> As a general rule whatever you are directly conencting to i.e UA, B2BUA,
>> media relay will negoitate a codec that is common to both you and them. It
>> is possible that the interconnect, if used, will use a totally different
>> protocol and will be performing transcoding to enable this.
>
> Don't all these codec conversions introduce a degrade in quality?
>
> For instance, some people use a DECT phone which is using G.726. This is
> converted to analogue to their ATA. This ATA is using maybe G.729 to the
> VOIP provider. This VOIP provider is putting this signal onto the PSTN via
> G.711a (I assume). And at the other side a similar conversion could be
> done...
>
> It just seems like a quality loss is unavoidable this way.
Yes you are correct, the quality of the call will be, amongst other
things, governed by the codec which uses the least amount of
bandwidth/least efficient conversion algorithm.
An analogy would be the internet itself where by the speed from your PC
to a server for example is governed by the slowest link in the route
from you to the server.
> Isn't G.711 (a in Europe, and µ in America) the international standard for
> PSTN calls? I just thought so because ISDN is also using this codec, and
> I suppose the PSTN operators are avoiding extra conversions on the way.
>
> So I thought if my ATA would negociate G.711a to my SIP provider, that
> there would be less conversions needed?
Potentially - but how do you know how your SIP provider gets your call
to/from the PSTN? They may be using ISDN, but then again they may have an
IP trunk instead.
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)
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 Henderson wrote:
> 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.
On 27 May, 13:05, "John Miller" <johnmil...@nospamplease.com> wrote:
> Don't all these codec conversions introduce a degrade in quality?
>
> For instance, some people use a DECT phone which is using G.726. This is
> converted to analogue to their ATA. This ATA is using maybe G.729 to the
> VOIP provider. This VOIP provider is putting this signal onto the PSTN via
> G.711a (I assume). And at the other side a similar conversion could be
> done...
>
> It just seems like a quality loss is unavoidable this way.
I am indeed curious. It seems a lot is going on
DECTphone A/D G.726; DECT base G726 D/A; ATA A/D G.711; my SIP
provider perhaps D/A on PSTN if receiver not known
other side reverse
If I do this with MP3 one time (decode to wave and recode) there is
clearly a difference. Is this different with voice? Is this why my
DECT sound so sharp/hissy?
Who decides which codec to use? 
Linear Mode
