- sg16-avd - lists.packetizer.com

Three TDs have been uploaded
by Sakae OKUBO 03 Sep '98

03 Sep '98

Dear Q.12-14/16 experts, I have placed the following three TDs for the coming SG16 meeting at the Incoming directory (ftp://standard.pictel.com/avc-site/Incoming/) H220AM6.zip - Amendment 6 to H.222.0 for Determination Q12status.zip - Q.12/16 status report Interim.zip - Report of interim Q.12-14/16 meetings They were all produced with Word 98 Mac (compatible with Word 97). Best regards, Sakae OKUBO (Mr.) *********************************************************** Waseda Research Center … [View More]

1 0

Re: H.323 Addresses
by Chris Purvis WVdevmt-WS 02 Sep '98

02 Sep '98

All, Good point, Pete! It's a shame you weren't on the call (there was a certain amount of guesswork as to how 800 numbers work)! There are two ways of handling this that I can see immediately. Although philosophically different, in practice they will normally amount to the same thing: 1. The "owner" of a domain needs to be told where a query originates, given that the calling location may affect the answer it gives or: 2. A border element handling queries for 800-type numbers needs to know … [View More]what to do with it depending on the origin of the query. 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 -------------------------------- Dear All, It may not be possible to handle 800 numbers in the same way as other numbers as the destination may be based on the geographical location of the caller. For example, ISPs may be accessible by something like an 800 number which may be fixed for a whole country, but the POP you end up connected to may vary depending on where you called from. I'm not sure what the implications of this are, but it is something to think about!!! Regards, Pete ================================= Pete Cordell BT Labs E-Mail: pete.cordell(a)bt-sys.bt.co.uk Tel: +44 1473 646436 Fax: +44 1473 645499 ================================= >---------- >From: Chris Purvis WVdevmt-WS[SMTP:cpurvis@MADGE.COM] >Sent: 02 September 1998 13:09 >To: ITU-SG16(a)MAILBAG.INTEL.COM >Subject: Re: H.323 Addresses > >Radhika, > >>We are discussing about H.323 addresing schemes in our bi-weekly H.323 >>inter-GK conf calls. >> >>The H.323 addresses that are being considered are 1. E.164, 2. E-mail, >3. >>URL, and 4. TCP/UDP/RTP port addresses (and 5. aliases as well I guess). >> >>Although a hierarchical notion of addressing scehmes have been >discussed, we >>have also recognized that some other variations of addressing schemes >are >>there. >> >>For example, people change their physical locations, but they might have >to >>keep the same E.164 addresses. So, a translation is needed. Therefore, >the >>very physical relationship of E.164 addressing scheme (e.g., knowing >NPAs >>and NXXs, one can find the distance) has been broken. > >I was under the impression that finally (after several weeks of >discussion) we'd reached closure on this in last Thursday's call. The >solution that I understood had been agreed came in two parts: >1. Mobile IP solves most of the problem for us - E.164 number resolves >to >an IP address which may be anywhere in the world at any given moment in >time. >2. If a user wants to move (and take their number with them) to being >in >an administrative domain with an otherwise reasonably contiguous E.164 >address space, this is easily handled as follows. The domain that >"should" (in the hierarchical sense) "own" the number that the user is >keeping holds a record of where to contact the current holder of that >number (which will typically be an entity to which an LRQ message can >be >sent). > >>Another example can be 800 numbers where the translation is also needed. >It seemed to be agreed in the call that 800 numbers are not a special >case, but merely an example of number portability. > >>In addition, from mobility point of view (device or person) wired (and >>wireless?) environement may also be looked into. >Does this mean anything at all? > >>As we go froward, we may consider many of those aspects as pointed above >to >>provide solutions for the H.323 addressing schemes. >I was under the impression that we'd reached closure on most of these >already. > >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]

2 1

Re: Communications between Administrative Domains
by Andrew Draper WVdevmt-WS 02 Sep '98

02 Sep '98

On Wed, 2 Sep 1998 10:37:32 +1000 Douglas Clowes wrote: > From my POV, this underscores the need for thought on the Back End > Services, both in terms of the services to be offered, and the protocol(s) > to support those services. Just for my information, where does the term Back End Services come from? Is this related to some sort of protocol currently run by telcos (SS7 database services for example)? Does the term always refer to a third server somewhere else which communicates … [View More]with both the originating and destination border elements? While discussing billing, I assume that we are only discussing payment from the originating administrative domain to the destination administrative domain and that we are not discussing payment to the transport network providers (such as ISPs) for QoS connections (such as those set up by RSVP). > Here, it is fairly clear that authentication and billing is a Back End > Service. The available destinations for a call may be dependent on the > (authenticated) identity of the caller. Yes, I agree that some entities will reject SETUP messages which are not authenticated and do not provide a suitable payment token. However, I think we should try hard to design a protocol which will not cause hopeless (bound to fail) SETUP messages to be sent. This is important because a) SETUP messages create state in the recipient and b) SETUP messages may involve charges to the originating administrative domain. Later on in this message I use the term "setup requirements" to refer to a description of setup messages which the destination administrative domain will accept. Examples would be "you must authenticate using mechanism X (and server Y)" or "you must pay using method Z" (are there any other forms of setup requirement?). I use the term "setup capabilities" to refer to the set of mechanisms which the originating border element is able to send in a SETUP message (because they have been implemented and enabled). > The "token" to be included in the > Setup message is produced by the Back End Service and may well be > destination sensitive. I agree. > Which raises the possibility of address translation > also being a back end service. In the sense of having a third party server (not belonging to the originating or destination administrative domain) perform address translation I agree. > Back-End Services (may) include: > > o caller identification, authentication, and authorisation; > o address translation, gateway location; > o call pricing; > o call detail recording, billing, and settlement; By my understanding of the term back-end services (which might be wrong) call pricing is for the destination administrative domain and is unrelated to any third party server. Call detail recording is also a problem only for the destination administrative domain. > which are all interrelated Out of interest, are you expecting/requiring that the services provided by each of your bullet points must be provided by the same third party server (or would using one server for address translation and another for billing be acceptable). If not then how are they all interrelated? > and, in total, outside the scope of the > gatekeeper to gatekeeper communications. I disagree. Here are my reasons for thinking that identifying the requirements of the destination administrative domain fall within the scope of communications between administrative domains (an important subset of gatekeeper-gatekeeper communications). To prevent hopeless SETUP messages from being sent the originating border element (or a third party) needs to work out the intersection of its setup capabilities and the destination border element's setup requirements. As far as I can tell there are three ways for the originating BE to find out the destination administration domain's setup requirements: a) It can find out during the resolution stage (the stage where an email-ID or E.164 number is translated to the address of a border element). b) It can find out during the LRQ/LCF exchange. c) We could design an extra protocol which is used before/after LRQ/LCF to let the originating BE find out what the requirements of the destination BE are. For an email-ID type destinationAddress using the DNS to find the destination border element seems non-controversial. DNS only provides the name and address of the destination, so method a is not appropriate. In this case I favour method b over method c for two reasons: firstly because it reduces the number of round trips required for a call setup and secondly because requirement 7 (of the latest annex G draft "diff0201.doc") suggests that the minimum number of changes to existing protocols should be made. The E.164 to border element address protocol is as yet unspecified, so it could return the requirements of the destination administrative domain at the same time as it returns the address to which to send LRQ. If the E.164 number resolves to an administrative domain which can be contacted directly then this doesn't seem to help much (as only one address is provided to which an LRQ must be sent anyway - so there are no efficiency savings to be made). If the E.164 number would resolve to one or more third party gateways (eg. for a POTS number) then passing the setup capabilities of the originating border element might help narrow down the responses which the resolution server returns. However this has security implications and so should be a choice for the originating BE. We still need a mechanism for the originating BE to ask the destination BE about its setup requirements if it is being paranoid and not telling the resolution server. Hope this makes sense (and my assumptions aren't too wildly different from yours). Regards, Andy. -- Andrew Draper - Principal Development Engineer - WAVE Software Madge Networks, Wexham Springs, Framewood Road, Wexham, Berks. mailto:adraper@dev.madge.com phone:+44 1753 661329 pgp fingerprint D6 ED 72 4F 96 BB CA 2D 68 74 4C E0 CB B9 0B 3F [View Less]

2 1

Directory Services?
by William Pimentel 02 Sep '98

02 Sep '98

Hi all I haven't seen anything about directory services interacting with GKs, how would a user know the alias (number or string) of the other party he/she wants to call? Or is there any way for a Terminal user to retrive/search the users currently registered with a GK? And what if the other party is register with another GK? Thanks -- William Pimentel w-piment(a)uniandes.edu.co

1 0

subscribe, how to
by Barnaby Duncan 02 Sep '98

02 Sep '98

I wish to subscribe to this list. Please infrom me of the way to do that. Barnaby

1 0

Re: H.323 Addresses
by Pete Cordell 02 Sep '98

02 Sep '98

Dear All, It may not be possible to handle 800 numbers in the same way as other numbers as the destination may be based on the geographical location of the caller. For example, ISPs may be accessible by something like an 800 number which may be fixed for a whole country, but the POP you end up connected to may vary depending on where you called from. I'm not sure what the implications of this are, but it is something to think about!!! Regards, Pete ================================= Pete … [View More]Cordell BT Labs E-Mail: pete.cordell(a)bt-sys.bt.co.uk Tel: +44 1473 646436 Fax: +44 1473 645499 ================================= >---------- >From: Chris Purvis WVdevmt-WS[SMTP:cpurvis@MADGE.COM] >Sent: 02 September 1998 13:09 >To: ITU-SG16(a)MAILBAG.INTEL.COM >Subject: Re: H.323 Addresses > >Radhika, > >>We are discussing about H.323 addresing schemes in our bi-weekly H.323 >>inter-GK conf calls. >> >>The H.323 addresses that are being considered are 1. E.164, 2. E-mail, >3. >>URL, and 4. TCP/UDP/RTP port addresses (and 5. aliases as well I guess). >> >>Although a hierarchical notion of addressing scehmes have been >discussed, we >>have also recognized that some other variations of addressing schemes >are >>there. >> >>For example, people change their physical locations, but they might have >to >>keep the same E.164 addresses. So, a translation is needed. Therefore, >the >>very physical relationship of E.164 addressing scheme (e.g., knowing >NPAs >>and NXXs, one can find the distance) has been broken. > >I was under the impression that finally (after several weeks of >discussion) we'd reached closure on this in last Thursday's call. The >solution that I understood had been agreed came in two parts: >1. Mobile IP solves most of the problem for us - E.164 number resolves >to >an IP address which may be anywhere in the world at any given moment in >time. >2. If a user wants to move (and take their number with them) to being >in >an administrative domain with an otherwise reasonably contiguous E.164 >address space, this is easily handled as follows. The domain that >"should" (in the hierarchical sense) "own" the number that the user is >keeping holds a record of where to contact the current holder of that >number (which will typically be an entity to which an LRQ message can >be >sent). > >>Another example can be 800 numbers where the translation is also needed. >It seemed to be agreed in the call that 800 numbers are not a special >case, but merely an example of number portability. > >>In addition, from mobility point of view (device or person) wired (and >>wireless?) environement may also be looked into. >Does this mean anything at all? > >>As we go froward, we may consider many of those aspects as pointed above >to >>provide solutions for the H.323 addressing schemes. >I was under the impression that we'd reached closure on most of these >already. > >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: H.323 Addresses
by Chris Purvis WVdevmt-WS 02 Sep '98

02 Sep '98

Radhika, >We are discussing about H.323 addresing schemes in our bi-weekly H.323 >inter-GK conf calls. > >The H.323 addresses that are being considered are 1. E.164, 2. E-mail, 3. >URL, and 4. TCP/UDP/RTP port addresses (and 5. aliases as well I guess). > >Although a hierarchical notion of addressing scehmes have been discussed, we >have also recognized that some other variations of addressing schemes are >there. > >For example, people change their physical … [View More]

1 0

Re: H.323 Addresses
by Ami Amir 02 Sep '98

02 Sep '98

Hi Radhika, FYI - the IETF is just starting work on E.164 to IP address resolution - the last IETF meeting covered this subject - and maybe someone on our list is also active there and could help (or server as a contact person)? Ami -----Original Message----- From: Roy, Radhika R, ALTEC [SMTP:rrroy@ATT.COM] Sent: Tuesday, September 01, 1998 8:38 PM To: ITU-SG16(a)mailbag.cps.intel.com Subject: H.323 Addresses Hi Everyone: … [View More]

1 0

Subscribe
by denggc 01 Sep '98

01 Sep '98

Can i subscribe and watch the status of H.323 Development ?

1 0

Re: Communications between Administrative Domains
by Andrew Draper WVdevmt-WS 01 Sep '98

01 Sep '98

Santo, Enclosed are my responses to your comments. Hopefully this will help clarify my meaning in the areas where the proposal was unclear. Regards, Andy -- Andrew Draper - Principal Development Engineer - WAVE Software Madge Networks, Wexham Springs, Framewood Road, Wexham, Berks. mailto:adraper@dev.madge.com phone:+44 1753 661329 pgp fingerprint D6 ED 72 4F 96 BB CA 2D 68 74 4C E0 CB B9 0B 3F

2 1