I have the same problem, most carriers out there deal with both g723.1 or
g729. During passing through via Asterisk, carrier customers will send us
calls broadcasting both codecs with one having priority over the other, the
way it is supposed to work is that asterisk will try to negotiate the top
priority codec first with the terminating endpoint, assuming that the
originating endpoint broadcasts g729 as first priority and then g723.1,
Asterisk should take g729 and try to negotiate with terminating endpoint and
if the terminating takes g729, then the call should be patched and bridged,
but if the terminating endpoint takes ONLY g723.1, then Asterisk should then
go back and take g723.1 (which is the second priority as per the originating
endpoint) and bridge the call through. However, the way Asterisk is doing it
is if I allow both g723.1 and g729, then if the originating endpoint
broadcasts both codecs and the terminating endpoint only allows g723.1, then
the call will not go through and it will say no path from g729 to ....., and
calls will not go through.
Summing up, if originating gateway allows both g723.1 and g729 , Asterisk
being the pass-through entity, allows both codecs, and the terminating
gateway allows ONLY g723.1, the calls will not go through which is certainly
a bug in the asterisk.
I wonder if anyone out there has any solution to this problem.
TC
-----Original Message-----
From: asterisk-users-admin@lists.digium.com
[mailto:asterisk-users-admin@lists.digium.com]On Behalf Of dkwok
Sent: Friday, February 20, 2004 8:42 AM
To: asterisk-users@lists.digium.com
Subject: [Asterisk-Users] RE: codec negotiation prob solved
(Philipp von Klitzing) wrote:
FYI - bug 1043 has been fixed on Feb 18:
"From my log, below, you will see that ast_rtp_bridge is not comparing
the codecs properly. Asterisk is currently comparing the integers, and
not the bits of the codec.
In the below example codec0 = 260. That means Codec0 allows both 256
(g729) and 4 (uLaw). So that would mean that Codec0 and Codec1 do have a
"Codec Match".
Asterisk needs to do a bit compare, and not a int compare in this case."
-- SIP/dialnet-8bac answered SIP/chris0-df00
-- Attempting native bridge of SIP/chris0-df00 and SIP/dialnet-8bac
Feb 16 11:27:48 WARNING[68889520]: rtp.c:1204 ast_rtp_bridge: codec0 260 is not
codec1 = 256, cannot native bridge.
Feb 16 11:27:50 NOTICE[68889520]: rtp.c:264 process_rfc3389: RFC3389
support incomplete. Turn off on client if possible
Feb 16 11:27:50 NOTICE[68889520]: rtp.c:293 process_rfc3389: Don't know
how to handle RFC3389 for receive codec 256
>>
I have the same problem with codec negotiation, my Voip provider use
g729 however I have also connection with Iaxtel which only use GSM. I
can only get one or the other codec working when dialing out.
My iax.conf setting is below:
; Inter-Asterisk eXchange driver definition
[general]
port=4569
bandwidth=low
disallow=all
allow=gsm
allow=g729
disallow=g723.1 ; Hm... Proprietary, don't use it...
disallow=lpc10 ; Icky sound quality... Mr. Roboto.
jitterbuffer=yes
dropcount=3
maxjitterbuffer=250
maxexccessbuffer=50
register => dkwok:ccccf01@iaxtel.com
tos=lowdelay
[iax_home]
type=friend
context=int-ext
auth=md5
user=iax_home
secret=cccccc
trunking=yes
disallow=all
allow=gsm
host=dynamic
qualify=yes
[iaxtel]
type=friend
disallow=all
disallow=g729
allow=gsm
trunking=yes
context=from-iaxtel
[atp]
type=friend
disallow=all
allow=g729
trunking=yes
context=atp
host=xxx.xxx.xxx.xxx
I would like to hear any comment from * developer.
--
David Kwok
Iaxtel/FWD # 17001813482 ext 1002
---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.590 / Virus Database: 373 - Release Date: 2/16/2004