Subject: RE: [SIP] T.38 fax calls - advertising capabilities and INVITE re transmit

From: Jean-Francois Mule <[email-masked]>
Date: Mon, 30 Oct 2000 16:05:53 -0800

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