Re: [MMUSIC] Comments to draft-ietf-mmusic-media-path-middleboxes
Ivo Sedlacek <ivo.sedlacek@ericsson.com> Fri, 31 May 2013 09:49 UTC
Return-Path: <prvs=586395ec7e=ivo.sedlacek@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 E2FF521F96EB for <mmusic@ietfa.amsl.com>; Fri, 31 May 2013 02:49:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -6.249
X-Spam-Level:
X-Spam-Status: No, score=-6.249 tagged_above=-999 required=5 tests=[AWL=0.000, BAYES_00=-2.599, HELO_EQ_SE=0.35, RCVD_IN_DNSWL_MED=-4]
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 ZzDIQ6-Ho592 for <mmusic@ietfa.amsl.com>; Fri, 31 May 2013 02:49:32 -0700 (PDT)
Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id CF56121F8E12 for <mmusic@ietf.org>; Fri, 31 May 2013 02:49:31 -0700 (PDT)
X-AuditID: c1b4fb25-b7f4c6d000004656-14-51a8722ae759
Received: from ESESSHC004.ericsson.se (Unknown_Domain [153.88.253.125]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 7A.F0.18006.A2278A15; Fri, 31 May 2013 11:49:30 +0200 (CEST)
Received: from ESESSMB301.ericsson.se ([169.254.1.55]) by ESESSHC004.ericsson.se ([153.88.183.30]) with mapi id 14.02.0328.009; Fri, 31 May 2013 11:49:30 +0200
From: Ivo Sedlacek <ivo.sedlacek@ericsson.com>
To: Gonzalo Salgueiro <gsalguei@cisco.com>
Thread-Topic: Comments to draft-ietf-mmusic-media-path-middleboxes
Thread-Index: AQHOXV/vMkYv9S/UjUq1uIDl6n9odpkfC9Wg
Importance: low
X-Priority: 5
Date: Fri, 31 May 2013 09:49:29 +0000
Message-ID: <39B5E4D390E9BD4890E2B310790061010D77EF@ESESSMB301.ericsson.se>
References: <39B5E4D390E9BD4890E2B310790061010D72D7@ESESSMB301.ericsson.se> <673F23F8-5627-4F4A-A5ED-3A7987A634D0@cisco.com>
In-Reply-To: <673F23F8-5627-4F4A-A5ED-3A7987A634D0@cisco.com>
Accept-Language: en-US, cs-CZ
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [153.88.183.19]
Content-Type: text/plain; charset="iso-8859-2"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrNLMWRmVeSWpSXmKPExsUyM+Jvra5W0YpAg+Z7ahZzp/hZLN15j9Vi 6vLHLBbL5jxidmDxmPJ7I6vHzll32T0Wb9rP5rFkyU+mAJYobpukxJKy4Mz0PH27BO6Mtxf+ sRecNK74P/sLSwPjJ+UuRg4OCQETialdLl2MnECmmMSFe+vZuhi5OIQEDjNK/Ft8EcpZzCix adUSVpAqNgE9iYlbjoDZIgJaEtfvXGcCsZkFJjNK7FkuDmILCzhKvL36mgWixkni67UPTCDL RASMJC5P1gIJcwrwS7y4c5YNYjGvRO+SNrCRLAKqEjPPvQEbySvgLfHqeCtYq5BAncTaBV4Q rbYSzUeWgU1nFJCVuPqnlxHiAnGJW0/mM0GMFJBYsuc8M4QtKvHy8T9WCFtRov1pA1S9nsSz U7NYIGxtiWULXzNDrBWUODnzCcsERolZSMbOQtIyC0nLLCQtCxhZVjGy5yZm5qSXG21iBMbd wS2/VXcw3jkncohRmoNFSZxXj3dxoJBAemJJanZqakFqUXxRaU5q8SFGJg5OEMEl1cAo4cq/ Ju2f6dQ+S+msd1xp9t9fv6w5XWAU2zzJRtGWyaK1wk7tlu3K4KlT391dNkdr59uwzoYF1dF5 yjLG3c6mZfdbFVcrqYk+SWb/Z5p4UjZ0xhKjv+whiir7Tlwy+91+J6fX2KhSaWtjReKmDq/r p678/HWmyHmt7LUPDgv1PfNWM574+V+JpTgj0VCLuag4EQCxPJEbjgIAAA==
Cc: "obsidian97@gmail.com" <obsidian97@gmail.com>, "mmusic@ietf.org" <mmusic@ietf.org>
Subject: Re: [MMUSIC] Comments to draft-ietf-mmusic-media-path-middleboxes
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, 31 May 2013 09:49:37 -0000
Thank you for covering my comments in draft-ietf-mmusic-media-path-middleboxes-07. Kind regards Ivo Sedlacek This Communication is Confidential. We only send and receive email on the basis of the terms set out at www.ericsson.com/email_disclaimer -----Original Message----- From: Gonzalo Salgueiro [mailto:gsalguei@cisco.com] Sent: 30. května 2013 20:03 To: Ivo Sedlacek Cc: Hannes.Tschofenig@gmx.net; obsidian97@gmail.com; mmusic@ietf.org Subject: Re: Comments to draft-ietf-mmusic-media-path-middleboxes Thanks, Ivo. I have posted a new version addressing your and Bruno's comments. Thanks, Gonzalo On May 30, 2013, at 10:11 AM, Ivo Sedlacek <ivo.sedlacek@ericsson.com> wrote: > Hello, > > Comments to draft-ietf-mmusic-media-path-middleboxes-06: > > Comment 1: > > ISSUE: > > http://tools.ietf.org/html/draft-ietf-mmusic-media-path-middleboxes-06 states: > ------------------- > 3. Architecture > > Figure 1 shows the architecture that is being considered in this > document with respect to firewall and NAT traversal using media > relaying. The timing and directionality with which media packets are > allowed to traverse a particular edge device is the subject of this > investigation. The MIDCOM agent thereby pushes policy rules to the > middlebox that allow or deny certain flows to >>bypass<<. Additionally, > in case of media relaying it is important for the MIDCOM agent to > adjust the signaling messages. > > > SIP +-----------------+ SIP > +-----+ Signaling | SIP ALG | Signaling +-----+ > | UAC |<----------->+-----------------+<----------->| UAS | > +-----+ | MIDCOM Agent | +-----+ > ^ +-----------------+ ^ > | ^ | > | Policy rule(s) | and NAT bindings | > | v | > | Media +-------------+ Media | > +----------------->| Middlebox |<-----------------+ > +-------------+ > > Figure 1: Analysed Firewalling Architecture > > The aspects of packet filtering are described in Section 4 whereas > NAT traversal is illustrated in Section 5. > ------------------- > > The word "bypass" does not seem to be correct. > > "bypass" is defined by http://dictionary.cambridge.org/ as: "to avoid something by going around it" or " to ignore a rule or official authority". > > However, the figure 1 shows media of the flows passing through/via the middlebox, not around the middlebox. > > > PROPOSAL: > ------------------- > 3. Architecture > > Figure 1 shows the architecture that is being considered in this > document with respect to firewall and NAT traversal using media > relaying. The timing and directionality with which media packets are > allowed to traverse a particular edge device is the subject of this > investigation. The MIDCOM agent thereby pushes policy rules to the > middlebox that allow or deny certain flows to >>pass through<<. Additionally, > in case of media relaying it is important for the MIDCOM agent to > adjust the signaling messages. > > > SIP +-----------------+ SIP > +-----+ Signaling | SIP ALG | Signaling +-----+ > | UAC |<----------->+-----------------+<----------->| UAS | > +-----+ | MIDCOM Agent | +-----+ > ^ +-----------------+ ^ > | ^ | > | Policy rule(s) | and NAT bindings | > | v | > | Media +-------------+ Media | > +----------------->| Middlebox |<-----------------+ > +-------------+ > > Figure 1: Analysed Firewalling Architecture > > The aspects of packet filtering are described in Section 4 whereas > NAT traversal is illustrated in Section 5. > ------------------- > > Comment 2: > > ISSUE: > > http://tools.ietf.org/html/draft-ietf-mmusic-media-path-middleboxes-06 states: > ------------------- > REC #4: If signaling on the media path is required before media can > flow, the >>answer<< should send the SDP answer as soon as possible, > for example within a provisional SIP response, to allow the media > path signaling to bypass middleboxes and therefore to avoid > clipping. > ------------------- > I believe there is an error. > > PROPOSAL: > ------------------- > REC #4: If signaling on the media path is required before media can > flow, the >>answerer<< should send the SDP answer as soon as possible, > for example within a provisional SIP response, to allow the media > path signaling to bypass middleboxes and therefore to avoid > clipping. > ------------------- > > Comment 3: > > ISSUE: > > http://tools.ietf.org/html/draft-ietf-mmusic-media-path-middleboxes-06 states: > ------------------- > REC #4: If signaling on the media path is required before media can > flow, the answer should send the SDP answer as soon as possible, > for example within a provisional SIP response, to allow the media > path signaling to >>bypass<< middleboxes and therefore to avoid > clipping. > ------------------- > Same issue as in Comment 1. > > PROPOSAL: > ------------------- > REC #4: If signaling on the media path is required before media can > flow, the answer should send the SDP answer as soon as possible, > for example within a provisional SIP response, to allow the media > path signaling to >>pass through<< middleboxes and therefore to avoid > clipping. > ------------------- > > > Kind regards > > Ivo Sedlacek > > Ericsson > Mobile +420 608 234 709 > ivo.sedlacek@ericsson.com > www.ericsson.com > > This Communication is Confidential. We only send and receive email on the basis of the terms set out at www.ericsson.com/email_disclaimer
- [MMUSIC] Comments to draft-ietf-mmusic-media-path… Ivo Sedlacek
- Re: [MMUSIC] Comments to draft-ietf-mmusic-media-… Gonzalo Salgueiro
- Re: [MMUSIC] Comments to draft-ietf-mmusic-media-… Ivo Sedlacek
- Re: [MMUSIC] Comments to draft-ietf-mmusic-media-… Hannes Tschofenig