Re: FW: Where H.245 goes - MG or MGC (Skran's comments)
Hi Well - it seems we are getting pretty religious about this issue. My take: For a simple toll by-pass application - it makes sense to route H.245 to the MGC. The MG is "dumb" - all decisions are centralized - and life is simple :) However, if we believe that the real future of VoIP is in adding functionality and services, that there will be instances when H.323 end points also are involved, and multimedia is important, a case can be made for that the MG should support H.245. I believe that in reaching a sensible conclusion we should also look at enterprise connections that utilize Q.931 or Q.SIG for signaling. My question - can't we allow for both? Ami -----Original Message----- From: Flemming Andreasen [SMTP:fandreas@telcordia.com] Sent: Wednesday, March 10, 1999 4:58 PM To: ITU-SG16@mailbag.cps.intel.com Subject: Re: FW: Where H.245 goes - MG or MGC (Skran's comments) I will agree with that. Let's not forget that we are addressing "decomposed gateways". As Dave pointed, out GW = MGC + MG + SG so there's no argument there. Also, the idea with the decompostion is precisely that; to decompose the GW into its logical components that each address different aspects of the combined GW. The MGC is the one with the intelligence/control/complexity, or whatever we want to call it, and as Brian pointed out earlier the bearer part is in the MG. Thus Dave's arguments still stand, and H.245 should be in the MGC, not the MG. Regards Flemming Andreasen "David R. Oran" <oran@cisco.com> on 03/10/99 09:33:05 AM To: "Taylor, Tom-PT [SKY:B318-I:EXCH]" <taylor@americasm01.nt.com>, "Mailing list for parties associated with ITU-T Study Group 16" <ITU-SG16@mailbag.cps.intel.com> cc: megaco@BayNetworks.COM (bcc: Flemming Andreasen/Bellcore) Subject: RE: FW: Where H.245 goes - MG or MGC (Skran's comments) Dale's arguments are impeccable if one believes that MGCs are gatekeepers, which they're not. MGCs and MGs are a single H.323 endpoint, ripped apart and put in different boxes. The Megaco protocol glues the boxes together. If you put all of H.323 in the MG then you have no need of an MGC in the first place. QED. I don't think anyone proposes declaring that monolithic H.323 endpoints (i.e. MGC+MG+SG) must be split up. Heavens, many of us sell hundreds of these every day and they work just fine, thank you. So, I think I agree with Tom that this response is interesting but not terribly relevant to the engineering tradeoffs in marrying Megaco to H.323.
-----Original Message----- From: owner-megaco@BayNetworks.COM [mailto:owner-megaco@BayNetworks.COM]On Behalf Of Taylor, Tom-PT [SKY:B318-I:EXCH] Sent: Wednesday, March 10, 1999 8:54 AM To: Mailing list for parties associated with ITU-T Study Group 16 Cc: megaco@BayNetworks.COM Subject: RE: FW: Where H.245 goes - MG or MGC (Skran's comments)
I'll forward this to the Megaco list. One point, though. Just because call signalling is in the MGC doesn't mean we have a GK-routed model: the MGC is part of the Gateway in the SG 16 architecture and TIPHON's. (Its relationship to the H.323 architecture is unstated in Megaco, except that we cite the TIPHON architecture as an example.)
-----Original Message----- From: Dale L. Skran [SMTP:dskran@ASCEND.COM] Sent: Tuesday, March 09, 1999 12:22 PM To: ITU-SG16@MAILBAG.INTEL.COM Subject: Re: FW: Where H.245 goes - MG or MGC (Skran's comments)
See detailed comments below.
Dale Skran Q13 rapporteur
At 12:07 PM 3/8/99 -0600, Tom-PT Taylor wrote:
-----Original Message----- From: David R. Oran [SMTP:oran@cisco.com] Sent: Monday, March 08, 1999 10:25 AM To: megaco Subject: Where H.245 goes - MG or MGC
Here are some random thoughts on one of the questions of marrying Megaco with H.323 - where H.245 goes. Some prior messages have indicated that there are tradeoffs involved here, and I agree. Some food for thought:
- If we terminate H.245 on the MG, this blows away V2 fast start, and looking at likely call flows may introduce 1/2 RTT extra over a monolothic H.323 gateway.
If GW A sends a setup with an OLC to GW B, H.225.0 and H.245 both go between the GWs and fast start works fine. The penalty of not using fast start only occurs if you want the call signaling going to the controller and the H.245 to the GWs.
In any case, the key word here is OPTIONAL. All three alternatives need to be supported, not just the imposition of the GK-routed call model on all vendors and customers.
a)full GK-routed b)GK routed signaling; H.245 between GWs c)direct call model with H.323 RAS in MGC and H.225.0/H.245 between GWs
- The MGC may wish to participate in CAPs exchange for
policy reasons.
Of course, and this should be the MGC's choice to force the GK-routed call model just as is currently the case.
- The H.245 open logical channel operation is analogous
establishment on the MG in the ATM case, and for
to doing VC parallelism might be best
done MG-MG. It is also where certain resource allocation operations get
This is part of the case for doing H.245 between GWs rather than through the controller.
done and hence synchronizes well with the H.323 model of error reporting. Unfortunately, putting CAPs excahnge in one association and logical channel control in a different association would be a pretty major tweak to H.323.
There is a mental leap here that is not clear; why would this be done?
- Putting H.245 completely on the MG factors the problem
among different media description syntaxes (e.g. H245/ASN1 vs SDP) -
of translating the
MGC-MG protocol then might not need to have a full-blown media description in it when using H.323 for global signaling.
Indeed, another good reason for H.245 between the GWs.
- Putting H.245 on the MG gives the MG a lot of autonomy. This is
arguably
more autonomy than the Megaco model should assign to the MG.
Different strokes for different folks. Different customers will take each approach.
- Splitting up H.323 with H.225 signaling in one place and H.245
in another place may uncover some state coordination issues which would (unneccesarily?) complicate the MGC-MG protocol and
signaling possibly introduce
direct H.323 dependencies.
Certainly this is possible, although there are vendors who do this right now (how about a posting?). It is difficult to not have H.323 dependencies in a protocol to decompose an H.323 GW.
My intuition says that the tradeoffs favor keeping H.245
in the MGC. What
do others think?
The arguements presented here indicate the opposite; that H.245 should optionally go between the GWs, as well as H.225.0 call signaling.
Beware the black/white view. Different customers will use the products in different ways.
Amir, I would like to comment on your response, for the purpose of understanding the issues better. --Hong
Hi
Well - it seems we are getting pretty religious about this issue.
Maybe some technical discussions will help.
My take:
For a simple toll by-pass application - it makes sense to route H.245 to the MGC. The MG is "dumb" - all decisions are centralized - and life is simple :)
The main purpose is separate of concerns: the MGC handles signaling while the MG handles media streams. The scripting capability will minimize the messaging traffic between the MGC and the MG, and as a side effect, give the MG certain intelligence. But all these are under the control of MGC.
However, if we believe that the real future of VoIP is in adding functionality and services, that there will be instances when H.323 end points also are involved, and multimedia is important, a case can be made for that the MG should support H.245.
I would like to see concrete examples and sound technical arguments for your claim. Maybe you can show a few call flows that really demonstrate the needs to have H.245 down in the MG that could not be handled gracefully otherwise. This will really help both sides understand each other better.
I believe that in reaching a sensible conclusion we should also look at enterprise connections that utilize Q.931 or Q.SIG for signaling.
I would also like to see call flows and technical arguments for these cases.
My question - can't we allow for both?
Ami
-----Original Message----- From: Flemming Andreasen [SMTP:fandreas@telcordia.com] Sent: Wednesday, March 10, 1999 4:58 PM To: ITU-SG16@mailbag.cps.intel.com Subject: Re: FW: Where H.245 goes - MG or MGC (Skran's comments)
I will agree with that. Let's not forget that we are addressing "decomposed gateways". As Dave pointed, out GW = MGC + MG + SG so there's no argument there. Also, the idea with the decompostion is precisely that; to decompose the GW into its logical components that each address different aspects of the combined GW. The MGC is the one with the intelligence/control/complexity, or whatever we want to call it, and as Brian pointed out earlier the bearer part is in the MG. Thus Dave's arguments still stand, and H.245 should be in the MGC, not the MG.
Regards
Flemming Andreasen
"David R. Oran" <oran@cisco.com> on 03/10/99 09:33:05 AM
To: "Taylor, Tom-PT [SKY:B318-I:EXCH]" <taylor@americasm01.nt.com>, "Mailing list for parties associated with ITU-T Study Group 16" <ITU-SG16@mailbag.cps.intel.com> cc: megaco@BayNetworks.COM (bcc: Flemming Andreasen/Bellcore) Subject: RE: FW: Where H.245 goes - MG or MGC (Skran's comments)
Dale's arguments are impeccable if one believes that MGCs are gatekeepers, which they're not. MGCs and MGs are a single H.323 endpoint, ripped apart and put in different boxes. The Megaco protocol glues the boxes together. If you put all of H.323 in the MG then you have no need of an MGC in the first place. QED.
I don't think anyone proposes declaring that monolithic H.323 endpoints (i.e. MGC+MG+SG) must be split up. Heavens, many of us sell hundreds of these every day and they work just fine, thank you.
So, I think I agree with Tom that this response is interesting but not terribly relevant to the engineering tradeoffs in marrying Megaco to H.323.
-----Original Message----- From: owner-megaco@BayNetworks.COM [mailto:owner-megaco@BayNetworks.COM]On Behalf Of Taylor, Tom-PT [SKY:B318-I:EXCH] Sent: Wednesday, March 10, 1999 8:54 AM To: Mailing list for parties associated with ITU-T Study Group 16 Cc: megaco@BayNetworks.COM Subject: RE: FW: Where H.245 goes - MG or MGC (Skran's comments)
I'll forward this to the Megaco list. One point, though. Just because call signalling is in the MGC doesn't mean we have a GK-routed model: the MGC is part of the Gateway in the SG 16 architecture and TIPHON's. (Its relationship to the H.323 architecture is unstated in Megaco, except that we cite the TIPHON architecture as an example.)
-----Original Message----- From: Dale L. Skran [SMTP:dskran@ASCEND.COM] Sent: Tuesday, March 09, 1999 12:22 PM To: ITU-SG16@MAILBAG.INTEL.COM Subject: Re: FW: Where H.245 goes - MG or MGC (Skran's comments)
See detailed comments below.
Dale Skran Q13 rapporteur
At 12:07 PM 3/8/99 -0600, Tom-PT Taylor wrote:
-----Original Message----- From: David R. Oran [SMTP:oran@cisco.com] Sent: Monday, March 08, 1999 10:25 AM To: megaco Subject: Where H.245 goes - MG or MGC
Here are some random thoughts on one of the questions of marrying Megaco with H.323 - where H.245 goes. Some prior messages have indicated that there are tradeoffs involved here, and I agree. Some food for thought:
- If we terminate H.245 on the MG, this blows away V2 fast start, and looking at likely call flows may introduce 1/2 RTT extra over a monolothic H.323 gateway.
If GW A sends a setup with an OLC to GW B, H.225.0 and H.245 both go between the GWs and fast start works fine. The penalty of not using fast start only occurs if you want the call signaling going to the controller and the H.245 to the GWs.
In any case, the key word here is OPTIONAL. All three alternatives need to be supported, not just the imposition of the GK-routed call model on all vendors and customers.
a)full GK-routed b)GK routed signaling; H.245 between GWs c)direct call model with H.323 RAS in MGC and H.225.0/H.245 between GWs
- The MGC may wish to participate in CAPs exchange for
policy reasons.
Of course, and this should be the MGC's choice to force the GK-routed call model just as is currently the case.
- The H.245 open logical channel operation is analogous
establishment on the MG in the ATM case, and for
to doing VC parallelism might be best
done MG-MG. It is also where certain resource allocation operations get
This is part of the case for doing H.245 between GWs rather than through the controller.
done and hence synchronizes well with the H.323 model of error reporting. Unfortunately, putting CAPs excahnge in one association and logical channel control in a different association would be a pretty major tweak to H.323.
There is a mental leap here that is not clear; why would this be done?
- Putting H.245 completely on the MG factors the problem
among different media description syntaxes (e.g. H245/ASN1 vs SDP) -
of translating the
MGC-MG protocol then might not need to have a full-blown media description in it when using H.323 for global signaling.
Indeed, another good reason for H.245 between the GWs.
- Putting H.245 on the MG gives the MG a lot of autonomy. This is
arguably
more autonomy than the Megaco model should assign to the MG.
Different strokes for different folks. Different customers will take each approach.
- Splitting up H.323 with H.225 signaling in one place and H.245
in another place may uncover some state coordination issues which would (unneccesarily?) complicate the MGC-MG protocol and
signaling possibly introduce
direct H.323 dependencies.
Certainly this is possible, although there are vendors who do this right now (how about a posting?). It is difficult to not have H.323 dependencies in a protocol to decompose an H.323 GW.
My intuition says that the tradeoffs favor keeping H.245
in the MGC. What
do others think?
The arguements presented here indicate the opposite; that H.245 should optionally go between the GWs, as well as H.225.0 call signaling.
Beware the black/white view. Different customers will use the products in different ways.
-----Original Message----- From: owner-megaco@BayNetworks.COM [mailto:owner-megaco@BayNetworks.COM]On Behalf Of Ami Amir Sent: Wednesday, March 10, 1999 9:26 PM To: 'Mailing list for parties associated with ITU-T Study Group 16' Cc: 'megaco@BayNetworks.COM' Subject: RE: FW: Where H.245 goes - MG or MGC (Skran's comments)
Hi
Well - it seems we are getting pretty religious about this issue.
Moi?
My take:
For a simple toll by-pass application - it makes sense to route H.245 to the MGC. The MG is "dumb" - all decisions are centralized - and life is simple :)
However, if we believe that the real future of VoIP is in adding functionality and services, that there will be instances when H.323 end points also are involved, and multimedia is important, a case can be made for that the MG should support H.245.
I believe that in reaching a sensible conclusion we should also look at enterprise connections that utilize Q.931 or Q.SIG for signaling.
My question - can't we allow for both?
As I pointed out in my original tradeofs note (which was at least *intended* to be technically oriented and politically neutral), if you put the H.225 signaling exchanges as MGC-MGC and the H.245 exchanges as MG-MG we need to assure ourselves that either: 1) there is no state coupling between H.225 and H.245 that fails if the two aren't running in the same box, or 2) the MGC-MG protocol explicitly carries the information needed for this state coupling. In case 2, we also need to analyze whether there is significant performance impact in carrying the state coupling and whether the tradeoffs still favor H.245 in the MG for some cases. As a simple example, H.225 carries the IP address and port to run H.245 on. At the very least this information would need to be conveyed from the MGC to the MG in the Megaco protocol. Christian Huitema mentioned one quite reasonable way to do this in the MGCP case by describing the H.245 addressing in an SDP announcement with m=H.245. Another example is the fate-sharing between the H.225 connection and the H.245 connection. I forget whether it's the H.225 or H.245 connection which determines the "liveness" of the end-to-end session, but if it's the H.245 connection alone this introduces some complications in maintaining MGC state. It would take someone much more expert than I in H.323 to ascertain what the exact scope of the state coupling is. I don't think anyone wants to BAN H.245 in the MG; just that there are a lot of potentially subtle technical points and the difficulties might be sufficiently large to warrant real caution. Two issues that particularly trouble me are: a) giving up the ability for the MGC to see and modify the capabilities exchanges for policy or other reasons. b) giving up the ability to put the audio logical channels on one MG and the video logical channels on another MG for the same session.
Ami
Now, a meta question, for my edification. Do people interpret this as a purely technical posting (as intended) or are we so polarized that every technical point seems laden with politico-religious portents. Dave.
At 10:41 AM 3/11/99 -0500, David R. Oran wrote:
-----Original Message----- From: owner-megaco@BayNetworks.COM [mailto:owner-megaco@BayNetworks.COM]On Behalf Of Ami Amir Sent: Wednesday, March 10, 1999 9:26 PM To: 'Mailing list for parties associated with ITU-T Study Group 16' Cc: 'megaco@BayNetworks.COM' Subject: RE: FW: Where H.245 goes - MG or MGC (Skran's comments)
Hi
Well - it seems we are getting pretty religious about this issue.
Moi?
My take:
For a simple toll by-pass application - it makes sense to route H.245 to the MGC. The MG is "dumb" - all decisions are centralized - and life is simple :)
However, if we believe that the real future of VoIP is in adding functionality and services, that there will be instances when H.323 end points also are involved, and multimedia is important, a case can be made for that the MG should support H.245.
I believe that in reaching a sensible conclusion we should also look at enterprise connections that utilize Q.931 or Q.SIG for signaling.
My question - can't we allow for both?
As I pointed out in my original tradeofs note (which was at least *intended* to be technically oriented and politically neutral), if you put the H.225 signaling exchanges as MGC-MGC and the H.245 exchanges as MG-MG we need to assure ourselves that either: 1) there is no state coupling between H.225 and H.245 that fails if the two aren't running in the same box, or 2) the MGC-MG protocol explicitly carries the information needed for this state coupling.
In case 2, we also need to analyze whether there is significant performance impact in carrying the state coupling and whether the tradeoffs still favor H.245 in the MG for some cases.
As a simple example, H.225 carries the IP address and port to run H.245 on. At the very least this information would need to be conveyed from the MGC to the MG in the Megaco protocol. Christian Huitema mentioned one quite reasonable way to do this in the MGCP case by describing the H.245 addressing in an SDP announcement with m=H.245. Another example is the fate-sharing between the H.225 connection and the H.245 connection. I forget whether it's the H.225 or H.245 connection which determines the "liveness" of the end-to-end session, but if it's the H.245 connection alone this introduces some complications in maintaining MGC state.
It would take someone much more expert than I in H.323 to ascertain what the exact scope of the state coupling is.
I don't think anyone wants to BAN H.245 in the MG; just that there are a lot of potentially subtle technical points and the difficulties might be sufficiently large to warrant real caution. Two issues that particularly trouble me are:
a) giving up the ability for the MGC to see and modify the capabilities exchanges for policy or other reasons. b) giving up the ability to put the audio logical channels on one MG and the video logical channels on another MG for the same session.
Ami
Now, a meta question, for my edification. Do people interpret this as a purely technical posting (as intended) or are we so polarized that every technical point seems laden with politico-religious portents.
I'll count this one as technical! Expect a longer reply to come. Thanks, Dale
Dave.
participants (4)
-
Ami Amir -
Dale L. Skran -
David R. Oran -
Hong Liu