no, B has not told A that it can do G726. So client A must not expect G726 after the response.
your offer and answer should result in: A<====G729====>B By the way, If B had responded m= PCMA, G729 then it would be allowed to have: A====PCMA====>B A<====G729====B ...but this is not normal behaviour. Your response (of "m= G729, PCMA") is better because it is strongly recommended in RFC3264 that an SDP answer has the codecs in the same order as in the SDP offer - this is because many UAs cannot handle codec asymmetry. regards Attila -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Michael Hirschbichler Sent: 17 March 2010 09:20 Cc: SIPImplementors Subject: Re: [Sip-implementors] Offer-answer question So, the combination client A sends: INVITE m= G726, G729, G723, PCMA, PCMU client B responses: 200OK m= G729, PCMA resulting in A====G729====>B A<====G726====B is a correct signalling regarding to RFC3264 SIP/SDP offer-answer? br Michael On 2010-03-15 16:54, Iñaki Baz Castillo wrote: > 2010/3/12 Aneesh Naik <[email protected]>: >> Hi Michael, >> >> This will not be allowed. A (UAC) has sent all the codecs it >> supports, and B (UAS) has respoded with the codecs it is willing to >> talk to A for this call. Only one codec will be negotiated for media >> transfer between A and B. >> In your example below, the negotiated codec is G.729, so both the >> parties must send media on G.729 codec. >> >> If the codec needs to change it between, then there can be a Re-NVITE >> to change the codec, and both parties once aggreed will start talking >> on that new codec negotiated. > > This is not true :( > _______________________________________________ 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
