DISCUSS and COMMENT: draft-ietf-avt-rtp-atrac-family

[Magnus Westerlund]

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.

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.

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?

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"?

_______________________________________________
Audio/Video Transport Working Group
avt@...
https://www.ietf.org/mailman/listinfo/avt

[actech]

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
avt@...
https://www.ietf.org/mailman/listinfo/avt

[Magnus Westerlund]

actech skrev:

> 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.

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.

>
>> 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".

Okay

>
>> 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.

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 [phone]
Färögatan 6                | Fax   [phone]
S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@...
----------------------------------------------------------------------
_______________________________________________
Audio/Video Transport Working Group
avt@...
https://www.ietf.org/mailman/listinfo/avt

[actech]

Discus:

Magnus,

Thank you for your comments advise.

>> 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.
>
> 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 didn't have any feedback from WG, so our idea of modification to
current draft is:

   In this case, it is REQUIRED to determine which sessions are paired
   together in receiver side. The solution for the problem is using
   CNAME bindings in RTCP session, or requiring the same SSRC in both
   RTP header.

Is it acceptable?

> 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.

We added the definition of grouping and dependency in scalable multi-session
streaming in chap.7.6.4.

> 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.

We changed the definition of the value of maxptime as
"rounding up of the fractional value" i.g. 23.2...ms to 24ms,
to clarify this problem.

We will submit revised version in soon, if there are no problem.

Regards,

> actech skrev:
>> 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.
>
> 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.
>
>>> 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".
>
> Okay
>
>>> 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.
>
> 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 [phone]
> Färögatan 6                | Fax   [phone]
> S-164 80 Stockholm, Sweden | mailto: magnus.westerlund@...
> ----------------------------------------------------------------------
>
>
>

_______________________________________________
Audio/Video Transport Working Group
avt@...
https://www.ietf.org/mailman/listinfo/avt

[Magnus Westerlund]

actech skrev:

> Discus:
>
> Magnus,
>
> Thank you for your comments advise.
>
>>> 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.
>> 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 didn't have any feedback from WG, so our idea of modification to
> current draft is:
>
>    In this case, it is REQUIRED to determine which sessions are paired
>    together in receiver side. The solution for the problem is using
>    CNAME bindings in RTCP session, or requiring the same SSRC in both
>    RTP header.
>
> Is it acceptable?

This seems way to vague for ensuring interoperable implementations. I
would require binding using same CNAME. You could also require the same
SSRC in the base and enhancement RTP sessions to allow speeded up
bindings, but it do have the potential for failure if the sessions are
translated without the knowledge that the both RTP sessions needs the
same SSRC mapping table.

>
>> 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.
>
> We added the definition of grouping and dependency in scalable multi-session
> streaming in chap.7.6.4.

Okay.

>
>> 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.
>
> We changed the definition of the value of maxptime as
> "rounding up of the fractional value" i.g. 23.2...ms to 24ms,
> to clarify this problem.
>

Ok

> We will submit revised version in soon, if there are no problem.

Good, I think you will need to be a bit clearer on the binding issue.

Cheers

Magnus Westerlund

IETF Transport Area Director & TSVWG Chair
----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  [phone]
Färögatan 6                | Mobile [phone]
SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@...
----------------------------------------------------------------------
_______________________________________________
Audio/Video Transport Working Group
avt@...
https://www.ietf.org/mailman/listinfo/avt

[actech]

Discus:

Magnus,
Thank you for your comments.

>>    In this case, it is REQUIRED to determine which sessions are paired
>>    together in receiver side. The solution for the problem is using
>>    CNAME bindings in RTCP session, or requiring the same SSRC in both
>>    RTP header.
>>
>> Is it acceptable?
>
> This seems way to vague for ensuring interoperable implementations. I
> would require binding using same CNAME. You could also require the same
> SSRC in the base and enhancement RTP sessions to allow speeded up
> bindings, but it do have the potential for failure if the sessions are
> translated without the knowledge that the both RTP sessions needs the
> same SSRC mapping table.

Okay, we will use CNAME binding in RTCP session only, instead of using
SSRC, i.e.

    In this case, it is REQUIRED to determine which sessions are paired
    together in receiver side. For paired base and enhancement layer
    session, the CNAME bindings in RTCP session MUST be applied using the
    same CNAME to ensure correct mapping to the RTP source.


Is it acceptable?

Regards,
_______________________________________________
Audio/Video Transport Working Group
avt@...
https://www.ietf.org/mailman/listinfo/avt

[Magnus Westerlund]

actech skrev:

> Discus:
>
> Magnus,
> Thank you for your comments.
>
>>>    In this case, it is REQUIRED to determine which sessions are paired
>>>    together in receiver side. The solution for the problem is using
>>>    CNAME bindings in RTCP session, or requiring the same SSRC in both
>>>    RTP header.
>>>
>>> Is it acceptable?
>> This seems way to vague for ensuring interoperable implementations. I
>> would require binding using same CNAME. You could also require the same
>> SSRC in the base and enhancement RTP sessions to allow speeded up
>> bindings, but it do have the potential for failure if the sessions are
>> translated without the knowledge that the both RTP sessions needs the
>> same SSRC mapping table.
>
> Okay, we will use CNAME binding in RTCP session only, instead of using
> SSRC, i.e.
>
>     In this case, it is REQUIRED to determine which sessions are paired
>     together in receiver side. For paired base and enhancement layer
>     session, the CNAME bindings in RTCP session MUST be applied using the
>     same CNAME to ensure correct mapping to the RTP source.
>
>
> Is it acceptable?
>

I don't see any problem with that.

Cheers

Magnus Westerlund

IETF Transport Area Director & TSVWG Chair
----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  [phone]
Färögatan 6                | Mobile [phone]
SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@...
----------------------------------------------------------------------
_______________________________________________
Audio/Video Transport Working Group
avt@...
https://www.ietf.org/mailman/listinfo/avt