- 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

call clearing by GK
by Srinivasa Beereddy 08 Mar '99

08 Mar '99

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.

1 0

FW: Where H.245 goes - MG or MGC
by Tom-PT Taylor 08 Mar '99

08 Mar '99

> -----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. > > - The MGC may wish to participate in CAPs exchange for policy reasons. > > - 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 > 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. > > - 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. > > - 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. > > - 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. > > My intuition says that the tradeoffs favor keeping H.245 in the MGC. What > do others think?

1 0

Re: TPKT in H.225.0
by Derks, Frank 08 Mar '99

08 Mar '99

Hi Greg, thanks for pointing that out. I was not aware of TPKT being described in any ITU-T recommendation. So rather than adding some text to H.225.0 to define/describe TPKT, it would be better to add explicit references to T.123 in the text of H.225.0 in those places where TPKT is mentioned. Frank ----------------------------------------------------- Frank Derks |Tel +31 35 6893238 | Advanced Development |Fax +31 35 6891030 | Philip Business Communications |P.O. Box 32 | |1200 JD Hilversum | |The Netherlands | ----------------------------------------------------| E-mail: mailto:f.derks@pbc.be.philips.com | WWW: http://www.business-comms.be.philips.com | ----------------------------------------------------- -----Original Message----- From: Greg Goodknight [mailto:ggoodkni@CISCO.COM] Sent: 05 March 1999 20:45 To: ITU-SG16(a)MAILBAG.INTEL.COM Subject: Re: TPKT in H.225.0 I'm just now plowing through old mail. Sorry to have not caught this thread sooner. TPKT is also defined in T.123 which is called out in H.225.0/2.2 Greg Goodknight Cisco Systems -----Original Message----- From: Derks, Frank <F.Derks(a)PBC.BE.PHILIPS.COM> To: ITU-SG16(a)mailbag.cps.intel.com <ITU-SG16(a)mailbag.cps.intel.com> Date: Thursday, February 04, 1999 5:17 AM Subject: Re: TPKT in H.225.0 >Hi Tom, > >I couldn't find it either and I suspect that it couldn't be in because the >ITU is very reluctant to reference any non-ITU material. Furthermore, >RFC1006 encompasses a lot more than just the bit(s) that are used for >H.225.0, so even referring to this RFC does not clarify it all. I think some >work should be spent on this. > >Frank > >-----Original Message----- >From: Tom-PT Taylor [mailto:taylor@NORTELNETWORKS.COM] >Sent: 02 February 1999 22:12 >To: ITU-SG16(a)MAILBAG.INTEL.COM >Subject: Re: TPKT in H.225.0 > > >I'd swear the reference to RFC1006 used to be in H.225.0 Appendix D, but I >can't find it there now. > >> -----Original Message----- >> From: Derks, Frank [SMTP:F.Derks@PBC.BE.PHILIPS.COM] >> Sent: Tuesday, February 02, 1999 4:05 AM >> To: ITU-SG16(a)MAILBAG.INTEL.COM >> Subject: Re: TPKT in H.225.0 >> >> Hi Paul, >> >> I received two responses to my question, one from you and one from Tom >> Taylor. The fact that there are at least two people that know about it >> (and >> several dozens more that have actually implemented the protocol stacks), >> makes it hard to believe that this is an "oversight" in the >> recommendation. >> In fact, not knowing about this makes it impossible to implement an >> interoperable protocol stack! Shouldn't action be taken to get this into >> the >> recommendation ASAP (e.g. through the Implementor's Guide)? >> >> Regards, >> >> Frank >> >> -----Original Message----- >> From: Paul Long [mailto:Plong@SMITHMICRO.COM] >> Sent: 01 February 1999 18:50 >> To: ITU-SG16(a)MAILBAG.INTEL.COM >> Subject: Re: TPKT in H.225.0 >> >> >> TPKT is defined in RFC 1006. Not identifying TPKT was an oversight that >> has >> never been fixed in the Recommendation. >> >> Paul Long >> Smith Micro Software, Inc. >

1 0

Santiago meeting
by Sakae OKUBO 08 Mar '99

08 Mar '99

/// This is more informative than my previous posting /// Date: Mon, 08 Mar 1999 11:17:12 +0100 From: Tosco Federico <Federico.Tosco(a)CSELT.IT> To: "Blaschitz, Michael" <michael.blaschitz(a)infonova.at>,"DeGrasse, Bruce" <b.degrasse(a)mci2000.com>,Freundlich <ggf(a)lucent.com>, "Geary, Tom" <tom.geary(a)CONEXANT.COM>,"Okubo, Sakae" <okubo(a)giti.or.jp>,"Robin-Champigneul, Yves" <yves.robinchampigneul(a)cnet.francetelecom.fr>,"Skran, Dale" <Dale.Skran(a)ascend.com>,"Thom, Gary" <gthom(a)delta-info.com> MIME-version: 1.0 Dear all, I remember you some relevant issues that I already mentioned in some previous e_mails: * Logistic information is available at http://www.ict.uchile.cl/itut.sg16/ Please note that hotel reservation deadline (March 31). The hotel reservation form is included in the ITU-T collective letter (see below) Please be sure to reserve your flights well in advance. * The ITU-T collective letter is available at http://www.itu.int/itudoc/itu-t/com16/coll/index.html Please note the deadline for delayed contributions (May 5). The meeting registration has to be sent, as usual, to ITU, by April 17. Best regards Federico CSELT Via Reiss Romoli 274 10148 TORINO Italy Tel.: +39 0112285321 Fax: +39 0112285295 E_mail: federico.tosco(a)cselt.it

1 0

Re: Invitation via Gatekeeper
by Truong Hong-Linh 08 Mar '99

08 Mar '99

Chris, my comments are marked with <Linh> Regards, Linh ---------------------------------------------------------------------------- --- PLEASE READ IF YOU CARE ABOUT EITHER GATEKEEPERS OR CONFERENCES!!! Linh and I appear to agree that we need the views of more interested parties! Linh, > >2. I disagree with Linh's assertion that "an MC never sends > ARQ". If I am > >administering an MCU which can initiate conferences by > calling up a list of > >participants at a given time, I will certainly require that > MCU to apply to > >its gatekeeper for permission to make these calls. > >In the particular case under discussion, E2/its MC certainly > has to send > >ARQ. It is going to make a call, which will result in data > flowing its > >gatekeeper's zone, and which may end up costing money. > >E1's "call" does not result in data flowing in its > gatekeeper's zone if the > >centralised model is used for data (in which I include both audio and > >video) and it happens to be in a different zone from E2/MC > and E3 - so > >maybe E1 doesn't have to send ARQ? However it will result > in data flowing > >in its gatekeeper's zone if the decentralised model is used > for data, and > >the MC may wish to (cross?) charge E1 for inviting E3, so > maybe E1 does > >need to send ARQ. > > I must admit that I only consider the "address resolution" > part of the ARQ > procedure. I did not consider its BW management and reservation part, > because that part is in my view broken. I'd never use the ARQ for that > purpose. An endpoint only knows about the needed BW when a > logical channel > is opened, and not at call setup time! And that applies > already in case of a > point-to-point call. Since it does not work for > point-to-point cases, it > will also not work for the conference cases. I agree that the bandwidth stuff is broken. However, if a gatekeeper chooses to do things with it, you're going to end up with interoperability problems from saying you don't use it. The point is slightly wider, though, that someone needs to have knowledge of whether a given user is authorised to initiate the inviting of people to conferences. I'd rather have all my configuration for that sort of thing in my gatekeeper than in the (potentially multiple) MCs in its zone. <Linh>I didn't say that I don't use the ARQ procedure. I need it for address resolution purpose. I only want to say that the BW management part of the ARQ procedure is broken. > To make the scenario a bit more complicated, assume there is already a > conference between E1, E2/MC and E4. Now E1 wants to invite > E3. E4 will only > knows about the joining of E3 when it is requested by the MC to either > re-open the logical channels (centralized case with codec > change) or open > new ones (distributed case). Really? I thought that was what the conferenceIndication "terminalJoinedConference" was for, and that the MC was supposed to send it to all participants whenever anyone new joined the conference. <Linh> You're rigth. I was thinking about the BW stuff. > Should E4 sends ARQ when it is > requested to > open the logical channels? I don't think that is actually specified. > Furthermore, how should E4 ask its GK for the permission to > have a call with > E3? I don't know whether the BRQ procedure can help. Maybe > somebody more > knowledgeable could help to clarify the situation. In my view, the calls are logically between each endpoint and the MC, and this is how the control paths run. Yes the model is slightly broken for data paths, particularly by by decentralised conferences. > >3. The destCallSignalAddress given in ACF is the only > address to which an > >endpoint should send a setup message. I find it hard to > agree with Linh's > >assertion that on the basis of an ACF mentioning E3, E1 > should send a setup > >message to E2/MC. The suggestion in the case of the > gatekeeper routed > >model is simply impossible. E1 doesn't know where E2/MC is, > so I fail to > >see how E1 can send its setup message to E2/MC in this case. > Note that all > >E1's call signalling goes to its gatekeeper - and as a > routing gatekeeper I > >would feel justified in ensuring that E1 doesn't find out > where E2/MC is: > >for instance I wouldn't feel obliged to leave > mcLocationIndication messages > >alone as I relay them. The upside of this is that at least then E1's > >gatekeeper knows where the activeMC is, and should be able > to work out > >what's going on when the setup message comes in. > > I was assuming that the call between E1 and E2 was direct and > the MC was > already created at E2. Otherwise, if the call was GK-routed > then according > to H.323 Section 8.4.3.4 the GK would know where the MC is, > and certainly E1 > would have to sends its SETUP to the GK/MC as specified in 8.4.3.5. Fair-ish cop... For some of it (ie the GK routed stuff). It kind of depends on your understanding of a GK having "access to" an MC. Does any entity with MC functionality that's registered with a GK count as an MC to which it "has access"? Or just ones that happen to be involved in this call? This is an area in which the standard is terribly woolly. <Linh>Agree. We need clarification. (BTW do you think that it is the only area? ;-) ) Can I just clarify your position, please? If I understand you correctly you're suggesting that if I as an endpoint want to send a setup "towards" the active MC in my call or conference in order to invite a new party to the conference, I don't need to send ARQ to my gatekeeper. In any other circumstances I need to send ARQ and receive ACF before I may send Setup. In the gatekeeper routed model, any setup message with conference goal "invite" will be sent by the gatekeeper to the active MC for the conference whose conferenceID matches that in the setup message UNLESS it comes from that entity, in which case it will go to the desired destination. <Linh>No. In my view, if an endpoint wants to invite a new party, it has to send ARQ to its GK. Then it shall send the SETUP mesage with the address info contained in the ACF to the MC. The MC will then route that SETUP accordingly, i.e. to the GK in the GK-routed case or to the destination endpoint in the direct case. Arising questions: What if there is NO active MC (ie the call is a typical one)? How do I promote a call to a conference in the direct-routed model where I've ended up as "slave" in the master-slave determination procedure (where other entities in the call may or may not contain MCs)? <Linh>With the terminal capabilty set exchange, you _know_ whether the remote endpoint is MC-capable or not. If yes you send the invite SETUP to the remote endpoint which then creates an MC. If no then tough luck the call cannot be promoted to a conference. Who is vetting the inviting endpoint's right to invite (certainly the GK's job in my opinion, whatever routing model you're using). Regards, Chris

1 0

SG16 Santiago meeting
by Sakae OKUBO 08 Mar '99

08 Mar '99

Dear Q.12-14/16 experts, This is pointer information from Mr. Tosco, Chairman of WP2/16 regarding the Santiago meeting of SG16 next May. Collective letter http://www.itu.int/itudoc/itu-t/com16/coll/005.html Logistic information http://www.ict.uchile.cl/itut.sg16/ Best regards, Sakae OKUBO (Mr.) *********************************************************** Waseda Research Center Telecommunications Advancement Organization of Japan (TAO) 5th Floor, Nishi-Waseda Bldg. 1-21-1 Nishi-Waseda, Shinjuku-ku, Tokyo 169-0051 Japan Tel: +81 3 5286 3830 Fax: +81 3 5287 7287 e-mail: okubo(a)giti.or.jp ***********************************************************

1 0

Revised Monterey meeting report APC-1554a
by Sakae OKUBO 08 Mar '99

08 Mar '99

Dear Q12-14/16 Monterey meeting participants, I have replaced the draft meeting report APC-1554.zip with a revised version APC-1554a.zip at the /9902_Mon directory. Some editorial improvements have been made: - Improvements on the parts relevant to the text conversation and text SET as requested by Mr. Hellstrom, - Addition of the list of participants - Addition of Amendment 5 to H.222.0 in the Q12 future plan - Some other purely editorial corrections Using this opportunity, let me remind the Annex D to H.323 collaborators of the following action: "TD-39 contains the proposed liaison response. Mr. Ott, Mr. Kumar, and Mr. Draper will help Mr. Skran finalize the text as authorized by the meeting." Once this has been confirmed, I will issue revision 2 with confirmed status and send its copies to Mr. Tosco and Mr. Bigi. Best regards, Sakae OKUBO (Mr.) *********************************************************** Waseda Research Center Telecommunications Advancement Organization of Japan (TAO) 5th Floor, Nishi-Waseda Bldg. 1-21-1 Nishi-Waseda, Shinjuku-ku, Tokyo 169-0051 Japan Tel: +81 3 5286 3830 Fax: +81 3 5287 7287 e-mail: okubo(a)giti.or.jp ***********************************************************

1 0

FYI: Travel to Chile
by Dale L. Skran 07 Mar '99

07 Mar '99

All: Some concern was raised about being let into Chile and needed a yellow fever shot to leave. This does not appear to be the case. Dale Skran Q13 Rapporteur >From: Eileen.Patterson(a)ascend.com >X-Lotus-FromDomain: ASCEND >To: Dale.Skran(a)ascend.com >Date: Thu, 4 Mar 1999 12:10:32 -0800 >Subject: Travel to Chile > > > >To travel to Chile you will need...a valid passport, $45 entrance fee to >the country, and nothing else. >I spoke with the State Department (202-647-5225). They say to use common >sense precautions in Chile...stay away from demonstrations by Chileans. US >citizens are not at risk unless they get involved in these demonstrations. > >The Chilean Embassy (202-785-1746) assured me that no immunizations were >necessary for travel to Chile or exiting from Chile. > > > >

2 1

Re: Invitation via Gatekeeper
by Chris Purvis 05 Mar '99

05 Mar '99

Radhika, Gary, H.323v2, section 6.7: "The MCU is an endpoint which provides support for multipoint conferences. The MCU shall consist of an MC and zero or more MPs." Note that the phrase used is "consist of", not "contain". If an MCU is an endpoint, it is callable (I think we're agreed on that). If it consists of an MC and zero or more MPs, that means it must still be callable when it consists of only an MC. Therefore the MC is the part of an MCU that is callable. Hence an MC MAY be a callable entity. The wider point is that my understanding was that all control signalling done by an MCU was done by the MC part of it (again on the basis of those two sentences). If this is inconsistent with other parts of the standard, then it certainly needs to be fixed (please give references); if it is consistent with the rest of the standard, but not what was intended, then we need to reconsider what we really want. For the case under discussion I'd agree with Gary that it's a minor semantic quibble (and as such I was planning to allow Gary's mail on its own to pass without comment), but if there's the possibility of it becoming more than that maybe we ought to clear it up. Regards, Chris > -----Original Message----- > From: Roy, Radhika R, ALCOO [mailto:rrroy@ATT.COM] > Sent: 05 March 1999 2:08 > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: Re: Invitation via Gatekeeper > > > This was my understanding as well. > > Does anyone disagree with Gary? > > Regards, > Radhika > > ------------------------------------------- > > Radhika R. Roy > AT&T Labs > Room C1-2B03 > 200 Laurel Avenue S. > Middletwon, NJ 07748 > USA > + 1 732 420 1580 Tel > rrroy(a)att.com > > > -----Original Message----- > > From: Gary A. Thom [SMTP:gthom@DELTA-INFO.COM] > > Sent: Friday, March 05, 1999 11:18 AM > > To: ITU-SG16(a)MAILBAG.INTEL.COM > > Subject: Re: Invitation via Gatekeeper > > > > I have this minor semantic clarification: > > > > > 2. I disagree with Linh's assertion that "an MC never > sends ARQ". If I > > am > > > administering an MCU which can initiate conferences by > calling up a list > > of > > > participants at a given time, I will certainly require > that MCU to apply > > to > > > its gatekeeper for permission to make these calls. > > > In the particular case under discussion, E2/its MC > certainly has to send > > > ARQ. It is going to make a call, which will result in > data flowing its > > > gatekeeper's zone, and which may end up costing money. > > > > The original idea was that only endpoints send ARQ. An MC is not an > > endpoint, however, it is a > > functional element which can be contained in an endpoint > (such is the case > > of an MCU or a terminal > > which contains an MC). So even though the endpoint contains > an MC, it is > > the endpoint which is > > sending the ARQ not the MC functional element. > > > > If an MC exists in the Gatekeeper, I do not beleive that > that MC will ever > > send ARQ for any of the > > connections in the conference. Only the endpoints in that > conference will > > send ARQ to their > > Gatekeepers. > > > > > > Gary > > ------------------------------------------------------ > > Name : Gary A. Thom > > Company: Delta Information Systems, Inc. > > Address: 300 Welsh Rd., Bldg 3 > > Horsham, PA 19044 USA > > Phone : +1-215-657-5270 Fax : +1-215-657-5273 > > E-mail : gthom(a)delta-info.com > > ------------------------------------------------------ >

2 1

Re: H.323/VoIP QoS
by Prasad Kallur 05 Mar '99

05 Mar '99

Hi Joon, Have you also, setup a web site for any discussion and document archival? Thanks, Prasad -----Original Message----- From: Joon Maeng [mailto:Joon_Maeng@VTEL.COM] Sent: Wednesday, March 03, 1999 8:49 PM To: ITU-SG16(a)mailbag.cps.intel.com Subject: Re: H.323/VoIP QoS Hi! To subscribe H.323/VoIP QoS Activity Group, please send mail to majordomo(a)majordomo.vtel.com with a command line subscribe h323_voip_qos your email address in the body of the message and follows the instruction of the response from the majordomo. Any text in the subject will be ignored. If you have any problem in subscribing the list server, please email me. Thank you much for your interests. Regards, Joon

1 0

Re: TPKT in H.225.0
by Greg Goodknight 05 Mar '99

05 Mar '99

I'm just now plowing through old mail. Sorry to have not caught this thread sooner. TPKT is also defined in T.123 which is called out in H.225.0/2.2 Greg Goodknight Cisco Systems -----Original Message----- From: Derks, Frank <F.Derks(a)PBC.BE.PHILIPS.COM> To: ITU-SG16(a)mailbag.cps.intel.com <ITU-SG16(a)mailbag.cps.intel.com> Date: Thursday, February 04, 1999 5:17 AM Subject: Re: TPKT in H.225.0 >Hi Tom, > >I couldn't find it either and I suspect that it couldn't be in because the >ITU is very reluctant to reference any non-ITU material. Furthermore, >RFC1006 encompasses a lot more than just the bit(s) that are used for >H.225.0, so even referring to this RFC does not clarify it all. I think some >work should be spent on this. > >Frank > >-----Original Message----- >From: Tom-PT Taylor [mailto:taylor@NORTELNETWORKS.COM] >Sent: 02 February 1999 22:12 >To: ITU-SG16(a)MAILBAG.INTEL.COM >Subject: Re: TPKT in H.225.0 > > >I'd swear the reference to RFC1006 used to be in H.225.0 Appendix D, but I >can't find it there now. > >> -----Original Message----- >> From: Derks, Frank [SMTP:F.Derks@PBC.BE.PHILIPS.COM] >> Sent: Tuesday, February 02, 1999 4:05 AM >> To: ITU-SG16(a)MAILBAG.INTEL.COM >> Subject: Re: TPKT in H.225.0 >> >> Hi Paul, >> >> I received two responses to my question, one from you and one from Tom >> Taylor. The fact that there are at least two people that know about it >> (and >> several dozens more that have actually implemented the protocol stacks), >> makes it hard to believe that this is an "oversight" in the >> recommendation. >> In fact, not knowing about this makes it impossible to implement an >> interoperable protocol stack! Shouldn't action be taken to get this into >> the >> recommendation ASAP (e.g. through the Implementor's Guide)? >> >> Regards, >> >> Frank >> >> -----Original Message----- >> From: Paul Long [mailto:Plong@SMITHMICRO.COM] >> Sent: 01 February 1999 18:50 >> To: ITU-SG16(a)MAILBAG.INTEL.COM >> Subject: Re: TPKT in H.225.0 >> >> >> TPKT is defined in RFC 1006. Not identifying TPKT was an oversight that >> has >> never been fixed in the Recommendation. >> >> Paul Long >> Smith Micro Software, Inc. >

1 0

Re: Invitation via Gatekeeper
by Chris Purvis 05 Mar '99

05 Mar '99

PLEASE READ IF YOU CARE ABOUT EITHER GATEKEEPERS OR CONFERENCES!!! Linh and I appear to agree that we need the views of more interested parties! Linh, > >2. I disagree with Linh's assertion that "an MC never sends > ARQ". If I am > >administering an MCU which can initiate conferences by > calling up a list of > >participants at a given time, I will certainly require that > MCU to apply to > >its gatekeeper for permission to make these calls. > >In the particular case under discussion, E2/its MC certainly > has to send > >ARQ. It is going to make a call, which will result in data > flowing its > >gatekeeper's zone, and which may end up costing money. > >E1's "call" does not result in data flowing in its > gatekeeper's zone if the > >centralised model is used for data (in which I include both audio and > >video) and it happens to be in a different zone from E2/MC > and E3 - so > >maybe E1 doesn't have to send ARQ? However it will result > in data flowing > >in its gatekeeper's zone if the decentralised model is used > for data, and > >the MC may wish to (cross?) charge E1 for inviting E3, so > maybe E1 does > >need to send ARQ. > > I must admit that I only consider the "address resolution" > part of the ARQ > procedure. I did not consider its BW management and reservation part, > because that part is in my view broken. I'd never use the ARQ for that > purpose. An endpoint only knows about the needed BW when a > logical channel > is opened, and not at call setup time! And that applies > already in case of a > point-to-point call. Since it does not work for > point-to-point cases, it > will also not work for the conference cases. I agree that the bandwidth stuff is broken. However, if a gatekeeper chooses to do things with it, you're going to end up with interoperability problems from saying you don't use it. The point is slightly wider, though, that someone needs to have knowledge of whether a given user is authorised to initiate the inviting of people to conferences. I'd rather have all my configuration for that sort of thing in my gatekeeper than in the (potentially multiple) MCs in its zone. > To make the scenario a bit more complicated, assume there is already a > conference between E1, E2/MC and E4. Now E1 wants to invite > E3. E4 will only > knows about the joining of E3 when it is requested by the MC to either > re-open the logical channels (centralized case with codec > change) or open > new ones (distributed case). Really? I thought that was what the conferenceIndication "terminalJoinedConference" was for, and that the MC was supposed to send it to all participants whenever anyone new joined the conference. > Should E4 sends ARQ when it is > requested to > open the logical channels? I don't think that is actually specified. > Furthermore, how should E4 ask its GK for the permission to > have a call with > E3? I don't know whether the BRQ procedure can help. Maybe > somebody more > knowledgeable could help to clarify the situation. In my view, the calls are logically between each endpoint and the MC, and this is how the control paths run. Yes the model is slightly broken for data paths, particularly by by decentralised conferences. > >3. The destCallSignalAddress given in ACF is the only > address to which an > >endpoint should send a setup message. I find it hard to > agree with Linh's > >assertion that on the basis of an ACF mentioning E3, E1 > should send a setup > >message to E2/MC. The suggestion in the case of the > gatekeeper routed > >model is simply impossible. E1 doesn't know where E2/MC is, > so I fail to > >see how E1 can send its setup message to E2/MC in this case. > Note that all > >E1's call signalling goes to its gatekeeper - and as a > routing gatekeeper I > >would feel justified in ensuring that E1 doesn't find out > where E2/MC is: > >for instance I wouldn't feel obliged to leave > mcLocationIndication messages > >alone as I relay them. The upside of this is that at least then E1's > >gatekeeper knows where the activeMC is, and should be able > to work out > >what's going on when the setup message comes in. > > I was assuming that the call between E1 and E2 was direct and > the MC was > already created at E2. Otherwise, if the call was GK-routed > then according > to H.323 Section 8.4.3.4 the GK would know where the MC is, > and certainly E1 > would have to sends its SETUP to the GK/MC as specified in 8.4.3.5. Fair-ish cop... For some of it (ie the GK routed stuff). It kind of depends on your understanding of a GK having "access to" an MC. Does any entity with MC functionality that's registered with a GK count as an MC to which it "has access"? Or just ones that happen to be involved in this call? This is an area in which the standard is terribly woolly. Can I just clarify your position, please? If I understand you correctly you're suggesting that if I as an endpoint want to send a setup "towards" the active MC in my call or conference in order to invite a new party to the conference, I don't need to send ARQ to my gatekeeper. In any other circumstances I need to send ARQ and receive ACF before I may send Setup. In the gatekeeper routed model, any setup message with conference goal "invite" will be sent by the gatekeeper to the active MC for the conference whose conferenceID matches that in the setup message UNLESS it comes from that entity, in which case it will go to the desired destination. Arising questions: What if there is NO active MC (ie the call is a typical one)? How do I promote a call to a conference in the direct-routed model where I've ended up as "slave" in the master-slave determination procedure (where other entities in the call may or may not contain MCs)? Who is vetting the inviting endpoint's right to invite (certainly the GK's job in my opinion, whatever routing model you're using). Regards, Chris

1 0

Re: Invitation via Gatekeeper
by Truong Hong-Linh 05 Mar '99

05 Mar '99

Chris, a few comments to your statements: >2. I disagree with Linh's assertion that "an MC never sends ARQ". If I am >administering an MCU which can initiate conferences by calling up a list of >participants at a given time, I will certainly require that MCU to apply to >its gatekeeper for permission to make these calls. >In the particular case under discussion, E2/its MC certainly has to send >ARQ. It is going to make a call, which will result in data flowing its >gatekeeper's zone, and which may end up costing money. >E1's "call" does not result in data flowing in its gatekeeper's zone if the >centralised model is used for data (in which I include both audio and >video) and it happens to be in a different zone from E2/MC and E3 - so >maybe E1 doesn't have to send ARQ? However it will result in data flowing >in its gatekeeper's zone if the decentralised model is used for data, and >the MC may wish to (cross?) charge E1 for inviting E3, so maybe E1 does >need to send ARQ. I must admit that I only consider the "address resolution" part of the ARQ procedure. I did not consider its BW management and reservation part, because that part is in my view broken. I'd never use the ARQ for that purpose. An endpoint only knows about the needed BW when a logical channel is opened, and not at call setup time! And that applies already in case of a point-to-point call. Since it does not work for point-to-point cases, it will also not work for the conference cases. To make the scenario a bit more complicated, assume there is already a conference between E1, E2/MC and E4. Now E1 wants to invite E3. E4 will only knows about the joining of E3 when it is requested by the MC to either re-open the logical channels (centralized case with codec change) or open new ones (distributed case). Should E4 sends ARQ when it is requested to open the logical channels? I don't think that is actually specified. Furthermore, how should E4 ask its GK for the permission to have a call with E3? I don't know whether the BRQ procedure can help. Maybe somebody more knowledgeable could help to clarify the situation. >3. The destCallSignalAddress given in ACF is the only address to which an >endpoint should send a setup message. I find it hard to agree with Linh's >assertion that on the basis of an ACF mentioning E3, E1 should send a setup >message to E2/MC. The suggestion in the case of the gatekeeper routed >model is simply impossible. E1 doesn't know where E2/MC is, so I fail to >see how E1 can send its setup message to E2/MC in this case. Note that all >E1's call signalling goes to its gatekeeper - and as a routing gatekeeper I >would feel justified in ensuring that E1 doesn't find out where E2/MC is: >for instance I wouldn't feel obliged to leave mcLocationIndication messages >alone as I relay them. The upside of this is that at least then E1's >gatekeeper knows where the activeMC is, and should be able to work out >what's going on when the setup message comes in. I was assuming that the call between E1 and E2 was direct and the MC was already created at E2. Otherwise, if the call was GK-routed then according to H.323 Section 8.4.3.4 the GK would know where the MC is, and certainly E1 would have to sends its SETUP to the GK/MC as specified in 8.4.3.5. Regards, Linh --------- TRUONG Hong Linh email: hlt(a)zurich.ibm.com IBM Zurich Research Laboratory tel : +41 1 724 8434 CH-8803 Rueschlikon / Switzerland fax : +41 1 724 8955

1 0

H.GCP Audio Call minutes
by Bryan Hill 05 Mar '99

05 Mar '99

Colleagues, The H.GCP audio call was held Thursday March 4th , 18 ports called in including a group from the TIPHON meeting. Companies represented were ATT, Lucent, ACGS, RadVision, Cisco, Nortel, Delta Information Systems, NetSpeak, Bellcore and others. . . The meeting opened by reviewing a proposed working model and fleshing out the work items that need to be addressed. A number of individuals committed to fleshing some of the work items prior to the next call, I would like to thank these individuals in advance. There was some news from TIPHON regarding changes to the reference model and some adjustments to the requirements they have contributed to H.GCP. These changes will be reflected once TDs from the Philadelphia meeting are released. The last hour or so was focussed on reviewing the H.GCP requirements I sent around prior to the meeting. The next call is tentatively planned for Thursday March 18 at 10AM EST. The working model Individuals will be working up submissions to be reviewed by the entire group at the next audio call. The objective is that the principals involved will collaborate off line initially, post the results to the SG16 reflector for comments and a final version will be posted for discussion in an audio call. The result of that final review will be added into the H.GCP by the editor. Every effort will be made to resolve issues in this forum but if issues remain they will be logged and discussed in Santiago Work items T he following work items were identified and individuals who expressed an interest in working on them are noted. Control Model Tom Taylor Connection Model Rex Coldren, Hong Liu, Nortel rep Command related issues Chip Sharp Resource Management Paul Sijben Other work items Messages (i.e.-command packaging) Message Encoding Scripting/Packages Interface C protocol (Q.931/Q.764) Interface B protocol (Q.931 ) -----Original Message----- From: Bryan Hill [SMTP:bhill@VIDEOSERVER.COM] Sent: Monday, March 01, 1999 2:37 PM To: ITU-SG16(a)mailbag.cps.intel.com Subject: H.GCP Audio Call Colleagues, I would like to invite you to participate in audio call on Thursday March 4th from 11AM until 1PM EST to discuss H.GCP. The call details are as follows: Calls from outside the US: 312-470-7273 Calls from within the US: 888-847-7598 Passcode: BryanHill Confirmation number: 5193957 Please respond to me directly to reserve a port for this call (where ever possible please try to minimize port requirements by sharing a port with a colleague). The main purpose of this initial call will be to review requirements and terminology for H.GCP which were discussed in Monterey. I have been editing these sections and will make them available on the ptel SG16 ftp site no later than tomorrow 3/2. The second purpose of the call is to identify other areas that need to be discussed in subsequent audio calls. An initial pass of topics is listed below. I would like to solicit volunteers to submit written contribution in each of the areas identified and use these submissions as a basis for discussing topics in future audio calls. In this manner I hope to scope our discussion to specific technical topics and combine the benefits from MDCP and MGCP approaches into H.GCP. 1) Control model a) Controller to gateway associations b) Controller to internal gateway entity associations c) Failover d) Security 2) Connection model a) Controllable entities b) Controllable entity properties 3) Commands a) Types b) Parameters c) Acknowledgement styles/sequencing 4) Messages (i.e.-command packaging) 5) Message Encoding 6) Resource management 7) Scripting/Packages 8) Interface C protocol (Q.931/Q.764) 9) Interface B protocol (Q.931 ) Best Regards, Bryan _________________________________________________________ Bryan Hill VideoServer Inc. (781) 505-2159 <mailto:bhill@videoserver.com>

1 0

Re: Invitation via Gatekeeper
by Chris Purvis 05 Mar '99

05 Mar '99

Linh, Soo, All, I think there's a genuine problem here, and I think we need to look for the "right" solution. 1. I agree with Linh that the fact that the MC happens to be located with one of the endpoints in this scenario is (or should be) irrelevant. 2. I disagree with Linh's assertion that "an MC never sends ARQ". If I am administering an MCU which can initiate conferences by calling up a list of participants at a given time, I will certainly require that MCU to apply to its gatekeeper for permission to make these calls. In the particular case under discussion, E2/its MC certainly has to send ARQ. It is going to make a call, which will result in data flowing its gatekeeper's zone, and which may end up costing money. E1's "call" does not result in data flowing in its gatekeeper's zone if the centralised model is used for data (in which I include both audio and video) and it happens to be in a different zone from E2/MC and E3 - so maybe E1 doesn't have to send ARQ? However it will result in data flowing in its gatekeeper's zone if the decentralised model is used for data, and the MC may wish to (cross?) charge E1 for inviting E3, so maybe E1 does need to send ARQ. 3. The destCallSignalAddress given in ACF is the only address to which an endpoint should send a setup message. I find it hard to agree with Linh's assertion that on the basis of an ACF mentioning E3, E1 should send a setup message to E2/MC. The suggestion in the case of the gatekeeper routed model is simply impossible. E1 doesn't know where E2/MC is, so I fail to see how E1 can send its setup message to E2/MC in this case. Note that all E1's call signalling goes to its gatekeeper - and as a routing gatekeeper I would feel justified in ensuring that E1 doesn't find out where E2/MC is: for instance I wouldn't feel obliged to leave mcLocationIndication messages alone as I relay them. The upside of this is that at least then E1's gatekeeper knows where the activeMC is, and should be able to work out what's going on when the setup message comes in. Outline Solution?: I really don't think we have the tools at our disposal as things stand. I'm (reluctantly) coming to the conclusion that we need either a1 & b or a2 & b (I think I prefer the latter) as follows: a1) An extra RAS message to tell gatekeepers where the active MC lives in conferences. I'm not certain how this works, though, because there needs to be an "I am NOT the active MC" option (sent on receipt of mcLocationIndication) which tells the gatekeeper where to find the active MC. This may or may not be a problem. a2) An "activeMCLocation" field in ARQ (and setup?). b) A conferenceGoal element in ARQ (as in setup). Then if a gatekeeper receives an "invite" ARQ from something that is not the active MC in its conference it can send back in its confirm the transport address to which to send setup, and destinationInfo for the final destination. In the routed model I believe there is still sufficient information in the setup message for the gatekeeper to do the right thing. Handling "invite" from the activeMC is then fairly obvious. I'd love to see how we can do this without new ASN.1, though... 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: Lee Hyoung soo [mailto:soo@DESKVIEW.NADA.CO.KR] > Sent: 05 March 1999 3:35 > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: Re: Invitation via Gatekeeper > > > Dear Hong-Linh and Chris, > > Thank you for your mail. > > my questions are embeded below. ^.^ > > > > > It's worth mentioning which standard here. For the benefit > of anyone > > needing to catch up, we're talking about H.323. > > Yes, I mentioned H.323 v2(October 1997). > > > > when an > > > endpoint(E1) which do not have active MC wants to invite other > > > endpoint(E3), does E1 send an ARQ to its Gatekeeper for > the invite or > > > does E2 send the ARQ to its gatekeeper, or do both of > them send ARQ's? > > > > I would suggest that both ought to send ARQs. Both are > logically setting up > > calls, so both need to ask permission. However, E1's ARQ > need ask for no > > bandwidth as none will be used on the call between it and E2. > > > > <Linh> Here I think we have to distinguish carefully > between an endpoint and > > an > > MC (what the current H.323 achieves very badly!). In the > above scenario, the > > MC is hosted in the same device as E2 and E1 is sending the > SETUP message > > to the MC and not to E2 (H.323 Figure 28-30 are misleading, > because they > > only > > show E2 and not the MC!). Therefore, IMO only E1 has to > send an ARQ, not E2, > > and an MC never sends ARQ! > > I agree with Chris's opnion. I think, every endpoint which is > registered to > Gatekeeper must send ARQ to its Gatekeeper. > > But I still have some problems. In the above scenario, if E1 > sends ARQ to its > Gatekeeper, E1's behavior after receiving ACF is not clear. > There are two > different cases. One is that E1 receives ACF with E3's > CallTransportAddress. In > this case, E1's behavior is not clear. E1 should keep its > status(invite or not), > and after receiving ACF, E1 send Setup message to E2 regardless of > CallTransportAddress in ACF. > And the other is that E1 receives ACF with E2's > CallTransportAddres. In this > case, E1' behavior is clear, but Gatekeeper should know E2 is > active MC, and > send ACF with E2's CallTransportAddress regardless of > destination address in > ARQ. > > > > > And, when Gatekeeper doesn't know which endpoint has > active MC in any > > > conference, what should Gatekeeper do if it receives ARQ(for > > > invitation) > > > from an endpoint which do not have active MC? I mean, if > Gatekeeper > > > receives ARQ from E1, what should Gatekeeper do? Does > Gatekeeper send > > > ACR with E2's CallTransportAddress instead of E3's > > > CallTransportAddress? > > > > E1's gatekeeper can conceivably spot that invite is > probably what's wanted, > > by matching up conferenceIDs, although there's nothing in > the ARQ message to > > say directly that invite is the desired outcome. The > gatekeeper certainly > > MUST return the address to which E1 should send its Setup > message, so in the > > direct-routed model that will be E2. However, a > non-routing gatekeeper will > > have no way of knowing where the active MC is. I believe > this is a genuine > > "hole" in the standard. > > Yes, you are right. E1's Gatekeeper can know E1's intention, > but generally E1's > gatekeeper doesn't know which endpoint is active MC in that > conference. > > > > <Linh>The point here is in general the GK does not (and > needs not) know > > where > > the MC is actually located! It therefore, in response to > the ARQ sent by E1, > > returns > > the transport address of either E3 (direct model) or itself > (GK-routed > > model). > > In both cases, E1 has to send its SETUP message to the MC > (which is in > > our specific scenario colocated with E2).Then the MC will > relay that message > > to > > either E3 or the GK, depending on which transport address > is included in the > > SETUP message sent by E1. > > According to Linh's opnion, As I explained above, E1 should keep its > status(invite or not) and E1 should follow different procedure between > invitation and other calls, after receiving ACF from its Gatekeeper. > > Best wishes, > soo. > > -- > Nada Research Co., Ltd. Korea > TEL : 82-2-525-3941 > > Lee Hyoung soo. > mailto:soo@nada.co.kr

2 1