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: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of dkwok Sent: Friday, February 20, 2004 8:42 AM To: [EMAIL PROTECTED] 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:[EMAIL PROTECTED] 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 _______________________________________________ Asterisk-Users mailing list [EMAIL PROTECTED] http://lists.digium.com/mailman/listinfo/asterisk-users To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-users