Thanks David this is how Cisco sees the g729 issue: http://www.cisco.com/en/US/tech/tk1077/technologies_tech_note09186a00800b671... IIRC the cng packets have 2 bytes payload, if an endpoint does not support annexb, what should it do about those packets? Regards Javi ---------- Forwarded message ----------
From: David Ponzone <david.ponzone@ipeva.fr> To: FreeSWITCH Users Help <freeswitch-users@lists.freeswitch.org> Date: Mon, 25 Apr 2011 16:19:39 +0200 Subject: Re: [Freeswitch-users] g729 annexa/annexb interoperability Javier,
I dont think there is anything to transcode. G729 and G729B are the same, except the latter uses VAD and CNG.
David Ponzone Direction Technique email: david.ponzone@ipeva.fr tel: 01 74 03 18 97 gsm: 06 66 98 76 34
Service Client IPeva tel: 0811 46 26 26 www.ipeva.fr - www.ipeva-studio.com
*Ce message et toutes les pièces jointes sont confidentiels et établis à l'intention exclusive de ses destinataires. Toute utilisation ou diffusion non autorisée est interdite. Tout message électronique est susceptible d'altération. **IPeva** décline toute responsabilité au titre de ce message s'il a été altéré, déformé ou falsifié. Si vous n'êtes pas destinataire de ce message, merci de le détruire immédiatement et d'avertir l'expéditeur.* * *
Le 25/04/2011 à 13:44, Javier Gallart a écrit :
Hello all
we're using a Sangoma D100 card for transcoding. Our configuration, as far as the codec policy is concerned, basically does this:
-In the first offer to the b-leg we use the same codec list we receive (<action application="export" data="absolute_codec_string=${ep_codec_string}"/>) -If the call fails with status 488, we repeat the call using all the codecs available. This includes changing from annexb to annexa and viceversa.
Let's suppose a-leg only supports g729 annexA, and B-leg only supports G729 annexB. My understanding is that those different codec flavours don't interoperate; in fact I've experienced many times audio problems when trying to set up a call between endpoints supporting different g729 variants.
In the described case, FS sends initially annexb=no, and B-leg rejects it with cause 488. We rebuild the offer with annexb=yes, and then the offer is accepted by the B-leg. Our concern is that no transcoding resources are used in this case, and we might run into audio problems because of that. The other concern is that in the answer to the A-leg (in 183 and 200), annexb=yes is included. I'm not sure if all devices would support different fmtp parameters in the offer and the answer (the RFC, as usual, won't be explicit about this).
Is there any way to force the transcoding in a situation like the one I described?
Thanks in advance
Javi
_______________________________________________ FreeSWITCH-users mailing list FreeSWITCH-users@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-users UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-users http://www.freeswitch.org