[Asterisk-Users] Codec Negotiation Does not seem to work as expected ?? Help Please !!

[SamW]

Hello,

I have been trying to get my coders to work without a conversion. I have 
read all the available asterisk documentation and support groups without 
any luck. Here is my issue. (Please feel free to ask questions if you do 
not understand what I am talking about.)

I am using Cisco ATA-186 set to g729 codec. (But it will switch to g711 if 
sip-server request g711)

I have 2 SIP-services to which I have to deliver the call in 2 coder 
formats. Lets call 2 sip-providers, SIP-A and SIP-B. SIP-A accept g729 and 
g711, SIP-B only accept g711.

I do not have any g729 licence, but I believe the * should negotiate to 
have the correct passthrough coders as ATA is capable of both coders. (I 
think even if you have the licenses, * should try avoid codec-conversions 
when ever it can)


Here is my settings in sip.conf. I will only list the required codec 
related lines, for easy understanding,

[general]
disallow=all
allow=g729
allow=ulaw
allow=alaw

register => sip-a at foo.com
register => sip-b at bar.com

[sip-a]
....
disallow=all
allow=ulaw


[sip-b]
...
disallow=all
allow=g729

[ATA]
.....
canreinvite=no

Here is what happens when I look at the SIP packets from linux. (ethereal)


Case 1 : ATA Dialing out through sip-a
============================


ATA indicate that it can have following, codecs in SDP packet, in following 
order
ATA --> asterisk  INVITE message
	g729
	ulaw
	alaw
asterisk  --> sip-a INVITE message (Note that already the order of coders 
are changed. Is this how it should be I do not know. And how * decide what 
order of coders to send to sip-a)
	alaw
	ulaw
	g729
sip-a --> asterisk Session Progress Message
	ulaw
asterisk --> ATA Session in Progress Message
	ulaw
	alaw
	g729
asterisk --> ATA send a BYE message and hang up.

at this point asterisk indicate it cannot native bridge message. I do not 
know why asterisk behaves like this, and I do think if asterisk send the 
message back to ATA with g729 in its message it should have worked fith 
nating bridging.

WARNING[1248642112]: File channel.c, Line 1853 
(ast_channel_make_compatible): No path to translate from 
SIP/sip-a-1e15(256) to SIP/4097-96d8(4)

	

Case 2 : ATA calling sip-b
===================
	
ATA indicate that it can have following, codecs in SDP packet, in following 
order
ATA --> asterisk  INVITE message
	g729
	ulaw
	alaw
asterisk  --> sip-b INVITE message (Note that unlike case 1, the decision 
by * in this case is OK. * only send one available coder info to the sip-b, 
which is correct as per my config)
	ulaw

sip-b --> asterisk Session Progress Message
	ulaw
asterisk --> ATA Session in Progress Message (Here again * sending multiple 
choices to the ATA, I expect this to be only one request as * already know 
from sip-b, that sip-b can only do ulaw. * know from 2 ways here one from 
Session Progress message above and other from sip-b context that sip-b can 
only do ulaw.) I am confused ????
	ulaw
	alaw
	g729

Asterisk send a BYE message to sip-b and send a 403 Forbidden Message to 
ATA and hang-up the call here.

asterisk --> sip-a send a BYE message and hang up.
asterisk -> ATA 403 Forbidden

NOTICE[1248642112]: File channel.c, Line 1478 (ast_set_read_format): Unable 
to find a path from G729A to ULAW
NOTICE[1248642112]: File channel.c, Line 1448 (ast_set_write_format): 
Unable to find a path from ULAW to G729A


=====================================================

Summery ;
Why this is happening this way, (Do I not understand how to configure or is 
this a bug?)
As the coder negotiation is not well documented anywhere can you please 
help me figure out how to configure the coder negotion.

IMHO, I belive that for each context, we need to have a way to force which 
coder to choose.   True that * can code convert with license, but when you 
code/decode it will always be lossy and will loose quality of sound.  If 
one side is fixed for a particular codec, and the other side is flexible 
for a negotiation, I should see that flexible side should get adjusted to 
the correct codec. It do not seem to happen.


Thank you in advance and appreciate your help.


- Sam