Re: [dispatch] I-D Action: draft-hanes-dispatch-fax-capability-07.txt

[Cary FitzGerald <[e-mail]>]

I'm going to restrict my attention to the gazallions of fax machines connected to the PSTN, since I think we're agreed that's the only real use case.

Also, I'm not disputing that the draft describes a way to denote probable fax calls from other calls - your example below is perfectly fine.

I'm a SMB and I have business cards printed up for my employees.  They either have one number on them for all of an employee's calls or a separate number for fax calls.

If they have one number, then I still don't see how to distinguish between a probable fax call and a probable voice call.  Should a call get routed to an employee on a UA that is not capable of dealing with fax, they'll probably transfer the call to voice mail since most messaging systems will take the fax call and render it as an email attachment in their unified mailbox.

If they have a separate number, then the server can make a rational routing decision.  There are several ways to do that, and this draft is one of them.

If you implement the draft, then there is code to write on the server and on the UA to implement the preference.  Then configure the UA to say that it would like to accept fax calls.  Good, works great.

Otherwise, configure the server to route calls to the fax number(s) to a (set of) UA(s).  Done.

I view preferences as a way to express fairly dynamic policy, rather than static routing.

If the draft proceeds, I don't mind, it just seems like a lot of bother to solve either an unsolvable problem or a non-problem.

I'm sorry if I've sounded like a curmudgeon on this thread.  I've had my say and that's pretty much it.

Cary.

On Jan 21, 2013, at 8:51 AM, David Hanes wrote:

> 
> On Jan 20, 2013, at 8:18 PM, Cary FitzGerald wrote:
> 
>> Copying dispatch.
>> 
>> You keep trying to tell me that fax is a widely used feature - trust me, I know that very well (and have the scars to prove it!).
>> 
>> What I don't understand is how a preference helps.  If there were some way _a priori_ to determine that a call was likely to be a fax call, then OK.  
> 
> 
> Yes, the cases we are interested in covering are from fax devices that originate the call knowing a priori that it is to be a fax call (e.g. fax servers). We've mentioned a few ways to make this determination. The simplest example again is an IP fax server. It knows the call it is sending out is ultimately going to be fax so the determination is easy. The fax server then simply tags its initial INVITE with the fax media feature tag expressing its preference for a fax capable termination. This all happens prior to any tone detection or re-INVITE.
> 
> 
>> But the example you present says precisely that you don't have any of that information - the INVITE for a call that has some fax content is indistinguishable from one that doesn't (as it should, calls can go between fax and voice content multiple times).  
> 
> 
> Actually, Kevin says that we DO have that information in his first paragraph - 
> 
> "It is quite likely that such a small business would own one or more FAX machines, and when those are connected to the new PBX, their analog ports would be 'marked' as FAX ports. Any calls that they initiate would be marked as "FAX" calls on their way out of the PBX, due to the vast majority of them actually being FAX calls."
> 
> The PBX knows that a fax machine is on a specific port. So, it can easily apply the fax media feature to that initial INVITE without having to wait for the re-INVITE, CNG, or some other mechanism later in the call.
> 
> You say that "the INVITE for a call that has some fax content is indistinguishable from one that doesn't". I admit I may be missing your point but based on my understanding, the examples and text in this draft indicate otherwise. Let's see if we can agree on the following example. Here is a sample INVITE header for a voice call - 
> 
> INVITE sip:[e-mail] SIP/2.0
>   Via: SIP/2.0/TCP client.atlanta.example.com:5060;branch=z9hG4bK74b43
>   Max-Forwards: 70
>   From: Alice <sip:[e-mail]>;tag=9fxced76sl
>   To: Bob <sip:[e-mail]>
>   Call-ID: [e-mail]
> 
> <snip>
> 
> And here is the same example for a fax call. The SDP in both would be the same as they both start as a voice call, which I think we already agree on.
> 
> INVITE sip:[e-mail] SIP/2.0
>   Via: SIP/2.0/TCP client.atlanta.example.com:5060;branch=z9hG4bK74b43
>   Max-Forwards: 70
>   From: Alice <sip:[e-mail]>;tag=9fxced76sl
>   To: Bob <sip:[e-mail]>
>   Accept-Contact: *;+sip.fax="t38"
>   Call-ID: [e-mail]
> 
> <snip>
> 
> The sample headers for the fax call have the fax media feature tag (+sip.fax="t38") in the Accept-Contact header while the voice does not. So, from this example, can we agree that the INVITE for a call that has some fax content is distinguishable from one that doesn't? 
> 
> 
>> My only real request is to add some kind of logic to the draft on how one divines that a call is more likely to contain fax content than any other call.
>> 
>> I don't think that this draft hurts anything, but I don't see how it helps.
>> 
>> Cary.
>> 
>> On Jan 20, 2013, at 4:48 AM, Kevin Fleming wrote:
>> 
>>> You are absolutely correct; there are plenty of far more useful alternatives to T.38 FAX. In spite of that, it's used heavily, and will likely be so for the foreseeable future. A simple example of where this feature tag would be useful would be a small business replacing a TDM PBX with an IP PBX, and using SIP for connection to the PSTN and other businesses. It is quite likely that such a small business would own one or more FAX machines, and when those are connected to the new PBX, their analog ports would be 'marked' as FAX ports. Any calls that they initiate would be marked as "FAX" calls on their way out of the PBX, due to the vast majority of them actually being FAX calls. Doing so would actually indicate to any network elements in the path of that call that it is intended to be a FAX call as early as that information is available (long before CNG or other inband negotiation would begin, which is much too late for many use cases).
>>> 
>>> That describes how it could be applied; as to how it could be useful, take the example of auto-discrimination of inbound calls to extensions on a PBX. Many PBXes do this today, so that users of the PBX can publish a single phone number for both voice and FAX calls. The implementation of this is rather ugly, though, the PBX has to spy on the media path to listen for CNG after the call is answered so it can redirect the call to a FAX endpoint. This works acceptably well when the user is not at their desk and the call lands at their voicemail, but it's inelegant when they are at their desk and their phone rings. They get interrupted, answer the call, say "Hello?" a few times, and then hear a short blip of CNG before the is dropped from their handset. It is even less elegant when a PBX user has 'call-forward-no-answer' to someone else in their team; now the FAX call rings for 6-7 rings before being answered, only to again be pulled away. As another complication, auto-discrimination effectively disables the use of V.34 FAX, because in that mode the *receiving* FAX endpoint is responsible for initiating the protocol negotiation (by emitting ANSam), which can't be done if the call wasn't answered by a FAX endpoint. The result of this is that even if both FAX endpoints are V.34 capable, the FAX transaction will use older/slower/less reliable modem protocols because the calling endpoint's state machine will have passed the 'point of no return' for V.34 negotiation by the time the call is redirected.
>>> 
>>> On the conceptual level, I think we're all in agreement that FAX is a terrible mechanism for document transmission and that there are far more effective (and less expensive) mechanisms available. Unfortunately, there are tens of milllions (if not hundreds of millions) of FAX machines deployed and they are used every day for billions of document transmissions. As the voice networks of the world move to IP and SIP, there is a need to provide FAX call success rates comparable to what the TDM networks provided.
>>> 
>>> 
>>> 
>>> 
>>> On Sat, Jan 19, 2013 at 10:16 PM, Cary FitzGerald <[e-mail]> wrote:
>>> 
>>> On Jan 19, 2013, at 4:32 AM, Kevin Fleming wrote:
>>> 
>>>> Actually, the primary use case for this feature tag is *not* expected to be PSTN-originated calls, but instead FAX-capable SIP endpoints
>>> 
>>> I am skeptical that this is an important use case.  Why would SIP endpoint generate a T.38 call when there are so many *much* better alternatives?
>>> 
>>>> (or non-SIP endpoints attached to a SIP gateway that has been administratively configured to be aware of their FAX capabilities).
>>> 
>>> That's what I meant by a PSTN call - the gateway is acting as a proxy for the PSTN-connected fax machine.
>>> 
>>>> In these cases, the endpoint or its immediate gateway will have explicit knowledge that the call being placed by the endpoint is for the purpose of a FAX transmission. If the T.38 recommendation had been designed differently, and INVITE carrying only a T.38 SDP was an acceptable option, then this feature tag would be unnecessary. Unfortunately (and for legitimate reasons) that is not the case, and the SIP Forum's FOIP task group came to the conclusion that providing a mechanism for the endpoint to explicitly indicate its intent to initiate a FAX transaction would be useful.
>>>> 
>>> However, I still am baffled about what logic one would use to determine that a call was more likely to carry fax than anything else.  That's all I'm asking - given that a fax call is in general indistinguishable from any other call how would someone make the determination that any specific call should get special treatment?
>>> 
>>> I don't think that this draft is harmful, so if itproceeds I don't mind.  Not to be rude, I just don't think that it is useful.  I'm not suggesting that fax is not important, I just don't understand how the draft helps.  The fact that you can't express T.38 in sdp is a canard - you wouldn't know whether that was important or not doesn't matter when an INVITE arrives, because you'd only know about CNG well after the media path was established - hundreds of milliseconds later.  I don't know what logic you'd use to figure out a m= line or this prefs decision.
>>> 
>>> Cary.
>>>> 
>>>> On Fri, Jan 18, 2013 at 11:03 PM, Cary FitzGerald <[e-mail]> wrote:
>>>> Hmmm.  I _thought_ i was subscribed to dispatch, but apparently there's a problem there.  I'll try to figure this out tomorrow.
>>>> 
>>>> On Jan 18, 2013, at 7:29 PM, David Hanes wrote:
>>>> 
>>>> > Hi Cary,
>>>> >
>>>> > I just wanted to follow-up once since we had not heard back from you and we are facing a deadline. This draft is on the agenda of the 1/24 IESG telechat and we want to make sure that we have addressed your concerns.
>>>> >
>>>> > Thanks,
>>>> > David
>>>> >
>>>> >
>>>> > On Jan 16, 2013, at 11:56 PM, David Hanes wrote:
>>>> >
>>>> >> Hi Cary,
>>>> >>
>>>> >> Thanks for the comments. I am taking this off-list as I needed some clarification on a few things; some of which may have been addressed already through the various discussions on DISPATCH that have already taken place prior to Last Call.  Some inline comments...
>>>> >>
>>>> >> Regards,
>>>> >> David
>>>> >>
>>>> >>
>>>> >>
>>>> >>
>>>> >> On Jan 16, 2013, at 1:36 PM, Cary FitzGerald wrote:
>>>> >>
>>>> >>> I don't understand use case for this draft.  Unless I'm missing something, it helps to solve a very small corner case.
>>>> >>>
>>>> >>> For the IP-UA to UA case, it seems very unlikely to be useful.  Of course someone _could_ construct a UA that sends T.38, but why bother when SMTP or mumble is so much less trouble.  So I don't see an actual problem here.
>>>> >>
>>>> >> Admittedly, fax is that evil which will never die but actually this draft addresses a very real problem that has been under discussion by the FoIP Task Group of the SIP Forum for a couple of years. They concluded that the ability to select SIP endpoints for session termination based on the need for fax support by the calling endpoint would be very useful. This draft is doing nothing more than registering a new media feature tag (like audio, video, data, text, etc.) that was omitted earlier.
>>>> >>
>>>> No argument that fax is the undead, stabbed in the heart many times, still stumbling forward.
>>>> 
>>>> >>>
>>>> >>> For the PSTN-UA to UA case, as the draft points out, there is no way to predict whether fax is going to be part of the call.  It's certainly true that increasing the probability of successfully handling a media stream, but I don't know how to figure out a priori how to set the balance between capabilities, convenience and whatever else the user's preferences are trying to tell us.
>>>> >>>
>>>> >>> If the call is routed to BOB (Big Old Business), then I'd kind of expect that by administrative policy, the BOB administrators would set a routing policy if some of the incoming PSTN numbers were fax banks to route to fax capable UAs.  You _could_ solve the problem with preferences, but that seems like a lot of unnecessary nuance.  Routing policy is a hammer, for sure, but it's simple and works for this case.
>>>> >>
>>>> >> Yes, routing policy can work in this case but in other cases it cannot. This draft provides a broader solution and encompasses use cases where multiple UAs are registered for a single number but only a certain one can handle fax media.
>>>> 
>>>> Of course, it is possible that BOB has UAs that are not always accessible, and that having a preference is that is dynamically updated is useful, but operationally, I don't see this actually happening.
>>>> >>
>>>> >>>
>>>> >>> If the call is routed to Bob Regular Guy, and assuming Alice can predict the preferences for that particular call (outside of any other preferences), then the draft solves an actual problem.
>>>> >>>
>>>> >>> I think that the draft would be improved if the authors could add some words about how Alice would calculate a preference.
>>>> >>
>>>> >> The main use case here would involve Alice initiating fax calls from a fax server or from a DID fronted by a proxy. In either of these cases, the fax media feature tag is appended to the INVITE. Can you clarify what you mean by "calculate a preference" as Alice is the initiator and ascertaining that the call is fax would not be complicated?
>>>> >>
>>>> >>
>>>> Sorry if I was being obscure.
>>>> 
>>>> An INVITE carries whatever information it carries.  What information would you use to assert that for _this call_ the INVITE should be routed this way versus that way?  If you buy my argument that this is a call that is originated in the PSTN, then you have an originating number and terminating number.  If this is what you know, what logic do you see filling in here:
>>>> 
>>>> if (originating_number == condition) then
>>>>         if (terminating_number == condition)
>>>>                 foo;
>>>>         else
>>>>                 bar;
>>>> else
>>>>         if (terminating_number == condition)
>>>>                 blatz;
>>>>         else
>>>>                 buzz;
>>>> 
>>>> I'm not disputing that there is value in increasing the probability of successfully terminating a fax call, I just don't know how to do it.  What I'm asking for is a clue how.
>>>> 
>>>> You can argue that my issues should not be in a protocol specification, but in this case, if I were a product manager, I wouldn't know how to assign a non-zero priority to this feature.  My point is what I said before.  If you could provide some logic of how you would decide how to route any particular call, it would help me understand how this draft helps the cause.
>>>> 
>>>> Cary.
>>>> >>>
>>>> >>> Cary.
>>>> >>>
>>>> >>> On Jan 15, 2013, at 2:12 PM, [e-mail] wrote:
>>>> >>>
>>>> >>>>
>>>> >>>> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>>>> >>>>
>>>> >>>>
>>>> >>>>    Title           : Indicating Fax over IP Capability in the Session Initiation Protocol (SIP)
>>>> >>>>    Author(s)       : David Hanes
>>>> >>>>                       Gonzalo Salgueiro
>>>> >>>>                       Kevin P. Fleming
>>>> >>>>    Filename        : draft-hanes-dispatch-fax-capability-07.txt
>>>> >>>>    Pages           : 9
>>>> >>>>    Date            : 2013-01-15
>>>> >>>>
>>>> >>>> Abstract:
>>>> >>>> This document defines and registers with IANA the new 'fax' media
>>>> >>>> feature tag for use with SIP.  Currently, fax calls are
>>>> >>>> indistinguishable from voice at call initiation.  Consequently, fax
>>>> >>>> calls can be routed to SIP user agents that are not fax capable.  A
>>>> >>>> 'fax' media feature tag implemented in conjunction with caller
>>>> >>>> preferences allows for more accurate fax call routing.
>>>> >>>>
>>>> >>>>
>>>> >>>> The IETF datatracker status page for this draft is:
>>>> >>>> https://datatracker.ietf.org/doc/draft-hanes-dispatch-fax-capability
>>>> >>>>
>>>> >>>> There's also a htmlized version available at:
>>>> >>>> http://tools.ietf.org/html/draft-hanes-dispatch-fax-capability-07
>>>> >>>>
>>>> >>>> A diff from the previous version is available at:
>>>> >>>> http://www.ietf.org/rfcdiff?url2=draft-hanes-dispatch-fax-capability-07
>>>> >>>>
>>>> >>>>
>>>> >>>> Internet-Drafts are also available by anonymous FTP at:
>>>> >>>> ftp://ftp.ietf.org/internet-drafts/
>>>> >>>>
>>>> >>>> _______________________________________________
>>>> >>>> I-D-Announce mailing list
>>>> >>>> [e-mail]
>>>> >>>> https://www.ietf.org/mailman/listinfo/i-d-announce
>>>> >>>> Internet-Draft directories: http://www.ietf.org/shadow.html
>>>> >>>> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
>>>> >>>
>>>> >>> _______________________________________________
>>>> >>> dispatch mailing list
>>>> >>> [e-mail]
>>>> >>> https://www.ietf.org/mailman/listinfo/dispatch
>>>> >>
>>>> 
>>>> 
>>> 
>>> 
>> 
>