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

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

On Jan 3, 2010, at 8: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.
>>

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: Dean Willis <[email-masked]>
Date: Tue, 5 Jan 2010 00:44:16 -0600

On Jan 4, 2010, at 3:59 PM, Gonzalo Salgueiro wrote:

> 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.
>

Note that I've dropped SIPCORE off the list, and left DISPATCH in the  
loop, as that seems to be the appropriate place.

So here's the question:

Does " fax transport using SIP" really mean "fax transport using RTP  
as negotiated by SIP"  to you?

Otherwise said: I think it is vital that we find a way to send fax  
using SIP. I don't think using RTP/UDP to encode  frequency-keyed  
audio tones that encode the fax is ever going to work very well. The  
physics are against us, and it seems needlessly complex to try and  
work around physics when we could use a different encoding and not  
have the problem.

--
Dean

---

From: "Kevin P. Fleming" <[email-masked]>
Date: Tue, 05 Jan 2010 07:14:51 -0600

Dean Willis wrote:

> 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.

T.37 *is* whole-document store-and-forward, so I find this paragraph a
bit confusing. I think the biggest concern with all store-and-forward
mechanisms is the lack of 'accountability' at the sender's end; if the
sender is using a physical FAX machine to send, and their machine tells
them the FAX was sent 'OK', they (rightly or wrongly) presume that to
mean the recipient's FAX machine has the FAX (it may not have been
printed yet, but it's there). Store and forward breaks that assumption,
and it means that the FAX may not actually arrive at the recipient's
machine/address for quite some time, or it may not arrive at all. Just a
simple incorrect destination number entry can result in confusion on the
sender's part, because they think the FAX was delivered, only to find
out later (maybe a day later) that it was not delivered because they
fudged up the telephone number.

Store and forward has its place, and personally I only send real-time
FAX when the recipient demands it, but I don't see how we can put a
store-and-forward technology in the path of real-time FAX and expect the
persons at the endpoints to accept it.

-- 
Kevin P. Fleming
Digium, Inc. | Director of Software Technologies
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
skype: kpfleming | jabber: [email-masked]
Check us out at www.digium.com & www.asterisk.org

---

From: "Kevin P. Fleming" <[email-masked]>
Date: Tue, 05 Jan 2010 07:17:05 -0600

Dean Willis wrote:

> Does " fax transport using SIP" really mean "fax transport using RTP as
> negotiated by SIP"  to you?

Well, right now it actually means 'FAX transport using UDPTL as
negotiated over SIP/SDP', as very few endpoints use RTP, but the effect
is the same.

> Otherwise said: I think it is vital that we find a way to send fax using
> SIP. I don't think using RTP/UDP to encode  frequency-keyed audio tones
> that encode the fax is ever going to work very well. The physics are
> against us, and it seems needlessly complex to try and work around
> physics when we could use a different encoding and not have the problem.

T.38 doesn't send audio tones over RTP/UDPTL, it sends demodulated HDLC
data bitstreams and control signals. The receiver of T.38 media streams
does not need to do any DSP work to extract the digital data from the
stream. However, the T.30 FAX timing issues are still present as you've
pointed out.

---

From: <[email-masked]>
Date: Tue, 5 Jan 2010 14:39:56 +0100

>> Does " fax transport using SIP" really mean "fax transport using RTP
as

>> Otherwise said: I think it is vital that we find a way to send fax
using
> stream. However, the T.30 FAX timing issues are still present as
you've

We did some tests with T.38 and found that the software quality of T.38
implementations leaves much to be desired. If it works, it works very
well. But

---

From: <[email-masked]>
Date: Tue, 5 Jan 2010 14:51:17 +0100

Ok, that accidental key combination initiates sending of mail..

Next try:

We did some tests with T.38 and found that the software quality of T.38
implementations leaves much to be desired. If it works, it works very well.
But it just doesn't work often enough.

I like Dean's idea looking at fax as some kind of interactive
file transfer between two users, as in XMPP or MSRP.

After occasionally dealing with fax problems since 1995, my conclusion is
that the only way to solve them is to make the possesion of such devices
illegal :-)

Regards,

Wolfgang Beck

--
Deutsche Telekom Netzproduktion GmbH 
Zentrum Technik Einführung 
Heinrich-Hertz-Straße 3-7, 64295 Darmstadt 
+49 61516282832 (Tel.) 
http://www.telekom.com 

Deutsche Telekom Netzproduktion GmbH 
Aufsichtsrat: Timotheus Höttges (Vorsitzender) 
Geschäftsführung: Bruno Jacobfeuerborn (Vorsitzender), Albert Matheis, Klaus Peren 
Handelsregister: Amtsgericht Bonn HRB 14190 
Sitz der Gesellschaft: Bonn 
USt-IdNr.: DE 814645262

Erleben, was verbindet.

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 05 Jan 2010 09:26:47 -0500

> fudged up the telephone number.

I agree there is some increased comfort level that the fax has been 
"received", but it may not be at all justified. You can screw up the 
phone number as well as the email address. I suppose the assumption is 
that most phone numbers don't identify fax machines, so a screwed up 
number is more likely to fail than to deliver a fax to an unexpected 
place. But that only covers a certain class of number screwups. 
(Choosing the wrong preprogrammed number in your fax machine will still 
give you confidence that your fax has been delivered.)

But none of those concerns is relevant if sip is used to establish the 
initial path, and *then* some other mechanism than RTP is used to 
transmit the fax content.

That would be true if it were fax-over-MSRP, fax-over-XMPP, or if the 
response to the sip invite were a 3xx to a mailto URI. In all cases you 
would have confidence that you at least had contacted a device that was 
prepared to receive your communication.

Fax-over-MSRP or fax-over-XMPP would have the added comfort of a 
confirmation of delivery of the entire content.

I agree with Dean that RTP has some "physics" problems. Specifically, 
RPT is designed with the assumption that it is better for packets to be 
dropped than to arrive late. But that is an incorrect assumption for 
fax. RTP over a reliable transport would be another way to solve this 
problem.

	Thanks,
	Paul

---

From: "Richard Shockey" <[email-masked]>
Date: Tue, 5 Jan 2010 13:10:18 -0500

>  > sender's part, because they think the FAX was delivered, only to
>  find out later (maybe a day later) that it was not delivered because they
>  "received", but it may not be at all justified. 

It is the principal issue that fax users expect. "It got there..my machine
tells me so." Plus my service provider has a record. Sure you can fat thumb
any communications technology that requires human input for addressing.

We've had store and forward solutions for years, that was what the old IETF
FAX WG documented and they have not gained any significant market acceptance
principally for this issue. We cannot ignore the "perceived" requirements
for realtime confirmation.

Paul I'm sorry. What you propose would work but would never deploy. I wish
there was a globally deployed ENUM service available that would make this
problem go away but ..well you know what happened there. I personally
thought the IETF Internet Print Protocol would work but that didn't deploy
either for reasons I can discuss over beer. 

You can screw up the
>  _______________________________________________
>  dispatch mailing list
>  [email-masked]
>  https://www.ietf.org/mailman/listinfo/dispatch

---

From: Dean Willis <[email-masked]>
Date: Tue, 5 Jan 2010 15:56:43 -0600

I've spliced together two of Kevin's astute responses below.

On Jan 5, 2010, at 7:14 AM, Kevin P. Fleming wrote:

>> more

True. There are training issues, although I'll note that we did deploy  
a very well-accepted store-and-forward fax system (that predated T.37)  
at JCPenney back in the early 90's. So there are user-interface  
aspects of real-time FAX that need to be preserved. However, this  
doesn't justify a requirement to maintain T.30 timing end-to-end.

> stream. However, the T.30 FAX timing issues are still present as  

Most of the Linkys customers I worked with a few years ago were  
actually trying to do fax over G.711 RTP/UDP, and wondering why it  
occasionally didn't work. Personally, I thought the interesting part  
was that it occasionally worked.

But I'm also not a big fan of systems that rely on gratuitous  
retransmission of data over UDP in order to compensate for loss, which  
is what we typically do when T.38 is carried over UDP, which it  
typically is because of reported problems maintaining T.30  
synchronization over a TCP retransmission sequence. I personally don't  
understand this problem, so I must be missing some information. I  
understand bad PCM timer synch in cheap gateways, but that's not a  
problem we can do much about without just saying "Implement T.30  
correctly in your gateway!"

However, I think we can get somewhere in-between "whole-document store  
and forward" and real-time T.30 by using buffered transmission over a  
reliable transport. Let's tentatively call this "streaming FAX" to  
differentiate it from "T.37 store and forward" and "T.38 real-time  
FAX" (or the more abhorent FAX over G.711, aka FAX/RTP or "G.711 pass- 
through") I suppose this would be an alternative to T.38 over TCP, and  
as I noted, I'm a little fuzzy on why T.38 doesn't seem to be widely  
used over TCP, so analyzing this would be useful.

What I have in mind is using SIP to route and negotiate a transport  
session. Both MSRP and XMPP have potential use at the transport layer,  
although MSRP is probably easier to get one's head around, given that  
we already have OMA doing file-transfer in a SIP mediated session  
using MSRP.  The originating node (assuming it knows in advance it's a  
FAX call and not a midstream conversion) would negotiate the transport  
stream in its initial INVITE. This gets us through the "did I call a  
real FAX destination?" question, although it won't do much if the user  
just entered a wrong FAX number that happens to actually have a  
listening machine. Following this, the CITTg3/g4 data is just streamed  
through the transport to the other end, which buffers and spits it out  
as it can. We might also need a "receive buffer full" indicator for  
larger transmissions.

If the node is a gateway, it needs to do all the tricky T.30 things to  
maintain transmission pacing and keep the antique fax machines on the  
end happy. We might also have requirements to do mid-call FAX  
detection and reINVITE to switch from voice to "streaming fax"  
midsession. And we have all the usual CNG "calling tone" awareness  
issues, although these (as is pointed out in Paul's draft) could be  
somewhat mitigated by better capability negotiation practices at the  
SIP level.

What we get is something like a T.37 scenario, except it doesn't need  
phone-number to email-address conversion directories, and it doesn't  
use SMTP relay agents, and it has some semblance of end-to-end FAX  
awareness, and it preserves the end-user experience of T.30. But it  
doesn't have the same network intolerance as T.38, can reduce the  
actual bandwidth required by as much as 5x from T.38 (use of TCP  
instead of FEC), re-uses existing encapsulation transforms (the TIFF  
imaging of T.37, on a page-by-page basis), and re-uses existing  
reliable transport protocols (MSRP or XMPP).

Admittedly, this is a different scope than just making recommendations  
on fixing T.38, but it might well be easier to make work in the long  
run.

Here's a corollary: Young people are moving away from SMTP-based email  
and onto IM and social networks for very good reasons having to do  
with both admissions policy and latency. Perhaps we should allow FAX  
to evolve similarly?

--
Dean

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 05 Jan 2010 19:22:29 -0500

I just skimmed the T.38 spec, and see that it does define use of TCP as 
the transport. But the examples of sip call setup don't show how to do 
that - probably because it wasn't defined at the time. Comedia is 
sufficiently defined now that it should be possible to set up a T.38 
over TCP session using sip. Has that been considered? If so, why isn't 
it up for discussion?

	Thanks,
	Paul

Dean Willis wrote:
> True. There are training issues, although I'll note that we did deploy a 
> very well-accepted store-and-forward fax system (that predated T.37) at 
> JCPenney back in the early 90's. So there are user-interface aspects of 
> real-time FAX that need to be preserved. However, this doesn't justify a 
> requirement to maintain T.30 timing end-to-end.
> 
> Kevin also said:
> 
> Most of the Linkys customers I worked with a few years ago were actually 
> trying to do fax over G.711 RTP/UDP, and wondering why it occasionally 
> didn't work. Personally, I thought the interesting part was that it 
> occasionally worked.
> 
> differentiate it from "T.37 store and forward" and "T.38 real-time FAX" 
> (or the more abhorent FAX over G.711, aka FAX/RTP or "G.711 
> pass-through") I suppose this would be an alternative to T.38 over TCP, 
> and as I noted, I'm a little fuzzy on why T.38 doesn't seem to be widely 
> although MSRP is probably easier to get one's head around, given that we 
> already have OMA doing file-transfer in a SIP mediated session using 
> MSRP.  The originating node (assuming it knows in advance it's a FAX 
> call and not a midstream conversion) would negotiate the transport 
> end happy. We might also have requirements to do mid-call FAX detection 
> and reINVITE to switch from voice to "streaming fax" midsession. And we 
> have all the usual CNG "calling tone" awareness issues, although these 
> (as is pointed out in Paul's draft) could be somewhat mitigated by 
> better capability negotiation practices at the SIP level.
> 
> phone-number to email-address conversion directories, and it doesn't use 
> SMTP relay agents, and it has some semblance of end-to-end FAX 
> doesn't have the same network intolerance as T.38, can reduce the actual 
> bandwidth required by as much as 5x from T.38 (use of TCP instead of 
> FEC), re-uses existing encapsulation transforms (the TIFF imaging of 
> T.37, on a page-by-page basis), and re-uses existing reliable transport 
> protocols (MSRP or XMPP).
> 
> on fixing T.38, but it might well be easier to make work in the long run.
> 
> and onto IM and social networks for very good reasons having to do with 
> both admissions policy and latency. Perhaps we should allow FAX to 
> evolve similarly?
> 
> 
> -- 
> Dean
> 
>

---

From: "Kevin P. Fleming" <[email-masked]>
Date: Tue, 05 Jan 2010 18:38:32 -0600

> over TCP session using sip. Has that been considered? If so, why isn't

To my knowledge, none of the problems identified by the SIP Forum TG to
date have involved media transport issues (except for discussions about
being able to support secure FAX, which will likely be predicated on
DTLS-SRTP becoming an RFC first). Nearly every issue to be worked on
relates to incorrect/improper interpretations of the T.38
recommendation, or lack of specification of required behaviors for
endpoints in situations that weren't accounted for in the recommendation.

While discussion of (possibly) better transport of T.30 data is not
outside the scope of the TG, it is not a 'pain point' that endpoint
implementors, carriers or users have identified as something that needs
work at this time.

---

From: Paul Kyzivat <[email-masked]>
Date: Tue, 05 Jan 2010 20:04:46 -0500

> implementors, carriers or users have identified as something that needs

That's interesting. So are you thinking what you need is a BCP and/or 
Use Cases document to show people how to do it? Or an IETF successor to 
the ITU T.38 document, that is more precise yet backward compatible?

	Thanks,
	Paul

---

From: "Paul E. Jones" <[email-masked]>
Date: Wed, 6 Jan 2010 04:34:36 -0500

Paul,

TCP has been there forever, but few actually implemented it.  I'm not sure
why, but I guess folks felt UDP was easier?  In any case, UDPTL is so
entrenched, it's not coming out anytime soon.  The only thing that might
drive change is SRTP, which gives the benefit of using RTP (vs. UDPTL) and
security.

Paul

> -----Original Message-----
> From: Paul Kyzivat [mailto:[email-masked]]
> Sent: Tuesday, January 05, 2010 7:22 PM
> To: Dean Willis
> Cc: Kevin P. Fleming; Paul E. Jones; [email-masked]
> Subject: Re: [dispatch] [sipcore] FW: I-D Action:draft-jones-sip-forum-
> fax-problem-statement-00.txt
> 
> find
> actually
> FAX"
> we
> detection
> use
> actual
> with

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 06 Jan 2010 10:29:18 -0500

> drive change is SRTP, which gives the benefit of using RTP (vs. UDPTL) and

"Easier" in that it is more-or-less already done for RTP. (Using T.38 
over RTP would be easier yet I presume.)

Using TCP isn't intrinsically hard. Once the connection is established 
it should be a lot easier. But I suppose the issues of establishing the 
connection in the context of sip media connection establishment is 
unfamiliar.

The obvious win is that you have a reliable connection. I only skimmed 
T.38. I gathered that for UDP there is provision for forward error 
correction by redundant sending of data. But I didn't see any mechanism 
for actively detecting and reporting errors due to loss of packets. Did 
I just miss that? If packets are lost, so that the recipient gets 
incomplete data for the fax, then what happens?

But if nobody sees a problem with data unreliability with T.38 over UDP, 
then I guess there is no motivation to fix it for that.

	Thanks,
	Paul

---

From: "Kevin P. Fleming" <[email-masked]>
Date: Wed, 06 Jan 2010 09:37:36 -0600

> incomplete data for the fax, then what happens?

The T.30 protocol itself has provisions at multiple layers for error
detection (and optionally correction). The next layer up would be HDLC
(since the data being transferred is really HDLC frames), and the
receiver would calculate an HDLC FCS over the received data in a frame,
find that it does not match what the sender said it was supposed to be,
and likely cause an immediate abort of that page transmission so that it
can restart. This is my understanding without being much of a T.30
expert, though... just based on what I've learned from inspecting packet
traces.

This mechanism is already in place because T.30 over TDM networks can
also experience data loss/corruption, and must have a method to
compensate for it.

---

From: "Paul E. Jones" <[email-masked]>
Date: Wed, 6 Jan 2010 14:46:17 -0500

Paul,

> incomplete data for the fax, then what happens?

There is the option of FEC and redundancy.  If enough packets are lost so
that data is lost, then it's lost: there is no means of recovering that in
T.38.  There is no feedback mechanism in UDPTL.
 
> then I guess there is no motivation to fix it for that.

Data loss is a problem.  I just don't think it is as much of a problem in
practice as other problems -- particularly timers.  I would assume that,
since people are not expressing a lot of concern over packet loss, is that
the redundancy is good enough.  I would assume that if the network is so bad
that redundancy does not address packet loss issues then the network is also
too poor for voice, too.

In all of my investigations related to fax problems, packet loss was rarely
a problem and lossy networks get fixed.

Paul

---

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: "Elwell, John" <[email-masked]>
Date: Thu, 7 Jan 2010 11:56:40 +0100

+1

John

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Paul E. Jones
> Sent: 06 January 2010 21:18
> To: [email-masked]; [email-masked]
> Subject: Re: [dispatch] [sipcore] I-D 
> Action:draft-jones-sip-forum-fax-problem-statement-00.txt
> 
> Folks,
>

---

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

> 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: "Kevin P. Fleming" <[email-masked]>
Date: Fri, 08 Jan 2010 11:07:56 -0600

> the ITU T.38 document, that is more precise yet backward compatible?

We will likely produce two results: a set of contributions to ITU SG16
for consideration to be included in the next version of the T.38
recommendation, and a BCP-type document showing implementors the right
way to implement it. That document will likely be published by the SIP
Forum, but could also become an informational RFC since its content will
be highly SIP and SDP specific.

---

From: Gonzalo Salgueiro <[email-masked]>
Date: Fri, 8 Jan 2010 12:43:48 -0500

> be highly SIP and SDP specific.

I think another informational RFC would be appropriate to bookend the issues with a problem statement and solution implementation.

Gonzalo

---

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

---

From: Cullen Jennings <[email-masked]>
Date: Wed, 27 Jan 2010 09:22:27 -0700

I'm trying to think about what we want to accomplish by publishing this draft as an RFC. I was very happy to read the draft and think there is some good stuff in it.  

The draft contains a mixture of things. Partially it is a liaison to IETF from sipforum about what they are up to with a sipform work group. This is great to get but I don't think there is much long term need to record that in RFC form. The more important part to publish IMHO is documenting some issues, problems, deficiencies and/or bugs in some IETF specifications that are leading to lack of interoperability in deployments. That type of problem statement would be great information to get written down in a concrete form that allows the appropriate WG to go fix the problems. 

I do realize fax works by using protocols from multiple SDOs and that does complicate things. I think it would be beneficial to document specific problems found with IETF protocols. I'm less interested in the IETF publishing problems with some other SDOs protocols.  You've caught me at a particularly sensitive time having just spend 1/2 my time for the last several months dealing with the IETF relationships with other SDOs. And if anyone mentions royalty free fax algorithms my head might explode :-)

So what I am getting at is could we move this draft more towards something that documents what is observed in real world deployments and discuss the problems with the existing IETF protocols, then WG Last Call it in the appropriate WG(s) (I'm assuming things like mmusic, fecframe, perhaps avt) and publish it as informational? The goal of publishing it would be to provide a problem statement for future work in theses WG.  

Does that make sense to people? Reasonable path forward? I'm open to other ideas but whatever we do, I would want to understand why publishing whatever document we published was going to help make things work better. And on that note, I'd like to express many thanks to SIP Forum and all the people who worked on this effort for helping get fax working better.

Cullen

PS - Paul, thanks for trying to make less work and Dean, as punishment for your sins I'm nominating you for AD to the next Nomcom :-) 

On Jan 7, 2010, at 11:27 PM, Paul E. Jones wrote:

> sipcore mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/sipcore

---

From: "Paul E. Jones" <[email-masked]>
Date: Mon, 1 Feb 2010 02:17:11 -0500

Cullen,

> I'm trying to think about what we want to accomplish by publishing this
> draft as an RFC. I was very happy to read the draft and think there is
> some good stuff in it.

As an informational RFC, the objective would be nothing more than to
document the issues that have been identified.  It does not try to address a
problem, but merely raise awareness to issues in a manner similar to many
other Informational RFCs over the years.
 
> The draft contains a mixture of things. Partially it is a liaison to
> IETF from sipforum about what they are up to with a sipform work group.

You're right.  I think we should change some of the wording, especially the
abstract.  The intent it not to be a liaison document, but it is intended to
report on current state of affairs to the Internet community.

> This is great to get but I don't think there is much long term need to
> record that in RFC form. The more important part to publish IMHO is
> documenting some issues, problems, deficiencies and/or bugs in some
> IETF specifications that are leading to lack of interoperability in
> deployments. That type of problem statement would be great information
> to get written down in a concrete form that allows the appropriate WG
> to go fix the problems.

The challenge, I suppose, is that there are no IETF documents that we can
fault.  There have been Internet Drafts written in the past that provide
inaccurate information.  Perhaps they didn't at the time, but they have been
implemented by vendors.

Having said that, the reason for wanting to publish this in the IETF is that
there are a number of SIP devices that implement T.38 and problems exist in
many of those implementations.  It's not a fault of SIP, but it is believed
that there is value in providing this information to those developers.  It
would also be of benefit to those deploying equipment.

Longer-term, it would only serve as a historical record in much the same way
many Informational RFCs do.
 
> I do realize fax works by using protocols from multiple SDOs and that
> does complicate things. I think it would be beneficial to document
> specific problems found with IETF protocols. I'm less interested in the
> IETF publishing problems with some other SDOs protocols.  You've caught
> me at a particularly sensitive time having just spend 1/2 my time for
> the last several months dealing with the IETF relationships with other
> SDOs. And if anyone mentions royalty free fax algorithms my head might
> explode :-)

We already have one: it's called PDF over SMTP. ;-)

I understand your point.  The issue is that, while some problems are
inherent in T.38, there is a bigger issue and perhaps a "lesson to be
learned" here: the Internet and gateways into legacy technology do not
always fit well together.  Some of the problems with T.38 have to do with
timers expiring due to multiple hops between IP network and PSTN network
segments, for example.

While this is not IETF technology, it's not all technology of any SDO.  Fax
issues have been something of joint interest by folks in both the ITU and
IETF.  I recall folks actively working on this in both organizations in 1998
and 1999.  More than a decade later, we see all of these issues with SIP
networks that are now being deployed.

One day, this will all be behind us.  It will either be when the last PSTN
GW is dismantled and buried, or when we all switch to something like the
above mentioned royalty-free IP-based document transmission system. ;-)
Until then (or perhaps as a driver for), we need to document the issues.  We
also need to take steps to try to resolve them and, ideally, some folks in
the IETF will help bring about change.
 
> So what I am getting at is could we move this draft more towards
> something that documents what is observed in real world deployments and
> discuss the problems with the existing IETF protocols, then WG Last
> Call it in the appropriate WG(s) (I'm assuming things like mmusic,
> fecframe, perhaps avt) and publish it as informational? The goal of
> publishing it would be to provide a problem statement for future work
> in theses WG.

I think we can remove some of the text that makes it sound too much like a
liaison, but I don't think we can highlight issues with existing IETF texts
and I don't think it would be appropriate to drive this through a WG to
produce a standards-track document.
 
> Does that make sense to people? Reasonable path forward? I'm open to
> other ideas but whatever we do, I would want to understand why
> publishing whatever document we published was going to help make things
> work better. And on that note, I'd like to express many thanks to SIP
> Forum and all the people who worked on this effort for helping get fax
> working better.

I think I heard crickets chirping.  Perhaps that's a bad sign, but I would
like to hear more voices.  Folks who have tried to deploy fax equipment,
either as a manufacturer or the end-user, surely has had some level of
frustration with fax.  So, how do people feel about this document?

Paul

> Cullen
> 
> PS - Paul, thanks for trying to make less work and Dean, as punishment
> for your sins I'm nominating you for AD to the next Nomcom :-)
>