Re: [AVTCORE] draft-ietf-avtcore-multi-party-rtt-mix Issue 1: transport

Gunnar Hellström <gunnar.hellstrom@ghaccess.se> Mon, 18 May 2020 18:54 UTC

Return-Path: <gunnar.hellstrom@ghaccess.se>
X-Original-To: avt@ietfa.amsl.com
Delivered-To: avt@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id D6DC83A0D36 for <avt@ietfa.amsl.com>; Mon, 18 May 2020 11:54:40 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.001
X-Spam-Level:
X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=egensajt.se
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id OUQ4rpNHBueu for <avt@ietfa.amsl.com>; Mon, 18 May 2020 11:54:36 -0700 (PDT)
Received: from smtp.egensajt.se (smtp.egensajt.se [194.68.80.251]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 2E5713A0D91 for <avt@ietf.org>; Mon, 18 May 2020 11:54:33 -0700 (PDT)
Received: from [192.168.2.136] (h79-138-72-251.cust.a3fiber.se [79.138.72.251]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) (Authenticated sender: gunnar.hellstrom@ghaccess.se) by smtp.egensajt.se (Postfix) with ESMTPSA id 9B00C2028E for <avt@ietf.org>; Mon, 18 May 2020 20:54:31 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=egensajt.se; s=dkim; t=1589828071; bh=q19KkCAdWDAFbYu8BpJB/zAxRD62IT2A0ApvtjpKip0=; h=Subject:To:References:From:Date:In-Reply-To:From; b=V2byDlj1goeFpVOYOwmZ7ANYk+bPXPpHBU0L7KGKs7vUFUuOam2Tci/KgnywzQeXq SwVWvPJdDk185fa0PIUCqkgZ0NTh0fjnwUuAGLGbyknjGatPQi3SodbIBIZXlG5Zvx MLzdLMufBzC8AE6O7Wt20RxpsBwhq1JWvf6gGqCg=
To: avt@ietf.org
References: <46CB285F-C49A-4910-B9B1-667AB1AE4538@brianrosen.net> <DC445046-4F9A-48AA-9192-6430B6FBEF4C@gmail.com> <0112D996-221B-4B2F-9647-A6CCBF0F3B4C@brianrosen.net> <77C1CD99-247A-4B3C-B164-DB6BA040C615@ericsson.com>
From: =?UTF-8?Q?Gunnar_Hellstr=c3=b6m?= <gunnar.hellstrom@ghaccess.se>
Message-ID: <7207a58f-85d3-6e27-af0a-06f51444768a@ghaccess.se>
Date: Mon, 18 May 2020 20:54:29 +0200
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.8.0
MIME-Version: 1.0
In-Reply-To: <77C1CD99-247A-4B3C-B164-DB6BA040C615@ericsson.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: sv
Archived-At: <https://mailarchive.ietf.org/arch/msg/avt/MgasTnRyFKqzE0gXylSXJYc4Kvw>
Subject: Re: [AVTCORE] draft-ietf-avtcore-multi-party-rtt-mix Issue 1: transport
X-BeenThere: avt@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Audio/Video Transport Core Maintenance <avt.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/avt>, <mailto:avt-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/avt/>
List-Post: <mailto:avt@ietf.org>
List-Help: <mailto:avt-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/avt>, <mailto:avt-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 18 May 2020 18:54:41 -0000

Hi,

Den 2020-05-18 kl. 18:00, skrev Christer Holmberg:
> Hi,
>
>> I think this means we use the WebRTC data channel, which is HTTP based, right?  Totally bypasses the SBC.  Have to be careful to not cause the SBC to get confused with the SDP.
> The WebRTC data channel is not HTTP based. It is basically an SCTP stream.

Yes, with UDP as the lowest layer.

So we are talking about two UDP based transports.

text/red and text/rex are RTP based, and may be SRTP encrypted. They are 
declared in the same m-line, and one selected and then will use one or 
two ports.

WebRTC data channels stack is UDP/DTLS/SCTP.

Both would normally use ICE to find their ways through networks.

Do we really have noticable differences in how hard it would be to get 
through the networks with any of these? And would there be any other 
transport that would be easier to get through?


Regards

Gunnar

>
> Regards,
>
> Christer
>
>
>      > On May 18, 2020, at 11:24 AM, Bernard Aboba <bernard.aboba@gmail.com> wrote:
>      >
>      > lOn May 18, 2020, at 8:09 AM, Brian Rosen <br@brianrosen.net> wrote:
>      >>
>      >> It occurs to me that the SBC may not pass text/red.  Depends on how picky they are.  Text/red is basic T.140.
>      >
>      > [BA] Legacy SBCs are indeed an issue, and a basic obstacle to deployment of RTT. I am not aware of any SIP trunk providers that support text/red, because they would need to upgrade their SBCs to do so, which would be a large cost, with no corresponding revenue source.
>
>      _______________________________________________
>      Audio/Video Transport Core Maintenance
>      avt@ietf.org
>      https://www.ietf.org/mailman/listinfo/avt
>
> _______________________________________________
> Audio/Video Transport Core Maintenance
> avt@ietf.org
> https://www.ietf.org/mailman/listinfo/avt

-- 
Gunnar Hellström
GHAccess
gunnar.hellstrom@ghaccess.se