From rlb@ipv.sx Mon Apr 1 10:40:35 2013 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4E6AD21F8D0D for ; Mon, 1 Apr 2013 10:40:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.037 X-Spam-Level: X-Spam-Status: No, score=-2.037 tagged_above=-999 required=5 tests=[AWL=0.940, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ckOBsra9GwwF for ; Mon, 1 Apr 2013 10:40:33 -0700 (PDT) Received: from mail-oa0-f49.google.com (mail-oa0-f49.google.com [209.85.219.49]) by ietfa.amsl.com (Postfix) with ESMTP id 99FF321F8D01 for ; Mon, 1 Apr 2013 10:40:33 -0700 (PDT) Received: by mail-oa0-f49.google.com with SMTP id j6so2169400oag.22 for ; Mon, 01 Apr 2013 10:40:33 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:x-originating-ip:in-reply-to:references :date:message-id:subject:from:to:cc:content-type:x-gm-message-state; bh=IziIK7yxnY9Oy0ASs2ZFRM2zVCSUaF6SlIlyngJL47k=; b=MaGL3Wct5f4vnEvMo5niBEkJbgSe75VLVsCN2jVZVEKegmHrHkE2WhUc6GwOyClr/T NlM9xi4eJOD8jyWa6urD5mPvg0ETUUCfSaCU/5Z58SFpRNZEf1rhKQxRE4TzZXMFpL6t p7r8qKkN4TBGuOLdeO4f54yUoDcEQnmu03xeahfq6awwcIFcllAk52smu1yi5S+avgZ4 a3bobz13X10drgvzaS9e4MvqlkhY3oRDXphSshnv5f1cHGWS8Wk42L17goYwxyN6hU/X UBs/97rgve8fw3tQBA45MDLwpnrRAs7uolYMGaEFN3mS0zqlbLv2OC3zmAhURTIhRfg/ NXYg== MIME-Version: 1.0 X-Received: by 10.60.14.104 with SMTP id o8mr4299840oec.127.1364838033154; Mon, 01 Apr 2013 10:40:33 -0700 (PDT) Received: by 10.60.160.201 with HTTP; Mon, 1 Apr 2013 10:40:33 -0700 (PDT) X-Originating-IP: [192.1.51.16] In-Reply-To: <05c501ce2de1$fedab280$fc901780$@gmail.com> References: <05c501ce2de1$fedab280$fc901780$@gmail.com> Date: Mon, 1 Apr 2013 13:40:33 -0400 Message-ID: From: Richard Barnes To: Roni Even Content-Type: multipart/alternative; boundary=e89a8fb1ef1624bd1b04d9501ed5 X-Gm-Message-State: ALoCoQklYS6eQt1M52OX6bg09nmcA/U1O4wIYn9qg5+r4xDabcALVnn5E63TZBcttNjxAylFm/7K Cc: iesg-secretary@ietf.org, rai-ads@tools.ietf.org, avt@ietf.org, Magnus Westerlund Subject: Re: [AVTCORE] Request for publication of draft-ietf-avtcore-idms-09 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Apr 2013 17:40:35 -0000 --e89a8fb1ef1624bd1b04d9501ed5 Content-Type: text/plain; charset=ISO-8859-1 Thanks, Roni. Confirming receipt. This hasn't shown up in the datatracker yet as Publication Requested, but hopefully it will soon. --Richard On Sun, Mar 31, 2013 at 3:33 AM, Roni Even wrote: > Hi Richard,**** > > I'd like to request that draft-ietf-avtcore-idms-09, Inter-destination > Media Synchronization using the RTP Control Protocol (RTCP), be published > as Standard Track RFC. **** > > ** ** > > I've reviewed the draft in detail, and the AVTCore working group was given > the opportunity to comment. The draft is documented in sufficient detail to > meet the registration requirements, and doesn't conflict with other work in > AVTCore. Accordingly, please consider it for publication.**** > > ** ** > > Thanks,**** > > Roni Even**** > > ** ** > > ** ** > > (1) What type of RFC is being requested (BCP, Proposed Standard, Internet > Standard, Informational, Experimental, or Historic)? Why is this the proper > type of RFC? Is this type of RFC indicated in the title page header? **** > > This is a standard track RFC defining new RTCP packets and procedures for > synchronizing media between multiple sites.**** > > The title page header indicates it.**** > > (2) The IESG approval announcement includes a Document Announcement > Write-Up. Please provide such a Document Announcement Write-Up. Recent > examples can be found in the "Action" announcements for approved documents. > The approval announcement contains the following sections: **** > > Technical Summary:**** > > This document defines a new RTP Control Protocol (RTCP) Packet Type and > RTCP Extended Report (XR) Block Type to be used for achieving > Inter-Destination Media Synchronization (IDMS). IDMS is the process of > synchronizing playout across multiple geographically distributed media > receivers. Typical use cases in which IDMS is usefull are social TV, > shared service control (i.e. applications where two or more > geographically separated users are watching a media stream together), > distance learning, networked video walls, networked loudspeakers, etc.*** > * > > **** > > Working Group Summary:**** > > This document went through a working group last call. There were comments > and the document was updated to resolve all comments. The work started in > ETSI and since it have to do with RTCP it was brought to the IETF AVTCore > WG. The last issue that took some time was to update the ETSI document > clarifying that the change control will be at the IETF.**** > > Document Quality:**** > > The document got good reviews from AVTcore members. **** > > Personnel:**** > > Roni Even is the Document Shepherd and the Responsible Area Director is Richard > Barnes.**** > > (3) Briefly describe the review of this document that was performed by the > Document Shepherd. If this version of the document is not ready for > publication, please explain why the document is being forwarded to the > IESG. **** > > The shepherd reviewed the document very carefully in all the versions > including the last one 09.**** > > (4) Does the document Shepherd have any concerns about the depth or > breadth of the reviews that have been performed? **** > > This document got good review by mutiple people from AVTcore and all > comments were addressed.**** > > (5) Do portions of the document need review from a particular or from > broader perspective, e.g., security, operational complexity, AAA, DNS, > DHCP, XML, or internationalization? If so, describe the review that took > place. **** > > No need for any such review.**** > > (6) Describe any specific concerns or issues that the Document Shepherd > has with this document that the Responsible Area Director and/or the IESG > should be aware of? For example, perhaps he or she is uncomfortable with > certain parts of the document, or has concerns whether there really is a > need for it. In any event, if the WG has discussed those issues and has > indicated that it still wishes to advance the document, detail those > concerns here. **** > > No concerns**** > > (7) Has each author confirmed that any and all appropriate IPR disclosures > required for full conformance with the provisions of BCP 78 and BCP 79 have > already been filed. If not, explain why?**** > > Yes, the shepherd has confirmed with all authors.**** > > (8) Has an IPR disclosure been filed that references this document? If so, > summarize any WG discussion and conclusion regarding the IPR disclosures. > **** > > No IPR disclosure**** > > (9) How solid is the WG consensus behind this document? Does it represent > the strong concurrence of a few individuals, with others being silent, or > does the WG as a whole understand and agree with it? **** > > There was a strong consensus to start this work at the IETF when it was > brought. Multiple people contributed to the work and as a result the WG > identified two new work items that are addressed in other new documents > which are currently in progress.**** > > (10) Has anyone threatened an appeal or otherwise indicated extreme > discontent? If so, please summarise the areas of conflict in separate email > messages to the Responsible Area Director. (It should be in a separate > email because this questionnaire is publicly available.) **** > > No**** > > (11) Identify any ID nits the Document Shepherd has found in this > document. (See http://www.ietf.org/tools/idnits/ and the Internet-Drafts > Checklist). Boilerplate checks are not enough; this check needs to be > thorough. **** > > No ID nits in this document.**** > > (12) Describe how the document meets any required formal review criteria, > such as the MIB Doctor, media type, and URI type reviews. **** > > Not applicable**** > > (13) Have all references within this document been identified as either > normative or informative? **** > > yes**** > > (14) Are there normative references to documents that are not ready for > advancement or are otherwise in an unclear state? If such normative > references exist, what is the plan for their completion? **** > > There is a normative reference to draft-ietf-avtcore-clksrc-03 that will > start WGLC very soon.**** > > (15) Are there downward normative references (see RFC 3967)? If so, list > these downward references to support the Area Director in the Last Call > procedure. **** > > no**** > > (16) Will publication of this document change the status of any existing > RFCs? Are those RFCs listed on the title page header, listed in the > abstract, and discussed in the introduction? If the RFCs are not listed in > the Abstract and Introduction, explain why, and point to the part of the > document where the relationship of this document to the other RFCs is > discussed. If this information is not in the document, explain why the WG > considers it unnecessary. **** > > No**** > > (17) Describe the Document Shepherd's review of the IANA considerations > section, especially with regard to its consistency with the body of the > document. Confirm that all protocol extensions that the document makes are > associated with the appropriate reservations in IANA registries. Confirm > that any referenced IANA registries have been clearly identified. Confirm > that newly created IANA registries include a detailed specification of the > initial contents for the registry, that allocations procedures for future > registrations are defined, and a reasonable name for the new registry has > been suggested (see RFC 5226). **** > > This document defines a new extension URI to the RTP Compact Header > Extensions sub-registry of the Real-Time Transport Protocol (RTP) > Parameters registry. The registration was reviewed by the document shepherd > and it follows the registration requirements. **** > > ** ** > > No new IANA registries are defined.**** > > ** ** > > (18) List any new IANA registries that require Expert Review for future > allocations. Provide any public guidance that the IESG would find useful in > selecting the IANA Experts for these new registries. **** > > No new IANA registries.**** > > (19) Describe reviews and automated checks performed by the Document > Shepherd to validate sections of the document written in a formal language, > such as XML code, BNF rules, MIB definitions, etc. **** > > There is an ABNF definition for using the new RTCP packet using RFC3264 > offer answer. This is common for any new RTCP packe**** > --e89a8fb1ef1624bd1b04d9501ed5 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Thanks, Roni. =A0Confirming receipt. =A0This hasn't shown up in the dat= atracker yet as Publication Requested, but hopefully it will soon.
--Ri= chard
=A0

On Sun, Mar 31= , 2013 at 3:33 AM, Roni Even <ron.even.tlv@gmail.com> w= rote:

Hi Richard,

I'd like to request that draft-ietf-avtcore-idms-09, Inter-destination = Media Synchronization using the RTP Control Protocol (RTCP), be published a= s Standard Track RFC.

=A0

I've reviewed the draft in detail, and the AVTCo= re working group was given the opportunity to comment. The draft is documen= ted in sufficient detail to meet the registration requirements, and doesn&#= 39;t conflict with other work in AVTCore. Accordingly, please consider it f= or publication.

=A0

Thanks,<= u>

Roni Even

=A0

=A0

(1) What type of RFC is being requested = (BCP, Proposed Standard, Internet Standard, Informational, Experimental, or= Historic)? Why is this the proper type of RFC? Is this type of RFC indicat= ed in the title page header?

This is a standard track RFC defining ne= w RTCP packets and procedures for synchronizing media between multiple site= s.

The title pag= e header indicates it.

(2) The IESG approval announcement includes a Docume= nt Announcement Write-Up. Please provide such a Document Announcement Write= -Up. Recent examples can be found in the "Action" announcements f= or approved documents. The approval announcement contains the following sec= tions:

Technical Summary:<= /p>

This document defines a new RTP Control Protocol = (RTCP) Packet Type and RTCP Extended Report (XR) Block Type to be used for = achieving Inter-Destination Media Synchronization (IDMS).=A0 IDMS is the pr= ocess of synchronizing playout across multiple geographically distributed m= edia receivers. Typical use cases in which IDMS is usefull are social TV, s= hared=A0 service control (i.e. applications where two or more geographicall= y=A0 separated users are watching a media stream together), distance=A0 lea= rning, networked video walls, networked loudspeakers, etc.

Working Group Summary:

This document went through a working group last call. There were c= omments and the document was updated to resolve all comments. The work star= ted in ETSI and since it have to do with RTCP it was brought to the IETF AV= TCore WG. The last issue that took some time was to update the ETSI documen= t clarifying that the change control will be at the IETF.

Document Quality:

The document got good reviews from AVT= core members.=A0

Personnel:

Roni Even is the Documen= t Shepherd and the Responsible Area Director is Richard Barnes.

(3) Briefly describe the review of this = document that was performed by the Document Shepherd. If this version of th= e document is not ready for publication, please explain why the document is= being forwarded to the IESG.

The shepherd reviewed th= e document very carefully in all the versions including the last one 09.

(4) Does the document Shepherd have any = concerns about the depth or breadth of the reviews that have been performed= ?

This document= got good review by mutiple people from AVTcore and all comments were addre= ssed.

(5) Do portions of the document need rev= iew from a particular or from broader perspective, e.g., security, operatio= nal complexity, AAA, DNS, DHCP, XML, or internationalization? If so, descri= be the review that took place.

No need for any such review.

(6) Describe any specific c= oncerns or issues that the Document Shepherd has with this document that th= e Responsible Area Director and/or the IESG should be aware of? For example= , perhaps he or she is uncomfortable with certain parts of the document, or= has concerns whether there really is a need for it. In any event, if the W= G has discussed those issues and has indicated that it still wishes to adva= nce the document, detail those concerns here.

No concerns

(7) Has each author confirmed that any and a= ll appropriate IPR disclosures required for full conformance with the provi= sions of BCP 78 and BCP 79 have already been filed. If not, explain why?=

Yes, the shepherd has co= nfirmed with all authors.

(8) Has an IPR disclosure been filed that references this docum= ent? If so, summarize any WG discussion and conclusion regarding the IPR di= sclosures.

No I= PR disclosure

(9) How solid is the WG consensus behind= this document? Does it represent the strong concurrence of a few individua= ls, with others being silent, or does the WG as a whole understand and agre= e with it?

There was a strong consensus to start th= is work at the IETF when it was brought. Multiple people contributed to the= work and as a result the WG identified two new work items that are address= ed in other new documents which are currently in progress.

(10) Has anyone threatened an appeal or = otherwise indicated extreme discontent? If so, please summarise the areas o= f conflict in separate email messages to the Responsible Area Director. (It= should be in a separate email because this questionnaire is publicly avail= able.)

No

(11) Identify any ID nits the Document Shepherd has f= ound in this document. (See http://www.ietf.org/tools/idnits/ and the Internet-Dra= fts Checklist). Boilerplate checks are not enough; this check needs to be t= horough.

No ID nits in this document.

(12) Describe how the docum= ent meets any required formal review criteria, such as the MIB Doctor, medi= a type, and URI type reviews.

Not applicable

<= p class=3D"MsoNormal">(13) Have all references within this docu= ment been identified as either normative or informative?

yes

(14) Are there normative references to documents tha= t are not ready for advancement or are otherwise in an unclear state? If su= ch normative references exist, what is the plan for their completion?

There is a normative reference to draft-ietf-avtcore-clksrc-03 that will start WGLC very soon.=

(15) Are there downward normative re= ferences (see RFC 3967)? If so, list these downward references to support t= he Area Director in the Last Call procedure.

no

(16) Will publication of this document change the sta= tus of any existing RFCs? Are those RFCs listed on the title page header, l= isted in the abstract, and discussed in the introduction? If the RFCs are n= ot listed in the Abstract and Introduction, explain why, and point to the p= art of the document where the relationship of this document to the other RF= Cs is discussed. If this information is not in the document, explain why th= e WG considers it unnecessary.

No=

(17) Describe the = Document Shepherd's review of the IANA considerations section, especial= ly with regard to its consistency with the body of the document. Confirm th= at all protocol extensions that the document makes are associated with the = appropriate reservations in IANA registries. Confirm that any referenced IA= NA registries have been clearly identified. Confirm that newly created IANA= registries include a detailed specification of the initial contents for th= e registry, that allocations procedures for future registrations are define= d, and a reasonable name for the new registry has been suggested (see RFC 5= 226).

This document defines a new extension URI to the RTP Compac= t Header Extensions sub-registry of the Real-Time Transport Protocol (RTP)= =A0=A0 Parameters registry. The registration was reviewed by the document s= hepherd and it follows the registration requirements.

=A0

No new IANA registries are defined.

=A0

(18) List any new IANA registries that r= equire Expert Review for future allocations. Provide any public guidance th= at the IESG would find useful in selecting the IANA Experts for these new r= egistries.

No new IANA registries.

(19) Describe reviews and automa= ted checks performed by the Document Shepherd to validate sections of the d= ocument written in a formal language, such as XML code, BNF rules, MIB defi= nitions, etc.

There is an ABNF definition for using the new RTCP p= acket using RFC3264 offer answer. This is common for any new RTCP packe<= /u>


--e89a8fb1ef1624bd1b04d9501ed5-- From kevin.gross@avanw.com Mon Apr 1 14:41:34 2013 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C4CD1F0D1A for ; Mon, 1 Apr 2013 14:41:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.416 X-Spam-Level: X-Spam-Status: No, score=-1.416 tagged_above=-999 required=5 tests=[AWL=0.226, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Str9iOlbvmBH for ; Mon, 1 Apr 2013 14:41:33 -0700 (PDT) Received: from oproxy5-pub.bluehost.com (oproxy5-pub.bluehost.com [67.222.38.55]) by ietfa.amsl.com (Postfix) with SMTP id 3A0921F0D0E for ; Mon, 1 Apr 2013 14:41:33 -0700 (PDT) Received: (qmail 7135 invoked by uid 0); 1 Apr 2013 21:41:09 -0000 Received: from unknown (HELO host291.hostmonster.com) (74.220.215.91) by cpoproxy2.bluehost.com with SMTP; 1 Apr 2013 21:41:09 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=avanw.com; s=default; h=Content-Type:Cc:To:From:Subject:Message-ID:Date:References:In-Reply-To:MIME-Version; bh=huM2v4Z0iQW3KNuoaTk5ix1whwv4RJbgWn30lqvJvR4=; b=RlPbzxFi3evlK62z2I7fUtVsxT72amm0dyvFbYKApS5CIGrPxs87drbng0n15TKGsDo0p2uwjtQ7ndmlxgsdOD842ncoZoiAv8vX4/uskslMfVs2m0L7XhLYTDjI+rGJ; Received: from [209.85.223.177] (port=53566 helo=mail-ie0-f177.google.com) by host291.hostmonster.com with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.80) (envelope-from ) id 1UMmTV-0001Kp-LT for avt@ietf.org; Mon, 01 Apr 2013 15:41:09 -0600 Received: by mail-ie0-f177.google.com with SMTP id tp5so2820054ieb.22 for ; Mon, 01 Apr 2013 14:41:08 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.50.237.71 with SMTP id va7mr4027435igc.88.1364852468711; Mon, 01 Apr 2013 14:41:08 -0700 (PDT) Received: by 10.50.183.163 with HTTP; Mon, 1 Apr 2013 14:41:08 -0700 (PDT) In-Reply-To: <51541502.90406@ericsson.com> References: <513F7C5B.5060101@ericsson.com> <51541502.90406@ericsson.com> Date: Mon, 1 Apr 2013 15:41:08 -0600 Message-ID: From: Kevin Gross To: Magnus Westerlund Content-Type: multipart/alternative; boundary=f46d0447a24391ee0c04d9537a37 X-Identified-User: {1416:host291.hostmonster.com:avanwcom:avanw.com} {sentby:smtp auth 209.85.223.177 authed with kevin.gross@avanw.com} Cc: "avt@ietf.org" Subject: Re: [AVTCORE] Reminder: Re: WG last call on draft-ietf-avtcore-6222bis-01 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 01 Apr 2013 21:41:34 -0000 --f46d0447a24391ee0c04d9537a37 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable You are not alone. I have done several rounds of review and comment resolution with the authors and have checked this version also. At this point, all my issues have been addressed. Kevin Gross +1-303-447-0517 Media Network Consultant AVA Networks - www.AVAnw.com , www.X192.org On Thu, Mar 28, 2013 at 4:01 AM, Magnus Westerlund < magnus.westerlund@ericsson.com> wrote: > WG, > > So far there has be no other reviews of this document than mine. > > Can someone please review this document? > > I hereby extended the WG last call with one week until the 7th of April. > > Cheers > > Magnus > > On 2013-03-12 20:04, Magnus Westerlund wrote: > > WG, > > > > This is to announce the start of a WG last call on: > > > > Guidelines for Choosing RTP Control Protocol (RTCP) Canonical Names > > (CNAMEs) to be published as a proposed standard. > > > > Document can be retrieved here: > > https://datatracker.ietf.org/doc/draft-ietf-avtcore-6222bis/ > > > > Please provide any feedback by the 31st of March. > > > > Regards > > > > Magnus Westerlund > > WG chair > > > > > > ---------------------------------------------------------------------- > > Multimedia Technologies, Ericsson Research EAB/TVM > > ---------------------------------------------------------------------- > > Ericsson AB | Phone +46 10 7148287 > > F=E4r=F6gatan 6 | Mobile +46 73 0949079 > > SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com > > ---------------------------------------------------------------------- > > > > _______________________________________________ > > Audio/Video Transport Core Maintenance > > avt@ietf.org > > https://www.ietf.org/mailman/listinfo/avt > > > > > > > -- > > Magnus Westerlund > > ---------------------------------------------------------------------- > Multimedia Technologies, Ericsson Research EAB/TVM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > F=E4r=F6gatan 6 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- > > _______________________________________________ > Audio/Video Transport Core Maintenance > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt > --f46d0447a24391ee0c04d9537a37 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
You are not alone. I have done several rounds of review an= d comment resolution with the authors and have checked this version also. A= t this point, all my issues have been addressed.

Kevin Gross
+1-303-447-0517
Media = Network Consultant
AVA Networks -=A0www.AVAnw.com,=A0www.X192.org


On Thu, Mar 28, 2013 at 4:01 AM, Magnus = Westerlund <magnus.westerlund@ericsson.com> wro= te:
WG,

So far there has be no other reviews of this document than mine.

Can someone please review this document?

I hereby extended the WG last call with one week until the 7th of April.
Cheers

Magnus

On 2013-03-12 20:04, Magnus Westerlund wrote:
> WG,
>
> This is to announce the start of a WG last call on:
>
> Guidelines for Choosing RTP Control Protocol (RTCP) Canonical Names > (CNAMEs) to be published as a proposed standard.
>
> Document can be retrieved here:
> https://datatracker.ietf.org/doc/draft-ietf-avtcore-62= 22bis/
>
> Please provide any feedback by the 31st of March.
>
> Regards
>
> Magnus Westerlund
> WG chair
>
>
> ----------------------------------------------------------------------=
> Multimedia Technologies, Ericsson Research EAB/TVM
> ----------------------------------------------------------------------=
> Ericsson AB =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| Phone =A0+46 10 7148287
> F=E4r=F6gatan 6 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| Mobile +46 73 0949079
> SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com
> ----------------------------------------------------------------------=
>
> _______________________________________________
> Audio/Video Transport Core Maintenance
> avt@ietf.org
> https://www.ietf.org/mailman/listinfo/avt
>
>


--

Magnus Westerlund

----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| Phone =A0+46 10 7148287
F=E4r=F6gatan 6 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com
----------------------------------------------------------------------

_______________________________________________
Audio/Video Transport Core Maintenance
avt@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/avt

--f46d0447a24391ee0c04d9537a37-- From magnus.westerlund@ericsson.com Tue Apr 2 01:13:54 2013 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7746321F97E1 for ; Tue, 2 Apr 2013 01:13:54 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.249 X-Spam-Level: X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FOTgMce72gCl for ; Tue, 2 Apr 2013 01:13:53 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id C916321F97DD for ; Tue, 2 Apr 2013 01:13:51 -0700 (PDT) X-AuditID: c1b4fb2d-b7f316d0000028db-a9-515a933e20d2 Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id BB.CA.10459.E339A515; Tue, 2 Apr 2013 10:13:50 +0200 (CEST) Received: from [127.0.0.1] (153.88.115.8) by esessmw0237.eemea.ericsson.se (153.88.115.91) with Microsoft SMTP Server id 8.3.279.1; Tue, 2 Apr 2013 10:13:49 +0200 Message-ID: <515A933D.5090806@ericsson.com> Date: Tue, 2 Apr 2013 10:13:49 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: Kevin Gross References: <513F7C5B.5060101@ericsson.com> <51541502.90406@ericsson.com> In-Reply-To: X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprALMWRmVeSWpSXmKPExsUyM+Jvra7d5KhAgzVbzSxe9qxkt3hxqJ3N gcnj39XtzB5LlvxkCmCK4rJJSc3JLEst0rdL4Mro3XqVrWClXMX0BXeZGxjniHcxcnJICJhI vN/7lgXCFpO4cG89G4gtJHCKUWL2D60uRi4gexmjxI95U1hBErwC2hJ7Vx5lBrFZBFQkmqZu BWtgE7CQuPmjEcwWFQiW+PnqDAtEvaDEyZlPwGwRAXWJR7seMnUxcnAwCyhKTGqXBAkLCwRJ 7F4ykx1iVx+jxM+t19lBEpwCgRKdf5sZIY6TlNjyoh0sziygJzHlagsjhC0v0bx1NjPE0doS DU0drBMYhWYhWT0LScssJC0LGJlXMbLnJmbmpJcbbmIEhurBLb91dzCeOidyiFGag0VJnDfM 9UKAkEB6YklqdmpqQWpRfFFpTmrxIUYmDk6pBkbdt4m6SU9+rFoSvnD9SatdpzxFsg3lFni2 mX/yvx57VGRl6xu/T/KiO6uyS2PN+duvrTVs0zcoLe3S+dGV48M+g/PU9+XSt8VbZOdz9LPY 9LVfCrIoZnodnfHNPvBqurVcWk3otNBbV3U2vpvE2r7tZufeFMubL8o33b0oWbn+qV1P1VWz HUosxRmJhlrMRcWJAIukNjgjAgAA Cc: "avt@ietf.org" Subject: Re: [AVTCORE] Reminder: Re: WG last call on draft-ietf-avtcore-6222bis-01 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Apr 2013 08:13:54 -0000 Thanks Kevin, To be clear towards everyone, we do need comments during WG last call. If you have before reviewed the document, a notice of you having verified any previous issues you raised being taken care of helps us chairs determine that there consensus in the WG to request publication of this document. Cheers Magnus On 2013-04-01 23:41, Kevin Gross wrote: > You are not alone. I have done several rounds of review and comment > resolution with the authors and have checked this version also. At this > point, all my issues have been addressed. > > Kevin Gross > +1-303-447-0517 > Media Network Consultant > AVA Networks - www.AVAnw.com , www.X192.org > > > > On Thu, Mar 28, 2013 at 4:01 AM, Magnus Westerlund > > > wrote: > > WG, > > So far there has be no other reviews of this document than mine. > > Can someone please review this document? > > I hereby extended the WG last call with one week until the 7th of April. > > Cheers > > Magnus > > On 2013-03-12 20:04, Magnus Westerlund wrote: > > WG, > > > > This is to announce the start of a WG last call on: > > > > Guidelines for Choosing RTP Control Protocol (RTCP) Canonical Names > > (CNAMEs) to be published as a proposed standard. > > > > Document can be retrieved here: > > https://datatracker.ietf.org/doc/draft-ietf-avtcore-6222bis/ > > > > Please provide any feedback by the 31st of March. > > > > Regards > > > > Magnus Westerlund > > WG chair > > > > > > ---------------------------------------------------------------------- > > Multimedia Technologies, Ericsson Research EAB/TVM > > ---------------------------------------------------------------------- > > Ericsson AB | Phone +46 10 7148287 > > > Färögatan 6 | Mobile +46 73 0949079 > > > SE-164 80 Stockholm, Sweden| mailto: > magnus.westerlund@ericsson.com > > ---------------------------------------------------------------------- > > > > _______________________________________________ > > Audio/Video Transport Core Maintenance > > avt@ietf.org > > https://www.ietf.org/mailman/listinfo/avt > > > > > > > -- > > Magnus Westerlund > > ---------------------------------------------------------------------- > Multimedia Technologies, Ericsson Research EAB/TVM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > > Färögatan 6 | Mobile +46 73 0949079 > > SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com > > ---------------------------------------------------------------------- > > _______________________________________________ > Audio/Video Transport Core Maintenance > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt > > -- Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From magnus.westerlund@ericsson.com Tue Apr 2 02:12:30 2013 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0AF7421F9895 for ; Tue, 2 Apr 2013 02:12:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.249 X-Spam-Level: X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ihu0+-WAPjZ1 for ; Tue, 2 Apr 2013 02:12:29 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id ED92821F9864 for ; Tue, 2 Apr 2013 02:12:28 -0700 (PDT) X-AuditID: c1b4fb30-b7f0d6d000007e61-fc-515aa0fb6e34 Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 66.3E.32353.BF0AA515; Tue, 2 Apr 2013 11:12:27 +0200 (CEST) Received: from [127.0.0.1] (153.88.115.8) by esessmw0247.eemea.ericsson.se (153.88.115.94) with Microsoft SMTP Server id 8.3.279.1; Tue, 2 Apr 2013 11:12:27 +0200 Message-ID: <515AA0FA.5010807@ericsson.com> Date: Tue, 2 Apr 2013 11:12:26 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: avt@ietf.org, draft-ietf-avtcore-avp-codecs@tools.ietf.org References: <513F7BDD.8010700@ericsson.com> In-Reply-To: <513F7BDD.8010700@ericsson.com> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmplluLIzCtJLcpLzFFi42KZGfG3Vvf3gqhAgxXbzCxe9qxkt9i7ZwqL A5PHkiU/mTy+XP7MFsAUxWWTkpqTWZZapG+XwJXRt2Mua8Ex/oqVW2cxNTBe4eli5OSQEDCR mHryFTuELSZx4d56ti5GLg4hgVOMEk2P5zBBOMsYJa7NPsgCUsUroC1xpO0aWAeLgIrEr44e ZhCbTcBC4uaPRjYQW1QgWOLnqzNQ9YISJ2c+AbNFBOwkVi1czwhiCwu4S1x58BLMFgKZebGJ FcTmFNCReHtiDSPERZISW160g+1iFtCTmHK1hRHClpdo3jqbGaa3oamDdQKj4Cwk62YhaZmF pGUBI/MqRvbcxMyc9HLzTYzAoDy45bfBDsZN98UOMUpzsCiJ84a7XggQEkhPLEnNTk0tSC2K LyrNSS0+xMjEwSnVwKjF+Z3dZZ9U5wbJ5dZfOLs1MiquyG+tnbMg9+gijq1qDzd8ONg/SSx2 YuueeT6rtnwznGy4673LhZCYOy9WJb/VXz3v78+UWdqbJxzi8tl8V6936br4fR9PbNu/nHdf +yPmbZabE7/P843M/h8fYN+vF60sKP2BievNlCzuD9WG1V35UWc+PmhVYinOSDTUYi4qTgQA 3XVy+hgCAAA= Subject: Re: [AVTCORE] WG last call on draft-ietf-avtcore-avp-codecs-01 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Apr 2013 09:12:30 -0000 WG, This WG last call has concluded. There has been a number of reviewers sufficient for progressing this to publication request. First however the raised issues should be addressed. Tim, please prepare a new version addressing the issues and if any issues with resolving them please bring the matter to the WG mailing list for discussion. Thanks Magnus Westerlund WG chair On 2013-03-12 20:02, Magnus Westerlund wrote: > WG, > > This is to announce the start of a WG last call on: > > Update to Recommended Codecs for the RTP Profile for Audio and Video > Conferences with Minimal Control (RTP/AVP) to be published as a proposed > standard. > > Document can be retrieved here: > https://datatracker.ietf.org/doc/draft-ietf-avtcore-avp-codecs > > Please provide any feedback by the 31st of March. > > Regards > > Magnus Westerlund > WG chair > > > ---------------------------------------------------------------------- > Multimedia Technologies, Ericsson Research EAB/TVM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > Färögatan 6 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- > > _______________________________________________ > Audio/Video Transport Core Maintenance > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt > > -- Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From ron.even.tlv@gmail.com Tue Apr 2 02:29:24 2013 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1BD9B21F982B for ; Tue, 2 Apr 2013 02:29:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.396 X-Spam-Level: X-Spam-Status: No, score=-0.396 tagged_above=-999 required=5 tests=[AWL=-1.067, BAYES_00=-2.599, DOS_OUTLOOK_TO_MX=1, DYN_RDNS_SHORT_HELO_HTML=0.499, FH_HOST_EQ_D_D_D_D=0.765, HTML_MESSAGE=0.001, RCVD_IN_PBL=0.905, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jACRP3nN53+T for ; Tue, 2 Apr 2013 02:29:14 -0700 (PDT) Received: from mail-ea0-x22b.google.com (mail-ea0-x22b.google.com [IPv6:2a00:1450:4013:c01::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 87ED521F9829 for ; Tue, 2 Apr 2013 02:29:13 -0700 (PDT) Received: by mail-ea0-f171.google.com with SMTP id b15so109179eae.2 for ; Tue, 02 Apr 2013 02:29:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:from:to:subject:date:message-id:mime-version :content-type:x-mailer:thread-index:content-language; bh=mNGgPQ7ums8CUjRyLqJdsSsF8/8SUnE0B+tjzv/FE3s=; b=l52roECcNb2JMH3WDP4ZW4ByMW5+i2qeoJKoqzrEFgKagqlYsFBqaWQ0B/tlI1j0qM XEoyVCEGEKtCAa6bc9xtKSpqvNdGTPpBxTL/vNpAVdD222lqoJE99kOelp1vQExu9k5Y 6JcmsFMDQkRz5r9gqG9mNs8EPXivNXdDi0I55hmdi1Jnlc9zkW0vncszTNuaOtDbJP3e Tlbv4bIGFXz6yqKYEZLEblu6ccYDkYV8Bh0reYt6A0QJEkbA73uq3RwD36lgNV3nbMkg BvXfUhY2W60i3W+fowlyOd+N61xS6uydJ/5haY8OrEAPJjwPuV1ceYvKpA5Aibsd1YLK kqxA== X-Received: by 10.14.218.71 with SMTP id j47mr46833630eep.28.1364894952239; Tue, 02 Apr 2013 02:29:12 -0700 (PDT) Received: from RoniE (bzq-79-181-177-28.red.bezeqint.net. [79.181.177.28]) by mx.google.com with ESMTPS id bc1sm1328440eeb.11.2013.04.02.02.29.08 (version=TLSv1 cipher=RC4-SHA bits=128/128); Tue, 02 Apr 2013 02:29:11 -0700 (PDT) From: "Roni Even" To: Date: Tue, 2 Apr 2013 12:28:44 +0300 Message-ID: <06b701ce2f84$7ba91470$72fb3d50$@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_06B8_01CE2F9D.A0F7AC00" X-Mailer: Microsoft Outlook 14.0 thread-index: Ac4vhFVFc4b38pm2Tziw1afDGGvt8Q== Content-Language: en-us Subject: [AVTCORE] AVTcore IETF86 minutes X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Apr 2013 09:29:24 -0000 This is a multipart message in MIME format. ------=_NextPart_000_06B8_01CE2F9D.A0F7AC00 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, Here are the minutes of the AVTcore session. Please review Magnus and Roni Audio/Video Transport Core Maintenance (AVTCore) Working Group meeting notes =============================================================== CHAIRS: Magnus Westerlund magnus.westerlund@ericsson.com Roni Even roni.even@mail01.huawei.com Notes taker: Paul Kyzivat Jabber Scribe: Jonathan Lennox Tuesday, 12 March 2013 AVTCore Status Update - chairs The slides are in http://www.ietf.org/proceedings/86/slides/slides-86-avtcore-0.pdf. Draft-ietf-avt-srtp-not-mandatory-12 is still in IESG processing it is waiting for progress of draft-ietf-avtcore-rtp-security-options-02 which reviews the different RTP security options, the security options draft need reviews by security experts as well as others since it gives guidance for developers on how to choose the appropriate security mechanism. draft-ietf-avtcore-aria-srtp-01 is ready for WGLC but need more SRTP security expert review. The authors of draft-ietf-avtcore-srtp-aes-gcm-05 added a section on RTP header extension encryption and the document needs a second WGLC before going to publication. We are waiting for an update of draft-ietf-avtcore-srtp-ekt-00 and we can probably start a WGLC when it is submitted. draft-ietf-avtcore-6222bis-00 need an update and will be ready for WGLC. Update was submitted during the meeting and WGLC started after the meeting. draft-ietf-avtcore-avp-codecs-00 need an update and will be ready for WGLC. Update was submitted during the meeting and WGLC started after the meeting. draft-ietf-avtcore-multi-media-rtp-session-02 had some open issues mostly on multi-streams and not on multi media types. The view in the meeting after discussing draft-lennox-avtcore-rtp-multi-stream-02 is that multi-streams topic will be part of the Lennox draft so a revision of multi-media-rtp-session is needed. draft-ietf-avtcore-idms-09 will go to publication. Publication request was sent after the meeting. draft-westerlund-avtcore-multiplex-architecture-03 is an informational document. There was support in the meeting to have it as a WG document. Will verify on the list There was support to have draft-westerlund-avtcore-rtp-topologies-update-02 as a WG document and it will be verified on the list. RTP Considerations for Endpoints sending multiple media streams in draft-lennox-avtcore-rtp-multi-stream-02 was presented by Jonathan Lennox. The slides are in http://www.ietf.org/proceedings/86/slides/slides-86-avtcore-4.pdf. The draft addresses the issue with supporting multiple sources in an RTP session since current solution will usually support only one source per RTP session. The draft re-visits RFC 3550 to clarify behavior for multi-source endpoints and suggests that there may be a need to update RFC 3550 to change some RTCP timing rules. It proposes recommendations on optimizations for reception reports. This revision incorporates draft-wu-avtcore-multiplex-multisource-endpoint-01 and has new solution based on meeting between the authors of both drafts at IETF85. There were no issues with the author's proposals for how deal with the open issues. On the way forward there was some discussion about the content of this draft and draft-ietf-avtcore-multi-media-rtp-session-02. There was support to have this document as a WG document and it will be verified on the list. It seems like the draft will include clarifications of rtcp size and timing that are now in draft-ietf-avtcore-multi-media-rtp-session-02. RTP Congestion Control: Circuit Breakers for Unicast Sessions in draft-ietf-avtcore-rtp-circuit-breakers-02 presented by Colin Perkins. The slides are in http://www.ietf.org/proceedings/86/slides/slides-86-avtcore-1.pdf RTP circuit breakers provide an envelope within which congestion control can operate. Circuit breakers are conditions under which an RTP sender needs to stop transmitting media data to protect the network from excessive congestion. Colin presented the changes in this revision There was a comment from Jonathan Lennox that the draft need to take into account the reporting groups if they will be accepted as a solution and not only reduced size RTCP. Colin says he has no open issues. There are some experimental implementations that will be presented at the next meeting. There was a request for help with implementation experience. RTP Clock Source Signalling presented by Kevin Gross The slides are in http://www.ietf.org/proceedings/86/slides/slides-86-avtcore-2.pdf. The draft proposes a solution to explicitly signal clock information in RTP including timestamp reference clock and media clock. Magnus Westerlund and Bo Burman volunteered to review the O/A portion of the document. The document is ready for WGLC. RTP and Leap Second presented by Kevin Gross The slides are in http://www.ietf.org/proceedings/86/slides/slides-86-avtcore-3.pdf. This document discusses issues that arise when RTP sessions span Universal Coordinate Time (UTC) leap seconds. It updates RFC 3550 to describe how RTP senders and receivers should behave in the presence of leap seconds. Colin Perkins wondered if sending sender report would be better than reception report. Kevin Gross thought that might confuse some devices. Colin replied "maybe". Jonathan Lennox said even if you don't send anything during the event, could you still have a problem. Conclusion that this is a problem only if the two sides disagree whether there is a leap second. The draft is ready for WGLC but it will be after the clock source signaling draft. ------=_NextPart_000_06B8_01CE2F9D.A0F7AC00 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

Here are the = minutes of the AVTcore session. Please review

Magnus and Roni

 

 

 

Audio/Video = Transport Core Maintenance  (AVTCore) Working Group meeting = notes

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

<= p class=3DMsoNormal> 

CHAIRS:  Magnus = Westerlund       magnus.westerlund@ericsson= .com

         &= nbsp;      Roni = Even         roni.even@mail01.huawei.com

 

Notes taker: Paul Kyzivat

Jabber Scribe: Jonathan Lennox

 

Tuesday, 12 = March 2013

AVTCore Status = Update - = chairs           &= nbsp;     

The slides are in http://www.ietf.org/proceedings/86/slides/slides-86-avtcore-0.pdf.<= o:p>

Draft-ietf-avt-srtp-not-mandatory-12 = is still in IESG processing it is waiting for progress of = draft-ietf-avtcore-rtp-security-options-02 which reviews the different = RTP security options, the security options draft need reviews by = security experts as well as others since it gives = guidance for developers on how to choose the appropriate security = mechanism.

draft-ietf-avtcore-aria-srtp-01 is ready for WGLC but = need more SRTP security expert review.

The authors = of draft-ietf-avtcore-srtp-aes-gcm-05 added a section on RTP header = extension encryption and the document needs a second WGLC before going = to publication.

We are = waiting for an update of draft-ietf-avtcore-srtp-ekt-00 and we can = probably start a WGLC when it is submitted.

draft-ietf-avtcore-6222bis-00 need an update and will = be ready for WGLC. Update was submitted during the meeting and WGLC = started after the meeting.

draft-ietf-avtcore-avp-codecs-00 need an update and = will be ready for WGLC. Update was submitted during the meeting and WGLC = started after the meeting.

draft-ietf-avtcore-multi-media-rtp-session-02 had some = open issues mostly on multi-streams and not on multi media types. The = view in the meeting after discussing = draft-lennox-avtcore-rtp-multi-stream-02 is that multi-streams topic = will be part of the Lennox draft so a revision of = multi-media-rtp-session is needed.

draft-ietf-avtcore-idms-09 will go to publication. = Publication request was sent after the meeting.

 

 

draft-westerlund-avtcore-multiplex-architecture-03 is = an informational document. There was support in the meeting to have it = as a WG document. Will verify on the list

There was support to have = draft-westerlund-avtcore-rtp-topologies-update-02 as a WG document and = it will be verified on the list.

RTP Considerations for Endpoints sending multiple = media streams in draft-lennox-avtcore-rtp-multi-stream-02 was = presented by Jonathan Lennox.

The slides are in http://www.ietf.org/proceedings/86/slides/slides-86-avtcore-4.pdf. =

The draft addresses the issue with supporting multiple sources = in an RTP session since current solution will usually support only one = source per RTP session. The draft re-visits RFC 3550 to clarify = behavior for multi-source endpoints and suggests that there may be a = need to update RFC 3550 to change some RTCP timing rules.  It = proposes recommendations on optimizations for reception reports. =

This = revision incorporates draft-wu-avtcore-multiplex-multisource-endpoint-01 = and has new solution based on meeting between the authors of both drafts = at IETF85.

There were no issues with the = author’s proposals for how deal with the open issues. =

On the = way forward there was some discussion about the content of this draft = and draft-ietf-avtcore-multi-media-rtp-session-02. There was support to = have this document as a WG document and it will be verified on the = list.

It seems like the draft will include = clarifications of rtcp size and timing that are now in = draft-ietf-avtcore-multi-media-rtp-session-02.

 

RTP Congestion Control: Circuit Breakers for = Unicast Sessions in draft-ietf-avtcore-rtp-circuit-breakers-02 presented = by Colin Perkins.

The slides are = in http://www.ietf.org/proceedings/86/slides/slides-86-avtcore-1.pdf&n= bsp;

 

RTP circuit breakers provide an envelope within which = congestion control can operate. Circuit breakers are conditions under = which an RTP sender needs to stop transmitting media data to protect the = network from excessive congestion. Colin presented the changes in this = revision

There was a comment from = Jonathan Lennox that the draft need to take into account the reporting = groups if they will be accepted as a solution and not only reduced size = RTCP.

Colin says he has no open = issues.

There are some experimental = implementations that will be presented at the next meeting. There was a = request for help with implementation experience.

     

RTP Clock Source Signalling presented by Kevin = Gross

The slides are = in http://www.ietf.org/proceedings/86/slides/slides-86-avtcore-2.pdf.

The draft proposes a solution to explicitly signal = clock information in RTP including timestamp reference clock and media = clock.

Magnus Westerlund and Bo = Burman volunteered to review the O/A portion of the document. The = document is ready for WGLC.

 

RTP and Leap Second presented by Kevin = Gross

The slides are = in http://www.ietf.org/proceedings/86/slides/slides-86-avtcore-3.pdf.

This document discusses issues that arise when RTP sessions = span Universal Coordinate Time (UTC) leap seconds.  It updates RFC = 3550 to describe how RTP senders and receivers should behave in the = presence of leap seconds.

Colin Perkins wondered if sending sender = report would be better than reception report. Kevin Gross thought that = might confuse some devices. Colin replied “maybe”. Jonathan = Lennox said even if you don’t send anything during the event, = could you still have a problem. Conclusion that this is a problem only = if the two sides disagree whether there is a leap = second.

The draft is ready for WGLC but it will be = after the clock source signaling draft.

 

 

------=_NextPart_000_06B8_01CE2F9D.A0F7AC00-- From tterribe@xiph.org Tue Apr 2 05:11:48 2013 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 48D7921F9849 for ; Tue, 2 Apr 2013 05:11:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.677 X-Spam-Level: X-Spam-Status: No, score=-2.677 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_COM=0.311, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QKT5kp4s3May for ; Tue, 2 Apr 2013 05:11:47 -0700 (PDT) Received: from smtp.mozilla.org (mx1.corp.phx1.mozilla.com [63.245.216.69]) by ietfa.amsl.com (Postfix) with ESMTP id 381D821F9800 for ; Tue, 2 Apr 2013 05:11:47 -0700 (PDT) Received: from [172.17.0.5] (50-78-100-113-static.hfc.comcastbusiness.net [50.78.100.113]) (Authenticated sender: tterriberry@mozilla.com) by mx1.mail.corp.phx1.mozilla.com (Postfix) with ESMTPSA id 80FD3F213D; Tue, 2 Apr 2013 05:11:46 -0700 (PDT) Message-ID: <515ACB01.7060106@xiph.org> Date: Tue, 02 Apr 2013 05:11:45 -0700 From: "Timothy B. Terriberry" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:13.0) Gecko/20120625 SeaMonkey/2.10.1 MIME-Version: 1.0 To: Magnus Westerlund References: <513F7BDD.8010700@ericsson.com> <515AA0FA.5010807@ericsson.com> In-Reply-To: <515AA0FA.5010807@ericsson.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Cc: avt@ietf.org, draft-ietf-avtcore-avp-codecs@tools.ietf.org Subject: Re: [AVTCORE] WG last call on draft-ietf-avtcore-avp-codecs-01 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 02 Apr 2013 12:11:48 -0000 Magnus Westerlund wrote: > Tim, please prepare a new version addressing the issues and if any > issues with resolving them please bring the matter to the WG mailing > list for discussion. Thank you Magnus, will do. From magnus.westerlund@ericsson.com Wed Apr 3 07:55:29 2013 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7D61121F8E6A; Wed, 3 Apr 2013 07:55:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.249 X-Spam-Level: X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uK80SsQbXLeP; Wed, 3 Apr 2013 07:55:28 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id A83FA21F8E58; Wed, 3 Apr 2013 07:55:27 -0700 (PDT) X-AuditID: c1b4fb30-b7f0d6d000007e61-74-515c42de5781 Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id E8.E6.32353.ED24C515; Wed, 3 Apr 2013 16:55:26 +0200 (CEST) Received: from [127.0.0.1] (153.88.115.8) by esessmw0184.eemea.ericsson.se (153.88.115.82) with Microsoft SMTP Server id 8.3.279.1; Wed, 3 Apr 2013 16:55:26 +0200 Message-ID: <515C42DD.1030902@ericsson.com> Date: Wed, 3 Apr 2013 16:55:25 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: avt@ietf.org, "payload@ietf.org" References: <20130219074201.79BD0B1E002@rfc-editor.org> In-Reply-To: <20130219074201.79BD0B1E002@rfc-editor.org> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrNLMWRmVeSWpSXmKPExsUyM+Jvre49p5hAg8srdS1e9qxkt3j1+gqr xdPGs4wWly6eZbKY2mdrcemfisWF9b9YHNg9Wp/tZfX4eusgk8fOWXfZPVqOvGX1WLLkJ5PH 5I2zWALYorhsUlJzMstSi/TtErgyZp6dy15wUabizlypBsYe8S5GTg4JAROJU3tusELYYhIX 7q1n62Lk4hASOMUocXblFihnGaNEz/Xb7CBVvALaEvt7zjF1MXJwsAioSNycFggSZhOwkLj5 o5ENxBYVCJb4+eoMC0S5oMTJmU/AbBEBc4lfR5czgsxkFtjMKHHreDNYg7CAo8TjIw8ZQWwh oKL5736BXcQJNPRDxxI2iOskJba8aAe7gVlAT2LK1RZGCFteonnrbGaIXm2JhqYO1gmMQrOQ 7J6FpGUWkpYFjMyrGNlzEzNz0svNNzECI+Dglt8GOxg33Rc7xCjNwaIkzhvueiFASCA9sSQ1 OzW1ILUovqg0J7X4ECMTBycwDDdJR3POzWQJ6s0+F1D1f3f4PNN9ddyK4qvWVC/exnT20Ic2 nwK9/4GykybPeBYSWbF01YvDGhPNy+Q78sx797A9PsvOP1NiPpPXpNigM+6O3u/seYJl1itd mrT3Mn9iX14ok27aI7l/Rc9OK8aeCH3yMIQ3YP5mLT2GA7V3J5+beYFJquxrihJLcUaioRZz UXEiAF3dw71OAgAA Cc: schulzrinne@cs.columbia.edu, even.roni@huawei.com, tom.taylor.stds@gmail.com Subject: Re: [AVTCORE] [Technical Errata Reported] RFC4733 (3489) X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Apr 2013 14:55:29 -0000 AVTCORE and Payload WG, There appear to exist an interoperability issue around the the need to use the same timestamp rate for the DTMF and the audio. Thus, I think we should serioulsy consider to approve this erratum. And if the text is not correct, propose a better text. I personally believe the proposal is significantly clearer than the old text and also reflect what must have been intended. This issues a 2-week last call on input on this erratum. After the 17th of April I will issue a final recommendation on this erratum. For previous discussion that resulted in this updated erratum proposal see this AVTCORE mailing list discussion: http://www.ietf.org/mail-archive/web/avt/current/msg15669.html Cheers Magnus Westerlund AVTCORE WG chair On 2013-02-19 08:42, RFC Errata System wrote: > > The following errata report has been submitted for RFC4733, > "RTP Payload for DTMF Digits, Telephony Tones, and Telephony Signals". > > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=4733&eid=3489 > > -------------------------------------- > Type: Technical > Reported by: Xavier Marjou > > Section: 2.1 > > Original Text > ------------- > Named telephone events are carried as part of the audio stream and MUST use the same sequence number and timestamp base as the regular audio channel to simplify the generation of audio waveforms at a gateway. > > Corrected Text > -------------- > Named telephone events are carried as part of the audio stream and if they use the same SSRC (therefore the same timing and sequence number space), they MUST use the same timestamp clock rate as the regular audio channel. > > Notes > ----- > RFC4733 was written in a way to avoid the multiple clock-rate problem by mandating the use of the same SSRC for DTMF and audio. However it's not explicitly written, which brings an ambiguity. It was commented that RFC4733 needs to be updated. (c.f. http://tools.ietf.org/wg/avtext/minutes?item=minutes-85-avtext.html). This errata obsoletes the previous proposed errata (ID: 3451). > > Instructions: > ------------- > This errata is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party (IESG) > can log in to change the status and edit the report, if necessary. > > -------------------------------------- > RFC4733 (draft-ietf-avt-rfc2833bis-15) > -------------------------------------- > Title : RTP Payload for DTMF Digits, Telephony Tones, and Telephony Signals > Publication Date : December 2006 > Author(s) : H. Schulzrinne, T. Taylor > Category : PROPOSED STANDARD > Source : Audio/Video Transport > Area : Real-time Applications and Infrastructure > Stream : IETF > Verifying Party : IESG > _______________________________________________ > Audio/Video Transport Core Maintenance > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt > > -- Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From gonzalo.camarillo@ericsson.com Wed Apr 3 03:03:46 2013 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8826121F85B0 for ; Wed, 3 Apr 2013 03:03:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.249 X-Spam-Level: X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id LkQN6gPYxkVU for ; Wed, 3 Apr 2013 03:03:43 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 2292521F8506 for ; Wed, 3 Apr 2013 03:03:42 -0700 (PDT) X-AuditID: c1b4fb25-b7f366d000004d10-9b-515bfe7e894c Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 1E.92.19728.E7EFB515; Wed, 3 Apr 2013 12:03:42 +0200 (CEST) Received: from [131.160.36.146] (153.88.115.8) by esessmw0247.eemea.ericsson.se (153.88.115.94) with Microsoft SMTP Server id 8.3.279.1; Wed, 3 Apr 2013 12:03:41 +0200 Message-ID: <515BFE7C.5050105@ericsson.com> Date: Wed, 3 Apr 2013 13:03:40 +0300 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: Karl Norrman References: <20121128143149.E05F3B1E004@rfc-editor.org> <33E51946CDE71249AF9D86CE4D8966B40213AC@ESESSMB203.ericsson.se> <514C7827.3030503@nostrum.com> <33E51946CDE71249AF9D86CE4D8966B4121F17BE@ESESSMB203.ericsson.se> In-Reply-To: <33E51946CDE71249AF9D86CE4D8966B4121F17BE@ESESSMB203.ericsson.se> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrBLMWRmVeSWpSXmKPExsUyM+JvrW7dv+hAg84v/BYve1ayW7x6fYXV 4mnjWUaLawf2s1h8mbKcxeLqqj/sFtfmNLJZTO2zdeDwaH22l9Vjyu+NrB6LN+1n82g58pbV Y8mSn0wekzfOYvGYtfMJSwB7FJdNSmpOZllqkb5dAlfG5aZepoIDchULbnxjamC8KdHFyMkh IWAicf7UFXYIW0ziwr31bF2MXBxCAqcYJX7vvcUGkhASWM0o8WejA4jNK6At0XVgLlgDi4CK xL2nW5lBbDYBC4ktt+6zgNiiAlESezdcZoaoF5Q4OfMJWFxEQEfi9NwXLCALmAU+M0u8efIL LCEsYC6x8uEDZojNNxglHp17BNbNKeAn8X9TFxPEeZISi6Z1gjUwC+hJTLnawghhy0s0b53N DHGptsTyZy0sExiFZiFZPgtJyywkLQsYmVcxsucmZuaklxttYgTGxsEtv1V3MN45J3KIUZqD RUmcN9z1QoCQQHpiSWp2ampBalF8UWlOavEhRiYOTqkGRhO7nqWLp4ssKYwN2nCu7P8Zw19e sn3OfE09Pe5KK0QtzCx11y6vvqlko5RlnFp1RfzF/W2PZ56tjNpntuLWua/PD3yJa1951ipn /Tmf/b2vnF/MDGjnEZHLmSB5or1/sZfsutCNxYv3TYhk0MzePZ1pnTzXDs0qYbn1S/78kvwk N+W5h275SiWW4oxEQy3mouJEAOYILOJbAgAA X-Mailman-Approved-At: Wed, 03 Apr 2013 08:13:29 -0700 Cc: "avt@ietf.org" , "even.roni@huawei.com" , "elisabetta.carrara@ericsson.com" , "mbaugher@cisco.com" , =?ISO-8859-1?Q?Mats_N=E4slund?= , "matthias.schertler@gmx.net" Subject: Re: [AVTCORE] [Technical Errata Reported] RFC3711 (3420) X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Apr 2013 10:03:46 -0000 Done. Gonzalo On 22/03/2013 7:45 PM, Karl Norrman wrote: > Hello! > > OK, putting it on hold for document update is fine with me. > > BR > Karl > >> -----Original Message----- >> From: Robert Sparks [mailto:rjsparks@nostrum.com] >> Sent: den 22 mars 2013 16:27 >> To: Karl Norrman >> Cc: mbaugher@cisco.com; elisabetta.carrara@ericsson.com; >> mcgrew@cisco.com; Mats Näslund; Gonzalo Camarillo; keith.drage@alcatel- >> lucent.com; even.roni@huawei.com; matthias.schertler@gmx.net; >> avt@ietf.org; Gonzalo Camarillo; Richard Barnes >> Subject: Re: [Technical Errata Reported] RFC3711 (3420) >> >> Using the criteria at >> I recommend >> putting this into Hold For Document Update. >> >> ( I could make an argument for Reject, given the text in 3550 is very clear, but >> a working group can make that decision if 3771 is ever revised). >> >> On 11/28/12 9:13 AM, Karl Norrman wrote: >>> Hello! >>> >>> I always considered the padding count to be part of the padding itself and >> hence it would be included in the encrypted portion. However, the >> proposed errata below makes the text more explicit on this point. So, if it >> can avoid some interoperability problems I'm all for accepting it. >>> >>> BR >>> Karl >>> >>> >>>> -----Original Message----- >>>> From: RFC Errata System [mailto:rfc-editor@rfc-editor.org] >>>> Sent: den 28 november 2012 15:32 >>>> To: mbaugher@cisco.com; elisabetta.carrara@ericsson.com; >>>> mcgrew@cisco.com; Mats Näslund; Karl Norrman; Gonzalo Camarillo; >>>> rjsparks@nostrum.com; keith.drage@alcatel-lucent.com; >>>> even.roni@huawei.com >>>> Cc: matthias.schertler@gmx.net; avt@ietf.org; >>>> rfc-editor@rfc-editor.org >>>> Subject: [Technical Errata Reported] RFC3711 (3420) >>>> >>>> >>>> The following errata report has been submitted for RFC3711, "The >>>> Secure Real-time Transport Protocol (SRTP)". >>>> >>>> -------------------------------------- >>>> You may review the report below and at: >>>> http://www.rfc-editor.org/errata_search.php?rfc=3711&eid=3420 >>>> >>>> -------------------------------------- >>>> Type: Technical >>>> Reported by: Matthias Schertler >>>> >>>> Section: 3.1. >>>> >>>> Original Text >>>> ------------- >>>> The "Encrypted Portion" of an SRTP packet consists of the >>>> encryption of the RTP payload (including RTP padding when >>>> present) of the equivalent RTP packet. >>>> >>>> Corrected Text >>>> -------------- >>>> The "Encrypted Portion" of an SRTP packet consists of the >>>> encryption of the RTP payload (including RTP padding and >>>> RTP pad count when present) of the equivalent RTP packet. >>>> >>>> Notes >>>> ----- >>>> In Figure 1 "RTP padding" and "RTP pad count" are different things. >>>> The text should use the same terminology in order to make clear that >>>> the padding count is encrypted. >>>> >>>> Instructions: >>>> ------------- >>>> This errata is currently posted as "Reported". If necessary, please >>>> use "Reply All" to discuss whether it should be verified or rejected. >>>> When a decision is reached, the verifying party (IESG) can log in to >>>> change the status and edit the report, if necessary. >>>> >>>> -------------------------------------- >>>> RFC3711 (draft-ietf-avt-srtp-09) >>>> -------------------------------------- >>>> Title : The Secure Real-time Transport Protocol (SRTP) >>>> Publication Date : March 2004 >>>> Author(s) : M. Baugher, D. McGrew, M. Naslund, E. >>>> Carrara, K. Norrman >>>> Category : PROPOSED STANDARD >>>> Source : Audio/Video Transport >>>> Area : Real-time Applications and Infrastructure >>>> Stream : IETF >>>> Verifying Party : IESG > > From petithug@acm.org Wed Apr 3 11:23:43 2013 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 15E7A21F8A68; Wed, 3 Apr 2013 11:23:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.6 X-Spam-Level: X-Spam-Status: No, score=-102.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id jBFoIi9v5XVV; Wed, 3 Apr 2013 11:23:42 -0700 (PDT) Received: from implementers.org (implementers.org [IPv6:2604:3400:dc1:41:216:3eff:fe5b:8240]) by ietfa.amsl.com (Postfix) with ESMTP id 205E021F89E1; Wed, 3 Apr 2013 11:23:42 -0700 (PDT) Received: from [IPv6:2601:9:4bc0:1f:25ac:5e55:3fb8:ac4f] (unknown [IPv6:2601:9:4bc0:1f:25ac:5e55:3fb8:ac4f]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (Client CN "Marc Petit-Huguenin", Issuer "implementers.org" (verified OK)) by implementers.org (Postfix) with ESMTPS id 1DDBA202D8; Wed, 3 Apr 2013 20:23:40 +0200 (CEST) Message-ID: <515C73AA.8080007@acm.org> Date: Wed, 03 Apr 2013 11:23:38 -0700 From: Marc Petit-Huguenin User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.12) Gecko/20130116 Icedove/10.0.12 MIME-Version: 1.0 To: Magnus Westerlund References: <20130219074201.79BD0B1E002@rfc-editor.org> <515C42DD.1030902@ericsson.com> In-Reply-To: <515C42DD.1030902@ericsson.com> X-Enigmail-Version: 1.4.1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Cc: schulzrinne@cs.columbia.edu, even.roni@huawei.com, avt@ietf.org, "payload@ietf.org" , tom.taylor.stds@gmail.com Subject: Re: [AVTCORE] [Technical Errata Reported] RFC4733 (3489) X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 03 Apr 2013 18:23:43 -0000 -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 04/03/2013 07:55 AM, Magnus Westerlund wrote: > AVTCORE and Payload WG, > > There appear to exist an interoperability issue around the the need to use > the same timestamp rate for the DTMF and the audio. Thus, I think we should > serioulsy consider to approve this erratum. And if the text is not correct, > propose a better text. > > I personally believe the proposal is significantly clearer than the old > text and also reflect what must have been intended. > > This issues a 2-week last call on input on this erratum. After the 17th of > April I will issue a final recommendation on this erratum. > I support this text. BTW I would like to applaud the way this erratum was handled. i.e. discussed and refined first in the WG, as it should be[1]. Thanks. [1] http://www.rfc-editor.org/pipermail/rfc-interest/2012-August/004839.html > > For previous discussion that resulted in this updated erratum proposal see > this AVTCORE mailing list discussion: > http://www.ietf.org/mail-archive/web/avt/current/msg15669.html > > Cheers > > Magnus Westerlund AVTCORE WG chair > > On 2013-02-19 08:42, RFC Errata System wrote: >> >> The following errata report has been submitted for RFC4733, "RTP Payload >> for DTMF Digits, Telephony Tones, and Telephony Signals". >> >> -------------------------------------- You may review the report below >> and at: http://www.rfc-editor.org/errata_search.php?rfc=4733&eid=3489 >> >> -------------------------------------- Type: Technical Reported by: >> Xavier Marjou >> >> Section: 2.1 >> >> Original Text ------------- Named telephone events are carried as part of >> the audio stream and MUST use the same sequence number and timestamp base >> as the regular audio channel to simplify the generation of audio >> waveforms at a gateway. >> >> Corrected Text -------------- Named telephone events are carried as part >> of the audio stream and if they use the same SSRC (therefore the same >> timing and sequence number space), they MUST use the same timestamp clock >> rate as the regular audio channel. >> >> Notes ----- RFC4733 was written in a way to avoid the multiple clock-rate >> problem by mandating the use of the same SSRC for DTMF and audio. However >> it's not explicitly written, which brings an ambiguity. It was commented >> that RFC4733 needs to be updated. (c.f. >> http://tools.ietf.org/wg/avtext/minutes?item=minutes-85-avtext.html). >> This errata obsoletes the previous proposed errata (ID: 3451). >> >> Instructions: ------------- This errata is currently posted as >> "Reported". If necessary, please use "Reply All" to discuss whether it >> should be verified or rejected. When a decision is reached, the verifying >> party (IESG) can log in to change the status and edit the report, if >> necessary. >> >> -------------------------------------- RFC4733 >> (draft-ietf-avt-rfc2833bis-15) -------------------------------------- >> Title : RTP Payload for DTMF Digits, Telephony Tones, and >> Telephony Signals Publication Date : December 2006 Author(s) >> : H. Schulzrinne, T. Taylor Category : PROPOSED STANDARD >> Source : Audio/Video Transport Area : >> Real-time Applications and Infrastructure Stream : IETF >> Verifying Party : IESG - -- Marc Petit-Huguenin Email: marc@petit-huguenin.org Blog: http://blog.marc.petit-huguenin.org Profile: http://www.linkedin.com/in/petithug -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.12 (GNU/Linux) iQIcBAEBCAAGBQJRXHOnAAoJECnERZXWan7E0TkQANzx6Ls7FTHJYIz4ijt3MPlM 0lZnq6tOgdaDGS4K9ol4Bp1Qf8EbB+tdzFTTOTpUWSO1Xx+ZmdLsdZIlxPcyFs36 Ylh9gxo9E/tVEiYQwrP7j/qsrIXMC5TQgMeQ7wqEVsRjo//jmo+1oE9O72QA2NL/ JJzZFkXdxpHIgkot6ILMVNMZ5IGAOKqqafKkSjLDnidmkma8CqnJal7SjaqsoYmO Kxabvbf+Rrh5iZnZa38eOYPKJc9FyxmjknbxPLrS+uM6Z8VZ5ogIOS0x1FUKXrMq /HYYV4TNbduUlh571lwYA+u85be/jRsLxl2XDWEIBHrtzp+DWo8DkZgg/7kOE/js XtU00+1qeu/Z3HljkjohkLyPBxqTu8L1PdVsN8N5LEdO4sqprGZD5aKf25LZOGF2 rhU0o/xCSFTW6W8hkycS+wtoIzTH7g2bTmajOW2/gfRU+VYosBaDeOqZIvWp9qzj Db6JRQlQ01rSFtvajL+LB/x1ykkaHmcuK8RHuPqemddTZH/wMGBCYKH86ErzI7AV BE7xArnNGBSGV6KEIXszyyaiJMAHmT8pliwr3/hga9LDqcfBwZS/flJRPWpEXhD/ 9YVbqnTBX3om2YyCJnxRhOvuj4S3kTsZxdmALvSnwpks+tsGtf7u9gIcGQfN8pKP kEZZP2g13bMxSkhWcbeZ =MkAX -----END PGP SIGNATURE----- From magnus.westerlund@ericsson.com Thu Apr 4 06:12:27 2013 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 05DDE21F84E9 for ; Thu, 4 Apr 2013 06:12:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.329 X-Spam-Level: X-Spam-Status: No, score=-105.329 tagged_above=-999 required=5 tests=[AWL=-0.920, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_73=0.6, RCVD_IN_DNSWL_MED=-4, SARE_LWSHORTT=1.24, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id R+xxsuIRJBHU for ; Thu, 4 Apr 2013 06:12:25 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 4053021F84E3 for ; Thu, 4 Apr 2013 06:12:25 -0700 (PDT) X-AuditID: c1b4fb25-b7f366d000004d10-3d-515d7c38cd66 Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id B2.1F.19728.83C7D515; Thu, 4 Apr 2013 15:12:24 +0200 (CEST) Received: from [127.0.0.1] (153.88.115.8) by esessmw0191.eemea.ericsson.se (153.88.115.85) with Microsoft SMTP Server id 8.3.279.1; Thu, 4 Apr 2013 15:12:19 +0200 Message-ID: <515D7C32.3000602@ericsson.com> Date: Thu, 4 Apr 2013 15:12:18 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: "Correll, Christian" References: <0EA3AE418270B64C930B97CECB6E78180126883D@MCHP04MSX.global-ad.net> In-Reply-To: <0EA3AE418270B64C930B97CECB6E78180126883D@MCHP04MSX.global-ad.net> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupnluLIzCtJLcpLzFFi42KZGfG3VteiJjbQ4OYjKYuXPSvZLRpXT2R1 YPJYsuQnk8eN2++ZA5iiuGxSUnMyy1KL9O0SuDKuPX3NVtASUfHl+2OmBsalbl2MnBwSAiYS s64uZISwxSQu3FvP1sXIxSEkcIpR4u20s0wQzjJGiYO9e5hBqngFtCU+T+5mArFZBFQkFk/d DWazCVhI3PzRyAZiiwoES/x8dYYFol5Q4uTMJ2C2iICzxOe/y4HmcHAwCyhKTGqXBAkLC3hL HNz+E6xVSMBP4tO+aWAlnAL+EutfO0HcJimx5UU7O4jNLKAnMeVqCyOELS/RvHU2M0SrtkRD UwfrBEahWUgWz0LSMgtJywJG5lWM7LmJmTnp5UabGIGBenDLb9UdjHfOiRxilOZgURLnDXe9 ECAkkJ5YkpqdmlqQWhRfVJqTWnyIkYmDU6qB0b7x64vSuIdrkhNOeDvsW3dr0y5Wr4U/5syK 2zR94m2vXy2PvgU2sGtcyN5emd5t6nA2YvmxA+VXWg52H5uiJBBknbb756OP4qX3vk6wdRaX Z66S1D7JszWS/dTO2Umu0jWODZnaUYklKy+u7zduFGlr/3Tojqcwt15H0q1nH0x4N+xsNF19 TYmlOCPRUIu5qDgRAB03F04iAgAA Cc: "avt@ietf.org" Subject: Re: [AVTCORE] Review of draft-ietf-avtcore-rtp-security-options-01 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 04 Apr 2013 13:12:27 -0000 Hi Christian, Sorry for being so late in responding to your email with comments. They are very good comments and we are making a number of changes to the draft to address these. A new version should be available soon. See inline for the proposals when suitable. I would appreciate feedback on the proposed changes. The last issue has an open question which I require WG input on. On 2012-12-12 13:59, Correll, Christian wrote: > Hi, > > I reviewed the RTP security options document and I have following comments. > > > 1) Section 3.1. Secure RTP > > The Secure RTP (SRTP) protocol [RFC3711] is one of the most commonly > used mechanisms to provide confidentiality, integrity protection and > source authentication for RTP. > > Another security property that is explicitly mentioned in RFC 3711 is > replay protection. Added > > > 2) Section 3.1.1. Key Management for SRTP: DTLS-SRTP > > A Datagram Transport Layer Security extension exists for establishing > SRTP keys [RFC5763][RFC5764]. This extension provides secure key- > exchange between two peers, including perfect forward secrecy and > enabling binding strong identity verification to an end-point. > > I wonder if the security properties of DTLS-SRTP actually depend on the > ciphersuite the endpoints negotiate during the DTLS handshake.For > example, when client and server agree on the ciphersuite > TLS_DHE_RSA_WITH_AES_128_CBC_SHA they perform a Diffie-Hellman key > agreement; in this case DTLS-SRTP provides PFS.Whereas when they agree > on TLS_RSA_WITH_AES_128_CBC_SHA the client encrypts a shared secret with > the server's public key; and in that case PFS is not provided.To meet > the security goals, the ciphersuites that the client can offer and the > server can accept need carefully be selected. You are correct. I changed the quoted sentence to say that it enables PFS and then added this new paragraph: The actual security properties of an established SRTP session using DTLS will depend on the cipher suits offered and used. For example some provides perfect forward secrecy (PFS), while other do not. When using DTLS the application designer needs to select which cipher suits that DTLS-SRTP can offer and accept so that the desired security properties are achieved. > > > 3) Section 3.1.2. Key Management for SRTP: MIKEY > > Pre-Shared Key mode: > > This system is the most efficient from the perspective of having > small messages and processing demands. > > The downside is scalability. Usually, the effort for the provisioning of > pre-shared keys is only manageable, if the number of endpoints is small. Added a sentence on this. Uses a pre-shared secret for symmetric key crypto used to secure a keying message carrying the already generated TGK. This system is the most efficient from the perspective of having small messages and processing demands. The downside is scalability, where usually the effort for the provisioning of pre-shared keys is only manageable, if the number of endpoints is small. > > > IBAKE mode: > > If provides both perfect forward and backwards secrecy. > > I think the term perfect backward secrecy needs more clarification. In > what exactly is it different from forward secrecy?For example, RFC 4949 > gives a definition of perfect forward secrecy and briefly discusses > issues where experts disagree about it.Backward secrecy is mentioned in > that context as one of the disputed issues (it seems to be a synonym for > forward secrecy), but not precisely defined.I am not aware of a clear > definition of this term. Thanks for the pointer to the Internet Security Glossary. I added this to an introduction section as a useful reference to learn about terms the reader may not understand. Regardin IBAKE, I am not a security expert and I don't understand the difference here. Until someone can provide a clear short explanation I will indicate that this is unclear and move on. IBAKE: uses a key management services (KMS) but with lower demand on the KMS. Claims to provides both perfect forward and backwards secrecy, the exact meaning is unclear (See Perfect Forward Secrecy in [RFC4949]). > > > SAKKE mode: > > Requires additional infrastructure. A key management service (KMS) must > create the secret keys associated with the identities (resp. public keys). SAKKE: [RFC6509] provides Sakai-Kasahara Key Encryption in MIKEY. Based on Identity based Public Key Cryptography and a KMS infrastructure to establish a shared secret value and certificate less signatures to provide source authentication. It features include simplex transmission, scalability, low-latency call set-up, and support for secure deferred delivery. I think what is relevant here is to understand that this requires infrastructure, so I added that "keyword" also to the IBAKE. > > > 4) Section 3.1.3. Key Management for SRTP: Security Descriptions > > Since keys are transported in plain text in SDP, they can easily be > intercepted unless the SDP carrying protocol provides strong end-to- > end confidentiality and authentication guarantees. This is not the > common use of security descriptions with SIP, where instead hop by > hop security is provided between signalling nodes using TLS. This > still leaves the keying material sensitive to capture by the > traversed signalling nodes. Thus in most cases the security > properties of security description are weak. > > I agree. The usage of security descriptions usually requires additional > security measures, e.g. the signalling nodes be trusted and protected by > strict access control. An example where these conditions are often given > is an enterprise environment.Usage of security descriptions requires > careful design in order to ensure that the security goals can be met. > Took two of your sentences to add to this paragraph: Since keys are transported in plain text in SDP, they can easily be intercepted unless the SDP carrying protocol provides strong end-to-end confidentiality and authentication guarantees. This is not the common use of security descriptions with SIP, where instead hop by hop security is provided between signalling nodes using TLS. This still leaves the keying material sensitive to capture by the traversed signalling nodes. Thus in most cases the security properties of security descriptions are weak. The usage of security descriptions usually requires additional security measures, e.g. the signalling nodes be trusted and protected by strict access control. Usage of security descriptions requires careful design in order to ensure that the security goals can be met. > > 5) Section 3.1.4. Key Management for SRTP: EKT > > Encrypted Key Transport (EKT) [I-D.ietf-avtcore-srtp-ekt] is an SRTP > extension that enables group keying despite using a keying mechanism > that can't support group keys, like DTLS-SRTP. > > A second use case also described in the EKT draft is interoperability > between different key management systems. Correct, and the intention with the last sentences in the first paragraph was to elude to this when discussing gateways. However, I guess being explicit is better so I added a sentence for this: Encrypted Key Transport (EKT) [I-D.ietf-avtcore-srtp-ekt] is an SRTP extension that enables group keying despite using a keying mechanism that can't support group keys, like DTLS-SRTP. It is designed for centralized conferencing, but can also be used in sessions where an end-points connect to a conference bridge or a gateway, and need to be provisioned with the keys each participant on the bridge or gateway uses to avoid decryption encryption cycles on the bridge or gateway. This can enable interworking between DTLS-SRTP and for example security descritptions or other keying systems where either part can set the key. > > > 6) Section 4.1.3. Source Authentication > > Binding the Source: > > For example, consider a point to point communication system that > use DTLS-SRTP using self-signed certificates for key-management, > and SIP for signalling. In such a system the end-points for the > DTLS-SRTP handshake have securely established keys that are not > visible to the signalling nodes. However, as the certificates > used by DTLS is not bound to any PKI they can't be verified. > Instead, hashes over the certificate are sent over the signalling > path. If the signalling can be trusted not to collaborate on > performaning a man in the middle attack by modifying the hashes, > then the end-points can verify that they have reached the peer > they are doing signalling with. > > A second example is a key management method that transports the key > exchange data in the signalling plane, e.g. MIKEY or security > descriptions.Such a method ties the key exchange directly to the > signalling. There are no additinal steps required to ensure that the > "signalling peer" is the same as the "key exchange peer". Added a new paragraph under this binding: Systems where the key-exchange are done using the signalling systems, such as Security Descriptions [RFC4568] or MIKEY embedded in SDP [RFC4567], enables an direct binding between signalling and key-exchange. Independent of DTLS-SRTP or MIKEY in SDP the actual security depends on the trust one can place in the signalling system to correctly associate the peer's identity with the key-exchange. > > > 7) Section 4.1.4. Identity > > ..., having an identity provider system can benefit the applications > by enabling them to do strong assertion between identity and the > actual media source. > > I wonder if the draft should briefly address how identity verification > can be achieved.The draft states several times that source > authentication is possible using verifiable identities.I think, giving > examples for the most widely used systems for asserting and verifying an > identity makes reading easier. I think you are right, but you are pushing my knowledge boundaries here. So what are needed here? The main methods I can think of are: 1. PKI based, where one have and use certificates to prove ones identity. 2. We have IdP based systems when have a third party Identity provider and the user proves their identity to the IdP, which then asserts it towards the authenticating party. Or provides short term credentials that the user can use to prove their identity. Assistance here would be appreciated. Cheers Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From ron.even.tlv@gmail.com Tue Apr 9 00:33:36 2013 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 92D7F21F9132 for ; Tue, 9 Apr 2013 00:33:36 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.124 X-Spam-Level: X-Spam-Status: No, score=-0.124 tagged_above=-999 required=5 tests=[AWL=-0.795, BAYES_00=-2.599, DOS_OUTLOOK_TO_MX=1, DYN_RDNS_SHORT_HELO_HTML=0.499, FH_HOST_EQ_D_D_D_D=0.765, HTML_MESSAGE=0.001, RCVD_IN_PBL=0.905, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id IDsaR4CXIJM0 for ; Tue, 9 Apr 2013 00:33:36 -0700 (PDT) Received: from mail-ea0-x22f.google.com (mail-ea0-x22f.google.com [IPv6:2a00:1450:4013:c01::22f]) by ietfa.amsl.com (Postfix) with ESMTP id C938E21F907E for ; Tue, 9 Apr 2013 00:33:35 -0700 (PDT) Received: by mail-ea0-f175.google.com with SMTP id r16so2633702ead.20 for ; Tue, 09 Apr 2013 00:33:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:from:to:subject:date:message-id:mime-version :content-type:x-mailer:thread-index:content-language; bh=CS5pBObAYvc6TLXcxTTYtF6VqjJce+9gkphEJvqeQxg=; b=Ht4Jt3WxBm6mIzlDnFeq2DyBU8ZD68VNmZjly3RPtuIUIugbdfI2JkVLCiri04mMHK RyvGm4PdWNM0z3OadqmLugmGgvgAtWoLDl02QzBMXJoAGnaQlvky5kfBKU0vsMcbeP/9 XiYumgmxRpFTL/z2w6e7jCyMcAH+MwBAYLSja4NYyIHnCfDABEKV5wPGuH0wIhDnyPly OXlCus55fg9qVhCPSdG9BFmp85K4jiFgaCb3fMz7Y7fI6julYP/Myy7S18+cIxhkmJEL kz9NgexMUI3ULm5L9TLgJ82ISwQkC+c0VMZN3ufFHz5gpR+fDWZ59nATJlShkzeFP6fo p3Qg== X-Received: by 10.14.39.5 with SMTP id c5mr48409682eeb.27.1365492814913; Tue, 09 Apr 2013 00:33:34 -0700 (PDT) Received: from RoniE (bzq-79-181-177-28.red.bezeqint.net. [79.181.177.28]) by mx.google.com with ESMTPS id cd3sm26458298eeb.6.2013.04.09.00.33.32 (version=TLSv1 cipher=RC4-SHA bits=128/128); Tue, 09 Apr 2013 00:33:34 -0700 (PDT) From: "Roni Even" To: Date: Tue, 9 Apr 2013 10:33:08 +0300 Message-ID: <02f301ce34f4$7cd1c570$76755050$@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_02F4_01CE350D.A21F4B90" X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac409HsCGNKUukWhQjK9UmRv1fp4dQ== Content-Language: en-us Subject: [AVTCORE] draft-westerlund-avtcore-multiplex-architecture to a working group document X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Apr 2013 07:33:36 -0000 This is a multipart message in MIME format. ------=_NextPart_000_02F4_01CE350D.A21F4B90 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, At the Orlando meeting there was support to have draft-westerlund-avtcore-multiplex-architecture-03 as a working group document. We would like to verify the support on the list. So if you have any comments please send to the list until April 19th. Thanks Roni Even AVTcore co-chair ------=_NextPart_000_02F4_01CE350D.A21F4B90 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

At the Orlando = meeting there was support to have draft-westerlund-avtcore-multiplex-architecture-03 as = a working group document.

 

We would = like to verify the support on the list.

So if you have any comments please send to the list = until April 19th.

 

Thanks

Roni Even = AVTcore co-chair

------=_NextPart_000_02F4_01CE350D.A21F4B90-- From ron.even.tlv@gmail.com Tue Apr 9 00:35:22 2013 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3ACE121F8EDF for ; Tue, 9 Apr 2013 00:35:22 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.179 X-Spam-Level: X-Spam-Status: No, score=-2.179 tagged_above=-999 required=5 tests=[AWL=1.419, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5g8PgM9nddSu for ; Tue, 9 Apr 2013 00:35:21 -0700 (PDT) Received: from mail-ee0-f43.google.com (mail-ee0-f43.google.com [74.125.83.43]) by ietfa.amsl.com (Postfix) with ESMTP id 17FEC21F8EC1 for ; Tue, 9 Apr 2013 00:35:19 -0700 (PDT) Received: by mail-ee0-f43.google.com with SMTP id e50so2756623eek.2 for ; Tue, 09 Apr 2013 00:35:19 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:from:to:subject:date:message-id:mime-version :content-type:x-mailer:thread-index:content-language; bh=AVGHFuF6lcaRL+HA6JN55A20ityiBTP2B8xifuxT3uE=; b=yyA0NWMDpLyRcDfr3nZSkFrDcX55vIwqrUJU5YTuPQfxh5I9pHAO1P9wrfh5169LGi B74Fz0E/fnpxTEpqJXWIA75FO5be/DsFlINOtV2/WTPyLWbu4jNtjhzQBDaLC0emau1k XKI9HguEzQkNOLRrxoNdFvZ8XupqA8GimlFfLLKQPGxZ29s0BkWlb48q3+bZXpB/FCfc 9SvF4X+BTCFYgpyLkBg0BYwozd1y1Ich6kFSgKGPgDC3Skkuu3rNzI6eNCgjcT0YWZ4C EaD77SkkZptGeQtVyQkJ+3Xh1AIwbKVFJ1mmZqX2CvIRsWz7Kz11ygb8CS86GbT26LDs dPjA== X-Received: by 10.15.99.201 with SMTP id bl49mr43476395eeb.43.1365492919202; Tue, 09 Apr 2013 00:35:19 -0700 (PDT) Received: from RoniE (bzq-79-181-177-28.red.bezeqint.net. [79.181.177.28]) by mx.google.com with ESMTPS id n2sm36249551eeo.10.2013.04.09.00.35.17 (version=TLSv1 cipher=RC4-SHA bits=128/128); Tue, 09 Apr 2013 00:35:18 -0700 (PDT) From: "Roni Even" To: Date: Tue, 9 Apr 2013 10:34:52 +0300 Message-ID: <02f801ce34f4$bb134570$3139d050$@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_02F9_01CE350D.E060CB90" X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac409KKyDqYroX7VRiiitegpEQPVgw== Content-Language: en-us Subject: [AVTCORE] draft-westerlund-avtcore-rtp-topologies-update to a working group document X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Apr 2013 07:35:22 -0000 This is a multipart message in MIME format. ------=_NextPart_000_02F9_01CE350D.E060CB90 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, At the Orlando meeting there was support to have draft-westerlund-avtcore-rtp-topologies-update-02 as a working group document. We would like to verify the support on the list. So if you have any comments please send to the list until April 19th. Thanks Roni Even AVTcore co-chair ------=_NextPart_000_02F9_01CE350D.E060CB90 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

At the Orlando = meeting there was support to have draft-westerlund-avtcore-rtp-topologies-update-02 =  as a working group document.

 

We would = like to verify the support on the list.

So if you have any comments please send to the list = until April 19th.

 

Thanks

Roni Even = AVTcore co-chair

------=_NextPart_000_02F9_01CE350D.E060CB90-- From ron.even.tlv@gmail.com Tue Apr 9 00:46:44 2013 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4AAC221F9184 for ; Tue, 9 Apr 2013 00:46:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.308 X-Spam-Level: X-Spam-Status: No, score=-2.308 tagged_above=-999 required=5 tests=[AWL=1.290, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id YUoo20C8vyNr for ; Tue, 9 Apr 2013 00:46:43 -0700 (PDT) Received: from mail-ee0-f53.google.com (mail-ee0-f53.google.com [74.125.83.53]) by ietfa.amsl.com (Postfix) with ESMTP id 59AB021F913C for ; Tue, 9 Apr 2013 00:46:43 -0700 (PDT) Received: by mail-ee0-f53.google.com with SMTP id c13so2768865eek.40 for ; Tue, 09 Apr 2013 00:46:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:from:to:cc:subject:date:message-id:mime-version :content-type:x-mailer:thread-index:content-language; bh=3KQQgiYYpt48mYrQll5s8x48Bab422qm4YEa/skw4X4=; b=vkE2Fc9fK4d632rhJmRZ3/ZCEy7EYe3zHLr7Sqv7or+J7uhG4xmc02dpj6vx06RBj3 OF7t2SOD+tySgrv8O8T3H8XUNnYRw7BnReXRY4GlCT3ZO8dXYwGNIXl4D21B82X3Yyt3 UqHqjGyMjpGNoPsQfTvS3FbA2FR7myCe6ukqapuZtrGgKSkZY+1JU9zxLhmqI5klEP6B TQYen5+MrGwlYrvcuKzJIhBUo9o+CG126RsUbJ3ye91awpqia1tY/IFYg5hqpjBgRDEz XjG4n1vO0LDd/uIAql6IbjPYU3HNfrDz5KNOoK4xxrTTTETw/8jE+/ibRZ68Zo0GlNMT 0h3w== X-Received: by 10.14.4.69 with SMTP id 45mr57702987eei.0.1365493602391; Tue, 09 Apr 2013 00:46:42 -0700 (PDT) Received: from RoniE (bzq-79-181-177-28.red.bezeqint.net. [79.181.177.28]) by mx.google.com with ESMTPS id t4sm36348974eel.0.2013.04.09.00.46.39 (version=TLSv1 cipher=RC4-SHA bits=128/128); Tue, 09 Apr 2013 00:46:41 -0700 (PDT) From: "Roni Even" To: Date: Tue, 9 Apr 2013 10:46:14 +0300 Message-ID: <030101ce34f6$522d9040$f688b0c0$@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0302_01CE350F.777B3D70" X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac409P8YhPv0Pj6eTRmKjBurOm871A== Content-Language: en-us Cc: 'Jonathan Lennox' , 'Colin Perkins' , Magnus Westerlund Subject: [AVTCORE] going forward with draft-lennox-avtcore-rtp-multi-stream X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Apr 2013 07:46:44 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0302_01CE350F.777B3D70 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, http://tools.ietf.org/html/draft-lennox-avtcore-rtp-multi-stream-02 was presented at the Orlando meeting. The draft addresses the issue with supporting multiple sources in an RTP session since current solution will usually support only one source per RTP session. The draft re-visits RFC 3550 to clarify behavior for multi-source endpoints and suggests that there may be a need to update RFC 3550 to change some RTCP timing rules. It proposes recommendations on optimizations for reception reports. There was a consensus to have this document as a WG document. It will incorporate some text from draft-ietf-avtcore-multi-media-rtp-session-02 about RTCP size and timing. Currently we will have the current content but we may look at dividing it to three draft. The AVTcore chairs are asking the authors of draft-lennox-avtcore-rtp-multi-stream to submit it as a WG document and start working also on updating draft-ietf-avtcore-multi-media-rtp-session-02 accordingly to discuss the multiple payload types in one RTP session. The author list of both draft is very similar so it should work. Thanks Roni Even AVTcore co-chair ------=_NextPart_000_0302_01CE350F.777B3D70 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

http://tools.ietf.org/html/draft-lennox-avtcore-rtp-multi-stream-02 was presented at the Orlando meeting.

The draft addresses the issue with = supporting multiple sources in an RTP session since current solution = will usually support only one source per RTP session. The draft = re-visits RFC 3550 to clarify behavior for multi-source endpoints = and suggests that there may be a need to update RFC 3550 to change some = RTCP timing rules.  It proposes recommendations on optimizations = for reception reports.

There was a = consensus to have this document as a WG document. It will incorporate = some text from draft-ietf-avtcore-multi-media-rtp-session-02 about RTCP = size and timing.

Currently we will = have the current content but we may look at dividing it to three = draft.

 

The AVTcore chairs are asking  the authors of = draft-lennox-avtcore-rtp-multi-stream to submit it as a WG = document and start working also on updating = draft-ietf-avtcore-multi-media-rtp-session-02 accordingly to discuss the = multiple payload types in one RTP session.

 

The author = list of both draft is very similar so it should work.

 

Thanks

Roni = Even

AVTcore = co-chair

 

------=_NextPart_000_0302_01CE350F.777B3D70-- From magnus.westerlund@ericsson.com Tue Apr 9 02:27:40 2013 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 84DA621F9173 for ; Tue, 9 Apr 2013 02:27:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.669 X-Spam-Level: X-Spam-Status: No, score=-105.669 tagged_above=-999 required=5 tests=[AWL=-0.376, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_16=0.6, RCVD_IN_DNSWL_MED=-4, SARE_SUB_6CONS_WORD=0.356, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DVt3JgRELgaZ for ; Tue, 9 Apr 2013 02:27:39 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 2EFA021F8FFA for ; Tue, 9 Apr 2013 02:27:39 -0700 (PDT) X-AuditID: c1b4fb2d-b7f316d0000028db-ad-5163df0aff4d Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id BB.93.10459.A0FD3615; Tue, 9 Apr 2013 11:27:38 +0200 (CEST) Received: from [127.0.0.1] (153.88.115.8) by esessmw0184.eemea.ericsson.se (153.88.115.82) with Microsoft SMTP Server id 8.3.279.1; Tue, 9 Apr 2013 11:27:38 +0200 Message-ID: <5163DF09.7050606@ericsson.com> Date: Tue, 9 Apr 2013 11:27:37 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: IETF AVTCore WG X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrEJMWRmVeSWpSXmKPExsUyM+JvrS7X/eRAg2VTeS1e9qxkd2D0WLLk J1MAYxSXTUpqTmZZapG+XQJXxvSbH5gLrupUPH3zj6mB8ahSFyMnh4SAicSLvxtYIGwxiQv3 1rN1MXJxCAmcYpRomzKRCcJZxihx7/Vqxi5GDg5eAW2J5VeyQRpYBFQk2g/sZgSx2QQsJG7+ aGQDsUUFgiV+vjoDNpRXQFDi5MwnYLaIgJLEjknbmEFsYQFDie0PHjFDLJaU2PKinR3EZhbQ k5hytYURwpaXaN46G6xGCGhtQ1MH6wRG/llIxs5C0jILScsCRuZVjOy5iZk56eWGmxiB4XRw y2/dHYynzokcYpTmYFES5w1zvRAgJJCeWJKanZpakFoUX1Sak1p8iJGJg1OqgdH7su+irsi3 IeEyleZP0nmV98bNqHy5ebuFar/PwnTLm/8OPFxpNntDyTffVOMQ19n/vcsc7fb8Puf+mPtd X2p+hBHPvBmtCsmrjYq2C3eF8W5h0GvPnWm+WM4mfJLOp/1vJigpzTIRVrcyXVHY9mT23Isa pvo/tkYnnrv172SM9a6zMSZcDUosxRmJhlrMRcWJANcsEZn1AQAA Subject: [AVTCORE] Comments on draft-ietf-avtcore-clksrc-03 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Apr 2013 09:27:40 -0000 Hi, I promised doing an review of the O/A section. I also found some other issues to consider. 1. Section 5.4: Figure 5 shows the ABNF [5] grammar for the SDP media clock source information. mediaclk-master = "a=ssrc:" integer SP clk-master-id clk-master-id = "mediaclk:master-id=" master-id timestamp-mediaclk = "a=mediaclk:" mediaclock mediaclock = sender / refclk / streamid / mediaclock-ext sender = "sender" sender-ext sender-ext = token refclk = "direct" [ "=" 1*DIGIT ] [rate] [direct-ext] rate = [ SP "rate=" integer "/" integer ] direct-ext = token streamid = "master-id=" master-id streamid =/ "IEEE1722=" avb-stream-id streamid =/ streamid-ext master-id = EUI48 avb-stream-id = EUI64 EUI48 = 5(2HEXDIG ":") 2HEXDIG EUI64 = 7(2HEXDIG ":") 2HEXDIG streamid-ext = token mediaclock-ext = token I wonder if not the mediaclock-ext construction is to restrictive. As the refclk produces a sting with white-spaces in it, why isn't other mediaclock-ext allowed the same freedom? I think the mediaclock-ext can be basically byte-string, i.e. any character allowed on an SDP line should be possible to use. Likely the only resteriction should be that it starts with a token. Thus using: mediaclock-ext = token [SP byte-string] This would require a token for identifying the method followed by a space and then full freedom for anything that is allowed on an SDP attribute value. 2. Section 6: Purpose of signalling? I think this type of signalling can select two levels of goals with signalling: 1) Declaring what each SDP O/A uses on its side 2) Negotiating to arrive at the best but available mechanism on both sides. The currently proposed solution does neither of these. It enables the offerer to express to declare I intended to use X and for the answer to say I know that, or simply say I can't tell you because we are not having the same clocks. I think we need to be clear what our goals are here. And I will propose some goals with the signalling based on my understanding of how these defined timestamp reference clocks and media stream clocks can be used. And we do need to be aware that different application may have different needs. Goal with signalling: 1. Enable each media sender to declare its actually used ts-refclk, i.e. what clock is base for the RTCP SR NTP timestamps 2. Enable each media sender to identify what clock reference is used to check/drive the media sampling, i.e. RTP timestamp advancement. 3. Enable two media sender using SDP O/A to determine what common clocks they actually have so they can be used in either of ts-refclk or mediaclk. The purpose of doing three (3) is really so that one can do the following. A. has three ts-refclk it can use. B has two ts-refclk available. They are going to watch social TV. To make it at all possible for the social TV service to play out content at A and B in sync they need to have either of these two things be available. a) Each has a common clock with the TV service b) A and B has a common clock In either of the scenario the TV service will be able to ensure that the media is played out is sync. As a technical solution to these issues there are two main solution tracks: 1) Change the respective SDP attributes to provide info on all possible clocks for that it could be using and let the answer select the most preferred that both are supporting 2) Leave the current SDP attributes as they are and only use them for declaration that: I use this! Then add new SDP attributes to negotiate the list of commonly supported clocks. At this stage I think 2) is what is simplest and require the least changes to what already exist. I will note that this is likely to require a second round of O/A messages to update used clocks if the arrived common clock(s) are not the default used ones. But, I don't see a way around these. In SIP one could use OPTIONS to provide a SDP which includes the negotiation attribute to enable the other side to select using a clock that is supported by both. But when that isn't done, it will take two rounds or other a'priori knowledge. So my proposal is simply that one create two new SDP attributes one for each type of clock usage (ts-refclk and mediaclk) and include a list of clock type and any ID of the clock in a priority order. The O/A is basic negotiated and the answer removes all clocks it doesn't support and adds all it supports. Hopefully there is someone in the list that is common. The highest priority between the two parties should be used when common clock is required. IF that is not, then these attributes should not be included. This for example allows one to use a common ts-refclk, but not require common mediaclk. We should also discuss if the answerer may change the priority of commonly supported, and if it should or should not add additional clocks it supports that are not common. I really appreciate feedback on these comments and ideas. Cheers Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From magnus.westerlund@ericsson.com Wed Apr 10 00:58:12 2013 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4ECE921F8675 for ; Wed, 10 Apr 2013 00:58:12 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.249 X-Spam-Level: X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OOlTc1bOvbCN for ; Wed, 10 Apr 2013 00:58:11 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 172B321F8546 for ; Wed, 10 Apr 2013 00:58:10 -0700 (PDT) X-AuditID: c1b4fb2d-b7f316d0000028db-a1-51651b923fa4 Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 2C.E8.10459.29B15615; Wed, 10 Apr 2013 09:58:10 +0200 (CEST) Received: from [127.0.0.1] (153.88.115.8) by esessmw0256.eemea.ericsson.se (153.88.115.97) with Microsoft SMTP Server id 8.3.279.1; Wed, 10 Apr 2013 09:58:10 +0200 Message-ID: <51651B91.1010303@ericsson.com> Date: Wed, 10 Apr 2013 09:58:09 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: Magnus Westerlund References: <513F7C5B.5060101@ericsson.com> <51541502.90406@ericsson.com> In-Reply-To: <51541502.90406@ericsson.com> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmpjluLIzCtJLcpLzFFi42KZGfG3VneSdGqgQdN8QYuXPSvZHRg9liz5 yRTAGMVlk5Kak1mWWqRvl8CVsfPLY/aCFuGKBYuvMzYwbuDvYuTkkBAwkZjWfpsdwhaTuHBv PVsXIxeHkMApRokTp1ayQjjLGSWOvd3FDFLFK6AtceH1BFYQm0VAVeL54qNgNpuAhcTNH41s ILaoQLDEz1dnWCDqBSVOznwCZosImEk8nLAfrIZZQEDi/9pmsM3CAkESu5fMBLI5gJZ5SrRP ByvnFNCSOHrvFBPEcZISW160s0O06klMudrCCGHLSzRvnQ12mhDQaQ1NHawTGIVmIdk8C0nL LCQtCxiZVzGy5yZm5qSXG25iBIblwS2/dXcwnjoncohRmoNFSZw3zPVCgJBAemJJanZqakFq UXxRaU5q8SFGJg5OqQZGy1KhJydmn/ZWWdr2/cUXR595bbF7EoNCeP/GJB0zWHtvVbuDxwPv 5+KHXvR2vQ7580hlsnH9okT37Q79y7evrtvpKixZ22Mis7TPPeVx1LyAhRn8S6asNmR3VNdM 6pzZlmLWUS9xQCbVb0l85sK7tfNeTuaOjfoy0/PWX7ljseFh20/P6ytQYinOSDTUYi4qTgQA tIp9XxkCAAA= Cc: avt@ietf.org Subject: Re: [AVTCORE] Reminder: Re: WG last call on draft-ietf-avtcore-6222bis-01 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Apr 2013 07:58:12 -0000 WG, This WG last call has concluded. I think the level of reviews on this document are very low. In the working group last call only Kevin Gross and I have stated that they have reviewed the latest version. Authors please address raised issues. I will not consider this a successful WG last call unless at least one additional person reviews it who are not an author. It is a very short document and it also don't require massive amounts of additional knowledge beyond basic RTP understanding to review. Regards Magnus Westerlund WG chair On 2013-03-28 11:01, Magnus Westerlund wrote: > WG, > > So far there has be no other reviews of this document than mine. > > Can someone please review this document? > > I hereby extended the WG last call with one week until the 7th of April. > > Cheers > > Magnus > > On 2013-03-12 20:04, Magnus Westerlund wrote: >> WG, >> >> This is to announce the start of a WG last call on: >> >> Guidelines for Choosing RTP Control Protocol (RTCP) Canonical Names >> (CNAMEs) to be published as a proposed standard. >> >> Document can be retrieved here: >> https://datatracker.ietf.org/doc/draft-ietf-avtcore-6222bis/ >> >> Please provide any feedback by the 31st of March. >> >> Regards >> >> Magnus Westerlund >> WG chair >> >> >> ---------------------------------------------------------------------- >> Multimedia Technologies, Ericsson Research EAB/TVM >> ---------------------------------------------------------------------- >> Ericsson AB | Phone +46 10 7148287 >> Färögatan 6 | Mobile +46 73 0949079 >> SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com >> ---------------------------------------------------------------------- >> >> _______________________________________________ >> Audio/Video Transport Core Maintenance >> avt@ietf.org >> https://www.ietf.org/mailman/listinfo/avt >> >> > > -- Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From magnus.westerlund@ericsson.com Wed Apr 10 06:19:24 2013 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3D1D421F960A for ; Wed, 10 Apr 2013 06:19:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.349 X-Spam-Level: X-Spam-Status: No, score=-105.349 tagged_above=-999 required=5 tests=[AWL=-0.900, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_33=0.6, J_CHICKENPOX_47=0.6, J_CHICKENPOX_48=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gvy-IrnfhuEo for ; Wed, 10 Apr 2013 06:19:21 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 3F73021F9607 for ; Wed, 10 Apr 2013 06:19:21 -0700 (PDT) X-AuditID: c1b4fb2d-b7f316d0000028db-a8-516566d8c4a6 Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id E1.05.10459.8D665615; Wed, 10 Apr 2013 15:19:20 +0200 (CEST) Received: from [127.0.0.1] (153.88.115.8) by esessmw0191.eemea.ericsson.se (153.88.115.85) with Microsoft SMTP Server id 8.3.279.1; Wed, 10 Apr 2013 15:19:19 +0200 Message-ID: <516566D7.809@ericsson.com> Date: Wed, 10 Apr 2013 15:19:19 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130307 Thunderbird/17.0.4 MIME-Version: 1.0 To: IETF AVTCore WG References: <20130410131256.CBFFFB1E006@rfc-editor.org> In-Reply-To: <20130410131256.CBFFFB1E006@rfc-editor.org> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrBJMWRmVeSWpSXmKPExsUyM+Jvre6NtNRAg8sTRCxe9qxkd2D0WLLk J1MAYxSXTUpqTmZZapG+XQJXxqe9wQVPxSs+Hl7K0sB4UKiLkYNDQsBEYtMrxy5GTiBTTOLC vfVsXYxcHEICpxglXm/cyArhLGeUmHnpPjNIFa+AusSVvuNMIDaLgKrE30lL2UFsNgELiZs/ GtlAbFGBYImfr86wQNQLSpyc+QTMFhFQktgxaRszyGJhAXOJhT0RIGEhIPPr9/msIDYn0Jg7 t48yQRwkKbHlRTvYeGYBPYkpV1sYIWx5ieats5kherUlGpo6WCcwCs5Csm0WkpZZSFoWMDKv YmTPTczMSS833MQIDL2DW37r7mA8dU7kEKM0B4uSOG+Y64UAIYH0xJLU7NTUgtSi+KLSnNTi Q4xMHJxSDYy95+I+7Zi7J+/VvGjpqW0BYScOnnor5Hnu40If5l3lzsJ6l8J9astPV9voumtN Not4soxLrDT/zbOwpWK/u8wvi3z+se9IR0zDnex94vN9X6sLvj9oGsjIsVYzesp9znnNtuX7 N09vvrt80R/dPy4qbpW3fc3eS9yXWfoqZPYf/rtvPBgPrTqrxFKckWioxVxUnAgAJV71FAsC AAA= Subject: Re: [AVTCORE] [Editorial Errata Reported] RFC6679 (3586) X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Apr 2013 13:19:24 -0000 WG, I have submitted this Errata. I would personally recommend that this will be put into Verified due to the common practice to code according to examples rather than the normative ABNF. I hope people can provide any input on this within the next 2 weeks. Cheers Magnus (As Individual) On 2013-04-10 15:12, RFC Errata System wrote: > The following errata report has been submitted for RFC6679, > "Explicit Congestion Notification (ECN) for RTP over UDP". > > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=6679&eid=3586 > > -------------------------------------- > Type: Editorial > Reported by: Magnus Westerlund > > Section: 12.1 > > Original Text > ------------- > The Offer: > > ... > a=ecn-capable-rtp: ice rtp ect=0 mode=setread > ... > > The Answer: > ... > a=ecn-capable-rtp: ice ect=0 mode=readonly > ... > > Corrected Text > -------------- > The Offer: > > ... > a=ecn-capable-rtp: ice,rtp ect=0; mode=setread > ... > > The Answer: > ... > a=ecn-capable-rtp: ice ect=0; mode=readonly > ... > > Notes > ----- > The examples does not match the ABNF rules for the > a=ecn-capaable-rtp attribute. Two issues are present, first the > init method list must be comma separated with no spaces, secondly > any additional parameters shall be semi colon plus space > separated. Therefore both a=ecn-capable-rtp lines have been > corrected. > > This is primarily an editorial issues but people needs to aware of > the errors in the example. > > Instructions: > ------------- > This errata is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party (IESG) > can log in to change the status and edit the report, if necessary. > > -------------------------------------- > RFC6679 (draft-ietf-avtcore-ecn-for-rtp-08) > -------------------------------------- > Title : Explicit Congestion Notification (ECN) for RTP over UDP > Publication Date : August 2012 > Author(s) : M. Westerlund, I. Johansson, C. Perkins, P. O'Hanlon, K. Carlberg > Category : PROPOSED STANDARD > Source : Audio/Video Transport Core Maintenance > Area : Real-time Applications and Infrastructure > Stream : IETF > Verifying Party : IESG > > -- Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From internet-drafts@ietf.org Wed Apr 10 09:29:50 2013 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6EDD021F87CB; Wed, 10 Apr 2013 09:29:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.346 X-Spam-Level: X-Spam-Status: No, score=-102.346 tagged_above=-999 required=5 tests=[AWL=0.254, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id QopjhhzRWqjQ; Wed, 10 Apr 2013 09:29:50 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 0A56821F8793; Wed, 10 Apr 2013 09:29:50 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.43.p4 Message-ID: <20130410162949.28228.61181.idtracker@ietfa.amsl.com> Date: Wed, 10 Apr 2013 09:29:49 -0700 Cc: avt@ietf.org Subject: [AVTCORE] I-D Action: draft-ietf-avtcore-avp-codecs-02.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Apr 2013 16:29:50 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Audio/Video Transport Core Maintenance Wo= rking Group of the IETF. Title : Update to Recommended Codecs for the RTP Profile for Aud= io and Video Conferences with Minimal Control (RTP/AVP) Author(s) : Timothy B. Terriberry Filename : draft-ietf-avtcore-avp-codecs-02.txt Pages : 4 Date : 2013-04-10 Abstract: The RTP Profile for Audio and Video Conferences with Minimal Control (RTP/AVP) is the basis for many other profiles, such as the Secure Real-time Transport Protocol (RTP/SAVP), the Extended RTP Profile for Real-time Transport Control Protocol (RTCP)-Based Feedback (RTP/ AVPF), and the Extended Secure RTP Profile for RTCP-Based Feedback (RTP/SAVPF). This document updates the RTP/AVP profile (and by extension, the profiles that build upon it) to reflect changes in audio codec usage since the document was originally published. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-avtcore-avp-codecs There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-avtcore-avp-codecs-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-avtcore-avp-codecs-02 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From tterribe@xiph.org Wed Apr 10 09:37:48 2013 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 3607721F8D0F for ; Wed, 10 Apr 2013 09:37:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.677 X-Spam-Level: X-Spam-Status: No, score=-2.677 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_MISMATCH_ORG=0.611, HOST_MISMATCH_COM=0.311, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id KtkOcQavsU5C for ; Wed, 10 Apr 2013 09:37:46 -0700 (PDT) Received: from smtp.mozilla.org (mx2.corp.phx1.mozilla.com [63.245.216.70]) by ietfa.amsl.com (Postfix) with ESMTP id 1CEC021F8D09 for ; Wed, 10 Apr 2013 09:37:46 -0700 (PDT) Received: from [10.250.6.54] (unknown [63.245.220.240]) (Authenticated sender: tterriberry@mozilla.com) by mx2.mail.corp.phx1.mozilla.com (Postfix) with ESMTPSA id B02A0F2252 for ; Wed, 10 Apr 2013 09:37:45 -0700 (PDT) Message-ID: <51659559.8060901@xiph.org> Date: Wed, 10 Apr 2013 09:37:45 -0700 From: "Timothy B. Terriberry" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:19.0) Gecko/20100101 SeaMonkey/2.16.2 MIME-Version: 1.0 To: avt@ietf.org References: <20130410162949.28228.61181.idtracker@ietfa.amsl.com> In-Reply-To: <20130410162949.28228.61181.idtracker@ietfa.amsl.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [AVTCORE] I-D Action: draft-ietf-avtcore-avp-codecs-02.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Apr 2013 16:37:48 -0000 internet-drafts@ietf.org wrote: > A New Internet-Draft is available from the on-line Internet-Drafts directories. > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-avtcore-avp-codecs > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-avtcore-avp-codecs-02 > > A diff from the previous version is available at: > http://www.ietf.org/rfcdiff?url2=draft-ietf-avtcore-avp-codecs-02 Changelog for this version: - Updated profile names to include the "RTP/" prefix. - Expanded the references in the abstract into document titles, and added a sentence to the introduce to actually reference the relevant RFCs. - Used Magnus's proposal for describing the text updates. - Used Keith's proposed text: "Some environments REQUIRE support for PCMU" (without including an "only"). I did not change anything with respect to PCMA, as I could detect no clear consensus on the topic. We have one person arguing that neither PCMU nor PCMA should be SHOULD requirements, but I think that's a big enough change that more than one person should advocate for it before we make it (especially considering that PCMU was recently made a MUST for WebRTC). If I missed any other comments, please let me know! From martin.thomson@gmail.com Wed Apr 10 10:42:08 2013 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BBBCC21F8BF4 for ; Wed, 10 Apr 2013 10:42:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.6 X-Spam-Level: X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id xwLcymBn4tud for ; Wed, 10 Apr 2013 10:42:08 -0700 (PDT) Received: from mail-wi0-x229.google.com (mail-wi0-x229.google.com [IPv6:2a00:1450:400c:c05::229]) by ietfa.amsl.com (Postfix) with ESMTP id 19CE021F8BBD for ; Wed, 10 Apr 2013 10:42:07 -0700 (PDT) Received: by mail-wi0-f169.google.com with SMTP id c10so6456305wiw.4 for ; Wed, 10 Apr 2013 10:42:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:date:message-id:subject:from:to :content-type; bh=GKs4hNxMBb0IptD/m1xSR7OfiQh1JDhBzHIqLle5BT0=; b=Xgf1qPia5yimpfGm56W9ZX4OzGeA+s1Bts5291kXaRt+Mp3MeFG/5YCyePxQWQj12q iZJX55S+SlXzNq6f8Fnwp1MzHApWe/xmvBUHLmPB8MnBrPXxOGVW1W5XQKTd5A8D/sCY wsvVisoZt6QDbwSaBuH0VDsB8CgYL2dbq+2+lpfKP1ZzNZgAUJOE2o51SGCk4JF1C0jO A4XH1LkFNLyXYM1MOgvr8gKApJ48LxoML5fUHitkcYXlbl3HTcuSPRwUFVFcKbWRbBv5 uZE9z68dojW5sGrX7aPhZnc0lS6uhBe4gbjtnzYitpe1Lrbq9lYHPh/UyZL54RBFLg/R 9mrg== MIME-Version: 1.0 X-Received: by 10.180.109.197 with SMTP id hu5mr4896388wib.22.1365615727296; Wed, 10 Apr 2013 10:42:07 -0700 (PDT) Received: by 10.194.41.35 with HTTP; Wed, 10 Apr 2013 10:42:07 -0700 (PDT) Date: Wed, 10 Apr 2013 10:42:07 -0700 Message-ID: From: Martin Thomson To: avt@ietf.org, Magnus Westerlund Content-Type: text/plain; charset=UTF-8 Subject: [AVTCORE] 6222bis X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Apr 2013 17:42:08 -0000 As requested of RTCWEB, I have read this document. It is good and should be published. I suspect that many people find it hard to get excited enough about this to bother reading it. It's just not that interesting a subject. Especially since this is entirely non-controversial. I feel a little uncomfortable that the document justifies its existence (as a -bis) largely based on a reference to an individual draft. I would prefer to see the rationale presented in an appendix instead; it's fairly important information to retain. From wwwrun@rfc-editor.org Wed Apr 10 06:13:33 2013 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2F58721F9796 for ; Wed, 10 Apr 2013 06:13:33 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -101.7 X-Spam-Level: X-Spam-Status: No, score=-101.7 tagged_above=-999 required=5 tests=[AWL=-0.900, BAYES_00=-2.599, J_CHICKENPOX_33=0.6, J_CHICKENPOX_47=0.6, J_CHICKENPOX_48=0.6, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Gk5BCOAfqMF5 for ; Wed, 10 Apr 2013 06:13:32 -0700 (PDT) Received: from rfc-editor.org (unknown [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id BC63021F9789 for ; Wed, 10 Apr 2013 06:13:32 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id CBFFFB1E006; Wed, 10 Apr 2013 06:12:56 -0700 (PDT) To: magnus.westerlund@ericsson.com, ingemar.s.johansson@ericsson.com, csp@csperkins.org, piers.ohanlon@oii.ox.ac.uk, carlberg@g11.org.uk, rlb@ipv.sx, gonzalo.camarillo@ericsson.com, roni.even@mail01.huawei.com, magnus.westerlund@ericsson.com From: RFC Errata System Message-Id: <20130410131256.CBFFFB1E006@rfc-editor.org> Date: Wed, 10 Apr 2013 06:12:56 -0700 (PDT) X-Mailman-Approved-At: Wed, 10 Apr 2013 11:40:54 -0700 Cc: magnus.westerlund@ericsson.com, avt@ietf.org, rfc-editor@rfc-editor.org Subject: [AVTCORE] [Editorial Errata Reported] RFC6679 (3586) X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 10 Apr 2013 13:13:33 -0000 The following errata report has been submitted for RFC6679, "Explicit Congestion Notification (ECN) for RTP over UDP". -------------------------------------- You may review the report below and at: http://www.rfc-editor.org/errata_search.php?rfc=6679&eid=3586 -------------------------------------- Type: Editorial Reported by: Magnus Westerlund Section: 12.1 Original Text ------------- The Offer: ... a=ecn-capable-rtp: ice rtp ect=0 mode=setread ... The Answer: ... a=ecn-capable-rtp: ice ect=0 mode=readonly ... Corrected Text -------------- The Offer: ... a=ecn-capable-rtp: ice,rtp ect=0; mode=setread ... The Answer: ... a=ecn-capable-rtp: ice ect=0; mode=readonly ... Notes ----- The examples does not match the ABNF rules for the a=ecn-capaable-rtp attribute. Two issues are present, first the init method list must be comma separated with no spaces, secondly any additional parameters shall be semi colon plus space separated. Therefore both a=ecn-capable-rtp lines have been corrected. This is primarily an editorial issues but people needs to aware of the errors in the example. Instructions: ------------- This errata is currently posted as "Reported". If necessary, please use "Reply All" to discuss whether it should be verified or rejected. When a decision is reached, the verifying party (IESG) can log in to change the status and edit the report, if necessary. -------------------------------------- RFC6679 (draft-ietf-avtcore-ecn-for-rtp-08) -------------------------------------- Title : Explicit Congestion Notification (ECN) for RTP over UDP Publication Date : August 2012 Author(s) : M. Westerlund, I. Johansson, C. Perkins, P. O'Hanlon, K. Carlberg Category : PROPOSED STANDARD Source : Audio/Video Transport Core Maintenance Area : Real-time Applications and Infrastructure Stream : IETF Verifying Party : IESG From ray.vanbrandenburg@tno.nl Thu Apr 11 00:49:35 2013 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ECCE821F8EA5 for ; Thu, 11 Apr 2013 00:49:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.503 X-Spam-Level: X-Spam-Status: No, score=-0.503 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, HTML_MESSAGE=0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 71RwRWD21zh9 for ; Thu, 11 Apr 2013 00:49:34 -0700 (PDT) Received: from fromintoutb.tno.nl (fromintoutb.tno.nl [134.221.1.27]) by ietfa.amsl.com (Postfix) with ESMTP id 7F7CE21F8E94 for ; Thu, 11 Apr 2013 00:49:34 -0700 (PDT) X-IronPort-AV: E=Sophos;i="4.87,454,1363129200"; d="scan'208,217";a="1167369" Received: from unknown (HELO mail.tno.nl) ([134.221.225.222]) by mailhost1b.tno.nl with ESMTP; 11 Apr 2013 09:49:33 +0200 Received: from EXC-MBX03.tsn.tno.nl ([169.254.3.241]) by EXC-CASHUB03.tsn.tno.nl ([134.221.225.222]) with mapi id 14.02.0318.004; Thu, 11 Apr 2013 09:49:32 +0200 From: "Brandenburg, R. (Ray) van" To: "avt@ietf.org" Thread-Topic: Review of draft-ietf-avtcore-6222bis Thread-Index: Ac42iQ5wIiEH76hBRRKKB654zp+zdg== Date: Thu, 11 Apr 2013 07:49:31 +0000 Message-ID: Accept-Language: en-US, nl-NL Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [134.221.225.191] Content-Type: multipart/alternative; boundary="_000_FCC100FC8D6B034CB88CD8173B2DA1581CA56936EXCMBX03tsntnon_" MIME-Version: 1.0 Cc: "draft-ietf-avtcore-6222bis@tools.ietf.org" Subject: [AVTCORE] Review of draft-ietf-avtcore-6222bis X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Apr 2013 07:49:36 -0000 --_000_FCC100FC8D6B034CB88CD8173B2DA1581CA56936EXCMBX03tsntnon_ Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Hi all, I've reviewed draft-ietf-avtcore-6222bis. I've got two small comments/questions. I've not followed all discussion on = this draft, so my comments might have been discussed earlier. - Section 1 includes a reference to I-D.rescorla-avtcore-random-cname. What= is the nature and intended status of this draft? Is it meant to be updated= in the future (the latest version expired a couple of months ago)? If not,= is it necessary to include it here for reference or can it be removed? - Section 3 describes the deficiencies with the generation of CNAMEs in RFC= 3550, it does not describe the deficiencies in RFC6222 (while the problems = with RFC6222 are hinted at in both the introduction and abstract). Is this = intentional due to the fact that this draft obsoletes RFC6222 and that docu= ment can thus be considered informative for the purposes of this draft? Apart from these minor comments, I consider the draft to be ready for publi= cation. Best regards, Ray This e-mail and its contents are subject to the DISCLAIMER at http://www.tn= o.nl/emaildisclaimer --_000_FCC100FC8D6B034CB88CD8173B2DA1581CA56936EXCMBX03tsntnon_ Content-Type: text/html; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable
Hi all,
 
I’ve reviewed draft-ietf-avtcore-6222bis.
 
I’ve got two small comments/questions. I’ve not followed a= ll discussion on this draft, so my comments might have been discussed earli= er.
 
- Section 1 includes a reference to I-D.rescorla-avtcore-random-cname.= What is the nature and intended status of this draft? Is it meant to be up= dated in the future (the latest version expired a couple of months ago)? If= not, is it necessary to include it here for reference or can it be removed?
- Section 3 describes the deficiencies with the generation of CNAMEs i= n RFC3550, it does not describe the deficiencies in RFC6222 (while the prob= lems with RFC6222 are hinted at in both the introduction and abstract). Is = this intentional due to the fact that this draft obsoletes RFC6222 and that document can thus be considered = informative for the purposes of this draft?
 
Apart from these minor comments, I consider the draft to be ready for = publication.
 
Best regards,
 
Ray
 
 

This e-mail and its contents are subject to the DISCLAIMER at http://www= .tno.nl/emaildisclaimer

--_000_FCC100FC8D6B034CB88CD8173B2DA1581CA56936EXCMBX03tsntnon_-- From abegen@cisco.com Thu Apr 11 00:55:24 2013 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B043321F8EC9 for ; Thu, 11 Apr 2013 00:55:24 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.598 X-Spam-Level: X-Spam-Status: No, score=-10.598 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U8OTt9gBZxGj for ; Thu, 11 Apr 2013 00:55:23 -0700 (PDT) Received: from rcdn-iport-7.cisco.com (rcdn-iport-7.cisco.com [173.37.86.78]) by ietfa.amsl.com (Postfix) with ESMTP id AB6F921F8ECA for ; Thu, 11 Apr 2013 00:55:23 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9453; q=dns/txt; s=iport; t=1365666923; x=1366876523; h=from:to:cc:subject:date:message-id:in-reply-to: mime-version; bh=fPGyjhavas2wnAt1WpWJKng7bMB3hn6VG/jqWukvbLM=; b=Xl6TltSfH3sxEpoK+kRSLjdJKFDUxV/YEYIx9RJd+7YzW/llG8ZBKpgd iECx0kpIRxRiqD7gxuIOg+kTA6fdH2AyGuE3MilPLQGKOa5xXYsITXYiu aqTptXl53gRacwo+RhoOxgnU7k4JYa/jrpoxS2efD9UrjSMEzF/b9O2gp M=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AisFAB1rZlGtJV2c/2dsb2JhbABQgkIjITaDLr4dDXQWdIIfAQEBBCMKTBIBCBEDAQILHQMCBDAUCQgBAQQBDQUIiAwBC6t6kn2NZIEBDQkKEQeCLjJhA6gOgwuBczU X-IronPort-AV: E=Sophos;i="4.87,454,1363132800"; d="scan'208,217";a="197489228" Received: from rcdn-core-5.cisco.com ([173.37.93.156]) by rcdn-iport-7.cisco.com with ESMTP; 11 Apr 2013 07:55:23 +0000 Received: from xhc-aln-x06.cisco.com (xhc-aln-x06.cisco.com [173.36.12.80]) by rcdn-core-5.cisco.com (8.14.5/8.14.5) with ESMTP id r3B7tNls027759 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 11 Apr 2013 07:55:23 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-aln-x06.cisco.com ([173.36.12.80]) with mapi id 14.02.0318.004; Thu, 11 Apr 2013 02:55:22 -0500 From: "Ali C. Begen (abegen)" To: "Brandenburg, R. (Ray) van" , "avt@ietf.org" Thread-Topic: [AVTCORE] Review of draft-ietf-avtcore-6222bis Thread-Index: Ac42iQ5wIiEH76hBRRKKB654zp+zdgAQ+qcA Date: Thu, 11 Apr 2013 07:54:00 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.2.130206 x-originating-ip: [10.61.98.223] Content-Type: multipart/alternative; boundary="_000_C15918F2FCDA0243A7C919DA7C4BE9940CFCE8D2xmbalnx01ciscoc_" MIME-Version: 1.0 Cc: "draft-ietf-avtcore-6222bis@tools.ietf.org" Subject: Re: [AVTCORE] Review of draft-ietf-avtcore-6222bis X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Apr 2013 07:55:24 -0000 --_000_C15918F2FCDA0243A7C919DA7C4BE9940CFCE8D2xmbalnx01ciscoc_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 RnJvbTogPEJyYW5kZW5idXJnPiwgIlIuIHZhbiAoUmF5KSIgPHJheS52YW5icmFuZGVuYnVyZ0B0 bm8ubmw8bWFpbHRvOnJheS52YW5icmFuZGVuYnVyZ0B0bm8ubmw+Pg0KRGF0ZTogVGh1cnNkYXks IEFwcmlsIDExLCAyMDEzIDEwOjQ5IEFNDQpUbzogImF2dEBpZXRmLm9yZzxtYWlsdG86YXZ0QGll dGYub3JnPiIgPGF2dEBpZXRmLm9yZzxtYWlsdG86YXZ0QGlldGYub3JnPj4NCkNjOiAiZHJhZnQt aWV0Zi1hdnRjb3JlLTYyMjJiaXNAdG9vbHMuaWV0Zi5vcmc8bWFpbHRvOmRyYWZ0LWlldGYtYXZ0 Y29yZS02MjIyYmlzQHRvb2xzLmlldGYub3JnPiIgPGRyYWZ0LWlldGYtYXZ0Y29yZS02MjIyYmlz QHRvb2xzLmlldGYub3JnPG1haWx0bzpkcmFmdC1pZXRmLWF2dGNvcmUtNjIyMmJpc0B0b29scy5p ZXRmLm9yZz4+DQpTdWJqZWN0OiBbQVZUQ09SRV0gUmV2aWV3IG9mIGRyYWZ0LWlldGYtYXZ0Y29y ZS02MjIyYmlzDQoNCkhpIGFsbCwNCg0KSeKAmXZlIHJldmlld2VkIGRyYWZ0LWlldGYtYXZ0Y29y ZS02MjIyYmlzLg0KDQpUaGFua3MuDQoNCknigJl2ZSBnb3QgdHdvIHNtYWxsIGNvbW1lbnRzL3F1 ZXN0aW9ucy4gSeKAmXZlIG5vdCBmb2xsb3dlZCBhbGwgZGlzY3Vzc2lvbiBvbiB0aGlzIGRyYWZ0 LCBzbyBteSBjb21tZW50cyBtaWdodCBoYXZlIGJlZW4gZGlzY3Vzc2VkIGVhcmxpZXIuDQoNCi0g U2VjdGlvbiAxIGluY2x1ZGVzIGEgcmVmZXJlbmNlIHRvIEktRC5yZXNjb3JsYS1hdnRjb3JlLXJh bmRvbS1jbmFtZS4gV2hhdCBpcyB0aGUgbmF0dXJlIGFuZCBpbnRlbmRlZCBzdGF0dXMgb2YgdGhp cyBkcmFmdD8gSXMgaXQgbWVhbnQgdG8gYmUgdXBkYXRlZCBpbiB0aGUgZnV0dXJlICh0aGUgbGF0 ZXN0IHZlcnNpb24gZXhwaXJlZCBhIGNvdXBsZSBvZiBtb250aHMgYWdvKT8gSWYgbm90LCBpcyBp dCBuZWNlc3NhcnkgdG8gaW5jbHVkZSBpdCBoZXJlIGZvciByZWZlcmVuY2Ugb3IgY2FuIGl0IGJl IHJlbW92ZWQ/DQoNClRoYXQgZHJhZnQgd2lsbCBsaWtlbHkgZXhwaXJlIGFuZCBub3QgYmUgcHVi bGlzaGVkLiBUaGF0IGRyYWZ0IG1vdGl2YXRlZCB0aGUgbmVlZCBmb3IgdGhlIGJpcyBkb2N1bWVu dCAodGhlIGxpbmthYmlsaXR5IG9mIG91dHB1dHMgcmVzdWx0aW5nIGZyb20gdGhlIGFsZ29yaXRo bXMgaW4gNjIyMikuDQoNCi0gU2VjdGlvbiAzIGRlc2NyaWJlcyB0aGUgZGVmaWNpZW5jaWVzIHdp dGggdGhlIGdlbmVyYXRpb24gb2YgQ05BTUVzIGluIFJGQzM1NTAsIGl0IGRvZXMgbm90IGRlc2Ny aWJlIHRoZSBkZWZpY2llbmNpZXMgaW4gUkZDNjIyMiAod2hpbGUgdGhlIHByb2JsZW1zIHdpdGgg UkZDNjIyMiBhcmUgaGludGVkIGF0IGluIGJvdGggdGhlIGludHJvZHVjdGlvbiBhbmQgYWJzdHJh Y3QpLiBJcyB0aGlzIGludGVudGlvbmFsIGR1ZSB0byB0aGUgZmFjdCB0aGF0IHRoaXMgZHJhZnQg b2Jzb2xldGVzIFJGQzYyMjIgYW5kIHRoYXQgZG9jdW1lbnQgY2FuIHRodXMgYmUgY29uc2lkZXJl ZCBpbmZvcm1hdGl2ZSBmb3IgdGhlIHB1cnBvc2VzIG9mIHRoaXMgZHJhZnQ/DQoNCkNvcnJlY3Qu DQoNCiBBcGFydCBmcm9tIHRoZXNlIG1pbm9yIGNvbW1lbnRzLCBJIGNvbnNpZGVyIHRoZSBkcmFm dCB0byBiZSByZWFkeSBmb3IgcHVibGljYXRpb24uDQoNCg0KVGhhbmtzLg0KLWFjYmVnZW4NCg0K QmVzdCByZWdhcmRzLA0KDQpSYXkNCg0KDQoNClRoaXMgZS1tYWlsIGFuZCBpdHMgY29udGVudHMg YXJlIHN1YmplY3QgdG8gdGhlIERJU0NMQUlNRVIgYXQgaHR0cDovL3d3dy50bm8ubmwvZW1haWxk aXNjbGFpbWVyDQoNCg0K --_000_C15918F2FCDA0243A7C919DA7C4BE9940CFCE8D2xmbalnx01ciscoc_ Content-Type: text/html; charset="utf-8" Content-ID: <67F650D1452D2E4A9C5043DB39016894@emea.cisco.com> Content-Transfer-Encoding: base64 PGh0bWw+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIgY29udGVudD0i dGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjwvaGVhZD4NCjxib2R5IHN0eWxlPSJ3b3JkLXdy YXA6IGJyZWFrLXdvcmQ7IC13ZWJraXQtbmJzcC1tb2RlOiBzcGFjZTsgLXdlYmtpdC1saW5lLWJy ZWFrOiBhZnRlci13aGl0ZS1zcGFjZTsgY29sb3I6IHJnYigwLCAwLCAwKTsgZm9udC1zaXplOiAx NHB4OyBmb250LWZhbWlseTogQ29uc29sYXMsIHNhbnMtc2VyaWY7ICI+DQo8c3BhbiBpZD0iT0xL X1NSQ19CT0RZX1NFQ1RJT04iPg0KPGRpdiBzdHlsZT0iZm9udC1mYW1pbHk6Q2FsaWJyaTsgZm9u dC1zaXplOjExcHQ7IHRleHQtYWxpZ246bGVmdDsgY29sb3I6YmxhY2s7IEJPUkRFUi1CT1RUT006 IG1lZGl1bSBub25lOyBCT1JERVItTEVGVDogbWVkaXVtIG5vbmU7IFBBRERJTkctQk9UVE9NOiAw aW47IFBBRERJTkctTEVGVDogMGluOyBQQURESU5HLVJJR0hUOiAwaW47IEJPUkRFUi1UT1A6ICNi NWM0ZGYgMXB0IHNvbGlkOyBCT1JERVItUklHSFQ6IG1lZGl1bSBub25lOyBQQURESU5HLVRPUDog M3B0Ij4NCjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xkIj5Gcm9tOiA8L3NwYW4+Jmx0O0Jy YW5kZW5idXJnJmd0OywgJnF1b3Q7Ui4gdmFuIChSYXkpJnF1b3Q7ICZsdDs8YSBocmVmPSJtYWls dG86cmF5LnZhbmJyYW5kZW5idXJnQHRuby5ubCI+cmF5LnZhbmJyYW5kZW5idXJnQHRuby5ubDwv YT4mZ3Q7PGJyPg0KPHNwYW4gc3R5bGU9ImZvbnQtd2VpZ2h0OmJvbGQiPkRhdGU6IDwvc3Bhbj5U aHVyc2RheSwgQXByaWwgMTEsIDIwMTMgMTA6NDkgQU08YnI+DQo8c3BhbiBzdHlsZT0iZm9udC13 ZWlnaHQ6Ym9sZCI+VG86IDwvc3Bhbj4mcXVvdDs8YSBocmVmPSJtYWlsdG86YXZ0QGlldGYub3Jn Ij5hdnRAaWV0Zi5vcmc8L2E+JnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86YXZ0QGlldGYub3Jn Ij5hdnRAaWV0Zi5vcmc8L2E+Jmd0Ozxicj4NCjxzcGFuIHN0eWxlPSJmb250LXdlaWdodDpib2xk Ij5DYzogPC9zcGFuPiZxdW90OzxhIGhyZWY9Im1haWx0bzpkcmFmdC1pZXRmLWF2dGNvcmUtNjIy MmJpc0B0b29scy5pZXRmLm9yZyI+ZHJhZnQtaWV0Zi1hdnRjb3JlLTYyMjJiaXNAdG9vbHMuaWV0 Zi5vcmc8L2E+JnF1b3Q7ICZsdDs8YSBocmVmPSJtYWlsdG86ZHJhZnQtaWV0Zi1hdnRjb3JlLTYy MjJiaXNAdG9vbHMuaWV0Zi5vcmciPmRyYWZ0LWlldGYtYXZ0Y29yZS02MjIyYmlzQHRvb2xzLmll dGYub3JnPC9hPiZndDs8YnI+DQo8c3BhbiBzdHlsZT0iZm9udC13ZWlnaHQ6Ym9sZCI+U3ViamVj dDogPC9zcGFuPltBVlRDT1JFXSBSZXZpZXcgb2YgZHJhZnQtaWV0Zi1hdnRjb3JlLTYyMjJiaXM8 YnI+DQo8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8YmxvY2txdW90ZSBpZD0iTUFDX09VVExP T0tfQVRUUklCVVRJT05fQkxPQ0tRVU9URSIgc3R5bGU9IkJPUkRFUi1MRUZUOiAjYjVjNGRmIDUg c29saWQ7IFBBRERJTkc6MCAwIDAgNTsgTUFSR0lOOjAgMCAwIDU7Ij4NCjxkaXY+DQo8bWV0YSBu YW1lPSJHZW5lcmF0b3IiIGNvbnRlbnQ9Ik1pY3Jvc29mdCBFeGNoYW5nZSBTZXJ2ZXIiPg0KPCEt LSBjb252ZXJ0ZWQgZnJvbSBydGYgLS0+PHN0eWxlPjwhLS0gLkVtYWlsUXVvdGUgeyBtYXJnaW4t bGVmdDogMXB0OyBwYWRkaW5nLWxlZnQ6IDRwdDsgYm9yZGVyLWxlZnQ6ICM4MDAwMDAgMnB4IHNv bGlkOyB9IC0tPjwvc3R5bGU+DQo8ZGl2Pjxmb250IGZhY2U9IkNhbGlicmkiIHNpemU9IjIiPjxz cGFuIHN0eWxlPSJmb250LXNpemU6MTFwdDsiPg0KPGRpdj5IaSBhbGwsPC9kaXY+DQo8ZGl2PiZu YnNwOzwvZGl2Pg0KPGRpdj5J4oCZdmUgcmV2aWV3ZWQgZHJhZnQtaWV0Zi1hdnRjb3JlLTYyMjJi aXMuIDwvZGl2Pg0KPGRpdj4mbmJzcDs8L2Rpdj4NCjwvc3Bhbj48L2ZvbnQ+PC9kaXY+DQo8L2Rp dj4NCjwvYmxvY2txdW90ZT4NCjwvc3Bhbj4NCjxkaXY+VGhhbmtzLjwvZGl2Pg0KPGRpdj48YnI+ DQo8L2Rpdj4NCjxzcGFuIGlkPSJPTEtfU1JDX0JPRFlfU0VDVElPTiI+DQo8YmxvY2txdW90ZSBp ZD0iTUFDX09VVExPT0tfQVRUUklCVVRJT05fQkxPQ0tRVU9URSIgc3R5bGU9IkJPUkRFUi1MRUZU OiAjYjVjNGRmIDUgc29saWQ7IFBBRERJTkc6MCAwIDAgNTsgTUFSR0lOOjAgMCAwIDU7Ij4NCjxk aXY+DQo8ZGl2Pjxmb250IGZhY2U9IkNhbGlicmkiIHNpemU9IjIiPjxzcGFuIHN0eWxlPSJmb250 LXNpemU6MTFwdDsiPg0KPGRpdj5J4oCZdmUgZ290IHR3byBzbWFsbCBjb21tZW50cy9xdWVzdGlv bnMuIEnigJl2ZSBub3QgZm9sbG93ZWQgYWxsIGRpc2N1c3Npb24gb24gdGhpcyBkcmFmdCwgc28g bXkgY29tbWVudHMgbWlnaHQgaGF2ZSBiZWVuIGRpc2N1c3NlZCBlYXJsaWVyLjwvZGl2Pg0KPGRp dj4mbmJzcDs8L2Rpdj4NCjxkaXY+LSBTZWN0aW9uIDEgaW5jbHVkZXMgYSByZWZlcmVuY2UgdG8g SS1ELnJlc2NvcmxhLWF2dGNvcmUtcmFuZG9tLWNuYW1lLiBXaGF0IGlzIHRoZSBuYXR1cmUgYW5k IGludGVuZGVkIHN0YXR1cyBvZiB0aGlzIGRyYWZ0PyBJcyBpdCBtZWFudCB0byBiZSB1cGRhdGVk IGluIHRoZSBmdXR1cmUgKHRoZSBsYXRlc3QgdmVyc2lvbiBleHBpcmVkIGEgY291cGxlIG9mIG1v bnRocyBhZ28pPyBJZiBub3QsIGlzIGl0IG5lY2Vzc2FyeSB0byBpbmNsdWRlDQogaXQgaGVyZSBm b3IgcmVmZXJlbmNlIG9yIGNhbiBpdCBiZSByZW1vdmVkPzwvZGl2Pg0KPC9zcGFuPjwvZm9udD48 L2Rpdj4NCjwvZGl2Pg0KPC9ibG9ja3F1b3RlPg0KPC9zcGFuPg0KPGRpdj48YnI+DQo8L2Rpdj4N CjxkaXY+VGhhdCBkcmFmdCB3aWxsIGxpa2VseSBleHBpcmUgYW5kIG5vdCBiZSBwdWJsaXNoZWQu IFRoYXQgZHJhZnQgbW90aXZhdGVkIHRoZSBuZWVkIGZvciB0aGUgYmlzIGRvY3VtZW50ICh0aGUg bGlua2FiaWxpdHkgb2Ygb3V0cHV0cyByZXN1bHRpbmcgZnJvbSB0aGUgYWxnb3JpdGhtcyBpbiA2 MjIyKS4mbmJzcDs8L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8c3BhbiBpZD0iT0xLX1NSQ19C T0RZX1NFQ1RJT04iPg0KPGJsb2NrcXVvdGUgaWQ9Ik1BQ19PVVRMT09LX0FUVFJJQlVUSU9OX0JM T0NLUVVPVEUiIHN0eWxlPSJCT1JERVItTEVGVDogI2I1YzRkZiA1IHNvbGlkOyBQQURESU5HOjAg MCAwIDU7IE1BUkdJTjowIDAgMCA1OyI+DQo8ZGl2Pg0KPGRpdj48Zm9udCBmYWNlPSJDYWxpYnJp IiBzaXplPSIyIj48c3BhbiBzdHlsZT0iZm9udC1zaXplOjExcHQ7Ij4NCjxkaXY+LSBTZWN0aW9u IDMgZGVzY3JpYmVzIHRoZSBkZWZpY2llbmNpZXMgd2l0aCB0aGUgZ2VuZXJhdGlvbiBvZiBDTkFN RXMgaW4gUkZDMzU1MCwgaXQgZG9lcyBub3QgZGVzY3JpYmUgdGhlIGRlZmljaWVuY2llcyBpbiBS RkM2MjIyICh3aGlsZSB0aGUgcHJvYmxlbXMgd2l0aCBSRkM2MjIyIGFyZSBoaW50ZWQgYXQgaW4g Ym90aCB0aGUgaW50cm9kdWN0aW9uIGFuZCBhYnN0cmFjdCkuIElzIHRoaXMgaW50ZW50aW9uYWwg ZHVlIHRvIHRoZSBmYWN0DQogdGhhdCB0aGlzIGRyYWZ0IG9ic29sZXRlcyBSRkM2MjIyIGFuZCB0 aGF0IGRvY3VtZW50IGNhbiB0aHVzIGJlIGNvbnNpZGVyZWQgaW5mb3JtYXRpdmUgZm9yIHRoZSBw dXJwb3NlcyBvZiB0aGlzIGRyYWZ0PzwvZGl2Pg0KPC9zcGFuPjwvZm9udD48L2Rpdj4NCjwvZGl2 Pg0KPC9ibG9ja3F1b3RlPg0KPC9zcGFuPg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+Q29ycmVj dC48L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8c3BhbiBpZD0iT0xLX1NSQ19CT0RZX1NFQ1RJ T04iPg0KPGJsb2NrcXVvdGUgaWQ9Ik1BQ19PVVRMT09LX0FUVFJJQlVUSU9OX0JMT0NLUVVPVEUi IHN0eWxlPSJCT1JERVItTEVGVDogI2I1YzRkZiA1IHNvbGlkOyBQQURESU5HOjAgMCAwIDU7IE1B UkdJTjowIDAgMCA1OyI+DQo8Zm9udCBmYWNlPSJDYWxpYnJpIiBzaXplPSIyIj48c3BhbiBzdHls ZT0iZm9udC1zaXplOjExcHQ7Ij4NCjxkaXY+PC9kaXY+DQo8ZGl2PiZuYnNwOzxzcGFuIHN0eWxl PSJmb250LXNpemU6IDExcHQ7ICI+QXBhcnQgZnJvbSB0aGVzZSBtaW5vciBjb21tZW50cywgSSBj b25zaWRlciB0aGUgZHJhZnQgdG8gYmUgcmVhZHkgZm9yIHB1YmxpY2F0aW9uLjwvc3Bhbj48L2Rp dj4NCjxkaXY+Jm5ic3A7PC9kaXY+DQo8L3NwYW4+PC9mb250PjwvYmxvY2txdW90ZT4NCjwvc3Bh bj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8ZGl2PlRoYW5rcy48L2Rpdj4NCjxkaXY+LWFjYmVnZW48 L2Rpdj4NCjxkaXY+PGJyPg0KPC9kaXY+DQo8c3BhbiBpZD0iT0xLX1NSQ19CT0RZX1NFQ1RJT04i Pg0KPGJsb2NrcXVvdGUgaWQ9Ik1BQ19PVVRMT09LX0FUVFJJQlVUSU9OX0JMT0NLUVVPVEUiIHN0 eWxlPSJCT1JERVItTEVGVDogI2I1YzRkZiA1IHNvbGlkOyBQQURESU5HOjAgMCAwIDU7IE1BUkdJ TjowIDAgMCA1OyI+DQo8Zm9udCBmYWNlPSJDYWxpYnJpIiBzaXplPSIyIj48c3BhbiBzdHlsZT0i Zm9udC1zaXplOjExcHQ7Ij4NCjxkaXY+QmVzdCByZWdhcmRzLDwvZGl2Pg0KPGRpdj4mbmJzcDs8 L2Rpdj4NCjxkaXY+UmF5PC9kaXY+DQo8ZGl2PiZuYnNwOzwvZGl2Pg0KPGRpdj4mbmJzcDs8L2Rp dj4NCjwvc3Bhbj48L2ZvbnQ+DQo8cD5UaGlzIGUtbWFpbCBhbmQgaXRzIGNvbnRlbnRzIGFyZSBz dWJqZWN0IHRvIHRoZSBESVNDTEFJTUVSIGF0IDxhIGhyZWY9Imh0dHA6Ly93d3cudG5vLm5sL2Vt YWlsZGlzY2xhaW1lciI+DQpodHRwOi8vd3d3LnRuby5ubC9lbWFpbGRpc2NsYWltZXI8L2E+PC9w Pg0KPC9ibG9ja3F1b3RlPg0KPC9zcGFuPg0KPGRpdj48YnI+DQo8L2Rpdj4NCjxkaXY+PGJyPg0K PC9kaXY+DQo8L2JvZHk+DQo8L2h0bWw+DQo= --_000_C15918F2FCDA0243A7C919DA7C4BE9940CFCE8D2xmbalnx01ciscoc_-- From abegen@cisco.com Thu Apr 11 00:57:17 2013 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 13BE421F8A11 for ; Thu, 11 Apr 2013 00:57:17 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XUn9usFM3t2P for ; Thu, 11 Apr 2013 00:57:16 -0700 (PDT) Received: from rcdn-iport-4.cisco.com (rcdn-iport-4.cisco.com [173.37.86.75]) by ietfa.amsl.com (Postfix) with ESMTP id 8475321F8A3F for ; Thu, 11 Apr 2013 00:57:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=1750; q=dns/txt; s=iport; t=1365667036; x=1366876636; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=v41ovsnJcIBMtZ0xUnCgARMMDZAiduYr3LZGitBN52c=; b=Q6AM9fBk5Mm03WBdIFsVbRUV40KGc3jAjQPhBbdzqnh0LAheQwJLdMm8 JuNz1dSJV1ikxeTz1ZM8nshIdQmYIq4BxbTxGGoX1iWqzra2X6BaKZRPY CXzt8BOuDZuhCCGtxGBqIwLUd4vAfBGXF1rctNCH3LhfYZVs4A8XNAsSb k=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AisFACpsZlGtJV2d/2dsb2JhbABQgmUhNoMuvh0NdBZ0gh8BAQEEAQEBIBFRBgEIEQMBAgMCBiACBB8GCxUICAIEARIIh3oDDwELq32JFA2JWQSBI4sggiI4BoIoMmEDlR2NVYUcgwuCKA X-IronPort-AV: E=Sophos;i="4.87,454,1363132800"; d="scan'208";a="197581063" Received: from rcdn-core-6.cisco.com ([173.37.93.157]) by rcdn-iport-4.cisco.com with ESMTP; 11 Apr 2013 07:57:16 +0000 Received: from xhc-aln-x08.cisco.com (xhc-aln-x08.cisco.com [173.36.12.82]) by rcdn-core-6.cisco.com (8.14.5/8.14.5) with ESMTP id r3B7vFjX001091 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 11 Apr 2013 07:57:15 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-aln-x08.cisco.com ([173.36.12.82]) with mapi id 14.02.0318.004; Thu, 11 Apr 2013 02:57:15 -0500 From: "Ali C. Begen (abegen)" To: Martin Thomson , "avt@ietf.org" , Magnus Westerlund Thread-Topic: [AVTCORE] 6222bis Thread-Index: AQHONhK9dPjRYaN1akKsO2TMTANSO5jRLlOA Date: Thu, 11 Apr 2013 07:55:52 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.2.130206 x-originating-ip: [10.61.98.223] Content-Type: text/plain; charset="utf-8" Content-ID: <35E6FAF79FDFE04AA5A459AA0126187B@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: Re: [AVTCORE] 6222bis X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Apr 2013 07:57:17 -0000 LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IE1hcnRpbiBUaG9tc29uIDxtYXJ0aW4u dGhvbXNvbkBnbWFpbC5jb20+DQpEYXRlOiBXZWRuZXNkYXksIEFwcmlsIDEwLCAyMDEzIDg6NDIg UE0NClRvOiAiYXZ0QGlldGYub3JnIiA8YXZ0QGlldGYub3JnPiwgTWFnbnVzIFdlc3Rlcmx1bmQN CjxtYWdudXMud2VzdGVybHVuZEBlcmljc3Nvbi5jb20+DQpTdWJqZWN0OiBbQVZUQ09SRV0gNjIy MmJpcw0KDQo+QXMgcmVxdWVzdGVkIG9mIFJUQ1dFQiwgSSBoYXZlIHJlYWQgdGhpcyBkb2N1bWVu dC4gIEl0IGlzIGdvb2QgYW5kDQo+c2hvdWxkIGJlIHB1Ymxpc2hlZC4NCj4NCj5JIHN1c3BlY3Qg dGhhdCBtYW55IHBlb3BsZSBmaW5kIGl0IGhhcmQgdG8gZ2V0IGV4Y2l0ZWQgZW5vdWdoIGFib3V0 DQo+dGhpcyB0byBib3RoZXIgcmVhZGluZyBpdC4gIEl0J3MganVzdCBub3QgdGhhdCBpbnRlcmVz dGluZyBhIHN1YmplY3QuDQo+RXNwZWNpYWxseSBzaW5jZSB0aGlzIGlzIGVudGlyZWx5IG5vbi1j b250cm92ZXJzaWFsLg0KDQpDb21wYXJlZCB0byBydGN3ZWIgc3R1ZmYsIHllYWguDQo+DQo+SSBm ZWVsIGEgbGl0dGxlIHVuY29tZm9ydGFibGUgdGhhdCB0aGUgZG9jdW1lbnQganVzdGlmaWVzIGl0 cw0KPmV4aXN0ZW5jZSAoYXMgYSAtYmlzKSBsYXJnZWx5IGJhc2VkIG9uIGEgcmVmZXJlbmNlIHRv IGFuIGluZGl2aWR1YWwNCj5kcmFmdC4gIEkgd291bGQgcHJlZmVyIHRvIHNlZSB0aGUgcmF0aW9u YWxlIHByZXNlbnRlZCBpbiBhbiBhcHBlbmRpeA0KPmluc3RlYWQ7IGl0J3MgZmFpcmx5IGltcG9y dGFudCBpbmZvcm1hdGlvbiB0byByZXRhaW4uDQoNCklmIHlvdSByZWFsbHkgZmVlbCBzdHJvbmcg YWJvdXQgaXQsIHdlIGNhbiBjb25zaWRlciBpdCBidXQgdGhlIGN1cnJlbnQNCmRyYWZ0IG1lbnRp b25zIHdoeSB3ZSBhcmUgZG9pbmcgdGhpcyBiaXMgKGR1ZSB0byB0aGUgbGlua2FiaWxpdHkgb2Yg dGhlDQpDTkFNRXMgcmVzdWx0aW5nIGZyb20gNjIyMiBhbGdvcml0aG1zKS4gRm9yIHRoZSBwdXJw b3NlIG9mIDYyMjJiaXMsIHdoZXJlDQp0aGF0IGxpbmthYmlsaXR5IGNvbWVzIGZyb20gaXMgbm90 IHJlYWxseSBlc3NlbnRpYWwgSU1PLg0KDQotYWNiZWdlbg0KDQo+X19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj5BdWRpby9WaWRlbyBUcmFuc3BvcnQgQ29y ZSBNYWludGVuYW5jZQ0KPmF2dEBpZXRmLm9yZw0KPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxt YW4vbGlzdGluZm8vYXZ0DQo+DQoNCg0K From ron.even.tlv@gmail.com Thu Apr 11 02:27:30 2013 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F2BB721F8AF0 for ; Thu, 11 Apr 2013 02:27:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.171 X-Spam-Level: X-Spam-Status: No, score=0.171 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, DOS_OUTLOOK_TO_MX=1, FH_HOST_EQ_D_D_D_D=0.765, RCVD_IN_PBL=0.905, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XgvAnzKflJBw for ; Thu, 11 Apr 2013 02:27:29 -0700 (PDT) Received: from mail-ea0-x22f.google.com (mail-ea0-x22f.google.com [IPv6:2a00:1450:4013:c01::22f]) by ietfa.amsl.com (Postfix) with ESMTP id 3642F21F8A52 for ; Thu, 11 Apr 2013 02:27:28 -0700 (PDT) Received: by mail-ea0-f175.google.com with SMTP id r16so626530ead.6 for ; Thu, 11 Apr 2013 02:27:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:from:to:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:x-mailer :thread-index:content-language; bh=eTtCjaPAeKOPM4XxJiDqkEJgaHFaZJkjSfRE5xINOSY=; b=Kxx9p6ldYBfFd9Ml00E6Rfpqgr7NKwUs/IbiZoOKLlQYwRPaVeCg2o6E6CHXo5GMwC JeiKLTnRbAwwkKzL97jZ1J9As6lapFn9dvW/Ko0xfl/DXyBu3UetifQgwOhIdx+HHnz4 EmbgMoRUCS8rbp3MakzNGa1LjulpCiNXDfr6Pa1VS4FjFRTJIKZqbz6WC/dLj7AuHJSb BVjMEXNer6hrL3YbphgWi1G5T4+iL4Kb0aG9ZyBSc5XWYNhqiG5OUahAI+bXtVMigjcV Y65q91RlOcj54FGwt8ctirG8U+/r6Etl6s/Iv3AwDYztYWSV64NQ+C0rli+1PoRCsy4Q K7dQ== X-Received: by 10.15.101.200 with SMTP id bp48mr14973086eeb.38.1365672447958; Thu, 11 Apr 2013 02:27:27 -0700 (PDT) Received: from RoniE (bzq-79-181-177-28.red.bezeqint.net. [79.181.177.28]) by mx.google.com with ESMTPS id u44sm4553917eel.7.2013.04.11.02.27.24 (version=TLSv1 cipher=RC4-SHA bits=128/128); Thu, 11 Apr 2013 02:27:26 -0700 (PDT) From: "Roni Even" To: "'Magnus Westerlund'" , References: <513F7C5B.5060101@ericsson.com> <51541502.90406@ericsson.com> In-Reply-To: <51541502.90406@ericsson.com> Date: Thu, 11 Apr 2013 12:26:55 +0300 Message-ID: <003701ce3696$b769ed90$263dc8b0$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQK9Lh6Y4AO1WsBn45nDpAqNFASGbAKXsiRhlt4PavA= Content-Language: en-us Subject: Re: [AVTCORE] Reminder: Re: WG last call on draft-ietf-avtcore-6222bis-01 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Apr 2013 09:27:30 -0000 Hi, Sorry for being late. I read the draft and in general it looks OK. Two comments: 1. I think that the folowing text in section 5 "The algorithm described below is intended to be used for locally generated unique identifiers. = It is based on simply generating a cryptographically pseudorandom value [RFC4086]. This value MUST be at least 96 bits but MAY be longer." Is = a bit confusing since I expected to algorithm and not a reference (the = first sentence is from RFC6222). Maybe explain that the algorithm is in = RFC4086, and maybe point to it. 2. PRNG is not expanded anywhere in the document Roni Even -----Original Message----- From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of = Magnus Westerlund Sent: 28 March, 2013 12:02 PM To: avt@ietf.org Subject: [AVTCORE] Reminder: Re: WG last call on draft-ietf-avtcore-6222bis-01 WG, So far there has be no other reviews of this document than mine. Can someone please review this document? I hereby extended the WG last call with one week until the 7th of April. Cheers Magnus On 2013-03-12 20:04, Magnus Westerlund wrote: > WG, >=20 > This is to announce the start of a WG last call on: >=20 > Guidelines for Choosing RTP Control Protocol (RTCP) Canonical Names > (CNAMEs) to be published as a proposed standard. >=20 > Document can be retrieved here: > https://datatracker.ietf.org/doc/draft-ietf-avtcore-6222bis/ >=20 > Please provide any feedback by the 31st of March. >=20 > Regards >=20 > Magnus Westerlund > WG chair >=20 >=20 > ---------------------------------------------------------------------- > Multimedia Technologies, Ericsson Research EAB/TVM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > F=E4r=F6gatan 6 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- >=20 > _______________________________________________ > Audio/Video Transport Core Maintenance avt@ietf.org=20 > https://www.ietf.org/mailman/listinfo/avt >=20 >=20 --=20 Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 F=E4r=F6gatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- _______________________________________________ Audio/Video Transport Core Maintenance avt@ietf.org https://www.ietf.org/mailman/listinfo/avt From bill.wu@huawei.com Thu Apr 11 04:04:32 2013 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2A08B21F85C6 for ; Thu, 11 Apr 2013 04:04:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.449 X-Spam-Level: X-Spam-Status: No, score=-3.449 tagged_above=-999 required=5 tests=[AWL=2.698, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, SARE_SUB_ENC_UTF8=0.152] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id n3cj6XYuGEAl for ; Thu, 11 Apr 2013 04:04:31 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id E019B21F8B13 for ; Thu, 11 Apr 2013 04:04:30 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AQH07243; Thu, 11 Apr 2013 11:04:28 +0000 (GMT) Received: from LHREML401-HUB.china.huawei.com (10.201.5.240) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.7; Thu, 11 Apr 2013 12:03:51 +0100 Received: from NKGEML401-HUB.china.huawei.com (10.98.56.32) by lhreml401-hub.china.huawei.com (10.201.5.240) with Microsoft SMTP Server (TLS) id 14.1.323.7; Thu, 11 Apr 2013 12:04:23 +0100 Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.126]) by nkgeml401-hub.china.huawei.com ([10.98.56.32]) with mapi id 14.01.0323.007; Thu, 11 Apr 2013 19:04:16 +0800 From: Qin Wu To: "avt@ietf.org" Thread-Topic: [AVTCORE] Reminder: Re: WG last call on draft-ietf-avtcore-6222bis-01 Thread-Index: AQHOK5tVSI3maVluv0G7TNDoaLI+HpjOpPWAgAJH91A= Date: Thu, 11 Apr 2013 11:04:14 +0000 Message-ID: References: <513F7C5B.5060101@ericsson.com> <51541502.90406@ericsson.com> <51651B91.1010303@ericsson.com> In-Reply-To: <51651B91.1010303@ericsson.com> Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.138.41.149] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: [AVTCORE] =?utf-8?b?562U5aSNOiAgUmVtaW5kZXI6IFJlOiBXRyBsYXN0IGNh?= =?utf-8?q?ll_on=09draft-ietf-avtcore-6222bis-01?= X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Apr 2013 11:04:32 -0000 SGksIEFsaToNCkhlcmUgaXMgbXkgcXVpY2sgcmV2aWV3IHRvIGRyYWZ0LWlldGYtYXZ0Y29yZS02 MjIyYmlzLTAxOg0KMS4gU2VjdGlvbiAxIGFuZCBTZWN0aW9uIDM6DQpJdCBpcyBub3QgY2xlYXIg aG93IHRoZSBzZWN0aW9uIDEgaXMgcmVsYXRlZCB0byBzZWN0aW9uIDM/DQpJcyB0aGlzIGRyYWZ0 IGZvY3VzaW5nIG9uIHRhY2tpbmcgbGlua2FiaWxpdHkgaXNzdWUgb3IgZGVmaWNpZW5jeSBpc3N1 ZXMgZGVzY3JpYmVkIGluIHNlY3Rpb24gMz8gDQpXaGF0IHRoZSBsaW5rYWJpbGl0eSBpc3N1ZSBp cz8gSXQgaXMgbm90IG9idmlvdXMgdG8gYSByZWFkZXIgd2hvIGFyZSBub3QgZmFtaWxpYXIgd2l0 aCB0aGlzIGFsdGhvdWdoIHRoaXMgZHJhZnQgcG9pbnQgdG8gDQpbSS1ELnJlc2NvcmxhLWF2dGNv cmUtcmFuZG9tLWNuYW1lXSBpbiB0aGUgc2VjdGlvbiAxPw0KDQoyLiBQUk5HIG5lZWRzIHRvIGJl IGV4cGFuZGVkIG9yIHBvaW50IHRvIGEgcmVmZXJlbmNlLg0KDQozLiBTZWN0aW9uIDYuMQ0KVGhl IGxhc3Qgc2VudGVuY2Ugc2FpZDoNCiINCkEgbGVuZ3RoIG9mIDk2IGJpdHMgYWxsb3dzIG9uIHRo ZSBvcmRlciBvZg0KMl57NDB9IFJUQ1AgQ05BTUVzIGdsb2JhbGx5IGJlZm9yZSB0aGVyZSBpcyBh IGxhcmdlIGNoYW5jZSBvZg0KY29sbGlzaW9uICh0aGVyZSBpcyBhYm91dCBhIDUwJSBjaGFuY2Ug b2Ygb25lIGNvbGxpc2lvbiBhZnRlciAyXns0OH0NClJUQ1AgQ05BTUVzKS4NCiINCkkgYW0gZGlm ZmljdWx0IHRvIHVuZGVyc3RhbmQgdGhlIHJhdGlvbmFsZSBmb3IgdGhpcyBjYWxjdWxhdGlvbiBz aW5jZSBJIGRvbid0IGtub3cgV2hhdCAiMl57NDB9IiBzdGFuZCBmb3I/DQpIb3cgIjQwIiBpcyBy ZWxhdGVkIHRvIHRoZSBsZW5ndGggb2YgOTYgYml0cz8NCg0KNC42LjINCkkgY2FuIHVuZGVyc3Rh bmQgdGhlIGZpcnN0IHNlbnRlbmNlLCBidXQgSSBkb24ndCB1bmRlcnN0YW5kIHRoZSBzZWNvbmQg b25lLiANCldoYXQga2luZCBvZiBjb3JyZWxhdGlvbiBuZWVkIHRvIGJlIHByZXZlbnRlZD8gV2h5 IHN1Y2ggY29ycmVsYXRpb24gc2hvdWxkIGJlIHByZXZlbnRlZD8NCklzbid0IHRoaXMgc2VjdGlv biBmb2N1c2luZyBvbiB0YWxraW5nIGFib3V0IGhvdyB0byBjb3JyZWxhdGUgc2Vzc2lvbnM/IFdo YXQgYW0gSSBtaXNzaW5nPw0KDQpSZWdhcmRzIQ0KLVFpbg0KLS0tLS3pgq7ku7bljp/ku7YtLS0t LQ0K5Y+R5Lu25Lq6OiBhdnQtYm91bmNlc0BpZXRmLm9yZyBbbWFpbHRvOmF2dC1ib3VuY2VzQGll dGYub3JnXSDku6PooaggTWFnbnVzIFdlc3Rlcmx1bmQNCuWPkemAgeaXtumXtDogMjAxM+W5tDTm nIgxMOaXpSAxNTo1OA0K5pS25Lu25Lq6OiBNYWdudXMgV2VzdGVybHVuZA0K5oqE6YCBOiBhdnRA aWV0Zi5vcmcNCuS4u+mimDogUmU6IFtBVlRDT1JFXSBSZW1pbmRlcjogUmU6IFdHIGxhc3QgY2Fs bCBvbiBkcmFmdC1pZXRmLWF2dGNvcmUtNjIyMmJpcy0wMQ0KDQpXRywNCg0KVGhpcyBXRyBsYXN0 IGNhbGwgaGFzIGNvbmNsdWRlZC4gSSB0aGluayB0aGUgbGV2ZWwgb2YgcmV2aWV3cyBvbiB0aGlz DQpkb2N1bWVudCBhcmUgdmVyeSBsb3cuIEluIHRoZSB3b3JraW5nIGdyb3VwIGxhc3QgY2FsbCBv bmx5IEtldmluIEdyb3NzDQphbmQgSSBoYXZlIHN0YXRlZCB0aGF0IHRoZXkgaGF2ZSByZXZpZXdl ZCB0aGUgbGF0ZXN0IHZlcnNpb24uDQoNCkF1dGhvcnMgcGxlYXNlIGFkZHJlc3MgcmFpc2VkIGlz c3Vlcy4NCg0KSSB3aWxsIG5vdCBjb25zaWRlciB0aGlzIGEgc3VjY2Vzc2Z1bCBXRyBsYXN0IGNh bGwgdW5sZXNzIGF0IGxlYXN0IG9uZQ0KYWRkaXRpb25hbCBwZXJzb24gcmV2aWV3cyBpdCB3aG8g YXJlIG5vdCBhbiBhdXRob3IuIEl0IGlzIGEgdmVyeSBzaG9ydA0KZG9jdW1lbnQgYW5kIGl0IGFs c28gZG9uJ3QgcmVxdWlyZSBtYXNzaXZlIGFtb3VudHMgb2YgYWRkaXRpb25hbA0Ka25vd2xlZGdl IGJleW9uZCBiYXNpYyBSVFAgdW5kZXJzdGFuZGluZyB0byByZXZpZXcuDQoNClJlZ2FyZHMNCg0K TWFnbnVzIFdlc3Rlcmx1bmQNCldHIGNoYWlyDQoNCk9uIDIwMTMtMDMtMjggMTE6MDEsIE1hZ251 cyBXZXN0ZXJsdW5kIHdyb3RlOg0KPiBXRywNCj4gDQo+IFNvIGZhciB0aGVyZSBoYXMgYmUgbm8g b3RoZXIgcmV2aWV3cyBvZiB0aGlzIGRvY3VtZW50IHRoYW4gbWluZS4NCj4gDQo+IENhbiBzb21l b25lIHBsZWFzZSByZXZpZXcgdGhpcyBkb2N1bWVudD8NCj4gDQo+IEkgaGVyZWJ5IGV4dGVuZGVk IHRoZSBXRyBsYXN0IGNhbGwgd2l0aCBvbmUgd2VlayB1bnRpbCB0aGUgN3RoIG9mIEFwcmlsLg0K PiANCj4gQ2hlZXJzDQo+IA0KPiBNYWdudXMNCj4gDQo+IE9uIDIwMTMtMDMtMTIgMjA6MDQsIE1h Z251cyBXZXN0ZXJsdW5kIHdyb3RlOg0KPj4gV0csDQo+Pg0KPj4gVGhpcyBpcyB0byBhbm5vdW5j ZSB0aGUgc3RhcnQgb2YgYSBXRyBsYXN0IGNhbGwgb246DQo+Pg0KPj4gR3VpZGVsaW5lcyBmb3Ig Q2hvb3NpbmcgUlRQIENvbnRyb2wgUHJvdG9jb2wgKFJUQ1ApIENhbm9uaWNhbCBOYW1lcw0KPj4g KENOQU1FcykgdG8gYmUgcHVibGlzaGVkIGFzIGEgcHJvcG9zZWQgc3RhbmRhcmQuDQo+Pg0KPj4g RG9jdW1lbnQgY2FuIGJlIHJldHJpZXZlZCBoZXJlOg0KPj4gaHR0cHM6Ly9kYXRhdHJhY2tlci5p ZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1hdnRjb3JlLTYyMjJiaXMvDQo+Pg0KPj4gUGxlYXNlIHBy b3ZpZGUgYW55IGZlZWRiYWNrIGJ5IHRoZSAzMXN0IG9mIE1hcmNoLg0KPj4NCj4+IFJlZ2FyZHMN Cj4+DQo+PiBNYWdudXMgV2VzdGVybHVuZA0KPj4gV0cgY2hhaXINCj4+DQo+Pg0KPj4gLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLQ0KPj4gTXVsdGltZWRpYSBUZWNobm9sb2dpZXMsIEVyaWNzc29uIFJlc2VhcmNoIEVB Qi9UVk0NCj4+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4+IEVyaWNzc29uIEFCICAgICAgICAgICAgICAgIHwg UGhvbmUgICs0NiAxMCA3MTQ4Mjg3DQo+PiBGw6Ryw7ZnYXRhbiA2ICAgICAgICAgICAgICAgIHwg TW9iaWxlICs0NiA3MyAwOTQ5MDc5DQo+PiBTRS0xNjQgODAgU3RvY2tob2xtLCBTd2VkZW58IG1h aWx0bzogbWFnbnVzLndlc3Rlcmx1bmRAZXJpY3Nzb24uY29tDQo+PiAtLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+ Pg0KPj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+ IEF1ZGlvL1ZpZGVvIFRyYW5zcG9ydCBDb3JlIE1haW50ZW5hbmNlDQo+PiBhdnRAaWV0Zi5vcmcN Cj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vYXZ0DQo+Pg0KPj4NCj4g DQo+IA0KDQoNCi0tIA0KDQpNYWdudXMgV2VzdGVybHVuZA0KDQotLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQpNdWx0 aW1lZGlhIFRlY2hub2xvZ2llcywgRXJpY3Nzb24gUmVzZWFyY2ggRUFCL1RWTQ0KLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLQ0KRXJpY3Nzb24gQUIgICAgICAgICAgICAgICAgfCBQaG9uZSAgKzQ2IDEwIDcxNDgyODcN CkbDpHLDtmdhdGFuIDYgICAgICAgICAgICAgICAgfCBNb2JpbGUgKzQ2IDczIDA5NDkwNzkNClNF LTE2NCA4MCBTdG9ja2hvbG0sIFN3ZWRlbnwgbWFpbHRvOiBtYWdudXMud2VzdGVybHVuZEBlcmlj c3Nvbi5jb20NCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0KX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX18NCkF1ZGlvL1ZpZGVvIFRyYW5zcG9ydCBDb3JlIE1haW50ZW5hbmNl DQphdnRAaWV0Zi5vcmcNCmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vYXZ0 DQo= From abegen@cisco.com Thu Apr 11 04:45:00 2013 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DFAD321F8610 for ; Thu, 11 Apr 2013 04:45:00 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sihQppvF0rXt for ; Thu, 11 Apr 2013 04:45:00 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id CD0AB21F8606 for ; Thu, 11 Apr 2013 04:44:59 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=5382; q=dns/txt; s=iport; t=1365680700; x=1366890300; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=IfOGmctkWqPwFxcPAk/z/RZ0EQ4T5hgdi8O6bURJXQY=; b=iUKcH2QK+Hrqr+FAkqg62TmwKzYTAGdufI8PQK6WWlCH0ELY2nu2bUg+ 7W42D8/b8klEXNf2FdTwB6GZvnp/FzYuE86Y9f7ehxz0Xb/aMzEIZitZz CAEcPBtupy0XX00YI6Jv1b7J9BG515UsPvD6+3rzI8R/bT3CCMjLiaFnM c=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjUFAEehZlGtJXG//2dsb2JhbABQgmUhNoJUWr4dDXcWdIIfAQEBBAEBAQkXEVECBAEGAg4DAwEBAQECAgYdAwIEGQYGCxQBCAgCBAESCId6Aw8BC49zmwSJFA2JWQQEgR+LIIIiFhASBoIoMmEDlR2NVYUcgwuCKA X-IronPort-AV: E=Sophos;i="4.87,454,1363132800"; d="scan'208";a="197552288" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-8.cisco.com with ESMTP; 11 Apr 2013 11:44:59 +0000 Received: from xhc-aln-x03.cisco.com (xhc-aln-x03.cisco.com [173.36.12.77]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id r3BBix2T032149 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 11 Apr 2013 11:44:59 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-aln-x03.cisco.com ([173.36.12.77]) with mapi id 14.02.0318.004; Thu, 11 Apr 2013 06:44:58 -0500 From: "Ali C. Begen (abegen)" To: Roni Even , "'Magnus Westerlund'" , "avt@ietf.org" Thread-Topic: [AVTCORE] Reminder: Re: WG last call on draft-ietf-avtcore-6222bis-01 Thread-Index: AQHONqn9MrH0dStZlE2LDoR1j6alrQ== Date: Thu, 11 Apr 2013 11:43:35 +0000 Message-ID: In-Reply-To: <003701ce3696$b769ed90$263dc8b0$@gmail.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.2.130206 x-originating-ip: [10.61.98.193] Content-Type: text/plain; charset="utf-8" Content-ID: <9AD412EEBE18C4498568A248FD2BC416@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: Re: [AVTCORE] Reminder: Re: WG last call on draft-ietf-avtcore-6222bis-01 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Apr 2013 11:45:01 -0000 LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IFJvbmkgRXZlbiA8cm9uLmV2ZW4udGx2 QGdtYWlsLmNvbT4NCkRhdGU6IFRodXJzZGF5LCBBcHJpbCAxMSwgMjAxMyAxMjoyNiBQTQ0KVG86 IE1hZ251cyBXZXN0ZXJsdW5kIDxtYWdudXMud2VzdGVybHVuZEBlcmljc3Nvbi5jb20+LCAiYXZ0 QGlldGYub3JnIg0KPGF2dEBpZXRmLm9yZz4NClN1YmplY3Q6IFJlOiBbQVZUQ09SRV0gUmVtaW5k ZXI6IFJlOiBXRyBsYXN0DQpjYWxsCW9uCWRyYWZ0LWlldGYtYXZ0Y29yZS02MjIyYmlzLTAxDQoN Cj5IaSwNCj5Tb3JyeSBmb3IgYmVpbmcgbGF0ZS4NCj5JIHJlYWQgdGhlIGRyYWZ0IGFuZCBpbiBn ZW5lcmFsIGl0IGxvb2tzIE9LLg0KDQpUaGFua3MuDQoNCj5Ud28gY29tbWVudHM6DQo+DQo+MS4g SSB0aGluayB0aGF0IHRoZSBmb2xvd2luZyB0ZXh0IGluIHNlY3Rpb24gNSAgIlRoZSBhbGdvcml0 aG0gZGVzY3JpYmVkDQo+YmVsb3cgaXMgaW50ZW5kZWQgdG8gYmUgdXNlZCBmb3IgbG9jYWxseSAg Z2VuZXJhdGVkIHVuaXF1ZSBpZGVudGlmaWVycy4NCj5JdA0KPmlzIGJhc2VkIG9uIHNpbXBseSBn ZW5lcmF0aW5nIGEgIGNyeXB0b2dyYXBoaWNhbGx5IHBzZXVkb3JhbmRvbSB2YWx1ZQ0KPltSRkM0 MDg2XS4gIFRoaXMgdmFsdWUgTVVTVCBiZSAgYXQgbGVhc3QgOTYgYml0cyBidXQgTUFZIGJlIGxv bmdlci4iIElzIGENCj5iaXQgY29uZnVzaW5nIHNpbmNlIEkgZXhwZWN0ZWQgdG8gYWxnb3JpdGht IGFuZCBub3QgYSByZWZlcmVuY2UgKHRoZSBmaXJzdA0KPnNlbnRlbmNlIGlzIGZyb20gUkZDNjIy MikuIE1heWJlIGV4cGxhaW4gdGhhdCB0aGUgYWxnb3JpdGhtIGlzIGluIFJGQzQwODYsDQo+YW5k IG1heWJlIHBvaW50IHRvIGl0Lg0KDQpPTEQ6DQoNCiAgIFRoZSBhbGdvcml0aG0gZGVzY3JpYmVk IGJlbG93IGlzIGludGVuZGVkIHRvIGJlIHVzZWQgZm9yIGxvY2FsbHkNCiAgIGdlbmVyYXRlZCB1 bmlxdWUgaWRlbnRpZmllcnMuICBJdCBpcyBiYXNlZCBvbiBzaW1wbHkgZ2VuZXJhdGluZyBhDQog ICBjcnlwdG9ncmFwaGljYWxseSBwc2V1ZG9yYW5kb20gdmFsdWUgW1JGQzQwODZdLiAgVGhpcyB2 YWx1ZSBNVVNUIGJlDQogICBhdCBsZWFzdCA5NiBiaXRzIGJ1dCBNQVkgYmUgbG9uZ2VyLg0KDQoN Ck5FVzoNCg0KICAgVG8gbG9jYWxseSBwcm9kdWNlIGEgdW5pcXVlIGlkZW50aWZpZXIsIHdlIHNp bXBseSBnZW5lcmF0ZSBhDQogICBjcnlwdG9ncmFwaGljYWxseSBwc2V1ZG9yYW5kb20gdmFsdWUg YXMgZGVzY3JpYmVkIGluIFtSRkM0MDg2XS4gIFRoaXMNCnZhbHVlIE1VU1QgYmUNCiAgIGF0IGxl YXN0IDk2IGJpdHMgYnV0IE1BWSBiZSBsb25nZXIuDQoNCg0KSSBkb250IHRoaW5rIHdlIHNob3Vs ZCBleHBsYWluIGhvdyB0aGlzIGdlbmVyYXRpb24gaXMgZG9uZSBpbiB0aGlzIGRyYWZ0Lg0KDQo+ DQo+Mi4gUFJORyBpcyBub3QgZXhwYW5kZWQgYW55d2hlcmUgaW4gdGhlIGRvY3VtZW50DQoNCkkg d2lsbCBmaXggdGhpcy4NCg0KLWFjYmVnZW4NCg0KPg0KPlJvbmkgRXZlbg0KPg0KPg0KPi0tLS0t T3JpZ2luYWwgTWVzc2FnZS0tLS0tDQo+RnJvbTogYXZ0LWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0 bzphdnQtYm91bmNlc0BpZXRmLm9yZ10gT24gQmVoYWxmIE9mDQo+TWFnbnVzDQo+V2VzdGVybHVu ZA0KPlNlbnQ6IDI4IE1hcmNoLCAyMDEzIDEyOjAyIFBNDQo+VG86IGF2dEBpZXRmLm9yZw0KPlN1 YmplY3Q6IFtBVlRDT1JFXSBSZW1pbmRlcjogUmU6IFdHIGxhc3QgY2FsbCBvbg0KPmRyYWZ0LWll dGYtYXZ0Y29yZS02MjIyYmlzLTAxDQo+DQo+V0csDQo+DQo+U28gZmFyIHRoZXJlIGhhcyBiZSBu byBvdGhlciByZXZpZXdzIG9mIHRoaXMgZG9jdW1lbnQgdGhhbiBtaW5lLg0KPg0KPkNhbiBzb21l b25lIHBsZWFzZSByZXZpZXcgdGhpcyBkb2N1bWVudD8NCj4NCj5JIGhlcmVieSBleHRlbmRlZCB0 aGUgV0cgbGFzdCBjYWxsIHdpdGggb25lIHdlZWsgdW50aWwgdGhlIDd0aCBvZiBBcHJpbC4NCj4N Cj5DaGVlcnMNCj4NCj5NYWdudXMNCj4NCj5PbiAyMDEzLTAzLTEyIDIwOjA0LCBNYWdudXMgV2Vz dGVybHVuZCB3cm90ZToNCj4+IFdHLA0KPj4gDQo+PiBUaGlzIGlzIHRvIGFubm91bmNlIHRoZSBz dGFydCBvZiBhIFdHIGxhc3QgY2FsbCBvbjoNCj4+IA0KPj4gR3VpZGVsaW5lcyBmb3IgQ2hvb3Np bmcgUlRQIENvbnRyb2wgUHJvdG9jb2wgKFJUQ1ApIENhbm9uaWNhbCBOYW1lcw0KPj4gKENOQU1F cykgdG8gYmUgcHVibGlzaGVkIGFzIGEgcHJvcG9zZWQgc3RhbmRhcmQuDQo+PiANCj4+IERvY3Vt ZW50IGNhbiBiZSByZXRyaWV2ZWQgaGVyZToNCj4+IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5v cmcvZG9jL2RyYWZ0LWlldGYtYXZ0Y29yZS02MjIyYmlzLw0KPj4gDQo+PiBQbGVhc2UgcHJvdmlk ZSBhbnkgZmVlZGJhY2sgYnkgdGhlIDMxc3Qgb2YgTWFyY2guDQo+PiANCj4+IFJlZ2FyZHMNCj4+ IA0KPj4gTWFnbnVzIFdlc3Rlcmx1bmQNCj4+IFdHIGNoYWlyDQo+PiANCj4+IA0KPj4gLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLQ0KPj4gTXVsdGltZWRpYSBUZWNobm9sb2dpZXMsIEVyaWNzc29uIFJlc2VhcmNoIEVB Qi9UVk0NCj4+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4+IEVyaWNzc29uIEFCICAgICAgICAgICAgICAgIHwg UGhvbmUgICs0NiAxMCA3MTQ4Mjg3DQo+PiBGw6Ryw7ZnYXRhbiA2ICAgICAgICAgICAgICAgIHwg TW9iaWxlICs0NiA3MyAwOTQ5MDc5DQo+PiBTRS0xNjQgODAgU3RvY2tob2xtLCBTd2VkZW58IG1h aWx0bzogbWFnbnVzLndlc3Rlcmx1bmRAZXJpY3Nzb24uY29tDQo+PiAtLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+ PiANCj4+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+ PiBBdWRpby9WaWRlbyBUcmFuc3BvcnQgQ29yZSBNYWludGVuYW5jZSBhdnRAaWV0Zi5vcmcNCj4+ IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vYXZ0DQo+PiANCj4+IA0KPg0K Pg0KPi0tIA0KPg0KPk1hZ251cyBXZXN0ZXJsdW5kDQo+DQo+LS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPk11bHRp bWVkaWEgVGVjaG5vbG9naWVzLCBFcmljc3NvbiBSZXNlYXJjaCBFQUIvVFZNDQo+LS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLQ0KPkVyaWNzc29uIEFCICAgICAgICAgICAgICAgIHwgUGhvbmUgICs0NiAxMCA3MTQ4Mjg3 DQo+RsOkcsO2Z2F0YW4gNiAgICAgICAgICAgICAgICB8IE1vYmlsZSArNDYgNzMgMDk0OTA3OQ0K PlNFLTE2NCA4MCBTdG9ja2hvbG0sIFN3ZWRlbnwgbWFpbHRvOiBtYWdudXMud2VzdGVybHVuZEBl cmljc3Nvbi5jb20NCj4tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+DQo+X19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX18NCj5BdWRpby9WaWRlbyBUcmFuc3BvcnQgQ29yZSBNYWlu dGVuYW5jZQ0KPmF2dEBpZXRmLm9yZw0KPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlz dGluZm8vYXZ0DQo+DQo+X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX18NCj5BdWRpby9WaWRlbyBUcmFuc3BvcnQgQ29yZSBNYWludGVuYW5jZQ0KPmF2dEBpZXRm Lm9yZw0KPmh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vYXZ0DQo+DQoNCg0K From abegen@cisco.com Thu Apr 11 04:53:40 2013 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 754A821F8B19 for ; Thu, 11 Apr 2013 04:53:40 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.147 X-Spam-Level: X-Spam-Status: No, score=-10.147 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_HI=-8, SARE_SUB_ENC_UTF8=0.152] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MTbFM8qNPlbI for ; Thu, 11 Apr 2013 04:53:39 -0700 (PDT) Received: from rcdn-iport-9.cisco.com (rcdn-iport-9.cisco.com [173.37.86.80]) by ietfa.amsl.com (Postfix) with ESMTP id 2BD4A21F8B13 for ; Thu, 11 Apr 2013 04:53:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=7436; q=dns/txt; s=iport; t=1365681219; x=1366890819; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=QsZM/cNR19eiHEdGjVsIbiud14/KgUFF26VIezFa8JU=; b=iRjVT9BQJ7gzaXGMS1Z4BkYuKZm5QcIlLbMot1/PmvrosGAq0Z6w+qKL 1WOS8t1HU7fyUTo1m9uJIanxfy1Qv5DoeUu8OP0bVZW1XMd3A4vjszU4V P3u2r6ZWPmjxFoGrWy+72x/nPlLlwXQSXpq5GKBUGBgH2Jw36Qxzd41qU 8=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjUFAMejZlGtJXG//2dsb2JhbABQgmUhNoJUWr4dDXcWdIIfAQEBBAEBAQkXEVECBAEGAg4DAwECAQICBh0DAgQZDAsUAQUDCAIEARIIiAwBC493mwSSfgSBH41AAhYQEgaCKDJhA5M1hGyPbYFVgTaCKA X-IronPort-AV: E=Sophos;i="4.87,454,1363132800"; d="scan'208";a="194585250" Received: from rcdn-core2-4.cisco.com ([173.37.113.191]) by rcdn-iport-9.cisco.com with ESMTP; 11 Apr 2013 11:53:38 +0000 Received: from xhc-rcd-x03.cisco.com (xhc-rcd-x03.cisco.com [173.37.183.77]) by rcdn-core2-4.cisco.com (8.14.5/8.14.5) with ESMTP id r3BBrca9009416 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Thu, 11 Apr 2013 11:53:38 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-rcd-x03.cisco.com ([173.37.183.77]) with mapi id 14.02.0318.004; Thu, 11 Apr 2013 06:53:38 -0500 From: "Ali C. Begen (abegen)" To: Qin Wu , "avt@ietf.org" Thread-Topic: =?utf-8?B?W0FWVENPUkVdIOetlOWkjTogIFJlbWluZGVyOiBSZTogV0cgbGFzdCBjYWxs?= =?utf-8?Q?_on_draft-ietf-avtcore-6222bis-01?= Thread-Index: AQHONqszgY9eNXn6t0y3xaVZNo5Eqw== Date: Thu, 11 Apr 2013 11:52:15 +0000 Message-ID: In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.2.130206 x-originating-ip: [10.61.98.193] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: Re: [AVTCORE] =?utf-8?b?562U5aSNOiAgUmVtaW5kZXI6IFJlOiBXRyBsYXN0IGNh?= =?utf-8?q?ll_on_draft-ietf-avtcore-6222bis-01?= X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Apr 2013 11:53:40 -0000 LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IFFpbiBXdSA8YmlsbC53dUBodWF3ZWku Y29tPg0KRGF0ZTogVGh1cnNkYXksIEFwcmlsIDExLCAyMDEzIDI6MDQgUE0NClRvOiAiYXZ0QGll dGYub3JnIiA8YXZ0QGlldGYub3JnPg0KU3ViamVjdDogW0FWVENPUkVdIOetlOWkjTogIFJlbWlu ZGVyOiBSZTogV0cgbGFzdCBjYWxsDQpvbglkcmFmdC1pZXRmLWF2dGNvcmUtNjIyMmJpcy0wMQ0K DQo+SGksIEFsaToNCj5IZXJlIGlzIG15IHF1aWNrIHJldmlldyB0byBkcmFmdC1pZXRmLWF2dGNv cmUtNjIyMmJpcy0wMToNCj4xLiBTZWN0aW9uIDEgYW5kIFNlY3Rpb24gMzoNCj5JdCBpcyBub3Qg Y2xlYXIgaG93IHRoZSBzZWN0aW9uIDEgaXMgcmVsYXRlZCB0byBzZWN0aW9uIDM/DQoNClNlY3Rp b24gMSBpcyBtb3RpdmF0aW5nIHRoZSBuZWVkIGZvciB0aGUgYmlzIGRvY3VtZW50Lg0KDQo+SXMg dGhpcyBkcmFmdCBmb2N1c2luZyBvbiB0YWNraW5nIGxpbmthYmlsaXR5IGlzc3VlIG9yIGRlZmlj aWVuY3kgaXNzdWVzDQo+ZGVzY3JpYmVkIGluIHNlY3Rpb24gMz8NCg0KVGhpcyBkcmFmdCBpcyBu b3QgYW4gdXBkYXRlIG9uIDYyMjIsIGl0IHJlcGxhY2VzIGl0IHNvIGl0IGhhcyB0aGUgdGV4dA0K ZnJvbSA2MjIyIGFzIHdlbGwuDQoNCj4gDQo+V2hhdCB0aGUgbGlua2FiaWxpdHkgaXNzdWUgaXM/ IEl0IGlzIG5vdCBvYnZpb3VzIHRvIGEgcmVhZGVyIHdobyBhcmUgbm90DQo+ZmFtaWxpYXIgd2l0 aCB0aGlzIGFsdGhvdWdoIHRoaXMgZHJhZnQgcG9pbnQgdG8NCj5bSS1ELnJlc2NvcmxhLWF2dGNv cmUtcmFuZG9tLWNuYW1lXSBpbiB0aGUgc2VjdGlvbiAxPw0KDQpGb3IgdGhlIHNha2Ugb2YgUlRD UCBDTkFNRSwgeW91IGRvbnQgbmVlZCB0byBrbm93IHRoZSBkZXRhaWxzIG9mDQpsaW5rYWJpbGl0 eSBjb25jZXJucyB0aGUgcmVzY29ybGEgZHJhZnQgZGlzY3Vzc2VzLiBJdCBpcyBzaW1wbHkgdGhl cmUNCnNpbmNlIGl0IHdhcyB0aGUgcmVhc29uIHdoeSB3ZSBzdGFydGVkIHRoaXMgYmlzIHdvcmsg aW4gdGhlIGZpcnN0IHBsYWNlLg0KDQo+DQo+Mi4gUFJORyBuZWVkcyB0byBiZSBleHBhbmRlZCBv ciBwb2ludCB0byBhIHJlZmVyZW5jZS4NCg0KV2lsbCBmaXggaXQuDQoNCj4NCj4zLiBTZWN0aW9u IDYuMQ0KPlRoZSBsYXN0IHNlbnRlbmNlIHNhaWQ6DQo+Ig0KPkEgbGVuZ3RoIG9mIDk2IGJpdHMg YWxsb3dzIG9uIHRoZSBvcmRlciBvZg0KPjJeezQwfSBSVENQIENOQU1FcyBnbG9iYWxseSBiZWZv cmUgdGhlcmUgaXMgYSBsYXJnZSBjaGFuY2Ugb2YNCj5jb2xsaXNpb24gKHRoZXJlIGlzIGFib3V0 IGEgNTAlIGNoYW5jZSBvZiBvbmUgY29sbGlzaW9uIGFmdGVyIDJeezQ4fQ0KPlJUQ1AgQ05BTUVz KS4NCj4iDQo+SSBhbSBkaWZmaWN1bHQgdG8gdW5kZXJzdGFuZCB0aGUgcmF0aW9uYWxlIGZvciB0 aGlzIGNhbGN1bGF0aW9uIHNpbmNlIEkNCj5kb24ndCBrbm93IFdoYXQgIjJeezQwfSIgc3RhbmQg Zm9yPw0KPkhvdyAiNDAiIGlzIHJlbGF0ZWQgdG8gdGhlIGxlbmd0aCBvZiA5NiBiaXRzPw0KDQpU aGlzIGluZm8gY29tZXMgZnJvbQ0KaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtcmVz Y29ybGEtYXZ0Y29yZS1yYW5kb20tY25hbWUtMDAgc2VjdGlvbg0KNC4gRXJpYyBtaWdodCBwcm92 aWRlIG1vcmUgaW5mbyBpZiB5b3UgbmVlZC4NCg0KPg0KPjQuNi4yDQo+SSBjYW4gdW5kZXJzdGFu ZCB0aGUgZmlyc3Qgc2VudGVuY2UsIGJ1dCBJIGRvbid0IHVuZGVyc3RhbmQgdGhlIHNlY29uZA0K Pm9uZS4gDQo+V2hhdCBraW5kIG9mIGNvcnJlbGF0aW9uIG5lZWQgdG8gYmUgcHJldmVudGVkPyBX aHkgc3VjaCBjb3JyZWxhdGlvbg0KPnNob3VsZCBiZSBwcmV2ZW50ZWQ/DQoNCklmIHlvdSBrZWVw IHVzaW5nIHRoZSBzYW1lIFJUQ1AgQ05BTUUgaW4gYWxsIG9mIHlvdXIgc2Vzc2lvbnMsIHNvbWVv bmUNCm1pZ2h0IHRyYWNrIHlvdS4gSW4gc29tZSBjYXNlcywgeW91IG1pZ2h0IHdhbnQgdGhhdCwg aW4gc29tZSBjYXNlcyB5b3UNCndvbid0LiBUaGF0IGlzIHdoYXQgdGhpcyBzZWN0aW9ucyBpcyBz YXlpbmcgeW91LiBCYXNlZCBvbiB3aGF0IHlvdSB3YW50LA0KY2hvb3NlIGEgcGVyc2lzdGVudCB2 cyBwZXItc2Vzc2lvbiBSVENQIENOQU1FLg0KDQo+SXNuJ3QgdGhpcyBzZWN0aW9uIGZvY3VzaW5n IG9uIHRhbGtpbmcgYWJvdXQgaG93IHRvIGNvcnJlbGF0ZSBzZXNzaW9ucz8NCj5XaGF0IGFtIEkg bWlzc2luZz8NCg0KSSBob3BlIGl0IGlzIGNsZWFyZXIgbm93Lg0KDQpUaGFua3MsDQotYWNiZWdl bg0KDQo+DQo+UmVnYXJkcyENCj4tUWluDQo+LS0tLS3pgq7ku7bljp/ku7YtLS0tLQ0KPuWPkeS7 tuS6ujogYXZ0LWJvdW5jZXNAaWV0Zi5vcmcgW21haWx0bzphdnQtYm91bmNlc0BpZXRmLm9yZ10g 5Luj6KGoIE1hZ251cw0KPldlc3Rlcmx1bmQNCj7lj5HpgIHml7bpl7Q6IDIwMTPlubQ05pyIMTDm l6UgMTU6NTgNCj7mlLbku7bkuro6IE1hZ251cyBXZXN0ZXJsdW5kDQo+5oqE6YCBOiBhdnRAaWV0 Zi5vcmcNCj7kuLvpopg6IFJlOiBbQVZUQ09SRV0gUmVtaW5kZXI6IFJlOiBXRyBsYXN0IGNhbGwg b24NCj5kcmFmdC1pZXRmLWF2dGNvcmUtNjIyMmJpcy0wMQ0KPg0KPldHLA0KPg0KPlRoaXMgV0cg bGFzdCBjYWxsIGhhcyBjb25jbHVkZWQuIEkgdGhpbmsgdGhlIGxldmVsIG9mIHJldmlld3Mgb24g dGhpcw0KPmRvY3VtZW50IGFyZSB2ZXJ5IGxvdy4gSW4gdGhlIHdvcmtpbmcgZ3JvdXAgbGFzdCBj YWxsIG9ubHkgS2V2aW4gR3Jvc3MNCj5hbmQgSSBoYXZlIHN0YXRlZCB0aGF0IHRoZXkgaGF2ZSBy ZXZpZXdlZCB0aGUgbGF0ZXN0IHZlcnNpb24uDQo+DQo+QXV0aG9ycyBwbGVhc2UgYWRkcmVzcyBy YWlzZWQgaXNzdWVzLg0KPg0KPkkgd2lsbCBub3QgY29uc2lkZXIgdGhpcyBhIHN1Y2Nlc3NmdWwg V0cgbGFzdCBjYWxsIHVubGVzcyBhdCBsZWFzdCBvbmUNCj5hZGRpdGlvbmFsIHBlcnNvbiByZXZp ZXdzIGl0IHdobyBhcmUgbm90IGFuIGF1dGhvci4gSXQgaXMgYSB2ZXJ5IHNob3J0DQo+ZG9jdW1l bnQgYW5kIGl0IGFsc28gZG9uJ3QgcmVxdWlyZSBtYXNzaXZlIGFtb3VudHMgb2YgYWRkaXRpb25h bA0KPmtub3dsZWRnZSBiZXlvbmQgYmFzaWMgUlRQIHVuZGVyc3RhbmRpbmcgdG8gcmV2aWV3Lg0K Pg0KPlJlZ2FyZHMNCj4NCj5NYWdudXMgV2VzdGVybHVuZA0KPldHIGNoYWlyDQo+DQo+T24gMjAx My0wMy0yOCAxMTowMSwgTWFnbnVzIFdlc3Rlcmx1bmQgd3JvdGU6DQo+PiBXRywNCj4+IA0KPj4g U28gZmFyIHRoZXJlIGhhcyBiZSBubyBvdGhlciByZXZpZXdzIG9mIHRoaXMgZG9jdW1lbnQgdGhh biBtaW5lLg0KPj4gDQo+PiBDYW4gc29tZW9uZSBwbGVhc2UgcmV2aWV3IHRoaXMgZG9jdW1lbnQ/ DQo+PiANCj4+IEkgaGVyZWJ5IGV4dGVuZGVkIHRoZSBXRyBsYXN0IGNhbGwgd2l0aCBvbmUgd2Vl ayB1bnRpbCB0aGUgN3RoIG9mIEFwcmlsLg0KPj4gDQo+PiBDaGVlcnMNCj4+IA0KPj4gTWFnbnVz DQo+PiANCj4+IE9uIDIwMTMtMDMtMTIgMjA6MDQsIE1hZ251cyBXZXN0ZXJsdW5kIHdyb3RlOg0K Pj4+IFdHLA0KPj4+DQo+Pj4gVGhpcyBpcyB0byBhbm5vdW5jZSB0aGUgc3RhcnQgb2YgYSBXRyBs YXN0IGNhbGwgb246DQo+Pj4NCj4+PiBHdWlkZWxpbmVzIGZvciBDaG9vc2luZyBSVFAgQ29udHJv bCBQcm90b2NvbCAoUlRDUCkgQ2Fub25pY2FsIE5hbWVzDQo+Pj4gKENOQU1FcykgdG8gYmUgcHVi bGlzaGVkIGFzIGEgcHJvcG9zZWQgc3RhbmRhcmQuDQo+Pj4NCj4+PiBEb2N1bWVudCBjYW4gYmUg cmV0cmlldmVkIGhlcmU6DQo+Pj4gaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJh ZnQtaWV0Zi1hdnRjb3JlLTYyMjJiaXMvDQo+Pj4NCj4+PiBQbGVhc2UgcHJvdmlkZSBhbnkgZmVl ZGJhY2sgYnkgdGhlIDMxc3Qgb2YgTWFyY2guDQo+Pj4NCj4+PiBSZWdhcmRzDQo+Pj4NCj4+PiBN YWdudXMgV2VzdGVybHVuZA0KPj4+IFdHIGNoYWlyDQo+Pj4NCj4+Pg0KPj4+IC0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0NCj4+PiBNdWx0aW1lZGlhIFRlY2hub2xvZ2llcywgRXJpY3Nzb24gUmVzZWFyY2ggRUFCL1RW TQ0KPj4+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4+PiBFcmljc3NvbiBBQiAgICAgICAgICAgICAgICB8IFBo b25lICArNDYgMTAgNzE0ODI4Nw0KPj4+IEbDpHLDtmdhdGFuIDYgICAgICAgICAgICAgICAgfCBN b2JpbGUgKzQ2IDczIDA5NDkwNzkNCj4+PiBTRS0xNjQgODAgU3RvY2tob2xtLCBTd2VkZW58IG1h aWx0bzogbWFnbnVzLndlc3Rlcmx1bmRAZXJpY3Nzb24uY29tDQo+Pj4gLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0K Pj4+DQo+Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18N Cj4+PiBBdWRpby9WaWRlbyBUcmFuc3BvcnQgQ29yZSBNYWludGVuYW5jZQ0KPj4+IGF2dEBpZXRm Lm9yZw0KPj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vYXZ0DQo+Pj4N Cj4+Pg0KPj4gDQo+PiANCj4NCj4NCj4tLSANCj4NCj5NYWdudXMgV2VzdGVybHVuZA0KPg0KPi0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0NCj5NdWx0aW1lZGlhIFRlY2hub2xvZ2llcywgRXJpY3Nzb24gUmVzZWFyY2gg RUFCL1RWTQ0KPi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj5Fcmljc3NvbiBBQiAgICAgICAgICAgICAgICB8IFBo b25lICArNDYgMTAgNzE0ODI4Nw0KPkbDpHLDtmdhdGFuIDYgICAgICAgICAgICAgICAgfCBNb2Jp bGUgKzQ2IDczIDA5NDkwNzkNCj5TRS0xNjQgODAgU3RvY2tob2xtLCBTd2VkZW58IG1haWx0bzog bWFnbnVzLndlc3Rlcmx1bmRAZXJpY3Nzb24uY29tDQo+LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPg0KPl9fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+QXVkaW8vVmlkZW8g VHJhbnNwb3J0IENvcmUgTWFpbnRlbmFuY2UNCj5hdnRAaWV0Zi5vcmcNCj5odHRwczovL3d3dy5p ZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2F2dA0KPl9fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fDQo+QXVkaW8vVmlkZW8gVHJhbnNwb3J0IENvcmUgTWFpbnRl bmFuY2UNCj5hdnRAaWV0Zi5vcmcNCj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3Rp bmZvL2F2dA0KPg0KDQoNCg== From gonzalo.camarillo@ericsson.com Thu Apr 11 05:04:35 2013 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E15B421F8C1E for ; Thu, 11 Apr 2013 05:04:35 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.133 X-Spam-Level: X-Spam-Status: No, score=-104.133 tagged_above=-999 required=5 tests=[AWL=0.316, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_33=0.6, J_CHICKENPOX_47=0.6, J_CHICKENPOX_48=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id vNIIQOcg5eg9 for ; Thu, 11 Apr 2013 05:04:35 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id B700721F8AE7 for ; Thu, 11 Apr 2013 05:04:34 -0700 (PDT) X-AuditID: c1b4fb25-b7f366d000004d10-7e-5166a6d196d5 Received: from esessmw0256.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id D1.4D.19728.1D6A6615; Thu, 11 Apr 2013 14:04:33 +0200 (CEST) To: undisclosed-recipients:; Received: from [131.160.126.154] (153.88.115.8) by esessmw0256.eemea.ericsson.se (153.88.115.97) with Microsoft SMTP Server id 8.3.279.1; Thu, 11 Apr 2013 14:04:33 +0200 Message-ID: <5166A6D0.4090201@ericsson.com> Date: Thu, 11 Apr 2013 15:04:32 +0300 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 References: <20130410131256.CBFFFB1E006@rfc-editor.org> In-Reply-To: <20130410131256.CBFFFB1E006@rfc-editor.org> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFtrGLMWRmVeSWpSXmKPExsUyM+Jvre7FZWmBBqcPiVu87FnJbvF8VrbF 8pcnGC12Hd3PZDG1z9biScsPZgc2j2n377N5TH63hMljyZKfTB6TN85i8dix+QGrx4ndrgFs UVw2Kak5mWWpRfp2CVwZN1cuZy7YJ1Sxvv0kUwPjXL4uRk4OCQETifbfz1ghbDGJC/fWs3Ux cnEICZxilJj9+zo7SEJEQEZi7uzHrBCJtYwSfb2zmEASvALaEm97d7GA2CwCqhIHZ25kBLHZ BCwktty6DxYXFYiS+Pd2NyNEvaDEyZlPWEAGMQscZZRoPtoKlODgEBYwl1jYEwFSIwRkfv0+ H+wiTqA5d24fZYK4TlJi0bROsJnMAnoSU662MELY8hLb385hhujVllj+rIVlAqPQLCTrZiFp mYWkZQEj8ypG9tzEzJz0cqNNjMCwP7jlt+oOxjvnRA4xSnOwKInzhrteCBASSE8sSc1OTS1I LYovKs1JLT7EyMTBKdXAOMv6VWnlAt4tdzU5S0tyAtIvv71ee2DOQbUM6fUvO0Tre3Yqv+FZ pfFR0GKtxw2/nww/7t//17XZyG7PUd/Ze4TUfv53/sGyJvJHnP5PVsaJBne+hO0KXrNo6p6m s4HPt3BOPaWudXxnU6Vn3pfds4KNDnPqiX1adJIpXq753pcnW9YplVz0lVRiKc5INNRiLipO BACdQ+f8SQIAAA== Cc: magnus.westerlund@ericsson.com, piers.ohanlon@oii.ox.ac.uk, avt@ietf.org, ingemar.s.johansson@ericsson.com, csp@csperkins.org Subject: Re: [AVTCORE] [Editorial Errata Reported] RFC6679 (3586) X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Apr 2013 12:04:36 -0000 Hi, would anybody object to put this erratum into the "held for document update" status? Cheers, Gonzalo On 10/04/2013 4:12 PM, RFC Errata System wrote: > The following errata report has been submitted for RFC6679, > "Explicit Congestion Notification (ECN) for RTP over UDP". > > -------------------------------------- > You may review the report below and at: > http://www.rfc-editor.org/errata_search.php?rfc=6679&eid=3586 > > -------------------------------------- > Type: Editorial > Reported by: Magnus Westerlund > > Section: 12.1 > > Original Text > ------------- > The Offer: > > ... > a=ecn-capable-rtp: ice rtp ect=0 mode=setread > ... > > The Answer: > ... > a=ecn-capable-rtp: ice ect=0 mode=readonly > ... > > Corrected Text > -------------- > The Offer: > > ... > a=ecn-capable-rtp: ice,rtp ect=0; mode=setread > ... > > The Answer: > ... > a=ecn-capable-rtp: ice ect=0; mode=readonly > ... > > Notes > ----- > The examples does not match the ABNF rules for the a=ecn-capaable-rtp attribute. Two issues are present, first the init method list must be comma separated with no spaces, secondly any additional parameters shall be semi colon plus space separated. Therefore both a=ecn-capable-rtp lines have been corrected. > > This is primarily an editorial issues but people needs to aware of the errors in the example. > > Instructions: > ------------- > This errata is currently posted as "Reported". If necessary, please > use "Reply All" to discuss whether it should be verified or > rejected. When a decision is reached, the verifying party (IESG) > can log in to change the status and edit the report, if necessary. > > -------------------------------------- > RFC6679 (draft-ietf-avtcore-ecn-for-rtp-08) > -------------------------------------- > Title : Explicit Congestion Notification (ECN) for RTP over UDP > Publication Date : August 2012 > Author(s) : M. Westerlund, I. Johansson, C. Perkins, P. O'Hanlon, K. Carlberg > Category : PROPOSED STANDARD > Source : Audio/Video Transport Core Maintenance > Area : Real-time Applications and Infrastructure > Stream : IETF > Verifying Party : IESG > From ron.even.tlv@gmail.com Thu Apr 11 05:39:48 2013 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9B69721F8D85 for ; Thu, 11 Apr 2013 05:39:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.714 X-Spam-Level: X-Spam-Status: No, score=-1.714 tagged_above=-999 required=5 tests=[AWL=1.885, BAYES_00=-2.599, RCVD_IN_DNSWL_LOW=-1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id lUGfH4-v8iAa for ; Thu, 11 Apr 2013 05:39:48 -0700 (PDT) Received: from mail-ee0-f45.google.com (mail-ee0-f45.google.com [74.125.83.45]) by ietfa.amsl.com (Postfix) with ESMTP id 8B6F921F8D5F for ; Thu, 11 Apr 2013 05:39:47 -0700 (PDT) Received: by mail-ee0-f45.google.com with SMTP id c50so720592eek.4 for ; Thu, 11 Apr 2013 05:39:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:from:to:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:x-mailer :thread-index:content-language; bh=WkIpjTEgEaAmJV9SHasnVdc8pDuWuXsrGs8Jg23JTA0=; b=kZbNJZwkUSOFxeISzTNaC00sdGu9uwZExNw84JijZFisHx3QaIGslD0JiHspJQfD2X TamGO3jknqjUJPO5N5yMNdqAvHX5aqccO6TlG/VLNOEgTmQQbZbSwD2ZBiqRcwt8gMRV Y8OlMh98zt4SwAsQbG/rVycVJxVv4ZfI5ZhQgi7TUeUITIt0AKLTZ6tE8fmrzZuznbZ5 kzcNFBBSiunaBwLbP51IwL0lY+rDUNZ7CQ5m1H6rZhEcHvSK7OHX2AbVGTkgISlOitqu 43Khiau2HWTlJhG4nCZg9l90DZnpiF6PopTFmA+UN4JGKSFOdEy5kN4N2o71sqxxjSVV ql7g== X-Received: by 10.15.41.2 with SMTP id r2mr16659112eev.20.1365683986435; Thu, 11 Apr 2013 05:39:46 -0700 (PDT) Received: from RoniE (bzq-79-181-177-28.red.bezeqint.net. [79.181.177.28]) by mx.google.com with ESMTPS id u44sm5430911eel.7.2013.04.11.05.39.43 (version=TLSv1 cipher=RC4-SHA bits=128/128); Thu, 11 Apr 2013 05:39:44 -0700 (PDT) From: "Roni Even" To: "'Ali C. Begen \(abegen\)'" , "'Magnus Westerlund'" , References: <003701ce3696$b769ed90$263dc8b0$@gmail.com> In-Reply-To: Date: Thu, 11 Apr 2013 15:39:14 +0300 Message-ID: <008001ce36b1$94d79230$be86b690$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQF4FpeNA+b7yKQMxTB8j0htPWi2QZl9Nb4A Content-Language: en-us Subject: Re: [AVTCORE] Reminder: Re: WG last call on draft-ietf-avtcore-6222bis-01 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Apr 2013 12:39:48 -0000 Hi Ali, The new text is OK. I did not ask for the algorithm itself. Roni -----Original Message----- From: Ali C. Begen (abegen) [mailto:abegen@cisco.com]=20 Sent: 11 April, 2013 2:44 PM To: Roni Even; 'Magnus Westerlund'; avt@ietf.org Subject: Re: [AVTCORE] Reminder: Re: WG last call on = draft-ietf-avtcore-6222bis-01 -----Original Message----- From: Roni Even Date: Thursday, April 11, 2013 12:26 PM To: Magnus Westerlund , "avt@ietf.org" Subject: Re: [AVTCORE] Reminder: Re: WG last call on draft-ietf-avtcore-6222bis-01 >Hi, >Sorry for being late. >I read the draft and in general it looks OK. Thanks. >Two comments: > >1. I think that the folowing text in section 5 "The algorithm=20 >described below is intended to be used for locally generated unique = identifiers. >It >is based on simply generating a cryptographically pseudorandom value=20 >[RFC4086]. This value MUST be at least 96 bits but MAY be longer." Is = >a bit confusing since I expected to algorithm and not a reference (the=20 >first sentence is from RFC6222). Maybe explain that the algorithm is in = >RFC4086, and maybe point to it. OLD: The algorithm described below is intended to be used for locally generated unique identifiers. It is based on simply generating a cryptographically pseudorandom value [RFC4086]. This value MUST be at least 96 bits but MAY be longer. NEW: To locally produce a unique identifier, we simply generate a cryptographically pseudorandom value as described in [RFC4086]. This = value MUST be at least 96 bits but MAY be longer. I dont think we should explain how this generation is done in this = draft. > >2. PRNG is not expanded anywhere in the document I will fix this. -acbegen > >Roni Even > > >-----Original Message----- >From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of=20 >Magnus Westerlund >Sent: 28 March, 2013 12:02 PM >To: avt@ietf.org >Subject: [AVTCORE] Reminder: Re: WG last call on >draft-ietf-avtcore-6222bis-01 > >WG, > >So far there has be no other reviews of this document than mine. > >Can someone please review this document? > >I hereby extended the WG last call with one week until the 7th of = April. > >Cheers > >Magnus > >On 2013-03-12 20:04, Magnus Westerlund wrote: >> WG, >>=20 >> This is to announce the start of a WG last call on: >>=20 >> Guidelines for Choosing RTP Control Protocol (RTCP) Canonical Names >> (CNAMEs) to be published as a proposed standard. >>=20 >> Document can be retrieved here: >> https://datatracker.ietf.org/doc/draft-ietf-avtcore-6222bis/ >>=20 >> Please provide any feedback by the 31st of March. >>=20 >> Regards >>=20 >> Magnus Westerlund >> WG chair >>=20 >>=20 >> --------------------------------------------------------------------- >> - Multimedia Technologies, Ericsson Research EAB/TVM >> = ---------------------------------------------------------------------- >> Ericsson AB | Phone +46 10 7148287 >> F=C3=A4r=C3=B6gatan 6 | Mobile +46 73 0949079 >> SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com >> --------------------------------------------------------------------- >> - >>=20 >> _______________________________________________ >> Audio/Video Transport Core Maintenance avt@ietf.org=20 >> https://www.ietf.org/mailman/listinfo/avt >>=20 >>=20 > > >-- > >Magnus Westerlund > >---------------------------------------------------------------------- >Multimedia Technologies, Ericsson Research EAB/TVM >---------------------------------------------------------------------- >Ericsson AB | Phone +46 10 7148287 >F=C3=A4r=C3=B6gatan 6 | Mobile +46 73 0949079 >SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com >---------------------------------------------------------------------- > >_______________________________________________ >Audio/Video Transport Core Maintenance >avt@ietf.org >https://www.ietf.org/mailman/listinfo/avt > >_______________________________________________ >Audio/Video Transport Core Maintenance >avt@ietf.org >https://www.ietf.org/mailman/listinfo/avt > From martin.thomson@gmail.com Thu Apr 11 09:58:32 2013 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 74E9621F91A0 for ; Thu, 11 Apr 2013 09:58:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.525 X-Spam-Level: X-Spam-Status: No, score=-2.525 tagged_above=-999 required=5 tests=[AWL=0.075, BAYES_00=-2.599, NO_RELAYS=-0.001] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HxBAgLz9OTTn for ; Thu, 11 Apr 2013 09:58:32 -0700 (PDT) Received: from mail-wi0-x22b.google.com (mail-wi0-x22b.google.com [IPv6:2a00:1450:400c:c05::22b]) by ietfa.amsl.com (Postfix) with ESMTP id AEA6C21F9057 for ; Thu, 11 Apr 2013 09:58:31 -0700 (PDT) Received: by mail-wi0-f171.google.com with SMTP id hn17so792182wib.4 for ; Thu, 11 Apr 2013 09:58:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=EQoqYTxISa47buobNqfpyYUCA117g6uYhM5xBY8x6dQ=; b=V1tU5sYDr/iADAf2L+nE8TnkSF9PaJevqd3w1mySZmBTrsAiqCTTWmvwR6c36+Irxz 7dtQZKdVjeMG9xcb4mSl0F8ZItxRLpTWNa6ZlvpuiA3x6hgkvj39CocCT1/34e2hitzZ JyNR1rJeGkWwTyUwFYub/EpguZRipVHzk3VTAbQpFk/P5rfk4c6GI29YWNx/hicBjs6W tURm6VsELtACRhvP/lWFqmmhHDcLmf5r07YXwJsjcCp0+3s/sV8Cww5rvUMh6R9t5eRH QOQcDq6EAXX4sv3Ha2b9YbSaNr40fEPqZfA50N3i5aHOKWJwBBegcOaRAQaWIfukzHRv Wo1A== MIME-Version: 1.0 X-Received: by 10.180.72.228 with SMTP id g4mr35347712wiv.22.1365699510881; Thu, 11 Apr 2013 09:58:30 -0700 (PDT) Received: by 10.194.41.35 with HTTP; Thu, 11 Apr 2013 09:58:30 -0700 (PDT) In-Reply-To: References: Date: Thu, 11 Apr 2013 09:58:30 -0700 Message-ID: From: Martin Thomson To: "Ali C. Begen (abegen)" Content-Type: text/plain; charset=UTF-8 Cc: Magnus Westerlund , "avt@ietf.org" Subject: Re: [AVTCORE] 6222bis X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 11 Apr 2013 16:58:32 -0000 On 11 April 2013 00:55, Ali C. Begen (abegen) wrote: >>I feel a little uncomfortable that the document justifies its >>existence (as a -bis) largely based on a reference to an individual >>draft. I would prefer to see the rationale presented in an appendix >>instead; it's fairly important information to retain. > > If you really feel strong about it, we can consider it but the current > draft mentions why we are doing this bis (due to the linkability of the > CNAMEs resulting from 6222 algorithms). For the purpose of 6222bis, where > that linkability comes from is not really essential IMO. My point was that the assertion (6222 provides linkability) is unsupported and not especially obvious. I would be happier if the document provided some stronger support for that claim. Happier. I'm already happy that this is far, far better than 6222. From bill.wu@huawei.com Thu Apr 11 20:54:08 2013 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1AEA621F85E7 for ; Thu, 11 Apr 2013 20:54:08 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -3.917 X-Spam-Level: X-Spam-Status: No, score=-3.917 tagged_above=-999 required=5 tests=[AWL=2.230, BAYES_00=-2.599, MIME_8BIT_HEADER=0.3, RCVD_IN_DNSWL_MED=-4, SARE_SUB_ENC_UTF8=0.152] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id V9OEJDHhbM+d for ; Thu, 11 Apr 2013 20:54:07 -0700 (PDT) Received: from lhrrgout.huawei.com (lhrrgout.huawei.com [194.213.3.17]) by ietfa.amsl.com (Postfix) with ESMTP id 5876321F86A6 for ; Thu, 11 Apr 2013 20:54:06 -0700 (PDT) Received: from 172.18.7.190 (EHLO lhreml204-edg.china.huawei.com) ([172.18.7.190]) by lhrrg02-dlp.huawei.com (MOS 4.3.5-GA FastPath queued) with ESMTP id AQH61305; Fri, 12 Apr 2013 03:54:03 +0000 (GMT) Received: from LHREML404-HUB.china.huawei.com (10.201.5.218) by lhreml204-edg.china.huawei.com (172.18.7.223) with Microsoft SMTP Server (TLS) id 14.1.323.7; Fri, 12 Apr 2013 04:53:27 +0100 Received: from NKGEML403-HUB.china.huawei.com (10.98.56.34) by lhreml404-hub.china.huawei.com (10.201.5.218) with Microsoft SMTP Server (TLS) id 14.1.323.7; Fri, 12 Apr 2013 11:54:01 +0800 Received: from NKGEML501-MBS.china.huawei.com ([169.254.2.126]) by nkgeml403-hub.china.huawei.com ([10.98.56.34]) with mapi id 14.01.0323.007; Fri, 12 Apr 2013 11:53:57 +0800 From: Qin Wu To: "Ali C. Begen (abegen)" , "avt@ietf.org" Thread-Topic: =?utf-8?B?W0FWVENPUkVdIOetlOWkjTogIFJlbWluZGVyOiBSZTogV0cgbGFzdCBjYWxs?= =?utf-8?Q?_on_draft-ietf-avtcore-6222bis-01?= Thread-Index: AQHONqs60PeNlZ/7qUyGM6+DIfLpgJjR9UAw Date: Fri, 12 Apr 2013 03:53:56 +0000 Message-ID: References: In-Reply-To: Accept-Language: zh-CN, en-US Content-Language: zh-CN X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [10.138.41.149] Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 MIME-Version: 1.0 X-CFilter-Loop: Reflected Subject: [AVTCORE] =?utf-8?b?562U5aSNOiAg562U5aSNOiAgUmVtaW5kZXI6IFJlOiBX?= =?utf-8?q?G_last_call_on_draft-ietf-avtcore-6222bis-01?= X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 12 Apr 2013 03:54:08 -0000 VGhhbmtzLCB5b3UgY2xlYXIgbXkgY29tbWVudHMuDQoNClJlZ2FyZHMhDQotUWluDQotLS0tLemC ruS7tuWOn+S7ti0tLS0tDQrlj5Hku7bkuro6IGF2dC1ib3VuY2VzQGlldGYub3JnIFttYWlsdG86 YXZ0LWJvdW5jZXNAaWV0Zi5vcmddIOS7o+ihqCBBbGkgQy4gQmVnZW4gKGFiZWdlbikNCuWPkemA geaXtumXtDogMjAxM+W5tDTmnIgxMeaXpSAxOTo1Mg0K5pS25Lu25Lq6OiBRaW4gV3U7IGF2dEBp ZXRmLm9yZw0K5Li76aKYOiBSZTogW0FWVENPUkVdIOetlOWkjTogUmVtaW5kZXI6IFJlOiBXRyBs YXN0IGNhbGwgb24gZHJhZnQtaWV0Zi1hdnRjb3JlLTYyMjJiaXMtMDENCg0KLS0tLS1PcmlnaW5h bCBNZXNzYWdlLS0tLS0NCkZyb206IFFpbiBXdSA8YmlsbC53dUBodWF3ZWkuY29tPg0KRGF0ZTog VGh1cnNkYXksIEFwcmlsIDExLCAyMDEzIDI6MDQgUE0NClRvOiAiYXZ0QGlldGYub3JnIiA8YXZ0 QGlldGYub3JnPg0KU3ViamVjdDogW0FWVENPUkVdIOetlOWkjTogIFJlbWluZGVyOiBSZTogV0cg bGFzdCBjYWxsDQpvbglkcmFmdC1pZXRmLWF2dGNvcmUtNjIyMmJpcy0wMQ0KDQo+SGksIEFsaToN Cj5IZXJlIGlzIG15IHF1aWNrIHJldmlldyB0byBkcmFmdC1pZXRmLWF2dGNvcmUtNjIyMmJpcy0w MToNCj4xLiBTZWN0aW9uIDEgYW5kIFNlY3Rpb24gMzoNCj5JdCBpcyBub3QgY2xlYXIgaG93IHRo ZSBzZWN0aW9uIDEgaXMgcmVsYXRlZCB0byBzZWN0aW9uIDM/DQoNClNlY3Rpb24gMSBpcyBtb3Rp dmF0aW5nIHRoZSBuZWVkIGZvciB0aGUgYmlzIGRvY3VtZW50Lg0KDQo+SXMgdGhpcyBkcmFmdCBm b2N1c2luZyBvbiB0YWNraW5nIGxpbmthYmlsaXR5IGlzc3VlIG9yIGRlZmljaWVuY3kgaXNzdWVz DQo+ZGVzY3JpYmVkIGluIHNlY3Rpb24gMz8NCg0KVGhpcyBkcmFmdCBpcyBub3QgYW4gdXBkYXRl IG9uIDYyMjIsIGl0IHJlcGxhY2VzIGl0IHNvIGl0IGhhcyB0aGUgdGV4dA0KZnJvbSA2MjIyIGFz IHdlbGwuDQoNCj4gDQo+V2hhdCB0aGUgbGlua2FiaWxpdHkgaXNzdWUgaXM/IEl0IGlzIG5vdCBv YnZpb3VzIHRvIGEgcmVhZGVyIHdobyBhcmUgbm90DQo+ZmFtaWxpYXIgd2l0aCB0aGlzIGFsdGhv dWdoIHRoaXMgZHJhZnQgcG9pbnQgdG8NCj5bSS1ELnJlc2NvcmxhLWF2dGNvcmUtcmFuZG9tLWNu YW1lXSBpbiB0aGUgc2VjdGlvbiAxPw0KDQpGb3IgdGhlIHNha2Ugb2YgUlRDUCBDTkFNRSwgeW91 IGRvbnQgbmVlZCB0byBrbm93IHRoZSBkZXRhaWxzIG9mDQpsaW5rYWJpbGl0eSBjb25jZXJucyB0 aGUgcmVzY29ybGEgZHJhZnQgZGlzY3Vzc2VzLiBJdCBpcyBzaW1wbHkgdGhlcmUNCnNpbmNlIGl0 IHdhcyB0aGUgcmVhc29uIHdoeSB3ZSBzdGFydGVkIHRoaXMgYmlzIHdvcmsgaW4gdGhlIGZpcnN0 IHBsYWNlLg0KDQo+DQo+Mi4gUFJORyBuZWVkcyB0byBiZSBleHBhbmRlZCBvciBwb2ludCB0byBh IHJlZmVyZW5jZS4NCg0KV2lsbCBmaXggaXQuDQoNCj4NCj4zLiBTZWN0aW9uIDYuMQ0KPlRoZSBs YXN0IHNlbnRlbmNlIHNhaWQ6DQo+Ig0KPkEgbGVuZ3RoIG9mIDk2IGJpdHMgYWxsb3dzIG9uIHRo ZSBvcmRlciBvZg0KPjJeezQwfSBSVENQIENOQU1FcyBnbG9iYWxseSBiZWZvcmUgdGhlcmUgaXMg YSBsYXJnZSBjaGFuY2Ugb2YNCj5jb2xsaXNpb24gKHRoZXJlIGlzIGFib3V0IGEgNTAlIGNoYW5j ZSBvZiBvbmUgY29sbGlzaW9uIGFmdGVyIDJeezQ4fQ0KPlJUQ1AgQ05BTUVzKS4NCj4iDQo+SSBh bSBkaWZmaWN1bHQgdG8gdW5kZXJzdGFuZCB0aGUgcmF0aW9uYWxlIGZvciB0aGlzIGNhbGN1bGF0 aW9uIHNpbmNlIEkNCj5kb24ndCBrbm93IFdoYXQgIjJeezQwfSIgc3RhbmQgZm9yPw0KPkhvdyAi NDAiIGlzIHJlbGF0ZWQgdG8gdGhlIGxlbmd0aCBvZiA5NiBiaXRzPw0KDQpUaGlzIGluZm8gY29t ZXMgZnJvbQ0KaHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQtcmVzY29ybGEtYXZ0Y29y ZS1yYW5kb20tY25hbWUtMDAgc2VjdGlvbg0KNC4gRXJpYyBtaWdodCBwcm92aWRlIG1vcmUgaW5m byBpZiB5b3UgbmVlZC4NCg0KPg0KPjQuNi4yDQo+SSBjYW4gdW5kZXJzdGFuZCB0aGUgZmlyc3Qg c2VudGVuY2UsIGJ1dCBJIGRvbid0IHVuZGVyc3RhbmQgdGhlIHNlY29uZA0KPm9uZS4gDQo+V2hh dCBraW5kIG9mIGNvcnJlbGF0aW9uIG5lZWQgdG8gYmUgcHJldmVudGVkPyBXaHkgc3VjaCBjb3Jy ZWxhdGlvbg0KPnNob3VsZCBiZSBwcmV2ZW50ZWQ/DQoNCklmIHlvdSBrZWVwIHVzaW5nIHRoZSBz YW1lIFJUQ1AgQ05BTUUgaW4gYWxsIG9mIHlvdXIgc2Vzc2lvbnMsIHNvbWVvbmUNCm1pZ2h0IHRy YWNrIHlvdS4gSW4gc29tZSBjYXNlcywgeW91IG1pZ2h0IHdhbnQgdGhhdCwgaW4gc29tZSBjYXNl cyB5b3UNCndvbid0LiBUaGF0IGlzIHdoYXQgdGhpcyBzZWN0aW9ucyBpcyBzYXlpbmcgeW91LiBC YXNlZCBvbiB3aGF0IHlvdSB3YW50LA0KY2hvb3NlIGEgcGVyc2lzdGVudCB2cyBwZXItc2Vzc2lv biBSVENQIENOQU1FLg0KDQo+SXNuJ3QgdGhpcyBzZWN0aW9uIGZvY3VzaW5nIG9uIHRhbGtpbmcg YWJvdXQgaG93IHRvIGNvcnJlbGF0ZSBzZXNzaW9ucz8NCj5XaGF0IGFtIEkgbWlzc2luZz8NCg0K SSBob3BlIGl0IGlzIGNsZWFyZXIgbm93Lg0KDQpUaGFua3MsDQotYWNiZWdlbg0KDQo+DQo+UmVn YXJkcyENCj4tUWluDQo+LS0tLS3pgq7ku7bljp/ku7YtLS0tLQ0KPuWPkeS7tuS6ujogYXZ0LWJv dW5jZXNAaWV0Zi5vcmcgW21haWx0bzphdnQtYm91bmNlc0BpZXRmLm9yZ10g5Luj6KGoIE1hZ251 cw0KPldlc3Rlcmx1bmQNCj7lj5HpgIHml7bpl7Q6IDIwMTPlubQ05pyIMTDml6UgMTU6NTgNCj7m lLbku7bkuro6IE1hZ251cyBXZXN0ZXJsdW5kDQo+5oqE6YCBOiBhdnRAaWV0Zi5vcmcNCj7kuLvp opg6IFJlOiBbQVZUQ09SRV0gUmVtaW5kZXI6IFJlOiBXRyBsYXN0IGNhbGwgb24NCj5kcmFmdC1p ZXRmLWF2dGNvcmUtNjIyMmJpcy0wMQ0KPg0KPldHLA0KPg0KPlRoaXMgV0cgbGFzdCBjYWxsIGhh cyBjb25jbHVkZWQuIEkgdGhpbmsgdGhlIGxldmVsIG9mIHJldmlld3Mgb24gdGhpcw0KPmRvY3Vt ZW50IGFyZSB2ZXJ5IGxvdy4gSW4gdGhlIHdvcmtpbmcgZ3JvdXAgbGFzdCBjYWxsIG9ubHkgS2V2 aW4gR3Jvc3MNCj5hbmQgSSBoYXZlIHN0YXRlZCB0aGF0IHRoZXkgaGF2ZSByZXZpZXdlZCB0aGUg bGF0ZXN0IHZlcnNpb24uDQo+DQo+QXV0aG9ycyBwbGVhc2UgYWRkcmVzcyByYWlzZWQgaXNzdWVz Lg0KPg0KPkkgd2lsbCBub3QgY29uc2lkZXIgdGhpcyBhIHN1Y2Nlc3NmdWwgV0cgbGFzdCBjYWxs IHVubGVzcyBhdCBsZWFzdCBvbmUNCj5hZGRpdGlvbmFsIHBlcnNvbiByZXZpZXdzIGl0IHdobyBh cmUgbm90IGFuIGF1dGhvci4gSXQgaXMgYSB2ZXJ5IHNob3J0DQo+ZG9jdW1lbnQgYW5kIGl0IGFs c28gZG9uJ3QgcmVxdWlyZSBtYXNzaXZlIGFtb3VudHMgb2YgYWRkaXRpb25hbA0KPmtub3dsZWRn ZSBiZXlvbmQgYmFzaWMgUlRQIHVuZGVyc3RhbmRpbmcgdG8gcmV2aWV3Lg0KPg0KPlJlZ2FyZHMN Cj4NCj5NYWdudXMgV2VzdGVybHVuZA0KPldHIGNoYWlyDQo+DQo+T24gMjAxMy0wMy0yOCAxMTow MSwgTWFnbnVzIFdlc3Rlcmx1bmQgd3JvdGU6DQo+PiBXRywNCj4+IA0KPj4gU28gZmFyIHRoZXJl IGhhcyBiZSBubyBvdGhlciByZXZpZXdzIG9mIHRoaXMgZG9jdW1lbnQgdGhhbiBtaW5lLg0KPj4g DQo+PiBDYW4gc29tZW9uZSBwbGVhc2UgcmV2aWV3IHRoaXMgZG9jdW1lbnQ/DQo+PiANCj4+IEkg aGVyZWJ5IGV4dGVuZGVkIHRoZSBXRyBsYXN0IGNhbGwgd2l0aCBvbmUgd2VlayB1bnRpbCB0aGUg N3RoIG9mIEFwcmlsLg0KPj4gDQo+PiBDaGVlcnMNCj4+IA0KPj4gTWFnbnVzDQo+PiANCj4+IE9u IDIwMTMtMDMtMTIgMjA6MDQsIE1hZ251cyBXZXN0ZXJsdW5kIHdyb3RlOg0KPj4+IFdHLA0KPj4+ DQo+Pj4gVGhpcyBpcyB0byBhbm5vdW5jZSB0aGUgc3RhcnQgb2YgYSBXRyBsYXN0IGNhbGwgb246 DQo+Pj4NCj4+PiBHdWlkZWxpbmVzIGZvciBDaG9vc2luZyBSVFAgQ29udHJvbCBQcm90b2NvbCAo UlRDUCkgQ2Fub25pY2FsIE5hbWVzDQo+Pj4gKENOQU1FcykgdG8gYmUgcHVibGlzaGVkIGFzIGEg cHJvcG9zZWQgc3RhbmRhcmQuDQo+Pj4NCj4+PiBEb2N1bWVudCBjYW4gYmUgcmV0cmlldmVkIGhl cmU6DQo+Pj4gaHR0cHM6Ly9kYXRhdHJhY2tlci5pZXRmLm9yZy9kb2MvZHJhZnQtaWV0Zi1hdnRj b3JlLTYyMjJiaXMvDQo+Pj4NCj4+PiBQbGVhc2UgcHJvdmlkZSBhbnkgZmVlZGJhY2sgYnkgdGhl IDMxc3Qgb2YgTWFyY2guDQo+Pj4NCj4+PiBSZWdhcmRzDQo+Pj4NCj4+PiBNYWdudXMgV2VzdGVy bHVuZA0KPj4+IFdHIGNoYWlyDQo+Pj4NCj4+Pg0KPj4+IC0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCj4+PiBNdWx0 aW1lZGlhIFRlY2hub2xvZ2llcywgRXJpY3Nzb24gUmVzZWFyY2ggRUFCL1RWTQ0KPj4+IC0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0NCj4+PiBFcmljc3NvbiBBQiAgICAgICAgICAgICAgICB8IFBob25lICArNDYgMTAg NzE0ODI4Nw0KPj4+IEbDpHLDtmdhdGFuIDYgICAgICAgICAgICAgICAgfCBNb2JpbGUgKzQ2IDcz IDA5NDkwNzkNCj4+PiBTRS0xNjQgODAgU3RvY2tob2xtLCBTd2VkZW58IG1haWx0bzogbWFnbnVz Lndlc3Rlcmx1bmRAZXJpY3Nzb24uY29tDQo+Pj4gLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPj4+DQo+Pj4gX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+PiBBdWRpby9W aWRlbyBUcmFuc3BvcnQgQ29yZSBNYWludGVuYW5jZQ0KPj4+IGF2dEBpZXRmLm9yZw0KPj4+IGh0 dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vYXZ0DQo+Pj4NCj4+Pg0KPj4gDQo+ PiANCj4NCj4NCj4tLSANCj4NCj5NYWdudXMgV2VzdGVybHVuZA0KPg0KPi0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0N Cj5NdWx0aW1lZGlhIFRlY2hub2xvZ2llcywgRXJpY3Nzb24gUmVzZWFyY2ggRUFCL1RWTQ0KPi0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0NCj5Fcmljc3NvbiBBQiAgICAgICAgICAgICAgICB8IFBob25lICArNDYgMTAg NzE0ODI4Nw0KPkbDpHLDtmdhdGFuIDYgICAgICAgICAgICAgICAgfCBNb2JpbGUgKzQ2IDczIDA5 NDkwNzkNCj5TRS0xNjQgODAgU3RvY2tob2xtLCBTd2VkZW58IG1haWx0bzogbWFnbnVzLndlc3Rl cmx1bmRAZXJpY3Nzb24uY29tDQo+LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPg0KPl9fX19fX19fX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQo+QXVkaW8vVmlkZW8gVHJhbnNwb3J0IENv cmUgTWFpbnRlbmFuY2UNCj5hdnRAaWV0Zi5vcmcNCj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWls bWFuL2xpc3RpbmZvL2F2dA0KPl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fDQo+QXVkaW8vVmlkZW8gVHJhbnNwb3J0IENvcmUgTWFpbnRlbmFuY2UNCj5hdnRA aWV0Zi5vcmcNCj5odHRwczovL3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2F2dA0KPg0K DQoNCl9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fDQpBdWRp by9WaWRlbyBUcmFuc3BvcnQgQ29yZSBNYWludGVuYW5jZQ0KYXZ0QGlldGYub3JnDQpodHRwczov L3d3dy5pZXRmLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2F2dA0K From internet-drafts@ietf.org Sat Apr 13 03:34:56 2013 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 52DA921F8733; Sat, 13 Apr 2013 03:34:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.44 X-Spam-Level: X-Spam-Status: No, score=-102.44 tagged_above=-999 required=5 tests=[AWL=0.160, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pAN8WSgzh4KM; Sat, 13 Apr 2013 03:34:55 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id DAAAD21F8607; Sat, 13 Apr 2013 03:34:55 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.43.p4 Message-ID: <20130413103455.19455.13643.idtracker@ietfa.amsl.com> Date: Sat, 13 Apr 2013 03:34:55 -0700 Cc: avt@ietf.org Subject: [AVTCORE] I-D Action: draft-ietf-avtcore-6222bis-02.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Apr 2013 10:34:56 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Audio/Video Transport Core Maintenance Wo= rking Group of the IETF. Title : Guidelines for Choosing RTP Control Protocol (RTCP) Cano= nical Names (CNAMEs) Author(s) : Ali Begen Colin Perkins Dan Wing Eric Rescorla Filename : draft-ietf-avtcore-6222bis-02.txt Pages : 10 Date : 2013-04-13 Abstract: The RTP Control Protocol (RTCP) Canonical Name (CNAME) is a persistent transport-level identifier for an RTP endpoint. While the Synchronization Source (SSRC) identifier of an RTP endpoint may change if a collision is detected or when the RTP application is restarted, its RTCP CNAME is meant to stay unchanged, so that RTP endpoints can be uniquely identified and associated with their RTP media streams. For proper functionality, RTCP CNAMEs should be unique within the participants of an RTP session. However, the existing guidelines for choosing the RTCP CNAME provided in the RTP standard are insufficient to achieve this uniqueness. RFC 6222 was published to update those guidelines to allow endpoints to choose unique RTCP CNAMEs. Unfortunately, later investigations showed that some parts of the new algorithms were unnecessarily complicated and/or ineffective. This document addresses these concerns and replaces RFC 6222. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-avtcore-6222bis There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-avtcore-6222bis-02 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-avtcore-6222bis-02 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From abegen@cisco.com Sat Apr 13 03:44:06 2013 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 36F1921F8528 for ; Sat, 13 Apr 2013 03:44:06 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ZD+w5NAN0Mv7 for ; Sat, 13 Apr 2013 03:44:05 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id F047821F8523 for ; Sat, 13 Apr 2013 03:44:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3602; q=dns/txt; s=iport; t=1365849845; x=1367059445; h=from:to:subject:date:message-id:in-reply-to:content-id: content-transfer-encoding:mime-version; bh=ADJgPtuYdbUW2bR5G0gpeb9k/4DEKXayxbMxYQcDTRo=; b=Tq/WMDypQaFH9UzlH0me7Il2VwWRj3dTXziCXM9CP7KtzHtmtLr25ldD 82sUR3Bbodi7+hd4GdIcsqOPOXRDgpPsP0xdNU97L1CcKrbnxZXHkG/r0 JX/NH7frraT+PF2LLgqXQIFQqbEDlFKG85/d0/q5iwnlmu5zqoIrALQbc A=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AjMFAAs2aVGtJXG9/2dsb2JhbABQgmUhNkSCbL4eDXgWdIIfAQEBBAEBASARUQYBCBEDAQIDAgYgAgQlCxUICAIEEwgBiAsBBgWbGY5SkiKBI41BAiYSBoIoMmEDmCOPcIMLgig X-IronPort-AV: E=Sophos;i="4.87,468,1363132800"; d="scan'208";a="198358898" Received: from rcdn-core2-2.cisco.com ([173.37.113.189]) by rcdn-iport-8.cisco.com with ESMTP; 13 Apr 2013 10:44:04 +0000 Received: from xhc-aln-x03.cisco.com (xhc-aln-x03.cisco.com [173.36.12.77]) by rcdn-core2-2.cisco.com (8.14.5/8.14.5) with ESMTP id r3DAi4on032263 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL) for ; Sat, 13 Apr 2013 10:44:04 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-aln-x03.cisco.com ([173.36.12.77]) with mapi id 14.02.0318.004; Sat, 13 Apr 2013 05:44:04 -0500 From: "Ali C. Begen (abegen)" To: "avt@ietf.org" Thread-Topic: [AVTCORE] I-D Action: draft-ietf-avtcore-6222bis-02.txt Thread-Index: AQHOODKPqSyveEg+S0yJ9MQm6MP6c5jUfWGA Date: Sat, 13 Apr 2013 10:44:03 +0000 Message-ID: In-Reply-To: <20130413103455.19455.13643.idtracker@ietfa.amsl.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.2.130206 x-originating-ip: [10.61.98.159] Content-Type: text/plain; charset="utf-8" Content-ID: <4945303E334D57439272E500B6A0DCB6@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Subject: Re: [AVTCORE] I-D Action: draft-ietf-avtcore-6222bis-02.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 13 Apr 2013 10:44:06 -0000 SSB0aGluayB3ZSBnb3QgYWxsIHRoZSBlc3NlbnRpYWwgV0dMQyBjb21tZW50cyBhZGRyZXNzZWQg aW4gdGhpcyByZXZpc2lvbi4NCklmIHRoZXJlIGlzIHNvbWV0aGluZyB3ZSBza2lwcGVkLCBwbGVh c2UgbGV0IHVzIGtub3cuDQoNCi1hY2JlZ2VuDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0t DQpGcm9tOiAiaW50ZXJuZXQtZHJhZnRzQGlldGYub3JnIiA8aW50ZXJuZXQtZHJhZnRzQGlldGYu b3JnPg0KRGF0ZTogU2F0dXJkYXksIEFwcmlsIDEzLCAyMDEzIDE6MzQgUE0NClRvOiAiaS1kLWFu bm91bmNlQGlldGYub3JnIiA8aS1kLWFubm91bmNlQGlldGYub3JnPg0KQ2M6ICJhdnRAaWV0Zi5v cmciIDxhdnRAaWV0Zi5vcmc+DQpTdWJqZWN0OiBbQVZUQ09SRV0gSS1EIEFjdGlvbjogZHJhZnQt aWV0Zi1hdnRjb3JlLTYyMjJiaXMtMDIudHh0DQoNCj4NCj5BIE5ldyBJbnRlcm5ldC1EcmFmdCBp cyBhdmFpbGFibGUgZnJvbSB0aGUgb24tbGluZSBJbnRlcm5ldC1EcmFmdHMNCj5kaXJlY3Rvcmll cy4NCj4gVGhpcyBkcmFmdCBpcyBhIHdvcmsgaXRlbSBvZiB0aGUgQXVkaW8vVmlkZW8gVHJhbnNw b3J0IENvcmUgTWFpbnRlbmFuY2UNCj5Xb3JraW5nIEdyb3VwIG9mIHRoZSBJRVRGLg0KPg0KPglU aXRsZSAgICAgICAgICAgOiBHdWlkZWxpbmVzIGZvciBDaG9vc2luZyBSVFAgQ29udHJvbCBQcm90 b2NvbCAoUlRDUCkNCj5DYW5vbmljYWwgTmFtZXMgKENOQU1FcykNCj4JQXV0aG9yKHMpICAgICAg IDogQWxpIEJlZ2VuDQo+ICAgICAgICAgICAgICAgICAgICAgICAgICBDb2xpbiBQZXJraW5zDQo+ ICAgICAgICAgICAgICAgICAgICAgICAgICBEYW4gV2luZw0KPiAgICAgICAgICAgICAgICAgICAg ICAgICAgRXJpYyBSZXNjb3JsYQ0KPglGaWxlbmFtZSAgICAgICAgOiBkcmFmdC1pZXRmLWF2dGNv cmUtNjIyMmJpcy0wMi50eHQNCj4JUGFnZXMgICAgICAgICAgIDogMTANCj4JRGF0ZSAgICAgICAg ICAgIDogMjAxMy0wNC0xMw0KPg0KPkFic3RyYWN0Og0KPiAgIFRoZSBSVFAgQ29udHJvbCBQcm90 b2NvbCAoUlRDUCkgQ2Fub25pY2FsIE5hbWUgKENOQU1FKSBpcyBhDQo+ICAgcGVyc2lzdGVudCB0 cmFuc3BvcnQtbGV2ZWwgaWRlbnRpZmllciBmb3IgYW4gUlRQIGVuZHBvaW50LiAgV2hpbGUgdGhl DQo+ICAgU3luY2hyb25pemF0aW9uIFNvdXJjZSAoU1NSQykgaWRlbnRpZmllciBvZiBhbiBSVFAg ZW5kcG9pbnQgbWF5DQo+ICAgY2hhbmdlIGlmIGEgY29sbGlzaW9uIGlzIGRldGVjdGVkIG9yIHdo ZW4gdGhlIFJUUCBhcHBsaWNhdGlvbiBpcw0KPiAgIHJlc3RhcnRlZCwgaXRzIFJUQ1AgQ05BTUUg aXMgbWVhbnQgdG8gc3RheSB1bmNoYW5nZWQsIHNvIHRoYXQgUlRQDQo+ICAgZW5kcG9pbnRzIGNh biBiZSB1bmlxdWVseSBpZGVudGlmaWVkIGFuZCBhc3NvY2lhdGVkIHdpdGggdGhlaXIgUlRQDQo+ ICAgbWVkaWEgc3RyZWFtcy4NCj4NCj4gICBGb3IgcHJvcGVyIGZ1bmN0aW9uYWxpdHksIFJUQ1Ag Q05BTUVzIHNob3VsZCBiZSB1bmlxdWUgd2l0aGluIHRoZQ0KPiAgIHBhcnRpY2lwYW50cyBvZiBh biBSVFAgc2Vzc2lvbi4gIEhvd2V2ZXIsIHRoZSBleGlzdGluZyBndWlkZWxpbmVzIGZvcg0KPiAg IGNob29zaW5nIHRoZSBSVENQIENOQU1FIHByb3ZpZGVkIGluIHRoZSBSVFAgc3RhbmRhcmQgYXJl IGluc3VmZmljaWVudA0KPiAgIHRvIGFjaGlldmUgdGhpcyB1bmlxdWVuZXNzLiAgUkZDIDYyMjIg d2FzIHB1Ymxpc2hlZCB0byB1cGRhdGUgdGhvc2UNCj4gICBndWlkZWxpbmVzIHRvIGFsbG93IGVu ZHBvaW50cyB0byBjaG9vc2UgdW5pcXVlIFJUQ1AgQ05BTUVzLg0KPiAgIFVuZm9ydHVuYXRlbHks IGxhdGVyIGludmVzdGlnYXRpb25zIHNob3dlZCB0aGF0IHNvbWUgcGFydHMgb2YgdGhlIG5ldw0K PiAgIGFsZ29yaXRobXMgd2VyZSB1bm5lY2Vzc2FyaWx5IGNvbXBsaWNhdGVkIGFuZC9vciBpbmVm ZmVjdGl2ZS4gIFRoaXMNCj4gICBkb2N1bWVudCBhZGRyZXNzZXMgdGhlc2UgY29uY2VybnMgYW5k IHJlcGxhY2VzIFJGQyA2MjIyLg0KPg0KPg0KPlRoZSBJRVRGIGRhdGF0cmFja2VyIHN0YXR1cyBw YWdlIGZvciB0aGlzIGRyYWZ0IGlzOg0KPmh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5vcmcvZG9j L2RyYWZ0LWlldGYtYXZ0Y29yZS02MjIyYmlzDQo+DQo+VGhlcmUncyBhbHNvIGEgaHRtbGl6ZWQg dmVyc2lvbiBhdmFpbGFibGUgYXQ6DQo+aHR0cDovL3Rvb2xzLmlldGYub3JnL2h0bWwvZHJhZnQt aWV0Zi1hdnRjb3JlLTYyMjJiaXMtMDINCj4NCj5BIGRpZmYgZnJvbSB0aGUgcHJldmlvdXMgdmVy c2lvbiBpcyBhdmFpbGFibGUgYXQ6DQo+aHR0cDovL3d3dy5pZXRmLm9yZy9yZmNkaWZmP3VybDI9 ZHJhZnQtaWV0Zi1hdnRjb3JlLTYyMjJiaXMtMDINCj4NCj4NCj5JbnRlcm5ldC1EcmFmdHMgYXJl IGFsc28gYXZhaWxhYmxlIGJ5IGFub255bW91cyBGVFAgYXQ6DQo+ZnRwOi8vZnRwLmlldGYub3Jn L2ludGVybmV0LWRyYWZ0cy8NCj4NCj5fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fX19fXw0KPkF1ZGlvL1ZpZGVvIFRyYW5zcG9ydCBDb3JlIE1haW50ZW5hbmNlDQo+ YXZ0QGlldGYub3JnDQo+aHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9hdnQN Cj4NCg0KDQo= From ron.even.tlv@gmail.com Sat Apr 13 23:43:45 2013 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6A69421F8E6D for ; Sat, 13 Apr 2013 23:43:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.457 X-Spam-Level: X-Spam-Status: No, score=-0.457 tagged_above=-999 required=5 tests=[AWL=-0.628, BAYES_00=-2.599, DOS_OUTLOOK_TO_MX=1, FH_HOST_EQ_D_D_D_D=0.765, RCVD_IN_PBL=0.905, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 17M3497fkW+X for ; Sat, 13 Apr 2013 23:43:44 -0700 (PDT) Received: from mail-ea0-x232.google.com (mail-ea0-x232.google.com [IPv6:2a00:1450:4013:c01::232]) by ietfa.amsl.com (Postfix) with ESMTP id 88F1C21F8DA6 for ; Sat, 13 Apr 2013 23:43:44 -0700 (PDT) Received: by mail-ea0-f178.google.com with SMTP id o10so1788171eaj.23 for ; Sat, 13 Apr 2013 23:43:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:from:to:references:in-reply-to:subject:date:message-id :mime-version:content-type:content-transfer-encoding:x-mailer :content-language:thread-index; bh=zEJlt1l4InSmWJ7Mt7X84A7vFZyXAA4rV8ViUFAXSeE=; b=eN5oGzqOEC4AeKfWUlyX8r1i1DsG7IQx0n/g6ZiRQjLaQn32yIK81oQXwiQUpBtwEI O3csJHO3suAMwdTUi9WYRZXfTvylE/nJSk2SsruL8Lsmpn2ovj1YAfJfx3TpOo7x+ALw 8lePUxOReCVBRUgQeyC3VXJoxozaiFJ1SEyC2g+uQLBO7aN8hz2KPw+C7U2/wjJocbqb dVQ+ll/wYjYVJUKPGh7OAuAEkj8rUYNVvrXMEJQNEq2/3EDYIcYxe4brObY7xwBzYHOC EGBZFpC1BJLsEllEOUlObWjplrVEmgBtGKPENEg5x2wYTGAKgoZ4wZDTPXq7nay/P7dn b4ZA== X-Received: by 10.14.183.198 with SMTP id q46mr47590816eem.1.1365921823541; Sat, 13 Apr 2013 23:43:43 -0700 (PDT) Received: from RoniE (bzq-79-181-177-28.red.bezeqint.net. [79.181.177.28]) by mx.google.com with ESMTPS id ch6sm3122010eeb.17.2013.04.13.23.43.40 (version=TLSv1 cipher=RC4-SHA bits=128/128); Sat, 13 Apr 2013 23:43:42 -0700 (PDT) From: "Roni Even" To: "'Ali C. Begen \(abegen\)'" , References: <20130413103455.19455.13643.idtracker@ietfa.amsl.com> In-Reply-To: Date: Sun, 14 Apr 2013 09:43:11 +0300 Message-ID: <008f01ce38db$56eb5660$04c20320$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Mailer: Microsoft Outlook 14.0 Content-Language: en-us Thread-Index: AQJwIAslsBa3811Sdezj4z7q/RHeX5eRdnIA Subject: Re: [AVTCORE] I-D Action: draft-ietf-avtcore-6222bis-02.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Apr 2013 06:43:45 -0000 Hi Ali, My comments are addressed in this version. Roni -----Original Message----- From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of Ali C. Begen (abegen) Sent: 13 April, 2013 1:44 PM To: avt@ietf.org Subject: Re: [AVTCORE] I-D Action: draft-ietf-avtcore-6222bis-02.txt I think we got all the essential WGLC comments addressed in this revision. If there is something we skipped, please let us know. -acbegen -----Original Message----- From: "internet-drafts@ietf.org" Date: Saturday, April 13, 2013 1:34 PM To: "i-d-announce@ietf.org" Cc: "avt@ietf.org" Subject: [AVTCORE] I-D Action: draft-ietf-avtcore-6222bis-02.txt > >A New Internet-Draft is available from the on-line Internet-Drafts >directories. > This draft is a work item of the Audio/Video Transport Core >Maintenance Working Group of the IETF. > > Title : Guidelines for Choosing RTP Control Protocol (RTCP) >Canonical Names (CNAMEs) > Author(s) : Ali Begen > Colin Perkins > Dan Wing > Eric Rescorla > Filename : draft-ietf-avtcore-6222bis-02.txt > Pages : 10 > Date : 2013-04-13 > >Abstract: > The RTP Control Protocol (RTCP) Canonical Name (CNAME) is a > persistent transport-level identifier for an RTP endpoint. While the > Synchronization Source (SSRC) identifier of an RTP endpoint may > change if a collision is detected or when the RTP application is > restarted, its RTCP CNAME is meant to stay unchanged, so that RTP > endpoints can be uniquely identified and associated with their RTP > media streams. > > For proper functionality, RTCP CNAMEs should be unique within the > participants of an RTP session. However, the existing guidelines for > choosing the RTCP CNAME provided in the RTP standard are insufficient > to achieve this uniqueness. RFC 6222 was published to update those > guidelines to allow endpoints to choose unique RTCP CNAMEs. > Unfortunately, later investigations showed that some parts of the new > algorithms were unnecessarily complicated and/or ineffective. This > document addresses these concerns and replaces RFC 6222. > > >The IETF datatracker status page for this draft is: >https://datatracker.ietf.org/doc/draft-ietf-avtcore-6222bis > >There's also a htmlized version available at: >http://tools.ietf.org/html/draft-ietf-avtcore-6222bis-02 > >A diff from the previous version is available at: >http://www.ietf.org/rfcdiff?url2=draft-ietf-avtcore-6222bis-02 > > >Internet-Drafts are also available by anonymous FTP at: >ftp://ftp.ietf.org/internet-drafts/ > >_______________________________________________ >Audio/Video Transport Core Maintenance >avt@ietf.org >https://www.ietf.org/mailman/listinfo/avt > _______________________________________________ Audio/Video Transport Core Maintenance avt@ietf.org https://www.ietf.org/mailman/listinfo/avt From magnus.westerlund@ericsson.com Mon Apr 15 02:54:43 2013 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AB6DC21F9362 for ; Mon, 15 Apr 2013 02:54:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.249 X-Spam-Level: X-Spam-Status: No, score=-106.249 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id G96D48BpGwXP for ; Mon, 15 Apr 2013 02:54:43 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 8FCD821F9357 for ; Mon, 15 Apr 2013 02:54:42 -0700 (PDT) X-AuditID: c1b4fb30-b7f266d000000cb5-f8-516bce612d7a Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 6C.73.03253.16ECB615; Mon, 15 Apr 2013 11:54:41 +0200 (CEST) Received: from [127.0.0.1] (153.88.115.8) by esessmw0184.eemea.ericsson.se (153.88.115.82) with Microsoft SMTP Server id 8.3.279.1; Mon, 15 Apr 2013 11:54:41 +0200 Message-ID: <516BCE60.6050707@ericsson.com> Date: Mon, 15 Apr 2013 11:54:40 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: "Ali C. Begen (abegen)" References: In-Reply-To: X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFuplluLIzCtJLcpLzFFi42KZGfG3VjfxXHagQXO7psWD7XMZLV72rGR3 YPKY8nsjq8eSJT+ZApiiuGxSUnMyy1KL9O0SuDLaV95iK5iuUNF77SZrA+MpyS5GTg4JAROJ 9XdesUDYYhIX7q1n62Lk4hASOMUo0fHgJDOEs5xR4vP3OYxdjBwcvALaErNnVoM0sAioStzr +wfWzCZgIXHzRyMbSImoQLDE1tYYkDCvgKDEyZlPwEpEBPQk9ndMA5vCLKAoMakd7ARhAReJ N42HmUDCQgI+Eq/PhoKEOQV8Jd6+ecEEcZmkxJYX7ewgNjPQlClXWxghbHmJ5q2zmUFsIaC7 Gpo6WCcwCs1CsngWkpZZSFoWMDKvYmTPTczMSS8338QIDNKDW34b7GDcdF/sEKM0B4uSOG+4 64UAIYH0xJLU7NTUgtSi+KLSnNTiQ4xMHJxSDYxx6q+4IiqL9SzsH77+uDjsyJ+IOftjNN2f bs7W4lu5V01N0ePx7Lknbhlvrtm4aVWrHN8et4Obz32KE9Z+uj75g98l9X4bA5n4d7srN953 +1KovcV98cTXQvfqWXfPSSg/OTN9d4RowE6/qnn3g9/FHf40R+nkbQOu2Xuc47Yvv/at8YXe epNMJZbijERDLeai4kQA+98pQCACAAA= Cc: "avt@ietf.org" Subject: Re: [AVTCORE] I-D Action: draft-ietf-avtcore-6222bis-02.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Apr 2013 09:54:43 -0000 Hi, (as individual) I realize one part of my first issue was the question of how commonly MAC addresses are going to be having the intended uniqueness properties. This got a bit lost dealing with the equally important aspect that you need to keep the one you have generated across any mobility event etc. The comment from Steve Underwood, do raise this as being a genuine issue in some cases. What I believe would be good, is to make it clear that an implementation may have issues with using MAC address in certain types of environments, like virtulazation. I think the simple fix is to press that using a stored random value might have better properties. Cheers Magnus On 2013-04-13 12:44, Ali C. Begen (abegen) wrote: > I think we got all the essential WGLC comments addressed in this revision. > If there is something we skipped, please let us know. > > -acbegen > > -----Original Message----- > From: "internet-drafts@ietf.org" > Date: Saturday, April 13, 2013 1:34 PM > To: "i-d-announce@ietf.org" > Cc: "avt@ietf.org" > Subject: [AVTCORE] I-D Action: draft-ietf-avtcore-6222bis-02.txt > >> >> A New Internet-Draft is available from the on-line Internet-Drafts >> directories. >> This draft is a work item of the Audio/Video Transport Core Maintenance >> Working Group of the IETF. >> >> Title : Guidelines for Choosing RTP Control Protocol (RTCP) >> Canonical Names (CNAMEs) >> Author(s) : Ali Begen >> Colin Perkins >> Dan Wing >> Eric Rescorla >> Filename : draft-ietf-avtcore-6222bis-02.txt >> Pages : 10 >> Date : 2013-04-13 >> >> Abstract: >> The RTP Control Protocol (RTCP) Canonical Name (CNAME) is a >> persistent transport-level identifier for an RTP endpoint. While the >> Synchronization Source (SSRC) identifier of an RTP endpoint may >> change if a collision is detected or when the RTP application is >> restarted, its RTCP CNAME is meant to stay unchanged, so that RTP >> endpoints can be uniquely identified and associated with their RTP >> media streams. >> >> For proper functionality, RTCP CNAMEs should be unique within the >> participants of an RTP session. However, the existing guidelines for >> choosing the RTCP CNAME provided in the RTP standard are insufficient >> to achieve this uniqueness. RFC 6222 was published to update those >> guidelines to allow endpoints to choose unique RTCP CNAMEs. >> Unfortunately, later investigations showed that some parts of the new >> algorithms were unnecessarily complicated and/or ineffective. This >> document addresses these concerns and replaces RFC 6222. >> >> >> The IETF datatracker status page for this draft is: >> https://datatracker.ietf.org/doc/draft-ietf-avtcore-6222bis >> >> There's also a htmlized version available at: >> http://tools.ietf.org/html/draft-ietf-avtcore-6222bis-02 >> >> A diff from the previous version is available at: >> http://www.ietf.org/rfcdiff?url2=draft-ietf-avtcore-6222bis-02 >> >> >> Internet-Drafts are also available by anonymous FTP at: >> ftp://ftp.ietf.org/internet-drafts/ >> >> _______________________________________________ >> Audio/Video Transport Core Maintenance >> avt@ietf.org >> https://www.ietf.org/mailman/listinfo/avt >> > > > _______________________________________________ > Audio/Video Transport Core Maintenance > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt > -- Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From magnus.westerlund@ericsson.com Tue Apr 16 01:45:13 2013 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DCE5321F9687 for ; Tue, 16 Apr 2013 01:45:13 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.349 X-Spam-Level: X-Spam-Status: No, score=-105.349 tagged_above=-999 required=5 tests=[AWL=-0.900, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_33=0.6, J_CHICKENPOX_47=0.6, J_CHICKENPOX_48=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Cj-qeLdHsF15 for ; Tue, 16 Apr 2013 01:45:13 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id CFB8321F9686 for ; Tue, 16 Apr 2013 01:45:12 -0700 (PDT) X-AuditID: c1b4fb25-b7f366d000004d10-94-516d0f972814 Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 3D.99.19728.79F0D615; Tue, 16 Apr 2013 10:45:11 +0200 (CEST) Received: from [127.0.0.1] (153.88.115.8) by esessmw0191.eemea.ericsson.se (153.88.115.85) with Microsoft SMTP Server id 8.3.279.1; Tue, 16 Apr 2013 10:45:11 +0200 Message-ID: <516D0F96.9040602@ericsson.com> Date: Tue, 16 Apr 2013 10:45:10 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: Gonzalo Camarillo References: <20130410131256.CBFFFB1E006@rfc-editor.org> <5166A6D0.4090201@ericsson.com> In-Reply-To: <5166A6D0.4090201@ericsson.com> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprOLMWRmVeSWpSXmKPExsUyM+Jvre50/txAg9dnDSxe9qxkt1j+8gSj xa6j+5kcmD2m3b/P5rFkyU8mjxO7XQOYo7hsUlJzMstSi/TtErgy7rxfzFRwWrLiz5cDrA2M s0S6GDk5JARMJKaumssIYYtJXLi3nq2LkYtDSOAUo8T+zS+hnOWMEg8e9bKDVPEKaEt8+r2G DcRmEVCVeHTmHpjNJmAhcfNHI5DNwSEqECyxtTUGolxQ4uTMJywgtoiAmcT7f6uYQGxmgRSJ U82LwBYLCzhKdJ9/BNYqJBAuMe+4A4jJKaAj8fZMBcRpkhJbXrSzQ3TqSUy52sIIYctLNG+d zQxiCwEd1tDUwTqBUWgWksWzkLTMQtKygJF5FSN7bmJmTnq50SZGYOAe3PJbdQfjnXMihxil OViUxHnDXS8ECAmkJ5akZqemFqQWxReV5qQWH2Jk4uCUamB0sJasSFs2UYU7eupVOZve6aWT xY8mTUt12pZ1UlK6VoXt+Atmq/bvXU2TLL177HRCjU6FHZkUVGzFZmeY+uCRifpzm9KZItmN p8/pfN7dP++jo7TOda2WVtXE2p87eUr8p3vutzD5fjx/ie6Jxufmr5Rsn1kv3LQ6I/lQ4LOJ 4qyn/4sYblZiKc5INNRiLipOBADQNHiOKgIAAA== Cc: piers.ohanlon@oii.ox.ac.uk, ingemar.s.johansson@ericsson.com, avt@ietf.org, csp@csperkins.org Subject: Re: [AVTCORE] [Editorial Errata Reported] RFC6679 (3586) X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 16 Apr 2013 08:45:14 -0000 On 2013-04-11 14:04, Gonzalo Camarillo wrote: > Hi, > > would anybody object to put this erratum into the "held for document > update" status? I am okay with held for document update, although I would prefer verified as I think it is an important, but editorial errata. Cheers Magnus > > Cheers, > > Gonzalo > > On 10/04/2013 4:12 PM, RFC Errata System wrote: >> The following errata report has been submitted for RFC6679, >> "Explicit Congestion Notification (ECN) for RTP over UDP". >> >> -------------------------------------- >> You may review the report below and at: >> http://www.rfc-editor.org/errata_search.php?rfc=6679&eid=3586 >> >> -------------------------------------- >> Type: Editorial >> Reported by: Magnus Westerlund >> >> Section: 12.1 >> >> Original Text >> ------------- >> The Offer: >> >> ... >> a=ecn-capable-rtp: ice rtp ect=0 mode=setread >> ... >> >> The Answer: >> ... >> a=ecn-capable-rtp: ice ect=0 mode=readonly >> ... >> >> Corrected Text >> -------------- >> The Offer: >> >> ... >> a=ecn-capable-rtp: ice,rtp ect=0; mode=setread >> ... >> >> The Answer: >> ... >> a=ecn-capable-rtp: ice ect=0; mode=readonly >> ... >> >> Notes >> ----- >> The examples does not match the ABNF rules for the a=ecn-capaable-rtp attribute. Two issues are present, first the init method list must be comma separated with no spaces, secondly any additional parameters shall be semi colon plus space separated. Therefore both a=ecn-capable-rtp lines have been corrected. >> >> This is primarily an editorial issues but people needs to aware of the errors in the example. >> >> Instructions: >> ------------- >> This errata is currently posted as "Reported". If necessary, please >> use "Reply All" to discuss whether it should be verified or >> rejected. When a decision is reached, the verifying party (IESG) >> can log in to change the status and edit the report, if necessary. >> >> -------------------------------------- >> RFC6679 (draft-ietf-avtcore-ecn-for-rtp-08) >> -------------------------------------- >> Title : Explicit Congestion Notification (ECN) for RTP over UDP >> Publication Date : August 2012 >> Author(s) : M. Westerlund, I. Johansson, C. Perkins, P. O'Hanlon, K. Carlberg >> Category : PROPOSED STANDARD >> Source : Audio/Video Transport Core Maintenance >> Area : Real-time Applications and Infrastructure >> Stream : IETF >> Verifying Party : IESG >> > > _______________________________________________ > Audio/Video Transport Core Maintenance > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt > > -- Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From kevin.gross@avanw.com Wed Apr 17 15:41:32 2013 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5566221E80E6 for ; Wed, 17 Apr 2013 15:41:32 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.686 X-Spam-Level: X-Spam-Status: No, score=-0.686 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_16=0.6, SARE_SUB_6CONS_WORD=0.356] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id I5E5oMFc9-uo for ; Wed, 17 Apr 2013 15:41:31 -0700 (PDT) Received: from oproxy9.bluehost.com (oproxy9.bluehost.com [69.89.24.6]) by ietfa.amsl.com (Postfix) with SMTP id DBF7C21E80E1 for ; Wed, 17 Apr 2013 15:41:30 -0700 (PDT) Received: (qmail 14335 invoked by uid 0); 17 Apr 2013 22:41:08 -0000 Received: from unknown (HELO host291.hostmonster.com) (74.220.215.91) by oproxy9.bluehost.com with SMTP; 17 Apr 2013 22:41:08 -0000 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=avanw.com; s=default; h=Content-Type:Cc:To:From:Subject:Message-ID:Date:References:In-Reply-To:MIME-Version; bh=amp7DueLMR+9fSUOXJhNweZIhRcHQs7ZeOrWH9bzzMc=; b=g+eiV6lSAZdwc/G/Q/0DvfX4zOyPN15Vcxyq5Wyew9JwhIS8eWpzoYGAKYROxFUtrO7U24mt+PB/Dvqxy7c8p7i3IarN5XqRondNlHAzRcOFApYdIkGsipoIcUVst/2a; Received: from [209.85.210.176] (port=63738 helo=mail-ia0-f176.google.com) by host291.hostmonster.com with esmtpsa (TLSv1:RC4-SHA:128) (Exim 4.80) (envelope-from ) id 1USb2K-0003MY-AI for avt@ietf.org; Wed, 17 Apr 2013 16:41:08 -0600 Received: by mail-ia0-f176.google.com with SMTP id i9so1889838iad.7 for ; Wed, 17 Apr 2013 15:41:07 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=amp7DueLMR+9fSUOXJhNweZIhRcHQs7ZeOrWH9bzzMc=; b=o/AfFXoywiJgXhasYy9tzF85H5btJ5mYFHGmznS60zed8E2uoU6Q8OhzqeAAuMWVIY ppmKY4dMNatydU++cVi+ZSqVjy45V+qSfCoCJ3weKONm2yIgPUFm2xr6hm9YDQ2D3eAf 15uAp/l4dkMDd++0tE8oJFfmBFf1s9zV/JfBUyX5vA3YmkbsEZCaheGAbffQqiTrTan5 +xk7Fb/ReVzMCGkgzk4kbhrN1Z/++1jUxXjEPOpnMeaNuZWLS736/Eqh93B+i///00vg S/3DBOTunCEaWsz0QLrm6YBz3kGbMhOBbJXQyjiFYWTVA8UOfBhS/htXy3N5IJB7St49 NsXA== MIME-Version: 1.0 X-Received: by 10.50.117.3 with SMTP id ka3mr11220766igb.107.1366238467347; Wed, 17 Apr 2013 15:41:07 -0700 (PDT) Received: by 10.50.180.201 with HTTP; Wed, 17 Apr 2013 15:41:07 -0700 (PDT) In-Reply-To: <5163DF09.7050606@ericsson.com> References: <5163DF09.7050606@ericsson.com> Date: Wed, 17 Apr 2013 16:41:07 -0600 Message-ID: From: Kevin Gross To: Magnus Westerlund Content-Type: multipart/alternative; boundary=089e01175f6d865cc404da962e81 X-Identified-User: {1416:host291.hostmonster.com:avanwcom:avanw.com} {sentby:smtp auth 209.85.210.176 authed with kevin.gross@avanw.com} Cc: IETF AVTCore WG Subject: Re: [AVTCORE] Comments on draft-ietf-avtcore-clksrc-03 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Apr 2013 22:41:32 -0000 --089e01175f6d865cc404da962e81 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Magnus, Thanks for looking at this and sorry for the delay responding. I agree that mediaclk-ext is too restrictive. Your suggestion is very accommodating Something a bit more structured such as 'token "=3D" byte-string' might be more appropriate. I will check with my co authors on this. As there is great precedent for it in SDP, we have implemented a simple offer-answer model. I would propose that systems should use the mechanisms defined in RFC 5939 if negotiation of clock configurations is necessary. Perhaps adding some discussion and a reference to this RFC would help. I don't think that independently negotiating reference and media clocks as you have suggested will be adequate. Under some implementations, while multiple clocks are supported, certain combinations of media and reference clocks may not be allowed. Kevin Gross +1-303-447-0517 Media Network Consultant AVA Networks - www.AVAnw.com , www.X192.org On Tue, Apr 9, 2013 at 3:27 AM, Magnus Westerlund < magnus.westerlund@ericsson.com> wrote: > Hi, > > I promised doing an review of the O/A section. I also found some other > issues to consider. > > 1. Section 5.4: > > Figure 5 shows the ABNF [5] grammar for the SDP media clock source > information. > > mediaclk-master =3D "a=3Dssrc:" integer SP clk-master-id > > clk-master-id =3D "mediaclk:master-id=3D" master-id > > timestamp-mediaclk =3D "a=3Dmediaclk:" mediaclock > > mediaclock =3D sender / refclk / streamid / mediaclock-ext > > sender =3D "sender" sender-ext > > sender-ext =3D token > > refclk =3D "direct" [ "=3D" 1*DIGIT ] [rate] [direct-ext] > > rate =3D [ SP "rate=3D" integer "/" integer ] > > direct-ext =3D token > > streamid =3D "master-id=3D" master-id > streamid =3D/ "IEEE1722=3D" avb-stream-id > streamid =3D/ streamid-ext > > master-id =3D EUI48 > avb-stream-id =3D EUI64 > > EUI48 =3D 5(2HEXDIG ":") 2HEXDIG > EUI64 =3D 7(2HEXDIG ":") 2HEXDIG > > streamid-ext =3D token > > mediaclock-ext =3D token > > I wonder if not the mediaclock-ext construction is to restrictive. As > the refclk produces a sting with white-spaces in it, why isn't other > mediaclock-ext allowed the same freedom? I think the mediaclock-ext can > be basically byte-string, i.e. any character allowed on an SDP line > should be possible to use. Likely the only resteriction should be that > it starts with a token. Thus using: > > mediaclock-ext =3D token [SP byte-string] > > This would require a token for identifying the method followed by a > space and then full freedom for anything that is allowed on an SDP > attribute value. > > > 2. Section 6: > > Purpose of signalling? > > I think this type of signalling can select two levels of goals with > signalling: > > 1) Declaring what each SDP O/A uses on its side > > 2) Negotiating to arrive at the best but available mechanism on both side= s. > > The currently proposed solution does neither of these. It enables the > offerer to express to declare I intended to use X and for the answer to > say I know that, or simply say I can't tell you because we are not > having the same clocks. > > I think we need to be clear what our goals are here. And I will propose > some goals with the signalling based on my understanding of how these > defined timestamp reference clocks and media stream clocks can be used. > And we do need to be aware that different application may have different > needs. > > Goal with signalling: > > 1. Enable each media sender to declare its actually used ts-refclk, i.e. > what clock is base for the RTCP SR NTP timestamps > 2. Enable each media sender to identify what clock reference is used to > check/drive the media sampling, i.e. RTP timestamp advancement. > 3. Enable two media sender using SDP O/A to determine what common clocks > they actually have so they can be used in either of ts-refclk or mediaclk= . > > The purpose of doing three (3) is really so that one can do the following= . > A. has three ts-refclk it can use. B has two ts-refclk available. They > are going to watch social TV. To make it at all possible for the social > TV service to play out content at A and B in sync they need to have > either of these two things be available. > > a) Each has a common clock with the TV service > b) A and B has a common clock > > In either of the scenario the TV service will be able to ensure that the > media is played out is sync. > > > As a technical solution to these issues there are two main solution track= s: > > 1) Change the respective SDP attributes to provide info on all possible > clocks for that it could be using and let the answer select the most > preferred that both are supporting > > 2) Leave the current SDP attributes as they are and only use them for > declaration that: I use this! Then add new SDP attributes to negotiate > the list of commonly supported clocks. > > At this stage I think 2) is what is simplest and require the least > changes to what already exist. > > I will note that this is likely to require a second round of O/A > messages to update used clocks if the arrived common clock(s) are not > the default used ones. But, I don't see a way around these. In SIP one > could use OPTIONS to provide a SDP which includes the negotiation > attribute to enable the other side to select using a clock that is > supported by both. But when that isn't done, it will take two rounds or > other a'priori knowledge. > > So my proposal is simply that one create two new SDP attributes one for > each type of clock usage (ts-refclk and mediaclk) and include a list of > clock type and any ID of the clock in a priority order. The O/A is basic > negotiated and the answer removes all clocks it doesn't support and adds > all it supports. Hopefully there is someone in the list that is common. > The highest priority between the two parties should be used when common > clock is required. IF that is not, then these attributes should not be > included. This for example allows one to use a common ts-refclk, but not > require common mediaclk. We should also discuss if the answerer may > change the priority of commonly supported, and if it should or should > not add additional clocks it supports that are not common. > > I really appreciate feedback on these comments and ideas. > > Cheers > > Magnus Westerlund > > ---------------------------------------------------------------------- > Multimedia Technologies, Ericsson Research EAB/TVM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > F=E4r=F6gatan 6 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- > > _______________________________________________ > Audio/Video Transport Core Maintenance > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt > --089e01175f6d865cc404da962e81 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Magnus,

Thanks for looking at thi= s and sorry for the delay responding.

= I agree that mediaclk-ext is too restrictive. Your suggestion is very=A0acc= ommodating=A0 Something a bit more structured such as 'token "=3D&= quot; byte-string' might be more appropriate. I will=A0check=A0with my = co authors on this.

As there is great=A0precedent for it in SDP= , we have implemented a simple offer-answer model. I would propose that sys= tems should use the mechanisms defined in RFC 5939 if negotiation of clock = configurations is necessary. Perhaps adding some discussion and a=A0referen= ce=A0to this RFC would help.

I don't think that independently negoti= ating reference=A0and=A0media clocks as you have suggested will be adequate= . Under some implementations, while multiple clocks are supported, certain = combinations of media and reference clocks may not be allowed.

Kevin Gross
+1-303-447-0517


On Tue, Apr 9, 2013 at 3:27 AM, Magnus W= esterlund <magnus.westerlund@ericsson.com> wrot= e:
Hi,

I promised doing an review of the O/A section. I also found some other
issues to consider.

1. Section 5.4:

Figure 5 shows the ABNF [5] grammar for the SDP media clock source
=A0 =A0information.

=A0 =A0 =A0 =A0 =A0 mediaclk-master =3D "a=3Dssrc:" integer SP cl= k-master-id

=A0 =A0 =A0 =A0 =A0 clk-master-id =3D "mediaclk:master-id=3D" mas= ter-id

=A0 =A0 =A0 =A0 =A0 timestamp-mediaclk =3D "a=3Dmediaclk:" mediac= lock

=A0 =A0 =A0 =A0 =A0 mediaclock =3D sender / refclk / streamid / mediaclock-= ext

=A0 =A0 =A0 =A0 =A0 sender =3D "sender" sender-ext

=A0 =A0 =A0 =A0 =A0 sender-ext =3D token

=A0 =A0 =A0 =A0 =A0 refclk =3D "direct" [ "=3D" 1*DIGIT= ] [rate] [direct-ext]

=A0 =A0 =A0 =A0 =A0 rate =3D [ SP "rate=3D" integer "/"= integer ]

=A0 =A0 =A0 =A0 =A0 direct-ext =3D token

=A0 =A0 =A0 =A0 =A0 streamid =3D "master-id=3D" master-id
=A0 =A0 =A0 =A0 =A0 streamid =3D/ "IEEE1722=3D" avb-stream-id
=A0 =A0 =A0 =A0 =A0 streamid =3D/ streamid-ext

=A0 =A0 =A0 =A0 =A0 master-id =3D EUI48
=A0 =A0 =A0 =A0 =A0 avb-stream-id =3D EUI64

=A0 =A0 =A0 =A0 =A0 EUI48 =3D 5(2HEXDIG ":") 2HEXDIG
=A0 =A0 =A0 =A0 =A0 EUI64 =3D 7(2HEXDIG ":") 2HEXDIG

=A0 =A0 =A0 =A0 =A0 streamid-ext =3D token

=A0 =A0 =A0 =A0 =A0 mediaclock-ext =3D token

I wonder if not the mediaclock-ext construction is to restrictive. As
the refclk produces a sting with white-spaces in it, why isn't other mediaclock-ext allowed the same freedom? I think the mediaclock-ext can
be basically byte-string, i.e. any character allowed on an SDP line
should be possible to use. Likely the only resteriction should be that
it starts with a token. Thus using:

mediaclock-ext =3D token [SP byte-string]

This would require a token for identifying the method followed by a
space and then full freedom for anything that is allowed on an SDP
attribute value.


2. Section 6:

Purpose of signalling?

I think this type of signalling can select two levels of goals with
signalling:

1) Declaring what each SDP O/A uses on its side

2) Negotiating to arrive at the best but available mechanism on both sides.=

The currently proposed solution does neither of these. It enables the
offerer to express to declare I intended to use X and for the answer to
say I know that, or simply say I can't tell you because we are not
having the same clocks.

I think we need to be clear what our goals are here. And I will propose
some goals with the signalling based on my understanding of how these
defined timestamp reference clocks and media stream clocks can be used.
And we do need to be aware that different application may have different needs.

Goal with signalling:

1. Enable each media sender to declare its actually used ts-refclk, i.e. what clock is base for the RTCP SR NTP timestamps
2. Enable each media sender to identify what clock reference is used to
check/drive the media sampling, i.e. RTP timestamp advancement.
3. Enable two media sender using SDP O/A to determine what common clocks they actually have so they can be used in either of ts-refclk or mediaclk.<= br>
The purpose of doing three (3) is really so that one can do the following.<= br> A. has three ts-refclk =A0it can use. B has two ts-refclk available. They are going to watch social TV. To make it at all possible for the social
TV service to play out content at A and B in sync they need to have
either of these two things be available.

a) Each has a common clock with the TV service
b) A and B has a common clock

In either of the scenario the TV service will be able to ensure that the media is played out is sync.


As a technical solution to these issues there are two main solution tracks:=

1) Change the respective SDP attributes to provide info on all possible
clocks for that it could be using and let the answer select the most
preferred that both are supporting

2) Leave the current SDP attributes as they are and only use them for
declaration that: I use this! Then add new SDP attributes to negotiate
the list of commonly supported clocks.

At this stage I think 2) is what is simplest and require the least
changes to what already exist.

I will note that this is likely to require a second round of O/A
messages to update used clocks if the arrived common clock(s) are not
the default used ones. But, I don't see a way around these. In SIP one<= br> could use OPTIONS to provide a SDP which includes the negotiation
attribute to enable the other side to select using a clock that is
supported by both. But when that isn't done, it will take two rounds or=
other a'priori knowledge.

So my proposal is simply that one create two new SDP attributes one for
each type of clock usage (ts-refclk and mediaclk) and include a list of
clock type and any ID of the clock in a priority order. The O/A is basic negotiated and the answer removes all clocks it doesn't support and add= s
all it supports. Hopefully there is someone in the list that is common.
The highest priority between the two parties should be used when common
clock is required. IF that is not, then these attributes should not be
included. This for example allows one to use a common ts-refclk, but not require common mediaclk. We should also discuss if the answerer may
change the priority of commonly supported, and if it should or should
not add additional clocks it supports that are not common.

I really appreciate feedback on these comments and ideas.

Cheers

Magnus Westerlund

----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| Phone =A0+46 10 7148287
F=E4r=F6gatan 6 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com
----------------------------------------------------------------------

_______________________________________________
Audio/Video Transport Core Maintenance
avt@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/avt

--089e01175f6d865cc404da962e81-- From gonzalo.camarillo@ericsson.com Wed Apr 17 23:27:37 2013 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CD50D21F8F1C for ; Wed, 17 Apr 2013 23:27:37 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.349 X-Spam-Level: X-Spam-Status: No, score=-105.349 tagged_above=-999 required=5 tests=[AWL=-0.900, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_33=0.6, J_CHICKENPOX_47=0.6, J_CHICKENPOX_48=0.6, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id WQbRsMaZeF-H for ; Wed, 17 Apr 2013 23:27:37 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id A882B21F8EC9 for ; Wed, 17 Apr 2013 23:27:36 -0700 (PDT) X-AuditID: c1b4fb30-b7f266d000000cb5-98-516f9252de22 Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 5F.F9.03253.2529F615; Thu, 18 Apr 2013 08:27:30 +0200 (CEST) Received: from [131.160.126.169] (153.88.115.8) by esessmw0191.eemea.ericsson.se (153.88.115.85) with Microsoft SMTP Server id 8.3.279.1; Thu, 18 Apr 2013 08:27:30 +0200 Message-ID: <516F9251.5070904@ericsson.com> Date: Thu, 18 Apr 2013 09:27:29 +0300 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: Magnus Westerlund References: <20130410131256.CBFFFB1E006@rfc-editor.org> <5166A6D0.4090201@ericsson.com> <516D0F96.9040602@ericsson.com> In-Reply-To: <516D0F96.9040602@ericsson.com> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprOLMWRmVeSWpSXmKPExsUyM+JvrW7QpPxAgxUXVS1e9qxkt1j+8gSj xa6j+5kcmD2m3b/P5rFkyU8mjxO7XQOYo7hsUlJzMstSi/TtErgy9q7/yF7wTLzi7cv/jA2M t4S6GDk5JARMJLo+z2KDsMUkLtxbD2RzcQgJnGKUuP32JztIQkhgLaPEuZO6IDavgLZE6/X1 rCA2i4CqxN/3f8Ca2QQsJLbcus8CYosKREn8e7ubEaJeUOLkzCdgcREBM4mHE/aD1TMLpEic al4EViMs4CjRff4RUJwDaFe5xNvp2iAmp4COxO3rKRCnSUosmtbJAtGpJzHlagsjhC0vsf3t HGaIK7Ullj9rYZnAKDQLyeJZSFpmIWlZwMi8ipE9NzEzJ73cfBMjMHAPbvltsINx032xQ4zS HCxK4rzhrhcChATSE0tSs1NTC1KL4otKc1KLDzEycXBKNTBu2fJ2+elDWwpqO2bMzd6TqRPS 1TJjvdE2qQm7FXU7q5jVk+sFpmsesH0Ww/jyo9r2zbkln39aXjLhsOhw7Ni9v+9KoKT+ywyR +qjbzS0R3u9v6T999F53i7bknYPy6TMnP3KYdOR0gKb0dPazule9RXUXWLydE1BQXfPMaE6T xsmEBw/3lyxVYinOSDTUYi4qTgQA+23tWCoCAAA= Cc: piers.ohanlon@oii.ox.ac.uk, ingemar.s.johansson@ericsson.com, avt@ietf.org, csp@csperkins.org Subject: Re: [AVTCORE] [Editorial Errata Reported] RFC6679 (3586) X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Apr 2013 06:27:37 -0000 Hi Magnus, yes, I agree it is important. I have just verified it. Cheers, Gonzalo On 16/04/2013 11:45 AM, Magnus Westerlund wrote: > On 2013-04-11 14:04, Gonzalo Camarillo wrote: >> Hi, >> >> would anybody object to put this erratum into the "held for document >> update" status? > > I am okay with held for document update, although I would prefer > verified as I think it is an important, but editorial errata. > > Cheers > > Magnus > >> >> Cheers, >> >> Gonzalo >> >> On 10/04/2013 4:12 PM, RFC Errata System wrote: >>> The following errata report has been submitted for RFC6679, >>> "Explicit Congestion Notification (ECN) for RTP over UDP". >>> >>> -------------------------------------- >>> You may review the report below and at: >>> http://www.rfc-editor.org/errata_search.php?rfc=6679&eid=3586 >>> >>> -------------------------------------- >>> Type: Editorial >>> Reported by: Magnus Westerlund >>> >>> Section: 12.1 >>> >>> Original Text >>> ------------- >>> The Offer: >>> >>> ... >>> a=ecn-capable-rtp: ice rtp ect=0 mode=setread >>> ... >>> >>> The Answer: >>> ... >>> a=ecn-capable-rtp: ice ect=0 mode=readonly >>> ... >>> >>> Corrected Text >>> -------------- >>> The Offer: >>> >>> ... >>> a=ecn-capable-rtp: ice,rtp ect=0; mode=setread >>> ... >>> >>> The Answer: >>> ... >>> a=ecn-capable-rtp: ice ect=0; mode=readonly >>> ... >>> >>> Notes >>> ----- >>> The examples does not match the ABNF rules for the a=ecn-capaable-rtp attribute. Two issues are present, first the init method list must be comma separated with no spaces, secondly any additional parameters shall be semi colon plus space separated. Therefore both a=ecn-capable-rtp lines have been corrected. >>> >>> This is primarily an editorial issues but people needs to aware of the errors in the example. >>> >>> Instructions: >>> ------------- >>> This errata is currently posted as "Reported". If necessary, please >>> use "Reply All" to discuss whether it should be verified or >>> rejected. When a decision is reached, the verifying party (IESG) >>> can log in to change the status and edit the report, if necessary. >>> >>> -------------------------------------- >>> RFC6679 (draft-ietf-avtcore-ecn-for-rtp-08) >>> -------------------------------------- >>> Title : Explicit Congestion Notification (ECN) for RTP over UDP >>> Publication Date : August 2012 >>> Author(s) : M. Westerlund, I. Johansson, C. Perkins, P. O'Hanlon, K. Carlberg >>> Category : PROPOSED STANDARD >>> Source : Audio/Video Transport Core Maintenance >>> Area : Real-time Applications and Infrastructure >>> Stream : IETF >>> Verifying Party : IESG >>> >> >> _______________________________________________ >> Audio/Video Transport Core Maintenance >> avt@ietf.org >> https://www.ietf.org/mailman/listinfo/avt >> >> > > From magnus.westerlund@ericsson.com Thu Apr 18 00:50:23 2013 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 76BDD21F89DB; Thu, 18 Apr 2013 00:50:23 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.024 X-Spam-Level: X-Spam-Status: No, score=-106.024 tagged_above=-999 required=5 tests=[AWL=0.225, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FXyQhxkRdTSe; Thu, 18 Apr 2013 00:50:22 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id C1A4021F89B2; Thu, 18 Apr 2013 00:50:11 -0700 (PDT) X-AuditID: c1b4fb2d-b7f316d0000028db-b5-516fa5b217a3 Received: from esessmw0184.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id D5.8F.10459.2B5AF615; Thu, 18 Apr 2013 09:50:10 +0200 (CEST) Received: from [127.0.0.1] (153.88.115.8) by esessmw0184.eemea.ericsson.se (153.88.115.82) with Microsoft SMTP Server id 8.3.279.1; Thu, 18 Apr 2013 09:50:10 +0200 Message-ID: <516FA5AA.5080900@ericsson.com> Date: Thu, 18 Apr 2013 09:50:02 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: Gonzalo Camarillo References: <20130219074201.79BD0B1E002@rfc-editor.org> <515C42DD.1030902@ericsson.com> In-Reply-To: <515C42DD.1030902@ericsson.com> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrOLMWRmVeSWpSXmKPExsUyM+Jvre6mpfmBBndaVSxe9qxkt3j1+gqr xaWLZ5ksLv1Tsbiw/heLA6vH11sHmTx2zrrL7tFy5C2rx5IlP5kCWKK4bFJSczLLUov07RK4 Mma8cSs4IV/RdaOfqYFxg2QXIyeHhICJxNU1rYwQtpjEhXvr2boYuTiEBE4xSvydN58FwlnO KHG+uYsFpIpXQFtizeYdQFUcHCwCqhJ3b0uDhNkELCRu/mgEC4sKBEtsbY2BqBaUODnzCVin iICZxPt/q5hARjILdDNKnP56lQkkISzgLbF18wewI4QEwiXuNB1hA7E5BXQkVrfvY4U4TlJi y4t2dhCbWUBPYsrVFkYIW16ieetsZohebYmGpg7WCYxCs5DsnoWkZRaSlgWMzKsY2XMTM3PS yw03MQID++CW37o7GE+dEznEKM3BoiTOG+Z6IUBIID2xJDU7NbUgtSi+qDQntfgQIxMHp1QD o5iRQPGEnStOWJoH7PAtfhFa+fxaR2b1uScte+ek7/U5HeuovsSPyTJhJfuNyLnPu+4UnOib p3H/uJbgtMfiBipXJ5xwnbJq1jKNJNmn4hvOJf7ZdEXNwmKGysVq/q+H+0T/vw6zn8fxdoVS liK3WKvSz0dlM+/pLWJWLfN+0tli88ni69bCbiWW4oxEQy3mouJEAAX9cSI6AgAA Cc: schulzrinne@cs.columbia.edu, even.roni@huawei.com, avt@ietf.org, "payload@ietf.org" , tom.taylor.stds@gmail.com Subject: Re: [AVTCORE] [payload] [Technical Errata Reported] RFC4733 (3489) X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Apr 2013 07:50:23 -0000 AD, I recommend that you verify this errata as there has been no objection during this last call period and the text was developed in the context of the AVTCORE WG. Cheers Magnus Westerlund as WG chair of AVTCORE WG On 2013-04-03 16:55, Magnus Westerlund wrote: > AVTCORE and Payload WG, > > There appear to exist an interoperability issue around the the need to > use the same timestamp rate for the DTMF and the audio. Thus, I think we > should serioulsy consider to approve this erratum. And if the text is > not correct, propose a better text. > > I personally believe the proposal is significantly clearer than the old > text and also reflect what must have been intended. > > This issues a 2-week last call on input on this erratum. After the 17th > of April I will issue a final recommendation on this erratum. > > > For previous discussion that resulted in this updated erratum proposal > see this AVTCORE mailing list discussion: > http://www.ietf.org/mail-archive/web/avt/current/msg15669.html > > Cheers > > Magnus Westerlund > AVTCORE WG chair > > On 2013-02-19 08:42, RFC Errata System wrote: >> >> The following errata report has been submitted for RFC4733, >> "RTP Payload for DTMF Digits, Telephony Tones, and Telephony Signals". >> >> -------------------------------------- >> You may review the report below and at: >> http://www.rfc-editor.org/errata_search.php?rfc=4733&eid=3489 >> >> -------------------------------------- >> Type: Technical >> Reported by: Xavier Marjou >> >> Section: 2.1 >> >> Original Text >> ------------- >> Named telephone events are carried as part of the audio stream and MUST use the same sequence number and timestamp base as the regular audio channel to simplify the generation of audio waveforms at a gateway. >> >> Corrected Text >> -------------- >> Named telephone events are carried as part of the audio stream and if they use the same SSRC (therefore the same timing and sequence number space), they MUST use the same timestamp clock rate as the regular audio channel. >> >> Notes >> ----- >> RFC4733 was written in a way to avoid the multiple clock-rate problem by mandating the use of the same SSRC for DTMF and audio. However it's not explicitly written, which brings an ambiguity. It was commented that RFC4733 needs to be updated. (c.f. http://tools.ietf.org/wg/avtext/minutes?item=minutes-85-avtext.html). This errata obsoletes the previous proposed errata (ID: 3451). >> >> Instructions: >> ------------- >> This errata is currently posted as "Reported". If necessary, please >> use "Reply All" to discuss whether it should be verified or >> rejected. When a decision is reached, the verifying party (IESG) >> can log in to change the status and edit the report, if necessary. >> >> -------------------------------------- >> RFC4733 (draft-ietf-avt-rfc2833bis-15) >> -------------------------------------- >> Title : RTP Payload for DTMF Digits, Telephony Tones, and Telephony Signals >> Publication Date : December 2006 >> Author(s) : H. Schulzrinne, T. Taylor >> Category : PROPOSED STANDARD >> Source : Audio/Video Transport >> Area : Real-time Applications and Infrastructure >> Stream : IETF >> Verifying Party : IESG >> _______________________________________________ >> Audio/Video Transport Core Maintenance >> avt@ietf.org >> https://www.ietf.org/mailman/listinfo/avt >> >> > > -- Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From gonzalo.camarillo@ericsson.com Thu Apr 18 01:09:45 2013 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 291D021F8E94; Thu, 18 Apr 2013 01:09:45 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.069 X-Spam-Level: X-Spam-Status: No, score=-106.069 tagged_above=-999 required=5 tests=[AWL=0.180, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id q7JDoyIhjfia; Thu, 18 Apr 2013 01:09:44 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id D4D6221F8935; Thu, 18 Apr 2013 01:09:43 -0700 (PDT) X-AuditID: c1b4fb25-b7f366d000004d10-38-516faa463c9a Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 75.FF.19728.64AAF615; Thu, 18 Apr 2013 10:09:42 +0200 (CEST) Received: from [131.160.126.169] (153.88.115.8) by esessmw0247.eemea.ericsson.se (153.88.115.94) with Microsoft SMTP Server id 8.3.279.1; Thu, 18 Apr 2013 10:09:43 +0200 Message-ID: <516FAA45.2010005@ericsson.com> Date: Thu, 18 Apr 2013 11:09:41 +0300 From: Gonzalo Camarillo User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: Magnus Westerlund References: <20130219074201.79BD0B1E002@rfc-editor.org> <515C42DD.1030902@ericsson.com> <516FA5AA.5080900@ericsson.com> In-Reply-To: <516FA5AA.5080900@ericsson.com> X-Enigmail-Version: 1.4.6 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrFLMWRmVeSWpSXmKPExsUyM+Jvra7bqvxAg6vHrC1e9qxkt3j1+gqr xaWLZ5ksLv1Tsbiw/heLA6vH11sHmTx2zrrL7tFy5C2rx5IlP5kCWKK4bFJSczLLUov07RK4 Mg5M28RUsE+24vamPYwNjBfFuxg5OSQETCSWPpjLDmGLSVy4t56ti5GLQ0jgFKPEq+W7GCGc tYwSU86uYgKp4hXQlnjz/g6YzSKgKvFi91E2EJtNwEJiy637LCC2qECUxL+3uxkh6gUlTs58 AhYXETCTeDhhP9gGZoFuRonTX6+CDRIW8JbYuvkDWIOQQLnE/3O/WUFsTgEdiX0v+6DOk5RY NK0TbBCzgJ7ElKstjBC2vMT2t3OYIXq1JZY/a2GZwCg0C8nuWUhaZiFpWcDIvIqRPTcxMye9 3GgTIzC8D275rbqD8c45kUOM0hwsSuK84a4XAoQE0hNLUrNTUwtSi+KLSnNSiw8xMnFwSjUw zkiZ987MbcYUgeDb3/Xfdmn+DfisoTBv+rtrG+zmtvK+7fhc/2An69Xy/XOOyq/jC1E9GCYf +bftfaNoUo37tpy3EpcnRx/PNp8979Sd6QfqA4z2/uDh/MB7fCXbywUJsvl6+ofMPA7s4Yh1 1P3/bbbO1LJXklIqrfutE3+/OWxms+TZj9t3NZVYijMSDbWYi4oTAYcM+uI9AgAA Cc: schulzrinne@cs.columbia.edu, even.roni@huawei.com, avt@ietf.org, "payload@ietf.org" , tom.taylor.stds@gmail.com Subject: Re: [AVTCORE] [payload] [Technical Errata Reported] RFC4733 (3489) X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Apr 2013 08:09:45 -0000 Hi, I have just verified it. Thanks, Gonzalo On 18/04/2013 10:50 AM, Magnus Westerlund wrote: > AD, > > I recommend that you verify this errata as there has been no objection > during this last call period and the text was developed in the context > of the AVTCORE WG. > > Cheers > > Magnus Westerlund > as WG chair of AVTCORE WG > > > On 2013-04-03 16:55, Magnus Westerlund wrote: >> AVTCORE and Payload WG, >> >> There appear to exist an interoperability issue around the the need to >> use the same timestamp rate for the DTMF and the audio. Thus, I think we >> should serioulsy consider to approve this erratum. And if the text is >> not correct, propose a better text. >> >> I personally believe the proposal is significantly clearer than the old >> text and also reflect what must have been intended. >> >> This issues a 2-week last call on input on this erratum. After the 17th >> of April I will issue a final recommendation on this erratum. >> >> >> For previous discussion that resulted in this updated erratum proposal >> see this AVTCORE mailing list discussion: >> http://www.ietf.org/mail-archive/web/avt/current/msg15669.html >> >> Cheers >> >> Magnus Westerlund >> AVTCORE WG chair >> >> On 2013-02-19 08:42, RFC Errata System wrote: >>> >>> The following errata report has been submitted for RFC4733, >>> "RTP Payload for DTMF Digits, Telephony Tones, and Telephony Signals". >>> >>> -------------------------------------- >>> You may review the report below and at: >>> http://www.rfc-editor.org/errata_search.php?rfc=4733&eid=3489 >>> >>> -------------------------------------- >>> Type: Technical >>> Reported by: Xavier Marjou >>> >>> Section: 2.1 >>> >>> Original Text >>> ------------- >>> Named telephone events are carried as part of the audio stream and MUST use the same sequence number and timestamp base as the regular audio channel to simplify the generation of audio waveforms at a gateway. >>> >>> Corrected Text >>> -------------- >>> Named telephone events are carried as part of the audio stream and if they use the same SSRC (therefore the same timing and sequence number space), they MUST use the same timestamp clock rate as the regular audio channel. >>> >>> Notes >>> ----- >>> RFC4733 was written in a way to avoid the multiple clock-rate problem by mandating the use of the same SSRC for DTMF and audio. However it's not explicitly written, which brings an ambiguity. It was commented that RFC4733 needs to be updated. (c.f. http://tools.ietf.org/wg/avtext/minutes?item=minutes-85-avtext.html). This errata obsoletes the previous proposed errata (ID: 3451). >>> >>> Instructions: >>> ------------- >>> This errata is currently posted as "Reported". If necessary, please >>> use "Reply All" to discuss whether it should be verified or >>> rejected. When a decision is reached, the verifying party (IESG) >>> can log in to change the status and edit the report, if necessary. >>> >>> -------------------------------------- >>> RFC4733 (draft-ietf-avt-rfc2833bis-15) >>> -------------------------------------- >>> Title : RTP Payload for DTMF Digits, Telephony Tones, and Telephony Signals >>> Publication Date : December 2006 >>> Author(s) : H. Schulzrinne, T. Taylor >>> Category : PROPOSED STANDARD >>> Source : Audio/Video Transport >>> Area : Real-time Applications and Infrastructure >>> Stream : IETF >>> Verifying Party : IESG >>> _______________________________________________ >>> Audio/Video Transport Core Maintenance >>> avt@ietf.org >>> https://www.ietf.org/mailman/listinfo/avt >>> >>> >> >> > > From magnus.westerlund@ericsson.com Thu Apr 18 08:09:49 2013 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8FC4E21F8F6D for ; Thu, 18 Apr 2013 08:09:49 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.12 X-Spam-Level: X-Spam-Status: No, score=-106.12 tagged_above=-999 required=5 tests=[AWL=0.129, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HjpvkFSggIGf for ; Thu, 18 Apr 2013 08:09:48 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 95D2F21F8F69 for ; Thu, 18 Apr 2013 08:09:47 -0700 (PDT) X-AuditID: c1b4fb30-b7f266d000000cb5-8e-51700cba53e9 Received: from esessmw0237.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 74.09.03253.ABC00715; Thu, 18 Apr 2013 17:09:46 +0200 (CEST) Received: from [127.0.0.1] (153.88.115.8) by esessmw0237.eemea.ericsson.se (153.88.115.91) with Microsoft SMTP Server id 8.3.279.1; Thu, 18 Apr 2013 17:09:45 +0200 Message-ID: <51700CB9.4030601@ericsson.com> Date: Thu, 18 Apr 2013 17:09:45 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: IETF AVTCore WG , "draft-ietf-avtcore-srtp-aes-gcm@tools.ietf.org" X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFnrNJMWRmVeSWpSXmKPExsUyM+Jvre4unoJAg8UXpC1e9qxkt1h7JNGB yWPJkp9MHl8uf2YLYIrisklJzcksSy3St0vgyni5uIupYJFqxYe2CYwNjDtkuxg5OCQETCTW bYrtYuQEMsUkLtxbz9bFyMUhJHCKUeLO09msEM5yRokFq1+ygFTxCmhLbH/fzQZiswioSuy+ cYEZxGYTsJC4+aORDWSoqECwxNbWGIhyQYmTM5+wgMwREehglLhxYT07SEJYwFyib9YvJojN khJbXrSDxZkF9CSmXG1hhLDlJZq3zgabLwS0t6Gpg3UCI/8sJHNnIWmZhaRlASPzKkb23MTM nPRy802MwAA7uOW3wQ7GTffFDjFKc7AoifOGu14IEBJITyxJzU5NLUgtii8qzUktPsTIxMEp 1cB4SGftoVd7fXa9v7TzA+fywxPM1aNb/z45tHs5Q8jxqkOt3jbabjvZVkaEvfl6ciXTUlHN ZCOLirtzxYRy1Ax/LsvoTL76yUy2u275s70zTvr+OWvoW2ZiXO/4KuNWA/vKA3n3J3oX7Z4x YWf2jbaDd+K3aq2IEEw1PaDN7rP0ZnGU9YMPzGLTlViKMxINtZiLihMBb81yyP4BAAA= Subject: [AVTCORE] Comments on draft-ietf-avtcore-srtp-aes-gcm-05 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Apr 2013 15:09:49 -0000 Authors and WG, In my review of the draft in preparing the Document Shepherd's writeup I found some issues that I believe needs to be fixed. 1) Section 14.1: Security description [RFC 4568] defines SRTP "crypto suites"; a crypto suite corresponds to a particular AEAD algorithm in SRTP. As the registry is located on the SDP page it can be difficult to find and it also not named as written I propose to change this to: Security description [RFC 4568] defines the "SRTP Crypto Suite Registrations" registry on the "Session Description Protocol (SDP) Security Descriptions" page currently located at "http://www.iana.org/assignments/sdp-security-descriptions/sdp-security-descriptions.xml"; a crypto suite corresponds to a particular AEAD algorithm in SRTP. 2) Security Descriptions and the "inline" value string Section 10.3.2.1 of RFC 4568 says: The semantics of the SRTP crypto suite MUST be described in an RFC in accordance with the RFC 2434 Standards Action, including the semantics of the "inline" key-method and any special semantics of parameters. As there is no such definition of how the inline method is actually using the fields for these algorithms this drafts appears to not be in conformance. Please look at RFC 4568 to figure out what is missing. I think at minimum one needs to define if one has both key and salt and how many octets that is going to be. Pointers to the DTLS SRTPprotection profiles is likely part of the solution here. 3) Section 14.2: DTLS-SRTP [RFC5764] defines a DTLS-SRTP "SRTP Protection Profile"; This registry is actually named "DTLS-SRTP Protection Profiles" on IANA's page. 4) IANA registry: On the SRTP policy Type/Value list (derived from Table 6.10.1.a of [RFC3830]) we request the following addition: Type | Meaning | Possible values ---------------------------------------------------------------- TBD | AEAD authentication tag length | 8, 12, or 16 (in octets) This registry is called : MIKEY Security Protocol Parameters at http://www.iana.org/assignments/mikey-payloads/mikey-payloads.xml Can you please confirm that it is this registry you want to add to? 5) IANA registry: 14.4. AEAD registry We request that IANA make the following additions to the AEAD registry: AEAD_AES_128_CCM_12 = TBD AEAD_AES_256_CCM_12 = TBD You are not using the exact correct names for the registry: http://www.iana.org/assignments/aead-parameters/aead-parameters.xml Would indicate that you should write this as: We request that IANA make the following additions to the IANA Authenticated Encryption with Associated Data (AEAD) Parameters page's registry for "AEAD Algorithms": 6) Abstract: This document defines how AES-GCM and AES-CCM Authenticated Encryption with Associated Data algorithms can be used to provide confidentiality and data authentication in the SRTP protocol. The ID-Checklist says: Should be meaningful to someone not versed in the technology; most abbreviations must be expanded on first use. This makes me wonder if you should expand the acronyms, although they probably need to be present in the acronym form to enable searching for them. 7) Usage of RFC 2119 words 8.1. SRTP/SRTCP Authentication Field The AEAD message authentication mechanism MUST be the primary message authentication mechanism for AEAD SRTP/SRTCP. Additional SRTP/SRTCP authentication mechanisms SHOULD NOT be used with any AEAD algorithm and the optional SRTP/SRTCP Authentication Tags are NOT RECOMMENDED and SHOULD NOT be present. "NOT RECOMMENDED" is not included in the normal blurb text: The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119. So please modify it to include "NOT RECOMMENDED" as it is actually defined as part of the RFC. I also sent some basic editorial issues to the authors directly. Some which was unresolved isssue found by ID-Nits, please use it before submitting the draft! Cheers Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From wwwrun@rfc-editor.org Thu Apr 18 09:58:48 2013 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7870321F90B4; Thu, 18 Apr 2013 09:58:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.115 X-Spam-Level: X-Spam-Status: No, score=-102.115 tagged_above=-999 required=5 tests=[AWL=-0.115, BAYES_00=-2.599, J_CHICKENPOX_93=0.6, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pyplVzaJj7uI; Thu, 18 Apr 2013 09:58:48 -0700 (PDT) Received: from rfc-editor.org (unknown [IPv6:2001:1890:123a::1:2f]) by ietfa.amsl.com (Postfix) with ESMTP id 1702821F90AC; Thu, 18 Apr 2013 09:58:48 -0700 (PDT) Received: by rfc-editor.org (Postfix, from userid 30) id EB792B1E002; Thu, 18 Apr 2013 09:57:42 -0700 (PDT) To: ietf-announce@ietf.org, rfc-dist@rfc-editor.org From: rfc-editor@rfc-editor.org Message-Id: <20130418165742.EB792B1E002@rfc-editor.org> Date: Thu, 18 Apr 2013 09:57:42 -0700 (PDT) Cc: avt@ietf.org, rfc-editor@rfc-editor.org Subject: [AVTCORE] RFC 6904 on Encryption of Header Extensions in the Secure Real-time Transport Protocol (SRTP) X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 18 Apr 2013 16:58:48 -0000 A new Request for Comments is now available in online RFC libraries. RFC 6904 Title: Encryption of Header Extensions in the Secure Real-time Transport Protocol (SRTP) Author: J. Lennox Status: Standards Track Stream: IETF Date: April 2013 Mailbox: jonathan@vidyo.com Pages: 15 Characters: 33486 Updates: RFC 3711 I-D Tag: draft-ietf-avtcore-srtp-encrypted-header-ext-05.txt URL: http://www.rfc-editor.org/rfc/rfc6904.txt The Secure Real-time Transport Protocol (SRTP) provides authentication, but not encryption, of the headers of Real-time Transport Protocol (RTP) packets. However, RTP header extensions may carry sensitive information for which participants in multimedia sessions want confidentiality. This document provides a mechanism, extending the mechanisms of SRTP, to selectively encrypt RTP header extensions in SRTP. This document updates RFC 3711, the Secure Real-time Transport Protocol specification, to require that all future SRTP encryption transforms specify how RTP header extensions are to be encrypted. This document is a product of the Audio/Video Transport Core Maintenance Working Group of the IETF. This is now a Proposed Standard. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-editor@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC From jonathan@vidyo.com Fri Apr 19 08:59:16 2013 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0F25221F86D8 for ; Fri, 19 Apr 2013 08:59:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.185 X-Spam-Level: X-Spam-Status: No, score=-0.185 tagged_above=-999 required=5 tests=[BAYES_40=-0.185] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id gK4x1bs2u+Wo for ; Fri, 19 Apr 2013 08:59:14 -0700 (PDT) Received: from mxout.myoutlookonline.com (mxout.myoutlookonline.com [64.95.72.252]) by ietfa.amsl.com (Postfix) with ESMTP id 088CF21F962D for ; Fri, 19 Apr 2013 08:59:12 -0700 (PDT) Received: from mxout.myoutlookonline.com (localhost [127.0.0.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id C2070416939 for ; Fri, 19 Apr 2013 11:59:01 -0400 (EDT) X-Virus-Scanned: by SpamTitan at mail.lan Received: from HUB022.mail.lan (unknown [10.110.2.1]) by mxout.myoutlookonline.com (Postfix) with ESMTP id 9193C416B66 for ; Fri, 19 Apr 2013 11:59:00 -0400 (EDT) Received: from BE235.mail.lan ([10.110.32.235]) by HUB022.mail.lan ([10.110.17.22]) with mapi; Fri, 19 Apr 2013 11:57:53 -0400 From: Jonathan Lennox To: IETF AVTCore WG Date: Fri, 19 Apr 2013 11:58:59 -0400 Thread-Topic: header extensions and draft-ietf-avtcore-srtp-aes-gcm-04.txt Thread-Index: Ac49FsMyIepl6QzoSuCQQ+PEUtZgtg== Message-ID: <1F2A6816-DDB9-4964-AD82-5F9EC2A2957D@vidyo.com> References: <20130204181454.8284.73608.idtracker@ietfa.amsl.com> <461FB470-9F33-4B72-BDCC-402E44208789@vidyo.com> <3C4AAD4B5304AB44A6BA85173B4675CA69669890@MSMR-GH1-UEA03.corp.nsa.gov> <3C4AAD4B5304AB44A6BA85173B4675CA6AA9DCC8@MSMR-GH1-UEA03.corp.nsa.gov> In-Reply-To: <3C4AAD4B5304AB44A6BA85173B4675CA6AA9DCC8@MSMR-GH1-UEA03.corp.nsa.gov> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US Content-Type: text/plain; charset="Windows-1252" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [AVTCORE] header extensions and draft-ietf-avtcore-srtp-aes-gcm-04.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 19 Apr 2013 15:59:16 -0000 To note, the changes in srtp-aes-gcm-05 describing the use of header extens= ion encryption look good to me. The RFC for header extension encryption has now been published, as RFC 6904= . The next rev of srtp-aes-gcm (whenever that is) should update that in it= s references. -- Jonathan Lennox jonathan@vidyo.com From ron.even.tlv@gmail.com Sat Apr 20 23:27:50 2013 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 50ACB21F8EAA for ; Sat, 20 Apr 2013 23:27:50 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.142 X-Spam-Level: X-Spam-Status: No, score=0.142 tagged_above=-999 required=5 tests=[AWL=-0.529, BAYES_00=-2.599, DOS_OUTLOOK_TO_MX=1, DYN_RDNS_SHORT_HELO_HTML=0.499, FH_HOST_EQ_D_D_D_D=0.765, HTML_MESSAGE=0.001, RCVD_IN_PBL=0.905, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FWsF5gWod401 for ; Sat, 20 Apr 2013 23:27:49 -0700 (PDT) Received: from mail-wi0-x231.google.com (mail-wi0-x231.google.com [IPv6:2a00:1450:400c:c05::231]) by ietfa.amsl.com (Postfix) with ESMTP id 589B621F8E59 for ; Sat, 20 Apr 2013 23:27:49 -0700 (PDT) Received: by mail-wi0-f177.google.com with SMTP id hj19so2704447wib.4 for ; Sat, 20 Apr 2013 23:27:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:from:to:cc:subject:date:message-id:mime-version :content-type:x-mailer:thread-index:content-language; bh=FoOX3QmsaaumEfgtKcu2UWU2vgwKUT8H2uLAwhsVpLE=; b=WhVdj1sMISE5otTIGFpcaMNagOnwtjdYagxxOiLCaeaA5Eg5TuXxaAmrunQxRjVTZe LIzTe9GkwCcKFM/rggWPbkJOhCC2Yj1Qom3VKgL38bKkcx6jIwvnYj6AmTPdSUtjherv O8667t0efyh4IBsW5024TcFJaqpuEIG8zzDDkMlYK5eSMZ3k3PYGn9rESGDObO7OwFMb IZUCO7pjtP/5G0dtyhqJR2YNOc4XEWkCxJiAL4jeLDfpsH4qqzAakNosVRTW7KgHfTPg DBLM7niQuZaPGHgpKut55VmQFZg/s1ECrXh7hFdVhoPSTP/I+99xesZiA9wGGqOUScDb +yBg== X-Received: by 10.194.158.42 with SMTP id wr10mr40162572wjb.23.1366525668551; Sat, 20 Apr 2013 23:27:48 -0700 (PDT) Received: from RoniE (bzq-79-181-177-28.red.bezeqint.net. [79.181.177.28]) by mx.google.com with ESMTPS id d47sm32968514eem.9.2013.04.20.23.27.46 (version=TLSv1 cipher=RC4-SHA bits=128/128); Sat, 20 Apr 2013 23:27:47 -0700 (PDT) From: "Roni Even" To: "Magnus Westerlund" , Date: Sun, 21 Apr 2013 09:27:13 +0300 Message-ID: <013901ce3e59$454f7610$cfee6230$@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_013A_01CE3E72.6A9D4A50" X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac4+WULiwA/00GWCRpCfux7LpRXnkg== Content-Language: en-us Cc: avt@ietf.org Subject: [AVTCORE] submit draft-westerlund-avtcore-rtp-topologies-update as a working group document X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Apr 2013 06:27:50 -0000 This is a multipart message in MIME format. ------=_NextPart_000_013A_01CE3E72.6A9D4A50 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, Since there were no further input please go ahead and submit this document as a WG document. I asked for a milestone Roni Even AVTCore co-chair From: Roni Even [mailto:ron.even.tlv@gmail.com] Sent: 09 April, 2013 10:35 AM To: avt@ietf.org Subject: draft-westerlund-avtcore-rtp-topologies-update to a working group document Hi, At the Orlando meeting there was support to have draft-westerlund-avtcore-rtp-topologies-update-02 as a working group document. We would like to verify the support on the list. So if you have any comments please send to the list until April 19th. Thanks Roni Even AVTcore co-chair ------=_NextPart_000_013A_01CE3E72.6A9D4A50 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

Since there were no = further input please go ahead and submit this document as a WG = document.

I asked for a milestone

Roni = Even

AVTCore co-chair

 

From:= = Roni Even [mailto:ron.even.tlv@gmail.com]
Sent: 09 April, = 2013 10:35 AM
To: avt@ietf.org
Subject: = draft-westerlund-avtcore-rtp-topologies-update to a working group = document

 

Hi,

At the Orlando = meeting there was support to have draft-westerlund-avtcore-rtp-topologies-update-02 =  as a working group document.

 

We would = like to verify the support on the list.

So if you have any comments please send to the list = until April 19th.

 

Thanks

Roni Even = AVTcore co-chair

------=_NextPart_000_013A_01CE3E72.6A9D4A50-- From ron.even.tlv@gmail.com Sat Apr 20 23:32:30 2013 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4A47921F8F0F for ; Sat, 20 Apr 2013 23:32:30 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.318 X-Spam-Level: X-Spam-Status: No, score=0.318 tagged_above=-999 required=5 tests=[AWL=-0.353, BAYES_00=-2.599, DOS_OUTLOOK_TO_MX=1, DYN_RDNS_SHORT_HELO_HTML=0.499, FH_HOST_EQ_D_D_D_D=0.765, HTML_MESSAGE=0.001, RCVD_IN_PBL=0.905, RDNS_DYNAMIC=0.1] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 8PzJsHWuxLiy for ; Sat, 20 Apr 2013 23:32:29 -0700 (PDT) Received: from mail-wi0-x235.google.com (mail-wi0-x235.google.com [IPv6:2a00:1450:400c:c05::235]) by ietfa.amsl.com (Postfix) with ESMTP id 6C29121F8F0D for ; Sat, 20 Apr 2013 23:32:29 -0700 (PDT) Received: by mail-wi0-f181.google.com with SMTP id c10so2706556wiw.2 for ; Sat, 20 Apr 2013 23:32:28 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:from:to:cc:subject:date:message-id:mime-version :content-type:x-mailer:thread-index:content-language; bh=kgUeQ9zskROxPoDaZxHQTUruq/zy/Cvc/z/mBVpasqo=; b=eb5U4QaBTJ1mn/4IPdE4dHdnko29Um46CxZJewC61NumNUrRnbfgR7WBK9iVjACsmT NY6JIT3ut3KdyN4UlCi37pU4/+4+HHfvftdBaOg8V/Os5cCsaBzwjs+kPxoHK8LrqNEt Ah2icJcvFcZxgtzyBhVwKOrBFxraVAxYfY/ohYGZWTEXiuEOj6L6LbBIOsEMK4d2fmCz SZ0phUL5oQpK9xJm3HP4M6CWSgGcpX0qBt214l0bJ3tYJzCqPiBU/Bs0H3uQrJHaOmeY UVBIHKsW2EHgngeOrwv9hkuQMA0UksjO86eR4RZI/24V0wQPcacTOOKStd+NT1BNR85w /wuw== X-Received: by 10.194.81.71 with SMTP id y7mr40232195wjx.19.1366525948617; Sat, 20 Apr 2013 23:32:28 -0700 (PDT) Received: from RoniE (bzq-79-181-177-28.red.bezeqint.net. [79.181.177.28]) by mx.google.com with ESMTPS id n48sm32974701eeg.12.2013.04.20.23.32.25 (version=TLSv1 cipher=RC4-SHA bits=128/128); Sat, 20 Apr 2013 23:32:27 -0700 (PDT) From: "Roni Even" To: "Magnus Westerlund" , "'Bo Burman'" , "'Colin Perkins'" , "'Harald Alvestrand'" Date: Sun, 21 Apr 2013 09:31:53 +0300 Message-ID: <013e01ce3e59$ec4d6670$c4e83350$@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_013F_01CE3E73.119B3AB0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac4+WckUxD7uZy1xSpShsPcs1q/7hw== Content-Language: en-us Cc: avt@ietf.org Subject: [AVTCORE] submit draft-westerlund-avtcore-multiplex-architecture as a working group document X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Apr 2013 06:32:30 -0000 This is a multipart message in MIME format. ------=_NextPart_000_013F_01CE3E73.119B3AB0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, There were no new comments so please go ahead and submit the document as a WG document. I asked for a milestone Thanks Roni Even AVTCore co-chair From: Roni Even [mailto:ron.even.tlv@gmail.com] Sent: 09 April, 2013 10:33 AM To: avt@ietf.org Subject: draft-westerlund-avtcore-multiplex-architecture to a working group document Hi, At the Orlando meeting there was support to have draft-westerlund-avtcore-multiplex-architecture-03 as a working group document. We would like to verify the support on the list. So if you have any comments please send to the list until April 19th. Thanks Roni Even AVTcore co-chair ------=_NextPart_000_013F_01CE3E73.119B3AB0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

There were no new = comments so please go ahead and submit the document as a WG = document.

I asked for a milestone

Thanks

Roni = Even

AVTCore co-chair

 

From:= = Roni Even [mailto:ron.even.tlv@gmail.com]
Sent: 09 April, = 2013 10:33 AM
To: avt@ietf.org
Subject: = draft-westerlund-avtcore-multiplex-architecture to a working group = document

 

Hi,

At the Orlando = meeting there was support to have draft-westerlund-avtcore-multiplex-architecture-03 as = a working group document.

 

We would = like to verify the support on the list.

So if you have any comments please send to the list = until April 19th.

 

Thanks

Roni Even = AVTcore co-chair

------=_NextPart_000_013F_01CE3E73.119B3AB0-- From ron.even.tlv@gmail.com Sat Apr 20 23:39:53 2013 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4753121F85B4 for ; Sat, 20 Apr 2013 23:39:53 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 0.585 X-Spam-Level: X-Spam-Status: No, score=0.585 tagged_above=-999 required=5 tests=[AWL=-0.442, BAYES_00=-2.599, DOS_OUTLOOK_TO_MX=1, DYN_RDNS_SHORT_HELO_HTML=0.499, FH_HOST_EQ_D_D_D_D=0.765, HTML_MESSAGE=0.001, RCVD_IN_PBL=0.905, RDNS_DYNAMIC=0.1, SARE_SUB_6CONS_WORD=0.356] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id hhVhfiWEKNeb for ; Sat, 20 Apr 2013 23:39:52 -0700 (PDT) Received: from mail-we0-x232.google.com (mail-we0-x232.google.com [IPv6:2a00:1450:400c:c03::232]) by ietfa.amsl.com (Postfix) with ESMTP id 5C91C21F84F9 for ; Sat, 20 Apr 2013 23:39:52 -0700 (PDT) Received: by mail-we0-f178.google.com with SMTP id z53so5291739wey.9 for ; Sat, 20 Apr 2013 23:39:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:from:to:cc:subject:date:message-id:mime-version :content-type:x-mailer:thread-index:content-language; bh=A5JGy3mPsKUI/jgBlayDz8cEFMQoX0sYGhBPcGmsx9Q=; b=F02AmFKwNmPsB+/fdW6lRC/D1sDu/97tUK9NM6IhhyrMTVLlaSRk+AD+2PJOz4H6Fx foCEC+Ni49h+Y3GicF0OeZctmCQUSM3AlbfPnmm3ZFQx1b59ZO1FyMzg+zvOtVDsGsWq SqZE+FmvxGuXcJKs4XLToq6Ga4G50B0mOMNzAhikEroxOqphZAlGRrvoz9mVSZZFB2Oz xvkeLbt9Vcp/rgyz7oDylYmU3aDZxXUWcCU6sClHJA0lhfMHOIiA+LbZOkAeY//wuirq hEpXIuS+yAfFw9qdMeckNilals18l7R1AA4kUXIrzNHdlpS/tz9cD2VLQJp1J9kJTQ0L tzpQ== X-Received: by 10.180.13.34 with SMTP id e2mr31037880wic.29.1366526388523; Sat, 20 Apr 2013 23:39:48 -0700 (PDT) Received: from RoniE (bzq-79-181-177-28.red.bezeqint.net. [79.181.177.28]) by mx.google.com with ESMTPS id bj2sm33051965eeb.1.2013.04.20.23.39.46 (version=TLSv1 cipher=RC4-SHA bits=128/128); Sat, 20 Apr 2013 23:39:47 -0700 (PDT) From: "Roni Even" To: Date: Sun, 21 Apr 2013 09:39:14 +0300 Message-ID: <014401ce3e5a$f28208b0$d7861a10$@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_0145_01CE3E74.17CFDCF0" X-Mailer: Microsoft Outlook 14.0 Thread-Index: Ac4+WqMohGH7ErmuT8io65UqpDJFqA== Content-Language: en-us Cc: draft-ietf-avtcore-clksrc@tools.ietf.org Subject: [AVTCORE] WGLC on draft-ietf-avtcore-clksrc-03 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 21 Apr 2013 06:39:53 -0000 This is a multipart message in MIME format. ------=_NextPart_000_0145_01CE3E74.17CFDCF0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Hi, I would like to start a WGLC on http://tools.ietf.org/html/draft-ietf-avtcore-clksrc-03 , RTP Clock Source Signalling. The WGLC will end on May 12th , 2013 Please review the draft and send comments to the list. For the draft authors; Are you aware of any IPR that applies to draft-ietf-avtcore-clksrc-03? If so, has this IPR been disclosed in compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details)? The above question is needed for the document write-up when sent to publication. Thanks Roni Even AVTcore co-chair ------=_NextPart_000_0145_01CE3E74.17CFDCF0 Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Hi,

I would =
like to start a WGLC on http://t=
ools.ietf.org/html/draft-ietf-avtcore-clksrc-03  , RTP Clock =
Source Signalling.=

 =

The WGLC will = end on May 12th , 2013

 

Please = review the draft and send comments to the list.

 

For the =
draft authors;  Are you aware of any IPR that applies to =
draft-ietf-avtcore-clksrc-03?
 If so, =
has this IPR been disclosed in compliance with IETF IPR rules (see RFCs =
3979, 4879, 3669 and 5378 for more =
details)?
The above =
question is needed for the document write-up when sent to =
publication.
 =

Thanks

 

Roni = Even

AVTcore =  co-chair

 

 

------=_NextPart_000_0145_01CE3E74.17CFDCF0-- From abegen@cisco.com Sun Apr 21 23:11:44 2013 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6B90C21F8B16 for ; Sun, 21 Apr 2013 23:11:44 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VwjxdWkVx8qE for ; Sun, 21 Apr 2013 23:11:41 -0700 (PDT) Received: from rcdn-iport-1.cisco.com (rcdn-iport-1.cisco.com [173.37.86.72]) by ietfa.amsl.com (Postfix) with ESMTP id 647DC21F8ADC for ; Sun, 21 Apr 2013 23:11:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=8322; q=dns/txt; s=iport; t=1366611101; x=1367820701; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=XXfPn9UFXH1rROaCqt82Ex5yy1tuXSZHxGjpNv7yJYg=; b=dMeVPmpYtxyUmfqa9Ni3COeFTbArJXZvZV0OSbYDKvhJVHA1JCwhYxAz asxjTLTxKzIpoRl7BMyUsMG3LUl2Lxs0iYVCOs81OV0v+n5jVYxNb6EzT RC0D0+T3hhgTuDAbaKccoEF11dsQU+InfR2bSBI2ymCAs4vH8wm1MWVAi o=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ak0FANDTdFGtJV2a/2dsb2JhbABPgmUhNkSCE1q9Tw12FnSCHwEBAQQBAQEJFxFFDAIEAQYCEQMBAgECAgYdAwIEGQwLFAEICAIEDgUIAYgLAQYFjjebB5FqBIEfjWsWGwcGgi4yYQOYOI93gwyCKA X-IronPort-AV: E=Sophos;i="4.87,524,1363132800"; d="scan'208";a="201169645" Received: from rcdn-core-3.cisco.com ([173.37.93.154]) by rcdn-iport-1.cisco.com with ESMTP; 22 Apr 2013 06:11:40 +0000 Received: from xhc-aln-x13.cisco.com (xhc-aln-x13.cisco.com [173.36.12.87]) by rcdn-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r3M6BeG3016471 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 22 Apr 2013 06:11:40 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-aln-x13.cisco.com ([173.36.12.87]) with mapi id 14.02.0318.004; Mon, 22 Apr 2013 01:11:40 -0500 From: "Ali C. Begen (abegen)" To: Magnus Westerlund Thread-Topic: [AVTCORE] I-D Action: draft-ietf-avtcore-6222bis-02.txt Thread-Index: AQHOODKPqSyveEg+S0yJ9MQm6MP6c5jUfWGAgALkiQCAC1jhAA== Date: Mon, 22 Apr 2013 06:11:39 +0000 Message-ID: In-Reply-To: <516BCE60.6050707@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.2.130206 x-originating-ip: [10.21.148.112] Content-Type: text/plain; charset="utf-8" Content-ID: Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "avt@ietf.org" Subject: Re: [AVTCORE] I-D Action: draft-ietf-avtcore-6222bis-02.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Apr 2013 06:11:44 -0000 SGkgTWFnbnVzLA0KDQpJIGFtIG5vdCB0aGF0IGtub3dsZWRnZWFibGUgYWJvdXQgaG93IHRoZSB2 aXJ0dWFsaXphdGlvbiBwcm9kdWN0cyBkZWFsDQp3aXRoIHRoZWlyIG5ldHdvcmtpbmcgaW50ZXJm YWNlcy4gV2hpbGUgSSBhbSBub3QgY29tZm9ydGFibGUgdG8gbWFrZSBhDQpnZW5lcmFsaXphdGlv biBhbmQgc29tZXdoYXQgYmxhbWUgc3VjaCBwcm9kdWN0cyBmb3IgaW1wcm9wZXIgc2VsZWN0aW9u IG9mDQptYWMgYWRkcmVzc2VzLCB3aGF0IGFib3V0IHRoZSBmb2xsb3dpbmcgY2hhbmdlPw0KDQpB ZnRlciB0aGUgZm9sbG93aW5nIGJ1bGxldCBpbiBzZWN0aW9uIDQuMjoNCg0KVG8gcHJvZHVjZSBh IHNob3J0LXRlcm0gcGVyc2lzdGVudCBSVENQIENOQU1FLCBhbiBSVFAgZW5kcG9pbnQNCiAgICAg IE1VU1QgZWl0aGVyIChhKSB1c2UgdGhlIG51bWVyaWMgcmVwcmVzZW50YXRpb24gb2YgdGhlIGxh eWVyLTINCiAgICAgIChNZWRpYSBBY2Nlc3MgQ29udHJvbCAoTUFDKSkgYWRkcmVzcyBvZiB0aGUg aW50ZXJmYWNlIHRoYXQgaXMgdXNlZA0KICAgICAgdG8gaW5pdGlhdGUgdGhlIGluaXRpYWwgc2V0 IG9mIFJUUCBzZXNzaW9ucyBhcyB0aGUgImhvc3QiIHBhcnQgb2YNCiAgICAgIGl0cyBSVENQIENO QU1FIG9yIChiKSBnZW5lcmF0ZSBhbmQgdXNlIGFuIGlkZW50aWZpZXIgYnkgZm9sbG93aW5nDQog ICAgICB0aGUgcHJvY2VkdXJlIGRlc2NyaWJlZCBpbiBTZWN0aW9uIDUuICBJbiBlaXRoZXIgY2Fz ZSwgdGhlDQogICAgICBwcm9jZWR1cmUgaXMgcGVyZm9ybWVkIG9uY2UgcGVyIGluaXRpYWxpemF0 aW9uIG9mIHRoZSBzb2Z0d2FyZS4NCiAgICAgIEFmdGVyIG9idGFpbmluZyBhbiBpZGVudGlmaWVy IGluIGNhc2Ugb2YgKGEpLCB0aGUgNDggYml0cyBhcmUNCiAgICAgIGNvbnZlcnRlZCB0byB0aGUg c3RhbmRhcmQgY29sb24tc2VwYXJhdGVkIGhleGFkZWNpbWFsIGZvcm1hdA0KICAgICAgW1JGQzUz NDJdLCBlLmcuLCAiMDA6MjM6MzI6YWY6OWI6YWEiLCByZXN1bHRpbmcgaW4gYSAxNy1vY3RldA0K ICAgICAgcHJpbnRhYmxlIHN0cmluZyByZXByZXNlbnRhdGlvbi4gIEluIGNhc2Ugb2YgKGIpLCBt aW5pbWFsbHkgdGhlDQogICAgICBsZWFzdCBzaWduaWZpY2FudCA5NiBiaXRzIFNIT1VMRCBiZSBj b252ZXJ0ZWQgdG8gQVNDSUkgdXNpbmcNCiAgICAgIEJhc2U2NCBlbmNvZGluZyBbUkZDNDY0OF0g KHRvIGNvbXByb21pc2UgYmV0d2VlbiBwYWNrZXQgc2l6ZSBhbmQNCiAgICAgIHVuaXF1ZW5lc3Mg LSByZWZlciB0byBTZWN0aW9uIDYuMSkuICBJZiA5NiBiaXRzIGFyZSB1c2VkLCB0aGUNCiAgICAg IHJlc3VsdGluZyBzdHJpbmcgd2lsbCBiZSAxNiBvY3RldHMuDQoNCg0KQWRkIHRoZSBmb2xsb3dp bmcgdGV4dD8NCg0KIkluIHNvbWUgZW52aXJvbm1lbnRzIChmb3IgZXhhbXBsZSwgYSB2aXJ0dWFs aXplZCBvcGVyYXRpbmcgc3lzdGVtKSwgdGhlDQpNQUMgYWRkcmVzcyBtYXkgbm90IGJlIHVuaXF1 ZSBhcyBleHBlY3RlZC4gSW4gdGhlc2UgY2FzZXMsIHVzaW5nIG9wdGlvbg0KKGIpIGFib3ZlIGlz IFJFQ09NTUVOREVELiINCg0KLWFjYmVnZW4NCg0KDQotLS0tLU9yaWdpbmFsIE1lc3NhZ2UtLS0t LQ0KRnJvbTogTWFnbnVzIFdlc3Rlcmx1bmQgPG1hZ251cy53ZXN0ZXJsdW5kQGVyaWNzc29uLmNv bT4NCkRhdGU6IE1vbmRheSwgQXByaWwgMTUsIDIwMTMgNjo1NCBQTQ0KVG86ICJBbGkgQy4gQmVn ZW4iIDxhYmVnZW5AY2lzY28uY29tPg0KQ2M6ICJhdnRAaWV0Zi5vcmciIDxhdnRAaWV0Zi5vcmc+ DQpTdWJqZWN0OiBSZTogW0FWVENPUkVdIEktRCBBY3Rpb246IGRyYWZ0LWlldGYtYXZ0Y29yZS02 MjIyYmlzLTAyLnR4dA0KDQo+SGksDQo+KGFzIGluZGl2aWR1YWwpDQo+DQo+DQo+SSByZWFsaXpl IG9uZSBwYXJ0IG9mIG15IGZpcnN0IGlzc3VlIHdhcyB0aGUgcXVlc3Rpb24gb2YgaG93IGNvbW1v bmx5DQo+TUFDIGFkZHJlc3NlcyBhcmUgZ29pbmcgdG8gYmUgaGF2aW5nIHRoZSBpbnRlbmRlZCB1 bmlxdWVuZXNzIHByb3BlcnRpZXMuDQo+VGhpcyBnb3QgYSBiaXQgbG9zdCBkZWFsaW5nIHdpdGgg dGhlIGVxdWFsbHkgaW1wb3J0YW50IGFzcGVjdCB0aGF0IHlvdQ0KPm5lZWQgdG8ga2VlcCB0aGUg b25lIHlvdSBoYXZlIGdlbmVyYXRlZCBhY3Jvc3MgYW55IG1vYmlsaXR5IGV2ZW50IGV0Yy4NCj4N Cj5UaGUgY29tbWVudCBmcm9tIFN0ZXZlIFVuZGVyd29vZCwgZG8gcmFpc2UgdGhpcyBhcyBiZWlu ZyBhIGdlbnVpbmUgaXNzdWUNCj5pbiBzb21lIGNhc2VzLiBXaGF0IEkgYmVsaWV2ZSB3b3VsZCBi ZSBnb29kLCBpcyB0byBtYWtlIGl0IGNsZWFyIHRoYXQgYW4NCj5pbXBsZW1lbnRhdGlvbiBtYXkg aGF2ZSBpc3N1ZXMgd2l0aCB1c2luZyBNQUMgYWRkcmVzcyBpbiBjZXJ0YWluIHR5cGVzDQo+b2Yg ZW52aXJvbm1lbnRzLCBsaWtlIHZpcnR1bGF6YXRpb24uIEkgdGhpbmsgdGhlIHNpbXBsZSBmaXgg aXMgdG8gcHJlc3MNCj50aGF0IHVzaW5nIGEgc3RvcmVkIHJhbmRvbSB2YWx1ZSBtaWdodCBoYXZl IGJldHRlciBwcm9wZXJ0aWVzLg0KPg0KPkNoZWVycw0KPg0KPk1hZ251cw0KPg0KPg0KPg0KPg0K Pk9uIDIwMTMtMDQtMTMgMTI6NDQsIEFsaSBDLiBCZWdlbiAoYWJlZ2VuKSB3cm90ZToNCj4+IEkg dGhpbmsgd2UgZ290IGFsbCB0aGUgZXNzZW50aWFsIFdHTEMgY29tbWVudHMgYWRkcmVzc2VkIGlu IHRoaXMNCj4+cmV2aXNpb24uDQo+PiBJZiB0aGVyZSBpcyBzb21ldGhpbmcgd2Ugc2tpcHBlZCwg cGxlYXNlIGxldCB1cyBrbm93Lg0KPj4gDQo+PiAtYWNiZWdlbg0KPj4gDQo+PiAtLS0tLU9yaWdp bmFsIE1lc3NhZ2UtLS0tLQ0KPj4gRnJvbTogImludGVybmV0LWRyYWZ0c0BpZXRmLm9yZyIgPGlu dGVybmV0LWRyYWZ0c0BpZXRmLm9yZz4NCj4+IERhdGU6IFNhdHVyZGF5LCBBcHJpbCAxMywgMjAx MyAxOjM0IFBNDQo+PiBUbzogImktZC1hbm5vdW5jZUBpZXRmLm9yZyIgPGktZC1hbm5vdW5jZUBp ZXRmLm9yZz4NCj4+IENjOiAiYXZ0QGlldGYub3JnIiA8YXZ0QGlldGYub3JnPg0KPj4gU3ViamVj dDogW0FWVENPUkVdIEktRCBBY3Rpb246IGRyYWZ0LWlldGYtYXZ0Y29yZS02MjIyYmlzLTAyLnR4 dA0KPj4gDQo+Pj4NCj4+PiBBIE5ldyBJbnRlcm5ldC1EcmFmdCBpcyBhdmFpbGFibGUgZnJvbSB0 aGUgb24tbGluZSBJbnRlcm5ldC1EcmFmdHMNCj4+PiBkaXJlY3Rvcmllcy4NCj4+PiBUaGlzIGRy YWZ0IGlzIGEgd29yayBpdGVtIG9mIHRoZSBBdWRpby9WaWRlbyBUcmFuc3BvcnQgQ29yZSBNYWlu dGVuYW5jZQ0KPj4+IFdvcmtpbmcgR3JvdXAgb2YgdGhlIElFVEYuDQo+Pj4NCj4+PiAJVGl0bGUg ICAgICAgICAgIDogR3VpZGVsaW5lcyBmb3IgQ2hvb3NpbmcgUlRQIENvbnRyb2wgUHJvdG9jb2wg KFJUQ1ApDQo+Pj4gQ2Fub25pY2FsIE5hbWVzIChDTkFNRXMpDQo+Pj4gCUF1dGhvcihzKSAgICAg ICA6IEFsaSBCZWdlbg0KPj4+ICAgICAgICAgICAgICAgICAgICAgICAgICBDb2xpbiBQZXJraW5z DQo+Pj4gICAgICAgICAgICAgICAgICAgICAgICAgIERhbiBXaW5nDQo+Pj4gICAgICAgICAgICAg ICAgICAgICAgICAgIEVyaWMgUmVzY29ybGENCj4+PiAJRmlsZW5hbWUgICAgICAgIDogZHJhZnQt aWV0Zi1hdnRjb3JlLTYyMjJiaXMtMDIudHh0DQo+Pj4gCVBhZ2VzICAgICAgICAgICA6IDEwDQo+ Pj4gCURhdGUgICAgICAgICAgICA6IDIwMTMtMDQtMTMNCj4+Pg0KPj4+IEFic3RyYWN0Og0KPj4+ ICAgVGhlIFJUUCBDb250cm9sIFByb3RvY29sIChSVENQKSBDYW5vbmljYWwgTmFtZSAoQ05BTUUp IGlzIGENCj4+PiAgIHBlcnNpc3RlbnQgdHJhbnNwb3J0LWxldmVsIGlkZW50aWZpZXIgZm9yIGFu IFJUUCBlbmRwb2ludC4gIFdoaWxlIHRoZQ0KPj4+ICAgU3luY2hyb25pemF0aW9uIFNvdXJjZSAo U1NSQykgaWRlbnRpZmllciBvZiBhbiBSVFAgZW5kcG9pbnQgbWF5DQo+Pj4gICBjaGFuZ2UgaWYg YSBjb2xsaXNpb24gaXMgZGV0ZWN0ZWQgb3Igd2hlbiB0aGUgUlRQIGFwcGxpY2F0aW9uIGlzDQo+ Pj4gICByZXN0YXJ0ZWQsIGl0cyBSVENQIENOQU1FIGlzIG1lYW50IHRvIHN0YXkgdW5jaGFuZ2Vk LCBzbyB0aGF0IFJUUA0KPj4+ICAgZW5kcG9pbnRzIGNhbiBiZSB1bmlxdWVseSBpZGVudGlmaWVk IGFuZCBhc3NvY2lhdGVkIHdpdGggdGhlaXIgUlRQDQo+Pj4gICBtZWRpYSBzdHJlYW1zLg0KPj4+ DQo+Pj4gICBGb3IgcHJvcGVyIGZ1bmN0aW9uYWxpdHksIFJUQ1AgQ05BTUVzIHNob3VsZCBiZSB1 bmlxdWUgd2l0aGluIHRoZQ0KPj4+ICAgcGFydGljaXBhbnRzIG9mIGFuIFJUUCBzZXNzaW9uLiAg SG93ZXZlciwgdGhlIGV4aXN0aW5nIGd1aWRlbGluZXMgZm9yDQo+Pj4gICBjaG9vc2luZyB0aGUg UlRDUCBDTkFNRSBwcm92aWRlZCBpbiB0aGUgUlRQIHN0YW5kYXJkIGFyZSBpbnN1ZmZpY2llbnQN Cj4+PiAgIHRvIGFjaGlldmUgdGhpcyB1bmlxdWVuZXNzLiAgUkZDIDYyMjIgd2FzIHB1Ymxpc2hl ZCB0byB1cGRhdGUgdGhvc2UNCj4+PiAgIGd1aWRlbGluZXMgdG8gYWxsb3cgZW5kcG9pbnRzIHRv IGNob29zZSB1bmlxdWUgUlRDUCBDTkFNRXMuDQo+Pj4gICBVbmZvcnR1bmF0ZWx5LCBsYXRlciBp bnZlc3RpZ2F0aW9ucyBzaG93ZWQgdGhhdCBzb21lIHBhcnRzIG9mIHRoZSBuZXcNCj4+PiAgIGFs Z29yaXRobXMgd2VyZSB1bm5lY2Vzc2FyaWx5IGNvbXBsaWNhdGVkIGFuZC9vciBpbmVmZmVjdGl2 ZS4gIFRoaXMNCj4+PiAgIGRvY3VtZW50IGFkZHJlc3NlcyB0aGVzZSBjb25jZXJucyBhbmQgcmVw bGFjZXMgUkZDIDYyMjIuDQo+Pj4NCj4+Pg0KPj4+IFRoZSBJRVRGIGRhdGF0cmFja2VyIHN0YXR1 cyBwYWdlIGZvciB0aGlzIGRyYWZ0IGlzOg0KPj4+IGh0dHBzOi8vZGF0YXRyYWNrZXIuaWV0Zi5v cmcvZG9jL2RyYWZ0LWlldGYtYXZ0Y29yZS02MjIyYmlzDQo+Pj4NCj4+PiBUaGVyZSdzIGFsc28g YSBodG1saXplZCB2ZXJzaW9uIGF2YWlsYWJsZSBhdDoNCj4+PiBodHRwOi8vdG9vbHMuaWV0Zi5v cmcvaHRtbC9kcmFmdC1pZXRmLWF2dGNvcmUtNjIyMmJpcy0wMg0KPj4+DQo+Pj4gQSBkaWZmIGZy b20gdGhlIHByZXZpb3VzIHZlcnNpb24gaXMgYXZhaWxhYmxlIGF0Og0KPj4+IGh0dHA6Ly93d3cu aWV0Zi5vcmcvcmZjZGlmZj91cmwyPWRyYWZ0LWlldGYtYXZ0Y29yZS02MjIyYmlzLTAyDQo+Pj4N Cj4+Pg0KPj4+IEludGVybmV0LURyYWZ0cyBhcmUgYWxzbyBhdmFpbGFibGUgYnkgYW5vbnltb3Vz IEZUUCBhdDoNCj4+PiBmdHA6Ly9mdHAuaWV0Zi5vcmcvaW50ZXJuZXQtZHJhZnRzLw0KPj4+DQo+ Pj4gX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18NCj4+PiBB dWRpby9WaWRlbyBUcmFuc3BvcnQgQ29yZSBNYWludGVuYW5jZQ0KPj4+IGF2dEBpZXRmLm9yZw0K Pj4+IGh0dHBzOi8vd3d3LmlldGYub3JnL21haWxtYW4vbGlzdGluZm8vYXZ0DQo+Pj4NCj4+IA0K Pj4gDQo+PiBfX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fXw0K Pj4gQXVkaW8vVmlkZW8gVHJhbnNwb3J0IENvcmUgTWFpbnRlbmFuY2UNCj4+IGF2dEBpZXRmLm9y Zw0KPj4gaHR0cHM6Ly93d3cuaWV0Zi5vcmcvbWFpbG1hbi9saXN0aW5mby9hdnQNCj4+IA0KPg0K Pg0KPi0tIA0KPg0KPk1hZ251cyBXZXN0ZXJsdW5kDQo+DQo+LS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPk11bHRp bWVkaWEgVGVjaG5vbG9naWVzLCBFcmljc3NvbiBSZXNlYXJjaCBFQUIvVFZNDQo+LS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLQ0KPkVyaWNzc29uIEFCICAgICAgICAgICAgICAgIHwgUGhvbmUgICs0NiAxMCA3MTQ4Mjg3 DQo+RsOkcsO2Z2F0YW4gNiAgICAgICAgICAgICAgICB8IE1vYmlsZSArNDYgNzMgMDk0OTA3OQ0K PlNFLTE2NCA4MCBTdG9ja2hvbG0sIFN3ZWRlbnwgbWFpbHRvOiBtYWdudXMud2VzdGVybHVuZEBl cmljc3Nvbi5jb20NCj4tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+DQo+DQoNCg0K From magnus.westerlund@ericsson.com Sun Apr 21 23:59:29 2013 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B29BC21F8518 for ; Sun, 21 Apr 2013 23:59:29 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -104.921 X-Spam-Level: X-Spam-Status: No, score=-104.921 tagged_above=-999 required=5 tests=[AWL=-1.328, BAYES_00=-2.599, HELO_EQ_SE=0.35, MANGLED_PREMTR=2.3, RCVD_IN_DNSWL_MED=-4, SARE_SUB_6CONS_WORD=0.356, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id U9Vc7JfAmEcP for ; Sun, 21 Apr 2013 23:59:29 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id 989E221F84B0 for ; Sun, 21 Apr 2013 23:59:28 -0700 (PDT) X-AuditID: c1b4fb2d-b7f316d0000028db-48-5174dfcfa0b1 Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 9F.20.10459.FCFD4715; Mon, 22 Apr 2013 08:59:27 +0200 (CEST) Received: from [127.0.0.1] (153.88.115.8) by esessmw0197.eemea.ericsson.se (153.88.115.88) with Microsoft SMTP Server id 8.3.279.1; Mon, 22 Apr 2013 08:59:27 +0200 Message-ID: <5174DFCE.8060502@ericsson.com> Date: Mon, 22 Apr 2013 08:59:26 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: Roni Even References: <014401ce3e5a$f28208b0$d7861a10$@gmail.com> In-Reply-To: <014401ce3e5a$f28208b0$d7861a10$@gmail.com> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprOLMWRmVeSWpSXmKPExsUyM+Jvre75+yWBBq9b5S1e9qxkt5j0dTur xd92Zgdmj52z7rJ7LFnyk8njy+XPbAHMUVw2Kak5mWWpRfp2CVwZtx9aFzzirXjU9ImxgfE2 VxcjJ4eEgInE3/YTbBC2mMSFe+uBbC4OIYFTjBKXr89hgnCWM0p8+rsNrIpXQFviYNM1MJtF QFXi0blzjCA2m4CFxM0fjUBxDg5RgWCJra0xEOWCEidnPmEBsUUE1CRer/0M1sosYCXR8xVi sbCAtUTLkkVgrUIC5hJnj8qChDmBJu5++oEF4jZJiS0v2tkhWvUkplxtYYSw5SWat85mBrGF gC5raOpgncAoNAvJ5llIWmYhaVnAyLyKkT03MTMnvdxwEyMwcA9u+a27g/HUOZFDjNIcLEri vGGuFwKEBNITS1KzU1MLUovii0pzUosPMTJxcEo1MNZrdPKw90cZ2/G3PJl4urTx+f362Z+q 2772JgfXZy+4FK/H9corfz3nHbuo7H8L+RbvrAmPspg9N183/tBLB0XvI5MWdf27Ws31nm2R gcd9htOz7CRaTh39fPmn+Qrbmn0/krKK9qXrVAXmHFztcnPT1lRDNmFfhfqLe/98aBaSe2jR t6ZCR4mlOCPRUIu5qDgRAKbXG9MqAgAA Cc: avt@ietf.org, draft-ietf-avtcore-clksrc@tools.ietf.org Subject: Re: [AVTCORE] WGLC on draft-ietf-avtcore-clksrc-03 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Apr 2013 06:59:29 -0000 Hi, I want my previous submitted comments on -03 to apply. Based on that I think the WG last call is a bit pre-mature. It would have been better to have a solid proposals for the signalling issues on this draft prior to running the last call. Anyway until the negotiation signalling issues are resolved I think there is publication blocking issues on this draft. Cheers Magnus On 2013-04-21 08:39, Roni Even wrote: > Hi, > > I would like to start a WGLC on http://tools.ietf.org/html/draft-ietf-avtcore-clksrc-03 , RTP Clock Source Signalling. > > > > The WGLC will end on May 12^th , 2013 > > > > Please review the draft and send comments to the list. > > > > For the draft authors; Are you aware of any IPR that applies to draft-ietf-avtcore-clksrc-03? > > If so, has this IPR been disclosed in compliance with IETF IPR rules (see RFCs 3979, 4879, 3669 and 5378 for more details)? > > The above question is needed for the document write-up when sent to publication. > > > > Thanks > > > > Roni Even > > AVTcore co-chair > > > > > > > > _______________________________________________ > Audio/Video Transport Core Maintenance > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt > -- Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From magnus.westerlund@ericsson.com Mon Apr 22 00:02:48 2013 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DB7D621F8ADC for ; Mon, 22 Apr 2013 00:02:48 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.806 X-Spam-Level: X-Spam-Status: No, score=-105.806 tagged_above=-999 required=5 tests=[AWL=0.443, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id UsH+FnQMpoGp for ; Mon, 22 Apr 2013 00:02:48 -0700 (PDT) Received: from mailgw7.ericsson.se (mailgw7.ericsson.se [193.180.251.48]) by ietfa.amsl.com (Postfix) with ESMTP id 828FC21F8551 for ; Mon, 22 Apr 2013 00:02:47 -0700 (PDT) X-AuditID: c1b4fb30-b7f266d000000cb5-3f-5174e0964872 Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw7.ericsson.se (Symantec Mail Security) with SMTP id 35.33.03253.690E4715; Mon, 22 Apr 2013 09:02:46 +0200 (CEST) Received: from [127.0.0.1] (153.88.115.8) by esessmw0247.eemea.ericsson.se (153.88.115.94) with Microsoft SMTP Server id 8.3.279.1; Mon, 22 Apr 2013 09:02:44 +0200 Message-ID: <5174E093.2050604@ericsson.com> Date: Mon, 22 Apr 2013 09:02:43 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: "Ali C. Begen (abegen)" References: In-Reply-To: X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFuplluLIzCtJLcpLzFFi42KZGfG3Vnfag5JAg8ntihYPts9ltHjZs5Ld gcljyu+NrB5LlvxkCmCK4rJJSc3JLEst0rdL4MrYO/EzS8F1wYo9m1+zNTA+5u1i5OCQEDCR 2DJXt4uRE8gUk7hwbz1bFyMXh5DAKUaJ3zeOsIAkhASWM0r82FwOYvMKaEscn3uAHcRmEVCV aL4xH8xmE7CQuPmjkQ1kpqhAsMTW1hiIckGJkzOfgI0REdCT2N8xjRGkhFlAUWJSuyRIWFjA ReJN42EmiE0+EpPm3GUDsTkFfCV+tK1ghjhNUmLLi3awTcwCmhKt239D2fISzVtnM0P0aks0 NHWwTmAUmoVk8ywkLbOQtCxgZF7FyJ6bmJmTXm6+iREYpAe3/DbYwbjpvtghRmkOFiVx3nDX CwFCAumJJanZqakFqUXxRaU5qcWHGJk4OKUaGPNybRqYvqktdEhZmbhp4vGmlheTFU5dnb7t 6dnPd9Y8eGej9vlz4YZnkVt+Cd7IT2yPCdN84fmlaNmJTomiMxd+1Hgfqn09ad2TMqW3jwR/ VP/+s1E+RduAT4Q5IuDZ3UV8sdkfVh/qePSlPvNBLoscl8yX31NcLyyLDFw96a3szG+huwXX d/cpsRRnJBpqMRcVJwIARR/UYSACAAA= Cc: "avt@ietf.org" Subject: Re: [AVTCORE] I-D Action: draft-ietf-avtcore-6222bis-02.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Apr 2013 07:02:49 -0000 On 2013-04-22 08:11, Ali C. Begen (abegen) wrote: > Hi Magnus, > > I am not that knowledgeable about how the virtualization products deal > with their networking interfaces. While I am not comfortable to make a > generalization and somewhat blame such products for improper selection of > mac addresses, what about the following change? > > After the following bullet in section 4.2: > > To produce a short-term persistent RTCP CNAME, an RTP endpoint > MUST either (a) use the numeric representation of the layer-2 > (Media Access Control (MAC)) address of the interface that is used > to initiate the initial set of RTP sessions as the "host" part of > its RTCP CNAME or (b) generate and use an identifier by following > the procedure described in Section 5. In either case, the > procedure is performed once per initialization of the software. > After obtaining an identifier in case of (a), the 48 bits are > converted to the standard colon-separated hexadecimal format > [RFC5342], e.g., "00:23:32:af:9b:aa", resulting in a 17-octet > printable string representation. In case of (b), minimally the > least significant 96 bits SHOULD be converted to ASCII using > Base64 encoding [RFC4648] (to compromise between packet size and > uniqueness - refer to Section 6.1). If 96 bits are used, the > resulting string will be 16 octets. > > > Add the following text? > > "In some environments (for example, a virtualized operating system), the > MAC address may not be unique as expected. In these cases, using option > (b) above is RECOMMENDED." > Thanks, that is exactly what I wanted. Resolves my issue fully. I hope others in the WG has input on this. Cheers Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From abegen@cisco.com Mon Apr 22 00:08:43 2013 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 705CF21F8BC5 for ; Mon, 22 Apr 2013 00:08:43 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -10.599 X-Spam-Level: X-Spam-Status: No, score=-10.599 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, RCVD_IN_DNSWL_HI=-8] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Trgkoy7tYyID for ; Mon, 22 Apr 2013 00:08:42 -0700 (PDT) Received: from rcdn-iport-8.cisco.com (rcdn-iport-8.cisco.com [173.37.86.79]) by ietfa.amsl.com (Postfix) with ESMTP id 87C0321F8BBC for ; Mon, 22 Apr 2013 00:08:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=3712; q=dns/txt; s=iport; t=1366614522; x=1367824122; h=from:to:cc:subject:date:message-id:in-reply-to: content-id:content-transfer-encoding:mime-version; bh=06Nogi7xSq9Xv/C/c5MPFl0JyxO3A95dzSaRW7TgC9s=; b=KVexiAGIULH4TaZHGoopbvHGXH8gzQMuCDGcxAAyxdSadAfNwWXF1mCh p03unB+de1MkiUvQt5+d5HpqFDYiKrovW4rdiENepqbDCfZJLPV6loufK 5daZAfqwtUEMMYUPJUU8KH2OqfDcJQYsBDhH2BHLmi2C97cPrMBbNVRWN s=; X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AiAFAL3gdFGtJXHB/2dsb2JhbABPgmUhgw1avUsNeBZ0gh8BAQEEDBcRRQwCBAEGAhEDAQIBAgIGHQMCBBkXFAEICAIEDgUIiAwBjk2bB5FzBIEfjWsWGwcGgi4yYQOoL4MMgig X-IronPort-AV: E=Sophos;i="4.87,524,1363132800"; d="scan'208";a="201374181" Received: from rcdn-core2-6.cisco.com ([173.37.113.193]) by rcdn-iport-8.cisco.com with ESMTP; 22 Apr 2013 07:08:42 +0000 Received: from xhc-rcd-x09.cisco.com (xhc-rcd-x09.cisco.com [173.37.183.83]) by rcdn-core2-6.cisco.com (8.14.5/8.14.5) with ESMTP id r3M78gDA010243 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Mon, 22 Apr 2013 07:08:42 GMT Received: from xmb-aln-x01.cisco.com ([fe80::747b:83e1:9755:d453]) by xhc-rcd-x09.cisco.com ([173.37.183.83]) with mapi id 14.02.0318.004; Mon, 22 Apr 2013 02:08:41 -0500 From: "Ali C. Begen (abegen)" To: Magnus Westerlund Thread-Topic: [AVTCORE] I-D Action: draft-ietf-avtcore-6222bis-02.txt Thread-Index: AQHOODKPqSyveEg+S0yJ9MQm6MP6c5jUfWGAgALkiQCAC1jhAP//d2aAgACYiIA= Date: Mon, 22 Apr 2013 07:08:40 +0000 Message-ID: In-Reply-To: <5174E093.2050604@ericsson.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: user-agent: Microsoft-MacOutlook/14.3.2.130206 x-originating-ip: [10.21.148.112] Content-Type: text/plain; charset="utf-8" Content-ID: <6B5EC98CF4318A40933948323080A381@emea.cisco.com> Content-Transfer-Encoding: base64 MIME-Version: 1.0 Cc: "avt@ietf.org" Subject: Re: [AVTCORE] I-D Action: draft-ietf-avtcore-6222bis-02.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Apr 2013 07:08:43 -0000 LS0tLS1PcmlnaW5hbCBNZXNzYWdlLS0tLS0NCkZyb206IE1hZ251cyBXZXN0ZXJsdW5kIDxtYWdu dXMud2VzdGVybHVuZEBlcmljc3Nvbi5jb20+DQpEYXRlOiBNb25kYXksIEFwcmlsIDIyLCAyMDEz IDQ6MDIgUE0NClRvOiAiQWxpIEMuIEJlZ2VuIiA8YWJlZ2VuQGNpc2NvLmNvbT4NCkNjOiAiYXZ0 QGlldGYub3JnIiA8YXZ0QGlldGYub3JnPg0KU3ViamVjdDogUmU6IFtBVlRDT1JFXSBJLUQgQWN0 aW9uOiBkcmFmdC1pZXRmLWF2dGNvcmUtNjIyMmJpcy0wMi50eHQNCg0KPk9uIDIwMTMtMDQtMjIg MDg6MTEsIEFsaSBDLiBCZWdlbiAoYWJlZ2VuKSB3cm90ZToNCj4+IEhpIE1hZ251cywNCj4+IA0K Pj4gSSBhbSBub3QgdGhhdCBrbm93bGVkZ2VhYmxlIGFib3V0IGhvdyB0aGUgdmlydHVhbGl6YXRp b24gcHJvZHVjdHMgZGVhbA0KPj4gd2l0aCB0aGVpciBuZXR3b3JraW5nIGludGVyZmFjZXMuIFdo aWxlIEkgYW0gbm90IGNvbWZvcnRhYmxlIHRvIG1ha2UgYQ0KPj4gZ2VuZXJhbGl6YXRpb24gYW5k IHNvbWV3aGF0IGJsYW1lIHN1Y2ggcHJvZHVjdHMgZm9yIGltcHJvcGVyIHNlbGVjdGlvbg0KPj5v Zg0KPj4gbWFjIGFkZHJlc3Nlcywgd2hhdCBhYm91dCB0aGUgZm9sbG93aW5nIGNoYW5nZT8NCj4+ IA0KPj4gQWZ0ZXIgdGhlIGZvbGxvd2luZyBidWxsZXQgaW4gc2VjdGlvbiA0LjI6DQo+PiANCj4+ IFRvIHByb2R1Y2UgYSBzaG9ydC10ZXJtIHBlcnNpc3RlbnQgUlRDUCBDTkFNRSwgYW4gUlRQIGVu ZHBvaW50DQo+PiAgICAgICBNVVNUIGVpdGhlciAoYSkgdXNlIHRoZSBudW1lcmljIHJlcHJlc2Vu dGF0aW9uIG9mIHRoZSBsYXllci0yDQo+PiAgICAgICAoTWVkaWEgQWNjZXNzIENvbnRyb2wgKE1B QykpIGFkZHJlc3Mgb2YgdGhlIGludGVyZmFjZSB0aGF0IGlzIHVzZWQNCj4+ICAgICAgIHRvIGlu aXRpYXRlIHRoZSBpbml0aWFsIHNldCBvZiBSVFAgc2Vzc2lvbnMgYXMgdGhlICJob3N0IiBwYXJ0 IG9mDQo+PiAgICAgICBpdHMgUlRDUCBDTkFNRSBvciAoYikgZ2VuZXJhdGUgYW5kIHVzZSBhbiBp ZGVudGlmaWVyIGJ5IGZvbGxvd2luZw0KPj4gICAgICAgdGhlIHByb2NlZHVyZSBkZXNjcmliZWQg aW4gU2VjdGlvbiA1LiAgSW4gZWl0aGVyIGNhc2UsIHRoZQ0KPj4gICAgICAgcHJvY2VkdXJlIGlz IHBlcmZvcm1lZCBvbmNlIHBlciBpbml0aWFsaXphdGlvbiBvZiB0aGUgc29mdHdhcmUuDQo+PiAg ICAgICBBZnRlciBvYnRhaW5pbmcgYW4gaWRlbnRpZmllciBpbiBjYXNlIG9mIChhKSwgdGhlIDQ4 IGJpdHMgYXJlDQo+PiAgICAgICBjb252ZXJ0ZWQgdG8gdGhlIHN0YW5kYXJkIGNvbG9uLXNlcGFy YXRlZCBoZXhhZGVjaW1hbCBmb3JtYXQNCj4+ICAgICAgIFtSRkM1MzQyXSwgZS5nLiwgIjAwOjIz OjMyOmFmOjliOmFhIiwgcmVzdWx0aW5nIGluIGEgMTctb2N0ZXQNCj4+ICAgICAgIHByaW50YWJs ZSBzdHJpbmcgcmVwcmVzZW50YXRpb24uICBJbiBjYXNlIG9mIChiKSwgbWluaW1hbGx5IHRoZQ0K Pj4gICAgICAgbGVhc3Qgc2lnbmlmaWNhbnQgOTYgYml0cyBTSE9VTEQgYmUgY29udmVydGVkIHRv IEFTQ0lJIHVzaW5nDQo+PiAgICAgICBCYXNlNjQgZW5jb2RpbmcgW1JGQzQ2NDhdICh0byBjb21w cm9taXNlIGJldHdlZW4gcGFja2V0IHNpemUgYW5kDQo+PiAgICAgICB1bmlxdWVuZXNzIC0gcmVm ZXIgdG8gU2VjdGlvbiA2LjEpLiAgSWYgOTYgYml0cyBhcmUgdXNlZCwgdGhlDQo+PiAgICAgICBy ZXN1bHRpbmcgc3RyaW5nIHdpbGwgYmUgMTYgb2N0ZXRzLg0KPj4gDQo+PiANCj4+IEFkZCB0aGUg Zm9sbG93aW5nIHRleHQ/DQo+PiANCj4+ICJJbiBzb21lIGVudmlyb25tZW50cyAoZm9yIGV4YW1w bGUsIGEgdmlydHVhbGl6ZWQgb3BlcmF0aW5nIHN5c3RlbSksIHRoZQ0KPj4gTUFDIGFkZHJlc3Mg bWF5IG5vdCBiZSB1bmlxdWUgYXMgZXhwZWN0ZWQuIEluIHRoZXNlIGNhc2VzLCB1c2luZyBvcHRp b24NCj4+IChiKSBhYm92ZSBpcyBSRUNPTU1FTkRFRC4iDQo+PiANCj4NCj5UaGFua3MsIHRoYXQg aXMgZXhhY3RseSB3aGF0IEkgd2FudGVkLiBSZXNvbHZlcyBteSBpc3N1ZSBmdWxseS4NCg0KQ29v bCwgSSB3aWxsIGltcGxlbWVudCB0aGlzIGNoYW5nZSBpbiBhIGZldyBkYXlzIHVubGVzcyB0aGVy ZSBhcmUNCm9iamVjdGlvbnMgYW5kIHRoZW4gbWF5YmUgd2UgY2FuIG1vdmUgZm9yd2FyZD8NCg0K Pg0KPkkgaG9wZSBvdGhlcnMgaW4gdGhlIFdHIGhhcyBpbnB1dCBvbiB0aGlzLg0KPg0KPkNoZWVy cw0KPg0KPk1hZ251cyBXZXN0ZXJsdW5kDQo+DQo+LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0KPk11bHRpbWVkaWEg VGVjaG5vbG9naWVzLCBFcmljc3NvbiBSZXNlYXJjaCBFQUIvVFZNDQo+LS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLQ0K PkVyaWNzc29uIEFCICAgICAgICAgICAgICAgIHwgUGhvbmUgICs0NiAxMCA3MTQ4Mjg3DQo+RsOk csO2Z2F0YW4gNiAgICAgICAgICAgICAgICB8IE1vYmlsZSArNDYgNzMgMDk0OTA3OQ0KPlNFLTE2 NCA4MCBTdG9ja2hvbG0sIFN3ZWRlbnwgbWFpbHRvOiBtYWdudXMud2VzdGVybHVuZEBlcmljc3Nv bi5jb20NCj4tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tDQo+DQo+DQoNCg0K From internet-drafts@ietf.org Mon Apr 22 00:28:55 2013 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D3BC821F8D84; Mon, 22 Apr 2013 00:28:55 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.588 X-Spam-Level: X-Spam-Status: No, score=-102.588 tagged_above=-999 required=5 tests=[AWL=0.012, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id oSH1vbizVOns; Mon, 22 Apr 2013 00:28:55 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 72D8A21F8D61; Mon, 22 Apr 2013 00:28:55 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.44.p3 Message-ID: <20130422072855.29772.6824.idtracker@ietfa.amsl.com> Date: Mon, 22 Apr 2013 00:28:55 -0700 Cc: avt@ietf.org Subject: [AVTCORE] I-D Action: draft-ietf-avtcore-rtp-topologies-update-00.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Apr 2013 07:28:56 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Audio/Video Transport Core Maintenance Wo= rking Group of the IETF. Title : RTP Topologies Author(s) : Magnus Westerlund Stephan Wenger Filename : draft-ietf-avtcore-rtp-topologies-update-00.txt Pages : 37 Date : 2013-04-22 Abstract: This document discusses point to point and multi-endpoint topologies used in Real-time Transport Protocol (RTP)-based environments. In particular, centralized topologies commonly employed in the video conferencing industry are mapped to the RTP terminology. This document is updated with additional topologies and are intended to replace RFC 5117. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-avtcore-rtp-topologies-update There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-avtcore-rtp-topologies-update-00 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From internet-drafts@ietf.org Mon Apr 22 02:10:56 2013 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E2AF21F8F02; Mon, 22 Apr 2013 02:10:56 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.59 X-Spam-Level: X-Spam-Status: No, score=-102.59 tagged_above=-999 required=5 tests=[AWL=0.010, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ie3uF3bSCksi; Mon, 22 Apr 2013 02:10:55 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id AE44821F8EA5; Mon, 22 Apr 2013 02:10:55 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.44.p3 Message-ID: <20130422091055.21832.72951.idtracker@ietfa.amsl.com> Date: Mon, 22 Apr 2013 02:10:55 -0700 Cc: avt@ietf.org Subject: [AVTCORE] I-D Action: draft-ietf-avtcore-multiplex-guidelines-00.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Apr 2013 09:10:56 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Audio/Video Transport Core Maintenance Wo= rking Group of the IETF. Title : Guidelines for using the Multiplexing Features of RTP Author(s) : Magnus Westerlund Bo Burman Colin Perkins Harald Tveit Alvestrand Filename : draft-ietf-avtcore-multiplex-guidelines-00.txt Pages : 48 Date : 2013-04-22 Abstract: Real-time Transport Protocol (RTP) is a flexible protocol possible to use in a wide range of applications and network and system topologies. This flexibility and the implications of different choices should be understood by any application developer using RTP. To facilitate that understanding, this document contains an in-depth discussion of the usage of RTP's multiplexing points; the RTP session and the Synchronisation Source Identifier (SSRC). The document tries to give guidance and source material for an analysis on the most suitable choices for the application being designed. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-avtcore-multiplex-guidelines There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-avtcore-multiplex-guidelines-00 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From magnus.westerlund@ericsson.com Mon Apr 22 02:15:27 2013 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id DA5E821F8E2C for ; Mon, 22 Apr 2013 02:15:27 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.028 X-Spam-Level: X-Spam-Status: No, score=-106.028 tagged_above=-999 required=5 tests=[AWL=0.221, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HIxca0SOnjrT for ; Mon, 22 Apr 2013 02:15:27 -0700 (PDT) Received: from mailgw1.ericsson.se (mailgw1.ericsson.se [193.180.251.45]) by ietfa.amsl.com (Postfix) with ESMTP id A869721F8517 for ; Mon, 22 Apr 2013 02:15:25 -0700 (PDT) X-AuditID: c1b4fb2d-b7f316d0000028db-17-5174ffaca8c3 Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw1.ericsson.se (Symantec Mail Security) with SMTP id 6E.5D.10459.CAFF4715; Mon, 22 Apr 2013 11:15:24 +0200 (CEST) Received: from [127.0.0.1] (153.88.115.8) by esessmw0247.eemea.ericsson.se (153.88.115.94) with Microsoft SMTP Server id 8.3.279.1; Mon, 22 Apr 2013 11:15:18 +0200 Message-ID: <5174FFA6.4060701@ericsson.com> Date: Mon, 22 Apr 2013 11:15:18 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: avt@ietf.org References: <20130422072855.29772.6824.idtracker@ietfa.amsl.com> In-Reply-To: <20130422072855.29772.6824.idtracker@ietfa.amsl.com> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrFJMWRmVeSWpSXmKPExsUyM+Jvre6a/yWBBm/Wa1m87FnJ7sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujDdXd7AWrBCo+LJ9B3MD4zeeLkZODgkBE4m7n1+zQ9hiEhfu rWfrYuTiEBI4xSgx9WUnE4SznFFizuuDLCBVvALaEmd/LWAGsVkEVCUWfvrBCmKzCVhI3PzR CNTNwSEqECyxtTUGolxQ4uTMJ2CtIgICEiu2/wWzhQWCJB6cOwVmCwk4SPycfIUNxOYUcJR4 /3ol1EGSEltetIPZzAJ6ElOutjBC2PISzVtnM0P0aks0NHWwTmAUnIVk3SwkLbOQtCxgZF7F yJ6bmJmTXm64iREYfge3/NbdwXjqnMghRmkOFiVx3jDXCwFCAumJJanZqakFqUXxRaU5qcWH GJk4OKUaGAtqcnMu1ottfavMmrfba3dqsOIDeUElPgNLCfbmFalbCg2vyIifP88tvr/jW67H Xet3XyafSjwouOaMUUDnRkHXQ58DJp6IqDiwt1nUsOGRsWzw/+fB+5u5/1xZELXZt/W2JP+p 9vmuUZcZHj16srXg3EFpB4mgyH9VOV1PlFWlj0nu3OCUo8RSnJFoqMVcVJwIAFzOgpENAgAA Subject: Re: [AVTCORE] I-D Action: draft-ietf-avtcore-rtp-topologies-update-00.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Apr 2013 09:15:28 -0000 WG, This first WG version has no changes compared to the last individual version. As usual suggestions for improvements are highly appreciated. Cheers Magnus On 2013-04-22 09:28, internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Audio/Video Transport Core Maintenance Working Group of the IETF. > > Title : RTP Topologies > Author(s) : Magnus Westerlund > Stephan Wenger > Filename : draft-ietf-avtcore-rtp-topologies-update-00.txt > Pages : 37 > Date : 2013-04-22 > > Abstract: > This document discusses point to point and multi-endpoint topologies > used in Real-time Transport Protocol (RTP)-based environments. In > particular, centralized topologies commonly employed in the video > conferencing industry are mapped to the RTP terminology. > > This document is updated with additional topologies and are intended > to replace RFC 5117. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-avtcore-rtp-topologies-update > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-avtcore-rtp-topologies-update-00 > > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > Audio/Video Transport Core Maintenance > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt > > -- Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From magnus.westerlund@ericsson.com Mon Apr 22 02:16:51 2013 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 5D29521F8E2C for ; Mon, 22 Apr 2013 02:16:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -106.059 X-Spam-Level: X-Spam-Status: No, score=-106.059 tagged_above=-999 required=5 tests=[AWL=0.190, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kCWEeHIX0LDX for ; Mon, 22 Apr 2013 02:16:50 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 4776621F8517 for ; Mon, 22 Apr 2013 02:16:50 -0700 (PDT) X-AuditID: c1b4fb25-b7f366d000004d10-6a-5175000136d0 Received: from esessmw0197.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 6A.2C.19728.10005715; Mon, 22 Apr 2013 11:16:49 +0200 (CEST) Received: from [127.0.0.1] (153.88.115.8) by esessmw0197.eemea.ericsson.se (153.88.115.88) with Microsoft SMTP Server id 8.3.279.1; Mon, 22 Apr 2013 11:16:49 +0200 Message-ID: <51750000.1070701@ericsson.com> Date: Mon, 22 Apr 2013 11:16:48 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: avt@ietf.org References: <20130422091055.21832.72951.idtracker@ietfa.amsl.com> In-Reply-To: <20130422091055.21832.72951.idtracker@ietfa.amsl.com> X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrJJMWRmVeSWpSXmKPExsUyM+JvrS4jQ2mgwcq7shYve1ayOzB6LFny kymAMYrLJiU1J7MstUjfLoErY9uhhYwFh4QrLuycy9LAOIm/i5GTQ0LARGLVhm+sELaYxIV7 69m6GLk4hAROMUqsW7qCEcJZzihx8FEXUIaDg1dAW6L3Uw5IA4uAqsSjH3fBmtkELCRu/mgE KxEVCJbY2hoDEuYVEJQ4OfMJC4gtIiAgsWL7XzBbWCBQ4tGyg2wgtpCAo8TGKwvBbE4BJ4nG SSeh7pGU2PKinR3EZhbQk5hytYURwpaXaN46mxmiV1uioamDdQKj4Cwk62YhaZmFpGUBI/Mq RvbcxMyc9HKjTYzA4Du45bfqDsY750QOMUpzsCiJ84a7XggQEkhPLEnNTk0tSC2KLyrNSS0+ xMjEwSnVwCgfYpxZIPjzZ8Yfr89nbjZe39v29RlrILvbdQml873c15RES/OeTN78Ymr1ix9B Qhq6Qv8SzTPvVP/5OdnjUG39i7xHTYnxVh16Ce21urMmCb8K+P0oTzrXN3hS9awbrxMdnb2u SpawHK6eLxgbfnGW1vErVVJCuXkBDWu9Llr94PM/WqawSImlOCPRUIu5qDgRAEkvlqUMAgAA Subject: Re: [AVTCORE] I-D Action: draft-ietf-avtcore-multiplex-guidelines-00.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Apr 2013 09:16:51 -0000 WG, This version contains no changes compared to the last individual version except a capatizliation of Media Sink, that happened to get included from the upcoming update. Cheers Magnus On 2013-04-22 11:10, internet-drafts@ietf.org wrote: > > A New Internet-Draft is available from the on-line Internet-Drafts directories. > This draft is a work item of the Audio/Video Transport Core Maintenance Working Group of the IETF. > > Title : Guidelines for using the Multiplexing Features of RTP > Author(s) : Magnus Westerlund > Bo Burman > Colin Perkins > Harald Tveit Alvestrand > Filename : draft-ietf-avtcore-multiplex-guidelines-00.txt > Pages : 48 > Date : 2013-04-22 > > Abstract: > Real-time Transport Protocol (RTP) is a flexible protocol possible to > use in a wide range of applications and network and system > topologies. This flexibility and the implications of different > choices should be understood by any application developer using RTP. > To facilitate that understanding, this document contains an in-depth > discussion of the usage of RTP's multiplexing points; the RTP session > and the Synchronisation Source Identifier (SSRC). The document tries > to give guidance and source material for an analysis on the most > suitable choices for the application being designed. > > > The IETF datatracker status page for this draft is: > https://datatracker.ietf.org/doc/draft-ietf-avtcore-multiplex-guidelines > > There's also a htmlized version available at: > http://tools.ietf.org/html/draft-ietf-avtcore-multiplex-guidelines-00 > > > Internet-Drafts are also available by anonymous FTP at: > ftp://ftp.ietf.org/internet-drafts/ > > _______________________________________________ > Audio/Video Transport Core Maintenance > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt > > -- Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From ron.even.tlv@gmail.com Mon Apr 22 07:22:34 2013 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id BAA0921E8055 for ; Mon, 22 Apr 2013 07:22:34 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 1.682 X-Spam-Level: * X-Spam-Status: No, score=1.682 tagged_above=-999 required=5 tests=[AWL=-1.145, BAYES_00=-2.599, DOS_OUTLOOK_TO_MX=1, FH_HOST_EQ_D_D_D_D=0.765, MANGLED_PREMTR=2.3, RCVD_IN_PBL=0.905, RDNS_DYNAMIC=0.1, SARE_SUB_6CONS_WORD=0.356] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id MuYTVtZk1w1G for ; Mon, 22 Apr 2013 07:22:34 -0700 (PDT) Received: from mail-we0-x22b.google.com (mail-we0-x22b.google.com [IPv6:2a00:1450:400c:c03::22b]) by ietfa.amsl.com (Postfix) with ESMTP id E0C9621E804E for ; Mon, 22 Apr 2013 07:22:33 -0700 (PDT) Received: by mail-we0-f171.google.com with SMTP id i48so6480041wef.30 for ; Mon, 22 Apr 2013 07:22:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:content-type:content-transfer-encoding :x-mailer:thread-index:content-language; bh=/olN2W89rKp4+BqR3qjpnuwJbKUbY0QXf/227338sWM=; b=0+gdssH7V6V6YgCYx6yX9GyMF1wTc13+Rc4Cpf21WJuztTjlQ2sgECjHKC0DWqtKLj mHmYB3e0QYvFDCmSN38JX5zch2A44PP7BH5z+Ko7Ea9SmADKXNQgJCcY/EA0hVP40Udy 7OZrpZpxbCoqMvkFrqlRofAzxfV+HETqPENPV7V0IT7QXg6mjDmOTPLcdjJc5uw6JEJO IKeLeS15XxpBiHL4KpFVFFnvDt2zwbccCaO3GXMdT0nk/jvvvdCPHgiwftwKZ+GH2V20 p5p84KvcES4uYKK9ob911JJcq3MziuYdGg6AnvB2ttiGYz6mdc4Sd4rt3uuWd7VXBhTE NBJg== X-Received: by 10.180.98.198 with SMTP id ek6mr19017610wib.7.1366640550632; Mon, 22 Apr 2013 07:22:30 -0700 (PDT) Received: from RoniE (bzq-79-181-177-28.red.bezeqint.net. [79.181.177.28]) by mx.google.com with ESMTPS id cb50sm41010928eeb.14.2013.04.22.07.22.27 (version=TLSv1 cipher=RC4-SHA bits=128/128); Mon, 22 Apr 2013 07:22:29 -0700 (PDT) From: "Roni Even" To: "'Magnus Westerlund'" References: <014401ce3e5a$f28208b0$d7861a10$@gmail.com> <5174DFCE.8060502@ericsson.com> In-Reply-To: <5174DFCE.8060502@ericsson.com> Date: Mon, 22 Apr 2013 17:21:55 +0300 Message-ID: <01da01ce3f64$c0491ea0$40db5be0$@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQIe1THQHZq/zcactZz4Shl+b2CEzQJVzkwwmC5wFDA= Content-Language: en-us Cc: avt@ietf.org, draft-ietf-avtcore-clksrc@tools.ietf.org Subject: Re: [AVTCORE] WGLC on draft-ietf-avtcore-clksrc-03 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Apr 2013 14:22:34 -0000 Hi Magnus, Your comments should be discussed and if they will require changes, we = will most probably need a second WGLC. I hope that we can get more reviews and progress this document faster. = It will block IDMS that went to publication. Roni Even AVTCore co-chair -----Original Message----- From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com]=20 Sent: 22 April, 2013 9:59 AM To: Roni Even Cc: avt@ietf.org; draft-ietf-avtcore-clksrc@tools.ietf.org Subject: Re: [AVTCORE] WGLC on draft-ietf-avtcore-clksrc-03 Hi, I want my previous submitted comments on -03 to apply. Based on that I = think the WG last call is a bit pre-mature. It would have been better to have = a solid proposals for the signalling issues on this draft prior to running = the last call. Anyway until the negotiation signalling issues are resolved I think = there is publication blocking issues on this draft. Cheers Magnus On 2013-04-21 08:39, Roni Even wrote: > Hi, >=20 > I would like to start a WGLC on http://tools.ietf.org/html/draft-ietf-avtcore-clksrc-03 , RTP Clock = Source Signalling. >=20 > =20 >=20 > The WGLC will end on May 12^th , 2013 >=20 > =20 >=20 > Please review the draft and send comments to the list. >=20 > =20 >=20 > For the draft authors; Are you aware of any IPR that applies to draft-ietf-avtcore-clksrc-03? >=20 > If so, has this IPR been disclosed in compliance with IETF IPR rules = (see RFCs 3979, 4879, 3669 and 5378 for more details)? >=20 > The above question is needed for the document write-up when sent to publication. >=20 > =20 >=20 > Thanks >=20 > =20 >=20 > Roni Even >=20 > AVTcore co-chair >=20 > =20 >=20 > =20 >=20 >=20 >=20 > _______________________________________________ > Audio/Video Transport Core Maintenance avt@ietf.org=20 > https://www.ietf.org/mailman/listinfo/avt >=20 --=20 Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 F=E4r=F6gatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From kevin.gross@avanw.com Mon Apr 22 07:49:26 2013 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 87AAF21F8E2C for ; Mon, 22 Apr 2013 07:49:26 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: 2.842 X-Spam-Level: ** X-Spam-Status: No, score=2.842 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, FH_RELAY_NODNS=1.451, FM_FORGED_GMAIL=0.622, HELO_MISMATCH_NET=0.611, HTML_MESSAGE=0.001, MANGLED_PREMTR=2.3, RDNS_NONE=0.1, SARE_SUB_6CONS_WORD=0.356] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id HC-ZcaPP+MMP for ; Mon, 22 Apr 2013 07:49:25 -0700 (PDT) Received: from qmta03.emeryville.ca.mail.comcast.net (qmta03.emeryville.ca.mail.comcast.net [IPv6:2001:558:fe2d:43:76:96:30:32]) by ietfa.amsl.com (Postfix) with ESMTP id 92DE121F8D79 for ; Mon, 22 Apr 2013 07:49:25 -0700 (PDT) Received: from omta15.emeryville.ca.mail.comcast.net ([76.96.30.71]) by qmta03.emeryville.ca.mail.comcast.net with comcast id T0Ta1l0041Y3wxoA32pRaU; Mon, 22 Apr 2013 14:49:25 +0000 Received: from mail-ia0-x235.google.com ([IPv6:2607:f8b0:4001:c02::235]) by omta15.emeryville.ca.mail.comcast.net with comcast id T2pQ1l0024DaLQc8b2pQ10; Mon, 22 Apr 2013 14:49:25 +0000 Received: by mail-ia0-f181.google.com with SMTP id k38so990026iah.26 for ; Mon, 22 Apr 2013 07:49:23 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:x-received:in-reply-to:references:date:message-id :subject:from:to:cc:content-type; bh=lrI+B2nk3gAsia77yToEwgBfAQaiOw+N+OVGvW4WYp0=; b=Z96HtMiYhngO46xfOlLTYVR6oWYQDvdDZkWU7aVAlDNIhtWFUpciKkshhL+igT9J0Z pfPTTKjXlnPDjCfeP0B157fsKk7I/4/0LUcWDtoxvrlYAvMxCWgbeSQfI7qciWIonKGj PACtA7dY5JLHRJpbxGUPplJfnCefsMiwWc5aIBwwIR79/F13JShor9rlW+LJMcyRYQMX 5itWYw0iiIJhHnTU1Kijt0t1Acwd//vYjZOmuMd0e/BTWRRgvwzV0p6hNA8k9eAX75N+ EaThWpoP9BZmeHUwNicJfY76Js8hE+TLbCMbtZWiTAroL2Tb4f0hSrpV1+m9wiz0Lk/x YLpQ== MIME-Version: 1.0 X-Received: by 10.50.117.3 with SMTP id ka3mr20675690igb.107.1366642163922; Mon, 22 Apr 2013 07:49:23 -0700 (PDT) Received: by 10.50.180.201 with HTTP; Mon, 22 Apr 2013 07:49:23 -0700 (PDT) In-Reply-To: <01da01ce3f64$c0491ea0$40db5be0$@gmail.com> References: <014401ce3e5a$f28208b0$d7861a10$@gmail.com> <5174DFCE.8060502@ericsson.com> <01da01ce3f64$c0491ea0$40db5be0$@gmail.com> Date: Mon, 22 Apr 2013 08:49:23 -0600 Message-ID: From: Kevin Gross To: Roni Even Content-Type: multipart/alternative; boundary=089e01175f6db7426a04daf42cd0 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=comcast.net; s=q20121106; t=1366642165; bh=lrI+B2nk3gAsia77yToEwgBfAQaiOw+N+OVGvW4WYp0=; h=Received:Received:Received:MIME-Version:Received:Date:Message-ID: Subject:From:To:Content-Type; b=ItBZFyri5C9WmSG/KODFwt02SZ9FGwsDSF694lfdP9dSIBZLsUcAiz5VR/JwvcZog fCv/PEDPn3xSONf57TlWzEjAXrS43o+3Vuezs7l1ZbpyRCD55fu5biuv05xQqDs50k RlRQMMJVVLfkSMEkkziuWdXldwhRtguOB4M7qVkADKSSTnoq4ii1dF/NeosriylIVO BLYC5Gp+ZN/ljL13JeQVSOW6Tc7S83trCO1OipBxxaKvVNhYjUvVj8vGigK4fBeln7 Y52e6aHpXkkvx3Sase4NCdt8peVaXY9oxnlEh8sJsgZbFFztVKkdKETXKHjXvwFM1C eAciNKr6s2qcg== Cc: Magnus Westerlund , "avt@ietf.org" , "draft-ietf-avtcore-clksrc@tools.ietf.org" Subject: Re: [AVTCORE] WGLC on draft-ietf-avtcore-clksrc-03 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 22 Apr 2013 14:49:26 -0000 --089e01175f6db7426a04daf42cd0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Discussion is in progress - http://www.ietf.org/mail-archive/web/avt/current/msg15817.html So far we are considering one minor technical change in how future SDP is specified. If Magnus agrees that using RFC 5939 is appropriate for negotiating these parameters we may decide to add a note to that effect. Kevin Gross +1-303-447-0517 Media Network Consultant AVA Networks - www.AVAnw.com , www.X192.org On Mon, Apr 22, 2013 at 8:21 AM, Roni Even wrote: > Hi Magnus, > Your comments should be discussed and if they will require changes, we wi= ll > most probably need a second WGLC. > I hope that we can get more reviews and progress this document faster. It > will block IDMS that went to publication. > Roni Even > AVTCore co-chair > > -----Original Message----- > From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com] > Sent: 22 April, 2013 9:59 AM > To: Roni Even > Cc: avt@ietf.org; draft-ietf-avtcore-clksrc@tools.ietf.org > Subject: Re: [AVTCORE] WGLC on draft-ietf-avtcore-clksrc-03 > > Hi, > > I want my previous submitted comments on -03 to apply. Based on that I > think > the WG last call is a bit pre-mature. It would have been better to have a > solid proposals for the signalling issues on this draft prior to running > the > last call. > > Anyway until the negotiation signalling issues are resolved I think there > is > publication blocking issues on this draft. > > Cheers > > Magnus > > On 2013-04-21 08:39, Roni Even wrote: > > Hi, > > > > I would like to start a WGLC on > http://tools.ietf.org/html/draft-ietf-avtcore-clksrc-03 , RTP Clock > Source > Signalling. > > > > > > > > The WGLC will end on May 12^th , 2013 > > > > > > > > Please review the draft and send comments to the list. > > > > > > > > For the draft authors; Are you aware of any IPR that applies to > draft-ietf-avtcore-clksrc-03? > > > > If so, has this IPR been disclosed in compliance with IETF IPR rules > (see > RFCs 3979, 4879, 3669 and 5378 for more details)? > > > > The above question is needed for the document write-up when sent to > publication. > > > > > > > > Thanks > > > > > > > > Roni Even > > > > AVTcore co-chair > > > > > > > > > > > > > > > > _______________________________________________ > > Audio/Video Transport Core Maintenance avt@ietf.org > > https://www.ietf.org/mailman/listinfo/avt > > > > > -- > > Magnus Westerlund > > ---------------------------------------------------------------------- > Multimedia Technologies, Ericsson Research EAB/TVM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > F=E4r=F6gatan 6 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com > ---------------------------------------------------------------------- > > _______________________________________________ > Audio/Video Transport Core Maintenance > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt > --089e01175f6db7426a04daf42cd0 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Discussion is in progress -=A0http://www.ietf.org/mail-arc= hive/web/avt/current/msg15817.html

So far we a= re=A0considering=A0one minor technical change in how future SDP is specifie= d.

If Magnus agrees that using RFC 5939 is app= ropriate for negotiating these parameters we may decide to add a note to th= at effect.

Kev= in Gross
+1-303-447-0517
Media Network Consultant
AVA Network= s -=A0www.AVAnw.com= ,=A0www.X192.org


On Mon, Apr 22, 2013 at 8:21 AM, Roni Ev= en <ron.even.tlv@gmail.com> wrote:
Hi Magnus,
Your comments should be discussed and if they will require changes, we will=
most probably need a second WGLC.
I hope that we can get more reviews and progress this document faster. It will block IDMS that went to publication.
Roni Even
AVTCore co-chair

-----Original Message-----
From: Magnus Westerlund [mailto:magnus.westerlund@ericsson.com]
Sent: 22 April, 2013 9:59 AM
To: Roni Even
Cc: avt@ietf.org; draft-ietf-avtcore-clksrc@tools.ietf= .org
Subject: Re: [AVTCORE] WGLC on draft-ietf-avtcore-clksrc-03

Hi,

I want my previous submitted comments on -03 to apply. Based on that I thin= k
the WG last call is a bit pre-mature. It would have been better to have a solid proposals for the signalling issues on this draft prior to running th= e
last call.

Anyway until the negotiation signalling issues are resolved I think there i= s
publication blocking issues on this draft.

Cheers

Magnus

On 2013-04-21 08:39, Roni Even wrote:
> Hi,
>
> I would like to start a WGLC on
http://tools.ietf.org/html/draft-ietf-avtcore-clksrc-03 =A0= , RTP Clock Source
Signalling.
>
>
>
> The WGLC will end on May 12^th , 2013
>
>
>
> Please review the draft and send comments to the list.
>
>
>
> For the draft authors; =A0Are you aware of any IPR that applies to
draft-ietf-avtcore-clksrc-03?
>
> =A0If so, has this IPR been disclosed in compliance with IETF IPR rule= s (see
RFCs 3979, 4879, 3669 and 5378 for more details)?
>
> The above question is needed for the document write-up when sent to publication.
>
>
>
> Thanks
>
>
>
> Roni Even
>
> AVTcore =A0co-chair
>
>
>
>
>
>
>
> _______________________________________________
> Audio/Video Transport Core Maintenance avt@ietf.org
> https://www.ietf.org/mailman/listinfo/avt
>


--

Magnus Westerlund

----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| Phone =A0+46 10 7148287
F=E4r=F6gatan 6 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0| Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com
----------------------------------------------------------------------

_______________________________________________
Audio/Video Transport Core Maintenance
avt@ietf.org
htt= ps://www.ietf.org/mailman/listinfo/avt

--089e01175f6db7426a04daf42cd0-- From internet-drafts@ietf.org Mon Apr 22 21:17:38 2013 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id CB61E21E80DD; Mon, 22 Apr 2013 21:17:38 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.519 X-Spam-Level: X-Spam-Status: No, score=-102.519 tagged_above=-999 required=5 tests=[AWL=0.081, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ozabcFhz0-4A; Mon, 22 Apr 2013 21:17:35 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 2EE7521E80CD; Mon, 22 Apr 2013 21:17:15 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.44.p4 Message-ID: <20130423041715.4903.24642.idtracker@ietfa.amsl.com> Date: Mon, 22 Apr 2013 21:17:15 -0700 Cc: avt@ietf.org Subject: [AVTCORE] I-D Action: draft-ietf-avtcore-rtp-multi-stream-00.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Apr 2013 04:17:39 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Audio/Video Transport Core Maintenance Wo= rking Group of the IETF. Title : RTP Considerations for Endpoints Sending Multiple Media = Streams Author(s) : Jonathan Lennox Magnus Westerlund Qin Wu Colin Perkins Filename : draft-ietf-avtcore-rtp-multi-stream-00.txt Pages : 17 Date : 2013-04-22 Abstract: This document expands and clarifies the behavior of the Real-Time Transport Protocol (RTP) endpoints when they are sending multiple media streams in a single RTP session. In particular, issues involving Real-Time Transport Control Protocol (RTCP) messages are described. This document updates RFC 3550 in regards to handling of multiple SSRCs per endpoint in RTP sessions. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-avtcore-rtp-multi-stream There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-avtcore-rtp-multi-stream-00 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From magnus.westerlund@ericsson.com Tue Apr 23 00:23:16 2013 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 055A621F95DB for ; Tue, 23 Apr 2013 00:23:16 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -105.662 X-Spam-Level: X-Spam-Status: No, score=-105.662 tagged_above=-999 required=5 tests=[AWL=-0.369, BAYES_00=-2.599, HELO_EQ_SE=0.35, J_CHICKENPOX_16=0.6, RCVD_IN_DNSWL_MED=-4, SARE_SUB_6CONS_WORD=0.356, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id v3XP-0cascyu for ; Tue, 23 Apr 2013 00:23:14 -0700 (PDT) Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 3B5E121F94DF for ; Tue, 23 Apr 2013 00:23:14 -0700 (PDT) X-AuditID: c1b4fb25-b7f366d000004d10-07-517636e19d59 Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id FA.09.19728.1E636715; Tue, 23 Apr 2013 09:23:13 +0200 (CEST) Received: from [127.0.0.1] (153.88.115.8) by esessmw0191.eemea.ericsson.se (153.88.115.85) with Microsoft SMTP Server id 8.3.279.1; Tue, 23 Apr 2013 09:23:12 +0200 Message-ID: <517636E0.2020607@ericsson.com> Date: Tue, 23 Apr 2013 09:23:12 +0200 From: Magnus Westerlund User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130328 Thunderbird/17.0.5 MIME-Version: 1.0 To: Kevin Gross References: <5163DF09.7050606@ericsson.com> In-Reply-To: X-Enigmail-Version: 1.5.1 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 8bit X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFupnluLIzCtJLcpLzFFi42KZGfG3VvehWVmgwfF/IhYve1ayW7w41M7m wOTx7+p2Zo8lS34yBTBFcdmkpOZklqUW6dslcGV8uWdc0Odd0bqggbmB8aZ5FyMnh4SAicSu 3TvZIGwxiQv31gPZXBxCAqcYJU7PXwDlLGeU+Df/ClgVr4C2xJ2b69hBbBYBVYlLOw8zgths AhYSN380AtVwcIgKBEtsbY2BKBeUODnzCQuILSKgLvFo10MmEJtZQEli7tLXzCC2sIC9xNvL B8FqhAQKJJ5NOwsW5xQIlOj78ZUV4jhJiS0v2tkhevUkplxtYYSw5SWat85mhujVlmho6mCd wCg0C8nqWUhaZiFpWcDIvIqRPTcxMye93GgTIzBQD275rbqD8c45kUOM0hwsSuK84a4XAoQE 0hNLUrNTUwtSi+KLSnNSiw8xMnFwSjUwrmN137XuQ0hHOvPyRVOs+Nk3r0m65ZsiUfyPMyl6 +6ftx6712Dx/6hx6c55HjjFDIWPnQhUhuyoFsRa/gDbO+meFh5h5zvTb29nb/rpSVH/0UelE kciA7Z4Sy+dWXbLgP2h9btEHtStO2460PTLhWqS/+t+Hc91G3345bluXMOH406YHmW+nK7EU ZyQaajEXFScCAH5qK7IiAgAA Cc: IETF AVTCore WG Subject: Re: [AVTCORE] Comments on draft-ietf-avtcore-clksrc-03 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Apr 2013 07:23:16 -0000 On 2013-04-18 00:41, Kevin Gross wrote: > Magnus, > > Thanks for looking at this and sorry for the delay responding. > > I agree that mediaclk-ext is too restrictive. Your suggestion is > very accommodating Something a bit more structured such as 'token "=" > byte-string' might be more appropriate. I will check with my co authors > on this. Sure. > > As there is great precedent for it in SDP, we have implemented a simple > offer-answer model. I would propose that systems should use the > mechanisms defined in RFC 5939 if negotiation of clock configurations is > necessary. Perhaps adding some discussion and a reference to this RFC > would help. Yes, there are precedence for simple models. However, I think yours are over simplified and has unclear goals. Can you please comment on which of the goals I discuss below that you see needs to be meet? I think a purely declarative model would be better than what you have now, that would at least allow the answer to say, I use X when X is different from what is in the offer. When it comes to CAPNEG that is clearly a possible road, but likely will result that almost no one can actually determine your capability for clock sources. Instead they will be stuck with the your current proposal. I think even going to the model that the answer picks one for both out of the offerers capabilities would be better. That would at least enable the highest likelihood that both would use the same clocks. > > I don't think that independently negotiating reference and media clocks > as you have suggested will be adequate. Under some implementations, > while multiple clocks are supported, certain combinations of media and > reference clocks may not be allowed. Okay, that is an additional requirement. Which, might not even work well with CAPNEG. You will have two independent attributes that actually have dependencies. What you say, you appear to indicate that from each side you can have restrictions like this: This media-ref clock can only be used given that your wall clock source is either of these. Cheers Magnus > > Kevin Gross > +1-303-447-0517 > Media Network Consultant > AVA Networks - www.AVAnw.com , www.X192.org > > > > On Tue, Apr 9, 2013 at 3:27 AM, Magnus Westerlund > > > wrote: > > Hi, > > I promised doing an review of the O/A section. I also found some other > issues to consider. > > 1. Section 5.4: > > Figure 5 shows the ABNF [5] grammar for the SDP media clock source > information. > > mediaclk-master = "a=ssrc:" integer SP clk-master-id > > clk-master-id = "mediaclk:master-id=" master-id > > timestamp-mediaclk = "a=mediaclk:" mediaclock > > mediaclock = sender / refclk / streamid / mediaclock-ext > > sender = "sender" sender-ext > > sender-ext = token > > refclk = "direct" [ "=" 1*DIGIT ] [rate] [direct-ext] > > rate = [ SP "rate=" integer "/" integer ] > > direct-ext = token > > streamid = "master-id=" master-id > streamid =/ "IEEE1722=" avb-stream-id > streamid =/ streamid-ext > > master-id = EUI48 > avb-stream-id = EUI64 > > EUI48 = 5(2HEXDIG ":") 2HEXDIG > EUI64 = 7(2HEXDIG ":") 2HEXDIG > > streamid-ext = token > > mediaclock-ext = token > > I wonder if not the mediaclock-ext construction is to restrictive. As > the refclk produces a sting with white-spaces in it, why isn't other > mediaclock-ext allowed the same freedom? I think the mediaclock-ext can > be basically byte-string, i.e. any character allowed on an SDP line > should be possible to use. Likely the only resteriction should be that > it starts with a token. Thus using: > > mediaclock-ext = token [SP byte-string] > > This would require a token for identifying the method followed by a > space and then full freedom for anything that is allowed on an SDP > attribute value. > > > 2. Section 6: > > Purpose of signalling? > > I think this type of signalling can select two levels of goals with > signalling: > > 1) Declaring what each SDP O/A uses on its side > > 2) Negotiating to arrive at the best but available mechanism on both > sides. > > The currently proposed solution does neither of these. It enables the > offerer to express to declare I intended to use X and for the answer to > say I know that, or simply say I can't tell you because we are not > having the same clocks. > > I think we need to be clear what our goals are here. And I will propose > some goals with the signalling based on my understanding of how these > defined timestamp reference clocks and media stream clocks can be used. > And we do need to be aware that different application may have different > needs. > > Goal with signalling: > > 1. Enable each media sender to declare its actually used ts-refclk, i.e. > what clock is base for the RTCP SR NTP timestamps > 2. Enable each media sender to identify what clock reference is used to > check/drive the media sampling, i.e. RTP timestamp advancement. > 3. Enable two media sender using SDP O/A to determine what common clocks > they actually have so they can be used in either of ts-refclk or > mediaclk. > > The purpose of doing three (3) is really so that one can do the > following. > A. has three ts-refclk it can use. B has two ts-refclk available. They > are going to watch social TV. To make it at all possible for the social > TV service to play out content at A and B in sync they need to have > either of these two things be available. > > a) Each has a common clock with the TV service > b) A and B has a common clock > > In either of the scenario the TV service will be able to ensure that the > media is played out is sync. > > > As a technical solution to these issues there are two main solution > tracks: > > 1) Change the respective SDP attributes to provide info on all possible > clocks for that it could be using and let the answer select the most > preferred that both are supporting > > 2) Leave the current SDP attributes as they are and only use them for > declaration that: I use this! Then add new SDP attributes to negotiate > the list of commonly supported clocks. > > At this stage I think 2) is what is simplest and require the least > changes to what already exist. > > I will note that this is likely to require a second round of O/A > messages to update used clocks if the arrived common clock(s) are not > the default used ones. But, I don't see a way around these. In SIP one > could use OPTIONS to provide a SDP which includes the negotiation > attribute to enable the other side to select using a clock that is > supported by both. But when that isn't done, it will take two rounds or > other a'priori knowledge. > > So my proposal is simply that one create two new SDP attributes one for > each type of clock usage (ts-refclk and mediaclk) and include a list of > clock type and any ID of the clock in a priority order. The O/A is basic > negotiated and the answer removes all clocks it doesn't support and adds > all it supports. Hopefully there is someone in the list that is common. > The highest priority between the two parties should be used when common > clock is required. IF that is not, then these attributes should not be > included. This for example allows one to use a common ts-refclk, but not > require common mediaclk. We should also discuss if the answerer may > change the priority of commonly supported, and if it should or should > not add additional clocks it supports that are not common. > > I really appreciate feedback on these comments and ideas. > > Cheers > > Magnus Westerlund > > ---------------------------------------------------------------------- > Multimedia Technologies, Ericsson Research EAB/TVM > ---------------------------------------------------------------------- > Ericsson AB | Phone +46 10 7148287 > Färögatan 6 | Mobile +46 73 0949079 > SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com > > ---------------------------------------------------------------------- > > _______________________________________________ > Audio/Video Transport Core Maintenance > avt@ietf.org > https://www.ietf.org/mailman/listinfo/avt > > -- Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 Färögatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- From internet-drafts@ietf.org Tue Apr 23 06:28:46 2013 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 25B4F21F96CC; Tue, 23 Apr 2013 06:28:46 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -102.512 X-Spam-Level: X-Spam-Status: No, score=-102.512 tagged_above=-999 required=5 tests=[AWL=0.088, BAYES_00=-2.599, NO_RELAYS=-0.001, USER_IN_WHITELIST=-100] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id h4W1lcpe942N; Tue, 23 Apr 2013 06:28:45 -0700 (PDT) Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id 6466F21F96C4; Tue, 23 Apr 2013 06:28:45 -0700 (PDT) MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable From: internet-drafts@ietf.org To: i-d-announce@ietf.org X-Test-IDTracker: no X-IETF-IDTracker: 4.44.p4 Message-ID: <20130423132845.832.53701.idtracker@ietfa.amsl.com> Date: Tue, 23 Apr 2013 06:28:45 -0700 Cc: avt@ietf.org Subject: [AVTCORE] I-D Action: draft-ietf-avtcore-6222bis-03.txt X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 23 Apr 2013 13:28:46 -0000 A New Internet-Draft is available from the on-line Internet-Drafts director= ies. This draft is a work item of the Audio/Video Transport Core Maintenance Wo= rking Group of the IETF. Title : Guidelines for Choosing RTP Control Protocol (RTCP) Cano= nical Names (CNAMEs) Author(s) : Ali Begen Colin Perkins Dan Wing Eric Rescorla Filename : draft-ietf-avtcore-6222bis-03.txt Pages : 10 Date : 2013-04-23 Abstract: The RTP Control Protocol (RTCP) Canonical Name (CNAME) is a persistent transport-level identifier for an RTP endpoint. While the Synchronization Source (SSRC) identifier of an RTP endpoint may change if a collision is detected or when the RTP application is restarted, its RTCP CNAME is meant to stay unchanged, so that RTP endpoints can be uniquely identified and associated with their RTP media streams. For proper functionality, RTCP CNAMEs should be unique within the participants of an RTP session. However, the existing guidelines for choosing the RTCP CNAME provided in the RTP standard are insufficient to achieve this uniqueness. RFC 6222 was published to update those guidelines to allow endpoints to choose unique RTCP CNAMEs. Unfortunately, later investigations showed that some parts of the new algorithms were unnecessarily complicated and/or ineffective. This document addresses these concerns and replaces RFC 6222. The IETF datatracker status page for this draft is: https://datatracker.ietf.org/doc/draft-ietf-avtcore-6222bis There's also a htmlized version available at: http://tools.ietf.org/html/draft-ietf-avtcore-6222bis-03 A diff from the previous version is available at: http://www.ietf.org/rfcdiff?url2=3Ddraft-ietf-avtcore-6222bis-03 Internet-Drafts are also available by anonymous FTP at: ftp://ftp.ietf.org/internet-drafts/ From ron.even.tlv@gmail.com Wed Apr 24 07:01:52 2013 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F0B1821F8D79 for ; Wed, 24 Apr 2013 07:01:51 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -0.389 X-Spam-Level: X-Spam-Status: No, score=-0.389 tagged_above=-999 required=5 tests=[AWL=1.253, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_CHICKENPOX_16=0.6, SARE_SUB_6CONS_WORD=0.356] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id ljYMEmGxMpvC for ; Wed, 24 Apr 2013 07:01:47 -0700 (PDT) Received: from mail-we0-x22b.google.com (mail-we0-x22b.google.com [IPv6:2a00:1450:400c:c03::22b]) by ietfa.amsl.com (Postfix) with ESMTP id 9A50321F869A for ; Wed, 24 Apr 2013 07:01:46 -0700 (PDT) Received: by mail-we0-f171.google.com with SMTP id i48so1623188wef.2 for ; Wed, 24 Apr 2013 07:01:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=x-received:from:to:cc:references:in-reply-to:subject:date :message-id:mime-version:content-type:x-mailer:thread-index :content-language; bh=1wDMAnqwissK6ihz/AG3a58wGbyRJH0vIE9BTHz+Tck=; b=POia8ybvhSM2U0bMH4kLllSKA8w2jUi3PoinugJC633Z7rirZU+rsr9ovD04QfWxQy vLcgmhFppAm615fra0myN4b+5h6fj2cWFEqiZXKDnyVYpGMjzuaaypOtWOjGkkluoRos eFkY0nJT0BqS4AYBqeLgyMWr0ssFch0x9ZC3OVbnAz6B5vfViWmC7acZSVT4VfVMws5U Hv8stV7B9PJjx+rf8dj743l8Zb+4BfQRDhKdInIJ+sbKglHXSZAs9YsC/FxfJrE7q0wa +N9gym3FclKnFf7dLfH/8a0N0aMjsA8dOPxBKM3h2Q70+Up28A7asQuwO427Jld/+UDb PnzA== X-Received: by 10.180.21.193 with SMTP id x1mr44982820wie.31.1366812105278; Wed, 24 Apr 2013 07:01:45 -0700 (PDT) Received: from RoniE (bzq-79-181-177-28.red.bezeqint.net. [79.181.177.28]) by mx.google.com with ESMTPSA id fz3sm4461892wib.0.2013.04.24.07.01.41 for (version=TLSv1 cipher=RC4-SHA bits=128/128); Wed, 24 Apr 2013 07:01:44 -0700 (PDT) From: "Roni Even" To: "'Kevin Gross'" , "'Magnus Westerlund'" References: <5163DF09.7050606@ericsson.com> In-Reply-To: Date: Wed, 24 Apr 2013 17:01:09 +0300 Message-ID: <02d601ce40f4$2e765d30$8b631790$@gmail.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_NextPart_000_02D7_01CE410D.53C5B810" X-Mailer: Microsoft Outlook 14.0 Thread-Index: AQJ5HC9wvVjoQVUfIZENIsmmA9Bo8wEz1q+Hl4YJg/A= Content-Language: en-us Cc: 'IETF AVTCore WG' Subject: Re: [AVTCORE] Comments on draft-ietf-avtcore-clksrc-03 X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Apr 2013 14:01:52 -0000 This is a multipart message in MIME format. ------=_NextPart_000_02D7_01CE410D.53C5B810 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable Hi Kevin, I looked at the document and at Magnus comment. =20 I am not sure if the document allows offering and two reference clocks. = I am not sure what is meant in section 4.2=20 =93Two or more NTP servers may be listed at the same level in the = session description to indicate that they are interchangeable. RTP senders or receivers can use any of the listed NTP servers to govern a local clock = that is equivalent to a local clock slaved to a different server.=94=20 When you say interchangeable and how it relates to Magnus proposal to = allow negotiation. =20 I also assume that the information in offer/answer and in declarative = SDP is used to provide sender information and not receiver one so is there a = reason to have the same media clock in both direction when using conversional (offer/answer) application =20 =20 Other comments =20 1. ptp-domain-name =3D "domain-name=3D" 16ptp-domain-char =96 did = you mean exactly 16 charaters? 2. In figure 2 a=3Dts-refclk:ntp=3Dtraceable =96 do you need also = to specify the server address? 3. In figure 3 a=3Dts-refclk:ntp=3D203.0.113.10 2011-02-19 21:03:20.345+01:00 =96 what is the last part with the date and time, I = thought the syntax only have server address. 4. In section 6.1 the first sentence in the first and second = paragraph it look to me like the =93must=94 is really a =93SHOULD=94 5. In section 8 when defining a new registry you need to say what = is the policy for adding values to the registry (I think here it will be specification required=94 see RFC 5226=20 6. The IANA section is not fully compliant with the requirements = from RFC4566 you can look at examples in http://tools.ietf.org/html/draft-ietf-mmusic-sdp-capability-negotiation-1= 3 IANA section or other MMUSIC RFCs =20 Roni Even =20 =20 =20 From: avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of = Kevin Gross Sent: 18 April, 2013 1:41 AM To: Magnus Westerlund Cc: IETF AVTCore WG Subject: Re: [AVTCORE] Comments on draft-ietf-avtcore-clksrc-03 =20 Magnus, =20 Thanks for looking at this and sorry for the delay responding. =20 I agree that mediaclk-ext is too restrictive. Your suggestion is very accommodating Something a bit more structured such as 'token "=3D" byte-string' might be more appropriate. I will check with my co authors = on this. =20 As there is great precedent for it in SDP, we have implemented a simple offer-answer model. I would propose that systems should use the = mechanisms defined in RFC 5939 if negotiation of clock configurations is necessary. Perhaps adding some discussion and a reference to this RFC would help. =20 I don't think that independently negotiating reference and media clocks = as you have suggested will be adequate. Under some implementations, while multiple clocks are supported, certain combinations of media and = reference clocks may not be allowed. Kevin Gross +1-303-447-0517 Media Network Consultant AVA Networks - www.AVAnw.com , www.X192.org =20 On Tue, Apr 9, 2013 at 3:27 AM, Magnus Westerlund wrote: Hi, I promised doing an review of the O/A section. I also found some other issues to consider. 1. Section 5.4: Figure 5 shows the ABNF [5] grammar for the SDP media clock source information. mediaclk-master =3D "a=3Dssrc:" integer SP clk-master-id clk-master-id =3D "mediaclk:master-id=3D" master-id timestamp-mediaclk =3D "a=3Dmediaclk:" mediaclock mediaclock =3D sender / refclk / streamid / mediaclock-ext sender =3D "sender" sender-ext sender-ext =3D token refclk =3D "direct" [ "=3D" 1*DIGIT ] [rate] [direct-ext] rate =3D [ SP "rate=3D" integer "/" integer ] direct-ext =3D token streamid =3D "master-id=3D" master-id streamid =3D/ "IEEE1722=3D" avb-stream-id streamid =3D/ streamid-ext master-id =3D EUI48 avb-stream-id =3D EUI64 EUI48 =3D 5(2HEXDIG ":") 2HEXDIG EUI64 =3D 7(2HEXDIG ":") 2HEXDIG streamid-ext =3D token mediaclock-ext =3D token I wonder if not the mediaclock-ext construction is to restrictive. As the refclk produces a sting with white-spaces in it, why isn't other mediaclock-ext allowed the same freedom? I think the mediaclock-ext can be basically byte-string, i.e. any character allowed on an SDP line should be possible to use. Likely the only resteriction should be that it starts with a token. Thus using: mediaclock-ext =3D token [SP byte-string] This would require a token for identifying the method followed by a space and then full freedom for anything that is allowed on an SDP attribute value. 2. Section 6: Purpose of signalling? I think this type of signalling can select two levels of goals with signalling: 1) Declaring what each SDP O/A uses on its side 2) Negotiating to arrive at the best but available mechanism on both = sides. The currently proposed solution does neither of these. It enables the offerer to express to declare I intended to use X and for the answer to say I know that, or simply say I can't tell you because we are not having the same clocks. I think we need to be clear what our goals are here. And I will propose some goals with the signalling based on my understanding of how these defined timestamp reference clocks and media stream clocks can be used. And we do need to be aware that different application may have different needs. Goal with signalling: 1. Enable each media sender to declare its actually used ts-refclk, i.e. what clock is base for the RTCP SR NTP timestamps 2. Enable each media sender to identify what clock reference is used to check/drive the media sampling, i.e. RTP timestamp advancement. 3. Enable two media sender using SDP O/A to determine what common clocks they actually have so they can be used in either of ts-refclk or = mediaclk. The purpose of doing three (3) is really so that one can do the = following. A. has three ts-refclk it can use. B has two ts-refclk available. They are going to watch social TV. To make it at all possible for the social TV service to play out content at A and B in sync they need to have either of these two things be available. a) Each has a common clock with the TV service b) A and B has a common clock In either of the scenario the TV service will be able to ensure that the media is played out is sync. As a technical solution to these issues there are two main solution = tracks: 1) Change the respective SDP attributes to provide info on all possible clocks for that it could be using and let the answer select the most preferred that both are supporting 2) Leave the current SDP attributes as they are and only use them for declaration that: I use this! Then add new SDP attributes to negotiate the list of commonly supported clocks. At this stage I think 2) is what is simplest and require the least changes to what already exist. I will note that this is likely to require a second round of O/A messages to update used clocks if the arrived common clock(s) are not the default used ones. But, I don't see a way around these. In SIP one could use OPTIONS to provide a SDP which includes the negotiation attribute to enable the other side to select using a clock that is supported by both. But when that isn't done, it will take two rounds or other a'priori knowledge. So my proposal is simply that one create two new SDP attributes one for each type of clock usage (ts-refclk and mediaclk) and include a list of clock type and any ID of the clock in a priority order. The O/A is basic negotiated and the answer removes all clocks it doesn't support and adds all it supports. Hopefully there is someone in the list that is common. The highest priority between the two parties should be used when common clock is required. IF that is not, then these attributes should not be included. This for example allows one to use a common ts-refclk, but not require common mediaclk. We should also discuss if the answerer may change the priority of commonly supported, and if it should or should not add additional clocks it supports that are not common. I really appreciate feedback on these comments and ideas. Cheers Magnus Westerlund ---------------------------------------------------------------------- Multimedia Technologies, Ericsson Research EAB/TVM ---------------------------------------------------------------------- Ericsson AB | Phone +46 10 7148287 F=E4r=F6gatan 6 | Mobile +46 73 0949079 SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson.com ---------------------------------------------------------------------- _______________________________________________ Audio/Video Transport Core Maintenance avt@ietf.org https://www.ietf.org/mailman/listinfo/avt =20 _____ =20 ------=_NextPart_000_02D7_01CE410D.53C5B810 Content-Type: text/html; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable

Hi Kevin,

I looked at the document and at Magnus = comment.

 

I am not sure if the document allows offering and two reference = clocks. I am not sure what is meant in section 4.2 =

“Two or = more NTP servers may be listed at the same level in the session = description to indicate that they are interchangeable.=A0 RTP=A0 senders = or receivers can use any of the listed NTP servers to govern a local = clock that is equivalent to a local clock slaved to a different = server.”

When you = say interchangeable and how it relates to Magnus proposal to allow = negotiation.

 =

I also = assume that the information in offer/answer and in declarative SDP is = used to provide sender information and not receiver one so is there a = reason to have the same media clock in both direction when using = conversional (offer/answer) application

 =

 =

Other = comments

 =

1.       = ptp-domain-= name =3D=A0 "domain-name=3D" 16ptp-domain-char – did you = mean exactly 16 charaters?=

2.       = In figure = 2 a=3Dts-refclk:ntp=3Dtraceable – = do you need also to specify the server address?

3.       = In figure = 3 a=3Dts-refclk:ntp=3D203.0.113.10 2011-02-19 21:03:20.345+01:00 – = what is the last part with the date and time, I thought the syntax only = have server address.=

4.       = In section = 6.1 the first sentence in the first and second paragraph it look to me = like the “must” is really a “SHOULD”=

5.       = In section = 8 when defining a new registry you need to say what is the policy for = adding values to the registry (I think here it will be specification = required” see RFC 5226 =

6.       = The IANA = section is not fully compliant with the requirements from RFC4566 you = can look at examples in http://tools.ietf.org/html/draft-ietf-mmusic-sdp-capability-ne= gotiation-13 IANA section or other MMUSIC = RFCs

 =

Roni = Even

 =

 

 

From:= = avt-bounces@ietf.org [mailto:avt-bounces@ietf.org] On Behalf Of = Kevin Gross
Sent: 18 April, 2013 1:41 AM
To: = Magnus Westerlund
Cc: IETF AVTCore WG
Subject: Re: = [AVTCORE] Comments on = draft-ietf-avtcore-clksrc-03

 

Magnus,

 

Thanks for looking at this and sorry for the delay = responding.

 

I = agree that mediaclk-ext is too restrictive. Your suggestion is = very accommodating  Something a bit more structured such as = 'token "=3D" byte-string' might be more appropriate. I = will check with my co authors on = this.

 

As there is great precedent for it in SDP, we = have implemented a simple offer-answer model. I would propose that = systems should use the mechanisms defined in RFC 5939 if negotiation of = clock configurations is necessary. Perhaps adding some discussion and = a reference to this RFC would = help.

 

I = don't think that independently negotiating reference and media = clocks as you have suggested will be adequate. Under some = implementations, while multiple clocks are supported, certain = combinations of media and reference clocks may not be = allowed.


Kevin = Gross

+1-303-447-0517

Media Network Consultant

AVA Networks - www.AVAnw.com, www.X192.org

 

On Tue, Apr 9, 2013 at 3:27 AM, Magnus Westerlund = <magnus.westerlund@ericsson.com> = wrote:

Hi,

I promised doing an = review of the O/A section. I also found some other
issues to = consider.

1. Section 5.4:

Figure 5 shows the ABNF [5] = grammar for the SDP media clock source
  =  information.

          = mediaclk-master =3D "a=3Dssrc:" integer SP = clk-master-id

          clk-master-id = =3D "mediaclk:master-id=3D" master-id

    =       timestamp-mediaclk =3D "a=3Dmediaclk:" = mediaclock

          mediaclock =3D = sender / refclk / streamid / mediaclock-ext

      =     sender =3D "sender" sender-ext

  =         sender-ext =3D token

    =       refclk =3D "direct" [ "=3D" = 1*DIGIT ] [rate] [direct-ext]

          = rate =3D [ SP "rate=3D" integer "/" integer = ]

          direct-ext =3D = token

          streamid =3D = "master-id=3D" master-id
          = streamid =3D/ "IEEE1722=3D" avb-stream-id
    =       streamid =3D/ streamid-ext

    =       master-id =3D EUI48
        =   avb-stream-id =3D EUI64

          = EUI48 =3D 5(2HEXDIG ":") 2HEXDIG
      =     EUI64 =3D 7(2HEXDIG ":") 2HEXDIG

  =         streamid-ext =3D token

    =       mediaclock-ext =3D token

I wonder if not the = mediaclock-ext construction is to restrictive. As
the refclk produces = a sting with white-spaces in it, why isn't other
mediaclock-ext = allowed the same freedom? I think the mediaclock-ext can
be basically = byte-string, i.e. any character allowed on an SDP line
should be = possible to use. Likely the only resteriction should be that
it = starts with a token. Thus using:

mediaclock-ext =3D token [SP = byte-string]

This would require a token for identifying the = method followed by a
space and then full freedom for anything that is = allowed on an SDP
attribute value.


2. Section = 6:

Purpose of signalling?

I think this type of signalling = can select two levels of goals with
signalling:

1) Declaring = what each SDP O/A uses on its side

2) Negotiating to arrive at = the best but available mechanism on both sides.

The currently = proposed solution does neither of these. It enables the
offerer to = express to declare I intended to use X and for the answer to
say I = know that, or simply say I can't tell you because we are not
having = the same clocks.

I think we need to be clear what our goals are = here. And I will propose
some goals with the signalling based on my = understanding of how these
defined timestamp reference clocks and = media stream clocks can be used.
And we do need to be aware that = different application may have different
needs.

Goal with = signalling:

1. Enable each media sender to declare its actually = used ts-refclk, i.e.
what clock is base for the RTCP SR NTP = timestamps
2. Enable each media sender to identify what clock = reference is used to
check/drive the media sampling, i.e. RTP = timestamp advancement.
3. Enable two media sender using SDP O/A to = determine what common clocks
they actually have so they can be used = in either of ts-refclk or mediaclk.

The purpose of doing three = (3) is really so that one can do the following.
A. has three = ts-refclk  it can use. B has two ts-refclk available. They
are = going to watch social TV. To make it at all possible for the = social
TV service to play out content at A and B in sync they need to = have
either of these two things be available.

a) Each has a = common clock with the TV service
b) A and B has a common = clock

In either of the scenario the TV service will be able to = ensure that the
media is played out is sync.


As a = technical solution to these issues there are two main solution = tracks:

1) Change the respective SDP attributes to provide info = on all possible
clocks for that it could be using and let the answer = select the most
preferred that both are supporting

2) Leave = the current SDP attributes as they are and only use them = for
declaration that: I use this! Then add new SDP attributes to = negotiate
the list of commonly supported clocks.

At this stage = I think 2) is what is simplest and require the least
changes to what = already exist.

I will note that this is likely to require a = second round of O/A
messages to update used clocks if the arrived = common clock(s) are not
the default used ones. But, I don't see a way = around these. In SIP one
could use OPTIONS to provide a SDP which = includes the negotiation
attribute to enable the other side to select = using a clock that is
supported by both. But when that isn't done, it = will take two rounds or
other a'priori knowledge.

So my = proposal is simply that one create two new SDP attributes one = for
each type of clock usage (ts-refclk and mediaclk) and include a = list of
clock type and any ID of the clock in a priority order. The = O/A is basic
negotiated and the answer removes all clocks it doesn't = support and adds
all it supports. Hopefully there is someone in the = list that is common.
The highest priority between the two parties = should be used when common
clock is required. IF that is not, then = these attributes should not be
included. This for example allows one = to use a common ts-refclk, but not
require common mediaclk. We should = also discuss if the answerer may
change the priority of commonly = supported, and if it should or should
not add additional clocks it = supports that are not common.

I really appreciate feedback on = these comments and ideas.

Cheers

Magnus = Westerlund

-------------------------------------------------------= ---------------
Multimedia Technologies, Ericsson Research = EAB/TVM
--------------------------------------------------------------= --------
Ericsson AB               =  | Phone  +46 10 7148287
F=E4r=F6gatan 6     =            | Mobile +46 73 = 0949079
SE-164 80 Stockholm, Sweden| mailto: magnus.westerlund@ericsson= .com
-------------------------------------------------------------= ---------

_______________________________________________
Audio= /Video Transport Core Maintenance
avt@ietf.org
https://www.ietf.org/mailman/listinfo/avt

 

------=_NextPart_000_02D7_01CE410D.53C5B810-- From johnsonhammond2@hushmail.com Sat Apr 27 18:20:19 2013 Return-Path: X-Original-To: avt@ietfa.amsl.com Delivered-To: avt@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 7F93921F983B for ; Sat, 27 Apr 2013 18:20:19 -0700 (PDT) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -2.485 X-Spam-Level: X-Spam-Status: No, score=-2.485 tagged_above=-999 required=5 tests=[AWL=0.114, BAYES_00=-2.599] Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id kC+mkY5WU0ah for ; Sat, 27 Apr 2013 18:20:19 -0700 (PDT) Received: from smtp10.hushmail.com (smtp10a.hushmail.com [65.39.178.239]) by ietfa.amsl.com (Postfix) with ESMTP id 445A321F97BF for ; Sat, 27 Apr 2013 18:20:19 -0700 (PDT) Received: from smtp10.hushmail.com (smtp10a.hushmail.com [65.39.178.239]) by smtp10.hushmail.com (Postfix) with SMTP id C4F971B5313 for ; Sat, 27 Apr 2013 17:15:16 +0000 (UTC) X-hush-relay-time: 211 X-hush-relay-id: b1bd903faba185ee07e5a0ed3a1fde37 Received: from smtp.hushmail.com (w8.hushmail.com [65.39.178.52]) by smtp10.hushmail.com (Postfix) with ESMTP for ; Sat, 27 Apr 2013 17:15:16 +0000 (UTC) Received: by smtp.hushmail.com (Postfix, from userid 99) id 80DFB14DBD4; Sat, 27 Apr 2013 17:15:16 +0000 (UTC) MIME-Version: 1.0 Date: Sat, 27 Apr 2013 13:15:16 -0400 To: avt@ietf.org From: johnsonhammond2@hushmail.com Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset="UTF-8" Message-Id: <20130427171516.80DFB14DBD4@smtp.hushmail.com> Subject: [AVTCORE] Biggest Fake Conference in Computer Science X-BeenThere: avt@ietf.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Audio/Video Transport Core Maintenance List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Apr 2013 01:20:19 -0000 Biggest Fake Conference in Computer Science We are researchers from different parts of the world and conducted a study on the world’s biggest bogus computer science conference WORLDCOMP ( http://sites.google.com/site/worlddump1 ) organized by Prof. Hamid Arabnia from University of Georgia, USA. We submitted a fake paper to WORLDCOMP 2011 and again (the same paper with a modified title) to WORLDCOMP 2012. This paper had numerous fundamental mistakes. Sample statements from that paper include: (1). Binary logic is fuzzy logic and vice versa (2). Pascal developed fuzzy logic (3). Object oriented languages do not exhibit any polymorphism or inheritance (4). TCP and IP are synonyms and are part of OSI model (5). Distributed systems deal with only one computer (6). Laptop is an example for a super computer (7). Operating system is an example for computer hardware Also, our paper did not express any conceptual meaning. However, it was accepted both the times without any modifications (and without any reviews) and we were invited to submit the final paper and a payment of $500+ fee to present the paper. We decided to use the fee for better purposes than making Prof. Hamid Arabnia (Chairman of WORLDCOMP) rich. After that, we received few reminders from WORLDCOMP to pay the fee but we never responded. We MUST say that you should look at the above website if you have any thoughts to submit a paper to WORLDCOMP. DBLP and other indexing agencies have stopped indexing WORLDCOMP’s proceedings since 2011 due to its fakeness. See http://www.informatik.uni-trier.de/~ley/db/conf/icai/index.html for of one of the conferences of WORLDCOMP and notice that there is no listing after 2010. See Section 2 of http://sites.google.com/site/dumpconf for comments from well-known researchers about WORLDCOMP. The status of your WORLDCOMP papers can be changed from scientific to other (i.e., junk or non-technical) at any time. Better not to have a paper than having it in WORLDCOMP and spoil the resume and peace of mind forever! Our study revealed that WORLDCOMP is a money making business, using University of Georgia mask, for Prof. Hamid Arabnia. He is throwing out a small chunk of that money (around 20 dollars per paper published in WORLDCOMP’s proceedings) to his puppet (Mr. Ashu Solo or A.M.G. Solo) who publicizes WORLDCOMP and also defends it at various forums, using fake/anonymous names. The puppet uses fake names and defames other conferences to divert traffic to WORLDCOMP. He also makes anonymous phone calls and tries to threaten the critiques of WORLDCOMP (See Item 7 of Section 5 of above website). That is, the puppet does all his best to get a maximum number of papers published at WORLDCOMP to get more money into his (and Prof. Hamid Arabnia’s) pockets. Monte Carlo Resort (the venue of WORLDCOMP for more than 10 years, until 2012) has refused to provide the venue for WORLDCOMP’13 because of the fears of their image being tarnished due to WORLDCOMP’s fraudulent activities. That is why WORLDCOMP’13 is taking place at a different resort. WORLDCOMP will not be held after 2013. The draft paper submission deadline is over but still there are no committee members, no reviewers, and there is no conference Chairman. The only contact details available on WORLDCOMP’s website is just an email address! Let us make a direct request to Prof. Hamid arabnia: publish all reviews for all the papers (after blocking identifiable details) since 2000 conference. Reveal the names and affiliations of all the reviewers (for each year) and how many papers each reviewer had reviewed on average. We also request him to look at the Open Challenge (Section 6) at https://sites.google.com/site/moneycomp1 Sorry for posting to multiple lists. Spreading the word is the only way to stop this bogus conference. Please forward this message to other mailing lists and people. We are shocked with Prof. Hamid Arabnia and his puppet’s activities http://worldcomp-fake-bogus.blogspot.com Search Google using the keyword worldcomp fake for additional links.