Hi, I just finished porting a G.729 codec to PJSIP. I have created a codec factory for the codec and everything works great, except for one thing. I cannot prevent the placement of a 2 octet G.729B (comfort noise) frame followed by a 10 octet G.729/G.729A (coded speech) frame in the same RTP packet. Transmitting RTP packets with mixed frames G.729 types is order restricted, since frames contain do not contain a type field. RFC 3551 states: ?A G729 RTP packet may consist of zero or more G.729 or G.729 Annex A frames, followed by zero or one G.729 Annex B frames. The presence of a comfort noise frame can be deduced from the length of the RTP payload.? For example, if an RTP packet payload is 10 or 20 bytes in length, it contains 1 or 2 G.729/G.729A frames. If an RTP packet payload is 2 or 4 bytes in length, it contains 1 or 2 G.729B frames. If the RTP packet payload length is 12 bytes, it must contain a G.729/G.729A frame and a G.729B frame. Since there is no way to determine the order of the frames in the packet by examination, the order must be determined by convention. So how do I ensure this using the PJSIP codec framework? I must make sure that when the codec generates a G.729B packet followed by a G.729/G.729A packet, an RTP packet is not sent with these two frames in it. When the codec?s encode function is called, the codec processes all the input speech data and places the encoded frames, if any, in the output buffer and then returns. Transmission of the encoded frames in RTP is done behind the scenes by PJSIP. One solution would be to transmit each frame separately. I examined the IPP codec interface software in ipp_codecs.c and could not determine how this Intel G.729 implementation handles this situation either. Is there a problem with this codec as well? Any help would be greatly appriciated. Thanks, Dave Richards -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.pjsip.org/pipermail/pjsip_lists.pjsip.org/attachments/20150106/0b240b04/attachment.html>
