RE: alternate RTP profiles in SDP offer/answer

["Dan Wing" <dwing@xxxxxxxxx>]

> what you claim to be a problem here has been removed from the SAVPF
> spec for this very reason.  -08 had -- by accident -- some remnants
> in that were taken out in -09.  Should there be an oversight left in,
> then please be precise of what you mean and we will be happy to
> fix this.

Thanks.  I'm sorry for not noticing, until now, this AVT document was
normatively specifying SDP behavior for SAVPF.  Here are my comments about
the MUSTs in the document that may interfere with the I-Ds on best-effort
SRTP:

-----

1.  Section 3.3.1 says:

  If supported, the answerer SHOULD prefer a secure profile over 
  non-secure ones.

and later says:

  If a media description in an offer uses SAVPF and the answerer 
  does not support SAVPF, the media session MUST be rejected.

Based on -savpf-09's defintion of "media session", this means the entire
RFC3388 group has to be rejected.  This means an RFC3388-grouped offer with
SAVPF and SAVP, sent to an answerer that understands RFC3388 and SAVP (but
the answerer doesn't implement SAVPF), would have to be rejected by the
answerer.  I don't believe this is your intent.  I suggest deleting:

  If a media description in an offer uses SAVPF and the answerer 
  does not support SAVPF, the media session MUST be rejected.

otherwise, we'll not be able to use SDP grouping.

-----

2.  Section 3.3.2:

   To offer two or more alternative RTP
   profiles for a particular media stream, the SDP description MUST
   contain exactly one m= line for this media stream for each profile
   and all the same transport address (IP address and port number). 

This requirement makes sense if you're using grouping (RFC3388), so
prefixing this with "If using RFC3388, ..." seems suitable.

However, note that section 7.5.3 RFC3388 explitictly prohibits using the
same transport address.

-----

3.  Section 3.3.4, titled "Describing Alternative Session Profiles", which 
I assume is talking about SDP (which describes sessions):

   SAVP and SAVPF entities MAY be mixed in the same RTP session (see
   also section 4) and so MAY AVP and AVPF entities.  Other
   combinations -- i.e. between secure and insecure profiles -- in the
   same RTP session are incompatible and MUST NOT be used together.

The MUST NOT in that last sentence prohibits using RFC3388 grouping to mix
AVPF and SAVPF.  That MUST NOT should be removed from -savpf, as it is a
stronger requirement than SAVP's own registration (RFC3711), which is
counter to a sentence in draft-ietf-avt-profile-savpf's security
considerations section which says that draft-ietf-avt-profile-savpf doesn't
increase or decrease security compared to SAVP itself.

4.  Also, in that paragraph, I believe the first sentence should read:

   SAVP and SAVPF entities MAY be mixed in the same media session 
                                                    ^^^^^
   (see also section 4) and so MAY AVP and AVPF entities.

-----

5.  Example 4:

   A client inquires a media description from a
   server using DESCRIBE and obtains a static SDP description without
   any keying parameters but the media description shows that both
   secure and non-secure media sessions using (S)AVPF are available. 

However, the SDP is:

      v=0
      o=alice 3203093520 3203093520 IN IP4 movies.example.com
      s=Media with feedback
      t=0 0
      c=IN IP4 0.0.0.0
      m=video 49170 RTP/SAVPF 96
      a=rtpmap:96 H263-2000/90000
      a=rtcp-fb:96 nack
      m=video 49172 RTP/AVPF 96
      a=rtpmap:96 H263-2000/90000
      a=rtcp-fb:96 nack
   
which isn't for one video stream but rather is for two separate video
streams -- one encrypted, the other unencrypted.  I see that the port
numbers were modified between -07 and -09 (likely a result of my complaints
about -07), but the text introducing the example wasn't changed.

Is it useful to just show SAVPF in the SDP, and not show alternative
grouping?

-----

Editorial nits:

Section 3.3.1, 

OLD:
  setting the port number in the respect m= line to 0.  
NEW:
  setting the port number in the respective m= line to 0.  
                                        ^^^

Section 5:

OLD:
   The SAVP profile does not add, nor take away,
   any security services compared to SAVP.   
NEW:
   The SAVPF profile does not add, nor take away,
       ^^^^^
   any security services compared to SAVP.   


> From the mere authorship of the spec, it should become clear that
> there is a close interaction with what MMUSIC does.
>
> I must admit that I am somehwat surprised and not particularly
> amused about your seocnd-guessing below.

Please accept my apologies for not reviewing this document until 
now.  I hope my suggested changes improve the document and assist
with its forward progress.

I do hope there is time on the MMUSIC agenda to discuss 
grouping and its merits for negotiating RTP profiles along 
with the other two approaches that are on the MMUSIC agenda.

-d