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

From: Joerg Ott <[email-masked]>
Date: Thu, 02 Nov 2006 16:44:02 +0200

Hi Dan,

> 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.

Good observation.  I will need to check where this came from.

> -----
> 
> 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.

I would argue (and hope!) that 7.5.3 has different semantics.  From the
text, it only applies to a way of representing multiple codecs.

However, as I pointed out in my mail to Francois, there is a legitimate
use case for the same transport address: AVP and AVPF can be mixed in
a single session as can be SAVP and SAVPF.  They have been designed this
way for multicasting.

If you would disallow offering clearly marked alternatives (using a
yet tbd grouping), you can no longer support both old and new clients
in the same multicast group.  But you would clearly not want to send
the media stream twice as the new clients would maintain their feedback
functionality.

> -----
> 
> 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.

Well, this is not what it is supposed to say.  You assert that this
statement applies to the session description but, in fact, it applies
to the RTP entities in the media session.

And there they are incompatible and must not be used together.

I guess the major take-away from this discussion is that the
specification is not sufficiently clear in when it talks about
what.  So, I believe this requires a cleanup and some more
expressiveness rather than technical changes here.

> 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.

This is indeed true.

> -----
> 
> 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. 

Which continues to read:

    Note that a future grouping mechanism will allow to explicitly
    identify these as alternatives in the session description.

One could just add that this description would be misleading for
the client unless an explicit grouping is invented.  Or follow
your suggestion below.

> 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?

One can do this.  It will probably not lo

> -----
> 
> 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.

Thanks, well taken.  I will go through all the list discussion
and come up with a revised version.  While I am already more
than busy next week, maybe we can still find a moment to sit
together and go through the changes.  You have done very good
catches, looking at the spec from a slightly different angle.
So, I'll be more than happy to jointly figure out the last bits.

> 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.

Colin and myself tried to initiate some broader grouping discussion
quite some time ago (at least a year) as we clearly saw a need to
do something more explicit here -- which would also allow the
SAVPF draft to show better examples.  Neither of us had the cycles
but maybe we can do something together here as well.  May I volunteer
you? :-)

Cheers,
Joerg

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

---

From: Joerg Ott <[email-masked]>
Date: Thu, 02 Nov 2006 16:54:24 +0200

Hi,

> 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.

well, as I mentioned before, RFC 3388 section 7.5.3 says something
about how to represent codecs.

Next, RFC4585 does not establish any practice but clearly states after
the example:

    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].

Furthermore, this is an example with outlined limitations.  There is
no normative language to that end whatsoever in RFC 4585.

> --->
>   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].
> 

Finally, semantically, in this case, the transport address MUST BE THE
SAME.  The text speaks about a multicast group and AVP and AVPF are
compatible.  I.e., they can be mixed in the same media session (see
section 5 of RFC 4585).  Obviously, you can only achieve allowing
clients with different capabilities to use the same stream if you
specify equal addresses.

What RC 4585 does not do is making semantic assertions that this
is they way to go.  For the very reason that overloading semantics
of fields is usually not a good idea.

Joerg