Subject: [AVT] I-D Action:draft-ietf-avt-rtp-g711wb-01.txt

From: [email-masked]
Date: Wed, 9 Apr 2008 03:00:01 -0700 (PDT)

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Audio/Video Transport Working Group of the IETF.

	Title           : RTP Payload Format for ITU-T Recommendation G.711.1
	Author(s)       : A. Sollaud
	Filename        : draft-ietf-avt-rtp-g711wb-01.txt
	Pages           : 15
	Date            : 2008-04-09

This document specifies a Real-time Transport Protocol (RTP) payload
format to be used for the International Telecommunication Union
(ITU-T) G.711.1 audio codec.  Two media type registrations are also
included.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-avt-rtp-g711wb-01.txt

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
_______________________________________________
Audio/Video Transport Working Group
[email-masked]
https://www.ietf.org/mailman/listinfo/avt

---

From: <[email-masked]>
Date: Wed, 9 Apr 2008 14:15:11 +0200

Hi

The ITU-T has approved G.711.1. Now a payload format RFC is needed.
I have updated the draft to update the reference and to fix some minor editorial things.

I believe draft-ietf-avt-rtp-g711wb-01.txt is ready for WGLC.

Thanks,
Aurelien

> -----Message d'origine-----
> De : [email-masked] [mailto:[email-masked]] De la 
> part de [email-masked]
> Envoyé : mercredi 9 avril 2008 12:00
> À : [email-masked]
> Cc : [email-masked]
> Objet : [AVT] I-D Action:draft-ietf-avt-rtp-g711wb-01.txt
> 
> This document specifies a Real-time Transport Protocol (RTP) 
> payload format to be used for the International 
> Telecommunication Union
> (ITU-T) G.711.1 audio codec.  Two media type registrations 
> are also included.
>

---

From: Colin Perkins <[email-masked]>
Date: Fri, 11 Apr 2008 21:43:29 +0100

Hi,

I had one question on this: what's the rationale for having both  
fixed and dynamic modes? It would seem you could have the same effect  
as the dynamic mode by signalling several RTP payload types, and  
changing RTP payload type when you want to change mode.

Colin

-- 
Colin Perkins
http://csperkins.org/

---

From: <[email-masked]>
Date: Tue, 15 Apr 2008 09:46:52 +0200

> 
> I had one question on this: what's the rationale for having 
> both fixed and dynamic modes? It would seem you could have 
> the same effect as the dynamic mode by signalling several RTP 
> payload types, and changing RTP payload type when you want to 
> change mode.
> 
> Colin
> 

Hi Colin,

I agree it seems equivalent and you can do everything with several fixed mode payload types. But in practice, it leads to some annoyances :
- it consumes a lot of payload types. If you want to declare the 4 current modes both in A-law and mu-law, it is 8 payload types. In the future we can expect more modes to be defined, like super-wideband quality, stereo... It will be 10, 12, ... payload types.
- it leads to a larger SDP, that could be a problem regarding the path MTU for SIP messages. Again, with more modes in the future, it will be worse.

G.711.1 is an embedded codec, all modes are supported by the standardized decoder, so there is no reason in my opinion to force separate payload type per mode. Dynamic mode currently is the default in the media type registration.
See RFC 4749 for G.729.1, it does not define a payload type per bit rate (12 would be needed). It is the same rationale.

In earlier (unpublished) version of the draft, I only defined the dynamic mode. Some reviewers have asked for a payload-header-free format, with fixed mode, so I added it. I think both have their use cases.

Do you think it is an issue to have the 2 options?

Regards,
Aurelien

---

From: Colin Perkins <[email-masked]>
Date: Wed, 16 Apr 2008 22:53:30 +0100

Hi Aurelien,

On 15 Apr 2008, at 08:46, <[email-masked]> wrote:
>
> I agree it seems equivalent and you can do everything with several  
> fixed mode payload types. But in practice, it leads to some  
> annoyances :
> - it consumes a lot of payload types. If you want to declare the 4  
> current modes both in A-law and mu-law, it is 8 payload types. In  
> the future we can expect more modes to be defined, like super- 
> wideband quality, stereo... It will be 10, 12, ... payload types.
> - it leads to a larger SDP, that could be a problem regarding the  
> path MTU for SIP messages. Again, with more modes in the future, it  
> will be worse.
>
> G.711.1 is an embedded codec, all modes are supported by the  
> standardized decoder, so there is no reason in my opinion to force  
> separate payload type per mode. Dynamic mode currently is the  
> default in the media type registration.
> See RFC 4749 for G.729.1, it does not define a payload type per bit  
> rate (12 would be needed). It is the same rationale.

If the decoder is guaranteed to always be able to decode every  
(future) mode, then it makes sense to use a single payload type.

> In earlier (unpublished) version of the draft, I only defined the  
> dynamic mode. Some reviewers have asked for a payload-header-free  
> format, with fixed mode, so I added it. I think both have their use  
> cases.
>

The problem with options is that they're optional, and so can lead to  
interoperability problems due to differing implementation choices. Is  
saving one octet really that important?

-- 
Colin Perkins
http://csperkins.org/

---

From: Hitoshi Ohmuro <[email-masked]>
Date: Thu, 17 Apr 2008 15:31:38 +0900

Dear Colin,

I am one of the reviewers who asked for a payload-header-free fixed-mode 
format. The purpose of fixed mode is not to save one octet but to limit 
  the mode range.

Dynamic mode format is useful. However, I think there are many equipment 
vendors (or use cases) that prefer that one mode is determined using SDP 
when a connection is established. A VoIP application will be much 
simpler if only one mode is used.

When one mode is determined using SDP, one-octet payload-header is 
redundant. Therefore, I proposed removal of the payload-header in case 
of fixed mode.

I think that definition of both dynamic mode and fixed mode is useful, 
as described in the draft.

There may be one ambiguousness. The draft describes that "fixed-mode=" 
parameter is optional. However, fixed mode is a subset of dynamic mode 
and is mainly used by low-end terminals. Therefore, all terminals should 
support at least fixed mode. If some terminals support only dynamic mode 
and some terminals support only fixed mode, interoperability problems 
will occur, as you wrote.

Best regards,

Hitoshi Ohmuro

---

From: <[email-masked]>
Date: Thu, 17 Apr 2008 09:20:09 +0200

Hi

Thank you for providing additional information on the motivation for fixed mode.

I think there is misinterpretation of the word 'optional' in this case.
The _parameter_ is optional in the media type registration, but the _support_ of fixed mode is mandatory.
I confess it may be not clear in the draft, I will state it with a MUST. Both modes are mandatory to implement (it is so easy !). Dynamic mode is the default (by nature of the codec), but fixed mode must always work if requested through signaling.

I hope it is clearer

Aurelien

> part de Hitoshi Ohmuro
> Envoyé : jeudi 17 avril 2008 08:32
> À : Colin Perkins
> Cc : [email-masked]
> Objet : Re: [AVT] WGLC request for G.711.1 payload format
> 
> Dear Colin,
> 
> I am one of the reviewers who asked for a payload-header-free 
> fixed-mode format. The purpose of fixed mode is not to save 
> one octet but to limit
>   the mode range.
> 
> Dynamic mode format is useful. However, I think there are 
> many equipment vendors (or use cases) that prefer that one 
> mode is determined using SDP when a connection is 
> established. A VoIP application will be much simpler if only 
> one mode is used.
> 
> When one mode is determined using SDP, one-octet 
> payload-header is redundant. Therefore, I proposed removal of 
> the payload-header in case of fixed mode.
> 
> I think that definition of both dynamic mode and fixed mode 
> is useful, as described in the draft.
> 
> parameter is optional. However, fixed mode is a subset of 
> dynamic mode and is mainly used by low-end terminals. 
> Therefore, all terminals should support at least fixed mode. 
> If some terminals support only dynamic mode and some 
> terminals support only fixed mode, interoperability problems 
> > On 15 Apr 2008, at 08:46, 
> <[email-masked]> wrote:
> >> current modes both in A-law and mu-law, it is 8 payload 
> types. In the 
> >> future we can expect more modes to be defined, like super- 
> wideband 
> >> quality, stereo... It will be 10, 12, ... payload types.
> >> separate payload type per mode. Dynamic mode currently is 
> the default 
> >> in the media type registration.

---

From: "Even, Roni" <[email-masked]>
Date: Thu, 17 Apr 2008 10:39:33 +0300

Aurelien,
I think that you should clarify this because my understanding from the text was that there is no mandatory requirement to support both and that if you do not specify mode parameter it means dynamic mode.
Now if both modes are mandatory to implement there is no reason to do fixed since both sides support dynamic and the dynamic payload format.

Maybe you should have one mode, the dynamic, one payload format and have as parameter to the mode the requested mode for the receiver.  

Roni

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> [email-masked]
> Sent: Thursday, April 17, 2008 10:20 AM
> To: [email-masked]; [email-masked]
> Cc: [email-masked]
> Subject: Re: [AVT] WGLC request for G.711.1 payload format
> 
> Hi
> 
> I confess it may be not clear in the draft, I will state it with a MUST.
> Both modes are mandatory to implement (it is so easy !). Dynamic mode is
> the default (by nature of the codec), but fixed mode must always work if
> requested through signaling.
> 
> I hope it is clearer
> 
> Aurelien
> 
>

---

From: <[email-masked]>
Date: Thu, 17 Apr 2008 12:12:15 +0200

>
> I think that you should clarify this because my understanding 
> from the text was that there is no mandatory requirement to 
> support both and that if you do not specify mode parameter it 
> means dynamic mode.
> Now if both modes are mandatory to implement there is no 
> reason to do fixed since both sides support dynamic and the 
> dynamic payload format.

Roni,
I agree things must be clarified in the draft.
Both modes are actually not mandatory, my mistake. Hitoshi Ohmuro was
correct in his previous mail.

From what is described in the draft for offer/answer (Section 5.3.1):
dynamic offer + dynamic answer = dynamic payload format
dynamic offer + fixed reponse = fixed payload format
fixed offer + fixed reponse = fixed payload format
fixed offer + dynamic reponse = prohibited

So, either you implement both dynamic and fixed mode, or you implement
only fixed-mode. Because the fixed-mode takes precedence, there is no
interoperability issue.
If you only implement dynamic, you can not talk to someone with only
fixed-mode. So dynamic-only must be prohibited in the draft.

As a conclusion, the current draft allows a fixed-only implementation.
As earlier mentioned by Hitoshi Ohmuro, it is interesting for some
vendors. I allows minimal implementation of the codec.

>
> Maybe you should have one mode, the dynamic, one payload 
> format and have as parameter to the mode the requested mode 
> for the receiver.  

If you negotiate a fixed mode, the 1-byte payload header becomes
useless, that is why I defined 2 payload formats. It avoids to transmit
a useless byte, nothing more. I found the complexity of the format was
low enough to allow it. It is easy to implement both formats.

But if there is a strong consensus that it is better to have a single
payload format even with, for some sessions, a useless 1-byte
information, why not.
My personal opinion is that unification is not needed, because the
formats are very easy.

Aurelien