- sg16-avd - lists.packetizer.com

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] 14 Sep '99

14 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 13 Sep '99

13 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