Re: [rtcweb] Updated -gateways draft

Harald Alvestrand <harald@alvestrand.no> Wed, 15 July 2015 08:50 UTC

Return-Path: <harald@alvestrand.no>
X-Original-To: rtcweb@ietfa.amsl.com
Delivered-To: rtcweb@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id AC7C11A892B for <rtcweb@ietfa.amsl.com>; Wed, 15 Jul 2015 01:50:26 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.21
X-Spam-Level:
X-Spam-Status: No, score=-4.21 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
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 78VGSXGZkn5H for <rtcweb@ietfa.amsl.com>; Wed, 15 Jul 2015 01:50:23 -0700 (PDT)
Received: from mork.alvestrand.no (mork.alvestrand.no [158.38.152.117]) by ietfa.amsl.com (Postfix) with ESMTP id DF2701A8927 for <rtcweb@ietf.org>; Wed, 15 Jul 2015 01:50:22 -0700 (PDT)
Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id 0D4A07C3A7D; Wed, 15 Jul 2015 10:50:22 +0200 (CEST)
X-Virus-Scanned: Debian amavisd-new at alvestrand.no
Received: from mork.alvestrand.no ([127.0.0.1]) by localhost (mork.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id P9eTgPovJ1CB; Wed, 15 Jul 2015 10:50:19 +0200 (CEST)
Received: from [IPv6:2001:470:de0a:27:3da7:4293:4c8b:1565] (unknown [IPv6:2001:470:de0a:27:3da7:4293:4c8b:1565]) by mork.alvestrand.no (Postfix) with ESMTPSA id 8F61C7C3A0C; Wed, 15 Jul 2015 10:50:19 +0200 (CEST)
Message-ID: <55A61ECA.9020008@alvestrand.no>
Date: Wed, 15 Jul 2015 10:50:18 +0200
From: Harald Alvestrand <harald@alvestrand.no>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0
MIME-Version: 1.0
To: "Schwarz, Albrecht (Albrecht)" <albrecht.schwarz@alcatel-lucent.com>, "ranjit@ranjitvoip.com" <ranjit@ranjitvoip.com>, Ted Hardie <ted.ietf@gmail.com>
References: <559AFEDB.4070205@alvestrand.no> <CA+9kkMCd0udsYrKAdAxt1zhb+=Gb9dy4rG=x5RWcxFBTx+tNOw@mail.gmail.com> <ded5924de7a9d5d62a0d988b43d39373@ranjitvoip.com> <55A4AAEE.6090007@alvestrand.no> <786615F3A85DF44AA2A76164A71FE1AC7ADA8882@FR711WXCHMBA03.zeu.alcatel-lucent.com>
In-Reply-To: <786615F3A85DF44AA2A76164A71FE1AC7ADA8882@FR711WXCHMBA03.zeu.alcatel-lucent.com>
Content-Type: text/plain; charset="utf-8"
Content-Transfer-Encoding: 8bit
Archived-At: <http://mailarchive.ietf.org/arch/msg/rtcweb/-u2asbRkNV-hBBKhp-CRyVKLnks>
Cc: "rtcweb@ietf.org" <rtcweb@ietf.org>
Subject: Re: [rtcweb] Updated -gateways draft
X-BeenThere: rtcweb@ietf.org
X-Mailman-Version: 2.1.15
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: <https://mailarchive.ietf.org/arch/browse/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: Wed, 15 Jul 2015 08:50:26 -0000

Thank you very much for this information!

It would seem to me to make sense to have an informative reference from
the gateway draft to the H.248.WEBRTC draft, so that people can find a
real worked example of such a gateway.

The text-over-IP specification would seem to require additional work
outside the scope of RTCWEB - this has been discussed before, and the
decision was to declare it out of scope. I think this will be typical
for applications that connect to gateways - they will require more
things than just WebRTC for a complete specification; thus, having the
example to point to is a Good Thing.

Harald

Den 15. juli 2015 10:02, skrev Schwarz, Albrecht (Albrecht):
> Dear All,
> some background info:
> 
> the 3GPP architecture provides a WebRTC gateway function (since 3GPP Release 12).
> The 3GPP WebRTC gateway entity is based on the decomposed gateway model according ITU-T H.248, i.e., H.248 is used as (vertical) gateway control protocol.
> The 3GPP WebRTC gateway function is mapped on the existing 3GPP P-CSCF/IMS-ALG entity ("the controller part") and the IMS access gateway ("the media gateway part").
> Thus, the 3GPP WebRTC gateway represents actually an "IMS WebRTC gateway" (in Rel-12 and 13).
> 
> The 3GPP specs (from WebRTC gateway perspective) are
> a) 3GPP 23.334, which covers signalling requirements and procedures for the gateway control interface and
> b) 3GPP 29.334, which specifies the protocol solution, known as so called "H.248 profile specification" (in context of H.248).
> 
> The 3GPP WebRTC gateway work is complemented by ITU-T SG16, as the technology owner of the H.248 protocol, as responsible instance for the development of H.248 protocol extensions (called H.248 packages).
> 
> The associated ITU-T work item is "H.248.WEBRTC", - and there will be a first Recommendation for "H.248 WebRTC gateways" soon, under Rec number ITU-T H.248.94.
> The June draft may be found under:
>  http://wftp3.itu.int/av-arch/avc-site/2013-2016/1506_Che/TD-11.zip 
> The October meeting input for next IETU-T meeting is available (for ITU-T delegates) under:
>  https://www.itu.int/md/dologin_md.asp?lang=en&id=T13-SG16-151012-TD-WP1-0278!!MSW-E 
> 
> The scope of the ITU-T H.248 WebRTC gateway function is aligned to IETF RTCWEB requirements in order to provide full support from gateway side. Hence, the "ITU-T H.248 WebRTC gateway function" represents currently a superset in comparison to the "3GPP Rel-12/13 IMS H.248 WebRTC gateway function". All major capabilities are supported, but there' are also some differences ...
> 
> Harald, draft H.248.94 (H.248.WEBRTC) is already refering to draft-rtcweb-gateways, - because the H.248 WebRTC gateway actually just realizes such a WebRTC gateway entity as outlined by the rtcweb draft.
>  
> BTW: I'd like to take the chance to point out some gateway specific observations, which should be addressed as well by the gateway draft. See H.248.WEBRTC, Appendix L6 Living List – Distributed Text-over-IP endpoints for WebRTC data 'text'
> 
> Coming back to the original question: whether it should be Informational or Standards-track, - I don't know. But it is apparent that both, the 3GPP and ITU-T work on WebRTC gateways needs to be tightly coupled and linked to the IETF gateway draft in my opinion.
> 
> Regards,
> Albrecht
> 
> 
> 
> -----Original Message-----
> From: rtcweb [mailto:rtcweb-bounces@ietf.org] On Behalf Of Harald Alvestrand
> Sent: Dienstag, 14. Juli 2015 08:24
> To: ranjit@ranjitvoip.com; Ted Hardie
> Cc: rtcweb@ietf.org
> Subject: Re: [rtcweb] Updated -gateways draft
> 
> Den 14. juli 2015 05:18, skrev ranjit@ranjitvoip.com:
>> Hi
>> It would be good if it is a standards track as 3GPP depends on it and 
>> all implementations would confirm to it . having it as Informational 
>> is really not of much use.
> 
> Could you share some more detail here?
> 
> - What 3GPP spec is depending on it?
> - What does the 3GPP spec depend on being in the draft?
> - What's the rules for referencing an IETF spec from a 3GPP spec, and why does the category matter?
> 
> Harald
> 
> 
>>
>> - Ranjit
>>
>> On 2015-07-06 5:35 pm, Ted Hardie wrote:
>>> On Mon, Jul 6, 2015 at 3:19 PM, Harald Alvestrand 
>>> <harald@alvestrand.no> wrote:
>>>
>>>> Uwe and I have prepared a new -gateways draft (version -01).
>>>>
>>>> I don't think there's much controversial in it, and there's only one 
>>>> issue that I think needs WG time at this time:
>>>>
>>>> Should it be Informational or Standards-track?
>>>>
>>>> An informational document defines guidance for how gateways should 
>>>> behave, but nobody needs to pay attention if they don't want to.
>>>>
>>>> A standards-track document (which no other RTCWEB document should be 
>>>> dependent on) defines requirements for how things that call 
>>>> themselves "WebRTC gateways" should behave, but nobody needs to call 
>>>> their gateways that, and anyway, there's no protocol police, so the 
>>>> difference isn't all that much in practice.
>>>>
>>>> More important: What do people want it to be?
>>>
>>> ​I think we adopted it in part because 3GPP had a dependency on it.
>>> Does it need to be standards track for them to reference it?
>>>
>>> Ted​
>>>
>>>> Harald
>>>>
>>>> _______________________________________________
>>>> rtcweb mailing list
>>>> rtcweb@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/rtcweb [1]
>>>
>>>
>>>
>>> Links:
>>> ------
>>> [1] https://www.ietf.org/mailman/listinfo/rtcweb
>>>
>>> _______________________________________________
>>> rtcweb mailing list
>>> rtcweb@ietf.org
>>> https://www.ietf.org/mailman/listinfo/rtcweb
>>
> 
> _______________________________________________
> rtcweb mailing list
> rtcweb@ietf.org
> https://www.ietf.org/mailman/listinfo/rtcweb
>