COM16-D275: H.248.CCC connection capability control Package proposal

Albrecht.Schwarz at Albrecht.Schwarz at
Fri Mar 24 10:32:02 EST 2006

Hi YangboLin,

some thoughts in advance.

Your package proposal has similar aspects as the ETSI TISPAN discussion on
the H.248 Connection Model in Profile ES 283 002 for phy-to-RTP
residential/access gateways.

We studied the subject, too (see ALCATEL view in uploaded TISPAN docs in
the xchange area):

TISPAN WG3_TD22_§ 5.3 ConnectionModel Phy-to-Phy.doc 24-Mar-2006 15:52
TISPAN WG3_TD23_§ 5.3 ConnectionModel RTP-to-RTP.doc 24-Mar-2006 15:52

Our understanding is, that the autonomous model is illegal wrt H.248.
Therefore I would disagree in considering the controlled and autonomous
model equally (as in D275).

Our prime concern is, that the MG-autonoumous action in re-directing a
bearer segment (between Ta' and Tb') requires the "correlation of
Termination info" above the Context level.
The aimed functions on bearer connection segments requires firstly
operations on addressing information (plus potentially subsequent routing

Bearing this in mind, I cannot imagine that Ta' and Tb' could be physical
Terminations. Would you agree?
Thus, the scope of your capability could be ephemeral Terminations only.
Concerning ephemerals, there are again two main classes:

1) connection-oriented bearers, and
2) connectionless.

Category (1) requires a dedicated bearer control protocol besides GW
control, - autonomous actions on Ta' and Tb' could mean MG-external bearer
control signalling activity. Actions which would question the Package scope
of "MG internal connections". I would therefore exclude category (1) as

It remains (2): I could only imagine an IP-based ephemeral without any
bearer control protocol (like Q.1970).
If yes, then we are again in the same situation as in the ETSI discussion.

=> the "autonomous model" is (if at all) only applicable for IP and relates
to an "MG-embedded IP (edge) router function" (with certain feedback on
H.248 ...).

The MG-internal redirection of IP bearer connection segments is possible in
some (exceptional) cases, but there isn't any general applicability IMHO,
primarily due to
* IP address/port ranges ("relation to MG capacity")
* multi-homed IP interface
* support of L2VPNs or L3VPNs at MG
* support of multiple IP realms
* ...

Therefore I got some concerns with the approach of a *generic* Package.
An alternative could be the consideration of different H.248 Connection
models in Profiles.

Best regards,

More information about the sg16-avd mailing list