> > > > This is a useful example, thanks for explaining this. But I think this is > the wrong solution. Quoth RFC3264, S. 7: > > * When the offerer receives the answer, it MAY send media on the* > * accepted stream(s) (assuming it is listed as sendrecv or recvonly in* > * the answer). It MUST send using a media format listed in the answer,* > * and it SHOULD use the first media format listed in the answer when it* > * does send.* > > Note the use of SHOULD vs MUST. > [KIRAN] section 7 explains about "offerer processing of the Answer". But > I think the correct section for my explanation is section 6, " Generating > the Answer", which recommonds to use the same order of preference as that > in the offer. > > > "Although the answerer MAY list the formats in their desired order of > preference, it is RECOMMENDED that unless there is a specific reason, > the answerer list formats in the same relative order they were > present in the offer." > > The text says "unless there is a specific reason". You have a specific reason. Just do it. It is far more sensible to change the order of codecs in the answer, than to send a reoffer with changed codecs immediately afterwards.
Received on Wednesday, 23 July 2014 03:43:19 UTC