RE: [Asterisk-Users] RE: codec negotiation prob solved
I agree, that * codec negotiation is buggy, there must be some mechanism to give priority to pass through without trying to codec translate. Codec translation need lot of CPU and can deteriorate quality by its nature. Some developer sheding some light on this is buggy codec translation is very appreciated. - SamW -Original Message- From: T. Chan [mailto:[EMAIL PROTECTED] Sent: Friday, February 20, 2004 12:48 AM To: [EMAIL PROTECTED] Subject: RE: [Asterisk-Users] RE: codec negotiation prob solved 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=cc 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 ___ 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
RE: [Asterisk-Users] RE: codec negotiation prob solved
Dear All, That is my experience with Asterisk too, this codec negotiation is giving us lots of problems. I am using Asterisk mostly for passing-through VOIP traffic. Basically I will have to choose g7231 or g729 and not both. If I choose both, and when calls come in with with both codecs, and the terminating gateway (endpoint) only allows g729, the calls would go through, but if the terminating gateway only allows g7231, then calls would not go through, and if the terminating gateway allows both codecs, call would not go through either. Worst yet, Asterisk seems not to work with t38 fax and I have to allow g711 in order to get fax to go through and that is ONLY between Asterisk, if a cisco calls into my Asterisk with a fax, it just will not work. Anyway, the worst part is if I allow g711 on my Asterisk, ALL calls coming into my Asterisk will get converted to g711 before going out, whether out to a third party equipment (if they allow g711) or my other Asterisk. Conversion takes up too much resource and needless to say bandwidth (for g711), and it is highly a NONO to convert to g711 for all calls, even voice calls. If I allow g723, g729 and g711, calls will NOT just get passthrough, they will get converted. Is there anyway we can debug this problem please? TC -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of SamW Sent: Tuesday, March 02, 2004 3:32 PM To: [EMAIL PROTECTED] Subject: RE: [Asterisk-Users] RE: codec negotiation prob solved I agree, that * codec negotiation is buggy, there must be some mechanism to give priority to pass through without trying to codec translate. Codec translation need lot of CPU and can deteriorate quality by its nature. Some developer sheding some light on this is buggy codec translation is very appreciated. - SamW -Original Message- From: T. Chan [mailto:[EMAIL PROTECTED] Sent: Friday, February 20, 2004 12:48 AM To: [EMAIL PROTECTED] Subject: RE: [Asterisk-Users] RE: codec negotiation prob solved 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
[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=cc 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 smime.p7s Description: S/MIME Cryptographic Signature
RE: [Asterisk-Users] RE: codec negotiation prob solved
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=cc 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