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

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

Hi Magnus,

thanks a lot for your reply that pin-points two mistakes of mine
More inline

Guido

-----Messaggio originale-----
Da: Magnus Westerlund [mailto:[email-masked]] 
Inviato: mercoledì 3 maggio 2006 17.13
A: Franceschini Guido
Cc: [email-masked]; Oldrini Stefano; Madaro Livio
Oggetto: Re: [AVT] Multiplexing streams with different resolutions in one RTP Session

Hi Guido,

A few comments inline.

Franceschini Guido wrote:
> 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)

I still don't see why you keep on arguing for this case. To me this is a 
wrongly configured session. It should change the timestamp rate of the 
DTMF to 16kHz.

[guido]
I have re-read rfc2833 and figured out, in the end, that 8000 is just the norm, not the fixed clockrate!
This means that I can offer, in a single SDP m=audio section:
- PT=97 for AMR @ 8000
- PT=98 for AMR-WB @ 16000
- PT=99 for telephone-events @ 8000
- PT=100 for telephone-events @ 16000

The IETF specs do not constrain the selection of 97+99 or 98+100, but this could be an additional, obvious constraint that could be added by the service operator

> b) AMR-WB (16KHz) + another codec narrowband (8KHz)
> 

This is a reel one I agree. However it do simplify the issues of rapid 
switching which in my eyes should really not occur in this case.

[guido]
I agree

> 
> I have explored several approaches:
> 
[...]
> 
> 3) use a new MIME (X-DTMF) with 16 KHz resolution.
> PROS:
> - easy
> - no ambiguity
> CONS:
> - extra SDP length
> - does not address scenario b)

Not needed, the standard tones and telephone event payloads do support 
any rate.

[guido]
Great!

> 
> 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
> 
[...]
> 
> 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!

In my opinion the right way of handling multiple SSRC at one end-point 
is to treat them as they are each individual end-points part of a 
multicast where everyone sees everyone. This implies that each SSRC will 
send its own SR when an active sender, otherwise sending RRs. The 
bandwidth distribution is done using the normal rules. Which will result 
in that for one end-point with two SSRC and another end-point with a 
single SSRC the first one will commonly use twice the RTCP bandwidth 
compared to the other out of the common pool.

If one include empty RR then one are in fact reporting that one don't 
see the other sender co-located at the same host. That implies an error 
and should those not be done.

[guido]
I agree. I failed to consider the point of view of receivers of these RTCP reports, and your observations are absolutely valid. Thanks for correcting me.

> 
> 
> 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 agree that this is insufficiently described in RFC 3550. Are you 
willing to create a draft that tackles this issue?

[guido]
Before your e-mail, I would have said: I'd love to. Now that you showed me how wrong were some of my basic concerns, my opinion on the ambiguity of the specs has changed. I mean, my remarks hold true, but the real impact of these spec 'holes' on meaningful use cases is greatly reduced.
I think that it's not worth to work at an I-D for just these little things. If however more issues arise with time, and a 3550bis becomes a need, I definitely volunteer to contribute.

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]

--------------------------------------------------------------------

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

--------------------------------------------------------------------

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