September 1999 - sg16-avd - lists.packetizer.com

Queries on RAS security !!
by Aparna Saha 20 Sep '99

20 Sep '99

Hi Jim, I have a few queries related to H.235, specifically, RAS security. This is regarding the RAS procedures for authentication . During the GRQ-GCF exchange, the security info ( the secret key and the algorithmId ) gets established with the GK. For the subsequent RRQ, how does the GK relate the RRQ with the info stored ? Is there any mechanism for refreshing keys in RAS ? Thanks and regards, Aparna.

1 0

APC Document Numeber
by Noriko Hosokawa 20 Sep '99

20 Sep '99

Dear Mr. Francois Audet In response to your request, APC-1654 has been allocated to your contribution. APC-1654 > Title: ISO/IEC 11571 addressing in H.323 Annex V > Source: Nortel Networks 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 Nortel ISO/IEC 11571 addressing in H.323 Annex V Networks 1655 1656 ---------------------------------------------------------------------------- ----

1 0

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

19 Sep '99

At 12:01 1999-09-17 +0200, Euchner Martin wrote: >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. OK, I forgot the multicast case. However, the generalId should, IMHO, be either that of the recipient (unicast) or not present (multicast), rather than that of the sender as shown. >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. While you're at it, 10.3.2 method for forming a key from a password is embarrassingly weak. A short password ('X' for example) produces a key which is mostly zero bits. Even a longer pass phrase will prod use a key with high order bits set to zero in each byte, and similar characteristics reducing a keys strength significantly. Most credible schemes would use a hash function (MD5 or SHA1) over the pass phrase, and would not fill out the pass phrase with zeroes. The amount of entropy in such a key will be very low, and one should not use such a key for bulk encryption. To do so would provide an attacker with a large amount of cryptotext, some of which will be known, enabling a known-cryptotext attacks. An additional key generation/exchange mechanism should be employed. >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. In UDP based protocols, strict sequencing is not possible, because message order and delivery and duplication are not guaranteed. An eavesdropper can easily generate a sequence number in the range, so a legitimate message will duplicate an illegitimate message sequence number. A signature is a more secure check. >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. Good. It should not be part of H.235 either. >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. I understand that HMAC-xxx-96 gives away less information on the key, and should be preferred for a long term password based mechanism. >Let me just mention that when a message gets lost, B.4.2 says that the most recent random should be used. Trouble is that, for a time, neither party knows that a message is lost. If I send you an xRQ and you send me a new random in the xCF, which random do you use to check my next message? It needs to be different depending on whether the xCF was lost or not. If you use the new one, and my next transmission is a retransmit of the original xRQ, will you reject it because it doesn't use the new random? You will have to check both. If I send you an xRQ that lives for a while in a router queue, receive a new random and use it in a message that arrives at you before the earlier one (out of order reception happens) and you check it against the new random, it matches. When the first message arrives, it has the old random. Will you reject it or ignore it? Either way, will I understand that I have to recompute it and send it again. If you reject it, I may fail the operation. If you ignore it, I may resend the same bit-pattern with the old random. >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). Again, HMAC-SHA1-96 seems the preferred mechanism in IPsec (RFC-2403 and 2402). I agree with you there, but wonder if it's better to sign the entire message, just the DH component, or both. Regards, Douglas >Regards, > >Martin.

1 0

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

17 Sep '99

Hi Ed: I appreciate your reply. To support wireless handset in pure H.323 environment, we may think couple of scenarios: 1. Wireless LAN, 2. H.323 Wireless handset (2a. WAU that is NOT aware of H.323, 2b. WAU that is H.323-aware), and 3. (Non-H.323) wireless handset interfacing an H.323 system via a IWF (GW). In addition, we also have situations what mobile IP [IETF] is dealing with. I would call this as scenario 4. H.323 needs not to be aware of the radio link environment in scenarios 1 and 2a and, the H.323 mobility solution is independent of the lower link layer. The general H.323 mobility problem needs to address intra-zone, inter-zone, and inter-domain mobility management (change of point-of-attachment [network, zone, domain]) before bringing the radio link issues. In this context, we need to address (GK) discovery, registration, location updates, call establishment, roaming, and handover in the H.323 layer. We will find that H.323 needs extensions to support mobility. In scenario 2b (I guess is that your contribution is primarily concerned with) is a special case. That is, WAU is both H.323- and radio link-ware. As a result, your contribution is proposing some extensions in H.323 to deal with this situation. This is a very interesting situation that we need to consider as a special case. What I would suggest that let us address this situation in the light of cases 1, 2a, and 4 where the H.323 mobility solution is provided without being aware of the radio link. Then, we need to address scenario 4: For example, cellular-PSTN and H.323 Mobile system interworking. We have drafted this requirement as the "INTERWORKING." In this context, we might see that H.323 may need more extensions to support mobility. That is, the radio traffic that you are concerned with may be dealt later once we see that we have solved the mobility problems in the H.323 layer. Then, we can apply it in some specific scenarios like the radio environment as you have started (scenario 2b). The point is that the general solution should also be capable to solve the problem that you have undertaken (if needed some extensions can be made). The question is: what would be the approach to solve the H.323 mobility in the H.323 layer? The paper of W. Liao published in the INFOCOM'99 conf provides some ideas. This paper might be a good start to solve the mobility problem in the H.323 layer. However, we have to go a long way to meet all requirements of mobility in H.323 beyond what has been discussed in this paper. As APCs indicated, more contributions (e.g., AT&T, Lucent, others) are coming in the upcoming Red Bank (Oct 18-22) conf. With respect to the MC (not necessarily MCU) to provide the handoff, it can be placed with the GK, GW, or other entities (e.g., WAU) as needed. This might be an option for implementations. However, handoff will be in the H.323 layer (Please also see the above paper). Then, we can translate this into the corresponding radio layer. The handoff in the radio layer can be implementation specific. In fact, we might need all functionalities that you have proposed in the radio layer. Again, your contributions have provided valuable insights to address H.323 mobility problems. Hope this will help. Best regards, Radhika > -----Original Message----- > From: Edgar Martinez [1] [SMTP:martinze@CIG.MOT.COM] > Sent: Wednesday, September 15, 1999 10:44 AM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: Re: [Fwd: Re: [Fwd: [Fwd: [Fwd: Re: H.323 mobility first > draft]]]] > > 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: 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

Re: [Fwd: Re: [Fwd: [Fwd: [Fwd: Re: H.323 mobility first darft]]] ]
by Yang, Jin (Jin) 13 Sep '99

13 Sep '99

Dear Edgar, The document you attached is a contribution from Lucent, comparing two alternatives (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/ >

1 0

APC Document number
by Noriko Hosokawa 13 Sep '99

13 Sep '99

Dear Mr. Dan Gal In response to your request, APC-1650 has been allocated to your contribution. APC-1650 Source: Lucent Title : H.245 Generic Capabilities Definition and H.225 Packetization Specification for the Cellular/PCS CDMA EVRC Voice Codec. 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 1654 1655 1656 ----------------------------------------------------------------------------

1 0

APC Document number
by Noriko Hosokawa 13 Sep '99

13 Sep '99

Dear Mr. Radhika R. Roy In response to your request, APC-1651 and 1652 have been allocated to your contributions. APC-1651 Source: AT&T Title : H.323 Mobility Architecture and Protocol for Terminal, User, and Service Mobility APC-1652 Source: AT&T Title : Viewgraph Presentation of H.323 Mobility Architecture and Protocol for Terminal, User, and Service Mobility 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 1654 1655 1656 ---------------------------------------------------------------------------- ----

1 0

Megaco/H.248 Contexts and Context Parameters
by Tom-PT Taylor 13 Sep '99

13 Sep '99

We have had a long discussion on the Megaco list about whether the sort of topology micro-management proposed in Berlin, with "Topology" as a context property, is really necessary. I would summarize the outcome of that discussion by saying that we can meet the known requirements for Legal Interception (if a vendor chooses to implement it in the MG) without the proposed Topology property. However, that property could allow for some value-added capability in a gateway (e.g. the difference between the subject of an operator intervention hearing only the operator and hearing the operator and also the other parties to the call in the background). I therefore propose this as the consensus resolution: the Topology property will be defined in the protocol, but support is optional both at the MG and the MGC. With this resolution in mind, I propose a change in the opening paragraph of section 6.1, "Contexts", of the current draft. It currently reads: "A Context is an association between a number of Terminations. The Context describes the topology (who hears/sees whom) and the media mixing and/or switching parameters if more than two Terminations are involved in the association." I propose instead this more expanded description: "A Context is an association ... Terminations. When more than two Terminations are present in a Context, the Context takes on the properties of a mixing bridge. The default assumption for audio streams is that the Context serves as an N-1 additive bridge, passing to each Termination the sum of inputs from all other Terminations in the context. When other media or other types of mixing are desired, the mixing behaviour for each stream must be stated explicitly as a context parameter. "By default, the Context is assumed to implement a star topology with the mixing bridge at the centre. The topology of the media flows through the context is controlled by controlling the flows into and out of the context at the individual Termination level. The flows between the Terminations and the mixing bridge are assumed to be continuations of the external flows in each direction. "As a value-added option, some MGs may support an alternate mesh topology through the mixing bridge. To control this, the protocol provides for a Topology property at the context level. Support of this property is optional at both the MG and the MGC." ------------- Following on from that, we need help from the specialists in Study Group 16, to create the appropriate syntax, first to describe the bridging properties and secondly to describe the topology. I will remind people proposing the syntax that the bridging behaviour will generally be different for each medium, and hence must be tied to the StreamID. Tom Taylor Advisor -- IPConnect Standards E-mail: taylor(a)nortelnetworks.com (internally, Tom-PT Taylor) Phone and FAX: +1 613 736 0961

2 1

Introducing: Dr As Cellulite Reducing & Weight Loss System
by Andy 12 Sep '99

12 Sep '99

Hello, We work with a weight loss physician (also American Board Certified in Family Medicine), who has formulated a topical gel product that has been very successful in the elimination of cellulite fat. This cellulite-reducing topical gel product is simply amazing! You literally have to measure yourself before and after using this product to believe it. Testimonials are flooding into this physician s office from people who have lost both inches and pounds, after just the first week of using the system. Here is just one of them: "I lost nine and half inches total, after my very first week of applying the gels. After my second and third weeks of application, I lost an additional 18 inches. My inches loss, as well as my weight loss, accelerated tremendously, when I started using the weight loss pills that came in my pak. In three months, I have lost a total of 42 inches and 22 pounds! Whats more, I have more energy than ever, I sleep better and I feel so much healthier. Presently, my friends, having seen the great results I have had with Dr As Cellulite Reducing & Weight Loss System, are now using the system as well. One of them lost an astounding 18 inches total after her very first week of applying the gels. Her self esteem is so much improved. Need we say more? If you will like to receive FREE info about Dr As Cellulite Reducing & Weight Loss System, fill the Info Request Form below, and fax it to: 208-246-1506 Info Request Form: Yes, please send me the FREE info on Dr As Cellulite Reducing & Weight Loss System. Please forward the said info to my LEGIBLY written or typed email address below. Thanks. Email Address : ________________________________________________ Note: Info is only sent by email. Thank you for your time. You will receive complete info within 72Hours on regular weekdays. ********************************************************************* To be removed reply to: mailto:citra157@usa.net?subject=remove *********************************************************************

1 0

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

10 Sep '99

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/

1 0

I'm out of the office (auto reply)
by Francois-Xavier Kowalski 10 Sep '99

10 Sep '99

Hello, I am not in the office right now to respond to your mail. I will reply to you (if necessary) upon my return. * For urgent cases, please contact Laurent VALLUY - Hewlett-Packard Telecom Infrastructure Division phone: +33 (0) 4 76 14 58 78 net: LAURENT_VALLUY(a)grenoble.hp.com, LAURENT_VALLUY(a)HP-France-om8.om.hp.com Thank you.

1 0

Implementers Guide; Changes to h.341 MIB
by Irina Suconick 10 Sep '99

10 Sep '99

Paul, Please include the following changes to H.341 MIB in the H.323 Implementers Guide. These changes were approved in the last SG16 meeting in Berlin. Thanks, Irina 1) Removed a double definition of rasAdmissionCallIdentifier from this table. rasAdmissionTable OBJECT-TYPE SYNTAX SEQUENCE OF RasAdmissionTableEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table contains information about entities that have been admitted by the gatekeeper. It is a list of admitted endpoints. The number of entries equals to the number of admitted endpoints." ::= { rasAdmission 1 } rasAdmissionTableEntry OBJECT-TYPE SYNTAX RasAdmissionTableEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "It contains objects that describe endpoints that are admitted by the gatekeeper. " INDEX { ifIndex, rasAdmissionSrcCallSignallingAddress, rasAdmissionRasAddress, rasAdmissionCallIdentifier } ::= { rasAdmissionTable 1 } RasAdmissionTableEntry ::= SEQUENCE { rasAdmissionSrcCallSignallingAddressTag MmTAddressTag, rasAdmissionSrcCallSignallingAddress TAddress, rasAdmissionDestCallSignallingAddressTag MmTAddressTag, rasAdmissionDestCallSignallingAddress TAddress, rasAdmissionCallIdentifier MmGlobalIdentifier, rasAdmissionConferenceId MmGlobalIdentifier, rasAdmissionRasAddressTag MmTAddressTag, rasAdmissionRasAddress TAddress, rasAdmissionCRV MmH225Crv, rasAdmissionIsGatekeeper TruthValue, rasAdmissionSrcAliasAddressTag MmAliasTag, rasAdmissionSrcAliasAddress MmAliasAddress, rasAdmissionDestAliasAddressTag MmAliasTag, rasAdmissionDestAliasAddress MmAliasAddress, rasAdmissionAnswerCallIndicator INTEGER, rasAdmissionTime DateAndTime, rasAdmissionEndpointId MmEndpointID, rasAdmissionBandwidth Integer32, rasAdmissionIRRFrequency Integer32, rasAdmissionCallType MmCallType, rasAdmissionCallModel INTEGER, rasAdmissionSrcHandlesBandwidth TruthValue, rasAdmissionDestHandlesBandwidth TruthValue, rasAdmissionSecurity TruthValue, rasAdmissionSrcWillSupplyUUIE TruthValue, rasAdmissionDestWillSupplyUUIE TruthValue, rasAdmissionTableRowStatus RowStatus } 2) Combined the two counters for each variable into one. Each variable had a counter for the number of "In" messages (received) and the number of "Out" messages (sent). Now each variable represents the number of messages that were sent and received. CallSignalStatsEntry::= SEQUENCE { callSignalStatsCallConnections Counter32, callSignalStatsAlertingMsgs Counter32, callSignalStatsCallProceedings Counter32, callSignalStatsSetupMsgs Counter32, callSignalStatsSetupAckMsgs Counter32, callSignalStatsProgressMsgs Counter32, callSignalStatsReleaseCompleteMsgs Counter32, callSignalStatsStatusMsgs Counter32, callSignalStatsStatusInquiryMsgs Counter32, callSignalStatsFacilityMsgs Counter32, callSignalStatsInfoMsgs Counter32, callSignalStatsNotifyMsgs Counter32, callSignalStatsAverageCallDuration Integer32 } 3) rasRegistrationEndpointType is changed from Integer32 to MmH323EndpointType RasRegistrationTableEntry ::= SEQUENCE { rasRegistrationCallSignallingAddressTag MmTAddressTag, rasRegistrationCallSignallingAddress TAddress, rasRegistrationSrcRasAddressTag MmTAddressTag, rasRegistrationSrcRasAddress TAddress, rasRegistrationIsGatekeeper TruthValue, rasRegistrationGatekeeperId MmGatekeeperID, rasRegistrationEndpointId MmEndpointID, rasRegistrationEncryption TruthValue, rasRegistrationWillSupplyUUIE TruthValue, rasRegistrationIntegrityCheckValue TruthValue, rasRegistrationTableNumberOfAliases Integer32, rasRegistrationTableRowStatus RowStatus, rasRegistrationEndpointType MmH323EndpointType, rasRegistrationPregrantedARQ TruthValue, rasRegistrationIsregisteredByRRQ TruthValue }

1 0

Question about SET EndpointType
by henri.maenpaa＠NOKIA.COM 10 Sep '99

10 Sep '99

All, There seems to be redundant information in the endpointType IE concerning SETs. Hopefully this has just been left there accidentally from the earlier versions of H.225v3 drafts. Could someone clarify: First, endpointType can have set "bitmask" octet string along with terminal or gateway structures. OK. Then, if terminal was chosen for endpointType, terminalInfo specifies (again) being a SET with a boolean value. I think this should be removed. If there is some reason for including it there, then shouldn't it be included into gatewayInfo struct as well?!? -Henri Mäenpää, Nokia Wireless Business Communications

2 1

APC document number
by Noriko Hosokawa 10 Sep '99

10 Sep '99

Dear Mr. Orsic, Milo In response to your request, APC-1647,1648 and 1649 have been allocated to your contributions. APC-1647 Source: Lucent Title : Mobility Agents in H.323 Reference Architecture APC-1648 Source: Lucent Title : Registration Procedure for Wireless Mobile H.323 Terminals APC-1649 Source: Lucent Title : Mobility States for the Mobile H.323 Terminals 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 ---------------------------------------------------------------------------- From: "Orsic, Milo (Milo)" <orsic(a)lucent.com> To: "'okubo(a)GITI.OR.JP'" <okubo(a)GITI.OR.JP> Cc: "Orsic, Milo (Milo)" <orsic(a)lucent.com> Subject: APC Number Date: Thu, 9 Sep 1999 23:19:44 -0500 Dear Mr. Okubo, Will you please assign the APC numbers to the following Lucent contributions that will be presented at the forthcoming October 18-22, 1999 ITU-T SG16/Q 13-14 Rapporteur Meeting in Red Bank, NJ. 1. TITLE: Mobility Agents in H.323 Reference Architecture 2. TITLE: Registration Procedure for Wireless Mobile H.323 Terminals 3. TITLE: Mobility States for the Mobile H.323 Terminals All three contributions are discussing the mobility issues pertaining to the wireless mobile H.323 terminals. It is proposed that these contributions are discuss and adopted for inclusion into the H.323 Annex I document. Thank you very much for your kind attention to this matter. Regards, Milo Orsic Lucent Technologies orsic(a)lucent.com +1 630 713 5161 ----

1 0

Invitation to October Q.11-15 rapporteurs meeting in Red Bank
by Sakae OKUBO 10 Sep '99

10 Sep '99

Dear Q12-14/16 experts, Please find attached the invitation to the next Rapporteur meeting (Red Bank meeting) in October received from the host, AT&T and Lucent. Please note that there is an attachment file. The file has been placed at the PictureTel ftp site as: ftp://standard.pictel.com/avc-site/9910_Red/invitation.zip or http://standard.pictel.com/ftp/avc-site/9910_Red/invitation.zip The meeting notice will follow very soon. 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 *********************************************************** We are pleased to invite experts of Q.11, Q.12, Q.13, Q.14, and Q.15 to the joint rapporteurs' meeting to be held 18 - 22 October, 1999, in Red Bank, New Jersey. Please find attached information regarding the meeting location, meeting logistics, and lodging. Please also note that a block of rooms will be held by the hotel until 22 September, so delegates are encouraged to make arrangements very soon. The hotel had booked another function for Friday night before we made arrangements, so we will need to vacate the meeting rooms by 3:30 on Friday. We know this will disappoint many of us who have become accustomed to running until 7:00 or 8:00 in the evening on the last day. Because of this other function, the hotel is only able to hold a block of 70 rooms for Friday night. We hope this will not be a problem, as the early finish time should allow many delegates to catch a flight on Friday evening. Best Regards, Radhika Roy - AT&T Glen Freundlich - Lucent Technologies

1 0

LogicalChannelRateRelease
by Srinivasa Beereddy 10 Sep '99

10 Sep '99

Hi All, H.245V5 introduces new logical channel bit rate change messages. One of the message is LogicalChannelRateRelease. The section B.1.2.4 says the following. B.1.2.4 Logical Channel Rate Release This is sent in the case of a timeout. My question is which timer should be used for the above indicated purpose? There are no new timers added to H.245V5. thanks, Srini Trillium Digital Systems ~ ~

2 1

H.323v4 draft
by Paul E. Jones 09 Sep '99

09 Sep '99

Dear Experts, I have posted a preliminary draft of H.323v4 in the Incoming directory of the AVC site. This draft should contain all of the text approved for v4 during the Berlin meeting. As was mentioned Berlin, we would like to work out issues with the gateway decomposition and application sections as much as possible BEFORE the October meeting. Please, make comments. Also, there was some text that was accepted in Berlin for the Implementers Guide (relating to v2 and v3) and other text that was intended to be introduced as a rapporteur's TD during the September meeting to correct errors in the H.323v3 white contribution. All of that text should be in this v4 draft document. Please bring my attention to anything that is missing. I'll have to speak with Mr. Skran to find out exactly what he would like to introduce via a Rapporteur's TD for H.323v3. However, below is a list of things I would personally like to see introduced during the September meeting. o All changes made to Annex C, which were made to preserve backward compatibility. o Changes made to section 8.1.7 (fast connect procedure) o Changes to 8.4.6 (third party pause) Please voice your opinion on additions to or deletions from this list. Best Regards, Paul

3 3

Questions on H.235
by Aseem Agarwal 08 Sep '99

08 Sep '99

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

Issues with H.235
by Pete Cordell 08 Sep '99

08 Sep '99

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 =============================================

3 2

Re: Pathological bearer cap changes in H.225.0v3
by Callaghan, Robert 07 Sep '99

07 Sep '99

Paul, Your logic is correct. I only attempted to provide you with a summary of the discussion in Santiago. There were a number of IEs that forbidden that were to be added in Berlin. This, in part, came about from one possible solution for transporting QSIG over H.323. Because there was no resolution to the primary question, the IE change was not accepted. This question is scheduled to return at Red Bank. That would be a good chance for your opinion to be heard. The worst case is that everything forbidden will be possible. Bob ------------------------------------------------------------------ Robert Callaghan Siemens Business Communication Systems Tel: +1.561.997.3756 Fax: +1.561.997.3403 Email: Robert.Callaghan(a)ICN.Siemens.com ------------------------------------------------------------------ -----Original Message----- From: Paul Long [mailto:plong@SMITHMICRO.COM] Sent: Tuesday, September 07, 1999 3:13 PM To: ITU-SG16(a)mailbag.cps.intel.com Subject: Re: Pathological bearer cap changes in H.225.0v3 Bob, 1. But there has never been a requirement that components of IEs be treated like actual IEs. Where did this come from? This is a gross rationalization. The Recommendation clearly states that this octet shall not be encoded. Therefore, it is perfectly reasonable for an entity to assume that it will never encounter this octet. Geez, what are standards for? What other "shalls" will be relaxed in the future? 2. Even if IE components were to be treated like IEs--which they cannot--this would still not justify the removal of this requirement. H.225.0 says only that "unrecognized," e.g., new, IEs shall be ignored, not that well-known but otherwise clearly prohibited ones shall be ignored, which is what you are proposing. But please prove me wrong. Show me in the H.225.0 Recommendation where it says that 1. IE components, such as Octet 3a of bearer caps, shall be treated like IEs and 2. that well-known but otherwise prohibited IEs shall be ignored. BTW, our products in particular are okay in this regard--they will ignore optional IE fields, even the ones that are prohibited--so I'm not simply trying rationalize something to keep our products from becoming non-interoperable due to a bad design decision. It's just that I don't like the precedent this sets that it's okay to "change the rules once the game has started." I won't go on about this, though. I'm done. Paul Long Smith Micro Software, Inc. -----Original Message----- From: Callaghan, Robert [mailto:Robert.Callaghan@ICN.SIEMENS.COM] Sent: Tuesday, September 07, 1999 12:58 PM To: ITU-SG16(a)MAILBAG.INTEL.COM Subject: Re: Pathological bearer cap changes in H.225.0v3 Paul, The question you present was covered in Santiago. The conclusion is that v1 and v2 devices should conform to the procedures for information elements that have content that is not understood. For information elements that are not defined as "must understand" (Calling party number is in this class) if the contents are not understood, then the information element shall be discarded and the connection is completed without this element. For the calling party number information element, if octet 3a is added in order to indicate "presentation restricted" and this in not understood; the calling party number ie is discarded and the connection is completed without this element. If the element is not present, then its contents may not be presented (No problem). Bob ------------------------------------------------------------------ Robert Callaghan Siemens Business Communication Systems Tel: +1.561.997.3756 Fax: +1.561.997.3403 Email: Robert.Callaghan(a)ICN.Siemens.com ------------------------------------------------------------------ -----Original Message----- From: Paul Long [mailto:plong@SMITHMICRO.COM] Sent: Tuesday, September 07, 1999 1:08 PM To: ITU-SG16(a)mailbag.cps.intel.com Subject: Pathological bearer cap changes in H.225.0v3 I just took a look at the changes made to H.225.0v3 in Santiago. I noticed that whereas octet 3a of Calling Party Number in Bearer caps "Shall not be present" in H.225.0v1 and v2, it is allowed in v3! And this apparent oversight was not rectified in Berlin after discussion on this reflector. How will we now guarantee interoperability between v1, v2, and v3+ entities? What if some v1 or v2 entities were implemented according to the Recommendation and do not expect this octet to be present and indeed will fail through no fault of their own? Several alternatives were presented back in May. Why was the least interoperable solution kept? Paul Long Smith Micro Software, Inc.

1 0

Re: Pathological bearer cap changes in H.225.0v3
by Pete Cordell 07 Sep '99

07 Sep '99

For the record, I agree with Paul. The rational given for allowing octet 3a is not sufficient to allow backward compatibility with an endpoint conforming to v1, v2. Perhaps it was wrong to not allow octet 3a. It is wrong to allow something that was previously not allowed. Two wrongs don't make a right!!! Just for the record, I think in my implementation, it will be happy to have as many octet 3a, 3b as you care to give it, but will just ignore them. As the standard says there WILL BE NO octet 3as etc, IMO that's quite a legitimate implementation (just a case of being tolerant of what you get). However, as it doesn't know about octet 3as, it will present the information anyway. Thus a valid set of decisions (made without hindsight) doesn't give the results that are desired. How can that be backward compatible??? Pete ============================================= Pete Cordell pete(a)tech-know-ware.com ============================================= -----Original Message----- From: Paul Long <plong(a)SMITHMICRO.COM> To: ITU-SG16(a)MAILBAG.INTEL.COM <ITU-SG16(a)MAILBAG.INTEL.COM> Date: 07 September 1999 20:20 Subject: Re: Pathological bearer cap changes in H.225.0v3 >Bob, > >1. But there has never been a requirement that components of IEs be treated >like actual IEs. Where did this come from? This is a gross rationalization. >The Recommendation clearly states that this octet shall not be encoded. >Therefore, it is perfectly reasonable for an entity to assume that it will >never encounter this octet. Geez, what are standards for? What other >"shalls" will be relaxed in the future? > >2. Even if IE components were to be treated like IEs--which they >cannot--this would still not justify the removal of this requirement. >H.225.0 says only that "unrecognized," e.g., new, IEs shall be ignored, not >that well-known but otherwise clearly prohibited ones shall be ignored, >which is what you are proposing. > >But please prove me wrong. Show me in the H.225.0 Recommendation where it >says that 1. IE components, such as Octet 3a of bearer caps, shall be >treated like IEs and 2. that well-known but otherwise prohibited IEs shall >be ignored. > >BTW, our products in particular are okay in this regard--they will ignore >optional IE fields, even the ones that are prohibited--so I'm not simply >trying rationalize something to keep our products from becoming >non-interoperable due to a bad design decision. It's just that I don't like >the precedent this sets that it's okay to "change the rules once the game >has started." I won't go on about this, though. I'm done. > >Paul Long >Smith Micro Software, Inc. > >-----Original Message----- >From: Callaghan, Robert [mailto:Robert.Callaghan@ICN.SIEMENS.COM] >Sent: Tuesday, September 07, 1999 12:58 PM >To: ITU-SG16(a)MAILBAG.INTEL.COM >Subject: Re: Pathological bearer cap changes in H.225.0v3 > > >Paul, > >The question you present was covered in Santiago. > >The conclusion is that v1 and v2 devices should conform to the >procedures >for information elements that have content that is not understood. For >information elements that are not defined as "must understand" (Calling >party number is in this class) if the contents are not understood, then >the >information element shall be discarded and the connection is completed >without this element. For the calling party number information element, >if >octet 3a is added in order to indicate "presentation restricted" and >this in >not understood; the calling party number ie is discarded and the >connection >is completed without this element. If the element is not present, then >its >contents may not be presented (No problem). > >Bob > >------------------------------------------------------------------ >Robert Callaghan >Siemens Business Communication Systems >Tel: +1.561.997.3756 Fax: +1.561.997.3403 >Email: Robert.Callaghan(a)ICN.Siemens.com >------------------------------------------------------------------ > > >-----Original Message----- >From: Paul Long [mailto:plong@SMITHMICRO.COM] >Sent: Tuesday, September 07, 1999 1:08 PM >To: ITU-SG16(a)mailbag.cps.intel.com >Subject: Pathological bearer cap changes in H.225.0v3 > > >I just took a look at the changes made to H.225.0v3 in Santiago. I >noticed >that whereas octet 3a of Calling Party Number in Bearer caps "Shall not >be >present" in H.225.0v1 and v2, it is allowed in v3! And this apparent >oversight was not rectified in Berlin after discussion on this >reflector. >How will we now guarantee interoperability between v1, v2, and v3+ >entities? >What if some v1 or v2 entities were implemented according to the >Recommendation and do not expect this octet to be present and indeed >will >fail through no fault of their own? Several alternatives were presented >back >in May. Why was the least interoperable solution kept? > >Paul Long >Smith Micro Software, Inc. >

1 0

Most current H.225.0v3 draft?
by Paul Long 07 Sep '99

07 Sep '99

What is the most current draft of H.225.0v3 up for Decision this month? My guess is <ftp://standard.pictel.com/avc-site/9909_Gen/h225v3bcm.doc>. I need to know so that I can be sure I'm using the correct ASN.1 at SuperOp! next week. Thanks, Paul Long Smith Micro Software, Inc.

2 1

Re: Pathological bearer cap changes in H.225.0v3
by Callaghan, Robert 07 Sep '99

07 Sep '99

Paul, The question you present was covered in Santiago. The conclusion is that v1 and v2 devices should conform to the procedures for information elements that have content that is not understood. For information elements that are not defined as "must understand" (Calling party number is in this class) if the contents are not understood, then the information element shall be discarded and the connection is completed without this element. For the calling party number information element, if octet 3a is added in order to indicate "presentation restricted" and this in not understood; the calling party number ie is discarded and the connection is completed without this element. If the element is not present, then its contents may not be presented (No problem). Bob ------------------------------------------------------------------ Robert Callaghan Siemens Business Communication Systems Tel: +1.561.997.3756 Fax: +1.561.997.3403 Email: Robert.Callaghan(a)ICN.Siemens.com ------------------------------------------------------------------ -----Original Message----- From: Paul Long [mailto:plong@SMITHMICRO.COM] Sent: Tuesday, September 07, 1999 1:08 PM To: ITU-SG16(a)mailbag.cps.intel.com Subject: Pathological bearer cap changes in H.225.0v3 I just took a look at the changes made to H.225.0v3 in Santiago. I noticed that whereas octet 3a of Calling Party Number in Bearer caps "Shall not be present" in H.225.0v1 and v2, it is allowed in v3! And this apparent oversight was not rectified in Berlin after discussion on this reflector. How will we now guarantee interoperability between v1, v2, and v3+ entities? What if some v1 or v2 entities were implemented according to the Recommendation and do not expect this octet to be present and indeed will fail through no fault of their own? Several alternatives were presented back in May. Why was the least interoperable solution kept? Paul Long Smith Micro Software, Inc.

2 1

Pathological bearer cap changes in H.225.0v3
by Paul Long 07 Sep '99

07 Sep '99

I just took a look at the changes made to H.225.0v3 in Santiago. I noticed that whereas octet 3a of Calling Party Number in Bearer caps "Shall not be present" in H.225.0v1 and v2, it is allowed in v3! And this apparent oversight was not rectified in Berlin after discussion on this reflector. How will we now guarantee interoperability between v1, v2, and v3+ entities? What if some v1 or v2 entities were implemented according to the Recommendation and do not expect this octet to be present and indeed will fail through no fault of their own? Several alternatives were presented back in May. Why was the least interoperable solution kept? Paul Long Smith Micro Software, Inc.

1 0

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

07 Sep '99

Roberto, Tell me more... Roberto Winkler wrote: > Edgar, all > > thanks for the reply, but I have some more.... > > Again, with reference to the WAU, whose capabilities and role I still don't > quite understand, I don't see how can it 'intercept' messages belonging to > the RAS channel (i.e. addressed to or coming from the Gatekeeper), without > a true redefinition of the whole system. I disagreed with your last statement " without a true redefinition of the whole system". If we designed a system that needs to be redefined everytime we provide a new service then we did something wrong. It may be true for some other systems you are looking at, like G _ _ _ or 3_ _ _. The Radio sub-system WAU is just a (GW) which provides the Radio Control Function (RCF) and bearer connection. It maintains the state of the radio links connections, for a given call, between the a user agent/terminal agent and the network as perceived by the RCF. It establishes, maintains, modifies and releases a radio and fixed line bearer connection between a mobile and the network. The MT to WAU relationship we hope to re-use the Radio technology defined by UMTS/3GPP. The MT to H.323 IP relationship we plan to re-use the H.323 elements and the TIPHON system. > > But, most important, I think that Mr. Martinez's contribution cannot be > appreciated in its entirety without a clear and precise description of the > functionalities and capabilities of the blocks in the proposed reference > architecture, which I feel is missing from the picture as it is now. As a > matter of example, with reference to the WAU, the following items should be > clarified: > - capabilities and functions > - protocol stack > - differences to other Gateways > - differences to Gatekeepers All of the above is already available in one form or another, it has been presented in other contributions I had provided to ITU and WG7. The contributions can modified specificity for the new H.323 Annex H 'user and services mobility" once the framework is agreed on. Plus Annex H it is open for contributions and you or anyone are welcome to provide some. > > > To my humble opinion, this should be the first task to be accomplished, > before aiming at message flows. We need both and will have both, but this is the same old problem that network architects face and everyone has their own opinion. I rather first know from a high level, what we are trying to provide before jumping in to details. Have you ever been asked to "show me a call flow or block diagarm" what you are trying to do? Call flows without the intended protocols message to be used, in a specific system makes little sense to me. Regards, Ed > > > Thanks very much and best regards everybody > > Roberto Winkler > > Roberto Winkler > Senior Researcher > Fondazione Ugo Bordoni > Via B. Castiglione, 59 > 00142 Rome Italy > > tel +39 0654803411 > fax. +39 0654804404 > e-mail wnk(a)fub.it > > ------------------------------------------------------------------- > Mail archive for TIPHON_WG7 can be browsed at the following url : > > http://www.etsi.org/tiphon/mailing.htm > ------------------------------------------------------------------- -- Forwarded -- Subject: Re: H.323 mobility draft Date: Mon, 06 Sep 1999 10:54:19 -0400 From: "Edgar Martinez [1]" <martinze(a)cig.mot.com> Organization: NSS-NAT To: Roberto Winkler <wnk(a)FUB.IT> CC: TIPHON_WG7(a)LIST.ETSI.FR References: 1 Dear Roberto, Thank you for your comments. Responses follow: Roberto Winkler wrote: > hello > I have the following basic questions about the document in subject: > > - what does IMIS mean ? ASN.1 data type IMIS in section 8.5 and the call flows is a typo it will be correct. IMSI ::= TBCD-STRING (SIZE (3..8)) imsi IMIS OPTIONAL (typo in document) should be imsi IMSI OPTIONAL (correction) > > - I have the impression that many message flows in section 8 break the > usual RAS channel definition, because messages that in the 'original' H.323 > are exchanged between endpoint and gatekeeper are now intercepted by WAU, > whose role (and mapping to UMTS architecture) is really unclear to me. > As > an example, there is the GRQ/GCF exchange in 8.2.1.2 > and ARQ/ACF exchanged between WAU and GK in 8.3.1.1. The WAU is not that much different that a MCU or Gateway which may register a single Transport Address or multiple Transport Addresses. To the GateKeeper the WAU will look like (GW) end-point. Of course of we want to support wireless mobility some tweets will have to be done in the H.323 procedures to handle H.323 (MT) wireless or Fixed Terminal mobility. But, it should not beak the under lining core set procedures for basic H.323. > Text from H.323v3 section 7.2.2 http://standard.pictel.com/ftp/avc-site/Incoming/ 7.2.2 Endpoint registration: Registration is the process by which an endpoint joins a Zone, and informs the Gatekeeper of its Transport Address and alias addresses. As part of their configuration process, all endpoints shall register with the Gatekeeper identified through the discovery process. Registration shall occur before any calls are attempted and may occur periodically as necessary (for example, at endpoint power-up). A Gateway or MCU may register a single Transport Address or multiple Transport Addresses. The use of multiple Transport Addresses may simplify the routing of calls to specific ports. An endpoint shall send a Registration Request (RRQ) to a Gatekeeper. This is sent to the Gatekeeper's RAS Channel Transport Address. The endpoint has the Network Address of the Gatekeeper from the Gatekeeper discovery process and uses the well-known RAS Channel TSAP Identifier. The Gatekeeper shall respond with either a Registration Confirmation (RCF) or a Registration Reject (RRJ). See Figure 8. An endpoint shall only register with a single Gatekeeper. The RRQ may be repeated periodically (i.e. at terminal power-up), so the Gatekeeper shall be able to handle multiple requests from the same endpoint. If a Gatekeeper receives an RRQ having the same alias address and the same Transport Address as an active registration previous RRQ, it shall respond with RCF. Snip... Regards, Ed > > > Clarifications are appreciated > > best regards > > Roberto Winkler > > Roberto Winkler > Senior Researcher > Fondazione Ugo Bordoni > Via B. Castiglione, 59 > 00142 Rome Italy > > tel +39 0654803411 > fax. +39 0654804404 > e-mail wnk(a)fub.it > > ------------------------------------------------------------------- > 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/

1 0