- sg16-avd - lists.packetizer.com

Re: FW: Where H.245 goes - MG or MGC (Skran's comments)
by Tom-PT Taylor 10 Mar '99

10 Mar '99

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(a)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 to doing VC > >> establishment on the MG in the ATM case, and for 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 of translating > >> among different media description syntaxes (e.g. H245/ASN1 vs SDP) - > 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 > signaling > >> in another place may uncover some state coordination issues which would > >> (unneccesarily?) complicate the MGC-MG protocol and 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. > > > >

3 2

Re: FW: Where H.245 goes - MG or MGC (Skran's comments)
by Flemming Andreasen 10 Mar '99

10 Mar '99

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(a)cisco.com> on 03/10/99 09:33:05 AM To: "Taylor, Tom-PT [SKY:B318-I:EXCH]" <taylor(a)americasm01.nt.com>, "Mailing list for parties associated with ITU-T Study Group 16" <ITU-SG16(a)mailbag.cps.intel.com> cc: megaco(a)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(a)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(a)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(a)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 > to doing VC > > >> establishment on the MG in the ATM case, and for > 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 > of translating > > >> among different media description syntaxes (e.g. > H245/ASN1 vs SDP) - > > 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 > > signaling > > >> in another place may uncover some state coordination > issues which would > > >> (unneccesarily?) complicate the MGC-MG protocol and > 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. > > > > > > > >

1 0

Re: H.245 and MGs
by Dale L. Skran 09 Mar '99

09 Mar '99

At 05:14 PM 3/9/99 -0500, you wrote: >I forwarded a note from David Oran to this list yesterday, presenting a >number of arguments against placing H.245 with the MG function. I should >have explained the significance of this message. If his arguments are not >rebutted, Megaco will place a very low priority on protocol design to >accommodate any "remoted H.245" arrangement. > >Tom Taylor >E-mail: taylor(a)nortelnetworks.com (internally Tom-PT Taylor) >Tel.: +1 613 736 0961 (internally 396-1490) ***NOTE CHANGE*** >FAX: same number I trust my response was adequate. In any case, we must continue to develop on this list H.GCP in such a way that it meets the needs of those interested in putting H.245 in GWs. Dale Skran >

1 0

Voip
by Jason Chang 09 Mar '99

09 Mar '99

Hi, Joon; Please include me in the QoS discussion THanks Jason Chang jasonc(a)nplab.com

1 0

H.245 and MGs
by Tom-PT Taylor 09 Mar '99

09 Mar '99

I forwarded a note from David Oran to this list yesterday, presenting a number of arguments against placing H.245 with the MG function. I should have explained the significance of this message. If his arguments are not rebutted, Megaco will place a very low priority on protocol design to accommodate any "remoted H.245" arrangement. Tom Taylor E-mail: taylor(a)nortelnetworks.com (internally Tom-PT Taylor) Tel.: +1 613 736 0961 (internally 396-1490) ***NOTE CHANGE*** FAX: same number

1 0

Re: FW: Where H.245 goes - MG or MGC (Skran's comments)
by Dale L. Skran 09 Mar '99

09 Mar '99

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 to doing VC >> establishment on the MG in the ATM case, and for 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 of translating >> among different media description syntaxes (e.g. H245/ASN1 vs SDP) - 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 signaling >> in another place may uncover some state coordination issues which would >> (unneccesarily?) complicate the MGC-MG protocol and 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. >

1 0

Re: call clearing by GK
by Chris Purvis 09 Mar '99

09 Mar '99

Oops! Sorry about the blank response! Let's try again! This isn't QUITE as simple a question as it looks. I'd recommend looking at it from the two separate points of view: >From the endpoint's point of view, I would say the answer is "yes" (as Ritu says). A gatekeeper is allowed to send you a DRQ to clear the call. Depending on how the endpoint is written, though, this may not be trivial to achieve, since without pregranted ARQs it is reasonable for an endpoint to want to match up DRQs with individual ARQs. As a gatekeeper, though, I wonder why one would want to implement that. For the gatekeeper to be aware of a call when using pregranted ARQs, it must be routing call signalling, so it can quite happily terminate the call by means of ReleaseComplete - which will NOT break poorly written endpoints. The related question is whether an endpoint sends a DRQ on "normal" call termination in these cases. If the gatekeeper is routing call-signalling it is arguably unnecessary (ReleaseComplete clears the call); if not, then potentially the first the gatekeeper knows about the call is the DRQ at its end (not useful!)! Note that H.323v2 section 8.5.2 assumes that ARQ has happened at the beginning of the call, so behaviour where this is absent (due to pregranted ARQ) is arguable. This leaves a question mark over the use of the other call-specific RAS message, BRQ. Bandwidth issues with pregranted ARQs are discussed in both a contribution and a TD from the recent Monterey meeting (I forget the numbers). Regards, Chris -- Dr Chris Purvis - Senior Development Engineer, WAVE CC Software Madge Networks Ltd, Wexham Springs, Framewood Road, Wexham, Berks. ENGLAND Phone: +44 1753 661 359 email: cpurvis(a)madge.com > -----Original Message----- > From: rtgupta(a)hss.hns.com [mailto:rtgupta@hss.hns.com] > Sent: 09 March 1999 5:19 > To: srini(a)trillium.com > Cc: h323implementors(a)imtc.org; ITU-SG16(a)mailbag.cps.intel.com > Subject: Re: call clearing by GK > > > Hi srini, > Gatekeeper can clear an ongoing call by sending DRQ to > an endpoint. > Refer to section 8.5.3, ITU-T H.323 recommendation. > > Thanks, > Ritu. > _____________________________________________________________________ > Ritu Gupta | email: > rtgupta(a)hss.hns.com > Senior Software Engineer, | > rtgupta(a)hotmail.com > Hughes Software Systems, | phone: > 91-80-2286390/91/92(W) > Banglore, Karnataka | > 91-80-3374075(H) > INDIA. | Fax : > 91-80-2286393 > _____________________________________________________________________ > Restlessness and discontent are the first necessities of progress. > > srini(a)trillium.com (Srinivasa Beereddy) on 03/09/99 05:29:43 AM > > Please respond to srini(a)trillium.com (Srinivasa Beereddy) > > To: h323implementors(a)imtc.org, ITU-SG16(a)mailbag.cps.intel.com > cc: > Subject: call clearing by GK > > I have a question on call clearing by Gatekeeper. Can a > GateKeeper send DRQ > to clear the call in a preGrantedArq case? > thanks in advance. > Srini > Trillium Digital Systems, Inc.

2 1

Re: call clearing by GK
by Chris Purvis 09 Mar '99

09 Mar '99

> -----Original Message----- > From: rtgupta(a)hss.hns.com [mailto:rtgupta@hss.hns.com] > Sent: 09 March 1999 5:19 > To: srini(a)trillium.com > Cc: h323implementors(a)imtc.org; ITU-SG16(a)mailbag.cps.intel.com > Subject: Re: call clearing by GK > > > Hi srini, > Gatekeeper can clear an ongoing call by sending DRQ to > an endpoint. > Refer to section 8.5.3, ITU-T H.323 recommendation. > > Thanks, > Ritu. > _____________________________________________________________________ > Ritu Gupta | email: > rtgupta(a)hss.hns.com > Senior Software Engineer, | > rtgupta(a)hotmail.com > Hughes Software Systems, | phone: > 91-80-2286390/91/92(W) > Banglore, Karnataka | > 91-80-3374075(H) > INDIA. | Fax : > 91-80-2286393 > _____________________________________________________________________ > Restlessness and discontent are the first necessities of progress. > > > > > > srini(a)trillium.com (Srinivasa Beereddy) on 03/09/99 05:29:43 AM > > Please respond to srini(a)trillium.com (Srinivasa Beereddy) > > To: h323implementors(a)imtc.org, ITU-SG16(a)mailbag.cps.intel.com > cc: > Subject: call clearing by GK > > > > > > > I have a question on call clearing by Gatekeeper. Can a > GateKeeper send DRQ > to clear the call in a preGrantedArq case? > thanks in advance. > Srini > Trillium Digital Systems, Inc. > -------------------------------------------------------------- > ----------- > for list subscription instructions, > send email to h323implementors-request(a)imtc.org with text "info" > > > > > > > > -------------------------------------------------------------- > ----------- > for list subscription instructions, > send email to h323implementors-request(a)imtc.org with text "info" >

1 0

Re: call clearing by GK - Clarification
by rtgupta＠HSS.HNS.COM 09 Mar '99

09 Mar '99

Hi Srini, One clarification on my response. Clause 8.5.3 holds in any scenario where gatekeeper is present. So even in preGrantedArq case, it should hold good. Nothing has been explicitly mentioned for this particular case in the recommendation. Once a call has been established, it should not matter whether ARQ was sent or not for clearing the call. Thanks, Ritu. _____________________________________________________________________ Ritu Gupta | email: rtgupta(a)hss.hns.com Senior Software Engineer, | rtgupta(a)hotmail.com Hughes Software Systems, | phone: 91-80-2286390/91/92(W) Banglore, Karnataka | 91-80-3374075(H) INDIA. | Fax : 91-80-2286393 _____________________________________________________________________ Restlessness and discontent are the first necessities of progress. rtgupta(a)hss.hns.com on 03/09/99 10:49:03 AM Please respond to rtgupta(a)hss.hns.com To: srini(a)trillium.com (Srinivasa Beereddy) cc: h323implementors(a)imtc.org, ITU-SG16(a)mailbag.cps.intel.com Subject: Re: call clearing by GK Hi srini, Gatekeeper can clear an ongoing call by sending DRQ to an endpoint. Refer to section 8.5.3, ITU-T H.323 recommendation. Thanks, Ritu. _____________________________________________________________________ Ritu Gupta | email: rtgupta(a)hss.hns.com Senior Software Engineer, | rtgupta(a)hotmail.com Hughes Software Systems, | phone: 91-80-2286390/91/92(W) Banglore, Karnataka | 91-80-3374075(H) INDIA. | Fax : 91-80-2286393 _____________________________________________________________________ Restlessness and discontent are the first necessities of progress. srini(a)trillium.com (Srinivasa Beereddy) on 03/09/99 05:29:43 AM Please respond to srini(a)trillium.com (Srinivasa Beereddy) To: h323implementors(a)imtc.org, ITU-SG16(a)mailbag.cps.intel.com cc: Subject: call clearing by GK I have a question on call clearing by Gatekeeper. Can a GateKeeper send DRQ to clear the call in a preGrantedArq case? thanks in advance. Srini Trillium Digital Systems, Inc. ------------------------------------------------------------------------- for list subscription instructions, send email to h323implementors-request(a)imtc.org with text "info" ------------------------------------------------------------------------- for list subscription instructions, send email to h323implementors-request(a)imtc.org with text "info"

1 0

Re: call clearing by GK
by rtgupta＠HSS.HNS.COM 09 Mar '99

09 Mar '99

Hi srini, Gatekeeper can clear an ongoing call by sending DRQ to an endpoint. Refer to section 8.5.3, ITU-T H.323 recommendation. Thanks, Ritu. _____________________________________________________________________ Ritu Gupta | email: rtgupta(a)hss.hns.com Senior Software Engineer, | rtgupta(a)hotmail.com Hughes Software Systems, | phone: 91-80-2286390/91/92(W) Banglore, Karnataka | 91-80-3374075(H) INDIA. | Fax : 91-80-2286393 _____________________________________________________________________ Restlessness and discontent are the first necessities of progress. srini(a)trillium.com (Srinivasa Beereddy) on 03/09/99 05:29:43 AM Please respond to srini(a)trillium.com (Srinivasa Beereddy) To: h323implementors(a)imtc.org, ITU-SG16(a)mailbag.cps.intel.com cc: Subject: call clearing by GK I have a question on call clearing by Gatekeeper. Can a GateKeeper send DRQ to clear the call in a preGrantedArq case? thanks in advance. Srini Trillium Digital Systems, Inc. ------------------------------------------------------------------------- for list subscription instructions, send email to h323implementors-request(a)imtc.org with text "info"

1 0