Subject: RE: Request for information on using T.30/T.37/T.38 with SIP/SDP /RTP

From: [email-masked]
Date: Fri, 3 Nov 2000 13:32:19 -0600

James,

Your comments below are absolutely correct and are appreciated.

In my desire to keep my request for information short, I mis-used the terms
simply to give what I hoped was a short but perhaps not completely accurate
context for my request. Let me clarify.

As you state, T.30 is relevant only to faxes transmitted over the PSTN. By using
that term, I just wanted to indicate that my request for information had
something to do with faxes.

And as you state, T.37 is for fax MIME attachments. Our store-and-forward fax
and universal messaging systems can receive T.37 attachments for faxes to be
sent over the PSTN and can generate T.37 attachments for faxes received from the
PSTN. Again, I just wanted to indicate that my request had something to do with
faxes.

I apologize if my mis-use of these terms misled anyone.

And again as you state, T.38 as currently defined only uses TCP and UDPTL, not
RTP, as transport protocols, and SIP/SDP establishment of such sessions is
already standardized or is proposed.

While we certainly believe that TCP and UDPTL are useful transport protocols for
T.38, and we support them, we also see use for RTP as a transport protocol for
T.38. We have a proprietary implementation of that which we would like to see
standardized if others also find it useful. Doing so would require two things:
o    defining a T.38 payload type for RTP: and
o    defining SDP tokens to describe that.
Here specifically is one place where I was looking for information on anyone
that has already done work in this area or is interested in doing so. I think
this work might appropriately be done within the IETF FAX working group, but I
might be wrong. If so, I'm open to suggestions for where it should appropriately
be done.

The one other area that we are also looking for work already done or folk
interested in doing work is the use of Class 2.0 fax, as defined, e.g., by
EIA/TIA-578, -592, -602, etc., over TCP as an alternative to T.38 over any
transport protocol. Class 2.0 fax over TCP is already supported by many of our
products and the products of other vendors, but the establishment of sessions
between fax servers and PSTN gateways using Class 2.0 fax over TCP is handled by
non-standard, proprietary schemes. Again, we would like to standardize this so
that, in particular, SIP can be used to establish such sessions and multiple
vendors products can better interwork. In this case, the protocols are all
defined, all that is needed is a few SDP tokens. I think this work also might
appropriately be done within the IETF FAX working group, but am open to other
suggestions.

I hope this clarifies my original request. Anyone already working in these areas
or interested in doing so please contact me by e-mail. If anyone is interested,
perhaps we can get together informally in San Diego in a few weeks to discuss
this further.

Thank you in advance for your attention to this.

Jim Renkel
Director, Advanced Technology and System Engineering
3Com Carrier Networks Business

James Rafferty <[email-masked]> on 10/27/2000 12:58:41 PM

Sent by:  James Rafferty <[email-masked]>

To:   James Renkel/MW/US/3Com
cc:
Subject:  RE: Request for information on using T.30/T.37/T.38 with SIP/SDP/ RTP

James,

Hi.   I'm the former chair for the WG.    This request is somewhat
off topic for this list, but I'll give you a brief answer.  I've
been involved in all of the work referenced in the ITU and IETF.

See my comments below:

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]]
> Sent: Friday, October 27, 2000 12:33 PM
> To: [email-masked]
> Subject: Request for information on using T.30/T.37/T.38 with
> SIP/SDP/RTP
>
>
>
>
> The 3Com Carrier Networks Business System Engineering group
> is working on
> extending and integrating some of our products to achieve
> greater functionality
> and better interworking in the areas of store-and-forward and
> real-time
> facsimile transmission. Products in this area include
> facsimile applications
> systems and PSTN-Internet interworking gateways.
>
> Does anyone know of any work that has been done or is being
> done or anyone that
> has done or is doing work in the areas of:
> o    specification of T.30/T.37/T.38 payload formats for RTP
> and other transport
> protocols;
this is mixing apples and oranges. Briefly,

1.  T.30 is the PSTN protocol and needs to be supported for PSTN
fax support in products like gateways to IP; no direct connection
here to RTP, which is on the packet side.

2.   T.37 is an umbrella standard for store and forward Internet fax
where images are sent as MIME attachments (image/tiff) and the transport
is SMTP/ESMTP ; again, no connection to RTP; all of the technical details
are included in RFC 2301-2306; RFC 2530-2532, which are referenced by T.37
(my personal web site , www.humancomm.com, has some of this kind of
info on the About Internet fax link)

3.   T.38 is the standard for sending fax data in real time over packet
networks.
Instead of using RTP, the fax data and signals use packet methods which are
specified
in the ITU-T T.38 recommendation.   T.38 has annexes specifying operation
with H.323 and (recently approved) with SIP.   I believe the annex for use
with Megaco/H.248 is up for approval at next month's ITU-T SG16 meeting in
Geneva.

At Brooktrout, we do enabling technology for voice, fax and data over IP and
PSTN networks, so we are staying plugged in to all of the related standards
developments.

I hope this helps.   Please feel free to follow up if needed.

Regards,

James Rafferty

* -----------------------------------
James Rafferty
Senior Product Manager, IP Telephony
[email-masked]

Brooktrout Technology
410 First Avenue
Needham, MA 02494 USA
Phone:  +1-781-433-9462
Fax: 781-433-9268
www.brooktrout.com
Your Hook into the New Network(SM)

> and
> o    specification of the above media stream types in SDP/SIP.
>
> Any information you have on this would be greatly
> approciated. Thank you in
> advance for your attention to this.
>
> Jim Renkel
> Director, Advanced Technology & System Engineering
> 3Com Carrier Networks Business
>
>

---

From: Herman Silbiger <[email-masked]>
Date: Fri, 03 Nov 2000 16:17:11 -0500

James_R,

If you are interested in gettin T.38 amended to support RTP the that would have to
be done in ITU Study Group 16, which now is responsible for facsimile.  The next
meeting of SG16 is 13-17 November in Geneva so ypu can't put a contribution in to
that.  The best thing will be to take it to TR30.5, the successor group to TR29.

The new chair of TR29 is Jim Dahmen, [email-masked].

Herman Silbiger

---

From: Don Mactaggart <[email-masked]>
Date: Fri, 03 Nov 2000 20:13:28 -0500

I strongly support a good look at RTP, and am willing to put it forward at
Geneva under
headings 1.1 and 3.1 of my TD to SG16. I was going to put a specific
reference to RTP,
but didn't know enough about its performance - and still don't.    --- Don

>> I hope this helps.   Please feel free to follow up if needed.

ITU - Telecommunication Standardization Sector      Temporary Doc 

Study Group 16
______________

Geneva, 13-17 November 2000

Question: fax/16

Source: Canada

Title: Review of Recommendation T.38 in Q4/SG8 and suggestions arising.

1. Abstract:

As the Study Group 8 alumni join Study Group 16, a review of some of the 
events  related  to real time fax-over-IP, and to the present  state  of 
ITU-T Recommendation T.38, may be useful. These events are summarized in 
the following section, and lead to the conclusions in this abstract:

1.1 TCP/IP should not be used, since T.30 session integrity can only  be 
    maintained  by extreme spoofing, which increases the  total  session 
    duration to a degree which is commercially unsupportable. This  also 
    applies to any other form of error correction by retransmission.

1.2 The  raw uncorrected error rate of the international  Internet  does 
    not support a viable T.30-based facsimile service.

1.3 Therefore,  to provide a real time international  facsimile  service 
    over  the  Internet, some form of forward error correction  must  be 
    implemented. For reasonable bandwidth consumption on the IP path and 
    acceptable quality of service, a greater degree of error  correction 
    is  required for facsimile control fields than for image  data,  and 
    this is easily implemented in practice since there is less FCF data.

1.4 With the characteristics indicated in paragraph 1.3, a viable public 
    international  fax-over-public-IP  service can be  implemented,  and 
    was.  No  alternative public FOIP service has been  implemented  and 
    documented, at time of writing.

1.5 The  present  text of Recommendation T.38(98) does not  resolve  the 
    above  issues at all, and certainly not in a manner explicit  enough 
    to   define  an  international  service  interoperable   between   a 
    multiplicity  of  implementors and service providers, as  is  to  be 
    expected of a viable ITU Recommendation.

1.6 The  above relates to the body of Recommendation T.38 e.g. the  FOIP 
    communication   process;  call  establishment  procedures  are   not 
    addressed in this contribution.

contact: Don Mactaggart, CyberFax Canada            tel: +1 514 485 1908
                                                    fax: +1 514 485 6321
                                                e-mail: [email-masked]
                                - 2 -

2. History of fax-as-data services: FoGSTN, FoX.25, FoIP

2.1 FoGSTN: 

In  the  beginning of G3 facsimile, the data service accessible  to  the 
non-expert  public  with worldwide reach was the GSTN, as  seen  through 
APSK modems. Economy of scale, utility and ease of access were such that 
telex  was effectively  superseded in the 1985 to 1988 period.  Creation 
of message material was consistent with office procedure; sending it was 
comparable with GSTN or telex: dial number, press start.

The fax=phone transport equation suited many service providers, but  not 
all,  often for regulatory reasons as well as technical ones. Among  the 
technical reasons was that fax could tolerate satellite delay with  ease 
and data errors with difficulty, the reverse being true for speech.

Thus  a  technical  or  business case, or  both,  was  made  in  several 
jurisdictions  for a differentiated G3 fax service, for as much  of  the 
path  as made economic sense, albeit always terminating in  the  already 
dominant constituency of fax terminals, on a legacy "analog" path:

2.1.1 CNCP FacsRoute - Canada (1988)

      Initially, a store & forward fax service was provided over an X.25 
      data network, and presented to the market with all the traditional 
      "value added" arguments; it peaked at $2 million revenue and 2,000 
      subscribers.  A  year  later  the  regulator  allowed  real   time 
      FacsRoute,  which attracted $40 million and 50,000 subscribers  of 
      the  300,000 fax terminals then in Canada, doing so in  9  months. 
      Real  time FacsRoute was provided over a 64kbit/s bypass GSTN  via 
      "voice busters" which cut the dialed connection after a cumulative 
      70 seconds of speech per call: a remarkably "value subtracted" way 
      of  bringing a transcontinental 64kbit/s service to market, but  a 
      20-fold increase in business over the S&F FacsRoute Plus.

2.1.2 FaxStream - Telecom Australia

      Provided assured 64 kbit/s access and intercity trunk  connection. 
      FaxStream  and FacsRoute are believed to be the pioneer  dedicated 
      fax long distance services.

2.1.3 Mercury SureFax - United Kingdom

      When the access default was reversed to make real time SureFax the 
      default,  and  store & forward SureFax Plus  the  option,  traffic 
      increased 20-fold. Similar experiments by different  experimenters 
      seem to come up with 5% for S&F market share every time.

2.1.4 Hong Kong Tel - 002+ IDD Fax

      Provided a way of using excess satellite capacity, with the useful 
      added value of differentiating fax traffic on the monthly bill.
                                   - 3 -
 
2.2 FoX.25 (1990+)

By 1990, a GSTN circuit had evolved conceptually from 4kHz of  bandwidth 
to  64kbit/s  of data. Facsimile bits were being  transported  in  great 
numbers  at 9600 bit/s on 64 kbit/s channels for reasons of  convenience 
and  history;  X.25/X.75  was the then-established  way  of  statistical 
multiplexing of digital data. Thus begat ITU Recommendation X.38. In its 
way,  X.38 was a technically successful operation, but the  patient  has 
not survived:

2.2.1 Error correction by retransmission: required extreme spoofing; not       
      much point in halving the tolls if the calls take twice as long.

2.2.2 Accounting  rates for public data service: negated  the  technical 
      accomplishment  of  exploiting the fact that shared  services  are 
      more effective for all.

***   And so, the few X.38/X.25 FoX.25 services that survived did so on
      dedicated leased circuits.

***   And  the good news: X.38 defined the intergateway  interface  well 
      enough  that  the  only change needed to  make  two  independently 
      developed  gateways  interoperable  was a reversal  of  bit  order 
      within an octet.

2.3   FOIP - T.38 and CyberFax (1997+)

2.3.1 A 5-country, 1-channel switched network was built as a feasibility 
      demonstration:  Canada, Israel, Singapore, Sri Lanka, USA.  Either 
      TCP,  or UDP with a proprietary retransmission protocol  could  be 
      used. Frame size was large: 500 octets; call duration increase was 
      therefore  relatively  high, since retransmission  of  an  errored 
      frame  took  a  while. Performance and utility  were  adequate  to 
      proceed to a commercialisation phase.

2.3.2 Results  were tabled June 1997 as TD CM-008 in a Q4/8  meeting  in 
      Costa  Mesa, California, USA, and the T.ifax questions  to  become 
      T.37 and T.38 were created there.

2.3.3 May 1998, commercial FOIP service was launched out of Johannesburg 
      with  offramp  in  New York, followed in the  next  18  months  by 
      offramps  in Fort Lauderdale, Hong Kong, Montreal,  Guangzhou  and 
      Hong Kong, and onramps in Cape Town, Durban, Pretoria,  Guangzhou, 
      Beijing, Shanghai, Bangkok and Singapore. 
                                  - 4 -

3.    Conclusions, Lessons Learned:

      The  implementation  in 2.3.1 above was made  with  a  proprietary 
      superset  of Recommendation T.38. The extensions to T.38(98)  were 
      outlined  but  not explicitly defined in  SG8/D.223  (Geneva,  Feb 
      2000) and in GMD-20 (Gaithersburg, Maryland, June 2000), and are:

3.1   Minimize  spoofing;  therefore avoid use of  error  correction  by 
      retransmission (don't use TCP);

3.2   Selective redundancy; more error protection on FCFs than on  image 
      data.

***   and, to make T.38 truly useful:

3.3   Define  an  efficient forward error correction  algorithm  with  a 
      modest  increase in data rate yet capable of spanning at least  10 
      consecutive missing or errored IP frames;

3.4   Finally: make the intergateway protocol explicit and  unambiguous, 
      favouring solutions proven in service on the public Internet.

                               _________________