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
[email protected]
Phone: +1.310.369.6696
10201 West Pico Blvd.
Los Angeles, CA 90035
On 10/27/16, 5:30 AM, "Christer Holmberg" <[email protected]>
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
_______________________________________________
Gen-art mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/gen-art
