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--