Subject: [MMUSIC] On the SDP Offer/Answer model draft

From: [email-masked]
Date: Fri, 1 Mar 2002 10:47:16 +0100

- The draft defines "media stream", but regularly uses "stream" in stead. 
It
  would be better to also add "stream" to the definitions section.

- The text uses "media stream", "stream", "media description" and "'m=' 
line" 
  for the same purposes. This is not very consistent. It would seem, that 
in
  most cases "media description" is what is meant. 

- The the draft regularly uses phrasings like "the ... SDP" or "an ... 
SDP". 
  What is meant is either an "SDP session description" or an "SDP 
message", 
  therefore, the text can sometimes be somewhat misleading. I would be 
better 
  to use "SDP session description" and "SDP message" where appropriate.

- SDP only defines direction attributes as part of a media stream. Still, 
the
  draft talks about direction as a session attribute. How would this be 
  achieved?

- RTCP reports are always sent to an odd port number, one higher than the 
  associated RTP port number. Why does the draft indicate that this rule 
may
  be broken ("Unless there is an explicit indication ....")?

- It is not clear what the "semantic" difference between a stream marked 
as
  "inactive" and a stream with a port number value of 0 is, apart from the
  fact that in the former case RTCP is still exchanged. 

- It is not clear what the "semantic" difference between not offering 
media
  streams and specifying media streams with a port number of 0 is. 

- The draft talks about '..when multiple streams are received and sent to 
the 
  same sink ..". Obviously, nothing is ever sent from a sink. streams are 
  received on a sink and sent from a source.

- In the chapter on "generating the answer", it seems that the "normal" 
case 
  (returning a different session description in the answer than the one 
that
  was received in the offer) is made into a special case. Wouldn't it be 
  better to rephrase this somewhat to indicate this?

- The chapter on "Unicast Streams" talks about directionality of the 
_offer_,
  while, in fact, the directionality does not apply to the offer but to 
the
  media stream for which it is an attribute.

- It would seem that reusing a "slot", previously used by a disabled 
stream,
  contradicts the fact that new media descriptions MUST appear below any
  exising media sessions. This should be clarified.

- The chapter on "Indicating Capabilities", somehow gives the idea that 
there
  is something "special" with the SDP message used for this purpose. The 
SDP 
  message is constructed according to the rules from the previous 
chapters,
  with the difference that it lists all supported capabilities (in stead 
of 
  the ones that it is willing to use in a session). The example is 
somewhat
  misleading, in that it uses a "-" in the "s=" line (why?) and IP 
addresses
  (rather than host names, as in the other examples). 

Regards,

Frank