July 2000 - sg16-avd - lists.packetizer.com

subscribe
by nagaraju 26 Jul '00

26 Jul '00

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

APC-1883a
by Terry L Anderson 25 Jul '00

25 Jul '00

After I uploaded APC-1883, a copy of the internet draft of CPL <draft-ietf-iptel-cpl-01.txt>, to the incoming directory, a new draft, 02, was made available. So I have created APC-1883a containing the newer draft and uploaded it. Could you remove the APC-1883.zip file and replace it with the new APC-1883a.zip? Thank you. -- ------------------------------------------------------------ Terry L Anderson mailto:tla@lucent.com Tel:908.582.7013 Fax:908.582.6729 Pager:800.759.8352 pin 1704572 1704572(a)skytel.com Lucent Technologies/ Voice Over IP Access Networks/ Applications Grp Rm 2B-121, 600 Mountain Av, Murray Hill, NJ 07974 http://its.lucent.com/~tla (Lucent internal) http://www.gti.net/tla

1 0

Re: [H.323 Mobility:] Usage of H.225 Annex G in H.323 Annex H
by Roy, Radhika R, ALCOO 25 Jul '00

25 Jul '00

Hi, Jaakko and All: In fact, AT&T's contribution APC-1770 submitted in Osaka provides the framework for H.323 inter-domain mobility management using H.225.0 Annex G. So far I understand that this framework has been accepted. The next question is: How do we extend the H.323 protocol to support mobility using H.225.0 Annex G? We have not resolved this issue. I made several attempts what we need to do and why some of the proposals made earlier were NOT acceptable from Annex G point of view. I raised the issue that some proposals for inter-domain communications VIOLATE Annex G. One of the fundamental objections has been Figure 7 (H.323 Annex H Functional Architecture Diagram with Reference Points) of H.323 Annex H draft that shows that "VLF of one domain can communicate with another domain." In my opinion, this "VIOLATES" H.225.0 Annex G. Because Annex G ONLY allows that the communications between the two domains can ONLY be permitted via Border Elements (BEs). I am fully confident that we can solve all H.323 mobility related problems abiding by the "fundamental" principles of H.225.0 Annex G. For example, APC-1770 provides guidelines how we can do this. Please note that this is a very "SERIOUS" issue as I explained in many of my emails because it may break the fundamental protocol architecture of H.323 in general. One of the examples can be H.323 QOS. For inter-domain QOS, we also need to adhere to the same principles of H.225.0 Annex G. We cannot allow one QOS manager module sitting behind the GK will be communicating with another QOS manager of another domain "by-passing" the BEs. Similarly, we can extend the models for billing, directory, and many other services. In fact, H.225.0 Annex G is addressing usage and other services that are used for billing, and Annex G has solved this problem through communicating via BEs (not by-passing them). If one by-passes the BEs (as the VLFs and HLFs of Figure 7 do), people can develop an entirely new protocol (or a new sets of protocols) that can be totally independent of H.323 protocol ( and may not have any relationship of the existing H.323 or H.225.0 Annex G protocol). So, I am raising my serious concerns as I did in the past. I am also enclosing a copy of APC-1770. I like to see the comments of other members as well. Best regards, Radhika R. Roy AT&T -----Original Message----- From: Jaakko Sundquist [mailto:jaakko.sundquist@NOKIA.COM] Sent: Tuesday, July 25, 2000 9:19 AM To: ITU-SG16(a)MAILBAG.INTEL.COM Subject: [H.323 Mobility:] Usage of H.225 Annex G in H.323 Annex H Hi all, As the Mobility AHG members know, the idea of using the H.225 Annex G (Communication between Administrative Domains)protocol in H.323 Annex H has been brought up many times in the discussions. So far, we haven't, however, made any decision or even exhaustive proposals for its usage. Now, the next thing I would like to see in the next draft of Annex H would be the refinement of the information flows and the messages used in the flows and at this point I would like to see what the reaction of the AHG members as well as anyone interested in the topic to the usage of H.225 Annex G protocol would be. The more I have refreshed my memory and knowledge about H.225 Annex G, the more I think that the protocol would be suitable for use in H.323 Annex H (some additions to the protocol would surely be needed). I'm planning on writing an MD contribution for the Mobility Management procedures using the actual H.225 Annex G protocol and if it seems after discussion on the contribution that people are in favor of using the protocol, I'll add this stuff in the next draft annex. So, at this point I would just like to see your overall comments about the usage of H.225 Annex G. ------------------------------------------------ Jaakko Sundquist * +358 50 3598281 * Audere est Facere! jaakko.sundquist(a)nokia.com * ------------------------------------------------ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

[H.323 Mobility:] Usage of H.225 Annex G in H.323 Annex H
by Jaakko Sundquist 25 Jul '00

25 Jul '00

Hi all, As the Mobility AHG members know, the idea of using the H.225 Annex G (Communication between Administrative Domains)protocol in H.323 Annex H has been brought up many times in the discussions. So far, we haven't, however, made any decision or even exhaustive proposals for its usage. Now, the next thing I would like to see in the next draft of Annex H would be the refinement of the information flows and the messages used in the flows and at this point I would like to see what the reaction of the AHG members as well as anyone interested in the topic to the usage of H.225 Annex G protocol would be. The more I have refreshed my memory and knowledge about H.225 Annex G, the more I think that the protocol would be suitable for use in H.323 Annex H (some additions to the protocol would surely be needed). I'm planning on writing an MD contribution for the Mobility Management procedures using the actual H.225 Annex G protocol and if it seems after discussion on the contribution that people are in favor of using the protocol, I'll add this stuff in the next draft annex. So, at this point I would just like to see your overall comments about the usage of H.225 Annex G. ------------------------------------------------ Jaakko Sundquist * +358 50 3598281 * Audere est Facere! jaakko.sundquist(a)nokia.com * ------------------------------------------------ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

Re: [H.323 Mobility:] Update to Service Definitions for Annex H - > a question
by Jaakko Sundquist 25 Jul '00

25 Jul '00

Hi all, For once, a really short and simple email... > I think that MD-102a is good one. It consists of 3 parts: > > 1. Use mobility > 2. Terminal mobility > 3. Service mobility (clip) > So, my proposal for the interest of the rapid standardization > effort is as > follows: > a. Phase 1: Items 1 and 2 > b. Phase 2: Item 3 > > I like to see other members also provide comments on this. This is exactly my feeling on how we should proceed with the work. Let's try to get the basic services stuff determined in this autumn (October, was it?) and decided next spring. After that we can continue with the supplementary services, etc. in the next version of Annex H. Otherwise, I'm afraid we have too much to do with regards to the decision next spring. -Jaakko ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

Re: Request for APC Numbers for Portland
by Sakae OKUBO 25 Jul '00

25 Jul '00

Dear Bob, In response to your request, APC numbers have been allocated to your contributions as follows: APC-1887 >H.450.12 - Common Information Additional Network Feature for H.323 > From Siemens AG APC-1888 >M.3 - Tunneling of DSS1 in H.323 > From Siemens AG Best regards, Sakae OKUBO *********************************************************** 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 (to be transferred) +81 3 3204 8194 (direct) Fax: +81 3 5287 7287 e-mail: okubo(a)giti.or.jp *********************************************************** ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

H.225-Annex G clarification
by Archana Nehru 24 Jul '00

24 Jul '00

hi everyone, I need a clarification on the following issue for H.225 -Annex G used for communication between two border elements(BE). I would appreciate any help on this. 1. In the current Annex G specfications, border elements exchange "usageIndication" messages with each other to inform each about "call usages" etc for billing purposes. The usage Indication message is sent according to a information element called "usageSpecifcation". This element is exchanged in messages like ACCESS_CONFIRM etc. The ASN syntax defined for this "usageSpecification" is: UsageSpecification::= sequence { sendTo ElementIdentifier .... } The "sendTo" field is supposed to identify the destination "border element" to which the "usage indication" messages for a call must be sent. The issue here is that "elementidentifier" is not defined as a "unique string", so the "sendTo" field by itself cannot identify the destination BE of the "usageIndication" message uniquely? In other words, to send a usage indication message, a BE needs to know the logical address of the "destination" BE. This logical address could then be resolved to a transport address which in turn is used to send "usageIndication" messages. So dont we need to add suitable fields to the "usageSpecification" field to identify the recipient of the "usageindication" message uniquely? If yes, then we should add a "domainId"(this defines the domain within which the BE resides) and also a "logical address" to the "usageSpecification" element. Do we agree that this is required? Regards Archana ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

Re: [H.323 Mobility:] Update to Service Definitions for Annex H - > a question
by Roy, Radhika R, ALCOO 24 Jul '00

24 Jul '00

Hi, Mark and Jaakko: I think that MD-102a is good one. It consists of 3 parts: 1. Use mobility 2. Terminal mobility 3. Service mobility The interesting thing is that services also overlap for items 1 and 2 indirectly. However, let me relate above items from the H.323 standard perspective. Item 3 as described in the contribution, it may fall into the category of H.323 supplementary services mobility, while items 1 and 2 will be H.323 (basic) call services. With respect to the "scope" of our present standardization effort of Annex H, the basic question is: How far do we want to go? The reason that I am saying so is that AT&T contribution D.353 provides another view of the services mobility. MD-102a (Siemens and Intel) also describes how many more items need to be addressed for the services mobility. You can easily imagine that the services mobility is one of the most important items that the service providers like to see happen in standard arena. So, my proposal for the interest of the rapid standardization effort is as follows: a. Phase 1: Items 1 and 2 b. Phase 2: Item 3 I like to see other members also provide comments on this. Best regards, Radhika R. Roy AT&T -----Original Message----- From: Jaakko Sundquist [mailto:jaakko.sundquist@nokia.com] Sent: Monday, July 24, 2000 4:14 AM To: ITU-SG16(a)MAILBAG.INTEL.COM Subject: Re: [H.323 Mobility:] Update to Service Definitions for Annex H - > a question Hi Marc et al, I just finished reading MD-102a and I have a couple of questions. First of all, though, I want to thank you guys for the excelent contribution, I really liked it. Actually I have just one thing that I don't quite understand. In section 5.1.2 you talk about the Authentication of a H.323 Mobile Terminal and say that it enables the verification of the authenticity of the terminal is context of the association it has with the Mobile User. You also explain this a bit further by adding that this is used to verify that the terminal can act on behalf of the authenticated User using it but you still state that the identity of the terminal is only relevant for the purposes of denying the usage of stolen terminals, etc. (black lists). So my question is that are you talking here about authenticating the terminal or are you referring to authenticating some sort of identifier that is used for the association between the terminal and the user? Your statement in item 3. about not needing to authenticate the user in subsequent terminal re-registrations would also seem to indicate the latter. Thus are you thinking of implementing a way to avoid the User authentication at least in Intra-zone location changes by introducing some sort of temporary local identifier for the terminal/user pair? I know that these are just requirements, but these statements seem to lead to that direction, if I have understood them correctly. The idea seems to be worth while to consider and we should discuss this further, but I don't quite see, how the terminal/user pair could really be authenticated, i.e. you can authenticate the User (by contacting the AuF) and you can authenticate the terminal (if proper cryptographic methods are specified also for the terminal), but how can you authenticate their association? Or am I just reading too much into this? Otherwise the contribution seems fine and I would suggest the addition of its contents to the draft Annex H. Let's have a bit of discussion before that, however. ------------------------------------------------ Jaakko Sundquist * +358 50 3598281 * Audere est Facere! jaakko.sundquist(a)nokia.com * ------------------------------------------------ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

APC-1878, 1883, 1886
by Terry L Anderson 24 Jul '00

24 Jul '00

I have uploaded APC-1878: Reference Points for the use of Annex G APC-1883: CPL: A Language for User Control of Internet Telephony Services (a copy of draft-ietf-iptel-cpl-01.txt for information) APC-1886: RFC-2824: Call Processing Language Framework and Requirements (a copy of RFC-2824 for information) to the incoming directory of the avc-site. -- ------------------------------------------------------------ Terry L Anderson mailto:tla@lucent.com Tel:908.582.7013 Fax:908.582.6729 Pager:800.759.8352 pin 1704572 1704572(a)skytel.com Lucent Technologies/ Voice Over IP Access Networks/ Applications Grp Rm 2B-121, 600 Mountain Av, Murray Hill, NJ 07974 http://its.lucent.com/~tla (Lucent internal) http://www.gti.net/tla

1 0

Re: [H.323 Mobility:] Update to Service Definitions for Annex H - > a question
by Jaakko Sundquist 24 Jul '00

24 Jul '00

Hi Marc et al, I just finished reading MD-102a and I have a couple of questions. First of all, though, I want to thank you guys for the excelent contribution, I really liked it. Actually I have just one thing that I don't quite understand. In section 5.1.2 you talk about the Authentication of a H.323 Mobile Terminal and say that it enables the verification of the authenticity of the terminal is context of the association it has with the Mobile User. You also explain this a bit further by adding that this is used to verify that the terminal can act on behalf of the authenticated User using it but you still state that the identity of the terminal is only relevant for the purposes of denying the usage of stolen terminals, etc. (black lists). So my question is that are you talking here about authenticating the terminal or are you referring to authenticating some sort of identifier that is used for the association between the terminal and the user? Your statement in item 3. about not needing to authenticate the user in subsequent terminal re-registrations would also seem to indicate the latter. Thus are you thinking of implementing a way to avoid the User authentication at least in Intra-zone location changes by introducing some sort of temporary local identifier for the terminal/user pair? I know that these are just requirements, but these statements seem to lead to that direction, if I have understood them correctly. The idea seems to be worth while to consider and we should discuss this further, but I don't quite see, how the terminal/user pair could really be authenticated, i.e. you can authenticate the User (by contacting the AuF) and you can authenticate the terminal (if proper cryptographic methods are specified also for the terminal), but how can you authenticate their association? Or am I just reading too much into this? Otherwise the contribution seems fine and I would suggest the addition of its contents to the draft Annex H. Let's have a bit of discussion before that, however. ------------------------------------------------ Jaakko Sundquist * +358 50 3598281 * Audere est Facere! jaakko.sundquist(a)nokia.com * ------------------------------------------------ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0