[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
Do agree to Magnus.
Also that it is a enhancement feature, which originates in the 3GPP
circuit-switched domain (starting with AAL2/ATM, and 3GPP-specific framing
protocols IuFP and NbFP). Background should be considered when looking at
3267 extensions.
Personally I think that we should try to avoid the "emulation of 3GPP CS
framing protocol functionality" in RTP.
If there's an agreed requirement, then I'd like also ("as in below
referenced draft") to propose in considering first an RTCP-based signalling
of time alignment information.
Albrecht
Magnus Westerlund
<magnus.westerlund at er To: AVT <avt at ietf.org>
icsson.com> cc:
Subject: Re: [AVT] Proposed addition of time alignment for AMR in RFC 3267 bis
03.03.2006 10:33
Hi,
WG chair hat off!
Both David's and Chuck's email seem to me to relate to the same problem,
which has to do with synchronized playback of multiple streams. Where I
see two versions, multiple received streams need to be played backed at
the same time, and the case where multiple units need to play back
things in a synchronized way. Time alignment as existing today in
circuit switched networks is not the same problem.
Let look at Time alignment in AMR. Its origin is the circuit switched
GSM link for voice calls. That link enforces that speech is transmitted
with a periodic time of 20 ms. The data must be available every 20 ms or
you miss your time slot. As it is each base station that have this clock
there would buffering of up to 20 ms in that base station to keep that
schedule. To optimize this and remove this delay when possible a
procedure "time-alignment" was created that allows the base station to
request that the data delivery is done with a different phase to
minimize the buffering delay.
Things worth noting about time-alignment. It is all about of providing
data just in time. That exercise is difficult if there is varying delay
between the transmitting party and the consuming party. That was not a
problem for the circuit switched networks where also the links between
the radio network controller and the base station had fixed delay. This
becomes a bit more problematic in IP/UDP/RTP domain. My opinion is that
time-alignment procedures in RTP is useless unless you apply the
requirements of low delay variance to the underlying IP network. These
requirements I think can be satisfied primarily in a well controlled
environment, like a mobile operator's core network. Thus time alignment
applicability is limited to certain scenarios.
The use of time-alignment does not remove the need for a jitter-buffer
and to achieve high performance, and adaptive jitter-buffer. Which
results in that you have some interacting mechanisms. The jitter-buffer
will be part of the delay between the transmitting side and the
consuming side. Thus any adjustment of the jitter-buffer that result in
that delay changes results in a new optimal phase. This is an important
consideration to handle.
I would also like to point out that time-alignment is only usable when
the there is only one link having fixed time slots to adopt to between
the AMR encoding entity and the decoding entity. So two GSM or UMTS
links prevents this from being used.
I would also like to point out that any usage of time alignment or
similar procedures becomes impossible in cases where one encoding is
distributed to several receivers. It is strictly a procedure for point
to point sessions. In multi-party environments one will have to rely on
receiver side procedures.
If the WG thinks this feature with its limited applicability is worth
pursuing, I would be in favor for a more general mechanism.
From a glance through of
http://tools.ietf.org/wg/avt/draft-hdesineni-avt-avpf-ccm-pd-extn-00.txt
I think the authors of this draft is after doing something similar.
However also in this draft I think there is need for a consideration on
the applicability of the mechanism. What assumptions it makes of the IP
transport network. And what possibilities to action the sender and the
receiver can do to handle the problem(s).
Cheers
Magnus Westerlund
Multimedia Technologies, Ericsson Research EAB/TVA/A
----------------------------------------------------------------------
Ericsson AB | Phone +46 8 4048287
Torshamsgatan 23 | Fax +46 8 7575550
S-164 80 Stockholm, Sweden | mailto: magnus.westerlund at ericsson.com
_______________________________________________
Audio/Video Transport Working Group
avt at ietf.org
https://www1.ietf.org/mailman/listinfo/avt
###
"Ejzak, Richard
P (Richard)" To: AVT <avt at ietf.org>
<ejzak at lucent.co cc:
m> Subject: [AVT] Proposed addition of time alignment for AMR in RFC 3267 bis
01.03.2006 23:10
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