Subject: Re: [AVT] Multiplexing streams with different resolutions in one RTP Session

From: Dave Singer <[email-masked]>
Date: Tue, 2 May 2006 10:22:13 -0700

Ciao Guido

you don't outline another possibility;  stop writing payload specs 
that insist that the timescale of the stream be a specific value. 
Indeed, there is no ambiguity today if I signal an AMR 8KHz sampled 
stream with a 16 KHz clock frequency;  the timing is precise, 
accurate, and unambiguous.  Nothing conceptually breaks;  it's only a 
paper restriction which is violated.

At 14:54  +0200 2/05/06, Franceschini Guido wrote:
>Content-Class: urn:content-classes:message
>Content-Type: multipart/alternative;
>	boundary="----=_NextPart_000_6C78E_01C66DF8.4B3DDBE0"
>
>
>Dear all,
>
>a few months ago I already posted some mail on this issue (see the 
>thread on "Issue with different timestamp frequencies", and got some 
>feedback.
>Now I have progressed with my implementation and would like to share 
>with you my concerns/solutions.
>
>The problem I am talking about is: how to multiplex in a single RTP 
>Session streams with different time resolutions.
>
>There are two scenarios -at least- where this occurs:
>a) AMR-WB (16KHz) + DTMF (8KHz)
>b) AMR-WB (16KHz) + another codec narrowband (8KHz)
>
>
>I have explored several approaches:
>
>1) use the current specs, following the explaination from Magnus 
>(mail of 31/01/2006)
>PROS:
>- no spec change (although IMHO the explaination from Magnus can be 
>hardly derived from the text in the specs)
>CONS:
>- a complex receiver is required to identify the instants at which 
>the time resolution has switched and so reconstruct the correct 
>timeline
>- in case a packet loss occurs near to the time resolution switch, 
>an ambiguity in the timestamp of the packet cannot be resolved until 
>the next RTCP report. If multiple such events occur between two RTCP 
>reports, the ambiguity cannot be solved not even a posteriori.
>- even if no time resolution switch occurs, concurrence of packet 
>losses and audio suppression might induce the same ambiguity as 
>before, since this case cannot be univocally distinguished anymore.
>- if the time resolution switch occurs right at the time an RTCP 
>report is produced, it is unclear which resolution shall be used 
>within that RTCP report
>- RTCP jitter calculation is unclear
>
>2) use separate RTP sessions, i.e. separate destination addresses.
>PROS:
>- easy
>- no ambiguity
>CONS:
>- 2 m=audio lines are required in SDP
>- more network resources involved
>- more NAT related problems
>- need RTCP to sync the two flows
>
>3) use a new MIME (X-DTMF) with 16 KHz resolution.
>PROS:
>- easy
>- no ambiguity
>CONS:
>- extra SDP length
>- does not address scenario b)
>
>4) use separate SSRC for each time resolution
>PROS:
>- no ambiguity
>CONS:
>- need RTCP to sync the two flows
>- RTCP rules might need some clarification
>
>
>As you can guess from the list above, my favoured solution is #4. To 
>complete it, however, I ask your help in interpreting the specs with 
>reference to RTCP.
>The 'root' of my concerns is that RTCP SR and RR require that one 
>SSRC value is specified to indicate the sender. Unfortunately I have 
>2 SSRC values now...
>Usage of 2 SSRC for sending within a single RTP Session is 
>explicitely allowed (or even requested) in RFC3550, page 9 (look at 
>the last sentence):
>
>Synchronization source (SSRC): The source of a stream of RTP
>packets, identified by a 32-bit numeric SSRC identifier carried in
>the RTP header so as not to be dependent upon the network address.
>All packets from a synchronization source form part of the same
>timing and sequence number space, so a receiver groups packets by
>synchronization source for playback. Examples of synchronization
>sources include the sender of a stream of packets derived from a
>signal source such as a microphone or a camera, or an RTP mixer
>(see below). A synchronization source may change its data format,
>e.g., audio encoding, over time. The SSRC identifier is a
>randomly chosen value meant to be globally unique within a
>particular RTP session (see Section 8). A participant need not
>use the same SSRC identifier for all the RTP sessions in a
>multimedia session; the binding of the SSRC identifiers is
>provided through RTCP (see Section 6.5.1). If a participant
>generates multiple streams in one RTP session, for example from
>separate video cameras, each MUST be identified as a different
>SSRC.
>
>RFC3550 however does not help much when addressing RTCP. On page 34 I found:
>
>The SR is issued if a
>site has sent any data packets during the interval since issuing the
>last report or the previous one, otherwise the RR is issued.
>
>Both the SR and RR forms include zero or more reception report
>blocks, one for each of the synchronization sources from which this
>receiver has received RTP data packets since the last report.
>
>My interpretation is that the above text also implies:
>
>In case multiple SSRC are used by a site for sending, the SR for SSRCx
>is issued if a site has sent any data packets with that SSRCx during
>the interval since issuing the last report for SSRCx or the previous
>one; if no SR is needed, for any of the SSRCx in use for sending, then
>the RR is issued, indicating as sender's SSRC any of the SSRCx in use
>for sending.
>In case data packets have been sent with more than one SSRC, since SR
>only allow for describing the traffic generated by a single SSRC, only
>one SSRC can be elected to be represented in a SR report. This makes
>RTCP management quite difficult. An alternative idea is to combine
>multiple SR into a compound RTCP packet: in such a case the first SR
>will include a 'true' RR, while the additional SR will include only
>empty RR: this technique does not seem to contradict any rule, in
>particular for RR, since no data is received between the first and the
>subsequent SR in the compound RTCP packet!
>
>
>Whatever the solution selected, I believe that some extra wording in 
>the RFC3550 would be needed, in order to either clarify the use case 
>or set new constraints (e.g.: that media with different time 
>resolution cannot share the same SSRC within an RTP Session).
>For example for solution 1), the specs do not really describe how to 
>perform a time resolution switch at the sender side, nor how to 
>identify it at a receiver: furthermore significant areas of 
>ambiguity are introduced in such a case but totally ignored.
>
>I welcome your comments
>
>Thanks in advance
>Guido Franceschini
>
>--------------------------------------------------------------------
>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 contact us by
>replying to <mailto:[email-masked]>[email-masked].
>         Thank you
>                                         
><http://www.telecomitalia.it>www.telecomitalia.it
>--------------------------------------------------------------------
>
>_______________________________________________
>Audio/Video Transport Working Group
>[email-masked]
>https://www1.ietf.org/mailman/listinfo/avt

-- 
David Singer
Apple Computer/QuickTime

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

---

From: "Franceschini Guido" <[email-masked]>
Date: Wed, 3 May 2006 10:51:10 +0200

Ciao Dave,

well, I can certainly second your statement - exactly the same issue is present in the ISO/MP4/3GP file format, but in that case a timescale other than the audio sampling rate is tolerated too, am I right?

The change you are implying might have interoperability drawbacks. Not with my code, where the explicit timescale indicated in the a=rtpmap overwrites the payload type specific defaults, but I fear that this is not an RTP rule, and other implementations might behave differently :-(

I fail to understand the reason for this restriction, but that's it.

BTW: I am also curious, if anyone cares, to understand why RTP and RTCP could not be defined to share a single socket (maybe NATs were invented later and not taken into account?).

There is no polemic intention in my words.

Guido

  _____  

Da: Dave Singer [mailto:[email-masked]] 
Inviato: martedì 2 maggio 2006 19.22
A: Franceschini Guido; [email-masked]
Cc: Oldrini Stefano; Madaro Livio
Oggetto: Re: [AVT] Multiplexing streams with different resolutions in one RTP Session

Ciao Guido

you don't outline another possibility;  stop writing payload specs that insist that the timescale of the stream be a specific value.  Indeed, there is no ambiguity today if I signal an AMR 8KHz sampled stream with a 16 KHz clock frequency;  the timing is precise, accurate, and unambiguous.  Nothing conceptually breaks;  it's only a paper restriction which is violated.

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 contact us by replying to [email-masked].

        Thank you

                                        www.telecomitalia.it