RE: [AVT] Fwd: I-D ACTION:draft-perkins-avt-rtp-and-rtcp-mux-00.txt- multiplexing to what extent

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:hd@qualcomm.com

> 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: <ybuu098lwq9.fsf@jesup.eng.wgate.com> 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
> rjesup@wgate.com
> 
> 
> _______________________________________________
> Audio/Video Transport Working Group
> avt@ietf.org
> https://www1.ietf.org/mailman/listinfo/avt

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