Subject: [AVT] Working Group Last Call: draft-ietf-avt-rfc3047-bis-06.txt

From: Tom Taylor <[email-masked]>
Date: Thu, 19 Jun 2008 09:39:36 -0400

This is to announce WGLC for draft-ietf-avt-rfc3047-bis-06.txt, RTP Payload 
Format for ITU-T Recommendation G.722.1. Please send any comments to the list. 
WGLC will close on July 3 if no issues are identified.

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

---

From: <[email-masked]>
Date: Tue, 24 Jun 2008 16:38:41 +0200

Hi

I have few comments on this draft:

3.1) for timestamp, something should be added on the clock rate. It seems it is either 16000 or 32000.

3.2) "An application MAY switch bit rates
   from packet to packet by defining two payload type values and
   switching between them."
-> it is not limited to 2 

4.1.1) a "rate" parameter must be defined in the media type registration, with 16000 or 32000 as possible values

7) "The new draft updates RFC3047..." 
-> in terms of RFC publication, I guess the intent is to obsolete 3047 ?

Cheers,
Aurelien

> -----Message d'origine-----
> De : [email-masked] [mailto:[email-masked]] De la 
> part de Tom Taylor
> Envoyé : jeudi 19 juin 2008 15:40
> À : IETF AVT WG
> Cc : [email-masked]; Roni Even
> Objet : [AVT] Working Group Last Call: 
> draft-ietf-avt-rfc3047-bis-06.txt
> 
> This is to announce WGLC for 
> draft-ietf-avt-rfc3047-bis-06.txt, RTP Payload Format for 
> ITU-T Recommendation G.722.1. Please send any comments to the list.

---

From: "Even, Roni" <[email-masked]>
Date: Tue, 24 Jun 2008 17:54:57 +0300

Aurelien,
Thanks for the review, see in line
Roni

> -----Original Message-----
> From: [email-masked]
> [mailto:[email-masked]]
> Sent: Tuesday, June 24, 2008 5:39 PM
> To: [email-masked]; [email-masked]
> Cc: [email-masked]; Even, Roni
> Subject: RE: [AVT] Working Group Last Call: draft-ietf-avt-rfc3047-bis-
> 06.txt
> 
> Hi
> 
[RE:] I will add it

> -> it is not limited to 2
[RE:] It is from the RFC3047 that had two bit rates. I will change to "An application MAY switch bit rates and clock rates from packet to packet by defining different payload type value and switching between them."

> 4.1.1) a "rate" parameter must be defined in the media type
> registration, with 16000 or 32000 as possible values

[RE:]Only the bit rate is needed and is defined. The 16000 and 32000 are clock rates and are part of the rtpmap parameter. See example in section 5.1
> -> in terms of RFC publication, I guess the intent is to obsolete 3047
[RE:] Yes

---

From: <[email-masked]>
Date: Wed, 25 Jun 2008 09:33:52 +0200

> [RE:]Only the bit rate is needed and is defined. The 16000 
> and 32000 are clock rates and are part of the rtpmap 
> parameter. See example in section 5.1

Roni,

IMO, when multiple values are possible, the "rate" parameter must appear
in the media type registration as a required parameter.

See RFC 4855 Section 2 :

     Required parameters:
          If the payload format does not have a fixed RTP timestamp
          clock rate, then a "rate" parameter is required to specify the
          RTP timestamp clock rate.  A particular payload format may
          have additional required parameters.

I agree that is actually mapped in the SDP rtpmap

(Section 3)
      o  The general (possibly optional) parameters "rate" and
         "channels" also go in "a=rtpmap" as clock rate and encoding
         parameters, respectively.

Aurelien

---

From: "Even, Roni" <[email-masked]>
Date: Wed, 25 Jun 2008 10:40:30 +0300

Aurelien,
I think that in this case we have a fix rate since each payload type
uses just one rate, so the rtpmap parameter uniquely defines it.
Roni

> Sent: Wednesday, June 25, 2008 10:34 AM
> To: Even, Roni; [email-masked]; [email-masked]
> Cc: [email-masked]

---

From: <[email-masked]>
Date: Wed, 25 Jun 2008 10:20:59 +0200

We agree on the fact that the rate is clearly defined in SDP by rtpmap. That is SDP.
My comment here is for the media type registration itself.

For example if I have the media description "audio/G7221 bitrate=32000"
I don't know how to map it to SDP because I don't know if the RTP clock rate is 16000 or 32000. I need the "rate" parameter to know it.
e.g. "audio/G7221 rate=16000; bitrate=32000" is OK.

I think it is just a matter of formal description, it does not affect the rest of the draft to add the rate parameter.

See RFC4598 S5.1 for example. It defines 3 possible rates in the "rate" parameter. I think it is the same for your draft.

Aurelien

> De : Even, Roni [mailto:[email-masked]] 
> Envoyé : mercredi 25 juin 2008 09:41
> À : SOLLAUD Aurelien RD-CORE-LAN; [email-masked]; [email-masked]
> Cc : [email-masked]
> Objet : RE: [AVT] Working Group Last Call: 
> I think that in this case we have a fix rate since each 
> payload type uses just one rate, so the rtpmap parameter 
> uniquely defines it.
> Roni
> 
> > > [RE:]Only the bit rate is needed and is defined. The 
> 16000 and 32000 
> > > are clock rates and are part of the rtpmap parameter. See 
> example in 
> > > section 5.1
> > 
> > Roni,
> > 
> > IMO, when multiple values are possible, the "rate" parameter must 
> > appear in the media type registration as a required parameter.
> > 
> > See RFC 4855 Section 2 :
> > 
> >      Required parameters:
> >           clock rate, then a "rate" parameter is required 
> to specify 
> > the

---

From: Colin Perkins <[email-masked]>
Date: Wed, 25 Jun 2008 19:23:57 +0100

Right - the clock rate in the SDP takes the value of the "rate" media  
type parameter.

Colin

On 25 Jun 2008, at 09:20, <[email-masked]> wrote:
> I don't know how to map it to SDP because I don't know if the RTP  
> clock rate is 16000 or 32000. I need the "rate" parameter to know it.
> I think it is just a matter of formal description, it does not  
> affect the rest of the draft to add the rate parameter.
>
> See RFC4598 S5.1 for example. It defines 3 possible rates in the  
> "rate" parameter. I think it is the same for your draft.
>
> Aurelien
>

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

---

From: "Even, Roni" <[email-masked]>
Date: Thu, 26 Jun 2008 09:25:03 +0300

Hi,
This will cause a backward computability problem.
Adding a mandatory parameter will break existing implementations that use RFC3047.
I assume that if having the rate is a MUST I will need to have two payload subtype (G711 and G711C) or do you have another suggestion.
Roni  

> From: Colin Perkins [mailto:[email-masked]]
> Sent: Wednesday, June 25, 2008 9:24 PM
> To: <[email-masked]>
> Cc: Even, Roni; [email-masked]; [email-masked]; avt-
> [email-masked]
> Subject: Re: [AVT] Working Group Last Call: draft-ietf-avt-rfc3047-bis-
> 06.txt
>

---

From: <[email-masked]>
Date: Thu, 26 Jun 2008 09:18:27 +0200

Maybe you can define it as an optionnal parameter and define 16000 as default value.

I saw that in some other media type reg.

Aurelien 

> Envoyé : jeudi 26 juin 2008 08:25
> À : Colin Perkins; SOLLAUD Aurelien RD-CORE-LAN
> Cc : [email-masked]; [email-masked]; [email-masked]
> I assume that if having the rate is a MUST I will need to 
> have two payload subtype (G711 and G711C) or do you have 
> another suggestion.
> Roni  
> 
> > Subject: Re: [AVT] Working Group Last Call: 
> > draft-ietf-avt-rfc3047-bis- 06.txt
> > 
> > On 25 Jun 2008, at 09:20, 
> <[email-masked]> wrote:
> > >> De : Even, Roni [mailto:[email-masked]] Envoyé 
> : mercredi 
> > >> 25 juin 2008 09:41 À : SOLLAUD Aurelien RD-CORE-LAN; 
> > >> [email-masked];
> > [email-masked]
> > >> I think that in this case we have a fix rate since each payload 
> > >> type uses just one rate, so the rtpmap parameter 
> uniquely defines 
> > >> it.
> > >> Roni
> > >>

---

From: Randell Jesup <[email-masked]>
Date: Sun, 29 Jun 2008 22:01:48 -0400

>[RE:] It is from the RFC3047 that had two bit rates. I will change to "An
>application MAY switch bit rates and clock rates from packet to packet by
>defining different payload type value and switching between them."

I haven't been following this draft, but please check the AVT archives -
mixing clock rates in the same RTP stream (by switching between payloads
with different RTP timestamp rates) causes some real problems.

While in a perfect world with no packet loss this may seem ok, it's really
not. 

Consider the case of synchronization between two streams.  Normally this is
done via RTCP packets which provide RTP timestamp -> NTP time translation.
Now, if the RTP timestamp rate can change from one packet to the next, 
properly adjusting the inter-stream synchronization becomes impossible
if the wrong packets are lost.

For example:
m=audio 4567 RTP/AVP 99 100 101
a=rtpmap:99 foo/16000
a=rtpmap:100 foo/32000
a=rtpmap:101 telephone-event/8000

Payload   Sequence  Timestamp
99          0          0
99          1          320
99          2          640
<packets 3-8 lost>
100         9          3520

Now, you might be able to infer that packets 3-5 were type 99, and 6-8 were 
type 100.  But a) this is a tricky calculation to make, and prone to error
as you add codecs and bitrates, and b) there might be multiple solutions to
the problem - especially if there were a telephone-event packet in there.
If you can't figure out what the timestamp -> NTP relationship is, your
synchronization is screwed.

Even worse, you need that TS->NTP data even in order to play back packet 9
at the correct time, even in a single-stream case.

I have *strong* objections to mixing timestamp rates on a packet-by-packet
basis without some strong recommedations or guidelines on how to handle
all the edge cases.  If we could, I'd bump all the codecs up to the
lowest-common-multiple, though in some odd cases that could be too large,
at least in theory.  However, I'm certain huge numbers of endpoints would
barf on PCMU with a 32000 timestamp rate.

This was discussed in June of 2007 under the Subject: 
Re: [AVT] I-D ACTION:draft-ietf-avt-rtp-speex-01.txt

See my messages of June 20, 2007 for example:
(">>" is from me, ">" is Magnus' reply, and then my reply to him)

  >> The overloading of sample rate onto the timestamp rate for RTP for (most)
  >> audio codecs causes some real problems with certain cases.  Switching
  >> (in-call) between codecs with different sample rates -
  >> overloading means that playout time is tricky to calculate, and doubly so
  >> if there was a lost packet at the boundary.  (It also could significantly
  >> upset jitter buffers and the like, unless you do a full reset on codec
  >> shift.)  It may also complicate related RFCs like 2833, since 2833 is
  >> normally intermixed with regular codecs:
  >> m=audio 4321 RTP/AVP 98 99 100 101
  >> a=rtpmap:98 ILBC/8000
  >> a=rtpmap:99  G7221/16000
  >> a=rtpmap:100 G7221/32000
  >> a=rtpmap:101 telephone-event/8000
  >> (a=fmtp's would be needed too)
  >> Ok: what's the timestamp rate?  :-)  And when can it change?
  >
  >For this case to have a chance to work you need three telephone-event lines
  >like this:
  >  a=rtpmap:101 telephone-event/8000
  >  a=rtpmap:102 telephone-event/16000
  >  a=rtpmap:103 telephone-event/32000
  >
  >So that the packets sent is sent at the same timestamp rate as used by the
  >main codec.
  
  So long as none of the events span a timestamp rate change...
  
  I have a strong suspicion that including the above is likely to cause
  compatibility problems in practice (in addition to being lengthy, plus the
  related fmtp lines, and so adding to the overall SIP/UDP problem).
  
  Perhaps the real issue here comes down to a media stream is really a form
  of multiplexed channel.  Some payload "switches" are real switches, others
  are just passing additional streams of related data (like 2833 DTMF data).
  There are no limits on when payloads can switch, or on overlap between
  different payloads.  You *could* create a stream with 10 G.711 payloads,
  with all 10 arriving at all times, and each one being a different language.
  This might even be useful for RTSP, IPTV, etc.
  
  Now in practice devices won't overlap or even switch often, at least for
  VoIP devices, with rare exceptions like 2833.  Switches are usually to
  respond to network (or processor) impairments, quality, etc.  The probably
  works moderately well today in narrowband VoIP devices.  Mixing wideband
  (G.722/etc) into the mix really does confuse things if the device doesn't
  pick one at call setup and stick with it (or others of the same timestamp
  rate).
  
  Either we need to provide guidance on how to handle timestamp shifts, or
  we need to move away from them (tough), or we need to move away from
  timestamp rate == sample rate.  (Tough, but will help us in the long run.)

-- 
Randell Jesup, Worldgate (developers of the Ojo videophone), ex-Amiga OS team
[email-masked]
"The fetters imposed on liberty at home have ever been forged out of the weapons
provided for defence against real, pretended, or imaginary dangers from abroad."
		- James Madison, 4th US president (1751-1836)