Subject: [MMUSIC] alternate RTP profiles in SDP offer/answer

From: "Dan Wing" <[email-masked]>
Date: Fri, 27 Oct 2006 16:02:17 -0700

draft-ietf-avt-profile-savpf-09 mentions, in several places, how ports can
be overloaded and grouping can be used to specify RTP/SAVP and RTP/SAVPF in
the same offer.  The suggestions in draft-ietf-avt-profile-savpf-09 appear
to have the drawbacks that Flemming describes in section 3.1 and 3.5 of
draft-andreasen-mmusic-sdp-capability-negotiation-01.  It seems ill-advised
for AVT to publish a document encouraging use of mechanisms with these
drawbacks, unless MMUSIC agrees with this decision.

Considering that the upcoming IETF has two individual contributions in
MMUSIC on this topic, draft-andreasen-mmusic-sdp-capability-negotiation-01
and draft-kaplan-mmusic-best-effort-srtp-01, I don't believe there is
consensus within MMUSIC of which approach to take.

Can Joerggand Elisabetta discuss the technique proposed in
draft-ietf-avt-profile-savpf-09 at the upcoming MMUSIC meeting?  Or can we
perhaps have a joint presentation by all five authors so that MMUSIC can
make an informed decision on this important topic?

-d

> 	Title		: Extended Secure RTP Profile for 
>                   RTCP-based Feedback (RTP/SAVPF)
> 	Author(s)	: J. Ott, E. Carrara
> 	Filename	: draft-ietf-avt-profile-savpf-09.txt
> 	Pages		: 17
> 	Date		: 2006-10-25
> 	
>    An RTP profile (SAVP) is defined for secure real-time
>    communications, and another profile (AVPF) is specified to provide
>    timely feedback from the receivers to a sender.  This memo defines
>    the combination of both profiles to enable secure RTP
>    communications with feedback.
>
> http://www.ietf.org/internet-drafts/draft-ietf-avt-profile-savpf-09.txt

_______________________________________________
mmusic mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mmusic

---

From: "Francois Audet" <[email-masked]>
Date: Fri, 27 Oct 2006 19:13:41 -0500

I fully support Dan's suggestion.

It seems to me that a significant fraction of
draft-ietf-avt-profile-savpf-09
is really MMUSIC material, and does overlap with the two drafts that 
Dan listed.

I also support the suggestion that all the parties try to collaborate
on a joint presentation of the issues.

> -----Original Message-----
> From: Dan Wing [mailto:[email-masked]] 
> Sent: Friday, October 27, 2006 4:02 PM
> To: [email-masked]; 'Joerg Ott'; [email-masked]
> Cc: 'Flemming Andreasen'; 'Hadriel Kaplan'; Audet, Francois 
> (SC100:3055); [email-masked]
> Subject: alternate RTP profiles in SDP offer/answer
> 
> draft-ietf-avt-profile-savpf-09 mentions, in several places, 
> how ports can be overloaded and grouping can be used to 
> specify RTP/SAVP and RTP/SAVPF in the same offer.  The 
> suggestions in draft-ietf-avt-profile-savpf-09 appear to have 
> the drawbacks that Flemming describes in section 3.1 and 3.5 
> of draft-andreasen-mmusic-sdp-capability-negotiation-01.  It 
> seems ill-advised for AVT to publish a document encouraging 
> use of mechanisms with these drawbacks, unless MMUSIC agrees 
> with this decision.
> 
> Considering that the upcoming IETF has two individual 
> contributions in MMUSIC on this topic, 
> draft-andreasen-mmusic-sdp-capability-negotiation-01
> and draft-kaplan-mmusic-best-effort-srtp-01, I don't believe 
> there is consensus within MMUSIC of which approach to take.
> 
> draft-ietf-avt-profile-savpf-09 at the upcoming MMUSIC 
> meeting?  Or can we perhaps have a joint presentation by all 
> five authors so that MMUSIC can make an informed decision on 
> this important topic?
> 
> -d
> 
>

---

From: Joerg Ott <[email-masked]>
Date: Sat, 28 Oct 2006 11:19:32 +0300

Dan,

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.

To quote from present -09:

    If alternative RTP profiles are to be specified for a single RTP
    session, each alternative needs to be included on a separate media
    line in SDP.  However, with only basic SDP, it is not possible to
    communicate that the two m= lines are meant as alternatives (as
    opposed to specifying different media sessions of the same type).
    A mechanism to indicate semantic equivalence between the individual
    sessions and ensure that any receiver only joins one of them, such
    as the grouping framework [9], is being defined in the MMUSIC WG.

 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.

Joerg

---

From: "Francois Audet" <[email-masked]>
Date: Mon, 30 Oct 2006 12:36:06 -0600

Hi Joerg,

It looks like we may have misinterpreted the concept of "alternatives"
in the draft.

The drafts left us with the impression that it was indeed endorsing the
idea 
of port overloading. We had assumed that "alternatives" were meant to
denote
backward compatibility with UAs that did not support SAVPF.

I guess the paragraph that you quoted below clarifies it, but it may not
be 
totally obvious to the reader that the mechanism in this draft suffers
from
the exact same problem described in the 2 drafts than Dan listed.

Perhaps a simple statement upfront to clarify it would help.

For example, the  first paragraph of Page 7 currently state:

   Different RTP profiles MAY be used in different media sessions.
   For negotiation of a media description, the four profiles AVP,
   AVPF, SAVP, and SAVPF are mutually exclusive.  Note, however, that
   SAVP and SAVPF entities MAY be mixed in a single RTP session (see
   section 4).  Also, the offer/answer mechanism MAY be used to offer
   alternatives for the same media session (e.g. using the same
   transport parameters) and allow the answered to choose one of the
   profiles.

It could be emphasised that what you are really saying is that the
alternatives are using multiple media descriptions (i.e., multiple m
lines)
in a single media session. Something like:

   Different RTP profiles MAY be used in different media sessions.
   For negotiation of a media description, the four profiles AVP,
   AVPF, SAVP, and SAVPF are mutually exclusive.  Note, however, that
   SAVP and SAVPF entities MAY be mixed in a single RTP session (see
   section 4).  Also, the offer/answer mechanism MAY be used to offer
   alternatives for the same media session (e.g. using the same
   transport parameters and multiple media descriptions) and allow 
                        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   the answered to choose one of the profiles.

Also, in section 1.1, the description of (SDP) media description could
be clarified with something like:

   (SDP) media description:
        This term refers to the specification given in a single m=
        line in an SDP message.  An SDP media description may define
        only one RTP session.  Grouping of m= lines in SDP (each with 
                                                           ^^^^^^^^^^
        their own distinct transport address as described in [9]) may
cause
        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
        several SDP session level descriptions to define (alternatives
        of) the same RTP session for the same media type.
 
Or something along those lines.

Thanks, and sorry for the confusion.

> From: Joerg Ott [mailto:[email-masked]] 
> Sent: Saturday, October 28, 2006 1:20 AM
> To: Dan Wing
> Cc: [email-masked]; 'Joerg Ott'; [email-masked]; 'Flemming 
> Andreasen'; 'Hadriel Kaplan'; Audet, Francois (SC100:3055); 
> [email-masked]
> Subject: Re: alternate RTP profiles in SDP offer/answer
> 
> Dan,
> 
> 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.
> 
>  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.
> 
> Joerg
> 
> > draft-ietf-avt-profile-savpf-09 mentions, in several 
> places, how ports 
> > can be overloaded and grouping can be used to specify RTP/SAVP and 
> > RTP/SAVPF in the same offer.  The suggestions in 
> > draft-ietf-avt-profile-savpf-09 appear to have the drawbacks that 
> > Flemming describes in section 3.1 and 3.5 of 
> > draft-andreasen-mmusic-sdp-capability-negotiation-01.  It seems 
> > ill-advised for AVT to publish a document encouraging use 
> of mechanisms with these drawbacks, unless MMUSIC agrees with 
> this decision.
> > 
> > draft-ietf-avt-profile-savpf-09 at the upcoming MMUSIC meeting?  Or 
> > can we perhaps have a joint presentation by all five 
> authors so that 
> > MMUSIC can make an informed decision on this important topic?
> > 
> > -d
> > 
> > 
> > 
> >>http://www.ietf.org/internet-drafts/draft-ietf-avt-profile-s
> avpf-09.tx
> >>t
> > 
> > 
> 
>

---

From: "Dan Wing" <[email-masked]>
Date: Mon, 30 Oct 2006 14:58:08 -0800

> then please be precise of what you mean and we will be happy to

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.   

> 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

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 31 Oct 2006 13:06:37 -0800

> RFC4585, Section 4.4, Example 3 allows grouping of media 
> lines with the same transport address and port. I copied 
> it below FYI.  Even though RFC 3388 prohibits such 
> transport overloading, RFC 4585 allows such signaling for 
> profile negotiation (between RTP/AVP and RTP/AVPF).

Are we going to declare RFC4585's example normative?

> Indeed, RFC4585 is referring to RFC 3388 for such grouping. 
> Per RFC4585,
> overloading two "m=" lines isn't a violation of the standard when
> negotiating RTP/AVP and RTP/AVPF profiles. 

Unfortunately, though, SDP parsers that don't implement
RFC4585 aren't aware of RFC4585's permission to do this.

> It is an already established
> concept in RFC4585. Probably there are existing implementations which
> already support such signaling. Any new signaling solution can only be
> an alternative to the solution used in the following example.

Is there consensus in MMUSIC with that position?

-d

> --->
>   m=video 51372 RTP/AVP 98 99
>       c=IN IP4 224.2.1.184
>       a=rtpmap:98 H263-1998/90000
>       a=rtpmap:99 H261/90000
>       m=video 51372 RTP/AVPF 98 99
>       c=IN IP4 224.2.1.184
>       a=rtpmap:98 H263-1998/90000
>       a=rtpmap:99 H261/90000
>       a=rtcp-fb:* nack
>       a=rtcp-fb:98 nack rpsi
> Note that these two m= lines SHOULD be grouped by some appropriate
>    mechanism to indicate that both are alternatives actually conveying
>    the same contents.  A sample framework by which this can be
>    achieved is defined in [10].
> 
> 
> > From: [email-masked] [mailto:owner-ietf-
> > [email-masked]] On Behalf Of Dan Wing
> > Sent: Monday, October 30, 2006 2:58 PM
> > To: 'Joerg Ott'
> Andreasen';
> > 'Hadriel Kaplan'; 'Francois Audet'; [email-masked]
> > Subject: RE: alternate RTP profiles in SDP offer/answer
> > 
> > 
> .
> > 
> > -----
> > 
> > 2.  Section 3.3.2:
> >

---

From: "Desineni, Harikishan" <[email-masked]>
Date: Tue, 31 Oct 2006 11:50:37 -0800

RFC4585, Section 4.4, Example 3 allows grouping of media lines with the
same transport address and port. I copied it below FYI. Even though RFC
3388 prohibits such transport overloading, RFC 4585 allows such
signaling for profile negotiation (between RTP/AVP and RTP/AVPF).
Indeed, RFC4585 is referring to RFC 3388 for such grouping. Per RFC4585,
overloading two "m=" lines isn't a violation of the standard when
negotiating RTP/AVP and RTP/AVPF profiles. It is an already established
concept in RFC4585. Probably there are existing implementations which
already support such signaling. Any new signaling solution can only be
an alternative to the solution used in the following example.

--->

Andreasen';
.

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 31 Oct 2006 13:06:37 -0800

-d

---

From: "Desineni, Harikishan" <[email-masked]>
Date: Tue, 31 Oct 2006 11:50:37 -0800

--->

Andreasen';
.