Subject: Re: [Sipping] Questions on fax (T38) renegotiation

From: [email-masked]
Date: Mon, 6 Oct 2003 03:35:21 -0500

Hi Joel,
      Like you said most implementations use the "anyone INVITEs" strategy,
       and because of timing issues you might end up with a glare case.
      Take a look at sections 14.1/14.2 of Rfc 3261, It talks about using
the
      "491 request pending" or a "500 Internal server error" to handle such
cases,
      In case of 491 it makes use of a retrying scheme,something
      similar to what you proposed.

thanks
-Sharath

"Joel Payeur" <[email-masked]>@ietf.org on 10/02/2003 09:45:46 PM

Sent by:    [email-masked]

To:    "Sipping (E-mail)" <[email-masked]>, "Jean-Francois Mule (E-mail)"
       <[email-masked]>
cc:
Subject:    [Sipping] Questions on fax (T38) renegotiation

Hi all,

i've been browsing the implementors and sipping lists and can't find any
reference to my actual problems, so here goes.

Has anyone had problems with the fact that in both
draft-ietf-sipping-realtimefax-01.txt (now expired) and ITU T.38 03/2002,
there is no strong statement about who should be doing the reinviting upon
fax detection.

In realtimefax, Section 4.1

   Two possible ways exist for an Internet telephony gateway to detect
   a facsimile communication:

   1. On the emitting gateway (the one sending the facsimile document),
   the T.30 calling tone (CNG) is detected.  The CNG tone is however an
   optional signal [7];
   2. On the receiving gateway, the V.21 Preamble flag sequence is
   detected.  The Preamble is always present and follows the called
   station identification tone (CED) when CED is present.
   Note that even though the CED tone may be detected on the receiving
   gateway, since the fax CED tone is similar to V.25 ANS modem tones,
   it SHOULD NOT be used to trigger the fax switchover.

   In conclusion, several conditions can trigger fax detection.
   Internet telephony gateways supporting T.38 real-time facsimile MUST
   support the detection of fax transmission on the V.21 Preamble flag
   sequence; Internet telephony gateways MAY support the detection of
   fax on CNG tone.  The authors recommend that a facsimile
   transmission SHOULD be detected on the receiving Internet telephony
   gateway.

Interoperating with your own software is always pretty easy.  You decide on
a strategy that best suits your DSP/SIP capabilities, and implement that.

The problem is that each gateway vendor has different hardware limitations,
and uses its own strategy. I've even seen gateways that actually reInvite
for PCM for a second before reInviting for T38.

Trial and error have led us to use a "sender INVITEs only", then "receiver
INVITEs only" and finally "anyone that detects the fax INVITEs" strategies.
Each had its problems that we encountered when doing interop testing with
other vendors.

We've seen that most vendors use the "anyone INVITEs" strategy.  That's
cool, but there is a lingering problem with this strategy.  Someties a
certain timing can be achieved in which both endpoints will detect the fax
at about the same time, and both will INVITE the other.  The crossing
INVITEs will of course yield back crossing "486 Busy" 's and the
renogotiation fails.

I was wondering how T38 implementors have dealt with this particular issue.
I was thinking of either:

1- When getting a 486 response, find a good scheme for retrying, for
example "sender only retries after x seconds".

2- Since the remote's detection of the fax happens because the RTP path is
still open while negotiation takes place, perhaps i should stop sending RTP
while renegotiating.

3- In a next update of the draft-ietf-sipping-realtimefax, make it
mandatory for one of the two (sender, receiver) to do the reInviting.  This
way we wouldn't need to support every possible combination.

Of course, for method 1 there is the drawback that we don't know the
remote's strategy, and it could yield a flurry of crossing reinvites.
Method 2 may also break because sometimes a part of the fax noise will
creep in the RTP path before the fax is actually detected by the DSP, which
may be just enough so the remote detects it.

Any thoughts?

BTW, what's the status on draft-ietf-sipping-realtimefax, can we expect a
new revision soon?

Joël

_______________________________________________
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