Subject: [AVT] Comments on draft-ietf-avt-rtp-gsm-hr-02

From: Tom Taylor <[email-masked]>
Date: Sat, 09 Jan 2010 10:05:53 -0500

I have a couple of comments on draft-ietf-avt-rtp-gsm-hr-02.

1. It seems to me that the redundancy scheme described in section 4.1 and the 
associated SDP are really not specific to this payload. It might make more sense 
to define SDP to negotiate/declare redundancy in a separate MMUSIC draft, so 
that other payloads can use it too.

2. There is a missing qualification in section 5.3.1. It currently reads:

   5.3.1.  Transmission of SID frames

       When using this RTP payload format the sender SHOULD generate and
       send SID frames every 160ms, i.e. every 8th frame.  Other SID
       transmission intervals may occur due to gateways to other systems
       that uses other transmission intervals.

At the end of the first sentence I would suggest adding "during silent periods".

Tom Taylor

---

From: "Belling, Thomas (NSN - DE/Munich)" <[email-masked]>
Date: Mon, 11 Jan 2010 14:01:31 +0100

Hi Tom,

I belive section 4.1 provides procedures that relate to the specific payload format in section 5.2 that allows to group several speech frames in one RTP packet as well as to the maxred MIME type parameter in Section 7.1.

While I could indeed imagine that similar mechanisms could be used for other RTP payload types, it is thus not entirely correct that this FEC mechanism is independent of the payload type and could be used for any RTP payload type.

Generic RTP FEC is already defined, e.g. in RFC 5109.
Is there need for yet another generic mechanism?

Thomas

---------------------------------- 
Dr. Thomas Belling 
3GPP Standardisation
Nokia Siemens Networks 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of ext Tom Taylor
Sent: Saturday, January 09, 2010 4:06 PM
To: IETF AVT WG; "'Duan Xiaodong(段晓东)'"; [email-masked]; Magnus Westerlund; 'Karl Hellwig (AC/EDD)'
Subject: [AVT] Comments on draft-ietf-avt-rtp-gsm-hr-02

1. It seems to me that the redundancy scheme described in section 4.1 and the associated SDP are really not specific to this payload. It might make more sense to define SDP to negotiate/declare redundancy in a separate MMUSIC draft, so that other payloads can use it too.

Tom Taylor

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

---

From: Tom Taylor <[email-masked]>
Date: Mon, 11 Jan 2010 08:33:27 -0500

I think you've answered your own question. If RFC 5109 is there, why did you
invent your own mechanism? I expect it was to save overhead. I'm sure there are
other payload types that operate in an environment where every octet counts,
redundancy is desirable, and you don't want to go to the trouble of applying
more sophisticated FEC methods.

I agree that not every payload type could use the procedures. But more than this
one could.

---

From: Roni Even <[email-masked]>
Date: Mon, 11 Jan 2010 15:52:21 +0200

Hi,
I think one way to address it is to do a bis draft on RFC 5109 adding this
specific case when the original and fec streams use the same encoder.
Roni Even as Individual

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Belling, Thomas (NSN - DE/Munich)
> Sent: Monday, January 11, 2010 3:02 PM
> To: ext Tom Taylor; IETF AVT WG; "'Duan Xiaodong(段晓东)'";
> [email-masked]; Magnus Westerlund; Karl Hellwig (AC/EDD)
> Subject: Re: [AVT] Comments on draft-ietf-avt-rtp-gsm-hr-02
> 
> Hi Tom,
> 
> I belive section 4.1 provides procedures that relate to the specific
> payload format in section 5.2 that allows to group several speech
> frames in one RTP packet as well as to the maxred MIME type parameter
> in Section 7.1.
> 
> While I could indeed imagine that similar mechanisms could be used for
> other RTP payload types, it is thus not entirely correct that this FEC
> mechanism is independent of the payload type and could be used for any
> RTP payload type.
> 
> To: IETF AVT WG; "'Duan Xiaodong(段晓东)'"; [email-masked];
> Magnus Westerlund; 'Karl Hellwig (AC/EDD)'
> 1. It seems to me that the redundancy scheme described in section 4.1
> and the associated SDP are really not specific to this payload. It
> might make more sense to define SDP to negotiate/declare redundancy in
> a separate MMUSIC draft, so that other payloads can use it too.
>

---

From: Magnus Westerlund <[email-masked]>
Date: Mon, 11 Jan 2010 17:40:00 +0100

Roni and Tom,

Regarding the "redundancy scheme" in GSM-HR. I agree to certain degree
that it is generic and can be used for any frame or sample based codec.
It is different from RFC 5109 as discussed in the document due to that
it requires you to use the same encoding as previously. Thus it is
simply overlap. For certain interpretations of RFC 3550 you could argue
that this would be possible without explicit signaling. We have chosen
to make it explicit. I would also point out that this is not the first
payload format to have this mechanism or even the text. AMR and AMR-WB
both have it. The text in this document I think comes from G.719 that
also have the mechanism.

I also would like to expand on the generality question here. If you do
this generic you get interesting signaling problems. Because you need to
describe the inter codec relationship if you apply it to all codecs.
Yes, you could do something on a single payload basis. But, then it is a
payload parameter, and then it could be part of the payload specs
anyway. Especially as you need to do depacketization prior to buffering
to get the most out of this.

I am not against anyone picking up this thread of generic specification
of this mechanism. I do not have the time to pick this up. I simply want
to deliver this format to 3GPP that needs it.

Cheers

Magnus

Roni Even skrev:
>> ext Tom Taylor

-- 

Magnus Westerlund

IETF Transport Area Director
----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  +46 10 7148287
Färögatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: [email-masked]
----------------------------------------------------------------------

---

From: Tom Taylor <[email-masked]>
Date: Tue, 12 Jan 2010 00:18:06 -0500

As you point out, RFC 3550 can be read as permitting this behaviour without
signalling. Indeed, that was how I interpreted it when I checked before putting
out my comment.

I'm not sure I see your point about the signalling problem. It seems to me that
one would specify that the meaning of the signalling is an agreement that
overlap (to some maximum extent) can occur between successive packets conveying
the same payload type. Agreed that when the sender switches between payload
types, redundancy requires some other solution, e.g., RFC 5109.

Bottom line: if I create an MMUSIC draft providing the necessary signalling:
-- would the WG at large consider this useful?
-- would the authors of GSM-HR feel that they did not have to add the max-red 
parameter?

If the first answer is "no", I should drop this point.

Tom Taylor

---

From: Magnus Westerlund <[email-masked]>
Date: Thu, 14 Jan 2010 14:17:31 +0100

> types, redundancy requires some other solution, e.g., RFC 5109.

Yes, that is the reasonable interpretation. The question is if you can
come to agreement on a common overlap between payload types. Likely not,
thus a per PT will probably work.

> -- would the WG at large consider this useful?

I think that would be useful to move to a common model. However, I am
not volunteering to bring it forward.

> -- would the authors of GSM-HR feel that they did not have to add the
> max-red parameter?

I would not object if it was ready and had passed WG last call. I don't
want our document to be held hostage in waiting for this document to be
completed. AVT has a buyer of this document that would like to get there
reference to exist properly.

Thus I do suggest that you investigate the support and availability of
someone holding the pen for a common attribute. But don't hold up the
GSM-HR payload format over this.

Cheers

Magnus Westerlund

---

From: Tom Taylor <[email-masked]>
Date: Wed, 20 Jan 2010 16:53:07 -0500

WGLC is complete. Authors, could you do the minor fix suggested in item 2 and 
resubmit?

I'll concede on the redundancy thing, but will submit a draft to MMUSIC so this 
doesn't have to be done again.

Tom Taylor

Tom Taylor wrote:
> and the associated SDP are really not specific to this payload. It might 
> make more sense to define SDP to negotiate/declare redundancy in a 
> separate MMUSIC draft, so that other payloads can use it too.
>

---

From: Magnus Westerlund <[email-masked]>
Date: Thu, 21 Jan 2010 09:43:25 +0100

Hi,

A new version have been submitted making the suggested change.

Thanks for the comments.

Magnus

Tom Taylor skrev 2010-01-20 22:53:
> WGLC is complete. Authors, could you do the minor fix suggested in item
> 2 and resubmit?
> 
> I'll concede on the redundancy thing, but will submit a draft to MMUSIC
> so this doesn't have to be done again.
> 
> Tom Taylor
> 
> Tom Taylor wrote:

-- 

Magnus Westerlund