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