Subject: Comments on <draft-rosenberg-mmusic-sdp-offer-answer-00.txt>

From: Flemming Andreasen <[email-masked]>
Date: Tue, 06 Nov 2001 18:26:05 -0500

Thanks for putting together
<draft-rosenberg-mmusic-sdp-offer-answer-00.txt>. A couple of questions
and comments:

- Section 2 specifies that "Either an e line or p line MUST be present."
however this was made optional in <draft-ietf-mmusic-sdp-new-03.txt>. In
general, I think we should avoid stating or repeating requirements that
belong in the SDP specification itself.

- Section 2 mentions that SDP allows for concatenation of multiple
session descriptions. I can't seem to find this in the SDP spec - where
does it say that ?

- Section 2 says that "Once the offerer has sent the offer, it MUST be
prepared to receive media described by that offer." For send/receive
media streams, I believe the offerer must also be prepared to send such
media (although obviously it can't until it gets the answer).

- Section 2.1: I share the concerns raised by others about the following
sentence: "When receiving multiple streams of the same type, the streams
MUST be mixed before playing them out". This seems overly restrictive.

- Section 3: The sentence "The definition of rejected is both neither
offerer and answerer MUST NOT generate media (or RTCP packets) for that
stream." doesn't seem to parse quite right.

- Section 3 says that "Once the answer has been sent, the answerer MUST
be prepared to receive media as described in the answer.". For
send/receive streams I believe the answerer must also be prepared to
send such media.

- Section 3.1. says (for sendrecv media streams) that "The stream MAY
indicate additional codecs, not listed in the corresponding stream in
the offer, that the answerer is willing to receive with." This makes the
interpretation of the codecs listed context-dependent which is fairly
unfortunate. If the answerer wishes to add additional codecs to the
sendrecv stream, he should be able to both send and receive those codecs
(regardless of whether the offerer seems interested in receiving media
encoded with such codecs).

- Section 4.3 says that "The offerer MUST NOT cease listening for media
on the old port until media arrives on the new port. At that time, it
MAY cease listening for media on the old port.". This means that you
allow the presence of media to serve as confirmation of your offer. I
think this opens up a race condition and would prefer getting the answer
back as well.

- Section 4.3. says that "When a new codec is used with a dynamic
payload type number, it MUST NOT reuse a dynamic payload type number
used previously in the session.". I don't think the sentence accurately
captures the intention (since "new codec" seems to simply refer to the
most recent offer) which I belive is simply to forbid changing the
mapping from a given payload type to a given codec. If that mapping was
done X offer/invite exchanges ago, and we want to reuse it now, it
should be allowed.

- Section 4.3 is silent on what the offerer and answerer do with the
codecs (and media types) from the previous successful offer/answer. At
what point do the offerer and answerer stop accepting media according to
the old offer and answer ? Also, what happens if the offer is rejected ?

- Finally, for generality, the I-D should probably avoid some of the SIP
specific wording (e.g. "re-INVITE", "sending a SIP message") and simply
talk about sending offers and answers.

Thanks

        Flemming

--
Flemming Andreasen
Cisco Systems

---

From: Flemming Andreasen <[email-masked]>
Date: Mon, 26 Nov 2001 12:11:51 -0500

I haven't seen any response to this, so I'm trying again.

-- Flemming

--
Flemming Andreasen
Cisco Systems