- sg16-avd - lists.packetizer.com

Re: Questions on H.235
by Douglas Clowes 16 Sep '99

16 Sep '99

At 12:28 1999-09-16 +0200, Euchner Martin wrote: >The generalID of the GK could be configured in the endpoint or could be made available by some other means out of band. >In the next version of H.235 (i.e. H.235v2) the ClearToken will feature both the source and the destination identifiers. Then, the EP will learn the generalID of the GK. The crucial point is still the initial GRQ which either comes with some reduced security when not including the GK-ID or with increased security but also increased complexity when the EP has to know the GK-ID by some other means a priori. > >The basis for the H.235 security protocols are ISO/IEC 11770-3 (7.2) and ISO/IEC 9798-2 (5.1.2) / 9798-4 (5.1.1). These security protocols always carry the destination address/identification in their message in order to counter reflection attacks (a special variant of a replay attack). Thus, the generalID_A in the phase I reply message is correct. By this logic, and pre-knowledge of generalID_b, message 1 of phase 1 should contain generalID_b in the CryptoToken. This not only counters reflection (replay against the same receiver) but the more general case of replay against a different receiver. The ClearToken on the other hand, could contain the identifier of the sender, so that the receiver can identify the correct cryptographic material to use to verify the signature in the CryptoToken (unless that information appears elsewhere in the message). It is a good idea to include both identifiers in the ClearToken within the signed CryptoToken. Have I missed the H.235v2 draft somewhere? Are there APCs addressing this (and other) change(es), or are you alluding to future APCs? While I have a number of security/cryptography texts on my bookshelf, the referenced ISO/IEC ones are not among them. I only have the ITU-T and joint ISO-ITU-T (X-series) ones. >2. Man-in-the-middle attacks: The security protocol shown in Fig.1/H.235 is secure against man-in-the-middle attacks as long as the Diffie-Hellman tokens are signed with the private key or are authenticated by a cryptographic MAC. The security protocol is secure even when an attacker intercepts parts or the entire message. Basically, this is stated by the Diffie-Hellman and discrete logarithm assumptions that someone cannot break the crypto system by having access to all messages exchanged on the wire. Thus, no threat arises by snooping these parameters. >The Timestamp within the ClearToken is included in order for the recipient to verify the CryptoToken. I think that it is open to replay against another receiver, at least for denial of service, while the timestamp is fresh. The receiver needs to create state and an eavesdropper could replay the message against all other gatekeepers in the domain. If the initial (unicast) GRQ is unsuccessful and the real gateway issues a new GRQ (with possibly same or different DH conmonent) to such a gatekeeper that is waiting for phase 2, what will it do? Changing the generalID in the CryptoToken of message 1 to that of EPB will stop that. >3. Please note, that the Diffie-Hellman procedure appears twice in H.235 in different contexts: The first usage of Diffie-Hellman key exchange is during RAS (as shown in Fig1/H235) where the agreed DH-secret is to encrypt the XORed sequence number (see B.4.2 of H.235) It is used in message 3 of Figure 1 also, which is what I think is being described in B.4.2. I don't like the mechanism described in B.4.2 for the folowing reasons. Firstly, requiring the transmission of the ciphertext of specified cleartext opens up to the known cleartext attack. If the contents are known by both parties, then a keyed hash makes more sense. Secondly, it relies on the success of a previous exchange. If the latest random_b were returned in an ACF which was not delivered, then all subsequent messages (including the retransmission of the ARQ) would fail authentication. It would be better to send a new timestamp_a and random_a with each request, and the keyed HMAC (e.g. HMAC-SHA1-96) of that with the DH_secret (and gatekeeperID if you like, but I don't think it adds anything). My personal favorite is to include a ClearToken in the message, which contains the timestamp of the sender, possibly a random number or sequence, and HMAC the entire message with the shared secret. The HMAC can go in the icv (for those messages that have it - H.225.0 RAS and Annex G). The preferred solution, more widely applicable, is to place the HMAC in a CryptoToken with an OID for the purpose (as in H.225.0 Annex J). >Another use of the Diffie-Hellman key agreement scheme is applied during call signaling. Here, the entities involved agree to a common shared secret (i.e. the DH-key) from which a key encryption key (master key) is derived. This master key is used by the H.323 master in order to securely transmit and update the media encryption key. Note that these methods appear to provide protection for RAS messages and media, but not for call signalling, where the parties to communication have had no prior contact, unless a certificate based public key system is used. Regards, Douglas

1 0

endpointAlias field in URQ
by Sunil Chandra 16 Sep '99

16 Sep '99

Hi, In the explaination of endpointAlias field in URQ message (Section 7.10.1 of H.225.0), it is said that if the E.164 address is assigned, it should be mentioned. Why this is mandatory for E.164 address? Why it is mandatory for E.164 addresses only? With regards, Sunil

1 0

Regarding alternate endpoint
by Sunil Chandra 16 Sep '99

16 Sep '99

Hi Glen, I have few questions related to alternate endpoint info sent in RAS messages. 1. What is the semantic of use of Alternate endpoint info? As it is mentioned in section 7.2.2 of H.323, "an endpoint may indicate a backup, redundant or alternate transport address using the *alternateEndpoint* structure within the RAS messages. This allows an endpoint to have a secondary network interface or a secondary H.323 endpoint as a backup". But, when a list of call signalling addresses, ras addresses and aliases can be specified without even specifying alternate endpoint, what is the requirement of alternateEndpoint field? 2. What is the significance of remoteExtensionAddress and destExtensionCallInfo fields in endpoint sequence? Why these fields are not in the core RRQ message and are part of alternateEndpoints? With regards, Sunil

1 0

FW: Issues with H.235
by Euchner Martin 16 Sep '99

16 Sep '99

Pete, Bancroft, Pekka and others, now as I'm back from my long vacation I want to throw in my bits to this discussion. (By the way, I will try to answer or comment all the other pending emails which have been sent to me). 1.) RandomVal/INTEGER: It is true that H.235 has defined this as an arbitrary long integer for some reason which I can't remember. I've heard also that there are implementations that can only process 32-bit integers. H.323 Annex J uses RandomVal only as an increasing sequence number/counter. Thus, Annex J does not really require RandomVal as an arbitrary long integer; a 32-bit integer would be sufficient for that purpose while still guaranteeing sufficient security. H.235 Version 2 could restrict the scope of the RandomVal Integer to 32 bits; if this is considered useful and we can all agree to this. Please let me hear your opinions on this. 2.) nonStandardParameter: I can only guess why H.235 has chosen a simpler definition than H.225.0: Apparently, H.235 does not need the H.221 non-standard support; this was considered not necessary. Thus h221NonStandard was left out in the structure leaving the Object identifier. I hope that this simplification does not cause real implementation difficulties. 3.) I do not quite understand why you consider object identifiers limited? In my opinion, the concept of object identifiers is quite flexible and targeted for interoperability. H.323 Annex J section 8 shows a proposal for the various object identifiers used. Regards, Martin. ----------------------------------------------------------------------- | Dipl.-Inf. Phone: +49 89 636-46201 | Martin Euchner Fax : +49 89 636-48000 | Siemens AG | ZT IK 3 mailto:Martin.Euchner@mchp.siemens.de <mailto:Martin.Euchner@mchp.siemens.de> | Intranet: http://zt-security.mchp.siemens.de/Standardization/ITU-T_SG16/index.html <http://zt-security.mchp.siemens.de/Standardization/ITU-T_SG16/index.html> | Otto-Hahn-Ring 6 Internet: http://www.siemens.de <http://www.siemens.de> | D-81730 Muenchen | __________________ | Germany ----------------------------------------------------------------------- -----Original Message----- From: Pete Cordell [SMTP:pete@TECH-KNOW-WARE.COM] <mailto:[SMTP:pete@TECH-KNOW-WARE.COM]> Sent: Wednesday, September 08, 1999 9:26 AM To: ITU-SG16(a)mailbag.cps.intel.com <mailto:ITU-SG16@mailbag.cps.intel.com> Subject: Issues with H.235 Dear All, I'm implementing some of the H.235 stuff and have a few concerns. RandomVal is defined as INTEGER only. This is not a particularly helpful definition as in theory this could be a million bit + integer if needed. Not many computers support such types! In fact, a well known ASN.1 compiler maps this to an int which is a signed 32-bit value on our platform. Is this sufficient? Without further discussion about the range of this value I feel there is a potential for interoperability problems. Perhaps we can say that RandomVal will never be more than 32 bits long, and then add a type like RandomSeq as an OCTET STRING for cases when we need a longer random value. There are also a few other issues, for example: nonStandardParameter in H.235 is defined differently to that in H.225. Why is that? Similarly tokenID only takes an OID. Again, why such a limited format? Regards, Pete ============================================= Pete Cordell pete(a)tech-know-ware.com <mailto:pete@tech-know-ware.com> =============================================

1 0

Re: Questions on H.235
by Euchner Martin 16 Sep '99

16 Sep '99

Aseem, Douglas, and others, while I was on my long vacation, I received this message through the reflector. Let me try to answer and comment as follows: 1. Please note, that there is an error in Aseems figure: The reply message in phase I from the GK to the EP should have Time_B instead of Time_A in the ClearToken. The generalID of the GK could be configured in the endpoint or could be made available by some other means out of band. In the next version of H.235 (i.e. H.235v2) the ClearToken will feature both the source and the destination identifiers. Then, the EP will learn the generalID of the GK. The crucial point is still the initial GRQ which either comes with some reduced security when not including the GK-ID or with increased security but also increased complexity when the EP has to know the GK-ID by some other means a priori. The basis for the H.235 security protocols are ISO/IEC 11770-3 (7.2) and ISO/IEC 9798-2 (5.1.2) / 9798-4 (5.1.1). These security protocols always carry the destination address/identification in their message in order to counter reflection attacks (a special variant of a replay attack). Thus, the generalID_A in the phase I reply message is correct. 2. Man-in-the-middle attacks: The security protocol shown in Fig.1/H.235 is secure against man-in-the-middle attacks as long as the Diffie-Hellman tokens are signed with the private key or are authenticated by a cryptographic MAC. The security protocol is secure even when an attacker intercepts parts or the entire message. Basically, this is stated by the Diffie-Hellman and discrete logarithm assumptions that someone cannot break the crypto system by having access to all messages exchanged on the wire. Thus, no threat arises by snooping these parameters. The Timestamp within the ClearToken is included in order for the recipient to verify the CryptoToken. 3. Please note, that the Diffie-Hellman procedure appears twice in H.235 in different contexts: The first usage of Diffie-Hellman key exchange is during RAS (as shown in Fig1/H235) where the agreed DH-secret is to encrypt the XORed sequence number (see B.4.2 of H.235) Another use of the Diffie-Hellman key agreement scheme is applied during call signaling. Here, the entities involved agree to a common shared secret (i.e. the DH-key) from which a key encryption key (master key) is derived. This master key is used by the H.323 master in order to securely transmit and update the media encryption key. Regards, Martin. ----------------------------------------------------------------------- | Dipl.-Inf. Phone: +49 89 636-46201 | Martin Euchner Fax : +49 89 636-48000 | Siemens AG | ZT IK 3 mailto:Martin.Euchner@mchp.siemens.de | Intranet: http://zt-security.mchp.siemens.de/Standardization/ITU-T_SG16/index.html | Otto-Hahn-Ring 6 Internet: http://www.siemens.de | D-81730 Muenchen | __________________ | Germany ----------------------------------------------------------------------- -----Original Message----- From: Aseem Agarwal [SMTP:aseem@TRILLIUM.COM] Sent: Wednesday, September 08, 1999 8:51 PM To: ITU-SG16(a)mailbag.cps.intel.com Subject: Questions on H.235 Hi i have the following questions about H.235 procedures: The Diffie Hellman exchange as depicted in Fig 1/H.235 is as follows: EP GK ClrTkn(Dh_a, Time_a) CryptoTkn[(genId_a, time_a,Dh_a)Sign_a] ----------------------------------------------------------------------> ClrTkn(Dh_b, Random_b, Time_a) CryptoTkn[{genId_a,Time_b,Dh_b}Sign_b] ------- <----------------------------------------------------------------------- _____________________________________________________________________________ ClrTkn[{(genId_b XOR Random_b XOR (x)}EHD-secret)] ------- ----------------------------------------------------------------------> ClrTkn[ (genId_a, Random_b) ] <----------------------------------------------------------------------- 1.In the phase II procedure above, how does the EP know about genId_b ? I feel that the genId in cryptoToken in phase I message from GK to EP (second line in the diagram) should have genId_b and not genId_a. Is my understanding correct ? 2.As applied to RAS protocol in H.323 context, for a non subscription based authentication case: Dh_a and Dh_b have public keys for EP and Gk respectively. (x) is requestSeqNum. genId_b has gkId in GCF. What does genId_a have in GRQ ? The above exchange is NOT immune to man-in-the-middle attacks. A third party can easily snoop in and find out Dh_a, Dh_b, GkId and IntegrityMechanism algorithms as these are passed un-ecrypted in GRQ-GCF exchange. How is this authentication procedure any different from just passing a GK assigned dynamic identifier (e.g. EndPointId) in all messages to the GK ?? How is this procedure affected if the EP knows Gk's id apriori (through provisioning or out of band methods as in manual discovery)? 3. H.235 also mentions that this procedures may be used on the call signalling channel as well. The scope of the Key generated as a result of this procedure is not clearly specified. Is this key used for encryption on the call control channel or is it valid only for call signalling channel ? Any pointers would be appreciated. thanks, aseem(a)trillium.com

1 0

RTCP sender reports - when to use?
by henri.maenpaa＠NOKIA.COM 16 Sep '99

16 Sep '99

Hi, Could somebody clarify a few things for me... Say, there's a call between A and B in H.323. RTP sessions for both stream directions are totally independent of each other, right? (except with T.120 channel a bidirectional one can be used). Let's concentrate on RTP session where stream goes from A to B. This one RTP session is a unidirectional channel. Is the related RTCP channel also a unidirectional channel, but to opposite direction? So, if this is true, how can we use sender reports (SR) in H.323? Am I right when I assume that only way sender reports can be used in H.323 is with a T.120 bidirectional channel (when RTCP channel would probably be bidirectional also)? Cheers, Henri

1 0

H.450 support
by Alex Chatilov 16 Sep '99

16 Sep '99

Hello, I have a question about how to detect does remote endpoint supports H.450 (without using a timer)? Is it clear that receiving endpoint has to replay with a STATUS message in case when it receive an H.450 related FACILITY message? Assume that we have: Originator side sent: -------------------- FACILITY FacilityIE (length=0) ... User-UserIE H323-UserInformation h323-UU-PDU h323-message-body = empty ... h4501SupplementaryService (H.450.x request) ... ... ... Remote side received FACILITY, here is no support for H.450, so we will respond with STATUS message where the causeIE = 100 (invalid IE contents), or 99 (Information element/parameter non-existent or not implemented), or 97 (Message type non-existent or not implemented) STATUS ... CauseIE ... cause = XX diagnostics = YY ... Am I right? Thank you, Alex

1 0

FW: MegacoH248v10 is available
by Nancy-M Greene 15 Sep '99

15 Sep '99

FYI. This is the latest version of the Megaco/H.248 document. In many areas it expands on points made in Berlin. Discussion of this draft is ongoing on the megaco(a)standards.nortelnetworks.com mailing list, and comments are welcome at any time. To see the archive of mail messages, go to http://standards.nortelnetworks.com and follow the links to the Megaco archive. Nancy -------------------------------------------------------------------------- Nancy M. Greene Internet & Service Provider Networks, Nortel Networks T:514-271-7221 (internal:ESN853-1077) E:ngreene@nortelnetworks.com > ---------- > From: Brian Rosen[SMTP:brosen@ENG.FORE.COM] > Sent: Tuesday, September 14, 1999 6:00 PM > To: megaco(a)standards.nortelnetworks.com > Subject: MegacoHGCP10 is available > > We have released a new version of the MEGACO/H.248 protocol > document. > > The pdf can now be found at: > ftp://standards.nortelnetworks.com/megaco/docs/latest/megaco-h248_protocol > .p > df > > This link will always be maintained "current" to the latest > version that we release as an IETF draft, so you could > "bookmark" this one. > > The following two links provide this version in .doc and .pdf forms: > > ftp://standards.nortelnetworks.com/megaco/docs/wash99/megacoH248v10.pdf > ftp://standards.nortelnetworks.com/megaco/docs/wash99/megacoH248v10.doc > > There WILL be an I-D of this version, as draft-ietf-megaco-protocol-04.txt > > This will be a full text version of the document, not a pointer to the pdf > file. It will take a few days to prepare this version, so don't look for > it > on the IETF I-D sites yet. > > I apologize for the delay in getting this out; we had good intentions, but > lots of issues to deal with. > > Comments and suggestions are, as always, welcome. > > Brian > ------------ > Brian Rosen, Principal Engineer > FORE Systems, 1000 FORE Drive, Warrendale, PA 15086 > (724) 742-6826 mailto:brosen@eng.fore.com >

1 0

Re: Issues with H.235
by Euchner Martin 15 Sep '99

15 Sep '99

Pete, Bancroft, Pekka and others, now as I'm back from my long vacation I want to throw in my bits to this discussion. (By the way, I will try to answer or comment all the other pending emails which have been sent to me). 1.) RandomVal/INTEGER: It is true that H.235 has defined this as an arbitrary long integer for some reason which I can't remember. I've heard also that there are implementations that can only process 32-bit integers. H.323 Annex J uses RandomVal only as an increasing sequence number/counter. Thus, Annex J does not really require RandomVal as an arbitrary long integer; a 32-bit integer would be sufficient for that purpose while still guaranteeing sufficient security. H.235 Version 2 could restrict the scope of the RandomVal Integer to 32 bits; if this is considered useful and we can all agree to this. Please let me hear your opinions on this. 2.) nonStandardParameter: I can only guess why H.235 has chosen a simpler definition than H.225.0: Apparently, H.235 does not need the H.221 non-standard support; this was considered not necessary. Thus h221NonStandard was left out in the structure leaving the Object identifier. I hope that this simplification does not cause real implementation difficulties. 3.) I do not quite understand why you consider object identifiers limited? In my opinion, the concept of object identifiers is quite flexible and targeted for interoperability. H.323 Annex J section 8 shows a proposal for the various object identifiers used. Regards, Martin. ----------------------------------------------------------------------- | Dipl.-Inf. Phone: +49 89 636-46201 | Martin Euchner Fax : +49 89 636-48000 | Siemens AG | ZT IK 3 mailto:Martin.Euchner@mchp.siemens.de | Intranet: http://zt-security.mchp.siemens.de/Standardization/ITU-T_SG16/index.html | Otto-Hahn-Ring 6 Internet: http://www.siemens.de | D-81730 Muenchen | __________________ | Germany ----------------------------------------------------------------------- -----Original Message----- From: Pete Cordell [SMTP:pete@TECH-KNOW-WARE.COM] Sent: Wednesday, September 08, 1999 9:26 AM To: ITU-SG16(a)mailbag.cps.intel.com Subject: Issues with H.235 Dear All, I'm implementing some of the H.235 stuff and have a few concerns. RandomVal is defined as INTEGER only. This is not a particularly helpful definition as in theory this could be a million bit + integer if needed. Not many computers support such types! In fact, a well known ASN.1 compiler maps this to an int which is a signed 32-bit value on our platform. Is this sufficient? Without further discussion about the range of this value I feel there is a potential for interoperability problems. Perhaps we can say that RandomVal will never be more than 32 bits long, and then add a type like RandomSeq as an OCTET STRING for cases when we need a longer random value. There are also a few other issues, for example: nonStandardParameter in H.235 is defined differently to that in H.225. Why is that? Similarly tokenID only takes an OID. Again, why such a limited format? Regards, Pete ============================================= Pete Cordell pete(a)tech-know-ware.com =============================================

1 0

Re: [Fwd: Re: [Fwd: [Fwd: [Fwd: Re: H.323 mobility first draft]]]]
by Edgar Martinez [1] 15 Sep '99

15 Sep '99

Hi Roy, Just to take this off-line for the moment, but only for clarification. If we support a H.323 wireless handset in a pure H.323 environment. Where do you see the AIR interface access to the H.323 network? In the context of a pure IP mobile network without interworking. What I mean is do we only provide a BTS access to the network run all the radio traffic through the network. Or do we provide something like a RAN (WAU) to handle the radio traffic on the edges?. The radio traffic that I been mentioning is not directly related to H.323 call setup that is Mobile Terminal paging and all radio channel management functions. But, whether we use a BTS or WAU for wireless access to the IP network will greatly influence the way we do handovers in a pure IP network. This does not affect roaming. One suggestion you provided on handover was using the MCU, I could work with that. But something like the WAU can provide the MCU function in the edges between H.323 (MT to MT), or MT to PC. Since the only device that requires handover is the wireless Mobile Terminal (MT). Best Regards, Ed "Roy, Radhika R, ALARC" wrote: > Hi Ed: > > I understand your approach. Your approach is an INTERWORKING between the > H.323 and PSTN-Wireless networking environment. > > First, we need to solve all mobility problems in the H.323 layer. Once we > solve H.323 mobility problems in a transport independent way, we can then > implement that solution in a special "INTERWORKING" environment: H.323 > system (e.g., IP network) with an interface (e.g., WAU) to the PSTN-wireless > system. > > There are two steps: 1. Solve the mobility problems in H.323 layer > (Terminal, User, and Service Mobility) and 2. Implement the H.323 mobility > problems in specific networking environments for "Interworking". > > The H.323 mobility problems solved in the H.323 layer should be applicable > for all circumstances. For example, > > 1. Mobile IP (IETF) > 2. PSTN-wireless (PLMN) > 3. Emerging mobile and wireless networks > > That is, the general H.323 mobility solution will also complement the > solution that you are proposing. There may be some differences in approach > that you are proposing, but it (H.323 mobility) will achieve the same > objectives what your contribution is up to. In fact, I welcome your > contribution because it has provided us valuable insights of the mobility > problems in the context of H.323 and PSTN-Wireless networking environment. > > Best regards, > Radhika > > > -----Original Message----- > > From: Edgar Martinez [1] [SMTP:martinze@CIG.MOT.COM] > > Sent: Tuesday, September 14, 1999 9:21 PM > > To: ITU-SG16(a)MAILBAG.INTEL.COM > > Subject: Re: [Fwd: Re: [Fwd: [Fwd: [Fwd: Re: H.323 mobility first > > darft]]]] > > > > Thank you all for your comments. > > > > Roelands Marc wrote: > > > > > Hi all, > > > > > > I am struggling with some conceptual problems concerning the Annex-H > > > proposal of Edgar Martinez, feeling that this has some commonality with > > the > > > remarks of Roberto Winkler and Simon Binar on it. IMHO, the proposed > > > architecture, and especially the WAU and the GK, are mixing all kinds of > > > mobility related functionality in a single, strongly coupled, > > > do-it-all-in-H.323 layer, involving radio access up to H.323 application > > > layer. > > > > I believe there is a clear separation of functional requirements between > > the > > radio control > > functions of the WAU, and the Network control and Mobility Management > > functions > > in the GK. Would it make everyone happy if we called WAU RAN? For network > > efficiency > > the WAU would handle all the Radio link resources at the edges, thereby > > preventing > > traffic overloading on the network. > > > > > > > > > > > Specifically, I have some difficulties with the following: > > > > > > 1. No clear division in terminal and user mobility aspects in the basic > > > H.323 architecture is taken as a starting point: shouldn't there be > > > specified somewhere in general, in conjunction with the H.323 set of > > > protocols, that IP addresses represent terminals in an IP network, and > > that > > > users can only be represented by logical names from a directory (i.e. > > > aliases), and whether an "endpoint" is a user or a terminal? If this is > > > decided on, the H.323 registration procedure is just what is needed to > > have > > > user mobility, by dynamically associating a logical user name with one > > or > > > multiple terminals upon user request. With terminals identified by IP > > > addresses, terminal mobility would further be strictly a network access > > > problem. > > > > > > 2. Annex-H is supposed to handle user and service mobility, so why would > > the > > > handover problem, as any other terminal mobility related problem, be > > handled > > > here instead of independently in Annex-I? > > > > In the second day of the Ad-hoc SG-16 meeting, some of us discussed, > > the possibility of combining Annex H and I, if no contributions came > > in for Annex-I. > > > > > > > > > > > > > 3. Mobility is not an issue in H.323 alone, e.g. consider roaming and > > > handover for a connection-oriented data application, so why should it be > > > handled in H.323 on its own? Or put otherwise, is H.323 support really > > > required on a terminal in order to be able to roam, as a user of some > > > service, or as a terminal accessing a network? > > > > I specifically asked where do we focus, and was told to assume that > > there will be H.323 wireless sets. And focus only on H.323 terminals, > > to get the work started. And that other types of terminals would > > be handled separately. > > > > > > > > > > > 4. Although the proposal pays attention to the identification of several > > > degrees of locality for roaming and handover, solving all control issues > > > (radio access, IP-networking, etc.) in a single application layer still > > > leads to both resource sub-optimality and complexity. E.g. why should > > the > > > WAU be aware of anything having to do with (user) mobility management? > > > > I believe there is a misunderstanding the mobility management > > and services is handle by in the network e.g, GK. > > The Radio Resource management is at the edges which is aware > > of the terminals radio links. > > > > > > > > > > > Instead I would propose to use an approach of highly independent layers, > > > following good Internet tradition, and solving the problems as locally > > as > > > possible (both geographically and architecturally). Here's the layers I > > > think at least should be distinguished: > > > > > > - MAC level: terminal micro-mobility across radio cells, ethernet > > segments, > > > etc. can exist without any consciousness of this at the IP level (e.g. > > using > > > wireless LAN tunneling techniques); > > > > > > - IP network level: terminal macro-mobility across the Internet should > > be > > > invisible to higher layers (e.g. by means of Mobile IP v4 or v6 and the > > > improvements suggested for delay-sensitive traffic like RTP streams: > > Mobile > > > IP HAWAII, or draft-elmalki-mobileip-fast-handoffs-01 to name but a few; > > > note that route optimization is also worked on in this area); > > > > > > - "terminal real-time signaling" application level: the level where > > > telephony and MM signaling like H.323 can be placed (restricting GW and > > GK > > > functionality to strictly this level); here Annex-H might define > > transport > > > for additional parameters and vertical signaling, useful for serving the > > > "user services" application level (below); at this lowest application > > level > > > packet to circuit switched network boundaries may be crossed (cf. the > > > evolving traditional telephony networks vs. the Internet); > > > > > > - "user services" application level: user and service mobility takes > > place > > > here, making use of a network- (and H.323) independent naming system > > > (directories using e.g. DNS, LDAP schemas, etc.) and e.g. back-end > > services, > > > "behind" or "on top of" one or several GKs for realizing UM, user > > mobility > > > support for a larger scope than just H.323, smart user assistance, etc.. > > > > > > This approach has not only the general advantage that every layer can > > evolve > > > technically independent of all others, it also has the specific > > advantage > > > that it realizes true consolidation of mobility for telephony and > > > traditional data applications. > > > > > > As a last point, it is not clear to me at which of these levels H.450 > > would > > > belong. As it is specified now it is on top of H.323, but suppose one > > would > > > like to adopt a service provision model where a user could subscribe to > > a > > > telephony-related service , wouldn't it be nice then to be able to offer > > > this across different telephony technologies (a bit like where IN aims > > at)? > > > A comparison to using a HTTP service control layer (Annex-K) might be > > > interesting here. > > > > > > I cannot imagine that these fundamental issues where not previously > > > discussed in ITU-T SG16 or Tiphon WG7, so if anyone can give me some > > > arguments why an approach as I tried to describe here could not be > > followed, > > > I would be glad to know about it. > > > > Your comments are very good and your suggestions are very applicable to > > what we are working on, but unless a contribution is presented to the > > proper > > groups e.g., ITS-sg16 q13/14 they would just fade away. ITU > > recommendations > > are contribution driven. > > > > Best Reagrds, > > Ed > > > > > > > > > > > Regards, > > > Marc Roelands > > > Siemens ICN Atea > > > Atealaan 34 > > > B-2200 Herentals > > > Belgium > > > Tel.: +32 14253965 > > > Fax: +32 14222994 > > > E-mail: marc.roelands(a)siemens.atea.be > > > > > > -----Original Message----- > > > From: Roberto Winkler [mailto:wnk@FUB.IT] > > > Sent: Tuesday, September 14, 1999 10:34 AM > > > To: TIPHON_WG7(a)LIST.ETSI.FR > > > Subject: Re: [Fwd: Re: [Fwd: [Fwd: [Fwd: Re: H.323 mobility first > > > darft]]]] > > > > > > Jin, Edgar, > > > > > > If I may try to give my 2 cents in this discussion, I think that the > > > problems/weakness of 3GPP considered systems (which Edgar is speaking > > > about) cannot match with the faults identified by Lucent's contribution, > > > which is focused on the unique issue of R99 terminal support in the All > > IP > > > R00 network. Considering these 3GPP contributions does not help in > > > understanding Edgar's point of view. > > > I have already sent a few e-mails to comment the proposed mobile H.323 > > > architecture and would like to summarize here my view, hoping to get > > > reactions: > > > - the role and reason for being of WAU is unclear (as TIPHON is focused > > on > > > user and service mobility, why worry about the access medium ?) > > > - the redefinition of several RAS channel messages is confusing (why > > does > > > the RAS channel terminates at WAU ?) > > > - protocol stacks and interface definitions are missing from the > > picture. > > > > > > best regards > > > > -- > > Edgar Martinez - Principal Staff Engineer > > Email mailto:martinze@cig.mot.com > > FAX 1-847-632-3145 - - Voice 1-847-632-5278 > > 1501 West Shure Drive, Arlington Hgts. IL 60004 > > Public: TIPHON & Other Stds - http://people.itu.int/~emartine/ > > Private:TIPHON & Other Stds - http://www.cig.mot.com/~martinze/ -- Edgar Martinez - Principal Staff Engineer Email mailto:martinze@cig.mot.com FAX 1-847-632-3145 - - Voice 1-847-632-5278 1501 West Shure Drive, Arlington Hgts. IL 60004 Public: TIPHON & Other Stds - http://people.itu.int/~emartine/ Private:TIPHON & Other Stds - http://www.cig.mot.com/~martinze/

1 0