Expose capabilities / Allow for IP:Post based connections / Better abstraction

Dear WebRTC,

you are the future, and should be carefully build. The current proposal 
does not expose the capabilities gained very well.

In general, the standard puts capabilities into a monolithic (pool) 
object (for the sake of performance and probably due to SIP influences). 
This may be due to a focus on video and audio in the initial development 
phase of the protocol, for which this setup is probably a good idea and 
common practice.It currently has the disadvantaged that the developer 
can't access and use the functionality separately, has to write 
complicated code for simple things and is restricted by predefined flows.

- Objects should be independent from an API perspective:
     - Resources (streams) should be pooled under the hood and have 
nothing to do with the API
     - If necessary expose "pools" the developer can "add" to, not 
require them
- Added protocols and gained features should be exposed to the developer 
(if there are use cases)
     - So he can invent what to do with them
     - Example below
- Higher level objects are a good addition, but not a good base 
abstraction.
     - Once you have a monolith, breaking it up in a lib is ugly, the 
other way around is not (Look at the code that exists today to do this ...)

This was written under the assumption that much of the existing 
infrastructure is used and little adapted. I suggest a dual approach 
where small exposed objects and the current big monolith co-exist (lets 
see who wins in 2.0 by analyzing usage ...).

 From a data channel / web developer perspective the API and 
requirements are overly complicated and lack the abilities to:
     1 - Establish a connection to another user directly, based on the 
exchange of ip:port pairs (not large SPD)
         - [RTCPeerConnection.]connect(ip, port, [timeout], [number] ...)
             - punches holes until [timeout], [number] may be useful to 
regulate the number of punches
             - various security restrictions to address flooding / 
miss-use, but does not differ from current attack vectors
         - onconnect / callback
             - continue flow (exchange SDP)
     2 - Find out the IP of the current system
         - getIPAddresses(['stun: ...', 'stun: ....'], ...)
             - Provide a call outside of the webrtc object
     3 - Provide a simple WebRTCSocket alternative to send data
         - WebRTCSocket("to_ip:to_port", "my_ip:my_port" /*obtained via 
navigator.getIPAddress(stunServers)*/)
             - Which does the following (probably implemented more 
efficiently):
                 - RTCPeerConnection.connect(to_ip, to_port);
                 - createDataChannel
                 - Expose events of the data channel
         - This can be done for audio/video too in order to break up the 
monolithic nature ...

Towards ICE:
     - Build own Http flows and provide the ability to solve the problem 
without ICE:
         - {'iceServers': [{'url': 'https://example.org/myip'}]};
             - For most clients this will provide me a valid address for 
later hole punching and it's easy to create
             - Return any answer format the developer chooses, client 
code knows what to do
             - I can start signaling logic at this point already (and 
close my server to the public)
         - Client must convert IP into a SPD format for exchange
             - createOffer(ip, function(description) {....})

Kind regards and thanks for reading
Johannes H.

PS: I am glad to answer anything unclear or address issues (participate 
in discussions)