Subject: [AVT] Fwd: I-D ACTION:draft-perkins-avt-rtp-and-rtcp-mux-00.txt

From: Colin Perkins <[email-masked]>
Date: Fri, 8 Sep 2006 16:04:24 +0100

The following draft proposes rules for multiplexing RTP and RTCP  
traffic on a single UDP port, to ease NAT traversal. Any comments  
appreciated!

Colin

Begin forwarded message:
> From: [email-masked]
> Date: 8 September 2006 15:50:02 BDT
> To: [email-masked]
> Subject: I-D ACTION:draft-perkins-avt-rtp-and-rtcp-mux-00.txt
> Reply-To: [email-masked]
>
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
>
>
> 	Title		: Multiplexing RTP Data and Control Packets on a Single Port
> 	Author(s)	: C. Perkins, M. Westerlund
> 	Filename	: draft-perkins-avt-rtp-and-rtcp-mux-00.txt
> 	Pages		: 12
> 	Date		: 2006-9-8
> 	
> This memo discusses issues that arise when multiplexing RTP data
> packets and RTP control protocol (RTCP) packets on a single UDP port.
> It updates RFC 3550 to describe when such multiplexing is, and is
> not, appropriate, and explains how the Session Description Protocol
> (SDP) can be used to signal multiplexed sessions.
>
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-perkins-avt-rtp-and-rtcp- 
> mux-00.txt

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

---

From: Gunnar Hellstrom <[email-masked]>
Date: Sat, 9 Sep 2006 06:55:27 +0200

Colin and Magnus,
Thanks for a good initiative and a good draft.
It seems to cover part of the need for multiplexing in a good way.

But, I suggest that you in the abstract and early in the text describe to
what extent you solve the multiplexing problem.

I read it with the initial hope that you proposed a method to multiplex all
RTP and RTCP streams in e.g. a SIP session onto one UDP port.

I had to read it all through down below the sdp example, before I could
conclude that the method does not cover the problems that would occur if you
want to multiplex all media in a session onto the same port.

In multimedia applications, it is a similar burden to handle all media rtp
streams through NAT.

By this draft you cover half of the problem - the RTP-RTCP multiplexing
belonging to one RTP session, but not how to multiplex all RTP sessions with
its RTCP. Please indicate that early in the draft with wording that not
forbids solving the other half of the problem.

I leave to you to do the wording.

Thanks,

Gunnar

----------------------------------------------------------------------------
-
Gunnar Hellstrom, Omnitor
[email-masked]

-----Original Message-----
From: Colin Perkins [mailto:[email-masked]]
Sent: Friday, September 08, 2006 5:04 PM
To: AVT WG
Subject: [AVT] Fwd: I-D ACTION:draft-perkins-avt-rtp-and-rtcp-mux-00.txt

Colin

---

From: Randell Jesup <[email-masked]>
Date: Mon, 11 Sep 2006 15:15:15 -0400

>want to multiplex all media in a session onto the same port.

Another issue that at least should be mentioned is that it can fail if any
proxy doesn't support a=rtcp: and that proxy changes the RTP port.
Changing the RTP port is frequently (normally) done by ALGs and SBCs, and
not all of them support a=rtcp: - and if they do support it, the traffic
caused by this draft might mess them up.  I will concede that lack of
a=rtcp support by an SBC, ALG, rtp-relay, etc would also break regular
RTCP - but these are important issues for this draft and for users of it.

>forbids solving the other half of the problem.

This draft relies on a "tricky" use of a=rtcp as implicit signalling, and
to in some cases trick implementations that predate this draft into using
the same port for RTP and RTCP (assuming that they already support a=rtcp,
which many do not).

Explicit signalling would restrict it to implementations that know about
this draft, but would avoid problems with a=rtcp implementation (see above
about SBCs, etc).

The other option to consider is a more explicit multiplexing as Gunnar is
mentioning (sub-ports if you will) to minimize the number of holes that
need to be punched and tested, especially when ICE is involved.  A protocol
that uses (say) 3 streams in each direction needs 6 incoming ports tested
and punched open.  With a full multiplex layer for RTP, you'd only need 1
port.

In Message-ID: <[email-masked]> sent on April 4, 2006
to avt@ietf, Colin, etc, I suggested signalling a multiplex layer at the
connection level.  I quote:

| the canonical way to achieve this to be define a multiplexing
| protocol for datagrams, and specify this as part of a c= line in the
| SDP.  This would change the "port" value from the media line into a "stream
| ID" on the multiplex.  Something like:
| 
| c=IN IP4/PLEX 23.45.67.89 1234
| m=audio 2 RTP/AVP 0
| m=video 4 RTP/AVP 99
| a=rtpmap:99 H999/90000
| 
| That would put audio on multiplex "ports" 2 & 3, and video on 4 & 5.
| All data would be sent to 23.45.67.89 port 1234.
| 
| This is more overhead than if it were designed into RTP - but it can be
| used for any protocol, not just RTP.
| 
| Packet data could be something like:
| [short plex_port]
| [datagram]
| 
| Yes, this causes an MTU size drop, which is an issue for some.  This would
| need to be handled at the sending end.  Perhaps (maybe) you could consider
| optimizing this for the "common" case of "same as last packet", but you
| still need at least a bit, and more likely a byte.  Probably better to
| stick to two.
| 
| There would be no attempt to deal with duplication, ordering, timing or any
| other issue at this layer.  KISS.  That's the job of the application these
| datagrams get fed to.
| 
| If you do need to get fancier, you can add fragmentation, etc, but it gets
| ugly fast, and starts approaching the complexity/overhead of UDP.

-- 
Randell Jesup, Worldgate (developers of the Ojo videophone), ex-Amiga OS team
[email-masked]

---

From: "Hadriel Kaplan" <[email-masked]>
Date: Mon, 11 Sep 2006 16:39:09 -0400

Hey Randell,
Comments inline...

> From: Randell Jesup [mailto:[email-masked]]
> Sent: Monday, September 11, 2006 3:15 PM
> To: Gunnar Hellstrom
> Cc: Colin Perkins; AVT WG
> Subject: Re: [AVT] Fwd: I-D ACTION:draft-perkins-avt-rtp-and-rtcp-mux-
> 00.txt- multiplexing to what extent
> 

I think this draft handles that: if the answer does not have an a=rtcp
matching the m= udp port, then the offer must fail and the offerer must
retry it without muxing.  So an offer/answer using this draft through an
ALG/FW which did not support rfc3605 would probably fail, with a very high
probability, and re-signal.  It is then just as good/bad as 3605, or the
offerer could just not use a=rtcp at all at that point; i.e., it's no worse
than before.  

> this draft, but would avoid problems with a=rtcp implementation (see above

I was going to comment originally that this draft could use explicit
signaling instead of overloading a=rtcp; though I think it's a
graceful/clever reuse of a=rtcp.  But it occurs to me it's just as likely
you hit a FW/SBC that doesn't allow non-conforming PT's in the stream, and
you have as bad a problem.  In that case it would have been better to fail
the offer, as this draft would do.  IOW, damned if you do, damned if you
don't.  

Perhaps what this draft should say is if the answer still used a=rtcp but
with mismatching udp port to the answer's m= line, that the offerer may
consider retrying without muxing AND without using RFC 3605 at all, because
the odds are something in the middle's mucking with SDP and doesn't
understand a=rtcp?

-hadriel

---

From: Randell Jesup <[email-masked]>
Date: Mon, 11 Sep 2006 17:14:27 -0400

"Hadriel Kaplan" <[email-masked]> writes:
>retry it without muxing.

That could still confuse an existing app.  And the offer doesn't "fail",
the offer has been accepted; you're talking about re-INVITEing/UPDATEing
the offer after it's been accepted but with values that won't work
correctly.  This could cause problems until the call is re-established
without that.  And it may be more delayed if this means another pass of ICE
(this time for more ports).

>So an offer/answer using this draft through an ALG/FW which did not
>support rfc3605 would probably fail, with a very high probability, and
>re-signal.  It is then just as good/bad as 3605, or the offerer could just
>not use a=rtcp at all at that point; i.e., it's no worse than before.

The reason I say it wouldn't fail is:
Offer:
  m=audio 1234 ....
  a=rtcp:1234

Munged offer:
  m=audio 5678 ....
  a=rtcp:1234

Answer (200 OK):
  m=audio 9876 ...
The answerer assumes that rtp goes to 5678 and rtcp goes to 1234.
The offerer will need to re-INVITE (and perhaps re-STUN/ICE/TURN/etc).
And RTCP will be lost for a while at call startup (at minimum).

>the offer, as this draft would do.  IOW, damned if you do, damned if you

non-conforming PT's?  Perhaps you mean attributes.  I'm more willing to
deal with that sort of failure, and I think it will generally have less
effect on the call setup (it will fail before getting to the dest, and
in theory the caller could then retry).  But a gateway that rejects invites
with attributes it doesn't understand is quickly going to be a problem for
EVERY protocol and draft, unless we hide every addition and extension in 
the few attributes it passes through.  

>the odds are something in the middle's mucking with SDP and doesn't

You could (though include the no "a=rtcp" case there too).  But I think
overall there are too many bandaids here.  I'd recommend at least moving
away from the attempt to overload a=rtcp; there's too much chance of
breaking some ALG/SBC/UA that understands 3605 but not this (plus the
issues above).  It's cute, but I think the potential pain isn't worth it.

---

From: "Hadriel Kaplan" <[email-masked]>
Date: Mon, 11 Sep 2006 18:34:52 -0400

> (this time for more ports).

Yup, I assumed this draft meant the offerer would cancel/terminate the
session or re-invite/update the offer.  It's ugly though, obviously.

> And RTCP will be lost for a while at call startup (at minimum).

Yup, as it would for RFC 3605 alone.  Thus my point was it's no worse than
that rfc, fwiw.

> in theory the caller could then retry).  

Nope, I meant payload-types in RTP-UDP streams that weren't signaled in the
m= line.  In this case a RR/SR showing up.  There are such FW/SBCs.  So for
example this draft instead uses a=rtcp-mux or some such, to bypass the
FW/SBC/ALG's ineptitude.  Both sides then mux RTP+RTCP, and the FW blocks it
in the stream.  The irony is RTP+RTCP un-muxed would have worked fine,
because the FW was the one who NATs and thus would have opened UDP port+1
for RTCP.  But no matter - we've got to pick a poison no matter what, and I
agree with you it's less common to block on PT types.

> I'd recommend at least moving

Huh.  I was thinking the other way round - that a 3605-understanding ALG is
one that *would* work, because it would modify the a=rtcp line as well.  But
on reflection I think your point is it may modify it to be non-equal to the
m= line?  That's a good point, it might. (who knows with these foolish
intermediaries - that's what they get for mucking with SDP :)

-hadriel

---

From: "Desineni, Harikishan" <[email-masked]>
Date: Thu, 14 Sep 2006 14:45:34 -0700

What if you allow the following? Both RTP streams will arrive on 20000
and the receiver will demux based on payload type. Wouldn't this work as
long as the payload type for both media streams is not the same?

m=audio 20000 RTP/AVP 0
m=video 20000 RTP/AVP 99
a=rtpmap:99 H263/90000

This draft is proposing that a payload type be used for de-multiplexing
RTP and RTCP. This might just work to de-mux RTP streams as well. The
above SDP signaling approach looks much simpler than PLEX proposal (if
you choose to use PT as demux point).

- - - - - - - - - - - - - - - - - -
Harikishan Desineni
Qualcomm Inc.,
mailto:[email-masked]

> | There would be no attempt to deal with duplication, ordering, timing
or
> any
> | If you do need to get fancier, you can add fragmentation, etc, but
it
> gets
> Randell Jesup, Worldgate (developers of the Ojo videophone), ex-Amiga
OS
> team

---

From: Randell Jesup <[email-masked]>
Date: Fri, 15 Sep 2006 11:08:13 -0400

>you choose to use PT as demux point).

I agree it *appears* simpler (though you're more limited due to available
payload values).

A few issues though:
1) To share media streams using the same codecs you'd need to use different
   payloads, even for "standard" codecs like PCMU.  Not a big deal.
2) RTCP doesn't specify payload types, only SSRCs.  This could be a
   problem, even for UAs/etc that know about this idea.
3) I guarantee this WILL break/crash/confuse existing UAs, SBCs, etc.

Trying to shoehorn in something like this using existing signalling is
simply dangerous; it will cause problems in practice.

Now, you could try to come up with a signalling approach for initiating
a PLEX connection without requiring another round-trip if the called UA
didn't understand it; something like the capability stuff being discussed.

I think also architecturally a PLEX-style transport-layer makes more sense,
and isolates that complexity at that level.

---

From: Colin Perkins <[email-masked]>
Date: Fri, 15 Sep 2006 16:19:06 +0100

Gunnar,

[Apologies for the slow response, I've been travelling]

> forbids solving the other half of the problem.

I believe that multiplexing RTP streams representing different types  
of media onto a single port is a mistake, for the reasons enumerated  
in Section 5.2 of RFC 3550. I'll add a reference to that discussion,  
but I have no intention of changing this behaviour.

Colin

---

From: Randell Jesup <[email-masked]>
Date: Fri, 15 Sep 2006 12:03:44 -0400

Colin Perkins <[email-masked]> writes:
>I believe that multiplexing RTP streams representing different types  of
>media onto a single port is a mistake, for the reasons enumerated  in
>Section 5.2 of RFC 3550. I'll add a reference to that discussion,  but I
>have no intention of changing this behaviour.

5.2 talks more about multiplexing via PT or SSRC as opposed to port number
per se; it says that different streams should use different transport
addresses.  While Gunnar's proposal doesn't do that, the PLEX
transport-level mux would, and so avoid all of the points in 5.2.

As for 5.2 itself, I think point 4 may be wrong (though I'm not an expert
on mixing), and point 5 I think is at least mostly incorrect, at least as
far as this discussion:

   Using different network paths: since the receiver is specifying it wants
   to receive on the same port, that's not an issue - they chose it.

   Reception of a subset of media if desired for bw: again, they chose the
   media; if they don't want to receive all the media they should reject
   those streams.  And simply not servicing the port won't save you
   bandwidth; you need to not accept or you need to renegotiate.

   Separate processes: You _can_ demux data off to separate processes
   regardless of whether the mux point is port, PT, or SSRC; it may be
   "cleaner" to mux at the transport level, but it can be done easily
   almost anywhere.

In any case, I do agree a transport-level mux is cleaner (ala 'PLEX' or
equivalent).  5.2 was written in a time when NAT was unusual at best, note,
so there are issues that didn't exist then (like time to open ports via
ICE/etc, resources used by TURN servers, etc).

---

From: "Desineni, Harikishan" <[email-masked]>
Date: Fri, 15 Sep 2006 09:33:24 -0700

How about this approach of signaling the common RTP port using
"a=rtp-mux"?

a=rtp-mux: 20000
m=audio 20000 RTP/AVP 0
m=video 40000 RTP/AVP 99
a=rtpmap:99 H263/90000

This would solve issue 3 and does not require another round trip time if
the answerer does not support rtp muxing.

Issue 2 does not look like a problem if we make sure that PT field of
RTCP and PT field of RTP do not conflict as stated in the draft.

Here each media stream would use a different SSRC. So, points 1,2,3 from
Sec 5.2, RFC 3550 do not apply for this case. And I agree with you that
point 4 and 5 may not be real issues.

> Sent: Friday, September 15, 2006 8:08 AM
> To: Desineni, Harikishan
> Cc: Gunnar Hellstrom; Colin Perkins; AVT WG
OS

---

From: Colin Perkins <[email-masked]>
Date: Fri, 15 Sep 2006 18:49:20 +0100

Randell, Hadriel,

On 11 Sep 2006, at 23:34, Hadriel Kaplan wrote:
>> without that.  And it may be more delayed if this means another  
>> pass of
>> ICE (this time for more ports).
>

That was my intent. It's ugly, but shouldn't break the media playout  
(just the RTCP will be broken, and missing the initial RTCP packet  
shouldn't be fatal).

...
> intermediaries - that's what they get for mucking with SDP :)

I did consider using explicit signalling, but decided against it on  
the basis that "a=rtcp:" deployment was probably low enough that any  
compatibility issues would be minor. Also, I was expecting ICE to  
encourage the use of multiplexed RTP and RTCP, and "a=rtcp:", so any  
problems would get sorted out in the course of ICE deployment.

That may be me being over-optimistic, of course...

Cheers,
Colin

---

From: Randell Jesup <[email-masked]>
Date: Fri, 15 Sep 2006 16:39:01 -0400

Colin Perkins <[email-masked]> writes:
>>> I'd recommend at least moving away from the attempt to overload a=rtcp;
>>> there's too much chance of breaking some ALG/SBC/UA that understands
>>> 3605 but not this (plus the issues above).  It's cute, but I think the
>>> potential pain isn't worth it.
>>
>> Huh.  I was thinking the other way round - that a 3605- understanding
>> ALG is one that *would* work, because it would modify the a=rtcp line as
>> well.  But on reflection I think your point is it may modify it to be
>> non- equal to the m= line?  That's a good point, it might. (who knows
>> with these foolish intermediaries - that's what they get for mucking
>> with SDP :)

An ALG/SBC/etc may modify a=rtcp: to be a different port number; in general
that's ok (it's acting as a relay, so the transport addresses can/should
change).  So long as nothing else relies on a=rtcp: being the same port as
the m= line, it's ok.  But realize that if you go through such an ALG/etc,
the callee UA will see a "normal" set of ports.  That may cause/require(?)
it to not mux RTP and RTCP in the response, even though it could.  Payloads
shouldn't be an issue, since the receiver defines the payload values that
are valid.

>I did consider using explicit signalling, but decided against it on  the
>basis that "a=rtcp:" deployment was probably low enough that any

Since we're specifying this for reception, there is a limit to the
compatibility issues.  The biggest problems will be the same as with all
other uses of RFC 3605: endpoints that ignore it (and send to RTP+1), and
SBC's/etc that ignore it (and it goes through unchanged, causing the
other end to send to the wrong port on the SBC/etc).  We'd add one more
possible problem - SBCs (and UAs) that support 3605 but don't like the
"same port aspect" of it.  That shouldn't happen, but who knows.  And an
SBC that supports 3605 may not (and currently won't) preserve the RTP=RTCP
aspect, as mentioned above, possibly causing the caller to re-invite under
the assumption that the callee doesn't support this.

So, so long as RTP=RTCP is not used to influence other behaviors, there may
not be a huge gain from explicit signalling, but there is a gain.

We need to make sure we understand throughly the different supports/doesn't
support cases and how and when reINVITE/etc is done and the impact.  Some
of the cases I just mentioned will cause RTCP failure where it would have
worked and/or re-INVITEs even though RTCP may be working (I think, I
haven't thought through them all and don't have time this afternoon).

---

From: Gunnar Hellstrom <[email-masked]>
Date: Fri, 15 Sep 2006 22:48:13 +0200

Colin,
You say about multiplexing media streams:
"I'll add a reference to that discussion,"

You do not even need to mention that discussion. Please just make it clear
what multiplexing you are talking about in this spec.

My reasoning is: When you read "multiplexing RTP and RTCP" you cannot see if
it means one RTP stream and its RTCP. From these words it could just as well
be a number of both RTP and RTCP.

So, I think that just adding something like "multiplexing an RTP stream with
its RTCP" somewhere early in scope, abstract and introduction would be
perfectly enough to tell what this is about.

Thanks,

Gunnar

Mob: +46 708 204 288
Phone: +46 8 556 002 03
www.omnitor.se

-----Original Message-----
From: Colin Perkins [mailto:[email-masked]]
Sent: Friday, September 15, 2006 5:19 PM
To: Gunnar Hellstrom
Cc: AVT WG
Subject: Re: [AVT] Fwd: I-D
ACTION:draft-perkins-avt-rtp-and-rtcp-mux-00.txt -multiplexing to what
extent

Gunnar,

Colin

---

From: "Even, Roni" <[email-masked]>
Date: Thu, 21 Sep 2006 12:39:53 +0300

Hi,

I can understand the value of this multiplex as for the draft I have
some comments.
For the NAT traversal case we can then use the RTCP messages for
keep-alive.

RTP is by nature unidirectional while RTCP is bi-directional. The
comments has to with this

1. The draft should address the behavior of both sides when they are not
in a default sndrcv mode. Meaning the offerer wants to send only. Also
address hold scenario.

2. Since RTP is unidirectional what about multiplexing only to one
direction, currently you prevent it. The offerer may offer the same RTP
and RTCP port, the remote side can send both RTP and RTCP to the same
port but prefers to receive on different ports, do you think it makes
sense.

3.  When the offer includes port 0 in the m-line to find out the
capabilities of the other side, can it request later to support RTCP mux
even if the answer did not indicate support for it. The general case is
to move from multiplex to non-multiplex or back.

As for the BW issue.
My preference is to be able to still specify the AS and TIAS for the RTP
if resource reservation will be used. 

>From my point of view using different ports for audio and video allows
the specification of policy given higher priority to audio when
congestion occurs. The same goes to RTP and RTCP since my preference
will be to let the network discard RTCP and not RTP 

Roni Even

---

From: Randell Jesup <[email-masked]>
Date: Thu, 21 Sep 2006 10:59:53 -0400

>comments has to with this

RTCP is not bidirectional (in terms of ports).  Both RTP and RTCP are
unidirectional and specified by the receiver.  I understand what you mean,
but technically it's not the case.

>in a default sndrcv mode. Meaning the offerer wants to send only. Also

Ok, though it's not any different than normal - unless there's some
difference from normal behavior I don't see the need to add text - and
adding it could confuse people; they'll assume there has to be something
different for you to need to mention it.

>port but prefers to receive on different ports, do you think it makes

The current spec makes that impossible since it uses rtcp == rtp as a
form of indirect signalling that the answerer is ok with this.  Note that
most implementations that support a=rtcp would support rtcp == rtp without 
any modification, if the spec didn't mandate that they respond with rtcp ==
rtp.  While I can't think of why an existing implementation with a=rtcp
support *wouldn't* work if it got an rtp == rtcp offer, I suppose it's
possible.

You could add another parameter (a=rtcpmux:ok or some such) to indicate
that it was understood, but the responder doesn't want to receive muxed
data for some reason. (Perhaps some issue with gateways, relays or QoS for
example, though I can't think of one now..)

I'd be strongly tempted to remove the requirement to respond with rtcp=rtp,
*perhaps* add a=rtcpmux:ok, and allow the implementation to decide whether a
renegotiation is required.  (For example, if it gets the RTCP on the RTP
port, the other side probably is handling it ok anyways.)

Use of RFC 3605 is tricky anyways, since offering it (with a port != rtp+1)
often means you won't get any RTCP at all (and it's complicated by SBCs and
other RTP relays that ignore it and pass a=rtcp through unmodified, though
the RTCP port has changed).  Note that RFC 3605 basically says "if you need
this and it doesn't work, nothing is worse since you wouldn't have used it
unless you knew RTCP wasn't going to work.".  With this draft, that isn't
entirely the case - it may be being used to reduce call setup time and
resource (port) overhead.

>to move from multiplex to non-multiplex or back.

Re-negotiation is free to modify anything, so far as I know, so yes, it
should be allowed.

>will be to let the network discard RTCP and not RTP 

Separate ports does in theory allow for discarding RTCP without parsing the
payload types, though anything discarding RTCP would need to parse the SDP
enough to get the media lines and a=rtcp values anyways, so I'm not sure
it's much of a win.  I wouldn't consider this a strong argument.

-- 
Randell Jesup, Worldgate (developers of the Ojo videophone), ex-Amiga OS team
[email-masked]
"The fetters imposed on liberty at home have ever been forged out of the weapons
provided for defence against real, pretended, or imaginary dangers from abroad."
		- James Madison, 4th US president (1751-1836)

---

From: Randell Jesup <[email-masked]>
Date: Fri, 22 Sep 2006 10:08:53 -0400

Regarding http://www.ietf.org/internet-drafts/draft-ietf-avt-tfrc-profile-06.txt

Can I make a plea to please define RTP/SAVPFCC when defining RTP/AVPFCC?

This is another instance of the general issue of profile combinatoric
explosion, but until we find a way to allow negotiation of the combinatoric
elements individually, when we define a new dimension for profiles (like
CC, or early feedback) we need to include all the resultant (useful)
profiles, and not have to go back to define them later (like happened with SAVPF).

---

From: Colin Perkins <[email-masked]>
Date: Fri, 22 Sep 2006 23:14:36 +0100

> different for you to need to mention it.

Right - I don't think anything different happens here when multiplexing.

> port, the other side probably is handling it ok anyways.)

I think forcing symmetry is a good thing here, rather than allowing  
multiplexed RTP and RTCP in one direction, and non-multiplexed in the  
reverse. We had enough problems with non-symmetric RTP, that I don't  
particularly want to encourage other forms of asymmetry.

Colin