Re: [AVT] Re: Layered codecs: use of PT to distinguish layers

Colin Perkins <csp@csperkins.org> writes:
>> If we assume (for the sake of assumption) a hard requirement for a
>> single firewall pinhole, you are screwed with respect to point D,  no
>> matter what you do.  Right?
>
>Why is this an assumption? Once you've gone to the trouble of  implementing
>all 96 pages of ICE, running two instances of it can't  be that much worse
>than running a single instance...

Well, there's a LOT of overhead per-port to set stuff up with ICE, though I
imagine once the environment is ferreted out subsequent ports _might_ be
faster.  (Gotcha is that you can have different issues on different ports
due to collisions, etc, which can cause the mapping style of the NAT to
change.)  A couple of ports - ok.  20 or 30 ports - ouch.

>Or: if you have a hard requirement for a single pin-hole, then punch  a
>hole for an IP-in-UDP tunnel, and run real RTP over it with as many  ports
>as you need :-)

So, add another layer to RTP that exists solely as a multiplex layer, but
with a lot of extra overhead.  :-) Not to say it's a bad idea - but I've
never been fond of the heavy use of ports in RTP as stream-identifiers.  It
saves a (very small) number of bits per packet, at best.  It made more
sense in pre-NAT days when it was first created, of course, but even then
there were limits on numbers of ports per machine - a server handling a lot
of SVC-type streams might have run out of ports in some (unusual) cases,
much the way http servers can have issues with ports.

Using ports as inherent stream identifiers simplifies the application
(slightly), but at a cost of complexity at the network level (STUN/ICE/etc).
Or so it seems to me (who wasn't involved in all the discussions :-)

-- 
Randell Jesup, Worldgate (developers of the Ojo videophone), ex-Amiga OS team
rjesup@wgate.com

_______________________________________________
Audio/Video Transport Working Group
avt@ietf.org
https://www1.ietf.org/mailman/listinfo/avt