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

From: David Hanes <[email-masked]>
Date: Wed, 26 Sep 2012 11:33:26 -0400

How about the following descriptions for T.38 and passthrough in the IANA Considerations section?

t38:	The device supports the image/t38 media type [RFC 3326] and implements ITU-T T.38 for transporting the ITU-T T.30 and T.4 fax data over IP. 

passthrough: The device supports the audio/pcmu and audio/pcma media types [RFC4856] for transporting ITU-T T.30 and T.4 fax data using the ITU-T G.711 codec. Additional implementation recommendations are in ITU-T V.152 Sections 6 and 6.1.

Thanks,
David

On Sep 11, 2012, at 2:58 PM, Dale R. Worley wrote:

>> From: David Hanes <[email-masked]>
>>> 
>>> 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 can't remember if in the past I mistakenly considered the fax media
> type to be application/t38 (which was proposed in
> ietf-mmusic-sdp-t38-00), but the fact that the fax media type is
> image/t38 makes it impossible to use the +sip.app-subtype media
> feature tag to select fax-capable UAs.)
> 
>> I like the image/t38 media and RFC specifics that you added above and
>> I will include these updates in the next version.
> 
> Ideally, we should point to all the standards needed to define the
> feature (although in practice, in many respects there is only one
> practical way to implement this, so we could force people to figure
> things out for themselves).
> 
>> 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.
> 
> Yes, I agree.
> 
> I wanted to ensure that +sip.fax would require a sufficient set of
> image/t38 features (expressed as T38* attributes) that any two UAs
> that met the specification would be able to communicate (at least with
> a "baseline" capability).  Otherwise there could be multiple,
> incompatible groups of "sip.fax" UAs.  That would indicate that the
> sip.fax values should be finer-grained than simply "t38".
> 
> But looking at the T.38 spec, annexes D and H, it appears to me that
> T.38 is designed for maximum negotiation and compatibility, and so
> there should be little risk of incompatibility if we do not place any
> requirements on the T38* attribute values that are supported.
> 
>>> 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.
> 
> As I see it, there is a series of decoding steps:
> 
> - from the incoming RTP packets, the stream of PCM octets is extracted
>  based on the RTP standards
> 
> - from the PCM octets, an analog signal is constructed via G.711 (PCMA
>  or PCMU)
> 
> - from the analog signal, a bit stream is constructed via V.21/V.17/V.*
> 
> - from the bit stream, a fax image is constructed via T.30/T.4/T.6
> 
> and encoding is done in the reverse order.
> 
> So to specify how meaning is encoded in the packets, you need to
> specify that entire stack of standards.  Or, to ensure
> interoperability, you have to require implementation of a minimal
> subset of all those choices.
> 
> The reality is a bit messier, I think, because machines probably
> negotiate which "modem" protocol they use (V.21, etc.), and they may
> negotiate which fax encoding they use.
> 
> But since fax machines work in practice, there is a standard (or a
> ubiquitous de-facto standard) that specifies the two higher levels of
> the encoding stack.
> 
> So I think it is necessary to provide specification of the two higher
> levels, the "modem" encoding and the page encoding.  But I strongly
> suspect that there are standards or well-understood BCPs that can be
> referenced -- without excluding any practical implementation from
> being in conformance with "sip.fax".
> 
>>> 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.
> 
> As I said above, I want to ensure that if a call that specifies
> "sip.fax" arrives at a UA that registers with "sip.fax", then the fax
> call will succeed in practice.  Otherwise, defining sip.fax hasn't
> gained what we want.
> 
> But given that every SIP G.711 implementation I've ever seen supports
> both PCMU and PCMA, I would suggest that we require *both* as part of
> the definition.  With that, the definition ensures interoperability,
> but it does not (in practice) further constrain any implementation.
> 
>>> 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.
> 
> Or perhaps those parameters are effectively fixed by T.4/T.6/T.30
> (regarding channels) and G.711 (for the bitrate).
> 
>>> 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: Wed, 26 Sep 2012 12:00:53 -0400

This sounds pretty reasonable to me.

	Thanks,
	Paul

---

From: Gonzalo Salgueiro <[email-masked]>
Date: Wed, 26 Sep 2012 12:21:51 -0400

+1 

Gonzalo

On Sep 26, 2012, at 12:00 PM, Paul Kyzivat wrote:

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

---

From: James Rafferty <[email-masked]>
Date: Wed, 26 Sep 2012 13:55:39 -0400

+1

James

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Gonzalo Salgueiro
Sent: Wednesday, September 26, 2012 12:22 PM
To: Paul Kyzivat
Cc: Dale R. Worley; DISPATCH
Subject: Re: [dispatch] draft-hanes-dispatch-fax-capability-02

+1

Gonzalo

On Sep 26, 2012, at 12:00 PM, Paul Kyzivat wrote:

>>>>> 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 can't remember if in the past I mistakenly considered the fax 
>>> media type to be application/t38 (which was proposed in 
>>>> 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.
>>> 
>>> Yes, I agree.
>>> 
>>> that met the specification would be able to communicate (at least 
>>> with a "baseline" capability).  Otherwise there could be multiple, 
>>> there should be little risk of incompatibility if we do not place 
>>> any requirements on the T38* attribute values that are supported.
>>> 
>>>>> 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?
>>>> 
>>>> 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.
>>> 
>>> - from the incoming RTP packets, the stream of PCM octets is 
>>> extracted  based on the RTP standards
>>> 
>>> - from the PCM octets, an analog signal is constructed via G.711 
>>> (PCMA  or PCMU)
>>> 
>>> ubiquitous de-facto standard) that specifies the two higher levels 
>>> of the encoding stack.
>>> 
>>> So I think it is necessary to provide specification of the two 
>>> higher levels, the "modem" encoding and the page encoding.  But I 
>>> strongly suspect that there are standards or well-understood BCPs 
>>> that can be referenced -- without excluding any practical 
>>> implementation from being in conformance with "sip.fax".
>>> 
>>>> address in this draft or just leave it to the SDP portion? With 
>>>> only 2 codec options, you could have "passthrough-g711μ" and 
>>> "sip.fax" arrives at a UA that registers with "sip.fax", then the 
>>> fax call will succeed in practice.  Otherwise, defining sip.fax 
>>> hasn't gained what we want.
>>> 
>>> But given that every SIP G.711 implementation I've ever seen 
>>> supports both PCMU and PCMA, I would suggest that we require *both* 
>>> as part of the definition.  With that, the definition ensures 
>>> interoperability, but it does not (in practice) further constrain any implementation.
>>> 
>>>>> 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.
>>>>

---

From: <[email-masked]>
Date: Fri, 28 Sep 2012 08:11:11 +0000

The proposed definition for the pass-through mode assumes that G.711 is used as a voice-band codec. This is indeed the most likely configuration. However, as far as I can remember, the pass-through mode as described in V.152 is not restricted to G.711 (e.g. G.726 is possible as well).
BC

> -----Message d'origine-----
> De : [email-masked] [mailto:[email-masked]] De la part
> de James Rafferty
> Envoyé : mercredi 26 septembre 2012 19:56
> À : Gonzalo Salgueiro; Paul Kyzivat
> Cc : Dale R. Worley; DISPATCH
> Objet : Re: [dispatch] draft-hanes-dispatch-fax-capability-02
> 
> +1
> 
> James
> 
> >> t38:	The device supports the image/t38 media type [RFC 3326] and
> implements ITU-T T.38 for transporting the ITU-T T.30 and T.4 fax data over
> IP.
> >>
> >> passthrough: The device supports the audio/pcmu and audio/pcma media
> types [RFC4856] for transporting ITU-T T.30 and T.4 fax data using the ITU-T
> G.711 codec. Additional implementation recommendations are in ITU-T V.152
> Sections 6 and 6.1.
> >>
> >> Thanks,
> >> David
> >>
> >>
> >>
> >>
> >>
> >>

_________________________________________________________________________________________________________________________

Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc
pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler
a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration,
France Telecom - Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci.

This message and its attachments may contain confidential or privileged information that may be protected by law;
they should not be distributed, used or copied without authorisation.
If you have received this email in error, please notify the sender and delete this message and its attachments.
As emails may be altered, France Telecom - Orange is not liable for messages that have been modified, changed or falsified.
Thank you.

---

From: David Hanes <[email-masked]>
Date: Fri, 28 Sep 2012 16:38:51 -0400

Hi Bruno,

You are correct in that V.152 does propose G.726 as a passthrough codec in addition to G.711. However, this draft only references sections 6 and 6.1 of V.152 where G.726 is not mentioned and it states that a G.711 variant is required at a minimum. Please correct me if I am wrong but in real world scenarios I have only seen G.711 being used for passthrough and that is why it is the codec explicitly defined. Are you recommending that G.726 be included as an option in this draft? Or do you think we need more clarification that G.711 is the only codec that we are supporting based on the reference to V.152?

Thanks,
David