> > > > You can always lock down a codec by updating the initial > offer. Take > > > a > > look > > at section 10.2 of RFC 3264. > > That would be when you have to lock down to a subset of what > has been supported in the answer. Lets say if the offer > contained A,B,C and the answer contained only B, what would > be the need to lockdown specifically by another offer answer?
Yes, there is obviously no need to lock down in that case. You are probably aware that the offerer must be willing to accept any of the codecs that it offered before the answer arrives (early media). If your offerer implementation can not handle that then a=inactive in the offer and then a subsequent update with a=sendrecv will do the trick. Anyway, you seem to be more concerned about what happens post-answer. I think RFC 3264 is pretty clear about this. In your example, if the answerer (who answered with only B) actually sends codecs A or C in the media, then that answerer is broken. Somebody cited section 6.1 of RFC 3264 in an earlier posting which clearly spells it out. Regards, Raj Jain _______________________________________________ Sip mailing list https://www1.ietf.org/mailman/listinfo/sip This list is for NEW development of the core SIP Protocol Use [EMAIL PROTECTED] for questions on current sip Use [EMAIL PROTECTED] for new developments on the application of sip
