Re: [rtcweb] No Plan

Gunnar Hellstrom <gunnar.hellstrom@omnitor.se> Fri, 31 May 2013 05:33 UTC

Return-Path: <gunnar.hellstrom@omnitor.se>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C001F21F990D for <rtcweb@ietfa.amsl.com>; Thu, 30 May 2013 22:33:18 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.299
X-Spam-Level:
X-Spam-Status: No, score=-2.299 tagged_above=-999 required=5 tests=[AWL=0.300, BAYES_00=-2.599]
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 1FJmSWkTQNs1 for <rtcweb@ietfa.amsl.com>; Thu, 30 May 2013 22:33:13 -0700 (PDT)
Received: from vsp-authed-01-02.binero.net (vsp-authed02.binero.net [195.74.38.226]) by ietfa.amsl.com (Postfix) with SMTP id 2E70921F8EAE for <rtcweb@ietf.org>; Thu, 30 May 2013 22:33:10 -0700 (PDT)
Received: from smtp01.binero.se (unknown [195.74.38.28]) by vsp-authed-01-02.binero.net (Halon Mail Gateway) with ESMTP for <rtcweb@ietf.org>; Fri, 31 May 2013 07:32:04 +0200 (CEST)
Received: from [192.168.50.38] (h79n2fls31o933.telia.com [212.181.137.79]) (Authenticated sender: gunnar.hellstrom@omnitor.se) by smtp-09-01.atm.binero.net (Postfix) with ESMTPA id 2CA5A3A123 for <rtcweb@ietf.org>; Fri, 31 May 2013 07:32:04 +0200 (CEST)
Message-ID: <51A835D7.9060603@omnitor.se>
Date: Fri, 31 May 2013 07:32:07 +0200
From: Gunnar Hellstrom <gunnar.hellstrom@omnitor.se>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:17.0) Gecko/20130509 Thunderbird/17.0.6
MIME-Version: 1.0
To: rtcweb@ietf.org
References: <51A65017.4090502@jitsi.org> <51A7BEBE.2040302@omnitor.se> <CALiegfk6XchF4U1Orpd6oJsydz-VGtBQ=CwaWrPa_KjsaQynYQ@mail.gmail.com> <51A7CD81.2060805@gmail.com>
In-Reply-To: <51A7CD81.2060805@gmail.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Subject: Re: [rtcweb] No Plan
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Real-Time Communication in WEB-browsers working group list <rtcweb.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/rtcweb>
List-Post: <mailto:rtcweb@ietf.org>
List-Help: <mailto:rtcweb-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/rtcweb>, <mailto:rtcweb-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 31 May 2013 05:33:18 -0000

On 2013-05-31 00:06, Sergio Garcia Murillo wrote:
> El 30/05/2013 23:33, Iñaki Baz Castillo escribió:
>> 2013/5/30 Gunnar Hellstrom <gunnar.hellstrom@omnitor.se>se>:
>>> I find it to be good to have a specified ambition for legacy
>>> interoperability.
>>> But I cannot see how we could specify it without RTP based real-time 
>>> text on
>>> the SIP side.
>> So honestly I don't understand why WebRTC should care about "text 
>> messaging via RTP", and I really hope that "MSRP" word is never 
>> included in any RTCWEB WG specification. IMHO it's already enough 
>> having 3 proposals attempting to adapt SDP into WebRTC requirements. 
>
> To be fair, only two proposals try to modify the SDP, the third about 
> not adapting the SDP or change the O/A model.
>
>> Gateways are required, in any way, for connecting WebRTC and the 
>> world outside (SIP, PSTN, etc), let's leave those gateways to do the 
>> "magic" instead of proposing that a browser can send text messages 
>> via RTP to a SIP phone. Just my opinion.
It is not about text messages, it is about the real-time text medium. 
Just like real-time audio and real-time video. Smoother than messaging. 
Its user requirements for real-time transmission are close to the needs 
for audio and video, so it is on the rim to need RTP, but well designed 
data channel can also do. I do not understand why modern communication 
users accept to see a chat state indication of "composing" instead of 
really seeing what text is composed. With real-time text you get rid of 
the frustration that "composing" creates.
Now, this was not meant to be a repetition of the motivations for 
real-time text, but a discussion on interoperability requirements and 
sdp handling.
>>
>
> Indeed. I understand Gunnar requirements for RTT, but as you say, to 
> connect to legacy devices you would need a gateway in the middle 
> anyway. If the gateway support datachannels, It would be fairly 
> trivial to bridge the real time text data from T140 rtp packets 
> from/to the browser.
Yes, agreed, a data channel is one possible transport for real-time text 
and we need to get down to describing the alternatives and decide soon. 
What I am getting afraid of when I see the limited interperabillity 
discussion in "No Plan" is that we will not get a chance to specify the 
full view of the really needed interoperability. The mechanisms are tied 
to RTP characteristics, such as SSRCs, and it is said that interop 
beyond that limited scope will be an application concern. If this is the 
only place where we will discuss common specifications for SIP 
interoperability, then I want RTT to ride with this train and not be 
left alone on the station.

I also do not share Iñaki's view that rtcweb is all about communication 
between a server and a client delivered by that server, so that text 
communication is a local thing between that server and client. We have 
agreed that rtcweb must not be the continuation of building silos. Users 
of different providers and servers will want to have communication with 
each other, and that creates a need for explicit standards for session 
establishment and media stream establishment. Real-time text is one of 
the basic media together with audio and video which need to be fully 
defined for such interoperability.

Regards
Gunnar
>
> Best regards
> Sergio
>
>
>
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb