Subject: Re: [sipcore] [dispatch] FW: I-D Action:draft-jones-sip-forum-fax-problem-statement-00.txt

From: Gonzalo Salgueiro <[email-masked]>
Date: Mon, 4 Jan 2010 16:59:51 -0500

I agree with Eric's comments. The need for this is very real and there  
are serious deficiencies with fax transport using SIP that need to be  
addressed.  The work by the SIP Forum FoIP TG will provide the needed  
identification, investigation and possible resolution to these  
problems. I propose we forge ahead with publication of this draft as  
an informational RFC. Please provide any input on this draft so  
progress can continue to be made on this.

Gonzalo

On Jan 3, 2010, at 9:59 AM, Eric Burger wrote:

> Looking at this discussion in its entirety, I have to admit to what  
> might be a retro-verso conclusion. The arguments against fax (a  
> legacy technology that is 50 years OLDER than voice) have the  
> identical characteristic of those who said real-time IP  
> communications would never work. Cannot guarantee anything, only a  
> best-effort network, no one would want to use it. Blah, blah, blah.
>
> Really folks: there is a real need, a real market, and a promising  
> solution space. If *you* do not want to work on it, because ATM is  
> really the technology of the gods, great. However, there are others  
> who are working on it, so please either help out or create those  
> 5-10-year-out technologies that really will replace fax.
>
>
> On Dec 29, 2009, at 2:22 AM, Dean Willis wrote:
>
>> Paul Kyzivat wrote:
>>> I know this is a bit off topic, and doesn't alleviate the problem,  
>>> but has anybody ever proposed that an INVITE with offer for fax be  
>>> responded  to with a 3xx containing a mailto: URI? Or that ENUM  
>>> for a fax device yield a mailto uri?
>>
>> I was going to say "redirect to T.37, since real-time fax over VoIP  
>> is just a bad idea" but Paul beat me to it.
>>
>> Seriously: fax over IP really only works when the real-time  
>> conversion is done close to the edge of the IP network. and the  
>> core transit is store-and-forward/ The close to the consumer edge,  
>> the better. Trying to retrofit the timing equirements of fax onto  
>> RTP is an exercise in futility for those who don't understand the  
>> concept of lossy networks.
>>
>> --
>> Dean
>>
>>
>> _______________________________________________
>> dispatch mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/dispatch
>
>

---

From: Dean Willis <[email-masked]>
Date: Mon, 4 Jan 2010 18:38:23 -0600

>> concept of lossy networks.

Do not misunderstand. I'm not saying one can't do fax reliably over  
IP. I'm saying that it's much easier to do if one converts the circuit- 
modulated fax signal to something IP friendly at the edge of the IP  
network, then converts it back at the far edge if necessary.

Sometimes tunneling protocols makes sense. However, tunneling a very  
time-sensitive protocol over a temporaly looser protocol is generally  
a bad idea. The RT in RTP may be Real Time, but in the absence of some  
troublingly large buffering and redundant transmission overhead, fax  
over RTP just isn't Real Timely.

If we take a step back and re-assess the requirements, we're likely to  
end up with a very different architecture than we get from trying to  
carry fax-squawk-sounds in real time over the net.

For example, why can't we just put a T.37 gateway into every ATA? The  
answer has to do more with the inability to map user-supplied  
destination phone numbers into email-style addresses than it has to do  
with the limitations of DSP, processor, and memory in those ATA boxes.  
Oddly enough, this is exactly the same phone-number transformation  
problem we're arguing about in general SIP work, and it probably has  
the same kind of answer.

Another approach would be to use a T.37-like transport that uses a  
more SIP-friendly addressing schema. Fax over MSRP? Fax over XMPP?   
Both are imminently doable, and the general approach seems quite  
obvious. It also gives a closer-to-real-time feel to the resulting fax  
transmission than seems toe be the case with whole-document store-and- 
forward technologies.

--
Dean

---

From: "Paul E. Jones" <[email-masked]>
Date: Wed, 6 Jan 2010 16:18:26 -0500

Folks,

We've had a number of exchanges and some people have missed a few messages
as the thread bounced around two lists.  I'm sending this to both sipcore
and dispatch so that people do not miss the discussion.

The question before us is whether we want to publish the SIP Forum Fax
Problem statement as an informational RFC or not.  The purpose of the
document is to highlight the problems with fax, but does not attempt to
propose a solution.

It is believed that fax is an essential business tool and we must address
identified issues.  How we address the issues is not a subject of this
document, but work will continue in the SIP Forum for some time.  Perhaps
once the work is progressed, then some output document might get presented
to the IETF and/or ITU.  What the final solution looks like, of course, will
not be dictated by the SIP Forum, as it's not an SDO.

I believe there is benefit in publishing the document just to keep the
process as open as possible and encourage participation in the solution
process.

Is there any disagreement to presenting this document to the RFC Editor and
IESG for publication?

Paul

---

From: Dean Willis <[email-masked]>
Date: Thu, 7 Jan 2010 23:37:16 -0600

> Is there any disagreement to presenting this document to the RFC  

No disagreement; it seems harmless enough as a document, and useful as  
a reference about the problem. Were I in a position of other than  
(im)moral authority, I might suggest that "Area Director sponsored  
individual draft on the informational track" is the way to go.

No working group needed, no charters, etc. Just get a gullible AD to  
sign up, and away you go!

http://tools.ietf.org/html/draft-iesg-sponsoring-guidelines-02

--
Dean

---

From: "Paul E. Jones" <[email-masked]>
Date: Fri, 8 Jan 2010 00:51:33 -0500

"AD Sponsored submissions represent a significant workload to the IESG."

As if Cullen does not have enough to do.

Paul

> -----Original Message-----
> From: Dean Willis [mailto:[email-masked]]
> Sent: Friday, January 08, 2010 12:37 AM
> To: Paul E. Jones
> Cc: [email-masked]; [email-masked]
> Subject: Re: [dispatch] [sipcore] I-D Action:draft-jones-sip-forum-fax-
> problem-statement-00.txt
> 
>

---

From: Dean Willis <[email-masked]>
Date: Fri, 8 Jan 2010 00:09:06 -0600

> "AD Sponsored submissions represent a significant workload to the  

If the document is well enough drafted that it doesn't create a lot of  
work for the AD, then there isn't that much extra work.

One can also use an external document shepherd to make sure the doc is  
really "IESG ready" before the AD gets deeply into it. PaulK would be  
good at this ;-).

Besides, Cullen needs more work to do.

--
Dean

---

From: "Paul E. Jones" <[email-masked]>
Date: Fri, 8 Jan 2010 01:27:14 -0500

> Besides, Cullen needs more work to do.

So, Paul K. and Cullen should each be made aware that you've given them an
assignment.  They'll thank you at the next meeting. ;-)

Paul

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 08 Jan 2010 09:18:41 -0500

> assignment.  They'll thank you at the next meeting. ;-)

I'll wait to see if Cullen wants me to take it.

And I don't suppose I will thank dean at the next meeting because it 
seems I don't get to go to meetings any longer.

	Thanks,
	Paul

---

From: Gonzalo Camarillo <[email-masked]>
Date: Thu, 14 Jan 2010 13:52:41 +0200

Hi,

> and dispatch so that people do not miss the discussion.

that is why we do not want people to cross-post to multiple lists and 
that is also why Dean, showing great wisdom (as usual ;o) ), removed one 
of the lists from the cc: when following up. Things can get confusing 
between lists and people subscribed to both get a lot of duplicate 
messages. In the future, please stick to only one list.

Thanks,

Gonzalo
DISPATCH and SIPCORE co-chair