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

[Joerg Ott <[e-mail]>]

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
[e-mail]
https://www1.ietf.org/mailman/listinfo/mmusic