Summary:	ASTERISK-01358: G726 as compatible codec - recognition by various SIP devices
Reporter:	chrisorme (chrisorme)	Labels:
Date Opened:	2004-04-06 05:57:28	Date Closed:	2004-09-25 02:51:27
Priority:	Major	Regression?	No
Status:	Closed/Complete	Components:	Core/General
Versions:		Frequency of Occurrence
Related Issues:
Environment:		Attachments:	( 0) cisco.g726.2.txt
Description:	If Asterisk knows what SIP device is requesting a list of codecs from it (from the field where the remote SIP device says what it is) it would be cool if Asterisk then offered that remote device its G726 codec (if allow'ed) by the name that the remote device understands as G726 / knows G726 by.   I was thinking in particular for the ATA186 which I think calls G726(-32?) by a different name than asterisk does ? (I think that's the reason why I can't get these two to talk G726) I think this is also the case for the sipura - but I know that in the sipura you can change the name transmitted in its settings so it's not as big an issue with that as much as the ATA186/8 or possibly other Cisco devices/phones too??   Just an idea anyway.   Throw it away if you like or if the G726 isn't negoiating for some other reason? - Chris
Comments:	By: Olle Johansson (oej) 2004-04-06 08:54:58 The negotiation is normally done with IETF standard codes, not text. See http://www.iana.org/assignments/rtp-parameters Unfortunately, G.726 doesn't have a standard rtp code, so we're propably using one of the dynamic codes. Could you please add a SIP Debug of the INVITE, the OK and the ACK so I can see how it's been negotiated. If possible, include the CLI output from an Asterisk started with a lot of -vvvvvv and possibly a -d as well. edited on: 04-06-04 07:47 By: chrisorme (chrisorme) 2004-04-08 12:14:22 Thanks!  Our ATA186 is currently on a customer field trial.  I'll either get the customer to select G726-32, wait until the end of the trial, or go down and get this debug myself at their premises - could take a few days though with it being Easter. It'd be amazing if you could fix this. In the meantime if anyone has an ATA186 and could provide this debug that'd be amazing as it's probably the best codec to use with the device and I reckon it would benefit us all if it could be made to work with *.   Chris edited on: 04-08-04 11:07 By: chrisorme (chrisorme) 2004-04-09 10:35:09 Hi! Snom are planning to add G726-32 to their phones... I asked them how they described the new codec in their headers so * could recognise this and Christian told me the following which I hope helps. --------- I took media type 2 (saw that somewhere on the Internet). But it's visible in the a=rtpmap:2 g726-32/8000 header anyway. ----------- By: chrisorme (chrisorme) 2004-04-09 10:56:06 Hi! I've got some debug as promised. Enabling the cisco ATA186 with G726 did actually seem to be recognised :) 'sip show channels' shows G726 for the call in the debug .3 (see website link below) However we got pages of continuous errors of the like of : Unable to calculate sample frames and lots of clicking and really bad audio quality/breaking up especially from the PSTN to the VoIP user.... So this might be something other than a chan_sip.c issue and more an rtp one or something else??? The debug is at http://www.prioryhomes.com/cisco That server is only on a 64K link so will take a while to download.. sorry.  I tried to upload the debug but got errors .. cisco.g726.3.txt and possibly cisco.g726.2.txt I think are the most useful debug files. (if you follow the link) I managed to attached cisco.g726.2.txt but I don't think it's good as I think the cisco might have used G729 instead of G726 in that debug. We'd really like to be able to use G726 (-32?) usably. The asterisk being run that produced this debug is the stable version, not CVS. Many thanks for considering looking at this. - Chris By: Brian West (bkw918) 2004-04-09 21:42:36 upgrade your firmware (2.16.2 or even 3.1) g726 was tested with ATA's and works fine.  Please report if you can't get it working after firmware upgrade.  (3.0 was the first official release with g726 support but it does support it in lower version but might have bugs) By: chrisorme (chrisorme) 2004-04-10 04:36:04 I had the 3.1.0 firmware installed when running the debug and I get all these rtp errors still. By: chrisorme (chrisorme) 2004-04-10 04:40:09 I have the stable * running from about 7-10 days ago - maybe if a different version has been tested you can tell me which one was tested and works (preferably a stable version).... - Thanks By: Brian West (bkw918) 2004-04-10 06:54:41 show me the errors... what I see are notices and warnings which are just for informational purposes.  Turning off those warnings or errors is the best thing to do since they are not "ERRORS".  Does the ata work? Do you get audio? can you make a call? By: chrisorme (chrisorme) 2004-04-10 07:40:49 Did you see the massive debug from the link that I couldn't upload ? Perhaps they are still warnings but I think they are still causing problems. The download I attached I think is ok as G729 was used. Yes... A call can be made, and yes there is audio but it breaks up terribly especially for the person on the SIP device and about 10 clicks a second can be heard by the person on the PSTN end that it isn't at all usable Setup is : SIP -> * -IAX-> provider -> PSTN The audio is pretty much fine and usable with G729 and G711A it just all goes wrong with G726-32. Chris By: Olle Johansson (oej) 2004-04-10 08:22:00 THis may not be related to g726 at all, but to the other bugs with SIP-IAX calls. See 1093 and see if this is related. By: chrisorme (chrisorme) 2004-04-10 08:34:43 Thanks olle.   I only get the problems with G726 though ..   Both G729 and G711A work great (also over SIP), or almost great. I've read bug 1093 and don't think it's similar really though turning the jitter buffer off on IAX might be a good idea as I'm getting echo with an IAXy on both ends and I don't know really what are good settings with the iax jitter buffer and can't find any info anywhere on how to set up the jitter buffer in iax.conf or any settings that people have had success with ... I think this bug may be related to some non-sip code (the part giving out the warnings perhaps in the debug from the link above) but I'm not sure where. It would just be nice to have a medium compression codec rather than just G711A or G729.  I wonder if the quality is supposed to be somewhere between the two or if it's just similar to G729 and therefore not really worth the hassle of fixing this ? By: James Golovich (jamesgolovich) 2004-04-13 01:48:40 chrisorme: what version of asterisk are you using?  g726 (the codec) is only in CVS HEAD at this point By: chrisorme (chrisorme) 2004-04-15 08:16:57 I think G726 definitely is in stable as it places the call and the call connects and 'sip show channels' shows G726 as format for the call...   Testing with 3.1 sip code on a brand new ata186 the results are as follows : Latest CVS (11pm 4/14) doesn't generate all those pages of (what I called) errors about timestamps and also seems to sound better ie. audio is not delayed when compared my mar 29 stable. So perhaps this bug can be marked as 'now fixed in CVS'?? edited on: 04-15-04 07:11 By: Olle Johansson (oej) 2004-04-15 08:25:08 Per suggestion: "Now resolved in CVS" :-)