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

From: Colin Perkins <[email-masked]>
Date: Tue, 4 Apr 2006 19:11:10 +0100

Aurelien,

Thanks. From the comments, it appears that a revised draft is needed  
with a number of clarifications.  Please submit such an update, then  
we'll issue another working group last call to ensure the group is  
happy with the revised wording.

thanks,
Colin

On 31 Mar 2006, at 12:50, SOLLAUD Aurelien RD-TECH-LAN wrote:

> 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,
> 	
> 	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.
>
> [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.
> 	
> 	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.
>
> [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.
> 	
> 	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.
>
> [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")
> 	
> 	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.
>
> [AS] right.
> 	
> 	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.
>
> [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.
> 	
> 	6. How does frame size come from? How does the frame size calculate ?
> 	Is th frame size real RTP payload length?
>
> [AS] the frame size comes from FT, as per the table in section 5.3
> 	
> 	7. What's the use case of nb_frames?
>
> [AS] you may encapsulate several frames in a signe RTP packet,  
> nothing more in 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?
>
> [AS] it was just a synctatical example. Anyway you may have  
> bandwidth-sharing scenario where 26000 is a good value at a certain  
> time.
>
> 	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)?
>
> [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.
>
> 	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?
>
> [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
>
> 	----------------------------------
> 	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]  
> <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
> 		 <http://umail.etri.re.kr/External_ReadCheck.aspx? 
> email=[email-masked]&name=aurelien.sollaud% 
> 40francetelecom.com&fromemail=[email-masked]&messageid=% 
> [email-masked]%3E>
>
>
> _______________________________________________
> Audio/Video Transport Working Group
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/avt

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

---

From: "Kang Tae-Gyu" <[email-masked]>
Date: Fri, 7 Apr 2006 15:45:31 +0900

Hi,

Thank  you for your nice answer.

All of my comments and questions are cleared.

I think that this draft is very useful document.

Thanks.

Kang

----------------------------------
From: "SOLLAUD Aurelien RD-TECH-LAN" <[email-masked]>
From Date: 2006-03-31 8:50:02
To: "Kang Tae-Gyu" <[email-masked]>, "[email-masked]" <[email-masked]>
Cc:
Subject: RE: [AVT] Comments and questions about draft-ietf-avt-rtp-g729-scal-wb-ext-03.txt

Hi

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,

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.

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

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.

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

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.

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

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

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

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?

[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

----------------------------------
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
<http://umail.etri.re.kr/External_ReadCheck.aspx?email=[email-masked]&name=aurelien.sollaud%40francetelecom.com&fromemail=[email-masked]&messageid=[email-masked]%3E>