- sg16-avd - lists.packetizer.com

decided version of H.323 Annex D is now in the Incoming directory of the avc-site
by Kumar, Vineet 28 Sep '98

28 Sep '98

The decided version of H.323 Annex D is now in the Incoming directory of the avc-site. Is there a new directory where all the decided and determined documents need to be uploaded ? vineet ---------------------------------------------------------------------------- -------------------------- Vineet Kumar vineet.kumar(a)intel.com Intel Corporation, JF3-212 (+1) 503-264-3439 (phone) Hillsboro, OR 97124-5961 (+1) 503-264-3375 (fax) ---------------------------------------------------------------------------- --------------------------

1 0

sourceInfo field in RAS LRQ messages
by Meir Fuchs 27 Sep '98

27 Sep '98

Hi, The H.225.0 (v2) standard describes the sourceInfo field in RAS LRQ messages as follows: sourceInfo - indicates the sender of the LRQ. The gatekeeper can use this information to decide how to respond to the LRQ. A gatekeeper recieves an ARQ and wishes to resolve the called endpoint by sending an LRQ to neighboring gatekeepers. What would you expect the gatekeeper to put in the sourceInfo field of the LRQ ? Several answers come to mind: a. The source info of the calling endpoint (… [View More]

1 0

test, please ignore
by Michael F. Speer 26 Sep '98

26 Sep '98

test, please ignore Michael

1 0

Re: Authentication
by Chris Purvis WVdevmt-WS 17 Sep '98

17 Sep '98

>How does GKs authenticate each other?, As yet, they don't... >and furthermore, how does a GK >authenticate an H.323 entity under its zone so that it can be sure it is >talking with the entitiy it claims to be?, I haven't seen anything on >this on the proposals for Anex G I've read. ...however, in version 2 of H.225.0 all RAS messages may contain authentication tokens. H.235 specifies the framework within which this works, although it does not prescribe any particular … [View More]

1 0

Authentication
by William Pimentel 16 Sep '98

16 Sep '98

How does GKs authenticate each other?, and furthermore, how does a GK authenticate an H.323 entity under its zone so that it can be sure it is talking with the entitiy it claims to be?, I haven't seen anything on this on the proposals for Anex G I've read. Thank you. William Pimentel

1 0

Re: (very) short summary of IETF E.164 BOF
by Scott Bradner 15 Sep '98

15 Sep '98

Pete gave a good summary of the BOF - one thing I'd add is that for more info on the DNS-based resolution you should take a look at RFC 1703 ftp://ftp.iana.org/in-notes/rfc1703.txt Scott

1 0

(very) short summary of IETF E.164 BOF
by Pete Cordell 15 Sep '98

15 Sep '98

Dear All, Following one of the inter-gk conference calls, I picked up an action to find out what is happening in the IETF E.164 area. Although I wasn't actually at the BOF this is what I have managed to pick up from a colleague. Firstly, a working group is to be created, which is likely to be (will be?) chaired by Scott Petrack. The details of the scope have not been fully fleshed out yet. The input to the process will be an E.164/telephone number. Whether local short-cut codes and … [View More]private networks are supported is still to be decided. The output has not been decided, but could range from a simple IP address, to something that may include alternate E.164 number, to something that would list a full set of remote endpoint capabilities. A number of proposals were discussed most of which had the theme of: convert E.164 number/telephone number to domain name, then convert domain name to IP address. The latter stage may involve something like the gateway location work. One proposal (Falstrom(?)) is to use DNS NAPTR records to convert E.164 numbers to domain names. To do this each digit would be separated by a dot, the sequence reversed, and then the domain name e164.int appended to it. e.g.: +44-1473-646436 -> 6.3.4.6.4.6.3.7.4.1.4.4.e164.int This could match multiple NAPTR records. The NAPTR records map to a domain name and include with them what service is associated with that domain name. e.g. The above address could map to: IN NAPTR 100 10 "s" "h323call+N2R" tele2.se IN NAPTR 100 10 "s" "sipcall+N2R" tele3.se The first one indicates that the h323call+N2R service is at address tele2.se, and that there is a SRV record (indicated by the "s") for it. The other values indicate priorities. (Not sure what the +N2R indicates) A set of these queries would be returned to the querier, and it could select the service it was interested in and would do a DNS SRV look-up to convert this to an IP address. One issue with this is that it has a single top-level domain. Huitema suggested that multiple organisations should be able to provide the top level mappings, which he called a conflicting claims method. Other proposals had variations on this theme, some of which included references to other databases such as X.500, LDAP and so on (Brown). This seems quite sensible and is well worth keeping an eye. Apparently not much has happened on the mailing list since, but this could be because Scott hasn't produced the minutes yet!!! Hope this helps, Pete ================================= Pete Cordell BT Labs E-Mail: pete.cordell(a)bt-sys.bt.co.uk Tel: +44 1473 646436 Fax: +44 1473 645499 ================================= [View Less]

1 0

RE: H.225 Annex G
by Roy, Radhika R, ALINT 13 Sep '98

13 Sep '98

Yes, there is only one editor. Suggestions are given to the editor and ITU-T SG16 members via contributions. Radhika R. Roy AT&T > ---------- > From: Jim Toga[SMTP:jim.toga@intel.com] > Sent: Friday, September 11, 1998 11:24 AM > To: Roy, Radhika R, ALINT; Andrew Draper; Chris Purvis WVdevmt-WS; > Douglas Clowes; Gene Schroeder; Hal Purdy; Joon Maeng; Kaynam Hedayat; > Korpi Markku PN VS LP3; Kumar, Vineet; Mayer, Paul G; Michele Bozier > WVdevmt-WS; Nancy-M Greene;… [View More] Orit Levin; Paul E. Jones; Pete Cordell; Santo > Wiryaman; Sengodan Senthil NRC/Boston; Sree Peyyety; Youngho Lim; > 'ggf(a)lucent.com' > Subject: RE: H.225 Annex G > > My assumption was that there was only one editor.... > > > At 08:59 AM 9/11/98 -0400, Roy, Radhika R, ALINT wrote: > >Glen: > > > >Thanks for the update. > > > >I have also a plan to present a complete version of the modified Annex G > >along the line as I proposed earlier as this version appears to be > >incomplete considering the facts that has described in my proposed > outlines > >of Annex G document (as well clarifications made in the subsequent > emails). > > > >Regards, > >Radhika > > > >> ---------- > >> From: Glen Freundlich[SMTP:ggf@lucent.com] > >> Reply To: ggf(a)lucent.com > >> Sent: Thursday, September 10, 1998 12:48 AM > >> To: Andrew Draper; Chris Purvis WVdevmt-WS; Douglas Clowes; Gene > >> Schroeder; ggf; Hal Purdy; Jim Toga; Joon Maeng; Kaynam Hedayat; Korpi > >> Markku PN VS LP3; Kumar, Vineet; Mayer, Paul G; Michele Bozier > WVdevmt-WS; > >> Nancy-M Greene; Orit Levin; Paul E. Jones; Pete Cordell; Roy, Radhika > R, > >> ALTEC; Santo Wiryaman; Sengodan Senthil NRC/Boston; Sree Peyyety; > Youngho > >> Lim > >> Subject: H.225 Annex G > >> > >> <<File: annexg.zip>> > >> 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-503-264-8816(voice) Intel - Hillsboro, OR. > *** > *** mailto:jim.toga@intel.com mailto:james.toga@ties.itu.int *** > *** PGP keyID 36 07 86 49 7D 74 DF 57 50 CB BA 32 08 9C 7C 41 *** > ***************************************************** > [View Less]

1 0

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

11 Sep '98

I have uploaded a draft of H.225 Annex G to the incoming directory of avc-site as h225_annexg.zip. 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

RE: H.225 Annex G
by Roy, Radhika R, ALINT 11 Sep '98

11 Sep '98

Glen: Thanks for the update. I have also a plan to present a complete version of the modified Annex G along the line as I proposed earlier as this version appears to be incomplete considering the facts that has described in my proposed outlines of Annex G document (as well clarifications made in the subsequent emails). Regards, Radhika > ---------- > From: Glen Freundlich[SMTP:ggf@lucent.com] > Reply To: ggf(a)lucent.com > Sent: Thursday, September 10, 1998 12:48 AM > To: … [View More]

2 1

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 … [View More]

1 0

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

10 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 … [View More]

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 … [View More]

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, … [View More]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 > > > [View Less]

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 … [View More]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 > >================================= > > > [View Less]

1 0

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

08 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 … [View More]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> > [View Less]

1 0

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

08 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 … [View More]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 > > > >> ---------- > > > [View Less]

1 0

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

08 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, … [View More]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 > > > [View Less]

1 0

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

08 Sep '98

<<m_Glenn>> Hi Glen: My reply is enclosed herewith. Many thanks for provding me an opprotunity to clarify the points. Thanks, Radhika > ---------- > From: Glen Freundlich[SMTP:ggf@lucent.com] > Reply To: ggf(a)lucent.com > Sent: Tuesday, September 08, 1998 2:58 PM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: Re: Annex G > > <<File: m_G.doc>> > I have added my comments as change-marked text in Radhika's document, … [View More]

2 1

Annex G
by Roy, Radhika R, ALTEC 08 Sep '98

08 Sep '98

Hi Editor/SG16 Members: A proposal on Annex G is enclosed. Your comments will be highly appreciated. <<m_G.doc>> Sincerely, Radhika R. Roy AT&T Tel: + 1 732 949 8657 Email: rrroy(a)att.com

3 2

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

08 Sep '98

Chris: I guess that you have received my earlier email addressed to you via ITU-T SG16 mailing list. As I mentioned before, AT&T's contribution deals with RAS signaling messages only. The proposal does separates RAS signaling in one stage, and call signaling in another stage. (In this respect, you are confused in understanding the AT&T's contribution. I guess that the above answer will clarify the situation. If still you have questions, please let me know.) Based on this clarification,… [View More] you can now create the RAS or call signaling scenarios as appropriate. We are taking about the communications between the GKs in multiple GK environment. So, the communication is occurring at the GK level, and is above the so-called network level (e.g., IP, ATM, or FR) level. If a GK decides which one is the next GK it needs to choose for sending a message, it constitutes a kind of routing at the GK level. As I mentioned before, H.323v2 does envision to transfer messages between the GKs, but H.323v2 does not have the means to abstract that notion of routing at the GK level. The communications between multiple GKs mean communications between multiple zones (or can also be said communications between "chain of zones"). Each GK will have a complete knowledge of its own zone. Each GK will have its address table, and the knowledge of the addresses can be obtained through exchanges of zone/LRQ messages. Each GK will have its ability how to route RAS message between the GKs knowing the destination addresses. So, the notion for communicating between the zones knowing the destination address is known (not a discovery in a random fashion as mentioned by you). In the case of multicasting between the GKs, the assumption is that it is again happening at the GK level. The notion is that the same message has to be "routed" to all GKs. The notion of "routing" between the GKs is still there although the network level multicasting can be used for implementation to route the message to each GK (as in your case you have chosen IP network. Please also note that a H.323 network can also be LAN, IP, ATM, FR, and/or others - in any combination). I hope that the above explanation will clarify the things. Thanks, 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 4:50 AM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: Re: Annex G > > Radhika, > > >The "abstraction of routing" between the GKs is an option. Whether the > >"abstraction of this routing option" to be used through a chain of zones > or > >not is left up to the implementation schemes. > > >If one does not feel the advantage of this option, then one may not use > it. > > >I hope that this will clarify the things. > > In that case I for one don't understand your proposal (nh_gkx2.doc). As > I understood it, it works like this: > A source endpoint sends an ARQ to its gatekeeper (GKA) to try to make a > call. GKA sends LRQs to various "friends" (GKB1, GKB2, GKB3, say), which > do the same in turn until they find the destination alias (which is for > instance known by GKD111, discovered via GKB1 and GKC11). Now GKA needs > to send an ARQ somewhere (if I understand your scheme correctly). The > only place it knows that it can send an ARQ to is GKB1, as the address > returned in the LCF is a call signalling address rather than a RAS > address, and may refer to the destination endpoint itself. Hence the ARQ > must, as I understand your scheme, be routed via GKB1, GKC11 and GKD111 > and not direct from GKA to GKD111. Yet you say the "chain of zones" is > an option. Therefore I misunderstand your proposal. > > >PS When we see references in H.323 that a message is to be sent from one > GK > >to another GK, it implies that the message has to be "routed" from one > GK to > >another. (In another scenario, when in H.323 it is assumed that messages > are > >to be sent between the GKs via "multicasting", it is also a kind of > >"routing" through a tree architecture that has a "chain of branches" > where > >GKs are located.) > You appear to confuse IP (or equivalent) routing with routing messages > via a number of H.323 entities. In order to route messages via a number > of H.323 entities (as you suggest) the IP routing phase needs to be done > multiple times. Worse, the message needs to be processed multiple times > on its travels, whereas if we leave IP to do a job it is good at the > message only needs to be processed at relevant places. > > 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 > [View Less]

1 0

Locating users
by William Pimentel 08 Sep '98

08 Sep '98

Last time i asked i was simply ignored (i guess that's better than being flamed but didn't help either), so if you think this is not the place to ask this, sorry. How do i locate a user when i don't know his/her alias? GK's mantain a list (or table) of alias-adress to perform translation when another H.323 entity requires this, what other information does the GK know about the registered endpoint? user's name, e-mail adress? I think it would be a good idea to have like an extension of the GK … [View More]

1 0

Re: Annex G
by Chris Purvis WVdevmt-WS 08 Sep '98

08 Sep '98

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. The … [View More]

1 0