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):

/tsg16/sg16/xchange/wp2/q03 TISPAN WG3_TD22_§ 5.3 ConnectionModel Phy-to-Phy.doc 24-Mar-2006 15:52 229k TISPAN WG3_TD23_§ 5.3 ConnectionModel RTP-to-RTP.doc 24-Mar-2006 15:52 1.9M

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 actions).

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. Right? 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 well.

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, Albrecht