[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [AVT] Proposed addition of time alignment for AMR in RFC 3267 bis
I'm wondering if this might be better abstracted into a payload-
format independent capability and use a framework like that in draft-
wenger-avt-avpf-ccm-02.txt?
Dave.
On Mar 1, 2006, at 5:10 PM, Ejzak, Richard P (Richard) wrote:
Hi all,
The editors of RFC 3267 bis are preparing a new draft for the
upcoming meeting and we propose to add an optional capability to
perform time alignment for AMR and WB-AMR. Unless there are
significant objections to this addition, the editors propose to add
time alignment to the new draft next week. Please provide any
comments or concerns with the proposed new capability.
Time alignment is useful in certain gateway-to-gateway scenarios
and certain gateway-to-VoIP-terminal scenarios. It is the ability
for a receiving gateway to request that the encoder shift the time
reference for encoding and packetization by a specified amount.
When a receiving gateway with strict packet timing limitations,
e.g., due to a 3G UMTS Iu interface, is connected to an encoder at
a peer endpoint capable of responding to time alignment requests,
e.g., with an AMR encoder associated with a PCM interface to the
PSTN, this allows the endpoints to reduce delay in the speech path
by as much as the 20 ms frame-block duration, depending on the
degree of misalignment in the time reference.
Note that time alignment is an optimization that reduces delay by
adjusting the sender's packet transmission phase so that the packet
arrives just in time for consumption. When the delay/jitter
statistics change substantially during a call, delay optimization
will benefit from re-invocation of time alignment once the jitter
buffer has adapted to the new delay/jitter statistics. However, to
avoid repeated requests for time alignment it is recommended to
issue a new time alignment request only after the delay/jitter
statistics have stabilized. In environments where the delay or
jitter continuously varies, the usefulness of time alignment is
significantly reduced. In this case the receiver will be out of
alignment most of the time, and sent requests may become dated even
before the media sender has managed to implement them.
We propose to implement this feature with the following additions
to RFC 3267 bis:
1) A new declarative payload format parameter "time-align=1" will
inform the peer entity if the sender of the parameter is capable of
receiving "time alignment requests" within speech frames.
2) An endpoint that wants to request a change in time alignment at
its peer will send a group of time alignment requests in a series
of speech frames using currently reserved values of the CMR field.
Three values are used to indicate time shifts of 10 ms, 5 ms or 1
ms, respectively. These are transmitted in such a way as to give
priority to actual changes in codec mode requests and to allow
transmission of time alignment requests during DTX.
3) If the receiver of a group of time alignment requests is
currently capable of changing the time alignment, it will send
subsequent speech frames using a new (later) time offset,
effectively introducing a gap in the media stream (unless it occurs
during DTX).
4) The receiver will play out the new frames at the same relative
time as previous frames, effectively reducing end-to-end delay to
the extent of the time alignment shift implemented by the sender.
Note that this assumes that there was and continues to be extra
delay in the playout buffer that can be absorbed by the shift in
time alignment.
This capability has the potential to be very useful in reducing
critical end-to-end delay for certain call scenarios.
BR Richard Ejzak
Lucent Technologies
_______________________________________________
Audio/Video Transport Working Group
avt at ietf.org
https://www1.ietf.org/mailman/listinfo/avt
_______________________________________________
Audio/Video Transport Working Group
avt at ietf.org
https://www1.ietf.org/mailman/listinfo/avt