- sg16-avd - lists.packetizer.com

Re: RTCP sender reports - when to use?
by Orit Levin 17 Sep '99

17 Sep '99

Hi Henri! The answer is ... the RTCP channel is bi-directional even when opened to be used for A->B RTP media stream only. If A wants to send a stream going A->B, A originates the OLC procedure. During this procedure B's RTP port, B's RTCP port and A's RTCP ports are exchanged between the sides. For the same "kind" of media stream (such as "voice" or "video) usually B would like to send a media stream going A<-B belonging to the same H.245 session opened above. In this case B will issue OLC advertising the same B's RTCP port already used within this session. As the result, two media unidirectional RTP channels and a single common bi-directional RTCP channel will be opened within the same H.245 session. Best Regards, Orit Levin RADVision Inc. 575 Corporate Drive Suite 420 Mahwah, NJ 07430 Tel: 1 201 529 4300 (230) Fax: 1 201 529 3516 www.radvision.com orit(a)radvision.com -----Original Message----- From: henri.maenpaa(a)NOKIA.COM <henri.maenpaa(a)NOKIA.COM> To: ITU-SG16(a)MAILBAG.INTEL.COM <ITU-SG16(a)MAILBAG.INTEL.COM> Date: Thursday, September 16, 1999 5:05 AM Subject: RTCP sender reports - when to use? >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 >

2 1

Re: H.235 Control Channel
by Euchner Martin 17 Sep '99

17 Sep '99

Anseem, the secure logical channel does not have its own data type. It is merely an abstract notion telling that the OLC operates in a certain mode. It is flagged by KeyProtectionMethod.secureChannel. The security logical channel is a separate security connection parallel to the unprotected OLC; e.g., TLS, SSL,... The security logical channel is used to establish authentication and exchange key material. This key material is used by the master then as a key encryption key for secure transmission of the media key (within the OLC). I'm currently preparing an updated version of H.235v2, that will be presented at the upcoming Rapporteurs meeting in October. 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: Friday, September 17, 1999 2:54 AM To: ITU-SG16(a)mailbag.cps.intel.com Subject: H.235 Control Channel Hi All H.235 specifies opening up a secure logical channel. In this mode of operation the regular H.245 control channel may operate in unsecured mode. I have the following doubts about this procedure: 1. What is the "DataType" value used in the OpenLogicalChannel message exchanged for the secure channel ? Section 8.2 specifies that "encryptionData" may be used, but elsewhere in the document the channel is referred with the value "h235Control" which is yet another value for dataType. 2. How does the exchange of encryption related information happen on the secure logical channel ? Does this happen in the data plane ? OR this new logical channel serves as a new control channel and the key exchange happens using EncryptionUpdate messages ? H.235 does not clearly specify the sematics/functionality of this logical channel. IMHO, many loose ends have been left behind which may result in different implementations. Comments/feedback welcome. Also, please let me know when we can expect the updated/next version of H.235 document. Regards, aseem(a)trillium.com

1 0

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

17 Sep '99

Douglas, as I pointed out in a former email, I'm adding the source identifier to the ClearToken in H.235v2. As you said this will improve the security. On the other hand however, there is a specific problem using the destination identifier on multicast RAS messages like GRQ for example: Most of the recipients would then think that the received message is not destined for them. This was therefore the reason to use the source identifier instead of the destination identifier on GRQ (in violation of ISO protocols). For unicast RAS messages, I could add the destination identifier of course. But I do not know how to handle the multicast RAS message in a better way. Using This would result at least in a partial improvement. Yes, H.235v2 is on its way and I am already preparing a new, improved version. You will see this version at the upcoming Rapporteurs meeting in October soon. So far, no modified version of H.235 has been presented. Denial of service attacks: It seems that this is an issue as you described. A good countermeasure is to include a sequence number into the signed message. The receiver should check the sequence number and should verify the signature before proceeding any further. This should be fixed as well in H.235v2. Generally, I agree with you that the procedure described in B.4.2 using the XOR does not really provide any reasonable security. This method just provides a certain (instance) authentication of just one message field (the GK-identifier); any other field in the RAS message is not authenticated or protected by any means; thus replay or modification attacks on these parts are possible without detection. To be honest with you, I don't like procedure B.4.2 either for these reasons. Anyway, B.4.2 due to its weak security is therefore not part of H.323 Annex J. A much more secure protocol is thus being applied in H.323 Annex J: Protection of the entire RAS message using either HMAC-SHA1 (with a symmetric key/password) and rapid integrity checking, or an RSA-SHA1/RSA-MD5 digital signature. Let me just mention that when a message gets lost, B.4.2 says that the most recent random should be used. Diffie-Hellman on Call Signaling channel: H.323 Annex J addresses two scenarios: In a small closed environment with shared secrets among all the participants. Then "signing" Diffie-Hellman tokens can be done by the shared secret and using an HMAC-SHA1 (see the baseline profile). The much more scaleable scenario is satisfied with digital certificates and cryptographic signature upon the Diffie-Hellman tokens (see the sophisticated profile). 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: Douglas Clowes [SMTP:dclowes@OZEMAIL.COM.AU] Sent: Friday, September 17, 1999 1:41 AM To: ITU-SG16(a)mailbag.cps.intel.com Subject: Re: Questions on H.235 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

APC Document number
by Noriko Hosokawa 17 Sep '99

17 Sep '99

Dear Mr. Patrick Luthi In response to your request, APC-1653 has been allocated to your contribution. APC-1653 Source: PictureTel $B!! (BTitle : Proposed text for G.722.1 capabilities in the $B!!!!!!!!!! (BH.323 Implementor's Guide 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 5287 7287 e-mail: okubo(a)giti.or.jp *********************************************************** Documents for Q.12-14/16 Rapporteur meeting in Red Bank (18-22 October 1999) The documents can be retrieved as ftp://standard.pictel.com/avc-site/9910_Red/APC-1???.??? or http://standard.pictel.com/ftp/avc-site/9910_Red/APC-1???.??? ------------------------------------------------------------------------ APC- Source Title ------------------------------------------------------------------------ 1645 TIPHON Proposal for an H.323 "Security Profile" 1646 Motorola Annex-H(User and Service Mobility in H.323) 1647 Lucent Mobility Agents in H.323 Reference Architecture 1648 Lucent Registration Procedure for Wireless Mobile H.323 Terminals 1649 Lucent Mobility States for the Mobile H.323 Terminals 1650 Lucent H.245 Generic Capabilities Definition and H.225 Packetization Specification for the Cellular/PCS CDMA EVRC Voice Codec. 1651 AT&T H.323 Mobility Architecture and Protocol for Terminal, User, and Service Mobility 1652 AT&T Viewgraph Presentation of H.323 Mobility Architecture and Protocol for Terminal, User, and Service Mobility 1653 PictureTel Proposed text for G.722.1 capabilities in the H.323 Implementor's Guide 1654 1655 1656 ---------------------------------------------------------------------------- ----

1 0

H.235 Control Channel
by Aseem Agarwal 17 Sep '99

17 Sep '99

Hi All H.235 specifies opening up a secure logical channel. In this mode of operation the regular H.245 control channel may operate in unsecured mode. I have the following doubts about this procedure: 1. What is the "DataType" value used in the OpenLogicalChannel message exchanged for the secure channel ? Section 8.2 specifies that "encryptionData" may be used, but elsewhere in the document the channel is referred with the value "h235Control" which is yet another value for dataType. 2. How does the exchange of encryption related information happen on the secure logical channel ? Does this happen in the data plane ? OR this new logical channel serves as a new control channel and the key exchange happens using EncryptionUpdate messages ? H.235 does not clearly specify the sematics/functionality of this logical channel. IMHO, many loose ends have been left behind which may result in different implementations. Comments/feedback welcome. Also, please let me know when we can expect the updated/next version of H.235 document. Regards, aseem(a)trillium.com

1 0

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

Re: [Fwd: Re: [Fwd: [Fwd: [Fwd: Re: H.323 mobility first draft]]] ]
by Roy, Radhika R, ALARC 15 Sep '99

15 Sep '99

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/

1 0

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

15 Sep '99

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/

1 0

Re: Issues with H.235
by Pete Cordell 14 Sep '99

14 Sep '99

The default behaviour of the compiler we use was not to make it a huge value. We've now included something which makes it treat it as a huge value. If the directive specified is standard then perhaps we should include it in the ASN.1. It is in the form of a comment so presumably compilers that don't understand it will skip it. This should improve interoperability, which, after all, is what standards are all about (or should be!). At least it could be in the implementor's guide. Pete ============================================= Pete Cordell pete(a)tech-know-ware.com ============================================= -----Original Message----- From: Bancroft Scott <baos(a)OSS.COM> To: ITU-SG16(a)MAILBAG.INTEL.COM <ITU-SG16(a)MAILBAG.INTEL.COM> Date: 08 September 1999 11:28 Subject: Re: Issues with H.235 >On Wed, 8 Sep 1999, Pete Cordell wrote: > >> 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. > >I disagree. That would be a limitation of the tool and should be >corrected by the tool vendor. > >Note that if the ASN.1 compiler that you are using supports the >industry-standard compiler directives then you can say: > > --<ASN1.HugeInteger H235-SECURITY-MESSAGES.RandomVal>-- > >which instructs the ASN.1 compiler to represent RandomVal locally in a >format suitable for holding extremely large integer values of the kind you >have in mind. The encoding of such values are as specified by the >encoding rules, independent of the local representation. > >Such directives were made an industry standard two or three years ago by a >consortium of companies including Sun, IBM, OSS Nokalva, Hewlett Packard, >Ericsson and others, and you can expect up to date compilers to support >them. > >-------------------------------------------------------------------------- >Bancroft Scott Toll Free :1-888-OSS-ASN1 >OSS Nokalva International:1-609-987-9073 >baos(a)oss.com Tech Support :1-732-302-9669 >http://www.oss.com Fax :1-732-302-0023 >

2 1

Re: [Fwd: Re: [Fwd: [Fwd: [Fwd: Re: H.323 mobility first darft]]] ]
by Roy, Radhika R, ALARC 14 Sep '99

14 Sep '99

Hi Everyone: I fully agree with Roelands Marc's comments (along with Roberto Winkler and Simon Binar) that Edgar Martinez's proposal is "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." H.323 mobility problems needs to be addressed in H.323 layer. That is, H.323 is independent of the underlying transport network (e.g., IP, ATM, MAC, radio-access, wireless LAN, etc.). However, H.323 solutions (fixed or mobile) can be implemented over any packet-based network (PBN). In this context , we also produced a terms of reference document (TD-34) in the last SG!6 Q.13 Berlin meeting. Now Roelands's comments also clarify more how H.323 mobility problems need to be addressed. I support almost all the points mentioned by Roelands. Please also see my comments enclosed below. Best regards, Radhika R. Roy AT&T + 1 732 370 2542 rrroy(a)att.com PS: Once the general mobility problems are solved in the H.323 layer, a specific implementation what Edgar Martinez has proposed in the context of the PSTN-radio-access (e.g., WAU) can be addressed very easily (e.g., wireless-PSTN-[WAU]-H.323 [ e.g., IP Network] Mobility). > -----Original Message----- > From: Roelands Marc [SMTP:Marc.Roelands@SIEMENS.ATEA.BE] > Sent: Tuesday, September 14, 1999 10:17 AM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: Re: [Fwd: Re: [Fwd: [Fwd: [Fwd: Re: H.323 mobility first > darft]]] ] > > 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. [Roy, Radhika R] I fully agree with Roelands Marc. > 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. [Roy, Radhika R] Yes, Edgar Martinez's proposal does not separate clearly between the terminal and user mobility. We need to solve problems step-by-step as specified in the terms of reference document (TD-34): 1. Terminal Mobility, 2. User Mobility, and 3. Service Mobility. > 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? [Roy, Radhika R] Per last SG16 Q.13 Berlin meeting, Annex H will deal with all: 1. Terminal Mobility, 2. User Mobility, and 3. Service Mobility. > 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? [Roy, Radhika R] H.323 needs to handle roaming and handover in the H.323 layer as well if this is NOT transparent to the H.323 layer. For example, a handover to a "new" connection may cause to release resources to the "old" connection by the GK. The multipoint controller (MC) that has the capability to create new connections while terminating the old one via ad hoc conferencing can be used to provide handover in the H.323 layer (In turn, this may also be coordinated for implementation of the handover in the physical [wireless] layer). > > 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? [Roy, Radhika R] Yes, we need to solve mobility problems in H.323 layer in a transport independent way (however, specific implementations can be offered at the radio access layer, IP network layer, etc.). > 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); [Roy, Radhika R] H.323 mobility solutions shall be transparent to the lower transport layers. > - 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); > [Roy, Radhika R] Yes, I agree. > - "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); [Roy, Radhika R] Annex H will also specify 'Interworking" between H.323 and non-H.323 (e.g., wireless-PSTN-H.323 [IP]) system. However, in an H.323 system, both GW and GK will be using the H.323 protocol. > - "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.. [Roy, Radhika R] H.323 service mobility needs more careful considerations because H.323 is yet to standardize backend services protocol. > 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. [Roy, Radhika R] TD-09 and TD-34 clearly indicate how H.323 mobility problems need to addressed. Contributions are solicited by SG16. > 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. [Roy, Radhika R] It is clearly an issue. We need to address this as we go forward. > 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. [Roy, Radhika R] All issues were discussed in the last SG16 Berlin meeting. Contributions are solicited (Edger Marinez's proposal is one such contribution. More contributions are expected in this area). > 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

1 0

Correction to the notice of the Red Bank meeting
by Sakae OKUBO 14 Sep '99

14 Sep '99

Dear Q12-14/16 experts, I have received the following advice from Mr. Matt Holdrege <matt(a)ascend.com>. The corrected version is attached. >6. Registration >^^^^^^^^^^^^^^^ > >To register your meeting attendance, please send an e-mail registration of >the following form: > > To: rrroy(a)att.com, eileen.patterson(a)acsend.com ^^ Please note the error. It should be ascend rather than acsend. > Cc: okubo(a)giti.or.jp, dskran(a)ascend.com, ggf(a)lucent.com, > tom.geary(a)conexant.com, garysull(a)microsoft.com > Subject: Red Bank meeting registration 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 5287 7287 e-mail: okubo(a)giti.or.jp *********************************************************** Subject: Notice of the Red Bank meeting Comments: cc: Pierre-Andre PROBST <pierre-andre.probst(a)swisscom.com>, George Helder <georgeh(a)pictel.com>, Federico Tosco <Federico.Tosco(a)CSELT.IT>, Fabio Bigi <FABIO.BIGI(a)ITU.CH>, Tom Geary tom.geary(a)conexant.com>, Gary Sullivan <garysull(a)microsoft.com>, Radhika Roy <rrroy(a)att.com>, Glen Freundlich <ggf(a)lucent.com> To: ITU-SG16(a)MAILBAG.INTEL.COM -------------- To Experts of ITU-T SG16 Q.12/16, Q.13/16 and Q.14/16 Cc Mr. P-A. Probst, Chairman of SG16 Mr. G. Helder, Vice-Chairman of SG16 Mr. F. Tosco, Chairman of WP2/16 Mr. F. Bigi, ITU-TSB Mr. T. Geary, Rapporteur for Q.11/16 Mr. G. Sullivan, Rapporteur for Q.15/16 Mr. R. Roy, AT&T Mr. G. Freundlich, Lucent De Sakae OKUBO Rapporteur for Q.12/16 in ITU-T SG16 TAO Waseda Research Center 5th Floor, Nishi-Waseda Bldg. 1-21-1 Nishi-Waseda, Shinjuku-ku, Tokyo 169-0051 Japan Tel: +81 3 5286 3830 Fax: +81 3 5287 7287 E-mail: okubo(a)giti.or.jp Dale SKRAN Rapporteur for Q.13/16 in ITU-T SG16 Lucent Technologies 620 Tinton Avenue Building A, Second Floor Tinton Falls, NJ 07724 USA Tel: +1 732 578 3101 Fax: +1 732 578 3120 E-mail: Dale.Skran(a)ascend.com Glen FREUNDLICH Rapporteur for Q.14/16 in ITU-T SG16 Lucent Technologies 11900 N. Pecos Westminster, Colorado 80234 USA Tel: +1 303 538 2899 Fax: +1 303 538 3907 E-mail: ggf(a)lucent.com ------------------------------------------------------------ Subject: Notice of Q.12-14/16 Rapporteur Meeting in Red Bank Date: 10 September 1999 ------------------------------------------------------------ Dear Q.12-14/16 experts, The subject meeting of ITU-T SG16 experts will be held in Red Bank, USA at the kind invitation of AT&T and Lucent Technologies. Please note that Q.11/16 and Q.15/16 will meet concurrently at the same place and have joint sessions with Q.12-14/16. 1. Date ^^^^^^^ 18 (Monday) - 22 (Friday) October 1999 starting at 9:00 on the first day closing at 15:30 on the final day 2. Venue ^^^^^^^^ Molly Pitcher Inn 88 Riverside Avenue Red Bank, NJ 07701 Voice: out of state +1 800 221 1372 New Jersey 732 747 2500 Fax: +1 732 747 2713 E-mail: mollypitcher(a)msn.com 3. Topics (tentative) ^^^^^^^^^^^^^^^^^^^^^ 1) Review of the relevant group meetings 2) Q.12/16 B-ISDN multimedia systems and terminals - H.321 v2 Implementors Guide - H.310 v2 Implementors Guide - Work with Q.13 on high quality video transmission over IP - Future AV communication systems 3) Q.13/16 Packet switched multimedia systems and terminals - Update H.323 Implementers guide - Further Develop: * H.323 V4 * H.225.0 V4 * H.323 Annex H (User and Service Mobility) * H.323 Annex I (Terminal Mobility) * H.323 Annex J (Secure SET) * H.323 Annex K (HTTP Service Control Transport Channel) * H.323 Annex L (Stimulus Signaling in H.323) * H.450.9 (Call Completion on Busy) - Work with Q.14 on H.248 white paper - Work with Q.14 on H.246 Annex C white paper - Work with Q.14 on H.246 Annex D 4) Q.14/16 Common protocols, MCUs and protocols for interworking with H.300-series terminals - Prepare H.248 white draft - Prepare H.246 Annex C white draft - Progress work on IN-H.323 interface (H.246 Annex D) - Progress work on H.341 V2 - Consider work for H.235 V2 - Update implementer's guide 5) Coordination with Q.11/16 and Q.15/16 - System aspects - Video coding aspects - Questions in the new study period 6) Interaction with other groups 7) Future work plan 4. Documents ^^^^^^^^^^^^ /// Registration of the document: by 8 October (Friday) /// /// Distribution of the document: by 11 October (Monday) /// /// Use the ftp site (or e-mail reflector) for distribution /// 1) When you are going to submit a document, please notify S. Okubo as soon as possible, by 8 October (Friday) at the latest. Document number (APC-1nnn) will be allocated. Early indication of your submission plan is welcome and encouraged. Note - Prefix "APC" comes from Atm (Q.12/16), Packet based (Q.13/16) and Common protocols (Q.14/16) based on the coordination with Q.1 ("Q1City"), Q.3 ("T120"), Q.11 ("Q11"), Q.15 ("Q15") groups. 2) You are advised to include a header as follows: ------------------------------------------------------------------ | | | ITU Telecommunication Standardization Sector Document APC-{1nnn}| | Study Group 16 {Version m if relevant}| | Q.12-14/16 Rapporteur Meeting {Date}| | Red Bank, 18-22 October 1999 | | | | SOURCE*: { } | | TITLE : { } | | PURPOSE: {Proposal, Discussion, Information, Report, etc.} | | | | _________________________ | | | | | | | | *Contact: Name, e-mail | ------------------------------------------------------------------ 3) All the contributors are requested to distribute their documents as early as possible, at least 7 calendar days in advance of the meeting (11 October or before) by posting them at either of the following: - PictureTel ftp site (please advise S. Okubo of your posting) Site: standard.pictel.com/avc-site Login name: anonymous Directory: Incoming - Q.12-14/16 experts reflector e-mail address: itu-sg16(a)mailbag.jf.intel.com Please avoid the use of reflector when your document is voluminous. 4) Input documents can be retrieved from /9910_Red directory of the ftp site. 5) Please bring 80 copies of your document to Red Bank if it should be in hardcopy. Your cooperation is needed to start the meeting with all the documents at hand; please note that the copying capacity at the meeting site is very limited and expensive. 6) The document distribution / presentation at the meeting will be electronic (i.e. participants must bring their laptop and 10BASE-T cord along). 5. Logistic information ^^^^^^^^^^^^^^^^^^^^^^^ Please see the invitation distributed by the meeting host (http://standard.pictel.com/ftp/avc-site/9910_Red/invitation.zip) 6. Registration ^^^^^^^^^^^^^^^ To register your meeting attendance, please send an e-mail registration of the following form: To: rrroy(a)att.com, eileen.patterson(a)ascend.com Cc: okubo(a)giti.or.jp, dskran(a)ascend.com, ggf(a)lucent.com, tom.geary(a)conexant.com, garysull(a)microsoft.com Subject: Red Bank meeting registration Name: Company: Arrival: Departure: Special needs: 7. Hotel Room Reservation ^^^^^^^^^^^^^^^^^^^^^^^^^ Please directly contact Molly Pitcher Inn mentioning "ITU-SG16 meeting". Application forms (e-mail, fax) are in the meeting host's invitation. Special room rate is $85 per night (not including taxes). The block reservation is held until 22 September. 8. Meeting Fee ^^^^^^^^^^^^^^ To support the meeting organization, $60 meeting fee is collected by the Molly Pitcher Inn. We are looking forward to meeting with you in Red Bank. Sincerely yours, Sakae OKUBO Dale SKRAN Glen FREUNDLICH ----------

1 0

Re: [Fwd: Re: [Fwd: [Fwd: [Fwd: Re: H.323 mobility first darft]]] ]
by Roelands Marc 14 Sep '99

14 Sep '99

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. 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? 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? 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? 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. 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

1 0

Notice of the Red Bank meeting
by Sakae OKUBO 14 Sep '99

14 Sep '99

To Experts of ITU-T SG16 Q.12/16, Q.13/16 and Q.14/16 Cc Mr. P-A. Probst, Chairman of SG16 Mr. G. Helder, Vice-Chairman of SG16 Mr. F. Tosco, Chairman of WP2/16 Mr. F. Bigi, ITU-TSB Mr. T. Geary, Rapporteur for Q.11/16 Mr. G. Sullivan, Rapporteur for Q.15/16 Mr. R. Roy, AT&T Mr. G. Freundlich, Lucent De Sakae OKUBO Rapporteur for Q.12/16 in ITU-T SG16 TAO Waseda Research Center 5th Floor, Nishi-Waseda Bldg. 1-21-1 Nishi-Waseda, Shinjuku-ku, Tokyo 169-0051 Japan Tel: +81 3 5286 3830 Fax: +81 3 5287 7287 E-mail: okubo(a)giti.or.jp Dale SKRAN Rapporteur for Q.13/16 in ITU-T SG16 Lucent Technologies 620 Tinton Avenue Building A, Second Floor Tinton Falls, NJ 07724 USA Tel: +1 732 578 3101 Fax: +1 732 578 3120 E-mail: Dale.Skran(a)ascend.com Glen FREUNDLICH Rapporteur for Q.14/16 in ITU-T SG16 Lucent Technologies 11900 N. Pecos Westminster, Colorado 80234 USA Tel: +1 303 538 2899 Fax: +1 303 538 3907 E-mail: ggf(a)lucent.com ------------------------------------------------------------ Subject: Notice of Q.12-14/16 Rapporteur Meeting in Red Bank Date: 10 September 1999 ------------------------------------------------------------ Dear Q.12-14/16 experts, The subject meeting of ITU-T SG16 experts will be held in Red Bank, USA at the kind invitation of AT&T and Lucent Technologies. Please note that Q.11/16 and Q.15/16 will meet concurrently at the same place and have joint sessions with Q.12-14/16. 1. Date ^^^^^^^ 18 (Monday) - 22 (Friday) October 1999 starting at 9:00 on the first day closing at 15:30 on the final day 2. Venue ^^^^^^^^ Molly Pitcher Inn 88 Riverside Avenue Red Bank, NJ 07701 Voice: out of state +1 800 221 1372 New Jersey 732 747 2500 Fax: +1 732 747 2713 E-mail: mollypitcher(a)msn.com 3. Topics (tentative) ^^^^^^^^^^^^^^^^^^^^^ 1) Review of the relevant group meetings 2) Q.12/16 B-ISDN multimedia systems and terminals - H.321 v2 Implementors Guide - H.310 v2 Implementors Guide - Work with Q.13 on high quality video transmission over IP - Future AV communication systems 3) Q.13/16 Packet switched multimedia systems and terminals - Update H.323 Implementers guide - Further Develop: * H.323 V4 * H.225.0 V4 * H.323 Annex H (User and Service Mobility) * H.323 Annex I (Terminal Mobility) * H.323 Annex J (Secure SET) * H.323 Annex K (HTTP Service Control Transport Channel) * H.323 Annex L (Stimulus Signaling in H.323) * H.450.9 (Call Completion on Busy) - Work with Q.14 on H.248 white paper - Work with Q.14 on H.246 Annex C white paper - Work with Q.14 on H.246 Annex D 4) Q.14/16 Common protocols, MCUs and protocols for interworking with H.300-series terminals - Prepare H.248 white draft - Prepare H.246 Annex C white draft - Progress work on IN-H.323 interface (H.246 Annex D) - Progress work on H.341 V2 - Consider work for H.235 V2 - Update implementer's guide 5) Coordination with Q.11/16 and Q.15/16 - System aspects - Video coding aspects - Questions in the new study period 6) Interaction with other groups 7) Future work plan 4. Documents ^^^^^^^^^^^^ /// Registration of the document: by 8 October (Friday) /// /// Distribution of the document: by 11 October (Monday) /// /// Use the ftp site (or e-mail reflector) for distribution /// 1) When you are going to submit a document, please notify S. Okubo as soon as possible, by 8 October (Friday) at the latest. Document number (APC-1nnn) will be allocated. Early indication of your submission plan is welcome and encouraged. Note - Prefix "APC" comes from Atm (Q.12/16), Packet based (Q.13/16) and Common protocols (Q.14/16) based on the coordination with Q.1 ("Q1City"), Q.3 ("T120"), Q.11 ("Q11"), Q.15 ("Q15") groups. 2) You are advised to include a header as follows: ------------------------------------------------------------------ | | | ITU Telecommunication Standardization Sector Document APC-{1nnn}| | Study Group 16 {Version m if relevant}| | Q.12-14/16 Rapporteur Meeting {Date}| | Red Bank, 18-22 October 1999 | | | | SOURCE*: { } | | TITLE : { } | | PURPOSE: {Proposal, Discussion, Information, Report, etc.} | | | | _________________________ | | | | | | | | *Contact: Name, e-mail | ------------------------------------------------------------------ 3) All the contributors are requested to distribute their documents as early as possible, at least 7 calendar days in advance of the meeting (11 October or before) by posting them at either of the following: - PictureTel ftp site (please advise S. Okubo of your posting) Site: standard.pictel.com/avc-site Login name: anonymous Directory: Incoming - Q.12-14/16 experts reflector e-mail address: itu-sg16(a)mailbag.jf.intel.com Please avoid the use of reflector when your document is voluminous. 4) Input documents can be retrieved from /9910_Red directory of the ftp site. 5) Please bring 80 copies of your document to Red Bank if it should be in hardcopy. Your cooperation is needed to start the meeting with all the documents at hand; please note that the copying capacity at the meeting site is very limited and expensive. 6) The document distribution / presentation at the meeting will be electronic (i.e. participants must bring their laptop and 10BASE-T cord along). 5. Logistic information ^^^^^^^^^^^^^^^^^^^^^^^ Please see the invitation distributed by the meeting host (http://standard.pictel.com/ftp/avc-site/9910_Red/invitation.zip) 6. Registration ^^^^^^^^^^^^^^^ To register your meeting attendance, please send an e-mail registration of the following form: To: rrroy(a)att.com, eileen.patterson(a)acsend.com Cc: okubo(a)giti.or.jp, dskran(a)ascend.com, ggf(a)lucent.com, tom.geary(a)conexant.com, garysull(a)microsoft.com Subject: Red Bank meeting registration Name: Company: Arrival: Departure: Special needs: 7. Hotel Room Reservation ^^^^^^^^^^^^^^^^^^^^^^^^^ Please directly contact Molly Pitcher Inn mentioning "ITU-SG16 meeting". Application forms (e-mail, fax) are in the meeting host's invitation. Special room rate is $85 per night (not including taxes). The block reservation is held until 22 September. 8. Meeting Fee ^^^^^^^^^^^^^^ To support the meeting organization, $60 meeting fee is collected by the Molly Pitcher Inn. We are looking forward to meeting with you in Red Bank. Sincerely yours, Sakae OKUBO Dale SKRAN Glen FREUNDLICH ----------

1 0

Re: Questions on H.235
by Aseem Agarwal 13 Sep '99

13 Sep '99

Hi Please see my response inline. Regards aseem(a)trillium.com >From udayas(a)hss.hns.com Thu Sep 9 20:49 PDT 1999 >Received: from turin.trillium.com (turin.trillium.com [206.216.108.218]) > by aiglos.trillium.com (8.9.3/8.9.3) with ESMTP id UAA16738 > for <aseem(a)aiglos.trillium.com>; Thu, 9 Sep 1999 20:49:10 -0700 (PDT) >Received: from tapti.hss.hns.com ([139.85.242.19]) > by turin.trillium.com (8.8.7/8.8.7) with ESMTP id UAA11451 > for <aseem(a)trillium.com>; Thu, 9 Sep 1999 20:49:07 -0700 (PDT) >Received: from sampark.hss.hns.com (sampark.hss.hns.com [139.85.229.5]) > by tapti.hss.hns.com (8.8.8/8.8.8) with SMTP id KAA20043 > for <aseem(a)trillium.com>; Fri, 10 Sep 1999 10:45:03 +0530 (IST) >Received: by sampark.hss.hns.com(Lotus SMTP MTA SMTP v4.6 (462.2 9-3-1997)) id 652567E8.0014F3FA ; Fri, 10 Sep 1999 09:18:51 +0530 >From: udayas(a)hss.hns.com >X-Lotus-FromDomain: HSSBLR >To: aseem(a)trillium.com (Aseem Agarwal) >Message-ID: <652567E8.00146863.00(a)sampark.hss.hns.com> >Date: Fri, 10 Sep 1999 09:18:46 +0530 >Subject: Re: Questions on H.235 >Mime-Version: 1.0 >Content-Type: text/plain; charset=us-ascii >Content-Length: 2920 >Status: OR > > > > >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. I agree with what you say. > >>3. Since the key is established through RAS messages like GRQ and RRQ, >> changing the key for call control channel may require using >> nonstandard fields in some messages. I do not think this is a good >> idea as this may lead to inter-operability problems. ***** I think that Diffie Hellman should be used ONCE either in RAS or in H.225 (in case of Direct Endpoint to Endpoint calls). Keys established by this procedure should be used for encryption on the call control channel. For changing the keys, H.245 provides messages like EncryptionUpdate. Any comments ? > >Regards, > >Udaya

2 1

Re: ASN.1 Syntax of H.245
by mike.nilsson＠BT.COM 13 Sep '99

13 Sep '99

It is now 13 September. I have received three mails supporting this proposed change, and no mails against it. I think that we can conclude that we have consensus to make the change. Another purely editorial error has been pointed out to me by Hidenobu Harasaki. The words 'defined in section 6' appear in 18 places, but there is no section 6 as this has been renamed to be Annex C. So the 18 occurences of 'defined in section 6' should be changed to 'defined in Annex C'. He also pointed out that this error was also present in the version 4 that I submitted to the ITU. Best regards Mike Nilsson ********************************************************************** * Mike Nilsson Tel: +44 1473 645413 * * Applications Technology Group Fax: +44 1473 645011 * * Internet and Multimedia Applications Email: mike.nilsson(a)bt.com * * BT Advanced Communications Technology Centre [B54 Room 94] * * Adastral Park * * Martlesham Heath * * Ipswich IP5 3RE * * UK * ********************************************************************** > -----Original Message----- > From: Nilsson,ME,Mike,NZA5 R > Sent: Tuesday, August 31, 1999 10:24 AM > To: 'SG16'; 'LBC'; 'H323 Implementors'; 'PotsAG' > Cc: 'Greg Jones' > Subject: ASN.1 Syntax of H.245 > > An error has been found in the ASN.1 syntax of H.245 version 5. Thanks to > Jaakko Helanti and Paul Long for identifying it. > > The error occurs in the section given below where the word 'OPTIONAL' > should appear at the end of the line 'genericModeParameters > GenericCapability'. This was an editorial error, but one that has some > technical consequence. Although the absence of the word 'OPTIONAL' does > not change the understanding of bits received by a decoder, it does demand > that an encoder always send the information 'genericModeParameters'. This > was not the intention and is not desirable. > > ModeElement ::= SEQUENCE > { > type CHOICE > { > nonStandard NonStandardParameter, > videoMode VideoMode, > audioMode AudioMode, > dataMode DataMode, > encryptionMode EncryptionMode, > ..., > h235Mode H235Mode > }, > > h223ModeParameters H223ModeParameters OPTIONAL, > ..., > v76ModeParameters V76ModeParameters OPTIONAL, > h2250ModeParameters H2250ModeParameters OPTIONAL, > genericModeParameters GenericCapability > > > } > > I have contacted the ITU regarding this. Their response was that if there > is consensus, as determined by e-mail, then as version 5 (05/99) of H.245 > has not yet been published, it will be possible to correct this error > before publication. > > I hope that two weeks will be enough time for everyone to consider this > issue, and so aim to respond to the ITU on 13 September about whether we > have achieved consensus to make this correction. > > Best regards > > Mike Nilsson > > > ********************************************************************** > * Mike Nilsson Tel: +44 1473 645413 * > * Applications Technology Group Fax: +44 1473 645011 * > * Internet and Multimedia Applications Email: mike.nilsson(a)bt.com * > * BT Advanced Communications Technology Centre [B54 Room 94] * > * Adastral Park * > * Martlesham Heath * > * Ipswich IP5 3RE * > * UK * > ********************************************************************** > > >

1 0

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

13 Sep '99

Dear Jin, You questions are in Quotes > > what are the > > problems/weakness of the being-defined 3G systems we are going to > > address/attack. Lucent's contribution indicates that the alternatives at hand have their faults. Which applies to the question you asked. >Also this document was not about IN and IP. (what it said is that IP based >MSC can re-use IN platform easily). Would you shed some light on your >proposed IN for IP mobility? Re-read the statement I do not think a MSC SERVER means the same as an MSC switch. The following is from Lucent's document... -- being of docuement copy --- With this solution it is easier develop and to re-use existing supplementary and IN services implementations. An MSC server connected to the UTRAN handling CS mobiles is architecturally in line with R99 MSCs and is less drastic a change. This document compares the two options and makes a recommendation on which should be standardized as part of R00. Use of ATM goes against the All IP definition. 3 PROPOSAL Both solutions require a substantial amount of work. Given that it is expected that most networks will be migrating from Release 99 and hence will support a CS domain in the core network, it is questionable as to the real need for either of these solutions. However, some operators may require that all traffic be carried over a common IP network as in the MSC server proposal. However, if a solution must be standardized, it would be sensible to choose the solution that will require the minimum amount of standardization work. The MSC server proposal, although not complete, is considered to be the easier to standardize. The advantage of this solution is that it does not impact the GPRS nodes with what can be considered to be legacy support. -- end of docuement copy -- We have proposed the MSGK as a MSC Server, in TIPHON many times since Tiphon 10. We are also working in the IP Mobility interworking with legacy mobile systems. And we are working with other groups to include IN into TIPHON. The point here is that the work that 3GPP-2000 is just started to look from a IP view, was started long before in TIPHON and SG16. " I do not view 3GPP-2000 as a competitive architecture to TIPHON, but one that should be complementary." Regards, Ed "Yang, Jin (Jin)" wrote: > Dear Edgar, > > The document you attached is a contribution from Lucent, comparing two > (proposed by Ericsson and Alcatel) for CS terminal support in > an "all IP" architecture. I did not quite catch the commonality between this > discussion and what's happening in TIPHON. (I may miss something, in that > case can you kelp?) > > Also this document was not about IN and IP. (what it said is that IP based > MSC can re-use IN platform easily). Would you shed some light on your > proposed IN for IP mobility? > > Thanks, > Jin > > ------------------------------ > Dr. Jin Yang > GSM, Lucent Technologies > Sigma Building > Windmill Hill Business Park > Swindon SN5 6PP > UK > Email: jinyang(a)lucent.com > Tel: +44 1793 736070 > Fax: +44 1793 883815 > > > ---------- > > From: Edgar Martinez [1][SMTP:martinze@cig.mot.com] > > Sent: 10 September 1999 19:39 > > To: Yang, Jin (Jin) > > Cc: TIPHON_WG7(a)LIST.ETSI.FR; Entirely SG16; TIPHON : Entirely > > Subject: [Fwd: Re: [Fwd: [Fwd: [Fwd: Re: H.323 mobility first > > darft]]]] > > > > <<File: R99 support.doc>> > > Dear Jin, > > > > You asked following question: > > > > > If we are going to describe a complete wireless access system, what are > > the > > > problems/weakness of the being-defined 3G systems we are going to > > > address/attack. > > > > At the time I did not have the information to reply. > > But since then I gotten some contributions that are > > going into the next 3GPP-2000 meeting and with some > > proposals I can agree on. The main issue I saw from > > most of the contributions is that everything is centered > > on the SGSN. I send a comment to 3GPP-2000 suggesting > > the following. I mean if we can do IN on IP > > why not Mobility on the same IP network?? > > > > Regards, > > Ed > > > > "Edgar Martinez [1]" wrote: > > > -------- Original Message -------- > > > Subject: Re: Lucent contributions to R00 Ad hoc > > > Date: Fri, 10 Sep 1999 13:55:53 -0400 > > > From: "Edgar Martinez [1]" <martinze(a)cig.mot.com> > > > Organization: NSS-NAT > > > To: "Daniel, Elizabeth Mary (Liz)" <lizdaniel(a)LUCENT.COM> > > > CC: 3GPP_TSG_SA_WG2(a)LIST.ETSI.FR > > > References: <199909101704.MAA00109(a)alba.cig.mot.com> > > > > > > > > Dear Mary, > > > > > > I attend both TIPHON and ITU-SG16 and read with interest your > > > contribution on support R99 CS domain terminals. If standardizing > > > IP wireless is a big consideration. Has anyone looked at > > > decomposing the SGSN and applying those functional elements into > > >a existing IP standard, and an existing IP Architecture. > > > > > > Regards, > > > Ed > > > > > > "Daniel, Elizabeth Mary (Liz)" wrote: > > > > > > > Attached are two contributions to the R00 Ad Hoc. One on handover the > > other > > > > on support of R99 CS domain terminals. > > > > <<s2k_contribs>> > > > > > Liz Daniel > > > > > GSM/UMTS Standards > > > > > Lucent Technologies O > > > > > Sigma, Swindon, UK > > > > > Tel: +44 (0) 1793 88 3412 > > > > > Fax: +44 (0) 1793 88 3815 > > > > > E-Mail: lizdaniel(a)lucent.com > > > > > > > > > > > > > > > ------------------------------------------------------------------------ > > > > Name: s2k_contribs.zip > > > > s2k_contribs.zip Type: Winzip32 File (application/x-winzip) > > > > Encoding: base64 > > > > Description: s2k_contribs > > > > > > -- > > > 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/ > > > > > > -------- Original Message -------- > > Subject: Re: [Fwd: [Fwd: [Fwd: Re: H.323 mobility first darft]]] > > Date: Fri, 03 Sep 1999 16:27:25 -0400 > > From: "Edgar Martinez [1]" <martinze(a)cig.mot.com> > > Organization: NSS-NAT > > To: "Yang, Jin (Jin)" <jinyang(a)LUCENT.COM> > > CC: TIPHON_WG7(a)LIST.ETSI.FR > > References: <199909031416.JAA27858(a)alba.cig.mot.com> > > > > Dear Jin, > > > > The cat is out of the bag.. > > > > more to follow below... > > > > "Yang, Jin (Jin)" wrote: > > > > > Ed, > > > > > > more questions/comments follow. > > > > > > Thanks, > > > Jin > > > > > > ------------------------------ > > > Dr. Jin Yang > > > Principal Systems Engineer > > > GSM, Lucent Technologies > > > Sigma Building > > > Windmill Hill Business Park > > > Swindon SN5 6PP > > > UK > > > Email: jinyang(a)lucent.com > > > Tel: +44 1793 736070 > > > Fax: +44 1793 883815 > > > > > > > ---------- > > > > From: Edgar Martinez [1][SMTP:martinze@CIG.MOT.COM] > > > > Reply To: Edgar Martinez [1] > > > > Sent: 02 September 1999 12:56 > > > > To: TIPHON_WG7(a)LIST.ETSI.FR > > > > Subject: [Fwd: [Fwd: [Fwd: Re: H.323 mobility first darft]]] > > > > > > > > Dear All, > > > > > > > > Very good questions: > > > > > > > > I passing this email on because > > > > MR. Binar questions highlights > > > > some key issues. > > > > > > > > Ed > > > > > > > > FAQ's on IP wireless mobility. > > > > > > > > -------- Original Message -------- > > > > Subject: Re: H.323 mobility first darft > > > > Date: Wed, 01 Sep 1999 17:15:17 -0400 > > > > From: "Edgar Martinez [1]" <martinze(a)cig.mot.com> > > > > Organization: NSS-NAT > > > > To: "BINAR, Simon" <binar(a)isd-nec.co.uk> > > > > References: <199909011655.LAA02929(a)alba.cig.mot.com> > > > > > > > > Hi Simon, > > > > > > > > Thank you for your comments, > > > > Please read on... > > > > > > > > "BINAR, Simon" wrote: > > > > > > > > > Hi Ed, > > > > > > > > > > I looked at the document, and I would have a couple of > > > > > questions/comments about it. > > > > > > > > > > It seems to me that the draft provides the description of a complete > > > > > wireless access system. > > > > > > > > Yes, based on the SG16 Terms of reference. > > > If we are going to describe a complete wireless access system, what are > > the > > > problems/weakness of the being-defined 3G systems we are going to > > > address/attack. > > > > I can not attack something is being-defined, If it isn't defined. > > If it is defined to do something and it does it, that's fine. > > Lets defined wireless VoIP and address and attack those > > areas. Which is what TIPHON and SG16 is doing...all > > end-to-end IP issues. > > > > It is easier to be backward comparable them forward comparable. > > e.g., old Rotary phones can not outpluse DTMF and > > New DTMF phones can do both. Both types of phones > > are still supported but the old Analog systems are gone, > > and so are the Adjuncts (today it is called the overlay solutation). > > > > Lets focus on IP. > > > > If the Radio Access interface has the option to support > > a pure VoIP connection. > > > > The underline pure IP (pIP) Network will need to support > > what TIPHON is working on now, which is : charging/billing and security, > > call control procedures, naming and address translation issues, > > end to end quality of service aspects, verification, > > demonstration of legacy system interworking. All covered > > under the TIPHON systems. > > > > > > > > > > > > > However, I don't understand the point of > > > > > providing such a description, since wireless access systems suitable > > for > > > > > multimedia communications are being specified elsewhere (3GPP). > > > > > > > > Based on the Terms of reference and the Ad-hoc meetings we had in > > SG16. > > > > The assumptions where: > > > > > > > > 1. We will have H.323 wireless mobile handsets > > > > 2. We will provide IP mobility regardless of terminal type Fixed or > > > > Wireless > > > > 3. We will interwork with the legacy wireless (Networks and Terminals) > > > > which includes handovers.. > > > > > > > UMTS, for example, allows you to do 1 and 2. and 3GPP and 3GIP are > > working > > > on 3 (with lot of progresses already). > > > > If you imply that UMTS directly supports the H.323 Gateway, Gatekeeper > > MCU, SGW and MGW and both wireless/fixed H.323 PC terminals. > > Great I'll support it. Can you provide us reference to your claims. > > Also note that wireless mobility for a H.323 fixed terminals does not > > include > > handover, but for H.323 mobile terminal (MT) handover is included. > > > > Second point to your question, It would be nice to know what legacy > > NETWORK(s) is 3GPP-3GIP interworking with, since the voice and data is > > spit > > at the RAN where the voice traffic goes to the MSC and the data goes > > to the GPRS network. You call that alot of progresses? smells like > > adjuncts.. > > But you know all this I guess you wanted my confirmation? > > > > > > > > > > > > 3GPP or 3GPP-2000 is based on GPRS and something called > > > > the layered approach to the IP network. Which ready means > > > > two separate networks one for IP and the other for mobility > > > > connected via a GW. The RAN interface (Iu-ps) to the GPRS > > > > network element is a lower layer ATM/AAL2 with IP on > > > > the upper layer connected to E-SGSN switch. > > > Iu-ps (transport) has GTP/IP/ATM. Do you have any concern here? > > > > I miss something, Why ATM? in a end-to-end IP network. > > > > > > > > > > > > I can not be convinced or believe that this is the pure > > > > IP solution for wireless. > > > what is a pure IP solution in your mind? > > > > An network that is all IP end-to-end as > > for your example (Applications/GTP/IP). > > Like TIPHON system with molitity is a > > pure IP solution. > > > > Thanks, > > > > Ed > > > > > > > > > > > > > Thanks, > > > Jin > > > > > > > > > > > > > Shouldn't the wireless access system rather be completely > > transparent to > > > > > H.323 signalling? > > > > > > > > It is completely transparent, take alway the WAU and the HZR > > > > and you have your basic H.323 VoIP network. > > > > > > > > > > > > > > > > > > > Additionally, it seems to me that the proposed architecture does not > > > > > take into account mobility between fixed terminals. I can imagine > > > > > situations whereby a user could take his SIM card from one fixed > > H.323 > > > > > terminal to another. In such a case, mobility support at the H.323 > > > > > application layer would be required, however, no wireless access > > system > > > > > would be involved, and thus, components such as the WAU would not be > > > > > required either... > > > > > > > > Yes, you are right on the money, look at 8.2.1.5 "H.323 fixed terminal > > > > registration in a visited IP network" which implies exactly what > > > > you stated. The way it works from my research, is that the > > > > IMIS is programed in to the SIM card. The user ID is the IMIS once > > > > the user, that is, the IMIS is registered in the HZR. > > > > The user can plug the SIM card with the proper IMIS > > > > in a wireless terminal or fixed terminal. Please note that in the > > > > two fixed case call flows both 8.2.1.5 and 8.2.1.6 no WAU are > > > > used or shown. Only for the wireless cases. > > > > > > > > > > > > > > > > > > > ---------------------------------------------- > > > > > Simon Binar > > > > > NEC Europe Ltd. > > > > > Tel: +44 (0)1753 606933 > > > > > Fax: +44 (0)1753 606901 > > > > > EMail: binar(a)isd-nec.co.uk > > > > > ----------------------------------------------- > > > > > DISCLAIMER: Any views or opinions expressed in > > > > > this E-Mail message should be considered as the > > > > > personal views/opinions of the author. They do > > > > > not necessarily represent the views of the > > > > > author's employer. > > > > > > > > > > > -----Original Message----- > > > > > > From: Edgar Martinez [1] [mailto:martinze@CIG.MOT.COM] > > > > > > Sent: 23 August 1999 08:19 > > > > > > To: TIPHON(a)LIST.ETSI.FR > > > > > > Subject: H.323 mobility first darft > > > > > > > > > > > > > > > > > > Dear All > > > > > > > > > > > > I have uploaded the first H.323 draft, for user > > > > > > and service mobility. > > > > > > The focus of the document at the moment is to provide full > > > > > > mobility regards of terminal types, that is either fixed or > > wireless > > > > > > h.323 terminals. Only using H.323 messages with additional > > > > > > extensions to provide seamless wireless handover and > > > > > > terminal roaming. > > > > > > > > > > > > Anyone can pick-up a copy in following wed sites. > > > > > > > > > > > http://people.itu.int/~emartine/temp/ > > > > > or > > > > > ftp://standard.pictel.com/avc-site/Incoming/ > > > > > > > > > > The Filename is h323mob01.zip > > > > > > > > > > Comments are welcome. > > > > > > > > > > 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/ > > > > > > > > > > ------------------------------------------------------------------- > > > > > Mail archive for TIPHON can be browsed at the following url : > > > > > > > > > > http://www.etsi.org/tiphon/mailing.htm > > > > > ------------------------------------------------------------------- > > > > > > > > -- > > > > 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/ > > > > > > > > ------------------------------------------------------------------- > > > > Mail archive for TIPHON_WG7 can be browsed at the following url : > > > > > > > > http://www.etsi.org/tiphon/mailing.htm > > > > ------------------------------------------------------------------- > > > > > > > > > > ------------------------------------------------------------------- > > > Mail archive for TIPHON_WG7 can be browsed at the following url : > > > > > > http://www.etsi.org/tiphon/mailing.htm > > > ------------------------------------------------------------------- > > > > -- > > 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