>
> > > 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://ww
w1.ietf.org/mailman/listinfo/sip
This list is for NEW development of the core SIP Protocol
Use sip-implementors cs.columbia.edu for questions on current
sip
Use sippingietf.org for new developments on the application of
sip
|
