Subject: Re: [SIP] T.38 fax calls - advertising capabilities and INVITE retransmit

From: Flemming Andreasen <[email-masked]>
Date: Thu, 22 Feb 2001 20:46:58 -0500

Joining in a bit late here, but in any case:

Fundamentally, I don't understand why you view this as two separate media
streams. You are muting one when you want to use the other, so why have two in
the first place ? Also note, that there may be some undesirable QoS interactions
that way.

A couple of more specific comments on the current draft, some of which you may
have already gotten:
- T.30 CED is the same as as V.25 ANS and hence cannot be used as a fax
detection mechanism (the V.21 fax preamble is fine).
- Why must CNG tone detection not lead to a switch to T.38 ?
- SIP call flow should probably include a Contact header resulting in some of
your messages (e.g. ACK) going end-to-end rather than through the proxy).
- Section 4.1 mentions that different UDP ports are to be used where as Section
6.2 lists that as open issue. I agree with Section 6.2 and would leave that
choice to the gateways.

Regards

        Flemming

Jean-Francois Mule wrote:

> Sudipto wrote:
> > Is there a need for the fax enabled gateways to advertise the
> > fax capability & params in the initial INVITE and 200 OK ?
>
> There are 2 possible approaches:
> 1. UA advertises its full capabilities at the beginning of *any* call
> 2. Upon fax detection, the UA initiates a re INVITE with new capabilities
> Unless the Internet Fax gw is a fax terminal dedicated to fax transmissions,
> I would prefer the second approach.  It allows UAs to reject the re INVITE
> with a 415 Unsupported Media Type if t.38 capabilities are not supported and
> it allows the sender of the re INVITE to choose between t.38 fax or fax
> passthrough.
> Also, it could be heavy to advertize t.38 capabilities for all calls (you
> would carry fax-related media attributes in the initial INVITE for all
> calls...).
> So at a general level, I do not believe there is 'a need' for advertizing
> the fax capabilities in the initial INVITE.  The only case would be when the
> SIP UA knows that the call is going to be a fax (sometimes you can smell the
> ink on the paper), for e.g. if it is an IP fax terminal or an analog gw with
> an fxs port connected to a fax machine -- in that case, fine to advertise
> both media capabilities in SDP.
> Any comments on that?
>
> Sudipto wrote:
> > Is there a timing constraint on the use of RE-INVITEs to negotiate
> > the bit-rate and other parameters ? Potentially, the INVITEs could
> > get lost and might need to be retransmitted.
> I would think there is indeed a timing constraint based on the t.30
> protocol.  The T1 timer may be adjusted when the INVITE is for a fax call
> (see sections 10.4.1 and 10.5 of the rfc2543bis-01 draft on T1 and invite).
> Is there a need to add some text on this in the I-D?  Any suggestions?
>
> Thank you for your comments and questions Sudipto.
> Regards,
> Jean-Francois
>
> > -----Original Message-----
> > From: Sudipto Mukherjee [mailto:[email-masked]]
> > Sent: Monday, October 30, 2000 12:26 PM
> > To: Jean-Francois Mule
> > Cc: [email-masked]
> > Subject: Re: [SIP] SIP and T.38 fax calls - Internet Draft
> >
> >
> > Hello Jean,
> >
> > I read through the draft and had a few questions -
> >
> > Is there a need for the fax enabled gateways to advertise the
> > fax capability & params in the initial INVITE and 200 OK ?
> >
> > Is there a timing constraint on the use of RE-INVITEs to negotiate
> > the bit-rate and other parameters ? Potentially, the INVITEs could
> > get lost and might need to be retransmitted.
> >
> > Thanks
> > - Sudipto
> >
> >
> >
> >
> > Jean-Francois Mule wrote:
> > >
> > > A new Internet-Draft has been submitted, dealing with real
> > time fax calls
> > > and SIP: call flows and BCP.
> > >
> > > Comments and suggestions are very much appreciated.
> > > Regards,
> > > Jean-Francois Mule
> > >
> > > -----Original Message-----
> > > From: [email-masked] [mailto:[email-masked]]
> > > Sent: Tuesday, October 17, 2000 3:47 AM
> > > Subject: I-D ACTION:draft-mule-sip-t38callflows-00.txt
> > >
> > > A New Internet-Draft is available from the on-line Internet-Drafts
> > > directories.
> > >
> > >         Title           : SIP T.38 Call Flow Examples And
> > Best Current
> > > Practice
> > >         Author(s)       : J. Mule
> > >         Filename        : draft-mule-sip-t38callflows-00.txt
> > >         Pages           : 19
> > >         Date            : 16-Oct-00
> > >
> > > This document gives examples of SIP call flows for T.38 Internet fax
> > > communications (SIP, the Session Initiation Protocol is defined in
> > > RFC2543 [2] and T.38 is an ITU-T Recommendation [3]).  Elements in
> > > these call flows include SIP User Agents, SIP Proxy Servers, and
> > > Gateways to the PSTN (Public Switch Telephone Network).
> > > This document introduces best current practices for T.38 fax calls:
> > > a call starts with audio capabilities, and, upon fax tone detection,
> > > T.38 fax capabilities are negotiated.  The T.38 fax call scenarios
> > > include the detection of T.38 fax transmission by the receiving
> > > side, or the emitting side, or both (in the latter case, a 'glare'
> > > effect may appear).  The current version of this document only
> > > covers the case when the fax tone is detected by the receiving side
> > > (other cases were left for discussion and may be included in the
> > > future).  Call flow diagrams and message details are shown.  A list
> > > of IANA defined SDP attribute names for T.38 is summarized in
> > > section 5.
> > >
> > > A URL for this Internet-Draft is:
> > >
> http://www.ietf.org/internet-drafts/draft-mule-sip-t38callflows-00.txt
> >
> > Internet-Drafts are also available by anonymous FTP. Login with the
> > username
> > "anonymous" and a password of your e-mail address. After logging in,
> > type "cd internet-drafts" and then
> >         "get draft-mule-sip-t38callflows-00.txt".
> >
> > A list of Internet-Drafts directories can be found in
> > http://www.ietf.org/shadow.html
> > or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> >
> > Internet-Drafts can also be obtained by e-mail.
> >
> > Send a message to:
> >         [email-masked].
> > In the body type:
> >         "FILE /internet-drafts/draft-mule-sip-t38callflows-00.txt".
> >
> > NOTE:   The mail server at ietf.org can return the document in
> >         MIME-encoded form by using the "mpack" utility.  To use this
> >         feature, insert the command "ENCODING mime" before the "FILE"
> >         command.  To decode the response(s), you will need "munpack" or
> >         a MIME-compliant mail reader.  Different MIME-compliant mail
> > readers
> >         exhibit different behavior, especially when dealing with
> >         "multipart" MIME messages (i.e. documents which have been split
> >         up into multiple messages), so check your local documentation on
> >         how to manipulate these messages.
> >
> > Below is the data which will enable a MIME compliant mail reader
> > implementation to automatically retrieve the ASCII version of the
> > Internet-Draft.
> >
> >   ------------------------------------------------------------------------
> >
> >    Part 1.2    Type: message/rfc822
> >            Encoding: 7bit
>
> --
>
> ---------------------------------------------------------------------------
> Sudipto Mukherjee
> Cisco Systems, Inc             [email-masked]
> ---------------------------------------------------------------------------
>
> _______________________________________________
> SIP mailing list
> [email-masked]
> http://lists.bell-labs.com/mailman/listinfo/sip
>
> _______________________________________________
> SIP mailing list
> [email-masked]
> http://lists.bell-labs.com/mailman/listinfo/sip

--
Flemming Andreasen
Cisco Systems

_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementor's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to 
[email-masked] with "subscribe" in the body.

---

From: Flemming Andreasen <[email-masked]>
Date: Thu, 22 Feb 2001 21:31:12 -0500

Oops - responded to the wrong one

Please disregard.

-- Flemming

--
Flemming Andreasen
Cisco Systems