Re: [rtcweb] Reasons (not?) to multiplex audio with video

[Ross Finlayson <[e-mail]>]

When I first started thinking about the 'multiplexing' question, I 
tended to support Colin's point-of-view.  Carrying audio and video on 
separate ports gives a system more flexibility, is compatible with 
existing implementations (including mine :-), and is in line with 
long-standing assumptions about the use of the SSRC, RTCP etc.

But over time I have become increasingly sympathetic to Jonathan's 
arguments - especially regarding NAT traversal - in particular, setup 
time, use of resources (# of ports), and failure modes.  We have to 
assume that many, if not most users of RTCWEB systems will be on 
unsophisticated, heavily NATed IPv4 home (or hotel, or coffee shop 
etc.) networks.  As IPv4 addresses become scarcer, this situation 
will likely only get worse.

However, as someone noted (in the context of "security") during 
today's RTCWEB session, we're not the first people to be designing a 
(hopefully) widely-deployed consumer-oriented peer-to-peer A/V chat 
system.  There are several existing systems out there, so it might be 
instructive to look at how they address the 'media multiplexing' 
issue - in particular:

1/ Apple's "FaceTime".  OK, this is not browser-based (although with 
a bit of work it probably could have been), but it does use RTP.  Is 
it using separate ports for audio and video (and two more for RTCP)? 
If so, has NAT traversal been a problem, and would it have been 
beneficial to have been able to reduce the number of ports used?  (Is 
Dave Singer on this mailing list?)

2/ Facebook's new video chat.  OK, this uses Skype, and thus 
presumably not RTP (at least, not now).  But does this multiplex 
audio+video on a single port?  (And if so, did this help motivate 
Jonathan's point-of-view?)

3/ Google Plus "Hangouts".  Similar question to 1/.

4/ Any others (whether RTP-based or not)?

-- 

Ross Finlayson
Live Networks, Inc.
http://www.live555.com/