Re: [MMUSIC] T.38 (Re: M-line philosophy (Re: Wisdom sought: Prioritization of codecs))

Stefan Hakansson LK <stefan.lk.hakansson@ericsson.com> Fri, 23 November 2012 11:08 UTC

Return-Path: <stefan.lk.hakansson@ericsson.com>
X-Original-To: mmusic@ietfa.amsl.com
Delivered-To: mmusic@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 4B31121F842A for <mmusic@ietfa.amsl.com>; Fri, 23 Nov 2012 03:08:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -5.052
X-Spam-Level:
X-Spam-Status: No, score=-5.052 tagged_above=-999 required=5 tests=[AWL=-1.103, BAYES_00=-2.599, HELO_EQ_SE=0.35, MANGLED_OFF=2.3, RCVD_IN_DNSWL_MED=-4]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 34X0LJmifEPU for <mmusic@ietfa.amsl.com>; Fri, 23 Nov 2012 03:08:39 -0800 (PST)
Received: from mailgw2.ericsson.se (mailgw2.ericsson.se [193.180.251.37]) by ietfa.amsl.com (Postfix) with ESMTP id 3789721F8200 for <mmusic@ietf.org>; Fri, 23 Nov 2012 03:08:39 -0800 (PST)
X-AuditID: c1b4fb25-b7f926d00000661f-6d-50af59351d22
Received: from esessmw0191.eemea.ericsson.se (Unknown_Domain [153.88.253.124]) by mailgw2.ericsson.se (Symantec Mail Security) with SMTP id 2D.5B.26143.5395FA05; Fri, 23 Nov 2012 12:08:37 +0100 (CET)
Received: from [150.132.142.241] (153.88.115.8) by esessmw0191.eemea.ericsson.se (153.88.115.85) with Microsoft SMTP Server id 8.3.279.1; Fri, 23 Nov 2012 12:08:36 +0100
Message-ID: <50AF5934.8010307@ericsson.com>
Date: Fri, 23 Nov 2012 12:08:36 +0100
From: Stefan Hakansson LK <stefan.lk.hakansson@ericsson.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0
MIME-Version: 1.0
To: mmusic@ietf.org
References: <50AF589F.50501@ericsson.com>
In-Reply-To: <50AF589F.50501@ericsson.com>
X-Forwarded-Message-Id: <50AF589F.50501@ericsson.com>
Content-Type: text/plain; charset="ISO-8859-1"; format="flowed"
Content-Transfer-Encoding: 7bit
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFvrJJMWRmVeSWpSXmKPExsUyM+Jvja5p5PoAg+/HFCymLn/M4sDosWTJ T6YAxigum5TUnMyy1CJ9uwSujN3bV7AX3Bat2N79lrmBcadAFyMHh4SAicSn+7pdjJxAppjE hXvr2boYuTiEBE4ySnz98IwZJCEksJZR4ls/E4jNK6At8WLCe3YQm0VAVWLDliOMIDabgI3E 2u4pYDWiAgESi5ecY4eoF5Q4OfMJC4gtIiAsMePtXzYQW1ggSWLVsVlMEPM1Jeav3Q1Wwymg JXH00x1miINMJX5vvQw2n1nAVuLCnOssELa8xPa3c6Bu05V49/oe6wRGwVlI1s1C0jILScsC RuZVjOy5iZk56eVGmxiBwXdwy2/VHYx3zokcYpTmYFES57XeusdfSCA9sSQ1OzW1ILUovqg0 J7X4ECMTB6dUAyPDNgXz2hs3rzsuE1NmY5p+OPl80NuY6W67vz0O/c5VNOmiscb+W9OvJint VODiOfzC8UoKW1tP6R7xsFlWJkc1hL2WrLytdGtpnfeDWQLRGyrerLgy0fmzlUF9mryOyTFh +ekx3pZSE5n/3Ax/5+nzWOm3boXxzkc3hI9XREsmK2VYGt6xUlNiKc5INNRiLipOBABixX6M DAIAAA==
Subject: Re: [MMUSIC] T.38 (Re: M-line philosophy (Re: Wisdom sought: Prioritization of codecs))
X-BeenThere: mmusic@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: Multiparty Multimedia Session Control Working Group <mmusic.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mmusic>, <mailto:mmusic-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mmusic>
List-Post: <mailto:mmusic@ietf.org>
List-Help: <mailto:mmusic-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mmusic>, <mailto:mmusic-request@ietf.org?subject=subscribe>
X-List-Received-Date: Fri, 23 Nov 2012 11:08:40 -0000

Thanks for the clarifications, and I agree to what rtcweb/webrtc should
decide.

What I was implying in my original mail is that I think T.38 support
should not be added to browsers (at least not as part of the
rtcweb/webrtc effort), and there are at least two reasons:

* It is not in any of the use-cases
* You can support store-and-forward FoIP in browsers already

But this discussion should happen in the rtcweb/webrtc space.

Stefan

On 11/22/2012 02:59 PM, Schwarz, Albrecht (Albrecht) wrote:
> Looks like that your are describing T.37 FoIP behaviour, whereas Adam
> did point on T.38 FoIP.
>
> WebRTC should firstly agree
> a) whether fax is part of this conversational realtime multimedia
> service at all,
> and if,
> b) which transport mode via IP.
>
> To a): support of F.185 (Internet fax) Yes/No
> To b):
>      b.1) T.37 FoIP store-and-forward already sufficient Yes/No
>      b.2) T.38 FoIP realtime required Yes/No ((perhaps T.38 over RTP/UDP
> or UDPTL/UDP))
>      b.3) or any alternative to T.38 FoIP realtime Yes/No
>
> NOTE: T.38 would specify the behaviour of the
> 1) PSTN gateway (as "T.38 gateway", which is always a PSTN-to-IP
> gateway) and
> 2) Browser (as "T.38 IAD" (Internet aware fax device))
> in below illustration.
>
> -Albrecht
>
> -----Original Message-----
> From: mmusic-bounces at ietf.org [mailto:mmusic-bounces at ietf.org] On
> Behalf Of Stefan Hakansson LK
> Sent: Donnerstag, 22. November 2012 14:39
> To: mmusic at ietf.org
> Subject: Re: [MMUSIC] T.38 (Re: M-line philosophy (Re: Wisdom sought:
> Prioritization of codecs))
>
> On 11/20/2012 15:56, Adam Roach wrote:
>  >
>  >
>  >    +---------+   +------------+   +---------+
>  >    | Web App |---| SIP Server |---|         |
>  >    +---------+   +------------+   |         | +-------------+
>  >         |                         | PSTN GW |--| Fax Machine |
>  >    +---------+      media         |         | +-------------+
>  >    | Browser |--------------------|         |
>  >    +---------+                    +---------+
>
> For cases when one client is not a proper fax machine, is not the usual
> thing that is done that the facsimile is converted to/from TIFF, JPEG,
> PDF or similar somewhere between that client and the fax machine? (And
> often sent as a mail attachment)
>
> If so, all tools are already available (e.g. File API if you want to
> store/access on the local file system, XHR or WebSockets - or even the
> rtcweb data channel for transport) to build a client that can handle
> fax. (I am probably missing something)
>
> Stefan
>
> _______________________________________________
> mmusic mailing list
> mmusic at ietf.org
> https://www.ietf.org/mailman/listinfo/mmusic