Subject: [AVT] What is an RTP Session?

From: "Mike Taylor" <[email-masked]>
Date: Fri, 11 Oct 2002 16:25:14 -0700

Hi,

I'm an RTP newbie and I'm trying to understand just what constitutes
an RTP session when the participants are using unicast rather
than multicast.  I find the description in RFC 1889 quite ambiguous.

   "RTP session: The association among a set of participants
        communicating with RTP. For each participant, the session is
        defined by a particular pair of destination transport addresses
        (one network address plus a port pair for RTP and RTCP). The
        destination transport address pair may be common for all
        participants, as in the case of IP multicast, or may be
        different for each, as in the case of individual unicast network
        addresses plus a common port pair.  In a multimedia session,
        each medium is carried in a separate RTP session with its own
        RTCP packets. The multiple RTP sessions are distinguished by
        different port number pairs and/or different multicast
        addresses."

Perhaps this paragraph would be clearer if the definition of "participant"
was made clear.  The use of participant in the 1st sentence might be 
interpreted to mean a participant in a conference consisting of multiple
RTP sessions.  But the very next sentence refers to "the session" which
suggests that indeed there are multiple participants in a single RTP session.
This makes sense for multicast, but my problem is I find it confusing in
a multipoint unicast scenario (I'm assuming its peer-to-peer which might
be part of my problem, but read on).

Dissecting the paragraph we have:
        
        "For each participant, the session is
        defined by a particular pair of destination transport addresses
        (one network address plus a port pair for RTP and RTCP). "

This would seem to suggest that the triplet <dest_network_addr, rtp_port, rtcp_port> 
defines a session from the perspective of a given participant.  But then it seems 
to me that with unicast RTP can never be  more than two participants in a single 
session (assuming each participant is using a different computer and hence has a 
different network address).  Each participant sees the session as defined by its peer's 
IP address and the RTP and RTCP ports it uses to send RTP and/or RTCP to the peer.  

But the same paragraph goes on to say
       
        "The destination transport address pair may be common for all
        participants, as in the case of IP multicast, or may be
        different for each, as in the case of individual unicast network
        addresses plus a common port pair. "

This latter sentence seems to contradict the former and suggests that for
each participant in a multipoint unicast session the session is defined by
an array of triplets of the form:

        <net_addr_1, port>
        <net_addr_2, port>
        <net_addr_3, port>
        .....

I suppose that the author of the RFC would have assumed that for a multi-party
conference using unicast there would be an RTP mixer terminating all sources,
combining them, and sending them to all participants.  Thus, for each participant
there would only be a single session, and it would be defined by the net address
and port pair of the mixer node. Still, I'd like to know if anyone is aware of whether 
any consensus has been arrived at on this issue of what defines the session in
the multi-point unicast case, with no mixer. 

Furthermore, does anyone know of any commercial or public domain voice conferencing 
apps that can create multipoint unicast peer-to-peer conferences?  I've been 
experimenting with MS NetMeeting and have found that it only supports audio between 2 
parties in a multi-party conference.  Perhaps this issue hasn't been viewed as important
because nobody is supporting a peer-to-peer multi-party conference?

Thanks in advance,

Mike Taylor

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

---

From: Pekka Pessi <[email-masked]>
Date: 15 Oct 2002 18:14:31 +0300

>than multicast.  I find the description in RFC 1889 quite ambiguous.

	The description basically states that a group of participants
	sending RTP to a multicast address is one session identified by
	the destination address/port pair, but unicast streams can also
	be one session regardless of the destination address/port pairs. 
	The RFC1889 definition requires that all the recipients have
	common port number, but this limitation is lifted in rtp-new
	draft.

	Basically the pure unicast case boils down to two peers sending
	media to each other; they are in a single session and can send
	combined SR/RR RTCP packets to each other.

	A configuration where one participant is receiving multiple
	unicast streams and sending RTP/RTCP via multicast is also one
	session.

	Rule of thumb here is that if a participant can send all its
	RTCP packets to a single destination address, it is in one
	session.

	From the programming point-of-view, a RTP session participant
	always have four sockets: one for receiving RTP with recv(),
	second for sending RTP with send(), third for receiving RTCP
	with recv(), fourth for sending RTCP with send(). The sockets
	used for sending are always connected() to certain address, the
	sockets used for receiving are always bound. If the participant
	must change these sockets, he is moving to another session. 
	(The second socket is optional, if you do not send any
	media).

					Pekka