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

SamW swc at svtinc.com
Mon Jan 5 11:50:16 MST 2004


Steve,

My Problem is not a problem, with the codec negotiation between end points.
But when asterisk does it with canreinvite=no, * do not do it right. I
replied with a lengthy discussion about my findings here, This behavior can
be reproduced. But '*' do not seem to do the negotiation correctly. 

http://lists.digium.com/pipermail/asterisk-users/2004-January/032197.html
<http://lists.digium.com/pipermail/asterisk-users/2004-January/032197.html> 


		>I think your problem comes from a misunderstanding of how
the calls are
		>placed. With your canreinvite=no in the ATA section, you
end up with the
		>ATA negotiating with asterisk for a call leg. Then you have
asterisk
		>negotiating for the other call leg. Since the RTP stream is
going
		>through asterisk, it behaves with how asterisk is capable.
If there had
		>been a reinvite, then the ATA and the remote end would then
be able to
		>negotiate a different codec.



On Mon, 2004-01-05 at 01:29, SamW wrote:
> 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 <mailto:sip-a at foo.com> 
> register => sip-b at bar.com <mailto: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 
> 
> _______________________________________________
> Asterisk-Users mailing list
> Asterisk-Users at lists.digium.com <mailto:Asterisk-Users at lists.digium.com> 
> http://lists.digium.com/mailman/listinfo/asterisk-users
<http://lists.digium.com/mailman/listinfo/asterisk-users> 
-- 
Steven Critchfield <critch at basesys.com <mailto:critch at basesys.com> >

- SamW
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.digium.com/pipermail/asterisk-users/attachments/20040105/32004bc0/attachment.htm


More information about the asterisk-users mailing list