Support of T.38 fax by SIP/SDP

["Glenn Parsons" <[e-mail]>]

Folks,

As you may know, Real-time internet fax has been defined in T.38 by
ITU-T Study Group 8.  The group is currently defining call establishment
using SIP and Megacop/H.248 (both with SDP).

In March of this year a draft was proposed taking into account
draft-ietf-mmusic-sdp-t38-00.txt (which has now expired).  Since MMUSIC
is responsible for SIP & SDP, SG8 agreed to send this to the MMUSIC WG
for comments.  However, I don't see it in the archives so perhaps our
chair sent it to the chairs and authors.

To promote wider comment, I am sending this message that contains the
liaison and the draft text.  The Word versions of these can be found at:

ftp://standards.nortelnetworks.com/itu_to_ietf/SG8/March99/

Some key guidance that SG8 is looking for is whether MMUSIC has a
preference for the SDP work to be documented in an Annex to T.38 (since
it is specific to T.38) or in a new RFC (since it is in extension to
SDP).

Study Group 8 meets again September 20-24.

I look forward to your comments.

Cheers,
Glenn.


=======================================




     ITU - Telecommunication Standardization Sector   Temporary Document
0121

     STUDY GROUP 8



     Geneva, 24 March - 1 April 1999


         QUESTION: 4/8

         SOURCE*:  T.38 Ad Hoc Group

         TITLE:    Draft Communication on T.38 Support in SDP

                                   _____________

                                   COMMUNICATION

         TO:       IETF MMUSIC WG

         APPROVAL: (Proposed) Agreed to at March 1999 meeting

         FOR:      Action

         DEADLINE: September 1999


         CONTACT:  Glenn Parsons              Tel:         [phone]
7582
                                              Fax:  [phone]
                                              Email:

[e-mail]


         Introduction

     ITU-T Study Group 8 is the lead Study Group on facsimile.  SG8 has
reviewed
     the proposal <draft-ietf-mmusic-sdp-t38-00.txt> describing the
support of
     Rec. T.38 by SDP and SIP.  SG8 has determined the basic
modifications
     suggested in this proposal are essentially correct n that is, no
changes
     are currently required in SIP but some additions are needed in
SDP.  We
     have expanded the technical details of this proposal specifically
for SDP
     and included them below.

     We would like to inform you that we are currently working on a
draft Annex
     to Rec. T.38 that would support call establishment using SIP &
MGCP.  As

     this work develops, we may require additional SDP or SIP
enhancements.  We
     have attached our current draft for your information and comment.

     We would appreciate your guidance on the appropriate documentation
of the
     SDP enhancements described below.  Besides registration with IANA,
should
     we document them as in the attached draft Annex, in a short RFC
extension
     to SDP, or in the next revision to SDP?


     T.38 SDP Modifications



     As described in section 4 of <draft-ietf-mmusic-sdp-t38-00.txt>,
the
     Session Description Protocol (SDP) provides mechanisms for
describing
     sessions.  Revisions are required to support description of a fax
session.
     The revisions can be included in the next version of SDP or
published as a
     separate document.  The information that needs to be represented in
SDP to
     support Rec. T.38 is:

        1.
           The fact that T.38 is to be used
           Specifically, section 5.1 should include "fax" or "image" as
a media
           type and "T38" as a format type.
           Further, section 6 Media Announcements should indicate that
"image"
           is a valid "media" type (first field).  The media types are
defined
           as being the top level MIME types.  As such, "image" (as in
           image/tiff used in Rec T.3) is the logical choice for
facsimile. (as
           opposed to application or data)

        2.
           Ability to use either TCP or UDP for transport protocol
           Specifically, section 6 Media Announcments should indicate
TCP
           (transmission control protocol) as a valid transport value
(third
           field).  This will also require the registration of "TCP"
with IANA
           as a valid name for the "proto" type per the procedure noted
in
           Appendix B of SDP (RFC 2327).
           Additionally, section 6 Media Announcments should include
"t38" as a
           valid format type value (fourth field).  As this is not an
RTP
           defined value it has to be a MIME sub-type of the media
type.  As a
           result, this will require the registration of "image/t38"
with IANA
           as a valid MIME content-type per the procedure noted in
Appendix B
           of SDP (RFC 2327).  Note that this content-type is consistent
with
           other fax content types (e.g., image/tiff, and image/g3fax)

        3.
           Negotiation of error control to be used by T.38 as well as
other
           capabilities
           Specifically, new attributes (section 6 Attributes) must be
defined
           for each of the following capabilities (from Annex B of Rec.
T.38)
           that must be negotiated before the T.38 session can
progress.  These
           will require the registration of the following with IANA as
valid
           att-field and att-value values per the procedure noted in
Appendix B
           of SDP (RFC 2327).  These capabilities are defined in ABNF:

             Maximum Bit Rate
                Att-field=maxBitRate
                Att-value = 1*(DIGIT)
             Data Rate Management Method
                Att-field=T38facsimileRateMgmnt
                Att-value = localTCF | transferredTCF
             Fill Bit Removal
                Att-field=fillBitRemoval
             MMR & JBIG Transcoding
                Att-field=transcoding
                Att-value=MMR | JBIG
             Maximum Buffer Size
                Att-field=t38facsimileMaxBuffer
                Att-value = 1*(DIGIT)
             Maximum Datagram Size
                Att-field=t38facsimileMaxDatagram
                Att-value = 1*(DIGIT)
             Version
                Att-field=t38Version
                Att-value = 1*(DIGIT)
             Error Control
                Att-field=t38errorControl
                Att-value = UDP_FEC | UDP_Redundancy

                Note that with the error control capability, support of
the
                redundancy method is mandatory and use of FEC is
optional.

     An example of the SDP message could be the following:
               v=0
               o=faxgw1 2890844526 2890842807 IN IP4 128.59.19.68
               s=FAX message
               e=[e-mail]
               t=2873397496 0
               c=IN IP4 128.59.19.68
               m=image 49170 udp t38
               a=T38facsimileRateMgmnt:transferredTCF
               a=t38errorControl:UDP_FEC



     Attachments:

                    Proposed Annex C, Rec. T.38
                Proposed Appendix III, Rec. T.38
                                 ___________________




=======================================





     ITU - Telecommunication Standardization Sector   Temporary Document
0118

     STUDY GROUP 8



     Geneva, 24 March - 1 April 1999


     Question:4/8


     SOURCE*: T.38 Ad Hoc Group

     TITLE:   PROPOSED NEW ANNEX C TO REC. T.38

                                 __________________

                     MGCP/SIP/SDP Call Establishment Procedures



     1    Introduction

     This Annex describes system level requirements and procedures for
internet-
     aware facsimile implementations and internet aware facsimile
gateways
     conforming to Rec. T.38 to establish calls with other Rec. T.38
     implementations using the procedures defined by MGCP, SIP & SDP.


     2    Communication between  facsimile terminal and gateway

     Communication between a sending Group 3 facsimile terminal and the
incoming
     gateway is generally effected using dialup procedures over the
PSTN. Basic
     and optional T.30 procedures are supported.  The support for V.34
is for
     further study.

     The gateway may receive the facsimile transmission from the calling

     terminal as a modem signal on the PSTN if the gateway supports a
direct
     dial-in procedure.  Where the gateway is located within the network
it may
     receive the transmission in the form of a PCM encoded digital
channel.
     Internet aware facsimile (IAF) implementations are connected
directly to
     the IP network and act as a gateway for call establishment.

     2.1  Transfer of addressing information

     The conveyance of the Rec. E.164 address of the called terminal
from the
     calling terminal to the emitting gateway may be by manual
procedures using
     prompts; by means of double dialling; or by any other suitable
means

     3    Communication between gateways

     3.1  Overview

     3.1.1Call Setup

     Call setup for Rec. T.38 Annex C compliant implementations is based
on SIP
     defined in IETF RFC 2543 and MGCP defined in IETF RFC XXXX.  As in
Annex B,
     Rec. T.38 implementations may operate in two distinct compatible
     environments.

          1.
            A facsimile-only over IP environment. In this environment,
no voice
            support is provided.  The procedures and requirements of
section
            3.2.1 of this Annex shall apply to implementations operating
in
            this environment.

          2.
            A facsimile and voice over IP environment. The procedures
and
            requirements of section 3.2.2 of this Annex shall apply to
            implementations operating in this environment.

     3.1.2Media Channels

     Rec. T.38 facsimile packets are sent on a separate TCP/UDP port
from
     MGCP/SIP call signalling (TCP).  A minimal T.38 Annex B
implementation
     requires a TCP port for call signalling and either a UDP port or a
TCP port
     for Rec. T.38 facsimile information.

     3.2  Basic Call Setup

     According to RFC2543 section 1, SIP supports a five phase of
establishing
     and terminating a call:


        User location: determination of the end system to be used for

             communication;

        User capabilities: determination of the media and media
parameters to

             be used;

        User availability: determination of the willingness of the
called

             party to engage in communications;

        Call setup: "ringing", establishment of call parameters at both

             called and calling party;

        Call handling: including transfer and termination of calls.



        SIP can also be used in conjunction with other call setup and

        signaling protocols. In that mode, an end system uses SIP
exchanges

        to determine the appropriate end system address and protocol
from a

        given address that is protocol-independent. For example, SIP
could be

        used to determine that the party can be reached via H.323 [7],
obtain

        the H.245 [8] gateway and user address and then use H.225.0 [9]
to

        establish the call.



        SIP can invite users to sessions with and without resource

        reservation.  SIP does not reserve resources, but can convey to
the

        invited system the information necessary to do this.

     3.2.1Fax Only Connection

     Digits are collected by the media gateway (MG) and sent to the
calling
     agent to invite the called party.

     Upon detection of CNG by the media gateway (MG), the calling agent
is
     informed (via MGCP) of this event and requests that the connection
be
     changed to T.38 fax (per the SDP of section 3.3).  This can be done
in two
     ways:

          1.      If the Call Agent controls both MGs, then MGCP is used
to
             modify the existing connection between the two MGs

          2.      If different call agents are involved, then the
on-ramp call
             agent sends a SIP INVITE request (with the same call-id as
the
             voice connection) for a T.38 session.  On confirmation, the
on-
             ramp call agent instructs its media gateway (via MGCP) to
initiate
             a T.38 session with the off-ramp MG.

     3.2.2Voice and Fax Connection

     Digits are collected by the media gateway (MG) and sent to the
calling
     agent to invite the called party.

     A SIP INVITE is made to the called party requesting a voice
connection per
     the requirements of RFC 2543.

     Upon detection of CNG by the media gateway (MG), the calling agent
is
     informed (via MGCP) of this event and requests that the connection
be
     changed to T.38 fax.  As per section 3.2.1

     Upon completion of the fax call (T.38 completion) by the off-ramp
media
     gateway (MG), the calling agent is informed (via MGCP) of this
event and
     requests that the connection be reverted to voice.

     3.3  Capabilities Negotiation

     There are several options that need to be negotiated to determine
which
     options the gateways support and use.  These are described in Table
B-
     1/Rec. T.38

     The Session Description Protocol (SDP) - RFC 2327 provides
mechanisms for
     describing sessions for SIP and MGCP. However, new attributes
(section 6 of
     SDP) are required to support Rec. T.38.  Specifically, the
following will
     be registered with IANA as valid att-field and att-value values per
the
     procedure noted in Appendix B of SDP (RFC 2327). These capabilities
are
     negotiated using the following ABNF elements defined for use with
T.38:


             Maximum Bit Rate

                Att-field=maxBitRate

                Att-value = 1*(DIGIT)

             Data Rate Management Method

                Att-field=T38facsimileRateMgmnt

                Att-value = localTCF | transferredTCF

             Fill Bit Removal

                Att-field=fillBitRemoval

             MMR & JBIG Transcoding

                Att-field=transcoding

                Att-value=MMR | JBIG

             Maximum Buffer Size

                Att-field=t38facsimileMaxBuffer

                Att-value = 1*(DIGIT)

             Maximum Datagram Size

                Att-field=t38facsimileMaxDatagram

                Att-value = 1*(DIGIT)

             Version

                Att-field=t38Version

                Att-value = 1*(DIGIT)

             Error Correction

                Att-field=t38errorControl

                Att-value = UDP_FEC | UDP_Redundancy

               Note that with the error control capability, support of
the
               redundancy method is mandatory and use of FEC is
optional.



     3.3.1 Declaration of T.38 in SDP


     Rec. T.38 is indicated by the image/t38 content type in SDP.


     This choice is consistent with image/tiff used in Rec. T.37 and
image/g3fax
     used for Rec. X.420.

     3.3.2 Use of either TCP or UDP

     Two logical channels (sender to receiver channel and receiver to
sender
     channel) shall be opened for the transfer of T.38 packets. T.38
packets can
     be transferred using either TCP or UDP. In general, the usage of
TCP is
     more effective when the bandwidth for facsimile communication is
limited,
     or for IAF to IAF transfers since TCP provides flow control. On the
other
     hand, the usage of UDP may be more effective when the bandwidth for

     facsimile communication is sufficient.

     Note that during the SIP call setup, the calling party suggests the

     transport (TCP or UDP) but the called party choses.

     In support of T.38 choice of UDP or TCP transport, SDP extensions
are
     required to:

          . indicate TCP (transmission control protocol) as a valid
transport
            value (third field).  This will also require the
registration of
            TCP with IANA as a valid name for the proto type per the
procedure
            noted in Appendix B of SDP (RFC 2327).

          . include t38 as a valid format type value (fourth field).  As
this
            is not an RTP defined value it has to be a MIME sub-type of
the
            media type.  As a result, this will require the registration
of
            image/t38 with IANA as a valid MIME content-type per the
procedure
            noted in Appendix B of SDP (RFC 2327).

     3.4  Examples of Call Setup

     3.4.1  Fax only invite

     For a two party call between T.38 gateways:

          C->S: INVITE sip:[e-mail] SIP/2.0
               Via: SIP/2.0/UDP kton.bell-tel.com
               From: A. Bell <sip:[e-mail]>
               To: T. Watson <sip:[e-mail]>
               Call-ID: [e-mail]
               CSeq: 1 INVITE
               Subject: Mr. Watson, here is a fax
               Content-Type: application/sdp
               Content-Length: ...

               v=0
               o=faxgw1 2890844526 2890842807 IN IP4 128.59.19.68
               s=Mr. Watson, here is a fax
               e=[e-mail]
               t=2873397496 0
               c=IN IP4 128.59.19.68
               m=image 49170 udp t38
               a=T38facsimileRateMgmnt:transferredTCF
               a=t38errorControl:UDP_FEC

          S->C: SIP/2.0 200 OK
               ...



     Others TBD

     3.5  Minimum Call Setup Messages

     The Annex C implementation shall support the minimum requirements
for a SIP
     client and server as defined in RFC 2543 section A.1 and A.2:



        All clients MUST be able to generate the INVITE and ACK
requests.

        Clients MUST generate and parse the Call-ID, Content-Length,

        Content-Type, CSeq, From and To headers. Clients MUST also parse
the

        Require header. A minimal implementation MUST understand SDP
(RFC

        2327, [6]). It MUST be able to recognize the status code classes
1

        through 6 and act accordingly.



        A minimally compliant server implementation MUST understand the

        INVITE, ACK, OPTIONS and BYE requests. A proxy server MUST also

        understand CANCEL. It MUST parse and generate, as appropriate,
the

        Call-ID, Content-Length, Content-Type, CSeq, Expires, From, Max-

        Forwards, Require, To and Via headers. It MUST echo the CSeq and

        Timestamp headers in the response. It SHOULD include the Server

        header in its responses.



     3.6  Mapping of Call Progress Signals

     For call setup and call progress the return signals can be
simplified to
     the following set.  These are all returned prior to or instead of a
200 OK
     response to the INVITE request.



                 Meaning             SIP Response Mapping

        Busy1.  Subscriber busy    486 Busy here
        tone as defined in ITU-T
        Recommendation Q.35.

        Busy2.  Sometimes          486 Busy here
        referred to as
        Distinctive Busy on some
        PABX models.

        Congestion busy as         600 Busy everywhere
        defined in ITU-T Rec.
        Q.35.

                 Meaning             SIP Response Mapping

        Ring1. Ringing tone as     180 Ringing
        defined in ITU-T
        Recommendation Q.35. This
        is an intermediate call
        progress indicator.  It
        can be used to generate a
        ringback signal to the
        originating G3FE as if it
        there were an end-to-end
        PSTN connection.

        Ring2. Ringing tone        180 Ringing
        similar to Ring1 where
        two short rings are
        generated instead of one
        long ring.  This is an
        intermediate call
        progress result.

        SIT Intercept.  Special    503 Service Unavailable
        Information Tones are
        defined in ITU-T
        Recommendation Q.35.
        Intercept Tone is one
        combination of tones -
        frequency and duration.

        SIT Vacant. Special        503 Service Unavailable
        Information Tones are
        defined in ITU-T
        Recommendation Q.35.
        Circuit Vacant Tone is
        one combination of tones
        - frequency and duration.

        SIT Reorder. Special       503 Service Unavailable
        Information Tones are
        defined in ITU-T
        Recommendation Q.35.
        Reorder Tone is one
        combination of tones -
        frequency and duration.

                 Meaning             SIP Response Mapping

        SIT No Circuit. Special
        Information Tones are
        defined in ITU-T
        Recommendation Q.35. No
        Circuit Tone is one
        combination of tones -
                                   503 Service Unavailable
        frequency and duration




        Note: SIT tones are not distinguished because it generally
indicates a
        problem with the number to dial

       The 200 OK message in response to an INVITE request is returned
when the
       gateway, by some means, determines that a connection to the
terminal
       G3FE has been established.  If CED or FSK flags are detected, the

       appropriate Rec. T.38 messages can be sent.

     3.7  Usage of the MaxBitRate in messages

     When TCP is used for T.38 fax transmission, maxBitRate does not
apply.
     When UDP is used for T.38 fax transmission, maxBitRate usage in SIP
is TBD.

     3.8  DTMF transmission

     MGCP supports collection of DTMF digits to make a call.  SIP can
transfer
     these DTMF digits as a SIP URL as defined in RFC 2543 section 2:

          sip:[e-mail];user=phone

     DTMF transmission during an established voice and fax connection is
for
     Further Study.

     3.9  Interoperability

     Both SIP and Rec. T.38 Annex B require a well known port to
initiate call
     signalling. As described in SIP, its well-known port is 5060.  Rec.
T.38
     Annex C endpoints shall use the SIP well-known port. In order for a
single
     implementation (such as a gateway) to support multiple endpoints,
dynamic
     ports must be used.

     4    References

     The following references should be added to Section 2 of Rec. T.38


     SIP: Session Initiation Protocol - Proposed Standard
          http://www.ietf.org/rfc/rfc2543.txt

     SDP: Session Description Protocol  - Proposed Standard
          http://www.ietf.org/rfc/rfc2327.txt

     MGCP: Media Gateway Control Protocol - Internet Draft in initial
discussion
          http://
www.ietf.org/internet-drafts/draft-huitema-megaco-mgcp-v0r1-
     05.txt

                                 ___________________