Subject: Re: [dispatch] draft-hanes-dispatch-fax-capability-02

From: David Hanes <[email-masked]>
Date: Fri, 7 Sep 2012 12:18:23 -0400

On Sep 5, 2012, at 2:52 PM, Dale R. Worley wrote:

> I think the descriptions of the values could be improved a little bit.

You are probably right.  :-)

> 
> The "t38" value is better described as "supports the image/t38 media
> type[RFC3362] which encodes page images using the ITU-T T.38 fax
> protocol[T.38]".  That specifies the media type and adds a reference
> to the RFC, which includes more details of the specific ITU
> recommendations involved.  There are probably some implications of
> what values of the T.38 SDP attributes are supported -- is there a
> default set of attributes which constitute a baseline version of
> image/t38?
> 

I like the image/t38 media and RFC specifics that you added above and I will include these updates in the next version.

You also mention specific T.38 attributes. I am not aware of a default set of attribute values. It seems that each vendor has certain defaults but it is probably safe to say that many are commonly set the same.  Thinking this through though, it seems like the goal of this feature tag is to signal the preference that the call lands at a fax capable, or more specifically in this case, a T.38 capable UA. Once the T.38 capable UAs are connected, shouldn't they handle the T.38 attribute exchange/negotiation within SDP? This is how it works now. It seems that just specifying T.38 would be enough in this case and then the UAs can deal with the T.38 attribute settings within SDP.  

> The definition of "passthrough" is incomplete as it stands.  The
> meaning is "supports the audio/pcmu and audio/pcma media
> types[RFC4856] for the transmission of fax images encoded (somehow) as
> an analog audio stream, which is in turn encoded using G.711".  But
> what is the description of "somehow" and the proper reference for it?

The "somehow" here is defined by ITU-T T.30, T.4, and T.6 and these are modulated using common schemes like V.21 and V.17 so that the fax communication is now an analog stream. I am not sure that we need this level of detail though. This audio stream generation happens with every fax machine and gateway. Passthrough is very simple. We are just replacing human speech over G.711 with an analog fax stream. G.711 has been used on the PSTN for decades on T1/E1 spans for handling voice and fax. Basically, when we use the term passthrough, we are saying treat fax like a G.711 voice call. With that being said, wouldn't just referencing G.711 be enough from a media feature tag and user preference perspective?

> I don't know fax technologies well enough to know what it is, though
> I'm certain that there is a specific standard intended here.
> 

The only attempt that I am aware of towards passthrough (or voice band data) standardization is ITU-T V.152. However, I have never seen it implemented... probably because of the signaling portion of it. The part about vbd/passthrough implementation is really good and most vendors have implemented it in this manner. Here are Sections 6 and 6.1, which I think is along the lines of what you all are looking for - 

6	Definition of the VBD mode of operation
Voice-band data is the transport of modem, facsimile, and text telephony signals over a voice channel of a packet network with a codec appropriate for such signals.
For voice-band data (VBD) mode of operation, all voice-band modulated signal samples shall be transported across an IP network using the RTP protocol defined in IETF RFC 3550.
When in VBD mode, a V.152 compliant implementation shall:
•	Use a codec that passes voice-band modulated signals with minimal distortion. This codec shall be assigned as the VBD codec with a specific RTP payload type which shall be negotiated with the remote V.152 implementations as described in clause 7.
•	Have end-to-end constant latency.
•	Disable voice activity detection and comfort noise generation during the data transfer phase.
•	Disable any DC removal filters that may be integral with the speech encoder used. And should consider the appropriate application of:
•	The use of echo cancellers on the VBD channel, as per ITU-T Rec. G.168.
•	Forward Error Correction (FEC) (e.g., RFC 2733) or other forms of redundancy (e.g., RFC 2198) only if support has been successfully negotiated with the remote V.152 implementation.
•	Voice packet loss concealment techniques and algorithms that are suitable for modem and facsimile modulations.

6.1	Minimum requirements for VBD mode of operation
For purposes of interoperability, a V.152 compliant implementation shall support at least both G.711 A-law and G.711 μ-law codecs as VBD codecs.
When negotiating the VBD codec, the initiating V.152 implementation must include in the offer either PCMA or PCMU (or both) in the list of VBD codecs, though other VBD codecs may be additionally specified. The V.152 implementation answering the offer must indicate support for at least one VBD codec, which need not be PCM-based.
Redundancy as per IETF RFC2198 and forward error correction as per IETF RFC2733 are supported options.

> Do we want to require PCMU and PCMA support, or PCMU *or* PCMA
> support?
> 

As with the T.38 SDP attributes, is this something that we want to address in this draft or just leave it to the SDP portion? With only 2 codec options, you could have "passthrough-g711μ" and "passthrough-g711a" values. However, in reality most folks implementing passthrough will accept either G.711 variety.

> What encoding parameter values are required for support?  I expect we
> want to add that the audio stream is single-channel and we probably
> want to specify that it is at 8000Hz sample rate.
> 
> Also, the reference to the T.38 spec is given as informative, whereas
> it is used normatively.
> 

Thanks. I will get that fixed in the next version. 

> Dale

---

From: Paul Kyzivat <[email-masked]>
Date: Fri, 07 Sep 2012 12:42:43 -0400

> You also mention specific T.38 attributes. I am not aware of a default set of attribute values. It seems that each vendor has certain defaults but it is probably safe to say that many are commonly…

Yes, I think that is appropriate.

> The "somehow" here is defined by ITU-T T.30, T.4, and T.6 and these are modulated using common schemes like V.21 and V.17 so that the fax communication is now an analog stream. I am not sure that w…

Not much is needed if the goal is simply to connect existing analog fax 
machines.

But fax is becoming rarer as time goes on. Consider someone that wants 
to implement software that can transmit/receive images via fax in order 
to comply with needs of others. (E.g. because fax is the only thing the 
recipient supports.) This person needs to discover the specs to 
implement to accomplish this. With T.38 there is a clear reference that 
someone not familiar with fax can figure out. With passthru, he will 
need specs for everything. Perhaps the specs you mention above are what 
he needs. But "common schemes *like" V.21 *and* V.17" would leave me 
wondering - which other ones might be included, and how do I know which 
ones to implement? Since fax machines (old and new, cheap and fancy) 
seem to interoperate fairly successfully I presume there are 
interoperability and fallback provisions in the various specs. Maybe it 
is sufficient to reference one or a few, if those in turn reference the 
others they are interoperable with.

I'm not expecting that you write a book here. :-)
Just that you point to the key specs that will *lead* a developer to 
what he needs to know about anything you expect to be compliant with 
"passthru". Maybe the ones you have mentioned are sufficient.

	Thanks,
	Paul

---

From: "Richard Shockey" <[email-masked]>
Date: Fri, 7 Sep 2012 14:39:42 -0400

But fax is becoming rarer as time goes on. 

[RS> ] Less relevant but it is NOT going away, especially if you live in
countries with non ASCII characters in the language. Fax as a application is
imbedded in law since the principal attribute users are comfortable with is
non repudiation. ( 3rd party billing ). If sending a PDF over email was
acceptable than we wouldn't have this discussion. I point that out only as a
reminder.

Consider someone that wants to implement software that can transmit/receive
images via fax in order to comply with needs of others. (E.g. because fax is
the only thing the recipient supports.) This person needs to discover the
specs to implement to accomplish this. With T.38 there is a clear reference
that someone not familiar with fax can figure out. With passthru, he will
need specs for everything. Perhaps the specs you mention above are what he
needs. But "common schemes *like" V.21 *and* V.17" would leave me wondering
- which other ones might be included, and how do I know which ones to
implement? Since fax machines (old and new, cheap and fancy) seem to
interoperate fairly successfully I presume there are interoperability and
fallback provisions in the various specs. Maybe it is sufficient to
reference one or a few, if those in turn reference the others they are
interoperable with.

I'm not expecting that you write a book here. :-) Just that you point to the
key specs that will *lead* a developer to what he needs to know about
anything you expect to be compliant with "passthru". Maybe the ones you have
mentioned are sufficient.

	Thanks,
	Paul
_______________________________________________
dispatch mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/dispatch