[Asterisk-Users] first tries !

[Benjamin on Asterisk Mailing Lists]

On Fri, 22 Oct 2004 14:11:53 +0300, raptor at tvskat.net <raptor at tvskat.net> wrote:
> thanx, now it works..

Good. Remember, debug is always your best friend. Other feedback may
lie to you (ie "everybody is busy" is most often a lie and it really
means "No clue why it's not working") but debug will always tell you
the naked truth.

> I've set the both phones on auto-codecs ..
> In fact the results are :
> 
> If both phones are on auto, g729, gsm610 or g711a i can hear each other.
> If they are on different codecs "no hear"

This means that Asterisk either cannot do the transcoding because it
lacks one of the codecs or it has been told not to do the transcoding
by way of disallow in the phones' definition in sip.conf.

Again, the debug output will tell you that. Watch out for messages
that talk about capabilities, something along the lines of "us: x,
them: y, common: 0".

Take into account that Asterisk doesn't care about what phone 1 said
it can support when Asterisk is negotiating codecs with phone 2. At
that point Asterisk only cares about what sip.conf says phone 2 is
allowed to use.

Also, it is generally not a good idea to allow everything, ie
allow=all in sip.conf. This may seem illogical, but ...

allow=all

... is not the same as ...

disallow=all
allow=codec1
allow=codec2
...
allow=codecN

... even if  {codec1 .. codecN} is a complete list of all codecs available.

This is because allow=all means "I don't give a damn about codec
mismatch, connect me anyway". So this is not a good thing to do.

It may or may not be similar with the ALL or AUTO setting of codecs in
the phone itself. But why take a chance? Just limit the list of
allowed codecs to a reasonable set and make sure that this set is
enforced on any configuration and any phone you are looking after.

for example, I always use this:

disallow=all
allow=ulaw
allow=gsm
allow=ilbc

These are the codecs I allow and anything else, I don't. Take it or
leave it. Period.

You may find that a policy like this will get rid of all your codec
troubles once and for all. Then if you have the odd case where you
have to support some exotic or evil codec, you can look into it as an
isolated case and provide a custom solution there and then.

rgds
benjk

-- 
Sunrise Telephone Systems, 9F Shibuya Daikyo Bldg., 1-13-5 Shibuya,
Tokyo, Japan.

NB: Spam filters in place. Messages unrelated to the * mailing lists
may get trashed.