- sg16-avd - lists.packetizer.com

[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 24 Jul '00

24 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

Re: [Fwd: CPL/323]
by Sakae OKUBO 21 Jul '00

21 Jul '00

Dear Mr. Anderson, >Couyld you give me another APC number for the second CPL document: > >Title: "RFC-2824: Call Processing Language Framework and Requirements" APC-1886 has been allocated to this document. 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

Comments on H.225.0 v4 Whitedraft (sourceAddress)
by Klaghofer Karl ICN EN HC SE 81 20 Jul '00

20 Jul '00

One more try, since it seems that my previous mail I sent out yesterday did not arrive. Regards, Karl Klaghofer > -----Ursprüngliche Nachricht----- > Von: Klaghofer Karl ICN EN HC SE 81 > Gesendet am: Tuesday, July 18, 2000 12:02 > An: 'ITU-SG16(a)mailbag.cps.intel.com' > Betreff: Comments on H.225.0 v4 Whitedraft (sourceAddress) > > Rich and others, > > H.225.0v4 White draft, section 7.3.10 Setup reads: > "... > sourceAddress - Contains the alias addresses for the source; the dialed > digit string of the source is in the Q.931 Calling Party Number IE. The > primary address shall be first. > ..." > > PROPOSED TO BE CORRECTED TO: > "... > sourceAddress - Contains the alias addresses of the source. Note that the > E.164 Number of the source is contained within Calling Party Number > Information Element. The primary address shall be first. > ..." > > Background: > As part of the global v4 change to replace the term "e164" by the term > "dialedDigits" in the whole H.225.0 document, the sentense in current v4 > Whitedraft does not make sense anymore and should be corrected in v4 in > Portland. I think what we wanted to say is that the E.164 number is > contained within the Calling Party Number IE and not the dialed digit > string ! Dialed digit string (unstructured number which maybe may include > prefixes, etc would be put into sourceAddress.dialedDigits). > Note: There might be further sections where the simple replacement of the > term e164 by term dialed digits may have caused vagueness, since term e164 > in v2 was actually used for both - real E.164 but also unstructured digit > strings. > > Regards, > Karl Klaghofer > ------------------------------------------------------- > Karl Klaghofer, Siemens AG > Dpmt ICN EN HC D81, VoIP Architecture & Standardization > Hofmannstr. 51, 81359 Munich, Germany > Tel.: +49 89 722 31488; Fax.: +49 89 722 37629 > Mail: karl.klaghofer(a)icn.siemens.de > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

2 1

SIP-H.323 Interworking Draft
by Roy, Radhika R, ALCOO 20 Jul '00

20 Jul '00

Hi, Everyone: We are now pleased to inform that the "SIP-H.323 Interworking Requirements" Internet-Draft has been completed. You can find the draft as follows: Title : SIP-H.323 Interworking Requirements Author(s) : H. Agrawal, R. R. Roy, V. Palawat, A. Johnston, C. Agboh, K. Singh, and H. Schulzrinne Filename : draft-agrawal-sip-h323-interworking-reqs-00.txt Pages : 19 Date : 12-Jul-00 Abstract: "This document describes the requirements for the logical entity known as the interworking function (IWF) that will allow the interworking between the SIP(Session Initiation Protocol) and H.323 networks." This draft is expected to be presented in the 48th IETF meeting in Pittsburgh, USA (July 31 - August 4, 2000) and may become an Informational RFC if no future comments are received. The next step is to produce the "SIP-H.323 Interworking" draft for producing an IETF RFC based on this requirement draft. Best regards, Radhika R. Roy AT&T

1 0