[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [AVT] draft-ietf-avt-rtp-cn-06



Hi Simao,

> I see your point but please keep in mind that a mandatory 
> minimum rate might
> break interoperability scenarios (say PSTN->VoIP->PSTN) if the systems
> outside the IP network behave differently from a "mandatory" setup.
> Additionally, this issue is very system-specific and I am not 
> aware of a
> well-accept threshold for it; some systems use every 5 
> seconds, others every
> 20s... It might be hard to nail down a number.

Even a large period of 20 secs would provide some useful properties. I am
doubtful that many RTP over UDP implementations would use a value this
large. Even sending a SID packet every 5 seconds is not going cause
excessive network traffic.

I understand the backwards compatibility issues but I would be interested to
find out just how many systems supporting CN today (over unreliable
transport protocols) really don't transmit every a SID packet at least as
often as an RTCP retransmit period, say 5-10 seconds.

CN is still only a draft. Requiring a minimum retransmission period over
unreliable transport would have significant benefits and I'm not convinced
it would break any reasonable implementations today.

> This might be a parameter negotiated/communicated at session 
> establishment,
> so both ends would know what to expect and adjust accordingly.

I'm sure it could but it really doesn't need to be - its yet another
parameter to be negotiated. Hey can we get an acronym for that? YAPTBN? :)

Robert.
 
> Best regards,
> Simao
> 
> > -----Original Message-----
> > From: Fairlie-Cuninghame, Robert [mailto:rfairlie@nuera.com]
> > Sent: 11 June 2002 18:57
> > To: 'avt@ietf.org'
> > Subject: [AVT] draft-ietf-avt-rtp-cn-06
> > 
> > 
> > Hi,
> > 
> > The current incarnation of the draft says:
> > 
> >    The CN packet update rate is left implementation 
> >    specific.  For example, the CN packet may be sent 
> periodically or 
> >    only when there is a significant change in the background noise 
> >    characteristics.
> > 
> > The latter scheme is undesirable when the transport is 
> > unreliable (as most
> > RTP currently is). Shouldn't the draft recommend a minimum 
> > update period?
> > This would also be beneficial given that endpoints may also 
> > rely on period
> > comfort noise packets for keeping firewall holes open, it 
> > would be nice if
> > there was a recommendation that they should be sent AT LEAST 
> > every so often.
> > 
> > Regards,
> > 
> > Robert.
> > 
> > _______________________________________________
> > Audio/Video Transport Working Group
> > avt@ietf.org
> > https://www1.ietf.org/mailman/listinfo/avt
> > 
> 

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