Re: [MMUSIC] WGLC of draft-ietf-mmusic-media-loopback-18
Magnus Westerlund <magnus.westerlund@ericsson.com> Fri, 13 April 2012 12:22 UTC
Return-Path: <magnus.westerlund@ericsson.com>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id F39A921F8494 for <mmusic@ietfa.amsl.com>; Fri, 13 Apr 2012 05:22:06 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -106.192
X-Spam-Level:
X-Spam-Status: No, score=-106.192 tagged_above=-999 required=5 tests=[AWL=0.057, 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 cpb2N33PBPix for <mmusic@ietfa.amsl.com>; Fri, 13 Apr 2012 05:22:06 -0700 (PDT)
Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id D21ED21F8496 for <mmusic@ietf.org>; Fri, 13 Apr 2012 05:22:05 -0700 (PDT)
X-AuditID: c1b4fb25-b7b18ae000000dce-2d-4f881a6cb675
Received: from esessmw0247.eemea.ericsson.se (Unknown_Domain [153.88.253.125]) (using TLS with cipher AES128-SHA (AES128-SHA/128 bits)) (Client did not present a certificate) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id D8.FC.03534.C6A188F4; Fri, 13 Apr 2012 14:22:04 +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.213.0; Fri, 13 Apr 2012 14:22:04 +0200
Message-ID: <4F881A6B.7080308@ericsson.com>
Date: Fri, 13 Apr 2012 14:22:03 +0200
From: Magnus Westerlund <magnus.westerlund@ericsson.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:11.0) Gecko/20120327 Thunderbird/11.0.1
MIME-Version: 1.0
To: "Miguel A. Garcia" <Miguel.A.Garcia@ericsson.com>
References: <4F79A716.3080804@ericsson.com>
In-Reply-To: <4F79A716.3080804@ericsson.com>
X-Enigmail-Version: 1.4
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 8bit
X-Brightmail-Tracker: AAAAAA==
Cc: "draft-ietf-mmusic-media-loopback.authors@tools.ietf.org" <draft-ietf-mmusic-media-loopback.authors@tools.ietf.org>, Flemming Andreasen <fandreas@cisco.com>, mmusic <mmusic@ietf.org>
Subject: Re: [MMUSIC] WGLC of draft-ietf-mmusic-media-loopback-18
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mmusic>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 13 Apr 2012 12:22:07 -0000
Hi, I have reviewed the version in WGLC. I have some few comments: 1. Section 5.5: "Note that for any form of NAT traversal to function, symmetric RTP/RTCP MUST be used." Any reason to no reference RFC 4961 here? 2. Section 7.1.1 to 7.1.3 and 7.2.1 to 7.2.3 all are missing a space between the section number and the section title. 3. Section 6: A loopback mirror that is compliant to this specification and accepts media with rtp-pkt-loopback loopback-type MUST loopback the incoming RTP packets using either the encapsulated RTP payload format or the direct loopback RTP payload format as defined in section 7 of this specification. I don't think this has addressed my previous WG last call comment about that the MUST needs an escape clause or at least a pointer to the issue of congestion control. Because if you have no escape clause then the loopback source MUST perform congestion control not only on the path from the source to the mirror, but also on the mirror to the source. 4. Section 7.1.2: The outer RTP header of the encapsulating packet MUST be followed by the payload header defined in this section. If the received RTP packet has to be looped back in multiple encapsulating packets due to fragmentation, the encapsulating RTP header in each packet MUST be followed by the payload header defined in this section. I think this is are unfortunate formulations as it actually defines that RTP header extensions and CSRC lists are not allowed. Especially header extensions should not be disallowed. I would suggest a formulation saying: The RTP payload of the encapsulating RTP packet starts with the payload header defined in this section. And go on and define the payload structure in relation to the start of the payload. 5. Section 7.1.2: The Receive timestamp MUST be based on the same clock used by the loopback-source. I still think this formulation is extremely wrong. One alternative is the same clocks source, like if they where using the same NTP server. Or is it actually "clock rate" that is intended here? Se my previous comment 28 for more input about this: http://www.ietf.org/mail-archive/web/mmusic/current/msg08971.html 6. I can't locate any answer to my issue number 30: 30. Section 7.2.1: Sequence Number: The RTP sequence number SHOULD be generated by the loopback-mirror in the usual manner with a constant random offset. What is the acceptable cases for when to break it? I assume the intention with not saying MUST is that one can copy it from the incomming packet. Thus when source -> mirror packet losses occur causing wholes in the return path which isn't real loss on the mirror->source path. It also causes third party monitor to report losses that aren't real on this stream. Can you please summarize any discussion that has happened? 7. I also don't see any changes related to my comment 34: "34. Section 9. This section is thoroughly inadequate. The reason is that you have a forward path that is coupled to the reverse path. If the loopback is to work correctly the mirror needs to be able to send back what the source sent to it. Thus it is the loopback source that needs to adapt the media bit-rate so that both forward and reverse path can handle the flows. If doesn't the mirror will need to reduce the bit-rate it transmits and that can only happen in two ways, dropping packets or transcoding them to a lower rate fulfilling the congestion control requirement. Neither will fulfill the purpose of the loopback as I see it. This issue needs discussion, including some considerations in how to actually accomplish it with the tools we have available." This is coupled to issue 3 above. If that above MUST stands you absolutely have to have more detailed discussion about dealing with the whole loop, rather than a single leg that is the norm. 8. Section 11. The amplification or reflection this allows has at least been sufficiently discussed. I am far from certain that the mitigation is clear enough. I do support Flemming's comment about the SRTP implications of using loopback are. 9. Another not addressed issue: 41. The media type registrations "rate" parameter I think needs to be redefined. It needs to reference the rate of the payload types it intends to mirror back. 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 ----------------------------------------------------------------------
- [MMUSIC] WGLC of draft-ietf-mmusic-media-loopback… Miguel A. Garcia
- Re: [MMUSIC] WGLC of draft-ietf-mmusic-media-loop… Miguel A. Garcia
- Re: [MMUSIC] WGLC of draft-ietf-mmusic-media-loop… Flemming Andreasen
- Re: [MMUSIC] WGLC of draft-ietf-mmusic-media-loop… Magnus Westerlund
- Re: [MMUSIC] WGLC of draft-ietf-mmusic-media-loop… Nagarjuna Venna
- Re: [MMUSIC] WGLC of draft-ietf-mmusic-media-loop… Hadriel Kaplan
- Re: [MMUSIC] WGLC of draft-ietf-mmusic-media-loop… Gunnar Hellström
- Re: [MMUSIC] WGLC of draft-ietf-mmusic-media-loop… Miguel A. Garcia
- Re: [MMUSIC] WGLC of draft-ietf-mmusic-media-loop… Hadriel Kaplan