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.

Would you agree?

Albrecht

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

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

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

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

1. aware of the supported T.38 configuration(s) by his associated MGs or

2. unaware.