Favicon

H.248-controlled T.38 configurations: SDP- vs Property-based H.248 signalling

[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:
  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).
The MGC / MGCF may be either
  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.
 
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
 
 
 
_______________________________________________
Megaco mailing list
Megaco <at> ietf.org
https://www.ietf.org/mailman/listinfo/megaco
Christian Groves | 3 Aug 2012 12:35

Re: H.248-controlled T.38 configurations: SDP- vs Property-based H.248 signalling

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).
> There are fundamentally two signaling options for such T.38 
> configurations:
>
>  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).
> The MGC / MGCF may be either
>
>  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.
> 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
>
>
> _______________________________________________
> Megaco mailing list
> Megaco <at> ietf.org
> https://www.ietf.org/mailman/listinfo/megaco

Gmane