Subject: [Megaco] H.248-controlled T.38 configurations: SDP- vs Property-based H.248 signalling

From: "Schwarz, Albrecht (Albrecht)" <[email-masked]>
Date: Wed, 1 Aug 2012 16:16:56 +0200

[Cc'd megaco list due to H.248.2]

The T.38 parameters as defined by ITU-T T.38 are related to a T.38 endpoint implementation, such as the T.38 user plane interworking function as e.g. located in an H.248 IP-to-TDM media gateway (e.g. 3GPP IM-MGW).

There are fundamentally two signaling options for such T.38 configurations:
a)      SDP-based: using T.38 Annex D defined SDP elements embedded in H.248 descriptors
b)      Property-based: using H.248.2, IP Fax package defined properties, such as specified by clauses 10.1.3 to 10.1.7

Both H.248 signalling options are basically equivalent, - independent of SDP- or Property-based signaling elements. The signaling elements relate to the T.38 endpoint, but NOT to any remote G3FE.
[Note: the H.248 IP fax package version 1 (from 2005/2007) does not yet contain the latest T.38V4 (2010) parameter. But this aspect is irrelevant in this discussion due to the proposal in 3GPP for the SDP-based method.]

Thus,
all "T.38 SDP attributes" (in C3-121327) are related to gateway capabilities (such as supported T.38 configurations by an IM-MGW implementation) (NOTE: attached is T.38 Table B.1 for H.323 gateways, which again underlines the relation to gateway capabilities).
The MGC / MGCF may be either
a)      aware of the supported T.38 configuration(s) by his associated MGs or
b)      unaware.
Awareness may be achieved via auditing or configuration management.
Unawareness is basically possible, but may lead to inefficient or even ineffective H.248 scenarios for T.38.
Dependent on the amount of "supported T.38 configuration(s)" knowledge at MGC level would be the content of the SIP-level SDP O/A procedures.

Conclusions for C3-121327 (http://www.3gpp.org/ftp/tsg_ct/WG3_interworking_ex-CN3/TSGC3_70_Chicago/Docs/C3-121327.zip):
NOTEs 1 and 2 in Table X.3.1 are incorrect in my opinion.
The text related to "remote CS FAX equipment" (term should be anyway replaced by term G3FE) should be just deleted. And there would be correspondent changes at other tables.

-Albrecht

---

From: "Schwarz, Albrecht (Albrecht)" <[email-masked]>
Date: Thu, 2 Aug 2012 10:05:04 +0200

Hello Thomas,

I followed the SIP Forum FoIP thread, but I fail to see that confirmation towards remote G3FE.
Actually it's rather the opposite, see Kevin's reply to you:

> (I did not find any definition of MMR format apart from "Modified

> Modified Read" in T.38. However on Annex VI of T.30, MMR is defined as

> the T.6 encoding. This also matches explanations in Wikipedia)

> *T38FaxTranscodingJBIG*: Indicates the ability to convert to/from JBIG

> to reduce bandwidth. This

> is a boolean parameter (inclusion = true, exclusion = false).

It is possible for a T.30<->T.38 gateway to provide these behaviors if desired, and the resulting T.38 bitstream would differ in some noticeable ways from the T.30 bitstream. However, based on discussions with various knowledgeable parties during our previous work in this group, it appears that it is highly unusual for a T.38 implementation (gateway or terminal) to actually perform any of these three functions.

ð  it's a gateway capability!

ð  all your three referred T.38 parameters are subject of the IM-MGW implementation!
and ALU supports the recommended default values by Table H.2/T.38 (which should be inline with your proposal).

Hence, Kevin explicitly confirms this also as gateway capability!

Regards,
Albrecht

From: Belling, Thomas (NSN - DE/Munich) [mailto:[email-masked]]
Sent: Mittwoch, 1. August 2012 16:46
To: Schwarz, Albrecht (Albrecht); [email-masked]
Subject: RE: H.248-controlled T.38 configurations: SDP- vs Property-based H.248 signalling

Dear Albrecht,

Thanks for your comments.

with respect to T38FaxFillBitRemoval, T38FaxTranscodingMMR and T38FaxTranscodingJBIG SDP attributes, to which Notes 1 and 2 relate,  I had some discussions at the SIP forum FoIP mailing list as you suggested.

And it was confirmed that unless you do some "transcoding" of the payload within T.38 at the MGW, those properties relate to the remote CS FAX endpoint. However, people thought that not signaling those properties in H.248v4 might be OK, because the default values which then apply are likely to be supported by any receiving CS endpoint. The only open issue where I did not yet receive any reply is whether any harm is done if the CS endpoint behaves differently when sending.

Thomas

From: 3GPP_TSG_CT_WG3 - Core Network and Terminals WG 3 [mailto:[email-masked]] On Behalf Of ext Schwarz, Albrecht (Albrecht)
Sent: Wednesday, August 01, 2012 4:17 PM
To: [email-masked]
Subject: H.248-controlled T.38 configurations: SDP- vs Property-based H.248 signalling

 1.  SDP-based: using T.38 Annex D defined SDP elements embedded in H.248 descriptors
 2.  Property-based: using H.248.2, IP Fax package defined properties, such as specified by clauses 10.1.3 to 10.1.7

Thus,

 1.  aware of the supported T.38 configuration(s) by his associated MGs or
 2.  unaware.
Awareness may be achieved via auditing or configuration management.
Unawareness is basically possible, but may lead to inefficient or even ineffective H.248 scenarios for T.38.
Dependent on the amount of "supported T.38 configuration(s)" knowledge at MGC level would be the content of the SIP-level SDP O/A procedures.

-Albrecht

---

From: Christian Groves <[email-masked]>
Date: Fri, 03 Aug 2012 20:35:06 +1000

Hello Albrecht,

Yes I would agree that signalling elements from H.248.2 relate to the 
T.38 termination on a MG, i.e. the endpoint on a local MG. H.245 Annex B 
also indicates that T.38 parameters such as fillBiTRemoval and 
TranscodingJBIG indicate the gateway is in scope.

Regards, Christian

On 2/08/2012 12:16 AM, Schwarz, Albrecht (Albrecht) wrote:
> [Cc’d megaco list due to H.248.2]
> The *T.38 parameters* as defined by ITU-T T.38 are related to a *T.38 
> endpoint implementation*, such as the *T.38 user plane interworking 
> function* as e.g. located in an H.248 IP-to-TDM media gateway (e.g. 
> 3GPP IM-MGW).
>  1. *SDP-based*: using *T.38 Annex D* defined SDP elements embedded in
>     H.248 descriptors
>  2. *Property-based*: using *H.248.2, IP Fax package* defined
>     properties, such as specified by clauses 10.1.3 to 10.1.7
>
> Both H.248 signalling options are basically equivalent, - independent 
> of SDP- or Property-based signaling elements. The signaling elements 
> relate to the T.38 endpoint, but NOT to any remote G3FE.
> [Note: the H.248 IP fax package version 1 (from 2005/2007) does not 
> yet contain the latest T.38V4 (2010) parameter. But this aspect is 
> irrelevant in this discussion due to the proposal in 3GPP for the 
> SDP-based method.]
> Thus,
> all “T.38 SDP attributes” (in C3-121327) are related to gateway 
> capabilities (such as supported T.38 configurations by an IM-MGW 
> implementation) (NOTE: attached is T.38 Table B.1 for H.323 gateways, 
> which again underlines the relation to gateway capabilities).
> Dependent on the amount of “supported T.38 configuration(s)” knowledge 
> at MGC level would be the content of the SIP-level SDP O/A procedures.
> Conclusions for *C3-121327* 
> (_http://www.3gpp.org/ftp/tsg_ct/WG3_interworking_ex-CN3/TSGC3_70_Chicago/Docs/C3-121327.zip_):
> The *text* related to “remote CS FAX equipment” (term should be anyway 
> replaced by term G3FE) should be just *deleted*. And there would be 
> correspondent changes at other tables.
> -Albrecht
>
>
> _______________________________________________
> Megaco mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/megaco

---

From: "Schwarz, Albrecht (Albrecht)" <[email-masked]>
Date: Fri, 3 Aug 2012 10:25:11 +0200

Hello Thomas,
looks like that we are now on the same page, i.e. if the T.38 endpoint (here IM-MGW) would support that capability, then it could be also used in the negotiation of T.38 configurations with the remote T.38 endpoint.
Hence, the T.38 parameters are not related to remote G3FEs.
There would be then following changes in your CRs, let's take Table X.2.1 as example:

Table X.2.1: Recommended configuration for T.38 SDP attribute values.

T38FaxVersion

Version 2 or higher. (NOTE 1)

T38MaxBitRate

14 400

T38FaxFillBitRemoval

FALSE (NOTE 2)

T38FaxTranscodingMMR

FALSE (NOTE 2)

T38FaxTranscodingJBIG

FALSE (NOTE 2)

T38FaxRateManagement

'transferredTCF'

T38FaxMaxBuffer

1800

T38FaxMaxDatagram

At least 150

T38FaxMaxIFP

40 (NOTE 3)

T38FaxUdpEC

't38UDPRedundancy'

T38FaxUdpECDepth

Minred: 1; Maxred: 2 (NOTE 3)

T38FaxUdpFECMaxSpan

3 (NOTE 3)

T38ModemType

't38G3FaxOnly' (NOTE 2, NOTE 3)

NOTE 1:    With Version 4, default values for the SDP attributes apply if the attributes are omitted. However, some values relate to capabilities of the remote CS FAX equipment unknown to the MGCF.

NOTE 2:    This value relates to capabilities of the remote CS FAX equipment unknown to the MGCF. The recommended value (which is also the default value in T.38 version 4) is likely to be supported by FAX equipment in CS networks.

NOTE 3:    Only applicable for T.38 version 4.

Would you agree?
Albrecht

From: Belling, Thomas (NSN - DE/Munich) [mailto:[email-masked]]
Sent: Donnerstag, 2. August 2012 11:03
To: Schwarz, Albrecht (Albrecht); [email-masked]
Subject: RE: H.248-controlled T.38 configurations: SDP- vs Property-based H.248 signalling

Hello Albrecht,

a gateway could support FAX "transcoding", as I like to call it, and then use those parameters. But as Kevin wrote, it is highly unusual for MGW implementations to do so. In my view we should not burden the MGW with such functionality and the benefit is also questionable, in particular because Kevin believes the JBIG and NMR encoding are also rarely used by T.38 terminals. I was rather envisioning a reframing of T.30 at the MGW. Reading your explanation that you support the default values I suspect this is also what your MGW does (as mine). Also in the table B.1 you attached those parameters are "optional". So, depending on MGW implementation, those could either be capabilities of the CS FAX equipment (if a reframing is done at the MGW as I envision), or of the MGW (if the MGW performs FAX "transcoding").

For the 3GPP profiles, we do not necesarrily include any conceivable option but only options with a real benefit. I would prefer not to include FAX "transcoding" for the reasons outlined above. Assuming that we only want to use the default value, it does not need to be signalled to the MGW but can rather be a provisioned value. So I do not see a need to propagate those parameters over the Mn interface.

Perhaps the NOTES should be phrased a bit clearer and include an explanation that only T.30 reframing is included in the Mn profile and under this condition, those SDP attributes relate to capabilities of the CS FAX equipment.

Thomas

From: 3GPP_TSG_CT_WG3 - Core Network and Terminals WG 3 [mailto:[email-masked]] On Behalf Of ext Schwarz, Albrecht (Albrecht)
Sent: Thursday, August 02, 2012 10:05 AM
To: [email-masked]
Subject: Re: H.248-controlled T.38 configurations: SDP- vs Property-based H.248 signalling

Hello Thomas,

Regards,
Albrecht

From: Belling, Thomas (NSN - DE/Munich) [mailto:[email-masked]]
Sent: Mittwoch, 1. August 2012 16:46
To: Schwarz, Albrecht (Albrecht); [email-masked]<mailto:[email-masked]>
Subject: RE: H.248-controlled T.38 configurations: SDP- vs Property-based H.248 signalling

Dear Albrecht,

Thomas

From: 3GPP_TSG_CT_WG3 - Core Network and Terminals WG 3 [mailto:[email-masked]] On Behalf Of ext Schwarz, Albrecht (Albrecht)
Sent: Wednesday, August 01, 2012 4:17 PM
To: [email-masked]<mailto:[email-masked]>
Subject: H.248-controlled T.38 configurations: SDP- vs Property-based H.248 signalling

Thus,

-Albrecht

---

From: "Schwarz, Albrecht (Albrecht)" <[email-masked]>
Date: Fri, 3 Aug 2012 11:09:47 +0200

With below indicated changes, we recommended the default settings for those T.38 parameters, which is FALSE (i.e., 3GPP profiles would then recommend NOT to use such T.38 configurations).

Clause X.2 provides a RECOMMENDATION on T.38 configuration(s).
Clause X.3 the correspondent negotiation procedures.

I think that the prescriptive language between both clauses must be consistent (which isn't yet entirely the case in my opinion).

E.g., Table X.3.1:

T38FaxTranscodingJBIG

Accept offer with value "FALSE" or parameter omitted. Otherwise reject offer (NOTE 3).

Do not include parameter in the answer. (NOTE 2)

ð  Instead of "Otherwise reject offer (NOTE 3)." we should rather specify
"Otherwise, offer SHOULD be rejected (NOTE x)" and

NOTE x - This parameter is not recommended to use, but there might be remote T.38 endpoints with support of that capability. In order to improve the probability of a final successful T.38 call, the remote T.38 endpoint should be indicated not to use this T.38 capability (see ANSWER).

A pure rejection of the OFFER would immediately lead to an unsuccessful T. 38 call.

/Albrecht

From: Belling, Thomas (NSN - DE/Munich) [mailto:[email-masked]]
Sent: Freitag, 3. August 2012 10:46
To: Schwarz, Albrecht (Albrecht); [email-masked]
Subject: RE: H.248-controlled T.38 configurations: SDP- vs Property-based H.248 signalling

Dear Albrecht,

my proposal is still not include FAX "transcoding" in the 3GPP profile. Is that acceptable to you?

Thomas

From: ext Schwarz, Albrecht (Albrecht) [mailto:[email-masked]]
Sent: Friday, August 03, 2012 10:25 AM
To: Belling, Thomas (NSN - DE/Munich); [email-masked]
Cc: [email-masked]
Subject: RE: H.248-controlled T.38 configurations: SDP- vs Property-based H.248 signalling

Hello Thomas,

T38FaxVersion

T38MaxBitRate

14 400

T38FaxFillBitRemoval

FALSE (NOTE 2)

T38FaxTranscodingMMR

FALSE (NOTE 2)

T38FaxTranscodingJBIG

FALSE (NOTE 2)

T38FaxRateManagement

'transferredTCF'

T38FaxMaxBuffer

1800

T38FaxMaxDatagram

At least 150

T38FaxMaxIFP

40 (NOTE 3)

T38FaxUdpEC

't38UDPRedundancy'

T38FaxUdpECDepth

T38FaxUdpFECMaxSpan

3 (NOTE 3)

T38ModemType

Would you agree?
Albrecht

Hello Albrecht,

Thomas

Hello Thomas,

Regards,
Albrecht

Dear Albrecht,

Thomas

Thus,

-Albrecht

---

From: "Schwarz, Albrecht (Albrecht)" <[email-masked]>
Date: Fri, 3 Aug 2012 16:44:24 +0200

Thomas, hm ...

1st We do not need any new terminology in 3GPP, thus "CS FAX equipment" must be replaced with term "G3FE" (T.38, cl. 3.3).

2nd There is no need to consider remote G3FE capabilities in detail (concerning your referred parameters), however, with the exception of V.34-capable G3FE or non-V.34-capable G3FE.

Thus:
3rd We may only talk about "T.38 endpoints", - and there are two types "T.38/G3" and "T.38/V.34G3", see T.38, cl. 3.4 and 3.5.

=>
In the 3GPP Mn H.248 profile, it is recommended not to use this T.38 endpoint capability. When sent by the MGCF, this value would relate to a T.38 endpoint with support of that capability. The recommended value (which is also the default value in T.38 version 4) is likely to be supported by existing T.38 endpoint implementations.

/Albrecht

From: Belling, Thomas (NSN - DE/Munich) [mailto:[email-masked]]
Sent: Freitag, 3. August 2012 15:19
To: Schwarz, Albrecht (Albrecht); [email-masked]
Subject: RE: H.248-controlled T.38 configurations: SDP- vs Property-based H.248 signalling

Thanks Albrecht,

I can accept your last proposal.

For your previous suggested change, given that the 3GPP Profile will not support FAX transcoding (it seems you agree) perhaps we should not entirely remove those notes from table x.2.1. I can accept your change to Note 1. For Note 2, we could write:

In the 3GPP Mn H.248 profile, the T.30 protocol layer embedded within T.38 is not modified. When sent by the MGCF, this value thus relates to capabilities of the remote CS FAX equipment unknown to the MGCF. The recommended value (which is also the default value in T.38 version 4) is likely to be supported by FAX equipment in CS networks.

Thomas

From: 3GPP_TSG_CT_WG3 - Core Network and Terminals WG 3 [mailto:[email-masked]] On Behalf Of ext Schwarz, Albrecht (Albrecht)
Sent: Friday, August 03, 2012 11:10 AM
To: [email-masked]
Subject: Re: H.248-controlled T.38 configurations: SDP- vs Property-based H.248 signalling

E.g., Table X.3.1:

T38FaxTranscodingJBIG

/Albrecht

Dear Albrecht,

Thomas

From: ext Schwarz, Albrecht (Albrecht) [mailto:[email-masked]]
Sent: Friday, August 03, 2012 10:25 AM
To: Belling, Thomas (NSN - DE/Munich); [email-masked]<mailto:[email-masked]>
Cc: [email-masked]<mailto:[email-masked]>
Subject: RE: H.248-controlled T.38 configurations: SDP- vs Property-based H.248 signalling

Hello Thomas,

T38FaxVersion

T38MaxBitRate

14 400

T38FaxFillBitRemoval

FALSE (NOTE 2)

T38FaxTranscodingMMR

FALSE (NOTE 2)

T38FaxTranscodingJBIG

FALSE (NOTE 2)

T38FaxRateManagement

'transferredTCF'

T38FaxMaxBuffer

1800

T38FaxMaxDatagram

At least 150

T38FaxMaxIFP

40 (NOTE 3)

T38FaxUdpEC

't38UDPRedundancy'

T38FaxUdpECDepth

T38FaxUdpFECMaxSpan

3 (NOTE 3)

T38ModemType

Would you agree?
Albrecht

Hello Albrecht,

Thomas

Hello Thomas,

Regards,
Albrecht

Dear Albrecht,

Thomas

Thus,

-Albrecht

---

From: Tom Taylor <[email-masked]>
Date: Fri, 03 Aug 2012 08:41:17 -0700

Albrecht in particular: I'm having to release your messages 
administratively because they are too large. Please:

- delete older portions of your messages when you reply;

- send messages in text only rather than text and HTML.

Thanks,
Tom Taylor