Subject: [AVT] Comments and questions about draft-ietf-avt-rtp-g729-scal-wb-ext-03.txt

From: "Kang Tae-Gyu" <[email-masked]>
Date: Wed, 29 Mar 2006 15:57:31 +0900

Hi,

I think this draft is so nice to become RFC.

I would like to give comments and questions about draft-ietf-avt-rtp-g729-scal-wb-ext-03.txt.

1. The draft says in Chapter 3;

"Note that it is only useful for two-way G.729EV traffic, since the MBS request is piggy-backed over the speech frames in the reverse direction."
I am confused this sentense.

Which side is the MBS request? caliing party or callee party? why does it need reverse direction?

I think if you describe more detail mechanism, it would be better.

2. The draft says in Chapter 4;

"The RTP timestamp clock frequency is the same as the sampling frequency, that is 16 kHz.  So the timestamp unit is in samples. The duration of one frame is 20 ms, ..."

If FT is 0 or 1, are the sampling rate 8kHz? because those are narrow band.

3. The draft says in Chapter 4;

"If DTX is used, the first packet of a talkspurt,.."

What does it mean "talkspurt"?

I could  not find the word in English dictionary.

4. The draft says in Chapter 5;

"one ore more frames at the same bit rate" - -> one or more frames

I believe "e" should be eliminated.

5. What is usecase of MBS at 5.2?

I think FT has enough information for a codec media transmission between calling and calle party.

6. How does frame size come from? How does the frame size calculate ?

Is th frame size real RTP payload length?

7. What's the use case of nb_frames?

8. What's the use case of mbs=26000?

m=audio 51258 RTP/AVP 99
a=rtpmap:99 G729EV/16000
a=fmtp:99 dtx=0; mbs=26000
a=ptime:40
Do you believe that mbs=26000 can be used in real world?

9. If calling party sends below SDP information to callee party and callee party responds with a=rtpmap:18 G729/8000,

m=audio 55954 RTP/AVP 98 18
a=rtpmap:98 G729EV/16000
a=rtpmap:18 G729/8000
Which codec calling party invoke, G.729 or G.729EV FT=0(encoding rate = 8kbps)?

10. I know the narrow band G.729 can support VAD(Voice Act Detection) and PLC(Pack Loss Consealment), but G.729EV can not support VAD and PLC. Am I right?

Cheers,

Kang

----------------------------------
ETRI, Multimedia Communications Team
BcN Core Technology Group
Broadband Convergence Network Research Division
Principal Member of Engineering Staff
Ph.D, Professional Engineer
Kang Tae-Gyu
[email-masked] <mailto:[email-masked]>
+82-42-860-5232, FAX:+82-42-860-5440, 016-451-2968
----------------------------------

This is to announce a working group last call on the RTP payload format for the G.729EV audio codec (draft-ietf-avt-rtp-g729-scal-wb- ext-03.txt). Please send any final comments on this draft to the mailing list before 3rd April 2006. If no substantive issues are raised by that time, we will request the IESG publish this as a proposed standard RFC.

Colin

_______________________________________________
Audio/Video Transport Working Group
avt at ietf.org
https://www1.ietf.org/mailman/listinfo/avt

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

---

From: "SOLLAUD Aurelien RD-TECH-LAN" <[email-masked]>
Date: Fri, 31 Mar 2006 13:50:02 +0200

Hi
See my answers below ([AS]) 

Regards
Aurelien

________________________________

	De : Kang Tae-Gyu [mailto:[email-masked]] 
	Envoyé : mercredi 29 mars 2006 08:58
	À : [email-masked]; SOLLAUD Aurelien RD-TECH-LAN
	Cc : [email-masked]; [email-masked]
	Objet : [AVT] Comments and questions about draft-ietf-avt-rtp-g729-scal-wb-ext-03.txt 

	Hi, 

	 

[AS] I agree the sentence you quote is not very clear.
The MBS is not a matter of calling or callee. When A sends an in-band MBS to B, it is to request B to modify its sending bit rate, that is for the stream from B to A. 
So if there is no stream in the direction B->A, the MBS sent by A will have no effect.

[AS] the sampling rate of the codec is always 16kHz, that is the the ITU Terms of Reference for G.729EV.
An implementation may provide a 8kHz front-end but for the RTP transport the clock is always 16 kHz, no matter what bit rate is used. The receiver does not need to know what was the original sampling rate to decode.
It would not have been correct to change RTP clock on-the-fly if you go from 8-12 kbps (narrowband) to 14-32 kbps (wideband) and vice versa. So the RTP clock is always 16 kHz. We had such discussion on the list for VMR-WB, you may read section 3.1 of RFC 4348.

[AS] "Talkspurt" is used in RFC 3551 and a lot of audio payload format. It is explained in the following words of the sentence you quote : "the first packet of a talkspurt, that is, the first packet after a silence period during which packets have not been transmitted contiguously"
(look for "spurt")

[AS] right.

[AS] FT is enough to describe the stream, but MBS is an additional functionnality to request the other party to change its sending rate. See section 3 for a use case.

[AS] the frame size comes from FT, as per the table in section 5.3

[AS] you may encapsulate several frames in a signe RTP packet, nothing more in nb_frames.

[AS] it was just a synctatical example. Anyway you may have bandwidth-sharing scenario where 26000 is a good value at a certain time.

[AS] as stated in section 6.3, "the conversation will be done using G.729 (the payload format for G.729 is defined in RFC 3551 [4])".
To produce and decode G.729 frames, the calling party may use the G.729EV codec at 8 kbps, with the limitation that the frame size of G.729EV is 20 ms so if the callee sends 10 ms G.729 packets, they will be decoded 2 by 2.

[AS] VAD is not supported for the first version of G.729EV, that is in the draft.
But G.729EV has a built-in PLC.

[AS] By the way, that make me think I should add a line a=fmtp:18 annexb=no for the G.729/G.729EV interoperability scenario, to disable the VAD if G.729 is chosen. 

	Cheers,

	Kang

	[email-masked] <mailto:[email-masked] <mailto:[email-masked]> >

	Colin

	_______________________________________________
	Audio/Video Transport Working Group
	avt at ietf.org
	https://www1.ietf.org/mailman/listinfo/avt
		 <http://umail.etri.re.kr/External_ReadCheck.aspx?email=[email-masked]&name=aurelien.sollaud%40francetelecom.com&fromemail=[email-masked]&messageid=[email-masked]%3E>