News

W3C ORTC CG – Editors Draft Update – May 4

ORTC CG Editors Draft Update

http://ortc.org/wp-content/uploads/2016/05/ortc.html#change-log*

B.1 Changes since 01 March 2016

  1. Added the gather() method, as noted in: Issue 165
  2. Removed “public” from RTCIceGatherPolicy, as noted in: Issue 224
  3. Removed the minQuality attribute, as noted in: Issue 351
  4. Made send() and receive() asynchronous, as noted in: Issue 399, Issue 463, Issue 468 and Issue 469
  5. Provided additional information on ICE candidate errors, as noted in: Issue 402
  6. Added state attribute to RTCSctpTransport, as noted in: Issue 403
  7. Provided an example of RTX/RED/FEC configuration, as noted in: Issue 404
  8. Clarified payloadType uniqueness, as noted in: Issue 405
  9. Updated the list of header extensions, as noted in: Issue 409
  10. Added “goog-remb” to the list of feedback mechanisms, as noted in: Issue 410
  11. Added kind argument to the RTCRtpReceiver constructor, as noted in: Issue 411
  12. Clarified send() restrictions on kind, as noted in: Issue 414
  13. Added getAlgorithm() method, as noted in: Issue 427
  14. Changed RTCDataChannel protocol and label to USVString, as noted in: Issue 429
  15. Clarified nullable attributes and methods returning empty lists, as noted in: Issue 433
  16. Clarified support for the “direction” parameter, as noted in: Issue 442
  17. Clarified the apt capability of the “red” codec, as noted in: Issue 444
  18. Clarified usage of RTCRtpEncodingParameters attributes, as noted in: Issue 445
  19. Clarified firing of onssrcconflict event, as noted in: Issue 448
  20. Clarified that CNAME is only set on an RTCRtpSender, as noted in: Issue 450
  21. Updated references, as noted in: Issue 457
  22. Described behavior of send() and receive() with unset RTCRtpEncodingParameters, as noted in: Issue 461
  23. Corrected dictionary initialization in the examples, noted in: Issue 464 and Issue 465
  24. Corrected use of enums in the examples, noted in: Issue 466
  25. Clarified handling of identity constraints, as noted in: Issue 467 and Issue 468
  26. Clarified use of RTCRtpEncodingParameters, as noted in: Issue 470
  27. Changed hostCandidate type, as noted in: Issue 474
  28. Renamed state change event handlers to onstatechange, as noted in: Issue 475
  29. Updated description of RTCIceGatherer closed state, as noted in: Issue 476
  30. Updated description of RTCIceTransport object, as noted in: Issue 477
  31. Updated description of relatedPort, as noted in: Issue 484
  32. Updated description of RTCIceParameters, as noted in: Issue 485
  33. Clarified exceptions in RTCDataChannel construction, as noted in: Issue 492
  34. Provided a reference to error.message, as noted in: Issue 495
  35. Clarified RTCRtpReceiver description, as noted in: Issue 496
  36. Clarified default for clockRate attribute, as noted in: Issue 500
  37. Removed use of “null if unset”, as noted in: Issue 503
  38. Updated RTCSctpTransport constructor, as noted in: Issue 504
  39. Clarified behavior of getCapabilities(), as noted in: Issue 509
  40. Addressed issues with RTCDataChannelParameters, as noted in: Issue 519

WebRTC Developer Contract in Seattle – 5 months

webrtc1.1_logo

We have an immediate WebRTC development contract opportunity that has just come up in the Seattle area. The contract requires 4-5 full-time developers onsite, remote will not fit the bill on this one.

For this contract we are looking for a team lead, 2 x Node.js, 2 x common JS developers

You have built commercial web applications using WebRTC libraries and are intimately familiar with the WebRTC and ORTC specs and respective libraries.

Start date: ASAP

If you are interested please forward your resume elagerway@gmail.com

Microsoft Edge ships ORTC API preview

Screen Shot 2015-09-18 at 4.50.33 PM

From Microsoft – http://blogs.windows.com/msedgedev/2015/09/18/ortc-api-is-now-available-in-microsoft-edge/

Our initial ORTC implementation includes the following components:

  1. ORTC API Support. Our primary focus right now is audio/video communications. We have implemented the following objects: IceGatherer, IceTransport, DtlsTransport, RtpSender, RtpReceiver, as well as the RTCStatsinterfaces that are not shown directly in the diagram.
  2. RTP/RTCP multiplexing is supported and is required for use with DtlsTransport. A/V multiplexing is also supported.
  3. STUN/TURN/ICE support. We support STUN (RFC 5389), TURN (RFC 5766) as well as ICE (RFC 5245). Within ICE, regular nomination is supported, with aggressive nomination partially supported (as a receiver). DTLS-SRTP (RFC 5764) is supported, based on DTLS 1.0 (RFC 4347).
  4. Codec support. For audio codecs, we support G.711, G.722, Opus and SILK. We also support Comfort Noise (CN) and DTMF according to the RTCWEB audio requirements. For video we currently support the H.264UC codec used by Skype services, supporting advanced features such as simulcast, scalable video coding and forward error correction. We’re working toward to enabling interoperable video with H.264.

More here..

1 2 3 4 5 6 145 146
Archives
Recent Comments
    Privacy Settings
    We use cookies to enhance your experience while using our website. If you are using our Services via a browser you can restrict, block or remove cookies through your web browser settings. We also use content and scripts from third parties that may use tracking technologies. You can selectively provide your consent below to allow such third party embeds. For complete information about the cookies we use, data we collect and how we process them, please check our Privacy Policy
    Youtube
    Consent to display content from Youtube
    Vimeo
    Consent to display content from Vimeo
    Google Maps
    Consent to display content from Google
    Spotify
    Consent to display content from Spotify
    Sound Cloud
    Consent to display content from Sound