Re: [MMUSIC] Comments to draft-ietf-mmusic-media-path-middleboxes

Gonzalo Salgueiro <gsalguei@cisco.com> Thu, 30 May 2013 18:03 UTC

Return-Path: <gsalguei@cisco.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 48E3321F9410 for <mmusic@ietfa.amsl.com>; Thu, 30 May 2013 11:03:04 -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 IXAI8TzAvaiO for <mmusic@ietfa.amsl.com>; Thu, 30 May 2013 11:03:00 -0700 (PDT)
Received: from av-tac-rtp.cisco.com (av-tac-rtp.cisco.com [64.102.19.209]) by ietfa.amsl.com (Postfix) with ESMTP id 535B821F93EB for <mmusic@ietf.org>; Thu, 30 May 2013 11:03:00 -0700 (PDT)
X-TACSUNS: Virus Scanned
Received: from chook.cisco.com (localhost.cisco.com [127.0.0.1]) by av-tac-rtp.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r4UI2wlV026099 for <mmusic@ietf.org>; Thu, 30 May 2013 14:02:59 -0400 (EDT)
Received: from rtp-gsalguei-8912.cisco.com (rtp-gsalguei-8912.cisco.com [10.116.132.51]) by chook.cisco.com (8.13.8+Sun/8.13.8) with ESMTP id r4UI2wbG022518; Thu, 30 May 2013 14:02:58 -0400 (EDT)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 6.3 \(1503\))
From: Gonzalo Salgueiro <gsalguei@cisco.com>
In-Reply-To: <39B5E4D390E9BD4890E2B310790061010D72D7@ESESSMB301.ericsson.se>
Date: Thu, 30 May 2013 14:02:58 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <673F23F8-5627-4F4A-A5ED-3A7987A634D0@cisco.com>
References: <39B5E4D390E9BD4890E2B310790061010D72D7@ESESSMB301.ericsson.se>
To: Ivo Sedlacek <ivo.sedlacek@ericsson.com>
X-Mailer: Apple Mail (2.1503)
Cc: obsidian97@gmail.com, 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: Thu, 30 May 2013 18:03:04 -0000

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