[AVTCORE] IP address/port number handling in "RTP-in-QUIC" encapsulation layer

[Spencer Dawkins at IETF <[e-mail]>]

We've had some pretty interesting observations in
https://github.com/SpencerDawkins/sdp-rtp-quic-issues/issues/4 about our
observation that RTP/RTCP knows about IP addresses and  port numbers, but
QUIC applications only use IP addresses and port numbers when establishing
connections, and after that, QUIC applications are using connection IDs,
even if underlying IP addresses change because of NAT rebinding or the QUIC
implementation itself performs connection migration.

This is obviously part of a larger question about RTP-in-QUIC encapsulation
layer functionality, but it's interesting now, because

   - if an encapsulation layer can handle all the vagaries of ports and IP
   addresses, the application doesn't have to
   - if an application is talking to a single IP address/port number, the
   encapsulation layer can continue to present that interface to the
   application, no matter what else happens below the encapsulation layer.
   - If the IP address/port numbers are "virtual", the underlying IP
   addresses need not even be the same IP address family. If an application
   thinks it's talking to an IPv4 endpoint even if the underlying network
   supports IPv6, this could remove some impediments to IPv6 migration.
   - If the QUIC connection ID is the same for all the m=lines, this might
   provide bundling functionality as well.

Obviously, this will require more thought (Suhas suggested "design session"
in one of the comments), but does it seem interesting and/or useful?

Best,

Spencer