1 Mar 2008 02:22
Re: SSRC to DTLS-SRTP mapping
Dan Wing <dwing <at> cisco.com>
2008-03-01 01:22:23 GMT
2008-03-01 01:22:23 GMT
> On 21 Feb 2008, at 17:28, Dan Wing wrote: > ... > >>> Would dropping a DTLS packet on the floor if its source IP > >>> address and port are different from the DTLS handshake be > >>> acceptable? > >> > >> Yes, I think so. Why do you think it might not be? > > > > Because it is my understanding RTP does not allow similar filtering. > > RTP is certainly used in scenarios where such filtering is > inappropriate, but I don't think an end-point is prohibited from > filtering based on the source address. Ok. -d _______________________________________________ Audio/Video Transport Working Group avt <at> ietf.org https://www.ietf.org/mailman/listinfo/avt
Best Regards,
Jun Matsumoto
> The Working Group Last Call period expired for
> draft-ietf-avt-rtp-atrac-family-13 without comment on the AVT list. There was
> one objection on the Media Types list, that it is unacceptable to register a
> media type in the IETF tree without giving a reference to the source
> documentation. The submitting organization is discussing the matter.
>
> Here are my own comments. There are a few fixes that are essential, followed by
> a long list of trivial editorial changes.
>
> Issues that need fixing:
>
> 1. Numbering of fragments
>
> There is an inconsistency in the numbering of fragments. Section 5.3.1 says it
> starts from 0. Section 5.3.2.2, first sentence of the second paragraph, says
> that it starts from 1. The example in section 6.2 also shows it starting from 1.
> Before deciding too quickly what is the right answer, you should also think
> about and indicate in section 5.3.1 what the value should be for an unfragmented
> frame.
>
> 2. Normative language in section 7.5.2
>
> There is a "should", a "must", and a "recommended" (mis-spelled) in section
> 7.5.2 that should probably be capitalized. There is also a lower-case
> "recommended" near the end of section 7.5.3.
>
> 3. Cut-and-paste error in section 7.9?
>
> First example offer shows the same rtpmap description for payload types 98 and
> 99. Should payload type 99 be the same as in the answer?
>
> 4. Obsolete reference
>
> Your final normative reference [8] should now be to
> draft-ietf-mmusic-decoding-dependency-01.
>
>
> Trivial:
>
> - most I-Ds have the authors' organization (e.g., Sony Corporation) in the draft
> header. You're turning down a chance to put your organization's name in front of
> the public :)
>
> - section 1, first para first line: are designed -> is designed
> [to agree with "family"]
>
> - section 1, second para, fourth line: add comma at the end after "codecs"
>
> - section 4.1 third line: octect -> octet
>
> - section 4.4 second line: "decoding gap" by -> "decoding gap" at
>
> - section 4.4 again: I suggest adding a sentence: "For further details, see
> section 5.3.2.1." You could also consider adding a reference to RFC 2198 as a
> more sophisticated approach (implying a new informative reference).
>
> - I assume section 4.5.2 has multiple paragraphs, but the blank lines between
> them are missing. Anyway, in what appears to be the third para:
> can not -> cannot
> only with ignoring -> only, ignoring
>
> - section 5.1, second para (first after Figure 3), last sentence:
> In case of using redundant mechanism, -> When using the redundancy mechanism
> described in section 5.3.2.1,
>
> - section 5.2:
> Extention -> Extension
> In last line of timestamp description: sigalling -> signalling
>
> - section 5.3.1, Continuous flag:
> Might make more sense to call this the "Continuation flag", here and
> elsewhere in the document.
> fragmentaion -> fragmentation
>
> - section 5.3.2: is it too obvious to say that if multiple frames in a packet
> cover multiple sampling times, the frames must be ordered by increasing sample
> time? And as a consequence, when the redundancy mechanism of section 5.3.2.1 is
> used, the redundant frames come first and the timestamp corresponds to the
> sampling time of the oldest redundant frame. Also, probably should say that the
> frames in a packet, including the redundant ones, must cover a continuous time
> interval. The calculation in section 5.3.2.1 depends on these assumptions.
>
> - section 5.3.2 first para third line: preceeded -> preceded
>
> - section 5.3.2, block length description: final sentence could be confusing and
> should be deleted. The first para of the section already says that each frame is
> preceded by the Layer Type flag as well as the Block Length.
>
> - section 5.3.2.1 first para, second-last line:
> and to expand -> and warns it to expand
>
> - section 5.3.2.1, Figure 7:
> reciever -> receiver
> Exmaple -> Example
>
> - section 5.3.2.2, first to second lines of second para:
> packet, its -> packet with its
>
> - section 5.3.2.2, third para has its ideas in the wrong order, I think. I
> suggest that the para be rewritten to read:
>
> "Packets containing related fragmented frames MUST have identical
> timestamps. Thus, while the Continuous bit and Fragment Number fields
> indicate fragmentation and a means to reorder the packets, the
> timestamp can be used to determine which packets go together."
>
> - section 7.3, channelID description, second-last line:
> could be used -> could be used in this case
>
> - section 7.3, maxptime description:
> a multiple frames can not -> multiple frames cannot
> reciever -> receiver
>
> - section 7.4 first para: The Table 1. is explaining -> Table 1 explains
>
> - section 7.5.1, Media subtype:
> channels SHALL also be included -> channels (0 or 1) SHALL also be specified
>
> - section 7.5.3, remaining parameters bullet, fifth line:
> MUST be existing -> MUST be present
>
> - section 7.6, second line: either -> either of
>
> - section 7.7 first bullet:
> configuration(s) that is provided -> configuration(s) provided
>
> - section 7.7, final para, first sentence:
> scaleble -> scalable
> the attribute -> the attributes
>
> - section 9.1 first para: preferrable -> preferable
>
> - section 9.1 second para:
> for encryption affecting -> that encryption will affect
>
> - section 9.2 first line: due malicious -> due to malicious
>
> Tom Taylor
>
>
>
_______________________________________________
Audio/Video Transport Working Group
avt <at> ietf.org
RSS Feed