Hello, G.729 and G.729 AnnexB are not mutually compatible with each other as seen from below link.
http://www.cisco.com/en/US/tech/tk1077/technologies_tech_note09186a00800b6710.shtml These G.729 codec combinations interoperate: . G.729 and G.729A . G.729 and G.729 . G.729A and G.729A . G.729 Annex-B and G.729A Annex-B . G.729 Annex-B and G.729 Annex-B . G.729A Annex-B and G.729A Annex-B (As seen, G.729 and G.729 Annex-B are not compatible since G.729 AnnexB has built-in VAD (Voice Activity Detection = Silence Surpression) that can not be disabled.) And IMO, UAS shouldn't reject the call, instead should return an answer (even if annexb=no is available). BUT, this will bring ANOTHER problem. The UAC will send a CANCEL (there are few that are not sending) to terminate the call. This is because offer and answer doesn't match. RFC 3261; section 13.2.1 describes how to create the INVITE request as well as offer and answer in a call on simply basis, section 13.2.2.4 describes the codec negotiation during call establishment. 13.2.1 Creating the Initial INVITE ..... The UAC MUST treat the first session description it receives as the answer, and MUST ignore any session descriptions in subsequent responses to the initial INVITE. :::::::::::::::::::::::::::::::::: 13.2.2.4 2xx Responses ..... If the offer in the 2xx response is not acceptable, the UAC core MUST generate a valid answer in the ACK and then send a BYE immediately. Thus, RFC mandates that if the codecs offered in each side of a call doesn't match, the request originator should immediately terminate the call. This either should be by sending CANCEL after receiving SIP 183 Session Progress or sending an ACK following with a BYE after receiving SIP 200 OK message. Hope, this will help you. Thanks, Huseyin -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Iñaki Baz Castillo Sent: Wednesday, December 02, 2009 5:14 PM To: [email protected] Subject: Re: [Sip-implementors] G729 Negotiation El Miércoles, 2 de Diciembre de 2009, Johnny Jaguar escribió: > Hi all, > > what is the correct way for an UA (only with G729a support) to answer to > the following offer: > > Media Description, name and address (m): audio 53480 RTP/AVP 8 18 0 > Media Attribute (a): rtpmap:8 PCMA/8000 > Media Attribute (a): rtpmap:18 G729/8000 > Media Attribute (a): fmtp:18 annexb=yes > Media Attribute (a): rtpmap:0 PCMU/8000 > > > UA rejects the call. I think it shouldn't reject the call but should answer > with annexb=no. Is there a RFC describing this scenario? AFAIK G729a is fully compatible with G729b. -- Iñaki Baz Castillo <[email protected]> _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
