Subject: [AVT] Proposed addition of time alignment for AMR in RFC 3267 bis

From: "Ejzak, Richard P (Richard)" <[email-masked]>
Date: Wed, 1 Mar 2006 16:10:37 -0600

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
[email-masked]
https://www1.ietf.org/mailman/listinfo/avt

---

From: David R Oran <[email-masked]>
Date: Wed, 1 Mar 2006 18:25:07 -0500

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.
>
> 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
>

---

From: "Tom-PT Taylor" <[email-masked]>
Date: Thu, 02 Mar 2006 11:31:24 -0500

I support the proposal to add time alignment -- it's definitely needed. 
I have further comments on the details -- I'll get back to you on that 
one later today.

Ejzak, Richard P (Richard) wrote:
> Hi all, The editors of RFC 3267 bis are preparing a new draft for the
> 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.
> 
> 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
> 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
> 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).
> 
> 
> 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.
> 
> BR Richard Ejzak Lucent Technologies
> 
> _______________________________________________ Audio/Video Transport
> Working Group [email-masked] https://www1.ietf.org/mailman/listinfo/avt
> 
> 
>

---

From: Chuck Harrison <[email-masked]>
Date: Thu, 02 Mar 2006 13:32:33 -0800

I believe that there *are* significant use cases for something
like Dave's "payload format independent capability". Long-time
participants in this forum will have heard my refrain before:

RTP's original design never addressed or intended to address the
issue of long-term phase correlation among sender and receiver
sample clocks. In neither theory nor practice are RTP media
sources or sinks expected to be phase synchronous to NTP time,
and drift does occur.

There is a large class of applications wherein the resulting
artifacts (dropped/repeated video frames, audio pops, drifting
inter-track synchronization) are negligible and the current
RTP architecture is sufficient. There is also a class of
applications (largely but not exclusively of "professional"
type) which do not tolerate such artifacts well and would benefit
from additional features supporting phase synchronization of
sources and receivers.

This task is nontrivial, as different use cases call for different
types of "pulling" or "pushing" sync. Existing practice in
professional video and audio production studios offers insight
into the type of time alignment capabilities that are likely to
be useful.

I do not know whether Dave's view of the issue is as broad as I
state here, but I concur with his assessment that this is a
"generic" capability that could beneficially apply to many if
not all of the payload formats transported over RTP.

I do recognize that 3G gateway implementors may be impatient
regarding the development of a "big picture" solution. But that's
why I started posting to avt on this topic about 5 years ago ;-).

Peace,
  Chuck Harrison

> > reference for encoding and packetization by a specified amount.
[...]

---

From: "Herlein Greg" <[email-masked]>
Date: Thu, 2 Mar 2006 13:46:35 -0800

> There is also a class of applications (largely but not exclusively of "professional" type) which do not tolerate such artifacts well and would benefit
> from additional features supporting phase synchronization of sources and receivers.

I concur completely.  I posted a few months ago about this topic asking for state of the art.  Our application involves multiple receivers that are on the same VLAN and are receiving the same multicast transmission - but viewers can see (and more importantly, hear!) from more than one end point at once.  If those end points get out of sync - even by a small amount - the viewer experience is less than satisfactory (echo effect mostly).  We'd like to see a standards-based solution to this problem.  I've been closely following the SMPTE time code approach in hopes it would lead the way to a solution.
 
What can I do to help this effort along?
 
Greg Herlein
Manager, Software Development
PRN (www.prn.com)

---

From: Colin Perkins <[email-masked]>
Date: Fri, 3 Mar 2006 00:06:06 +0000

On 2 Mar 2006, at 21:46, Herlein Greg wrote:
>> There is also a class of applications (largely but not exclusively  
>> of "professional" type) which do not tolerate such artifacts well  
>> and would benefit
> I concur completely.  I posted a few months ago about this topic  
> asking for state of the art.  Our application involves multiple  
> receivers that are on the same VLAN and are receiving the same  
> multicast transmission - but viewers can see (and more importantly,  
> hear!) from more than one end point at once.  If those end points  
> get out of sync - even by a small amount - the viewer experience is  
> less than satisfactory (echo effect mostly).

I assume you've seen J. Escobar, C. Partridge and D. Deutsch, Flow  
Synchronization Protocol, IEEE/ACM Transactions on Networking, Volume  
2, Number 2, April 1994?

> We'd like to see a standards-based solution to this problem.  I've  
> been closely following the SMPTE time code approach in hopes it  
> would lead the way to a solution.
>

Write an internet-draft outlining the problem you need to solve, and  
explaining why it can't be solved using existing standards. Show you  
have a community willing to work on solving the problem.  Then talk  
to the working group chairs and/or area directors, and we'll figure  
out how to charter the work so it can get published.

Colin