Hi, When reading the draft, and chapter 2.10, I wonder if we also need to describe sendrecv (symmetric) cases where the answer codec(s) is NOT a subset of the offer codec(s), because my understanding is that it was once decided that that is NOT a requirement (RFC3264 only talks about that the number of m= lines must match). Now, if the nodes don't have a common codec the session will most likely be terminated, but it IS still a valid offer/answer case, I think. I don't know if these cases will happen in real-life (the receiver of the offer will probably reject it, instead of sending an answer, if it can't match any of the codecs).
Another case is where thera are common sendrecv codecs, but specific codec parameters (described using the fmtp attribute) are different, because I don't think there are any requirements that the parameters in the offer MUST be matched in the answer. Again, the session may be terminated, but it's still a valid offer/anser case. Regards, Christer Holmberg Ericsson Finland > -----Original Message----- > From: Robert Sparks [mailto:[EMAIL PROTECTED] > Sent: 11. hein�kuuta 2003 19:07 > To: [EMAIL PROTECTED] > Cc: Alan Johnston > Subject: [Sip-implementors] SDP Offer Answer examples > > > I'd like to call attention to > > http://www.ietf.org/internet-drafts/draft-ietf-mmusic-offer-an > swer-examples-01.txt > > ---------------------------------------------------------------------- > Abstract > > This document gives examples of Session Description Protocol (SDP) > offer answer exchanges. Examples include codec negotiation and > selection, hold and resume, and addition and deletion of media > streams. The examples show multiple media types, bidirectional, > unidirectional, inactive streams and dynamic payload types. Common > Third Party Call Control (3pcc) examples are also given. > > ---------------------------------------------------------------------- > > > If you haven't already seen it, please look through it and let us know > if there are any other scenarios that you think need to be detailed. > > The MMUSIC working group believes this draft is close to done > and will soon move toward issuing it as an RFC. > > Thanks, > RjS > > _______________________________________________ > Sip-implementors mailing list > [EMAIL PROTECTED] > http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors > _______________________________________________ Sip-implementors mailing list [EMAIL PROTECTED] http://lists.cs.columbia.edu/mailman/listinfo/sip-implementors
