Subject: Re: [AVT] I-D ACTION:draft-ietf-avt-topologies-04.txt

From: Colin Perkins <[email-masked]>
Date: Sat, 17 Mar 2007 15:52:57 +0100

On 23 Feb 2007, at 21:50, [email-masked] wrote:
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
> This draft is a work item of the Audio/Video Transport Working  
> Group of the IETF.
>
> 	Title		: RTP Topologies
> 	Author(s)	: M. Westerlund, S. Wenger
> 	Filename	: draft-ietf-avt-topologies-04.txt
> 	Pages		: 20
> 	Date		: 2007-2-23
> 	
> This document discucsses multi-endpoint topologies used in RTP
>    based environments.  In particular, centralized topologies commonly
>    employed in the video conferencing industry are mapped to the RTP
>    terminology.
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-avt-topologies-04.txt

Section 3.7 states:

    Topologies can be combined and linked to each other using mixers or
    translators. However, care must be taken in handling the SSRC
    space.  Mixers separate the SSRC space into two parts, while
    translators maintain the space across themselves. The combined SSRC
    and CSRC space still needs to be be common over any translator or
    mixer.

I find this wording confusing, since there is a single SSRC space  
across a mixer: each sender, plus the mixer, has its own unique SSRC  
value. Some of those values are only visible to some receivers in the  
CSRC field, but that doesn't change the fact that all sources share a  
single identifier space. The text quoted seems to imply the CSRC and  
SSRC spaces are separate, which is not correct.

Cheers,
-- 
Colin Perkins
http://csperkins.org/

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

---

From: "Franceschini Guido" <[email-masked]>
Date: Tue, 20 Mar 2007 15:11:06 +0100

Colin, all,
 
I feel now confused about what an RTP Session is. I re-read RFC3550, and found in the definition of RTP Session:
 
A participant distinguishes
      multiple RTP sessions by reception of different sessions using
      different pairs of destination transport addresses, where a pair
      of transport addresses comprises one network address plus a pair
      of ports for RTP and RTCP. 
[...]
The distinguishing feature of an RTP session is that each
      maintains a full, separate space of SSRC identifiers
 
I would therefore assume that Mixer and Translator terminate RTP sessions. (unless your argument is that a Mixer or Translator is assumed to bridge RTP flows among the various peers using a single port)
 
Nevertheless, I am further confused by the reading of your RTP over DCCP draft, where I read:
 
4.4:
   A single RTP session may also span a DCCP connection and some other
   type of transport connection.  An example might be an RTP over DCCP
   connection from an RTP end system to an RTP translator, with an RTP
   over UDP/IP multicast group on the other side of the translator.  A
   second example might be an RTP over DCCP connection that links PSTN
   gateways.  The issues for such an RTP translator are similar to those
   when linking two DCCP connections, except that the congestion control
   algorithms on either side of the translator may not be compatible.
   Implementation of effective translators for such an environment is
   non-trivial.
 
In conclusion my questions are:
- where exactly an RTP Session terminates? 
- is there a 1 to 1 relation between an RTP Session and (a media section of) an SDP description?
 
Thanks in advance
Guido
 
________________________________

From: Colin Perkins [mailto:[email-masked]]
Sent: Sat 3/17/2007 3:52 PM
To: Magnus Westerlund; Stephan Wenger
Cc: IETF AVT WG
Subject: Re: [AVT] I-D ACTION:draft-ietf-avt-topologies-04.txt 

Section 3.7 states:

Cheers,
--
Colin Perkins
http://csperkins.org/

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

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

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

---

From: Colin Perkins <[email-masked]>
Date: Tue, 20 Mar 2007 15:29:44 +0100

On 20 Mar 2007, at 15:11, Franceschini Guido wrote:
> I feel now confused about what an RTP Session is. I re-read  
> RFC3550, and found in the definition of RTP Session:
>
> I would therefore assume that Mixer and Translator terminate RTP  
> sessions. (unless your argument is that a Mixer or Translator is  
> assumed to bridge RTP flows among the various peers using a single  
> port)

No - there is a single RTP session across a mixer or translator.

> - where exactly an RTP Session terminates?

See the topologies draft.

> section of) an SDP description?

An SDP session description provides the information a receiver needs  
to join an RTP session. Not all participants in a session will get  
the same session description, obviously.

Colin

---

From: Colin Perkins <[email-masked]>
Date: Tue, 20 Mar 2007 15:33:31 +0100

> See the topologies draft.

(noticing this is about the topologies draft)

The session comprises the group of participants that share an SSRC  
space. That's independent of the underlying transport connections; a  
RTP session can span multiple transport connections, IPv4/IPv6,  
unicast/multicast, etc.

Colin

---

From: "Franceschini Guido" <[email-masked]>
Date: Tue, 20 Mar 2007 16:08:21 +0100

I am fine with your clarification.
Just in an attempt to totally clear things however, one more request:
- RFC3550 defines 'End System', 'Mixer' and 'Translator', but not 'participant'. I thought that any device involved in 'touching' the RTP packets were a participant, but I assume now that this is not the case, and that only 'End Systems' are 'participant'. Mixer and Translators are not participant, therefore the first excerpt I made from RFC3550 does not apply. Do you confirm?
 
Thanks again
Guido

From: Colin Perkins [mailto:[email-masked]]
Sent: Tue 3/20/2007 3:29 PM
To: Franceschini Guido
Cc: Magnus Westerlund; Stephan Wenger; IETF AVT WG
Subject: Re: [AVT] I-D ACTION:draft-ietf-avt-topologies-04.txt 

Colin

CONFIDENTIALITY NOTICE

        Thank you

                                        www.telecomitalia.it