Handling of nonreceipt of IRRs by gatekeeper

Srinivasa Beereddy srini at TRILLIUM.COM
Wed Mar 10 19:24:10 EST 1999


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 at 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 at 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.
> >
> 
> 



More information about the sg16-avd mailing list