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

From: "Joel Payeur" <[email-masked]>
Date: Thu, 2 Oct 2003 11:15:46 -0400

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

---

From: "Francois Audet" <[email-masked]>
Date: Thu, 2 Oct 2003 14:46:40 -0700

My experience is that the fax receiver should be the one doing the
re-invite, as the inband IP
stream for the tones (especially with non-G.711 codec) is not accurate
enough.

I would strongly recommend the approach where it is always the receiver of
the fax that does 
the re-inviting. 

> -----Original Message-----
> From: Joel Payeur [mailto:[email-masked]] 
> Sent: Thursday, October 02, 2003 08:16
> To: Sipping (E-mail); Jean-Francois Mule (E-mail)
> 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.
> 
> 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?
> 
> 
> Use [email-masked] for questions on current 
> sip Use [email-masked] for new developments of core SIP
>

---

From: "Joel Payeur" <[email-masked]>
Date: Wed, 8 Oct 2003 08:42:19 -0400

Francois,
 
    The reason why we stopped using the receiver approach is that in some scenarios where we were the fax sender, the third party remote reInvited us twice in about 1 second, once in PCM, then in T38.
 
This behavior was strange,  and it did not fit well with our DSP code.  We were not in a position to argue with the other vendor, so we changed our code so that the sender reInvites before the receiver has time to confuse our DSP code.  This was ugly, but it got the work done.
 
Thanks for your reply!
 
Joel

 -----Original Message-----
From: Francois Audet [mailto:[email-masked]]
Sent: Thursday, October 02, 2003 17:47
To: Joel Payeur; 'Sipping (E-mail)'; 'Jean-Francois Mule (E-mail)'
Subject: RE: [Sipping] Questions on fax (T38) renegotiation

My experience is that the fax receiver should be the one doing the re-invite, as the inband IP 
stream for the tones (especially with non-G.711 codec) is not accurate enough. 

I would strongly recommend the approach where it is always the receiver of the fax that does 
the re-inviting. 

> From: Joel Payeur [ mailto:[email-masked]]

---

From: "Joel Payeur" <[email-masked]>
Date: Wed, 8 Oct 2003 08:45:44 -0400

Sharath,

Thanks for the tip, but sadly, since my goal is interop, and i really can't know what each vendor will do in any given situation, i don't think any of us can come up with a solution in the current state of the fax renegotiation practice.  I believe that the answer may lie in standardizing this.

I'll start another thread, maybe shorten my question, i was hoping for the authors to answer.

Thanks!

Joel

> From: [email-masked] [mailto:[email-masked]]
> Sent: Monday, October 06, 2003 4:35
> To: Joel Payeur
> Cc: Sipping (E-mail); Jean-Francois Mule (E-mail)
> Subject: Re: [Sipping] Questions on fax (T38) renegotiation
> 
> 
> 
> 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:
> can't find any
> reference to my actual problems, so here goes.
> 
> T.38 03/2002,
> there is no strong statement about who should be doing the 
> reinviting upon
> fax detection.
> 
> You decide on
> a strategy that best suits your DSP/SIP capabilities, and 
> implement that.
> 
> hardware limitations,
> and uses its own strategy. I've even seen gateways that 
> actually reInvite
> for PCM for a second before reInviting for T38.
> 
> 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.
> 
> 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.
> 
> 1- When getting a 486 response, find a good scheme for retrying, for
> example "sender only retries after x seconds".
> 
> 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
>

---

From: "Joel Payeur" <[email-masked]>
Date: Wed, 8 Oct 2003 13:53:28 -0400

Thanks. 491 does seem to be the answer to my current problem.  However i still feel that the BCP does not guide implementors well enough.

Funny that you should say that you prefer anyone INVITEs.

In an earlier mail Francois Audet said that 

"I would strongly recommend the approach where it is always the receiver of the fax that does 
the re-inviting."

Maybe we should take the time to improve the BCP, (in fact maybe stop calling it BCP), and give a clear indication on which strategy MUST be used, complete with WHY.

I've also noticed that there is no T38 design team on the sipping web page
http://www.softarmor.com/sipping/teams/index.html

Anybody know why?

Joel

> From: Lyons, Terry [mailto:[email-masked]]
> Sent: Wednesday, October 08, 2003 12:38
> To: Joel Payeur
> Seem to me this is a misreading of RFC 3261:
> 
> 	The crossing INVITEs will of course yield back
> 	crossing "486 Busy" 's and the renogotiation fails.
> 
> You should respond 491 instead.
> Then there's a procedure to resolve the glare.
> 
> Anyone INVITEs is the preferred solution.
> 
> - [email-masked] +1 732 625-3003 x212
> 
> 
> Sent: Thursday, October 02, 2003 11:16 AM
> 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.
> 
> 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?
> 
>