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 => [EMAIL PROTECTED]
register => [EMAIL PROTECTED]

[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


_______________________________________________
Asterisk-Users mailing list
[EMAIL PROTECTED]
http://lists.digium.com/mailman/listinfo/asterisk-users

Reply via email to