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

From: <[email-masked]>
Date: Mon, 1 Oct 2012 09:09:15 +0000

Hi David,

I don't see a strong need to explicitly mention G.726 (G.726 is just an example anyway) but I find a bit confusing to create a definition of pass-through that is more restrictive than the one used in V.152. If there is a good reason for doing that, I think we should explain it somewhere in the draft...

BC 

> -----Message d'origine-----
> De : David Hanes [mailto:[email-masked]]
> Envoyé : vendredi 28 septembre 2012 22:39
> À : CHATRAS Bruno RD-CORE
> Cc : James Rafferty; Gonzalo Salgueiro; Paul Kyzivat; Dale R. Worley;
> DISPATCH
> Objet : Re: [dispatch] draft-hanes-dispatch-fax-capability-02
> 
> 
> 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
> 
> 
> 
> 
> On Sep 28, 2012, at 4:11 AM, <[email-masked]>
>  wrote:
> 
> > 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
> >>
> >> -----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:
> >>
> >>> This sounds pretty reasonable to me.
> >>>
> >>> 	Thanks,
> >>> 	Paul
> >>>
> >>> On 9/26/12 11:33 AM, David Hanes wrote:
> >>>> 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
> >>>>
> >>>>
> >>>
> >>> _______________________________________________
> >>> dispatch mailing list
> >>> [email-masked]
> >>> https://www.ietf.org/mailman/listinfo/dispatch
> >>>
> >>
> >> _______________________________________________
> >> dispatch mailing list
> >> [email-masked]
> >> https://www.ietf.org/mailman/listinfo/dispatch
> >> _______________________________________________
> >> dispatch mailing list
> >> [email-masked]
> >> https://www.ietf.org/mailman/listinfo/dispatch
> >
> >
> ____________________________________________________________________________
> _____________________________________________
> >
> > 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.
> >
> > _______________________________________________
> > dispatch mailing list
> > [email-masked]
> > https://www.ietf.org/mailman/listinfo/dispatch

_________________________________________________________________________________________________________________________

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: Mon, 1 Oct 2012 16:49:47 -0400

Hi Bruno,

I will let other folks on this list who have an expertise in FoIP also chime in here but I have never seen passthrough with G.726 implemented in the real world and in my own lab testing it was not as reliable as G.711. Also, the reference to V.152 is simply for implementation assistance. The G.726 codec is not mentioned in the sections I reference and I have not seen V.152 implemented in the real world either. My point here is that in reality neither G.726 nor V.152 are practical alternatives that have any sort of widespread adoption. So, I question whether folks will find it confusing when in reality only G.711 is being used for fax passthrough. In fact, I think you could make the argument that bringing up G.726 or any other codec in this draft could actually introduce some confusion. 

The reason that we need to be restrictive on the codec is that if multiple codecs are supported for passthrough then you could run into the scenario where UAs express a preference for passthrough but they are each using a different codec. This could lead to a mismatch scenario where the fax call fails. With G.711 being the only codec for a passthrough preference, then this scenario should not occur. I am not sure that we want to create the ability to have UAs expressing a passthrough preference with the potential for mismatched codecs. An option here would be to explicitly define other passthrough codec options but that seems unnecessary with G.711 being the de facto standard. Another option would be to go down this path and then hope that the UAs could negotiate a passthrough codec that works for both. However, you still have the possibility of the UAs not agreeing on a common passthrough codec. Restricting the codec to G.711 for passthrough ensures that UAs that express a passthrough preference will be using the same codec. I hope my thinking here makes sense and is inline with how preferences are supposed to function. 

-David

---

From: John Atkinson <[email-masked]>
Date: Tue, 2 Oct 2012 13:37:39 +0000

G.726 spec says that 32kbps adpcm may handle  up to 2400bps, so it won't handle fax very well.  Therefore, I agree that we don't need to include G.726-32 as a passthrough alternative.  The quote from G.726 below also indicates G.726-40 can only handle 12000bps - so again not suitable for fax passthrough 

I.8 Data performance
Voiceband data performance up to 2400 bit/s using, for example modems conforming to
Recommendation V.21, V.22 bis, V.23 and V.26 ter, will not be subject to significant degradation over 32 kbit/s
ADPCM links provided the numbers of such links do not exceed the limits of Recommendation G.113.
Voiceband data performance at 4800 bit/s using, for example modems conforming to
Recommendation V.27 bis, can be accommodated with 32 kbit/s ADPCM but will be subject to additional degradations
over and above that expected from standard 64 kbit/s PCM links. More care will need to be exercised in using such a
service.
Voiceband data at speeds up to 12 000 bit/s can be accommodated by 40 kbit/s ADPCM. The performance of
V.33 modems operating at 14 400 bit/s over 40 kbit/s ADPCM is for further study.

John 

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of David Hanes
Sent: Monday, October 01, 2012 4:50 PM
To: [email-masked]
Cc: Dale R. Worley; DISPATCH
Subject: Re: [dispatch] draft-hanes-dispatch-fax-capability-02

Hi Bruno,

-David

On Oct 1, 2012, at 5:09 AM, <[email-masked]>
 wrote:

>> De : David Hanes [mailto:[email-masked]] Envoyé : vendredi 28 
>> septembre 2012 22:39 À : CHATRAS Bruno RD-CORE Cc : James Rafferty; 
>> Gonzalo Salgueiro; Paul Kyzivat; Dale R. Worley; DISPATCH Objet : Re: 
>> [dispatch] draft-hanes-dispatch-fax-capability-02
>> 
>> 
>> 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
>> 
>> 
>> 
>> 
>>>> 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
>>>> 
>>>> G.711 codec. Additional implementation recommendations are in ITU-T 
>>>> V.152 Sections 6 and 6.1.
>>>>>> 
>>>>>> Thanks,
>>>>>> David
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>>>>> 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.
>>>>>>> 
>>>>>>> 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).
>>>>>>> 
>>>>>>>> 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
>>>>>>> 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".
>>>>>>> 
>>>>>>> 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 
>>>>>>>> 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.
>>>>>>> interoperability, you have to require implementation of a 
>>>>>>> minimal subset of all those choices.
>>>>>>> 
>>>>>>> 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.
>>>>>>> 
>>>>>>> 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 
>>>>>>>> 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 
>>>>>>> "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.
>>>>>>> 
>>>>>>> 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).
>>>>>>> 
>> _____________________________________________________________________
>> _______ _____________________________________________
>>> 
> ______________________________________________________________________
> ___________________________________________________
> 
> 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.

---

From: Gonzalo Salgueiro <[email-masked]>
Date: Tue, 2 Oct 2012 11:00:42 -0400

Thanks John. While you might be able to squeak by with 32k ADPCM, it is far from ideal and certainly not recommended. The reality is passthrough => G.711, so the text should represent that. I really like the proposed text and would prefer we move forward with that.

Gonzalo

On Oct 2, 2012, at 9:37 AM, John Atkinson wrote:

>>>> privileged

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 15 Oct 2012 10:32:50 +0000

Hi,

When we're doing this, I wonder whether it would be useful to define a feature capability indicator in the same shot.

I don't have a use-case at the moment, but I guess there could also be a need for media aware intermediaries to indicate their fax capabilities.

Regards,

Christer

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Gonzalo Salgueiro
Sent: 2. lokakuuta 2012 18:01
To: John Atkinson
Cc: Dale R. Worley; DISPATCH
Subject: Re: [dispatch] draft-hanes-dispatch-fax-capability-02

Gonzalo

On Oct 2, 2012, at 9:37 AM, John Atkinson wrote:

> G.726 spec says that 32kbps adpcm may handle  up to 2400bps, so it 
> won't handle fax very well.  Therefore, I agree that we don't need to 
> include G.726-32 as a passthrough alternative.  The quote from G.726 
> below also indicates G.726-40 can only handle 12000bps - so again not 
> suitable for fax passthrough
> 
> 
> 
> I.8 Data performance
> Voiceband data performance up to 2400 bit/s using, for example modems 
> conforming to Recommendation V.21, V.22 bis, V.23 and V.26 ter, will 
> not be subject to significant degradation over 32 kbit/s ADPCM links provided the numbers of such links do not exceed the limits of Recommendation G.113.
> Voiceband data performance at 4800 bit/s using, for example modems 
> conforming to Recommendation V.27 bis, can be accommodated with 32 
> kbit/s ADPCM but will be subject to additional degradations over and 
> above that expected from standard 64 kbit/s PCM links. More care will need to be exercised in using such a service.
> Behalf Of David Hanes
>>> 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
>>> 
>>> 
>>> 
>>> 
>>>>>>>>>> The "t38" value is better described as "supports the 
>>>>>>>>>> image/t38 media type[RFC3362] which encodes page images using 
>>>>>>>>>> the ITU-T
>>>>>>>>>> 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 
>>>>>>>>> With that being said, wouldn't just referencing G.711 be 
>>>>>>>>> enough from a media feature tag and user preference perspective?
>>>>>>>>> 
>>>>>>>> - from the PCM octets, an analog signal is constructed via 
>>>>>>>> G.711 (PCMA  or PCMU)
>>>>>>>> 
>>>>>>>> So to specify how meaning is encoded in the packets, you need 
>>>>>>>> to specify that entire stack of standards.  Or, to ensure 
>>>>>>>> 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.
>>>>>>>> 
>>>>>>>>>> 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?
>>> ____________________________________________________________________
>>> _ _______ _____________________________________________
>>>> 
>> _ ___________________________________________________
>>

---

From: "DRAGE, Keith (Keith)" <[email-masked]>
Date: Mon, 15 Oct 2012 12:59:14 +0200

If you are doing that, then surely you need to define feature capability indicator equivalents for all the existing media related media feature tags as well.

Regards

Keith

> Behalf Of Christer Holmberg
> Sent: 15 October 2012 11:33
> To: 'Gonzalo Salgueiro'; John Atkinson
> When we're doing this, I wonder whether it would be useful to define a
> feature capability indicator in the same shot.
>
> I don't have a use-case at the moment, but I guess there could also be a
> need for media aware intermediaries to indicate their fax capabilities.
>
> Regards,
>
> Christer
>
>
>
>
>
> Behalf Of Gonzalo Salgueiro
> Thanks John. While you might be able to squeak by with 32k ADPCM, it is
> far from ideal and certainly not recommended. The reality is passthrough
> => G.711, so the text should represent that. I really like the proposed
> text and would prefer we move forward with that.
>
> Gonzalo
>
> > not be subject to significant degradation over 32 kbit/s ADPCM links
> provided the numbers of such links do not exceed the limits of
> Recommendation G.113.
> > above that expected from standard 64 kbit/s PCM links. More care will
> need to be exercised in using such a service.
> > I will let other folks on this list who have an expertise in FoIP also
> chime in here but I have never seen passthrough with G.726 implemented in
> the real world and in my own lab testing it was not as reliable as G.711.
> Also, the reference to V.152 is simply for implementation assistance. The
> G.726 codec is not mentioned in the sections I reference and I have not
> seen V.152 implemented in the real world either. My point here is that in
> reality neither G.726 nor V.152 are practical alternatives that have any
> sort of widespread adoption. So, I question whether folks will find it
> confusing when in reality only G.711 is being used for fax passthrough. In
> fact, I think you could make the argument that bringing up G.726 or any
> other codec in this draft could actually introduce some confusion.
> >
> > The reason that we need to be restrictive on the codec is that if
> multiple codecs are supported for passthrough then you could run into the
> scenario where UAs express a preference for passthrough but they are each
> using a different codec. This could lead to a mismatch scenario where the
> fax call fails. With G.711 being the only codec for a passthrough
> preference, then this scenario should not occur. I am not sure that we
> want to create the ability to have UAs expressing a passthrough preference
> with the potential for mismatched codecs. An option here would be to
> explicitly define other passthrough codec options but that seems
> unnecessary with G.711 being the de facto standard. Another option would
> be to go down this path and then hope that the UAs could negotiate a
> passthrough codec that works for both. However, you still have the
> possibility of the UAs not agreeing on a common passthrough codec.
> Restricting the codec to G.711 for passthrough ensures that UAs that
> express a passthrough preference will be using the same codec. I hope my
> thinking here makes sense and is inline with how preferences are supposed
> to function.
> >
> > -David
> >
> >
> >
> >> I don't see a strong need to explicitly mention G.726 (G.726 is just an
> example anyway) but I find a bit confusing to create a definition of pass-
> through that is more restrictive than the one used in V.152. If there is a
> good reason for doing that, I think we should explain it somewhere in the
> draft...
> >>
> >> BC
> >>
> >>
> >>
> >> 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.
> >>
> >> privileged information that may be protected by law; they should not be
> distributed, used or copied without authorisation.

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 15 Oct 2012 11:21:44 +0000

Hi, 

>If you are doing that, then surely you need to define feature capability indicator equivalents for all the existing media related media feature tags as well.

Maybe we'll need to do that at some point, but I don't see why we should have to do that just because we define one for fax.

Regards,

Christer

> I don't have a use-case at the moment, but I guess there could also be 
> a need for media aware intermediaries to indicate their fax capabilities.
>
> Regards,
>
> Christer
>
>
>
>
>
> Thanks John. While you might be able to squeak by with 32k ADPCM, it 
> is far from ideal and certainly not recommended. The reality is 
> passthrough => G.711, so the text should represent that. I really like 
> the proposed text and would prefer we move forward with that.
>
> Gonzalo
>
> > won't handle fax very well.  Therefore, I agree that we don't need 
> > to include G.726-32 as a passthrough alternative.  The quote from 
> > G.726 below also indicates G.726-40 can only handle 12000bps - so 
> > again not suitable for fax passthrough
> >
> >
> >
> > I.8 Data performance
> > Voiceband data performance up to 2400 bit/s using, for example 
> > modems conforming to Recommendation V.21, V.22 bis, V.23 and V.26 
> > ter, will not be subject to significant degradation over 32 kbit/s 
> > ADPCM links
> chime in here but I have never seen passthrough with G.726 implemented 
> in the real world and in my own lab testing it was not as reliable as G.711.
> G.726 codec is not mentioned in the sections I reference and I have 
> not seen V.152 implemented in the real world either. My point here is 
> that in reality neither G.726 nor V.152 are practical alternatives 
> that have any sort of widespread adoption. So, I question whether 
> folks will find it confusing when in reality only G.711 is being used 
> for fax passthrough. In fact, I think you could make the argument that 
> bringing up G.726 or any other codec in this draft could actually introduce some confusion.
> >
> multiple codecs are supported for passthrough then you could run into 
> the scenario where UAs express a preference for passthrough but they 
> are each using a different codec. This could lead to a mismatch 
> scenario where the fax call fails. With G.711 being the only codec for 
> a passthrough preference, then this scenario should not occur. I am 
> not sure that we want to create the ability to have UAs expressing a 
> passthrough preference with the potential for mismatched codecs. An 
> option here would be to explicitly define other passthrough codec 
> options but that seems unnecessary with G.711 being the de facto 
> standard. Another option would be to go down this path and then hope 
> that the UAs could negotiate a passthrough codec that works for both. 
> However, you still have the possibility of the UAs not agreeing on a common passthrough codec.
> express a passthrough preference will be using the same codec. I hope 
> my thinking here makes sense and is inline with how preferences are 
> supposed to function.
> >
> > -David
> >
> >
> >
> example anyway) but I find a bit confusing to create a definition of 
> pass- through that is more restrictive than the one used in V.152. If 
> there is a good reason for doing that, I think we should explain it 
> somewhere in the draft...
> >>
> >> BC
> >>
> >>
> >>
> >>> septembre 2012 22:39 À : CHATRAS Bruno RD-CORE Cc : James 
> >>> Rafferty; Gonzalo Salgueiro; Paul Kyzivat; Dale R. Worley; DISPATCH Objet : Re:
> >>> 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?
> >>>>> De : [email-masked] 
> >>>>> [mailto:[email-masked]]
> >>>>> De la
> >>> part
> >>>>> de James Rafferty
> >>>>> From: [email-masked] 
> >>>>> [mailto:[email-masked]]
> >>>>> On
> >>> Behalf
> >>>>> Of Gonzalo Salgueiro
> >>>>>>>>>> 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?
> >>>>>>>>
> >>>>>>>> image/t38 makes it impossible to use the +sip.app-subtype 
> >>>>>>>> media feature tag to select fax-capable UAs.)
> >>>>>>>>
> >>>>>>>> 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
> >>>>>>>>> shouldn't they handle the T.38 attribute 
> >>>>>>>>> exchange/negotiation
> within SDP?
> >>>>>>>> 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".
> >>>>>>>>
> >>>>>>>> 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 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.
> >>>>>>>>>> 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.
> >>>>>>>>
> >>>>>>>> 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".
> >>>>>>>>
> >>>>>>>>> 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.
> >>>>>>>>
> >>>>>>>> ensures interoperability, but it does not (in practice) 
> >>>>>>>> further constrain any
> >>>>> implementation.
> >>>>>>>>
> >>>>>>>>>> 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.
> >>>>>>>>>
> >>> __________________________________________________________________
> >>> __ _ _______ _____________________________________________
> >>>>
> >> ___________________________________________________________________
> >> __ _ ___________________________________________________
> >>
> >> 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
> d'alteration, France Telecom - Orange decline toute responsabilite si 
> ce message a ete altere, deforme ou falsifie. Merci.
> >>

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 15 Oct 2012 09:33:36 -0400

> I don't have a use-case at the moment, but I guess there could also be a need for media aware intermediaries to indicate their fax capabilities.

What does it mean for an intermediary to have fax capabilitity?
Fax is an endpoint feature. It should not be necessary for 
intermediaries to be involved, other than in the sense that they are 
involved in the general process of session establishment.

It is a *bad* thing if every time we define a new endpoint feature we 
then have to consider extending intermediates to support it. This is 
exactly contrary to the philosophy of the internet.

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 15 Oct 2012 13:57:33 +0000

Hi, 

>Fax is an endpoint feature. It should not be necessary for intermediaries to be involved, other than in the sense that they are involved in the general process of session establishment.

I was thinking whether there e.g. could be some mixer entity, which needs to support specific fax mechanisms. But, maybe that's not the case.

Regards,

Christer

---

From: Paul Kyzivat <[email-masked]>
Date: Mon, 15 Oct 2012 10:06:24 -0400

> I was thinking whether there e.g. could be some mixer entity, which needs to support specific fax mechanisms. But, maybe that's not the case.

Say more.

I can see how a conference focus (one sort of mixer) might want to 
indicate support for fax. But then a conference focus will typically be 
viewed as an endpoint, not an intermediary.

In what circumstance is an intermediary (in the sense you mean) a mixer?

	Thanks,
	Paul

---

From: Christer Holmberg <[email-masked]>
Date: Mon, 15 Oct 2012 14:21:31 +0000

Hi, 

> I can see how a conference focus (one sort of mixer) might want to indicate support for fax. But then a conference focus will typically be viewed as an endpoint, not an intermediary.
>

I don't have any use-case at moment. OTOH, the hasn't been really much (if any) focus on fax when int intermediary media functions have been discussed.

But, keep in mind that the reason for proxy-feature was that the intermediaries could not be seen as endpoints (read: they could not be represented by the contact uri).

Anyway, no need to speculate. If there at some point will be a need for a fax fci we can discuss it :)

Regards,

Christer

---

From: Gonzalo Salgueiro <[email-masked]>
Date: Mon, 15 Oct 2012 13:05:51 -0400

> Anyway, no need to speculate. If there at some point will be a need for a fax fci we can discuss it :)

My intent was very deliberately endpoint focused.  I don't have a real use case I can think of for intermediaries requiring definition of a feature capability indicator. I think it is something worth thinking about and something I'd be happy to work with you on but I'd prefer it be separate from this very simple and scope restricted draft.

Cheers,

Gonzalo