[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