Subject: [MMUSIC] SDP comments on draft-signh-avtcore-mprtp-02: Scope of the document

From: "Miguel A. Garcia" <[email-masked]>
Date: Thu, 18 Aug 2011 15:21:06 +0200

I have a general comment on the scope of the 
draft-signh-avtcore-mprtp-02. I think the document needs to provide a 
neat cut on scope.

At the moment I think that the intention of the authors is to include RTP 
and SDP as part of the scope, and presumably ICE. Fair enough.

Then, it is not acceptable to find normative statements outside the scope 
of the document, for example, those pertaining to SIP and RTSP, or even 
legacy implementations. Let me provide you examples:

- Section 4.1

    Session signaling (e.g., SIP [14], RTSP [15]) SHOULD be done over a
    failover-capable or multipath-capable transport for e.g., SCTP [10]
    or MPTCP [11] instead of TCP or UDP.

Comment: The scope of the document should not consider SIP, RTSP, and 
whether it is used over a failover-capable or multipath-capable 
transport. This could be described in other drafts, and actually RFC 4168 
already describes how to use SIP over SCTP.

- Section 6, 5th bullet point:

                                                    [Open Issue: What
        happens if the interface that setup the session disappears? does
        the control channel also failover? re-start the session?]

Same comment, not in the scope of the draft.

- Section 7.5

    [Note: If the original interface that setup the session disappears
    then does the session signaling failover to another interface?  Can
    we recommend that SIP/RTSP be run over MPTCP, SCTP].

- Section 11.2:

    To signal the use of MPRTP header extensions in SDP, the following
    URI MUST be used: urn:ietf:params:rtp-hdrext:mprtp.  Legacy RTP (non-
    MPRTP) clients MUST ignore this header extension, but continue to
    parse and decode the packet.

Comment: The second sentence puts a requirement ("MUST ignore") to legacy 
clients. How do you intend legacy clients to implement a requirement 
which has been written in the future (your document was written after the 
legacy client was put into operation). You can say that "it is expected 
that legacy RTP clients will ignore this header extension ....", but it 
is merely an expectation, not a requirement.

- Section 11.3, 1st bullet point:

   1.   Advertising ICE candidates: in the initial INVITE the endpoints
        exchange candidates, as defined in ICE [3].

Comment: replace "INVITE" "SDP offer", and then you are back within the 
scope of the document.

/Miguel

-- 
Miguel A. Garcia
+34-91-339-3608
Ericsson Spain