Subject: [rtcweb] I-D Action: draft-ietf-rtcweb-rtp-usage-14.txt

From: [email-masked]
Date: Fri, 16 May 2014 04:34:00 -0700

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Real-Time Communication in WEB-browsers Working Group of the IETF.

        Title           : Web Real-Time Communication (WebRTC): Media Transport and Use of RTP
        Authors         : Colin Perkins
                          Magnus Westerlund
                          Joerg Ott
	Filename        : draft-ietf-rtcweb-rtp-usage-14.txt
	Pages           : 43
	Date            : 2014-05-16

Abstract:
   The Web Real-Time Communication (WebRTC) framework provides support
   for direct interactive rich communication using audio, video, text,
   collaboration, games, etc. between two peers' web-browsers.  This
   memo describes the media transport aspects of the WebRTC framework.
   It specifies how the Real-time Transport Protocol (RTP) is used in
   the WebRTC context, and gives requirements for which RTP features,
   profiles, and extensions need to be supported.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-rtcweb-rtp-usage/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-rtcweb-rtp-usage-14

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-rtcweb-rtp-usage-14

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Magnus Westerlund <[email-masked]>
Date: Fri, 16 May 2014 13:38:12 +0200

WG,

This version is intended to take care of the editorial comments we
received during the WG last call as well as any we authors directly
agreed with and have yet to see any disagreement with.

At the interim next week we will take the opportunity to go through all
the changes to normative requirements as well as discuss the open
issues. I will attempt to summarize these to the mailing list also,
although start of them already are present in the review emails.

Cheers

Magnus

On 2014-05-16 13:34, [email-masked] wrote:
> _______________________________________________
> rtcweb mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/rtcweb
> 
> 

-- 

Magnus Westerlund

----------------------------------------------------------------------
Services, Media and Network features, Ericsson Research EAB/TXM
----------------------------------------------------------------------
Ericsson AB                 | Phone  +46 10 7148287
Färögatan 6                 | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden | mailto: [email-masked]
----------------------------------------------------------------------

---

From: "Hutton, Andrew" <[email-masked]>
Date: Mon, 19 May 2014 00:11:55 +0000

Looking through the updates and it is looking good I have a couple of minor comments.

In sections 4.5 and 4.6 the text around the use of SDP has been cleaned up but now both sections state a MUST requirement against signaling if SDP is used.  For example section 4.5 states "If SDP is used for signalling, this negotiation MUST use the attributes defined in [RFC5761]".  Whilst it makes sense to implement it this way probably the RTP usage document should not contain "MUST" level requirements on how signaling is implemented.

Maybe this is really something for the API considerations as if SDP is used at the API then we could say this is how it MUST be implemented.  

Type on section 6 "However, they generally some add overhead" -> "However,they generally add some overhead".

Andy

> -----Original Message-----
> From: rtcweb [mailto:[email-masked]] On Behalf Of Magnus
> Westerlund
> Sent: 16 May 2014 12:38
> To: [email-masked]
> Subject: Re: [rtcweb] I-D Action: draft-ietf-rtcweb-rtp-usage-14.txt
> 
> WG
>

---

From: Colin Perkins <[email-masked]>
Date: Mon, 19 May 2014 10:59:39 +0100

> Maybe this is really something for the API considerations as if SDP is used at the API then we could say this is how it MUST be implemented.

I don’t see this as a problem. Many RTP-related specification mandate particular SDP attributes if SDP signalling is used. 

> Type on section 6 "However, they generally some add overhead" -> "However,they generally add some overhead".

Fixed, thanks.

-- 
Colin Perkins
http://csperkins.org/