Subject: RE: [AVT] Issue with different timestamp frequencies

From: Franceschini Guido <[email-masked]>
Date: Tue, 31 Jan 2006 15:50:39 +0100

Magnus,

I have some concern on your suggested solution (i.e. to duplicate in SDP the offering of Payload Types for DTMF, FEC etc):

1) the SDP description becomes larger and larger. Although I know that SIP has mechanisms for carrying INVITEs (which include SDP) that exceed the MTU size, I also know that many implementation do not support such mechanism, and that the MTUsize is in the end an hard limit.

2) in case the number of frequencies increases, the solution does not scale well, since the multiplication factor might become excessive

3) to make your approach effective we need a rule to force a peer to select within a list of PTs only a set of PTs that share the same timestamp frequency. In my case, the SDP offer might become:

m=audio 50000 RTP/AVP 97 98 99 100
a=rtpmap:97 AMR/8000
a=rtpmap:98 AMR-WB/16000
a=rtpmap:99 telephone-event/8000
a=rtpmap:100 telephone-event/16000

and the answerer should either pick 97+99 or 98+100. However, there is currently no rule that forbids 98+99, and so -in the end- the proposed solution is not effective unless we amend the rules themselves.

An alternative idea (that might require to amend various specs) could be to allow for specific PTs such as DTMF, FEC etc to NOT specify a particular timestamp frequency: in such a case some rule would be applied for determining the timestamp frequency to use (e.g.: it might be the same timestamp frequency as the first PT that has been negotiated). In my example:

m=audio 50000 RTP/AVP 97 98 99
a=rtpmap:97 AMR/8000
a=rtpmap:98 AMR-WB/16000
a=rtpmap:99 telephone-event/*

if the answerer picks 97 and 99, then "*" stands for 8000; if the answerer picks 98 and 99, then "*" stands for 16000.
This is just to express the idea: I think that this idea can be implemented in many more ways (e.g. new attributes for the specific PT, change of frequency in the answer, ...), thus if it is believed to be a promising approach we might elaborate more.
IMHO this proposal fits well the spirit of the issue, since we do not really have a reason to require a specific timestamp frequency for DTMF, FEC or whatever: we just want their timestamp frequency to match the timestamp frequency in use in the audio stream.

Best regards
Guido

-----Original Message-----
From: Magnus Westerlund [mailto:[email-masked]]
Sent: martedì 31 gennaio 2006 11.35
To: IETF AVT WG
Cc: Franceschini Guido
Subject: Re: [AVT] Issue with different timestamp frequencies

Hi,

I think I should clarify my view on how this work. It is allowed and do 
work to switch payload types with different timestamp rates within a 
single SSRC, i.e. timestamp and sequence number space, between payload 
types of different RTP timestamp rate. However some care is needed.

Lets assume that we have one payload type of rate with 8kHz and another 
with 16kHz. Both uses 20 ms frame lengths and each packet will contain 
only 20 ms of media.

Seq nr.      TS      Rate
1            0       8k
2            160     8k
3            320     8k
4            480     16k
5            800     16k
6            1120    16k
7            1440    8k
8            1600    8k

the 4th packet with the new frame rate indicates to the receiver that 
the new RTP timestamp rate will be used for all RTP and RTCP related 
functions from this point forward until a new timestamp rate is used 
again. The switching of rates must start with a media packet and it and 
the previous packet should not overlap, i.e. packet 4's content should 
not be overlapping with packet 3's content. In this case this they are 
nicely aligned. Packet 3 contains 160 samples at 8kHz and the next 
frames timestamp will be 480. In the next packet the rate has switched 
to 16k starting at TS 480. The fact that the timestamp runs with the 
current rate over the complete media content for a packet is also seen 
at the switch with packet 7. Which TS is 320 larger than packet 6's.

When performing these switches that are indicated using payload types 
the sender should also take care to not switch often. There are several 
reasons for that.
1. The receiver may not be able to determine the switch point if packet 
losses occur at the point of switching. In that case an RTCP SR are 
required to determine the switch point. Thus switching provides a 
potential loss of synchronization and this risk should be minimized.

2. The media codec switch may have substantial overhead or reduction in 
quality associated with it.

A further result of the above is the need to have any supporting or 
alternative encoding be able to use the same timestamp rate as the main 
one uses. This especially has implications for RFC 2833 when sending 
DTMF tones in addition or interleaved with the main audio encoding. The 
same applies for RFC2198 where the transmission of redundant encoding 
must use the same rate, and also the payload type for redundant payload 
must be signaled with the correct rate. Thus to use RFC 2198 at two 
different rates will in most cases require 6 payload types: 1 for first 
rate primary encoding, one for redundant encoding at first rate, and 
then one for the RFC 2198 payload format at the first rate, then the 
same set for the second TS rate.

Questions or comments?

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: [email-masked]

Gruppo Telecom Italia - Direzione e coordinamento di Telecom Italia S.p.A.

====================================================================
CONFIDENTIALITY NOTICE
This message and its attachments are addressed solely to the persons
above and may contain confidential information. If you have received
the message in error, be informed that any use of the content hereof
is prohibited. Please return it immediately to the sender and delete
the message. Should you have any questions, please send an e_mail to
[email-masked]. Thank you
====================================================================

_______________________________________________
Audio/Video Transport Working Group
[email-masked]
https://www1.ietf.org/mailman/listinfo/avt

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 31 Jan 2006 16:58:28 +0100

Hi Guido,

SDP do lacks the capability to express the desire to have the other part 
select either of the sampling frequencies, not both in a session. It has 
been clear for a long time that there is need for a new capability, 
negotiation and configuration protocol to replace the configuration 
protocol SDP. There are many different complex relationships that needs 
to be expressed for example in capability exchange. Please note that 
these protocols will require even more bandwidth than SDP.

I don't think allowing the clock rate to be a wild card makes life any 
easier. Using implicit values I think have a big risk of being 
misunderstood. Which would be very dangerous as the result would be the 
usage of different timestamp rates by different users. Also there are 
cases, for example when using FEC etc, when the knowledge of the actual 
timestamp rate is necessary. Thus explicit values signaled through the 
payload type becomes necessary.

My proposal is to my knowledge at least valid according today's 
specifications.

Cheers

Magnus

-- 

Magnus Westerlund