March 1999 - sg16-avd - lists.packetizer.com

Mailing List
by Simon Brewer 11 Mar '99

11 Mar '99

Dear Sir, could you please send me a list of mailing list resources, and how i may subscribe, Best Regards, Simon Brewer -- Simon Brewer Signal Processing Associates P/L Ph +61 3 9800 2000 3/97 Lewis Rd, Wantirna, 3152 Fx +61 3 9800 2111 Australia. simon(a)spa.com.au This communication is proprietary and confidential.

1 0

Fast Start
by Francois Audet 11 Mar '99

11 Mar '99

Hi, Question on fastStart. When presenting different alternatives in the OpenLogicalChannel, the sessionID is the same for all, in order to distinguish between alternatives for the same session, instead of a proposal to open multiple media channels. Is the same valid for the RTP/RTCP port numbers, and the logical channel numbers? Do they have to be the same for alternative proposals, or can they be different? Any views? ----- François Audet Tel:+1 408 565 5675 mailto:audet@NortelNetworks.com Nortel Networks Fax:+1 408 565 2375 http://www.NortelNetworks.com

2 1

Re: FW: Where H.245 goes - MG or MGC (Skran's comments)
by Ami Amir 11 Mar '99

11 Mar '99

Hi Well - it seems we are getting pretty religious about this issue. My take: For a simple toll by-pass application - it makes sense to route H.245 to the MGC. The MG is "dumb" - all decisions are centralized - and life is simple :) However, if we believe that the real future of VoIP is in adding functionality and services, that there will be instances when H.323 end points also are involved, and multimedia is important, a case can be made for that the MG should support H.245. I believe that in reaching a sensible conclusion we should also look at enterprise connections that utilize Q.931 or Q.SIG for signaling. My question - can't we allow for both? Ami -----Original Message----- From: Flemming Andreasen [SMTP:fandreas@telcordia.com] Sent: Wednesday, March 10, 1999 4:58 PM To: ITU-SG16(a)mailbag.cps.intel.com Subject: Re: FW: Where H.245 goes - MG or MGC (Skran's comments) I will agree with that. Let's not forget that we are addressing "decomposed gateways". As Dave pointed, out GW = MGC + MG + SG so there's no argument there. Also, the idea with the decompostion is precisely that; to decompose the GW into its logical components that each address different aspects of the combined GW. The MGC is the one with the intelligence/control/complexity, or whatever we want to call it, and as Brian pointed out earlier the bearer part is in the MG. Thus Dave's arguments still stand, and H.245 should be in the MGC, not the MG. Regards Flemming Andreasen "David R. Oran" <oran(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. > > > > > > > >

4 3

Re: Handling of nonreceipt of IRRs by gatekeeper
by rtgupta＠HSS.HNS.COM 11 Mar '99

11 Mar '99

Hi, Specifications have not included all the glare and error conditions. So I assume in these cases, decision making is at gatekeeper's discretion. Even in 'IRR not received' case, it is at gatekeeper's disposal how to deal with it. But in my opinion, best solution is 3rd one as suggested by you. If gatekeeper does not receive IRR from an endpoint within irrFrequency period, it should send IRQ. Gatekeeper should try atleast twice. In case no response is received, gatekeeper should clear the call. Thanks, Ritu. srini(a)trillium.com (Srinivasa Beereddy) on 03/11/99 05:54:10 AM Please respond to srini(a)trillium.com (Srinivasa Beereddy) To: h323implementors(a)imtc.org, ITU-SG16(a)mailbag.cps.intel.com cc: Subject: Handling of nonreceipt of IRRs by gatekeeper Handling of nonreceipt of IRRs by gatekeeper. If irrFrequency is specified in ACF message and the endpoint doesnot respond with an IRR in the specified interval, what should the GK do? (H2250V2 Section 7.11.2 says endpoint shall send IRRs if the irrFrequency is specified, but doesn't say about nonreceipt of IRRs) Following are the list of possible actions by GK, and I would like hear your opinion. 1. Just ignore 2. Clear the call by sending DRQ 3. Send a IRQ and release the call if no response. thanks, Srini Trillium Digital Systems, Inc. ------------------------------------------------------------------------- for list subscription instructions, send email to h323implementors-request(a)imtc.org with text "info"

1 0

Date of SG16 meeting in February 2000 has been fixed
by Sakae OKUBO 10 Mar '99

10 Mar '99

Dear Q12-14/16 experts, Mr. Tosco has advised Rapporteurs of the subject matter as follows: 7 to 18 February 2000 inclusive, at ITU premises in Geneva Please note that this is the final meeting of the current study period 1997 - 2000. I will update the Monterey meeting report accordingly. 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

Handling of nonreceipt of IRRs by gatekeeper
by Srinivasa Beereddy 10 Mar '99

10 Mar '99

Handling of nonreceipt of IRRs by gatekeeper. If irrFrequency is specified in ACF message and the endpoint doesnot respond with an IRR in the specified interval, what should the GK do? (H2250V2 Section 7.11.2 says endpoint shall send IRRs if the irrFrequency is specified, but doesn't say about nonreceipt of IRRs) Following are the list of possible actions by GK, and I would like hear your opinion. 1. Just ignore 2. Clear the call by sending DRQ 3. Send a IRQ and release the call if no response. thanks, Srini Trillium Digital Systems, Inc.

1 0

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

10 Mar '99

I think this sums things up. There was absolutely no intention that we mandate that H.245 be co-located with the MG. The only question was whether we would even consider it as an option. I think the answer is yes, but SG 16 has some issues to work out before it becomes a real priority for Megaco. These relate to definition of SG 16's interfaces B (occurs if H.225.0 call signalling is co-located with the MG) and E (occurs if H.245 is co-located with the MG). These interfaces are additional to the device control interface A, but will share the transport and do need to be coordinated with it. It is not our job to define what goes across those interfaces; the content will be tightly coupled to H.323. Until the definition of the messaging across those interfaces is well-begun, I'd say our main concern is what I stated in the first place: to make sure that our protocol is modular enough that parts of it can be left unused if the MG is designed to respond autonomously to H.245 messaging. The second possible requirement is to think about how to coordinate device control messaging with other messaging happening between the same boxes (e.g. back-hauled SCN signalling). Beyond that, I can't see any need to add anything to our protocol to support this option beyond the ability to negotiate its use. > -----Original Message----- > From: Christian Huitema [SMTP:huitema@research.telcordia.com] > Sent: Wednesday, March 10, 1999 12:42 PM > To: Rex Coldren; David R. Oran > Cc: Taylor, Tom-PT [SKY:B318-I:EXCH]; Mailing list for parties > associated with ITU-T Study Group 16; megaco(a)BayNetworks.COM > Subject: Re: FW: Where H.245 goes - MG or MGC (Skran's comments) > > On Mar 10, 8:57am, Rex Coldren wrote: > > Subject: Re: FW: Where H.245 goes - MG or MGC (Skran's comments) > > Just to get this argument back on track... > > > > Are we going to allow for the option of H.245 channels being opened > > on the MG? > > Hey, we are not the protocol police... The answer to your "are we going to > allow" is an unquivocal yes. You could in fact easily extend even our > simplest MG-MGC protocol (SGCP) to support H.245 in the gateway, for > example by declaring an "m=h245" media type in SDP. As Dave pointed out, > it would be difficult then to support the fast start option, but this > would definitely result in H.245 in the MG. It would also become very > difficult for the MGC to keep track of the resources used by the MG. > > The real question is whether the base protocol defined by Megaco should > mandate autonoumous support of H.245 in each and every MG. I think that at > this point, the consensus is "no." There is no need for a full support in > simple telephone-only gateways, the protocol is quite heavy and also > subject to rapid evolution with the definition of new media and new > algorithm, and the resulting resource control is very murky. > > On the other hand, there may be value in an H.245 "option", so that we > don't get three vendors implementing the H.245-in-the-gateway extensions > in three different ways. > > -- > Christian Huitema

1 0

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

10 Mar '99

Makes sense to me to allow for the OPTION of carrying H.245 messaging within Megaco protocol. This should be defined as an optional package. Not sure how it would be used in a product context, but that's ok, its optional. (I repeat myself, but don't want it to get lost on the twists and turns of the thread.) -- Peter Blatherwick > -----Original Message----- > From: Rex Coldren [SMTP:coldrenr@agcs.com] > Sent: 10 Mar, 1999 10:57 > To: David R. Oran > Cc: Taylor, Tom-PT [SKY:B318-I:EXCH]; Mailing list for parties > associated with ITU-T Study Group 16; megaco(a)BayNetworks.COM > Subject: Re: FW: Where H.245 goes - MG or MGC (Skran's comments) > > Just to get this argument back on track... > > Are we going to allow for the option of H.245 channels being opened > on the MG? > > David R. Oran wrote: > > > 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. > > > >

1 0

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

10 Mar '99

On Mar 10, 8:57am, Rex Coldren wrote: > Subject: Re: FW: Where H.245 goes - MG or MGC (Skran's comments) > Just to get this argument back on track... > > Are we going to allow for the option of H.245 channels being opened > on the MG? Hey, we are not the protocol police... The answer to your "are we going to allow" is an unquivocal yes. You could in fact easily extend even our simplest MG-MGC protocol (SGCP) to support H.245 in the gateway, for example by declaring an "m=h245" media type in SDP. As Dave pointed out, it would be difficult then to support the fast start option, but this would definitely result in H.245 in the MG. It would also become very difficult for the MGC to keep track of the resources used by the MG. The real question is whether the base protocol defined by Megaco should mandate autonoumous support of H.245 in each and every MG. I think that at this point, the consensus is "no." There is no need for a full support in simple telephone-only gateways, the protocol is quite heavy and also subject to rapid evolution with the definition of new media and new algorithm, and the resulting resource control is very murky. On the other hand, there may be value in an H.245 "option", so that we don't get three vendors implementing the H.245-in-the-gateway extensions in three different ways. -- Christian Huitema

1 0

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