thx to all for the replies. On Wed, Dec 2, 2009 at 4:22 PM, Huseyin ALTUN <[email protected]>wrote:
> 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 > _______________________________________________ Sip-implementors mailing list [email protected] https://lists.cs.columbia.edu/cucslists/listinfo/sip-implementors
