Re: Getting rid of SDP (relation to ORTC)

Here's what I present at a WebRTC virtual interim:

https://docs.google.com/presentation/d/1o-o5jZBLw3Py1OuenzWDkxDG6NigSmLHvGw5KemKWLw/edit#slide=id.g2f8f4acff1_1_136

And here's copy-and-paste version of the important bits:

interface SliceTransport {
  IceNetworkRoute addNetworkRoute(PacketTransport transport);
  void selectNetworkRoute(IceNetworkRoute networkRoute);
  void removeNetworkRoute(IceNetworkRoute networkRoute);
}

interface IceNetworkRoute {
  Promise sendCheck(...);
  eventhandler oncheckreceived;
}

interface UdpTransport : PacketTransport {
  readonly attribute IpPort localAddress;
  readonly attribute IpPort remoteAddress;
  void close();
}

interface UdpPort {
  readonly attribute IpPort localAddress;
  UdpTransport connect(IpPort remoteAddress);
  void close();
  eventhandler onnewremoteaddress;
}

interface NetworkManager {
  Promise<sequence<NetworkInfo>> EnumerateNetworks();
  Promise<UdpPort> OpenUdpPort(IPAddress localIp);
  attribute eventhandler onnetworkschanged;
}

interface NetworkInfo {
  readonly attribute sequence<IPAddress> ips;
  readonly attribute NetworkAdapterType type;
}

interface StunClient {
  Promise<IpPort> sendBindingRequest(PacketTransport transport, ...);
}

interface TurnClient {
  Promise<TurnAllocation> sendAllocationRequest(PacketTransport transport,
...);
}

interface TurnAllocation {
  readonly attribute IpPort serverAddress;
  TurnTransport connect(IpPort remoteAddress);
  void close();
  eventhandler onnewremoteaddress;
}

interface TurnTransport : PacketTransport {
  readonly attribute IpPort serverAddress;
  readonly attribute IpPort remoteAddress;
  void close();
}






On Mon, Mar 5, 2018 at 2:40 PM Lennart Grahl <lennart.grahl@gmail.com>
wrote:

> On 05.03.2018 23:20, Cullen Jennings wrote:
> >> On Mar 5, 2018, at 2:57 PM, Lennart Grahl <lennart.grahl@gmail.com>
> wrote:
> >>
> >>>
> >>> Let's define a low level modular api (that is what most devs want
> >>> anyway) that could be reused in different scenarios (ICE+DTLS+ICE or
> >>> quick) easily.
> >>
> >> Isn't that what ORTC does provide?
> >
> > So ORTC does a good job of what it does, which is get rid of the syntax
> of SDP and provide a programmatic interface to an RTP media stack that is
> roughly capable of what can be done with SDP Offer/Answer. As a result,
> most of ORTC 1:1 maps to the semantics or SDP.
> >
> > Take something simple like ptime and maxptime in ORTC. To real
> understand what these are and how they fit into RTP, what they do in an
> offer/answer, etc, you will be reading SDP documents. The approach in
> new-media is to ask if we could get rid of tons of the baggage that has
> accumulated in RTP, solve a bunch of the features that are too hard to do
> in existing RTP/ICE,  and simplify the RTP in a huge way that allowed us to
> move to something with far simpler semantics that SDP.
>
> Fair enough. Having read Peter's and Sergio's answers as well, it seems
> using ORTC as a starting point is a good idea and extending it with more
> fine granular control or entirely new "building blocks" (objects).
>
> Peter, can you send me a link to the SLICE spec/slides?
> (https://w3c.github.io/webrtc-ice does look way too high level to me)
>
> Cheers
> Lennart
>