Subject: Re: [AVT] DISCUSS and COMMENT: draft-ietf-avt-rtp-atrac-family

From: actech <[email-masked]>
Date: Tue, 07 Oct 2008 21:44:44 +0900

Discus:

Magnus,
Sorry for late response.

> Discuss:
> Section 4.5.2:
> 
> I think this section is missing to answer one important factor on 
how one determines which streams in each of the base and enhancement
RTP sessions that belong together. I get the strong impression that
the timestamp synch text is only discussing the issue of finding the
frames that belong to the audio stream frame position. The common solution
for this problem has been to either use CNAME bindings to find them or
require the same SSRC in both RTP session. I think the problem needs to be
discussed at least here.

Is it OK to expect that the same SSRC will be bound to the same CNAME?
If so, we will add the description of requiring the same SSRC in both
base and enhancement session in 4.5.2.

> Section 5.3.1: "This value SHOULD be zero for an unfragmented frame."
> Can someone please explain how any any other value than 0 can be allowed for 
an unfragmented frame. By the definition of the field all other values will be
interpreted as this being a fragment. Even if C=0 the inconsistency between having
the filed be seperate from 0 indicates that some fragements should have preceeded
this packet. And if that packet was lost one can't determine that previous packet
didn't contain a fragment. I suggest to change the SHOULD to a MUST.

We agree to change the word from "SHOULD" to "MUST".

> Section 7.6 Signaling of dependency for enhancements layers in offer/answer session. 
> The specification doesn't talk about signalling of that despite the fact that 
it is as useful to setup a session with offer/answer as with declarative usage.
Can you please motivate the choice of not talking about this for offer/answer?

The signaling of the dependency in Scalable multi-session streaming are
described in 7.8 as an example of offer/answer session referring [8] in
11.1 (Normative References).
We would like to have your comment if you think more description are needed.

> Comment:
> Section 5.3.1:
>    Number of Frames (NFrames): 4 bits
>    The number of audio frames in this packet.
> 
> Shouldn't this be defined as "The number of audio frames in this packet are field value + 1"?

Exactly! We will change the draft.

Thanks, Jun
_______________________________________________
Audio/Video Transport Working Group
[email-masked]
https://www.ietf.org/mailman/listinfo/avt

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 07 Oct 2008 16:05:58 +0200

> base and enhancement session in 4.5.2.

I think there is a point to actually ask the WG about this. We have done
 so in the past for certain cases. But as I am not on top of the latest
scalability discussion I think getting the WGs feedback on this is
preferred.

> We agree to change the word from "SHOULD" to "MUST".

Okay

> We would like to have your comment if you think more description are needed.

My point is that unless you define that this usage is allowed in the
offer/answer part of the usage rule you can't use them. An example is an
example and should show something that is defined. So I ask that the
definition in the offer/answer is made clear about this.

Also, I noticed that you had maxptime values that are fractional. I
agree that the SDP definition isn't clear that this is allowed or not.
But I do wonder if there are any implementations out there that support
this.

Best Regards

Magnus Westerlund

IETF Transport Area Director & TSVWG Chair
----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone +46 8 4048287
Färögatan 6                | Fax   +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: [email-masked]
----------------------------------------------------------------------
_______________________________________________
Audio/Video Transport Working Group
[email-masked]
https://www.ietf.org/mailman/listinfo/avt