Subject: RE: [Sipping] Question about SIP support for real-time fax

From: David Oliver <[email-masked]>
Date: Fri, 2 Aug 2002 10:29:15 -0500

Eiji and Harsh,

As I understand draft-ietf-sipping-realtimefax-00.txt, the scenarios in
5.2-4 correspond to user agents which act just like traditional fax machines
or phone/fax machine combinations.

At first glance, scenario 5.1 looks as though it would only support SIP-Fax
to SIP-Fax connections. These would be of little use, as fax is successful
because of its universality, and in any case, fax over UDP is an inefficient
way of transmitting documents, compared to, for example, email, ftp or http.
However, in conjunction with an appropriately configured PSTN gateway, a
SIP-only fax machine would be useful. For example, a gateway could be
configured to handle certain incoming numbers as fax only, and attempt to
perform CNG/CED handshake on them, and then route the connection to the SIP
fax machine; if CNG is not received, the GW could be configured to produce a
wrong number message, and then disconnect, route the caller to an automated
attendant or human operator, or attempt to "blind answer" by connecting to
the fax machine.

By the way, it seems that the direction of tones in section 4.1 are reversed
- CalliNG tone (CNG) is sent by the caller (the sender, unless reverse
transmission is requested), and CallED station identification (CED) is sent
by the receiver.

Regards,

David C. Oliver
Principal Engineer
SecureLogix Corp
Email: mailto:[email-masked]
Tel:   210.402.9669
Fax:   210.402.6996 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: Friday, August 02, 2002 5:29 AM
To: Eiji Tomimura
Cc: [email-masked]
Subject: Re: [Sipping] Question about SIP support for real-time fax

Hi  Eiji,

If i may attempt to respond, i think what you've actually tried out is the
scenario in section 5.2
where a voice path has to exist for receiving end to detect the fax tones
and then setup a SIP connection. See section D.2.2.4 of T.38(04/02).

However section 5.1 refers to a case where a voice path does not exist
(only fax) and negotiation  is done by passing relevant information in the
SIP SDP. And therefore, there is no need to allow voice path first for
tones to pass and then detect fax.
(In fact negotiation in both cases is actually done using SIP SDP)

Please see  section D.2.1.1 and D.2.2.3 of ITU T.38 specs(04/02).

Scenario in Section 5.1 does appear to be a valid scenario from T.38
perspective.

Section 4 of the referenced draft says:
"The Internet telephony gateway only supports T.38 real-time
   fax communications (by design or by configuration).  In this case,
   the Internet fax gateway SHOULD initiate the SIP session with T.38
   SDP capabilities (this is typically the case of Internet fax
   terminals, also called Internet-aware fax devices or the case of
   gateways statically configured to support T.38 fax calls only)".

regards
Harsh Bhondwe
hughes software systems

Eiji Tomimura <[email-masked]> on 08/02/2002 01:31:37 PM

To:   [email-masked]
cc:

Subject:  [Sipping] Question about SIP support for real-time fax

Dear all,

I resubmit this question since it has got no answer yet.

A about draft-ietf-sipping-realtimefax-00.txt,

In section 5.1 "Internet fax device  fax only support" call sequence, it
shows a diagram to establish T.38/UDPTL session from the beginning. We
tried
this scenario and realized the following thing:

--
(1) In case both SIP-UA are telephony gateway which are configured to
support fax only, T.38/UDPTL session are established as the section 5.1
represents.

(2) FAX machines tries to negotiate their capability by exchanging CNG and
CED tones.

(3) As T.38/UDPTL session basically doesn't have a capability to pass
through CNG or CED tones, this negotiation fails.

(4) The Calling FAX machine terminate fax call as it cannot get CED
response
from the callee side. Then, FAX fails.

---

So, if FAX machines need CNG/CED exchange to start fax, this call scenario
is not appropriate. Instead, we should always use section 5.2 call
scenario,
which use voice stream to exchange CNG/CED first.

So, my questions is that, is section 5.1 is appropriate from fax machines'
and T.38 session's perspective?

If not, I would like to recommend to remover section 5.1 of
draft-ietf-sipping-realtimefax-00.txt, and allows only the procedure
described in section 5.2.

Regards,
- Eiji Tomimura

--
Eiji Tomimura
Senior Engineer
Systems Technology Dept., Information Technology R&D Laboratories
Sumitomo Electric Industries, Ltd.
Phone: +81-6-6466-5609  Fax: +81-6-6466-5732  Email: [email-masked]

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [email-masked] for questions on current sip
Use [email-masked] for new developments of core SIP

---

From: Eiji Tomimura <[email-masked]>
Date: Sun, 04 Aug 2002 16:39:32 +0900

Hi David,

Thank you very much for your response. I agree with you that scenario 5.1
looks only support  SIP-Fax to SIP-Fax connections. And I also agree that,
if a incoming PSTN gateway perform CNG/CED handshake for receiving fax
machine connecting to it, scenario 5.1 might work.

So, I would like the authors of the draft to clarify the scenario described
in section 5.1. For example,

- scenario 5.1 supports SIP-Fax to SIP-Fax connections, and do not support a
PSTN gateway connecting to traditional fax machine.

- or, if a PSTN gateway applies scenario 5.1, special handling (CNG/CED
handshake between receiving fax machine and the gateway) would be required.

And, I also have another question. If a PSTN gateway, which prefer scenario
5.2 and don't support scenario 5.1, want to reject incoming INVITE with T.38
session request as scenario 5.1, which Response Code should be used? So far,
I could not find appropriate one.

Regards,
- Eiji Tomimura