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

["Hannes Tschofenig" <[e-mail]>]

Thanks for the careful reading of the document and for providing actionable feedback, Ivo. 

And thanks to Gonzalo for reacting so quickly with a new draft update. 

 

Ciao
Hannes

 

Gesendet: Freitag, 31. Mai 2013 um 11:49 Uhr
Von: "Ivo Sedlacek" <[e-mail]>
An: "Gonzalo Salgueiro" <[e-mail]>
Cc: "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>, "[e-mail]" <[e-mail]>
Betreff: RE: Comments to draft-ietf-mmusic-media-path-middleboxes

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 http://www.ericsson.com/email_disclaimer" target="_blank" rel="nofollow">www.ericsson.com/email_disclaimer

-----Original Message-----
From: Gonzalo Salgueiro [mailto:[e-mail]]
Sent: 30. května 2013 20:03
To: Ivo Sedlacek
Cc: [e-mail]; [e-mail]; [e-mail]
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 <[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" target="_blank" rel="nofollow">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/" target="_blank" rel="nofollow">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" target="_blank" rel="nofollow">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" target="_blank" rel="nofollow">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]
> http://www.ericsson.com" target="_blank" rel="nofollow">www.ericsson.com
>
> This Communication is Confidential. We only send and receive email on the basis of the terms set out at http://www.ericsson.com/email_disclaimer" target="_blank" rel="nofollow">www.ericsson.com/email_disclaimer