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

[Gonzalo Salgueiro <[e-mail]>]

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 <[e-mail]> 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 [phone]
> [e-mail]
> 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