Re: [Gen-art] Gen-art LC review of draft-ietf-payload-rtp-ancillary-06

[Thomas Edwards <[e-mail]>]

Thanks very much for the Gen-ART LC review of draft-ietf-payload-rtp-ancillary-06!

Please see below for a list of comments, my responses, and my suggested draft changes.

Comment: "Section 3.1: The text talks about what the presence of DID and SDID means. But, as they are optional, what does it mean if they are NOT present?"
Response: Will add text regarding interpretation of non DID_SDID parameters.
Draft change: "The absence of the DID_SDID parameter signals that in order to determine the DID and SDID of ANC packets in the payload, the DID and SDID fields of each ANC packet must be inspected."

Comment: “Section 3.2: I would suggest that the section is renamed to “SDP Considerations”, and becomes a level 1 section (i.e., “4 SDP Considerations”).”
Response: OK
Draft change: "Mapping to SDP" becomes level 1 section "SDP Considerations", also "Offer/Answer Model and Declarative Considerations" becomes level 1 section.

Comment: “Section 3.2: Is it allowed to carry both a “normal” video stream and the ANC RTP payload within the same m= line? If so, how are they related?
    Example:
    v=0
    o=Al 123456 11 IN IP4 host.example.com
    s=Professional Networked Media Test
    i=A test of synchronized video and ANC data
    t=0 0
    m=video 50000 RTP/AVP 96 97
    c=IN IP4 233.252.0.1/255
    a=rtpmap:96 raw/90000
    a=fmtp:96 sampling=YCbCr-4:2:2; width=1280; height=720; depth=10
    a=rtpmap:97 smpte291/90000
    a=fmtp:97 DID_SDID={0x61,0x02};DID_SDID={0x41,0x05}"
Response: Per RFC 4566 regarding m-lines, “If the <proto> sub-field is "RTP/AVP" or "RTP/SAVP" the <fmt> sub-fields contain RTP payload type numbers.  When a list of payload type numbers is given, this implies that all of these payload formats MAY be used in the session, but the first of these formats SHOULD be used as the default format for the session.”  I believe there is no need to repeat RFC 4566 in this document.
Draft change: No change

Comment: "Section 3.2: Is it allowed to use two or more ANC RTP payloads (e.g., each using a different DID_SDID), either within a single m- line, or within different m- lines? If so, how are they related?"
Response: In a single m-line, the behavior is as specified in RFC 4566.  With different m-lines, multiple streams of ANC data can be grouped together with Lip Synchronization (LS) or other groupings.  I believe that this is defined by higher-order RTP and grouping protocols.
Draft change: No change

Comment: “Section 3.2: When I indicate DID_SDID, it is something I intend to SEND, or something I am willing to RECEIVE?"
Response: It depends how SDP is being used.  In an out-of-band or SAP implementation, it may be what kind of ANC data will be sent.  In an offer/answer model,
it might be what kind of ANC data can be received.  I believe that this is dependent on higher-order protocols beyond this RTP payload definition.
Draft change: No change

Comment: "Section 3.2:  If multiple DID_SDIDs are listed, can they be used in any order during the session? If so, it would be good to explicitly indicate that,
and note that the same payload type value will be used for all of them"
Response: Yes, there is no ordering implied by multiple DID_SDIDs.
Draft change: "Multiple DID_SDID parameters do not imply any particular ordering of the different types of ANC packets in the stream."

Comment: "Section 3.2:  Is there a possibility that the receiver does not understand DID_SDID, or specific DID_SDID values? If so, what shall it do?""
Response: I believe that this could apply to any RTP media type or specific sub-format described by media type parameters (such as sampling rate, frame rate, bandwidth, etc.) that a receiver does not understand, and is not defined within RTP.
Draft change: No change

Comment: "Section 3.2.1: The text says:

   ""The ANC RTP payload format will often be used in groupings with
   associated video streams.  Any legal SDP grouping mechanism could be
   used.""

   What is meant by the second sentence (“any legal SDP grouping)? Isn¹t the semantic depending on the type of grouping?"
Response: After consideration, I think it is best to limit this section to an example of LS grouping under RFC 6838 to be clear.
Draft change: Formerly: "The ANC RTP payload format will often be used in groupings with associated video streams.  Any legal SDP grouping mechanism could be used.  Implementers may wish to use the Lip Synchronization (LS) grouping defined in RFC 5888 [RFC5888], which requires that "m" lines that are grouped together using LS semantics MUST synchronize the playout of the corresponding media streams."
Change to: "To associate an ANC RTP stream with other media streams, implementers may wish to use the Lip Synchronization (LS) grouping defined in RFC 5888 [RFC5888], which requires that "m" lines that are grouped together using LS semantics MUST synchronize the playout of the corresponding media streams.”

Comment: “Section 3.2.1: What if the SDP group contains two (or more) video m= lines. Is the ANC RTP payload then associated with all of them?”
Response: RFC 5888 states "When a session description contains more than one "m" line, SDP does not provide any means to express a particular relationship
between two or more of them.", however, "lines that are grouped together using LS semantics MUST synchronize the playout of the corresponding media streams."
Draft change: No change

Comment: "Section 3.2.1: Could you rename the section title to ""Grouping ANC Streams with Video Streams”?"
Response: After consideration, I think it is best to retitle to "Grouping ANC Streams with other Media Streams", as the grouped streams could include audio, 
video, ANC, etc.
Draft change: Retitle "Grouping ANC data RTP Streams with Associated Video Streams" to "Grouping ANC Streams with other Media Streams"

Comment: "Section 3.3: You should say something about updating the parameters in a sub-sequent offer (or within an answer to an sub-sequent offer). Are there
any restrictions?"
Response: There are no restrictions on updating parameters in a subsequent offer.
Draft change: Add: "There are no restrictions on updating DID_SDID parameters in a subsequent offer."

Comment: “Section 3.3: What does it mean if one sends a sub-sequent offer/answer without some/all parameters. Does it mean they are disabled?"
Response: Yes.  "The presence of the DID_SDID parameters signals that all ancillary data packets of this stream are of a particular type or types"
Draft change: No change

Comment: “Section 3.3: Is it allowed to include ANC RTP in an answer if the offer doesn’t contain it?"
Response: No, "The answerer may respond with all or a subset of the streams offered along with fmtp lines with all or a subset of the DID_SDID parameters offered."
Draft change: No change

Comment: “Section 3.3:  Is it allowed to include DID_SDID in an answer if not included in the offer?"
Response: No, "The answerer may respond with all or a subset of the streams offered along with fmtp lines with all or a subset of the DID_SDID parameters offered."
Draft change: Typo found - change "a all" to just "all" Offer/Answer Model section

Comment: “Section 3.3:   Can the DID_SDID values in the answer be different than the ones in the offer, or are there any restrictions?”
Response: No, "The answerer may respond with all or a subset of the streams offered along with fmtp lines with all or a subset of the DID_SDID parameters offered."
Draft change: No change

-Thomas

-- 
Thomas Edwards 
VP Engineering & Development
FOX Networks Engineering and Operations
[e-mail]
Phone: [phone]
10201 West Pico Blvd.
Los Angeles, CA 90035

 

On 10/27/16, 5:30 AM, "Christer Holmberg" <[e-mail]> wrote:

    I am the assigned Gen-ART reviewer for this draft. For background on
    Gen-ART, please see the FAQ at
    <https://urldefense.proofpoint.com/v2/url?u=http-3A__wiki.tools.ietf.org_area_gen_trac_wiki_GenArtfaq&d=DQIFAw&c=uw6TLu4hwhHdiGJOgwcWD4AjKQx6zvFcGEsbfiY9-EI&r=lekNOOM5noV61zrPH3rwPyhtNnLLWoLEHgd0quQxly8&m=xsmDGgxhHslgj99Wo_od1kVlnCNRmeWa5uuPcCuIuvo&s=NNvezMeMrnCoKKdibLICb-i4GNXHX7AgCb-ZxDdO_lc&e= >
    
    Document:            draft-ietf-payload-rtp-ancillary-06
    Reviewer:            Christer Holmberg
    
    Review Date:         26 October 2016
    IETF LC End Date:    3 November 2016
    IETF Telechat Date:  N/A
    
    Summary:
    
    The document is well written, and is almost ready for publication as
    standards track RFC. However, I have some issue regarding the SDP sections
    (see below).
    
    Major Issues:           None
    
    Minor Issues:      
    
    Q0: Section 3.1:
    
        The text talks about what the presence of DID and SDID means. But, as
    they are optional, what does it mean if they are NOT present?
    
    
    Q1: Section 3.2:
    
        1) I would suggested that the section is renamed to ³SDP
    Considerations², and becomes a level 1 section (i.e., ³4 SDP
    Considerations²).
    
        2) Is it allowed to carry both a ³normal² video stream and the ANC RTP
    payload within the same m= line? If so, how are they related?
    
        Example:
    
        v=0
        o=Al 123456 11 IN IP4 https://urldefense.proofpoint.com/v2/url?u=http-3A__host.example.com&d=DQIFAw&c=uw6TLu4hwhHdiGJOgwcWD4AjKQx6zvFcGEsbfiY9-EI&r=lekNOOM5noV61zrPH3rwPyhtNnLLWoLEHgd0quQxly8&m=xsmDGgxhHslgj99Wo_od1kVlnCNRmeWa5uuPcCuIuvo&s=cxX37wG6tdBU3dGr1Z7Y7Ngh9Nezv39qmy5LbnXYAzo&e= 
        s=Professional Networked Media Test
        i=A test of synchronized video and ANC data
        t=0 0
        m=video 50000 RTP/AVP 96 97
        c=IN IP4 https://urldefense.proofpoint.com/v2/url?u=http-3A__233.252.0.1_255&d=DQIFAw&c=uw6TLu4hwhHdiGJOgwcWD4AjKQx6zvFcGEsbfiY9-EI&r=lekNOOM5noV61zrPH3rwPyhtNnLLWoLEHgd0quQxly8&m=xsmDGgxhHslgj99Wo_od1kVlnCNRmeWa5uuPcCuIuvo&s=SbqkLWBrXh72HkN_gLnzNDA5h8wm2unYpdy3_DcPrGQ&e= 
        a=rtpmap:96 raw/90000
        a=fmtp:96 sampling=YCbCr-4:2:2; width=1280; height=720; depth=10
        a=rtpmap:97 smpte291/90000
        a=fmtp:97 DID_SDID={0x61,0x02};DID_SDID={0x41,0x05}
    
        3) Is it allowed to use two or more ANC RTP payloads (e.g., each using
    a different DID_SDID), either within a single m- line, or within different
    m- lines? If so, how are they related?
    
        4) When I indicate DID_SDID, it is something I intend to SEND, or
    something I am willing to RECEIVE?
    
        5) If multiple DID_SDIDs are listed, can they be used in any order
    during the session? If so, it would be good to explicitly indicate that,
    and note that the same payload type value will be used for all of them.
    
        6) Is there a possibility that the receiver does not understand
    DID_SDID, or specific DID_SDID values? If so, what shall it do?
    
    
    
    Q2: Section 3.2.1:
    
       The text says:
    
       "The ANC RTP payload format will often be used in groupings with
       associated video streams.  Any legal SDP grouping mechanism could be
       used."
    
       1) What is meant by the second sentence (³any legal SDP grouping²)?
    Isn¹t the semantic depending on the type of grouping?
    
       2) What if the SDP group contains two (or more) video m= lines. Is the
    ANC RTP payload then associated with all of them?
    
       3) Could you rename the section title to "Grouping ANC Streams with
    Video Streams²?
    
    
    
    Q3: Section 3.3:
    
       1) You should say something about updating the parameters in a
    sub-sequent offer (or within an answer to an sub-sequent offer). Are there
    any restrictions?
    
       2) What does it mean if one sends a sub-sequent offer/answer without
    some/all parameters. Does it mean they are disabled?
    
       3) Is it allowed to include ANC RTP in an answer if the offer doesn¹t
    contain it?
    
       4) Is is allowed to include DID_SDID in an answer if not included in
    the offer?
    
       5) Can the DID_SDID values in the answer be different than the ones in
    the offer, or are there any restrictions?
    
    
    
    
    Editorial Issues:       None