Re: [pntaw] Real-time media over TCP

Dan Wing <dwing@cisco.com> Tue, 15 October 2013 00:52 UTC

Return-Path: <dwing@cisco.com>
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 6E29921E8134 for <pntaw@ietfa.amsl.com>; Mon, 14 Oct 2013 17:52:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -110.598
X-Spam-Level:
X-Spam-Status: No, score=-110.598 tagged_above=-999 required=5 tests=[AWL=-0.000, BAYES_00=-2.599, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-8, USER_IN_WHITELIST=-100]
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 NH+28NflACOK for <pntaw@ietfa.amsl.com>; Mon, 14 Oct 2013 17:52:52 -0700 (PDT)
Received: from mtv-iport-2.cisco.com (mtv-iport-2.cisco.com [173.36.130.13]) by ietfa.amsl.com (Postfix) with ESMTP id 0F7B121E811D for <pntaw@ietf.org>; Mon, 14 Oct 2013 17:52:50 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cisco.com; i=@cisco.com; l=9269; q=dns/txt; s=iport; t=1381798370; x=1383007970; h=mime-version:subject:from:in-reply-to:date:cc:message-id: references:to; bh=yC2VExo+44AmDjub78auUY9LMxBzEVjhn7U5CoN/3LA=; b=BrfS9SJxsM2vR2ST0XJ7/CLIBpv8+kZsJtzTUsZKHTkgnCNKLYIp+PFf aNSoE+MmPAmQ+dhOKJqp0RGh5mv7Hhd1bu4Rv/h8LH4Ji6YSuK4VxFcWL vpC5JLMaMi0yO0mQdxUmm0lB7i/zOwVoJL4LVP8PZMarBpgtQUYhhJmdF 0=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-Anti-Spam-Result: AgMFAMyQXFKrRDoI/2dsb2JhbABZgwc4wnGBJxZ0giUBAQEDAQEBAWsLBQcECxEEAQEBJwchBh8JCAYTh3QDCQUNs2wNiWcEjFyBNYE1BAcGgxmBBgOJPIxfgWmMTIU2g0QcgTQ
X-IronPort-AV: E=Sophos; i="4.93,495,1378857600"; d="scan'208,217"; a="94721539"
Received: from mtv-core-3.cisco.com ([171.68.58.8]) by mtv-iport-2.cisco.com with ESMTP; 15 Oct 2013 00:52:49 +0000
Received: from dhcp-10-155-84-77.cisco.com (dhcp-10-155-84-77.cisco.com [10.155.84.77]) by mtv-core-3.cisco.com (8.14.5/8.14.5) with ESMTP id r9F0qmS2027544; Tue, 15 Oct 2013 00:52:48 GMT
Content-Type: multipart/alternative; boundary="Apple-Mail=_A2656246-BE9D-4D83-A720-67713EC58FE7"
Mime-Version: 1.0 (Mac OS X Mail 6.6 \(1510\))
From: Dan Wing <dwing@cisco.com>
In-Reply-To: <CA+9kkMDofv4+nhAWhxVBT6dFy55uyCVCx=EEsatWiU=WvAhKKA@mail.gmail.com>
Date: Mon, 14 Oct 2013 17:52:50 -0700
Message-Id: <557505AD-86DB-41D5-9ED7-71223D4937A9@cisco.com>
References: <CAGTXFp92jSzQz05uHngzscz88n=fT_JPbEvQRxgeUUqPVRQUyQ@mail.gmail.com> <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> <E44893DD4E290745BB608EB23FDDB7620A0E2DC6@008-AM1MPN1-043.mgdnok.nokia.com> <9F33F40F6F2CD847824537F3C4E37DDF17BEFB3E@MCHP04MSX.global-ad.net> <BLU402-EAS357ECBFC621A567B9D3A7B4931A0@phx.gbl> <525C148F.8070502@gmail.com> <00d401cec90e$d688d5a0$839a80e0$@co.in> <E44893DD4E290745BB608EB23FDDB7620A0E7172@008-AM1MPN1-043.mgdnok.nokia.com> <525C655B.6020802@ alum.mit.edu> <0AE4085A-CE50-4813-B03C-9A5FB86277BD@cisco.com> <CA+9kkMDofv4+nhAWhxVBT6dFy55uyCVCx=EEsatWiU=WvAhKKA@mail.gmail.com>
To: Ted Hardie <ted.ietf@gmail.com>
X-Mailer: Apple Mail (2.1510)
Cc: pntaw@ietf.org, Paul Kyzivat <pkyzivat@alum.mit.edu>
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: Tue, 15 Oct 2013 00:52:56 -0000

On Oct 14, 2013, at 5:08 PM, Ted Hardie <ted.ietf@gmail.com>; wrote:

> On Mon, Oct 14, 2013 at 5:04 PM, Dan Wing <dwing@cisco.com>; wrote:
> 
> On Oct 14, 2013, at 2:42 PM, Paul Kyzivat <pkyzivat@alum.mit.edu>; wrote:
> 
> > But in practice I suppose the relay will be conveniently located relative to one of the two endpoints.
> 
> I think that is a separate problem.  Smart ICE candidate prioritization would choose the "best candidate" (for some value of "best candidate").  The ICE connectivity check round-trip time is an oft-cited example of a reasonable metric (although it doesn't measure bandwidth and packet loss is considered by some to mislead [but if a path is lossy it may indeed be a very undesirable path]).  Geolocation of the TURN IP address versus my own IP address could also influence ICE candidate prioritization or candidate selection.
> 
> -d
> 
> 
> Hi Dan,
> 
> I don't think I understand who is running a geolocation algorithm in this scenario.  Can you elaborate?

The RTCWEB host.  For example, it could ask a geolocation service how many miles away the TURN server's IP address is from itself.  I'm not saying this is better than just doing a STUN transaction with that same TURN server; I just wanted another way to influence ICE candidate selection.

-d


> 
> regards,
> 
> Ted
> 
>  
> 
> >
> >       Thanks,
> >       Paul
> >
> >> Markus
> >>
> >>> -----Original Message-----
> >>> From: pntaw-bounces@ietf.org [mailto:pntaw-bounces@ietf.org] On Behalf
> >>> Of ext Parthasarathi R
> >>> Sent: 14 October, 2013 21:55
> >>> To: pntaw@ietf.org
> >>> Subject: Re: [pntaw] Real-time media over TCP
> >>>
> >>> Hi all,
> >>>
> >>> My point is that the direct media connection has to be given priority over
> >>> TURN based mechanism. In case of ICE-TCP, there is a possibility for the
> >>> direction connection between two browsers involved in the WebRTC session
> >>> and should be given priority over TURN based mechanism. So, 6) TCP based
> >>> candidates (ICE-TCP) - MUST
> >>>
> >>> There is an assumption in the discussion that the incoming TCP traffic is not
> >>> allowed through firewall. In case it is the problem to be solved, RTCWeb
> >>> usecase and requirement has to be updated. I noticed in
> >>> draft-ietf-rtcweb-use-cases-and-requirements-12 (published today) that
> >>> there is no such requirement. I'll write the mail in RTCWeb WG to get the
> >>> clarity on the requirement in case the firewall forbidding incoming TCP traffic
> >>> is a matter of missing text in the requirement.
> >>>
> >>> Thanks
> >>> Partha
> >>>
> >> _______________________________________________
> >> 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