September 1998 - sg16-avd - lists.packetizer.com

Discussion TD re MPEG stream packetization
by Sakae OKUBO 11 Sep '98

11 Sep '98

Dear Q.12-14/16 experts, I have sent the following TD to Geneva: ftp://standard.pictel.com/avc-site/9809_Gen/Input_TD/MPEG_pac.zip Source: Q12 Rap Title: Study on MPEG stream packetization 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

Drafts H.450.9 and H.RDC
by Sakae OKUBO 11 Sep '98

11 Sep '98

Dear Q.12-14/16 experts, The following files have been moved from /Incoming to: ftp://stanard.pictel.com/avc-site/9809_Gen/Input_TD/h450.8_980910.zip (G Freundlich) ftp://stanard.pictel.com/avc-site/9809_Gen/Input_TD/H_RDC_Proposal.zip (M Duckworth) 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

H.RDC proposal available on ftp site
by Mark Duckworth 10 Sep '98

10 Sep '98

My Temporary Document regarding H.RDC is available at ftp://standard.pictel.com/avc-site/Incoming/H_RDC_Proposal.zip This is a proposal for carrying the Common Remote Device Control protocol on a new Data Link Protocol in an H.323 conference. This simple Data Link Protocol runs over a bidirectional unreliable logical channel. It allows many RDC nodes to communicate with each other in a multipoint conference. Mark Duckworth PictureTel Corporation

1 0

H.450.8 - Identification Services
by Glen Freundlich 10 Sep '98

10 Sep '98

I have uploaded the draft of H.450.8, Identification Services, to the incoming directory of the avc-site. The file appears as h450.8_980910.zip. The hope was to propose this for determination at the upcoming SG16 meeting. Regards, Glen -- Glen Freundlich ggf(a)lucent.com Lucent Technologies office: +1 303 538 2899 11900 N. Pecos fax: +1 303 538 3907 Westminster, Colorado 80234 USA

1 0

H.225 Annex G
by Glen Freundlich 10 Sep '98

10 Sep '98

Attached is my first attempt at Annex G. I'm sure I've omitted things or misrepresented things, so please review this and send your comments as soon as possible. I'd like to get another version around for comments before I distribute it to the SG16 list. Glen p.s.: I've sent this only to the group of people who have been on the conference calls. -- Glen Freundlich ggf(a)lucent.com Lucent Technologies office: +1 303 538 2899 11900 N. Pecos fax: +1 303 538 3907 Westminster, Colorado 80234 USA

1 0

FW: E.164 Resolution
by Nancy-M Greene 09 Sep '98

09 Sep '98

Here is some information on E.164 Resolution from Anne Brown. I promised to send this to the group in the Annex G call today. Nancy -------------------------------------------------------------------------- Nancy Greene (internally Nancy-M Greene) Internet & Service Provider Networks, Nortel NOTE NEW TELEPHONE NUMBERS: T:514-271-7221 (internally ESN853-1077) E:ngreene@nortel.com > ---------- > From: Brown, Anne [NORSE:6L45:EXCH] > Sent: Wednesday, September 09, 1998 11:05 AM > To: Greene, Nancy-M [CAR:6F13:EXCH] > Subject: E.164 Resolution > > <<Microsoft Word Document>> > Nancy, > > Attached is the proposal for E.164 resolution that I presented at the > Chicago > IETF. There are some missing pieces that I have to add before submitting > as > a draft to the IETF. A person from TIPHON expressed an interest in > co-authoring the draft so I have to ensure that I have his input as well. > > It is not scoped to be a solution for GW location, however, there is > a possibility that the proposal may help out with this problem. GW > location > requires additional service logic that a directory does not provide. > > I am subscribing to the SG16 listserv, but because I'll be in at SG7 in > Beijing for the next three weeks, I may not be able to follow very > closely at first. > > Basically the proposal is as follows: > > In order to ensure business-grade service and access to endpoint addresses > (mostly for servers holding required informtion), given an E.164 address, > there > must be a global third-party service that spans geo-political boundaries. > An > Internet Telephony Directory Service Provider (ITDSP) will list E.164 > mapping > information on behalf of carriers, ISPs, etc. They will probably not be > responsible for allocation and assignment of numbers, however this is > entirely possible. Access to ITDSP information should be free and > unauthenticated, unless a number is requested to be unlisted. > > If more than one organization wishes to provide ITD services, they must > cooperate with all other ITDSPs to form a federation such that you will > get the same information back, no matter which service provider you > query. > > The interfaces between the components (ITDSP servers, ITDSP consumers, > ITDSP suppliers) are described, as well as the rationale for thissolution. > I have included a section that describes how the solution relates to > other related standards and initiatives. > > The solution was designed to support immediate adoption, while allowing > additional uses in the future. As far as I can tell, it does not pose any > limitations on future services like global number portability, etc. > > I hope this helps, > Anne > > >

1 0

Re: No root node/H.323 addressing
by Roy, Radhika R, ALTEC 09 Sep '98

09 Sep '98

Hi Everyone: I like to refer to a contribution - R. Scholl, "RFI: Requirements for Very Large Scale E.164 -> IP Database", ETSI EP TIPHON 9, Portland, 31 Aug.-03 Sept 1998. The findings of this contribution can be interesting to the ITU-T SG16 as well. For example, "...The name space will eventually be completely flat. .. A flat name space (or number space) facilitates number portability...This is contrary to the hierarchical DNS or X.500 name sapce. .. a flat name space does not necessarily mean a flat database architecture. .." As we go forward for the H.323 addressing schemes, this paper might also provide us some help in that direction. Regards, Radhika R. Roy AT&T > ---------- > From: Pete Cordell[SMTP:pete.cordell@BT-SYS.BT.CO.UK] > Reply To: Mailing list for parties associated with ITU-T Study Group > 16 > Sent: Friday, September 04, 1998 2:37 PM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: Re: No root node > > Santo, > > In general, to a first order approximation, I would expect a fully > meshed arrangement of 'country' border elements. However I would see > the fine detail of the structure being down to who people have > arrangements for resolving addresses with. For example, BT might go to > AT+T to resolve all North and South American numbers, and AT+T might > come to BT for all European numbers. I could also see that > opportunistic companies could set up global clearing houses that would > handle address translation for outfits that haven't been able to > establish their own knowledge of all the borders such as ISPs, or > corporates. This would look like a root node to the people that used > it, but it would be used purely as a commercial expedient and not > mandated by the way the standard works. > > On the issue of France moving its entry point to Lyon for the week, I > think we have to allow France to have more than one entry point. After > all, Paris could all of a sudden slide into the Seine, and the press, if > nobody else, would still want to make calls into France to find out > what's going on. By having multiple entry points, the French can turn > off their Paris BE for a while and switch on their Lyon one, and if the > data didn't propagate around the system for a while it wouldn't really > matter too much. > > Pete > ================================= > Pete Cordell > BT Labs > E-Mail: pete.cordell(a)bt-sys.bt.co.uk > Tel: +44 1473 646436 > Fax: +44 1473 645499 > ================================= > > > >---------- > >From: Santo Wiryaman[SMTP:swiryaman@VIDEOSERVER.COM] > >Sent: 04 September 1998 17:29 > >To: ITU-SG16(a)MAILBAG.INTEL.COM > >Subject: Re: No root node > > > >Hi All, > > > >I am not at all opposed to eliminating the root domain. A couple of > >questions for Pete and the group: > > > >1. Are you suggesting that at the national level the border elements > >are fully meshed together, or alternatively arranged in a big ring as > >Radhika is suggesting? > >2. If so, when a new country "goes on-line" endpoints in the new > >country would not be reachable until the information is propagated in > >this fully meshed database (or inserted in the ring). > >3. Same if, say France, had to switch its National H.323 Border > Element > >from Paris to Lyons for one week. > >4. Are you open to the idea of a global clearing house to resolve the > >address of border elements of countries which are currently not listed > >in the fully-meshed database. > > > >Regards, > > > >Santo Wiryaman > >Videoserver > > > > > >---------- > >From: Pete Cordell [SMTP:pete.cordell@BT-SYS.BT.CO.UK] > >Sent: Thursday, September 03, 1998 10:20 AM > >To: ITU-SG16(a)mailbag.cps.INTEL.COM > >Subject: No root node > > > >Dear All, > > > >Apologies for not being on the last call, but... > > > >I feel one really important issue with Santo's contribution is that we > >must remove the root domain. Having such a concept would give > >politicians and lawyers far too much work!!! I believe the notes that > >I > >put forward would allow the root node to be removed, and based on > >comments I heard from Jim, I believe what he is proposing would allow > >this too. > > > >Regards, > > > >Pete > >================================= > >Pete Cordell > >BT Labs > >E-Mail: pete.cordell(a)bt-sys.bt.co.uk > >Tel: +44 1473 646436 > >Fax: +44 1473 645499 > >================================= > > >

1 0

Re: Annex G
by Roy, Radhika R, ALTEC 09 Sep '98

09 Sep '98

Santo: I guess that LRQ/LCF/LRJ and BRQ/BCJ/BRJ are more clearly explained in the contribution. This was also clarified in response to your earlier questions. URQ/UCF/URJ and DRQ/DCF/DRJ may be needed in multiple GK environment if the GKs of those zones are involved in keeping the information (e.g., LRQ caches, resource reservation, etc). IRQ/IRR is needed for status information. Like single GK, multiple GKs may be involved in allocating resources or for other purposes, it would be helpful to take appropriate actions by all GKs involved once the status infromation is known. Please let me know whether things are better understood now. Thanks, Radhika > ---------- > From: Santo Wiryaman[SMTP:swiryaman@VIDEOSERVER.COM] > Reply To: Mailing list for parties associated with ITU-T Study Group > 16 > Sent: Tuesday, September 08, 1998 9:02 AM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: Re: Annex G > > Radhika, > > Since your proposal for passing all RAS messages differ radically from how > an inter-zone call works in H.323, today, it would be helpful for you to > describe in detail how call signaling messages flow between, say, > Endpoint1 > in Zone1 to Endpoint4 in Zone4, which traverse zones 2 and 3. > > Up to now you have strongly advocated that all RAS messages be passed from > one GK to another without giving a specific example on how the following > messages would be propagated: > 1. RRQ/RCF/RRJ > 2. ARQ/ACF/ARJ > 3. LRQ/LCF/LRJ > 4. IRQ/IRR > 5. BRQ/BCF/BRJ > 6. DRQ/DCF/DRJ > 7. URQ/UCF/URJ > > Therefore an example of an inter-zone call such as proposed above from you > would be helpful for us to see why you are proposing what you are > proposing. > Thanks. > > -santo > > ---------- > From: Chris Purvis WVdevmt-WS [SMTP:cpurvis@MADGE.COM] > <mailto:[SMTP:cpurvis@MADGE.COM]> > Sent: Monday, September 07, 1998 12:30 PM > To: ITU-SG16(a)mailbag.cps.intel.com > <mailto:ITU-SG16@mailbag.cps.intel.com> > Subject: Re: Annex G > > Radhika, > > In my view there is a fundamental difference between the scheme that you > are > proposing and the other contributions on inter-administrative-domain > communication: > Your proposal continues to expect all RAS, call setup, media negotiation > and, (for all I know - it's not clear to me in your proposal), data > packets > associated with a call to follow a path through intermediate entities that > are on the path that address resolution messages happened to take. > All the other proposals I have seen preserve a separation between the > resolution phase (where messages may indeed need to be sent to a number of > different places), and the call signalling stage which follows a more > direct > route between endpoints. > Your proposal requires the addition of extra fields to almost all RAS > messages, and will generate a significant amount of extra call signalling > traffic on the global network. > I still fail to understand what the technical (or business) advantages of > this extra propogation of messages are. My impression was that the vast > majority of the people on last Friday's conference call share my > scepticism. > Regards, > Chris > > -- > Dr Chris Purvis - Senior Development Engineer, WAVE CC Software Madge > Networks Ltd, Wexham Springs, Framewood Road, Wexham, Berks. > Phone:+44 1753 661359 email: cpurvis(a)madge.com <mailto:cpurvis@madge.com> >

1 0

Re: Annex G
by Roy, Radhika R, ALTEC 09 Sep '98

09 Sep '98

> Douglas: > > I am so happy to see your insights in solving the specific problems. I > exactly understand where you are driving at. The inter-GK signaling are > the most interesting problems. The more you dig, the more jewels will come > up. Let me explain why I am saying so. > > Instead of providing point by point reply of your email, I will provide a > generalized answer so that you can find answers for other specific schemes > as well. > > H.323v2 envisions that signaling messages can be passed through the GK. We > are just extending the situation in the case of multiple GK environment. > In your example, you have made an assumption that all signaling messages > will follow the same path (Please forgive me that this path is the not > network-level path. This path notion is of GK-to-GK level) between the > GKs. It does NOT have to be so. A GK is an application layer entity, and > can be made to have much higher intelligence (what we cannot expect at the > network level devices or entities because they have other constraints). A > GK can understand each signaling message, and a decision can also be taken > how to route each signaling message that if one wants to implement that > way. (As if it appears that the routing has become multidimensional!) > > For example, a GK can be used to route messages for authentication in one > way while the billing messages in another way. Similarly, ARQ messages may > be routed in another way. This routing between the GKs can be > implementation specific, and at H.323 level, we are creating abstraction > of routing of signaling messages (Please note that we are NOT providing > any solutions for specific rotuing schems at the H.323 level for any > specific signaling messages. Let an implemetor decide that). Please note > that we are NOT making assumptions, at H.323 level, that all signaling > messages will be sent through the same GK-GK path. > > I hope that it may clarify the fundamental question for which we are > looking for an answer. > > Regards, > Radhika > > ---------- > From: Douglas Clowes[SMTP:dclowes@OZEMAIL.COM.AU] > Reply To: Mailing list for parties associated with ITU-T Study Group > 16 > Sent: Tuesday, September 08, 1998 8:17 PM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: Re: Annex G > > At 18:17 08/09/98 -0400, Radhika wrote: > > <<m_Glenn>> > > > >Hi Glen: > > > >My reply is enclosed herewith. Many thanks for provding me an opprotunity > to > >clarify the points. > > > Radhika, > > In part, you wrote: > > >>>> > > In the direct endpoint, the call will be established directly between the > endpoints although the call will be established over the multiple zones, > and no GK will be involved.] > > <<<< > > You have also made other statements made about bandwidth management in > intermediate zones. I _still_ have the feeling that, despite statements to > the contrary about media routing, you are still expecting the media > packets will flow "over the multiple zones". In the general case, > especially with no explicit path management (suck as GK-routed media), > there is absolutely no reason why they should. > > In the scenario Z2---Z3---Z4 > / \ > / \ > C1--Z1--------------Z5--C5 > > Each Zone may be in a different administrative domain. The relationships > between administrative domains may not be mesh topology, but linear; > sequential in increasing numerical order. Inter-gatekeeper communication > may have to go the long way round because of established relationships, > authentication, and authorisation requirements. But, in my aspirations, > call setup and media would be able to take the direct route. There is > nothing to be gained by having Zones Z2, Z3, and Z4 active in bandwidth > management at the ARQ, It is even counter-productive to have Zone Z3 > reject the call because its LAN is busy with internal traffic. > > What needs to happen here, is that the source gateway (GW1) needs to > obtain, from the ARQ stage, an authorisation token acceptable to the > destination gateway (GW5), or its gatekeeper (GK5). This token > authenticates the call, authorises it, and provides for the payment > mechanism. The token is to be included in the call setup, and probably in > the ARQ in response, meaning GK5 generates and validates the token. > > Payment follows the relationships, Z1=>Z2=>Z3=>Z4=>Z5, but, for each zone > to authorise the call, it needs the call to be identified as originating > from a trusted party. Since only Zone Z1 trusts Customer C1, the source > information needs to be augmented along the way. Zone Z2 only trusts Zone > Z1 and expects to be paid by Zone Z1, not Customer C1. And, so it goes > down the path. > > Coming back, the ACF needs to contain the ultimate call signalling address > in Zone Z5, be it the gateway or gatekeeper in that zone. You can always > go for GK routed through each zone, if you want to measure call duration > yourself; but, I would expect that to be limited to exclude the media. > > At settlement time, the billing goes in the reverse direction. Zone Z5 > bills Z4=>Z3=>Z2=>Z1=>C1 and the customer, hopefully, pays. > > Now, whether token generation and validation, and all the authentication, > validation, billing and settlement, is done within the gatekeeper, or by > the elusive Back-End Services provider, is unresolved at this time. > > Regards, > > Douglas > > >Thanks, > >Radhika > > > >> ---------- > > >

1 0

Re: Annex G
by Roy, Radhika R, ALTEC 09 Sep '98

09 Sep '98

Chris: I have enclosed my reply below. Thanks for providing me an opportunity to clarify further. Regards, Radhika > ---------- > From: Chris Purvis WVdevmt-WS[SMTP:cpurvis@MADGE.COM] > Reply To: Mailing list for parties associated with ITU-T Study Group > 16 > Sent: Tuesday, September 08, 1998 1:25 PM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: Re: Annex G > > Radhika, > > >Yes, AT&T's contribution, like other proposals, also separates between > the > >RAS signaling stage and the call signaling stage. So, the call signaling > is > >free to take any path as appropriate. > Thank you for this clarification. Given that you are now permitting > call-signalling and RAS messages to follow different routes I see no > advantage, when placing a call between administrative domains, to routing > any RAS message other than LRQ/LCF/LRJ between gatekeepers/BEs. > > [Radhika: A H.323 call is end-to-end. Moreover, H.323 is an application. > That is, it will have both network layer and upper layer (above network > layer) resources. An MCU in the carrier network that will have resources > at both network layer and upper layer may be shared among thousand of > users. Now an end-to-end H.323 call may span between the domains that will > have H.323 networks (LAN, IP, ATM, FR, and/or others - in any > combinations). It happens to be that the two domains need to send > signaling messages via border GKs/Border Elelments. H.323v2 envisions that > the GK will have an abstraction of BW/QOS at the GK level. If we take the > example of ARQ messages, then the ARQ has to be confirmed between the > end-to-end considering both network layer and upper layer resources as > well. So, this simple example shows why the signaling messages need to be > sent across the domains if one needs to implement that option to > differentiate services.] > > The other problem your proposal appears to be trying to solve appears to > be that of roaming users. Andrew Draper's email of 21st August explains > why there is no necessity for a roaming endpoint to register with a > foreign gatekeeper. Thus support of roaming users is no reason to route > GRQ/GCF/GRJ, RRQ/RCF/RRJ, ARQ/ACF/ARJ, BRQ/BCF/BRJ, URQ/UCF/URJ, > DRQ/DCF/DRQ, IRQ/IRR/IACK/INACK and RAI/RAC/RIP/NSM/XRS between > gatekeepers. > > [Radhika: I feel that Mr. Draper's email is not the last word in solving > the H.323 mobility problems. It may be one of the options (may not be the > best) to solve the H.323 mobility problems in a limited way. (For example, > IP mobility problems could also be solved in a similar way that has > described by Mr. Draper. Unfortunately, mobile IP people has taken a > different approach.) I personally feel that the H.323 mobility problems > are much more complex, and it requires careful study to find efficient > solutions. Probably, a mini-group, like inter-GK, may have to work to find > the appropriate solutions. The most important point is that the signaling > messages need to be sent across all Zones and Domains, because a services > provider may find numerous ways to create back-end services through > intercepting the signaling messages from the GKs as appropriate. The more > important point is that H.323 signaling messages exist, and it is almost > against the principle of standard making process to MANDATE not to use > those signaling messages either for the inter-zone or for the inter-domain > communications, and I believe that it may also NOT be acceptable to the > ITU-T as a matter of principle.] > > Nokia's APC 1382 (S. Sengodan, Nokia, "On the Use of Multicast Scope for > Gatekeeper Discovery," is explicitly limited to GRQ/GCF/GRJ, and may be > of interest as a way of propogating knowledge of gatekeepers within an > administrative domain. The zone messages proposed by Jim Toga in > APC-1422 are an alternative solution to a similar problem. > > [Radhika: Here, I am not sure whether we are speaking the same thing. In > APC 1382, Mr. Sengodan has shown why the exiting GRQ message fields need > to be extended for the GK-to-GK communications considering the multiple GK > communication environment if multicasting is used. I think that this work > has become one of the most important contribution if one needs communicate > between the multiple GKs considering the multicasting. I was referring > that work. (Mr Toga also has done a beautiful work for the zone message > sets.) Similarly, AT&T contribution, similar to Nokia's, has proposed the > extension of the existing RAS message fields for communications in > multiple GK environment.] > > Regards, > Chris > -- > Dr Chris Purvis - Senior Development Engineer, WAVE CC Software > Madge Networks Ltd, Wexham Springs, Framewood Road, Wexham, Berks. > Phone:+44 1753 661359 email: cpurvis(a)madge.com > > >

1 0