Re: [pntaw] Real-time media over TCP

"Parthasarathi R" <partha@parthasarathi.co.in> Mon, 14 October 2013 18:31 UTC

Return-Path: <partha@parthasarathi.co.in>
X-Original-To: pntaw@ietfa.amsl.com
Delivered-To: pntaw@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 2782621E80B3 for <pntaw@ietfa.amsl.com>; Mon, 14 Oct 2013 11:31:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.132
X-Spam-Level:
X-Spam-Status: No, score=-2.132 tagged_above=-999 required=5 tests=[AWL=-0.467, BAYES_00=-2.599, IP_NOT_FRIENDLY=0.334, J_CHICKENPOX_35=0.6]
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 M4DtOSWMEiah for <pntaw@ietfa.amsl.com>; Mon, 14 Oct 2013 11:31:37 -0700 (PDT)
Received: from smtp.mailhostbox.com (outbound-us2.mailhostbox.com [69.93.141.235]) by ietfa.amsl.com (Postfix) with ESMTP id 7E9DB21F936F for <pntaw@ietf.org>; Mon, 14 Oct 2013 11:31:27 -0700 (PDT)
Received: from userPC (unknown [122.172.182.21]) (Authenticated sender: partha@parthasarathi.co.in) by smtp.mailhostbox.com (Postfix) with ESMTPA id 70FCB639297; Mon, 14 Oct 2013 18:30:26 +0000 (GMT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=parthasarathi.co.in; s=20120823; t=1381775431; bh=4u5So05Kwsarpo4iEZikwSqUoI//fe2LXzps/m4Q06E=; h=From:To:References:In-Reply-To:Subject:Date:Message-ID: MIME-Version:Content-Type:Content-Transfer-Encoding; b=Zod+nfdvmY8724rZbpConn5FR0X0nIe8Ep/CKJkzspGR7/CjcWSIFzRddWhu1apqm Nvg4h86KQfoyxxomhKEQOQGAqfKDMqKNGTWaqa3bgDzOaD5n5HToVCMhoauXJtZeS5 z45RzvuG0mLP0LMMmD0dNsyExchn5Qh5T5eF1kBU=
From: "Parthasarathi R" <partha@parthasarathi.co.in>
To: "'Chenxin \(Xin\)'" <hangzhou.chenxin@huawei.com>, <Markus.Isomaki@nokia.com>, <simon.perreault@viagenie.ca>, <pntaw@ietf.org>
References: <CAGTXFp92jSzQz05uHngzscz88n=fT_JPbEvQRxgeUUqPVRQUyQ@mail.gmail.com> <52244DD7.1020900@alvestrand.no> <BLU405-EAS183E36A927CA42270B6936D93300@phx.gbl> <522590EE.7070508@alvestrand.no> <C632A223-A55A-47F4-B083-9BDC447DA959@cisco.com> <52262657.3080208@alvestrand.no> <A2C315DB-1882-4BD1-A8C0-E8AF7DEA48F4@cisco.com> <00ca01cec387$f881cae0$e98560a0$@co.in> <BLU406-EAS274696C3D9DFE505F96B8E393130@phx.gbl> <004201cec44f$381a47f0$a84ed7d0$@co.in> <52544E0E.5080405@viagenie.ca> <003b01cec511$27e1abe0$77a503a0$@co.in> <E44893DD4E290745BB608EB23FDDB7620A0D672F@008-AM1MPN1-042.mgdnok.nokia.com> <9E34D50A21D1D1489134B4D770CE039768081AC9@SZXEMA504-MBX.china.huawei.com> <004e01cec5df$cf8daaf0$6ea900d0$@co.in> <9E34D50A21D1D1489134B4D770CE039768081D1B@SZXEMA504-MBX.china.huawei.com>
In-Reply-To: <9E34D50A21D1D1489134B4D770CE039768081D1B@SZXEMA504-MBX.china.huawei.com>
Date: Tue, 15 Oct 2013 00:00:22 +0530
Message-ID: <00cc01cec90b$75faff90$61f0feb0$@co.in>
MIME-Version: 1.0
Content-Type: text/plain; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
X-Mailer: Microsoft Office Outlook 12.0
Thread-Index: AQHOp7eh97CWvanNyUO4L+fWrmoYupmyO7sAgADeqQCAAKUrgIAADPKAgAAjEICANUrLAIAAB1IAgAGHKgCAAAkXAIABes4AgAAIDACAARCqIIAA8XlQgADDLECABanJQA==
Content-Language: en-us
X-CTCH-RefID: str=0001.0A02020A.525C3847.00FE, ss=1, re=0.000, recu=0.000, reip=0.000, cl=1, cld=1, fgs=0
X-CTCH-VOD: Unknown
X-CTCH-Spam: Unknown
X-CTCH-Score: 0.000
X-CTCH-Rules:
X-CTCH-Flags: 0
X-CTCH-ScoreCust: 0.000
X-CTCH-SenderID: partha@parthasarathi.co.in
X-CTCH-SenderID-TotalMessages: 1
X-CTCH-SenderID-TotalSpam: 0
X-CTCH-SenderID-TotalSuspected: 0
X-CTCH-SenderID-TotalBulk: 0
X-CTCH-SenderID-TotalConfirmed: 0
X-CTCH-SenderID-TotalRecipients: 0
X-CTCH-SenderID-TotalVirus: 0
X-CTCH-SenderID-BlueWhiteFlag: 0
X-Scanned-By: MIMEDefang 2.72 on 70.87.28.142
Subject: Re: [pntaw] Real-time media over TCP
X-BeenThere: pntaw@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "Discussion list for practices related to proxies, NATs, TURN, and WebRTC" <pntaw.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/pntaw>, <mailto:pntaw-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/pntaw>
List-Post: <mailto:pntaw@ietf.org>
List-Help: <mailto:pntaw-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/pntaw>, <mailto:pntaw-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 14 Oct 2013 18:31:42 -0000

Xin,

<snip> The
> advantage
> >with
> >Media over HTTP is that HTTP friendly firewall shall filter out media
> from
> >HTTP traffic if required.
> [xin] And media over websocket should be a option. The sub-protocol
> attribute in websokcet could also provide the firewall friendly
> information, so the firewall could decide to filter out the media or
> not.
</snip>

Agreed. I'll write DTLS-SRTP over WebSocket draft for more clarity.  

Please read inline.

Thanks
Partha

> -----Original Message-----
> From: Chenxin (Xin) [mailto:hangzhou.chenxin@huawei.com]
> Sent: Friday, October 11, 2013 9:28 AM
> To: Parthasarathi R; Markus.Isomaki@nokia.com;
> simon.perreault@viagenie.ca; pntaw@ietf.org
> Subject: RE: [pntaw] Real-time media over TCP
> 
> Hi
> >Hi all,
> >
> >As I mentioned below, ICE-TCP is not replacement for TURN but ICE-TCP
> helps
> >for the browser-to-browser media flow without middle box (TURN
> Server).
> >Also, please note that both browsers behind UDP blocked firewall is
> not the
> >worst case scenario for WebRTC firewall requirements. The actual worst
> case
> >scenario is that both browsers are behind HTTP only firewalls and in
> this
> >scenario, both TURN server and ICE-TCP will not work. There is a need
> of one
> >more solution.
> >
> >AFAIK, HTTP allowing firewall is not happen by mis-configuration but
> it is
> >policy of the given network. It is more appropriate to pass the media
> over
> >HTTP based mechanism rather than finding the workarounds. The
> advantage
> >with
> >Media over HTTP is that HTTP friendly firewall shall filter out media
> from
> >HTTP traffic if required.
> [xin] And media over websocket should be a option. The sub-protocol
> attribute in websokcet could also provide the firewall friendly
> information, so the firewall could decide to filter out the media or
> not.
> 
>  IMO, Media over HTTP based mechanism has to be
> >used for HTTP only firewall (Sec 3.2.3 of
> >draft-ietf-rtcweb-use-cases-and-requirements) requirement and ICE-TCP
> shall
> >be used for (Sec 3.2.3 of draft-ietf-rtcweb-use-cases-and-
> requirements)
> >requirement.
> 
>   [Xin] I think you means ICE-TCP shall be used for (*Sec 3.2.2* of
> draft-ietf-rtcweb-use-cases-and-requirements) requirement.:)

<Partha> Thanks for the indicating the cut&paste issue :-(. Your thinking is
correct. </Partha>

> 
> Thanks,
>   Xin
> >
> >Thanks
> >Partha
> >
> >> -----Original Message-----
> >> From: pntaw-bounces@ietf.org [mailto:pntaw-bounces@ietf.org] On
> Behalf
> >> Of Chenxin (Xin)
> >> Sent: Thursday, October 10, 2013 7:23 AM
> >> To: Markus.Isomaki@nokia.com; partha@parthasarathi.co.in;
> >> simon.perreault@viagenie.ca; pntaw@ietf.org
> >> Subject: Re: [pntaw] Real-time media over TCP
> >>
> >> Hi
> >>
> >>  I agree that ICE-TCP should not replace TURN as a requirement for
> >> every browser to implement. If we need support ICE-TCP , should we
> >> support TURN-TCP too? I do not think ICE-TCP will be more useful
> >> without TURN-TCP in the scenario where both browsers is under the
> NAT
> >> /FW which block UDP.
> >>
> >>   I believe the user 1->TCP->TURN server 1->UDP->TURN server 2->TCP-
> >> >user 2, which Harald wrote before is workable. It is easy to tunnel
> >> the data internally if we need use the same server, right?
> >>
> >> Best Regards,
> >>      Xin
> >>
> >>
> >> >-----Original Message-----
> >> >From: pntaw-bounces@ietf.org [mailto:pntaw-bounces@ietf.org] On
> Behalf
> >> Of
> >> >Markus.Isomaki@nokia.com
> >> >Sent: Thursday, October 10, 2013 1:30 AM
> >> >To: partha@parthasarathi.co.in; simon.perreault@viagenie.ca;
> >> pntaw@ietf.org
> >> >Subject: Re: [pntaw] Real-time media over TCP
> >> >
> >> >Hi,
> >> >
> >> >I think the clarification is that it is not possible to initiate
> TCP
> >> connections from
> >> >the "outside" of any NAT or most of the firewalls. So even if the
> FW
> >> does not
> >> >block TCP per se, it only allows TCP connections to be opened from
> the
> >> "inside".
> >> >
> >> >I believe ICE-TCP will typically work only in cases where at least
> one
> >> of the
> >> >endpoints is NOT behind a NAT or FW. In cases where both endpoints
> are
> >> behind
> >> >firewalls completely blocking all UDP, the only option is to use a
> >> relay (TURN)
> >> >with endpoint initiated TCP connections. ICE allows us to optimize
> >> connectivity
> >> >in special cases, but I think we need also to make the worst case
> >> scenarios to
> >> >work. For that reason I don't see that ICE-TCP could replace TURN
> as a
> >> >requirement for every browser to implement. In some specific
> >> deployments it
> >> >may be that TURN does not get used much or at all, but browsers are
> >> used
> >> >everywhere.
> >> >
> >> >Markus
> >> >
> >> >> -----Original Message-----
> >> >> From: pntaw-bounces@ietf.org [mailto:pntaw-bounces@ietf.org] On
> >> Behalf
> >> >> Of ext Parthasarathi R
> >> >> Sent: 09 October, 2013 20:01
> >> >> To: 'Simon Perreault'; pntaw@ietf.org
> >> >> Subject: Re: [pntaw] Real-time media over TCP
> >> >>
> >> >> Hi Simon,
> >> >>
> >> >> I have seen only two requirements in
> >> >> draft-ietf-rtcweb-use-cases-and-requirements-11, NAT/FW that
> blocks
> >> UDP
> >> >> and FW that only allows http. The relevant draft snippet is
> attached
> >> as a note
> >> >> of this mail. I'm discussing about NAT/FW that blocks UDP
> >> requirement. In
> >> >> case you foresee that the requirement is not detailed now, we
> need
> >> to sort
> >> >> out the requirement first before discussion the solutions.
> >> >>
> >> >> Regards
> >> >> Partha
> >> >>
> >> >> PS: In draft-ietf-rtcweb-use-cases-and-requirements-11 snippet,
> >> >>
> >> >> 3.2.2.  Simple Video Communication Service, NAT/FW that blocks
> UDP
> >> >>
> >> >> 3.2.2.1.  Description
> >> >>
> >> >>    This use-case is almost identical to the Simple Video
> >> Communication
> >> >>    Service use-case (Section 3.2.1).  The difference is that one
> of
> >> the
> >> >>    users is behind a NAT that blocks UDP traffic.
> >> >>
> >> >> 3.2.3.  Simple Video Communication Service, FW that only allows
> http
> >> >>
> >> >> 3.2.3.1.  Description
> >> >>
> >> >>    This use-case is almost identical to the Simple Video
> >> Communication
> >> >>    Service use-case (Section 3.2.1).  The difference is that one
> of
> >> the
> >> >>    users is behind a FW that only allows http traffic.
> >> >>
> >> >> > -----Original Message-----
> >> >> > From: pntaw-bounces@ietf.org [mailto:pntaw-bounces@ietf.org] On
> >> >> Behalf
> >> >> > Of Simon Perreault
> >> >> > Sent: Tuesday, October 08, 2013 11:55 PM
> >> >> > To: pntaw@ietf.org
> >> >> > Subject: Re: [pntaw] Real-time media over TCP
> >> >> >
> >> >> > Le 2013-10-08 19:52, Parthasarathi R a écrit :
> >> >> > > I understand that two WebRTC endpoint are behind firewall
> >> scenario
> >> >> > wherein
> >> >> > > TURN server is unavoidable. Most of the SP & Enterprise
> >> deployment
> >> >> > wherein
> >> >> > > one of the endpoint is not surely going to be behind UDP
> >> blocking
> >> >> > Firewall,
> >> >> > > mandating TURN server as a mechanism is overkill. As ICE is
> >> mandated
> >> >> > in
> >> >> > > WebRTC, supporting ICE-TCP should not be such a complex
> >> activity.
> >> >> >
> >> >> > A firewall that blocks UDP but allows incoming TCP is not very
> >> common,
> >> >> > is it?
> >> >> >
> >> >> > Or did I miss something?
> >> >> >
> >> >> > Simon
> >> >> > --
> >> >> > DTN made easy, lean, and smart -->
> http://postellation.viagenie.ca
> >> >> > NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
> >> >> > STUN/TURN server               --> http://numb.viagenie.ca
> >> >> > _______________________________________________
> >> >> > pntaw mailing list
> >> >> > pntaw@ietf.org
> >> >> > https://www.ietf.org/mailman/listinfo/pntaw
> >> >>
> >> >> _______________________________________________
> >> >> pntaw mailing list
> >> >> pntaw@ietf.org
> >> >> https://www.ietf.org/mailman/listinfo/pntaw
> >> >_______________________________________________
> >> >pntaw mailing list
> >> >pntaw@ietf.org
> >> >https://www.ietf.org/mailman/listinfo/pntaw
> >> _______________________________________________
> >> pntaw mailing list
> >> pntaw@ietf.org
> >> https://www.ietf.org/mailman/listinfo/pntaw