4 Contributions on H246 Annex C and H225.0

Ichiro SEKI seki.ichiro at LAB.NTT.CO.JP
Mon Jan 21 22:38:46 EST 2002


Mr. Roy,

since my company actively promoted the Annex G approach I have no problem
with it. But H.22x would NOT be a NEW protocol, it would still be H.225.0
annex G (v2, to be precise) if used between border elements. The only
"documentation" advantage of a separate recommendation is that for further
applications it may be cleaner to use H.22x than H.225.0 annex G. What we
ought to avoid is that a further application specifies nearly the same
protocol again from scratch.

Regards,
Ernst Horvath 

> -----Ursprüngliche Nachricht-----
> Von: Roy, Radhika R, ALASO [mailto:rrroy at att.com]
> Gesendet am: Freitag, 18. Jänner 2002 17:08
> An: Horvath Ernst; ITU-SG16 at echo.jf.INTEL.COM
> Cc: Meyer, Greg W
> Betreff: RE: Report of Q.5 (mobility) phone conference, December 18th,
> 200 1
> 
> (I would request Mr. Meyer to send the message to the SG16 
> reflector ... and thanks to Mr. Meyer. )
> --------------------------------------------------------------
> ----------
>  
> Hi, Mr. Ernst and All:
>  
> We have seen all pros and cons of all arguments.
>  
> There are some fundamental problems to develop another NEW 
> protocol like "H.22x" among the BEs.
>  
> So, my vote will be for "H.225.0 Annex v2" that will include 
> all mobility features extending H.225.0 Annex G v1.
>  
> Best regards,
>  
> Radhika R. Roy
> rrroy at att.com
> 
> -----Original Message-----
> From: Horvath Ernst [mailto:ernst.horvath at SIEMENS.AT]
> Sent: Friday, January 18, 2002 4:02 AM
> To: ITU-SG16 at echo.jf.INTEL.COM
> Subject: AW: Report of Q.5 (mobility) phone conference, 
> December 18th, 200 1
> 
> 
> 
> We should really try to stop going in circles and come to a 
> conclusion. 
> 
> These are the facts: 
> 
> 1) For a full year the procedures described in H.MMS.1 have 
> been stable; they referred to H.225.0 Annex G, but that was 
> opposed by some participants in the mobility discussion. This 
> was one reason why mobility work progressed slower than expected. 
> 
> 2) In Dublin we found a compromise which did not change the 
> technical solution, just the form of presentation and 
> documentation: the "protocol kernel" should be lifted out of 
> H.225.0 Annex G and turned into an own recommendation. This 
> would allow different applications to make use of this 
> protocol independently and still maintain the protocol in a 
> single document. One application would be H.225.0 Annex G v2, 
> another one mobility management.
> 
> 3) The effect on H.MMS.1 is probably minimal, just a change 
> of reference. 
> 
> 4) Contrary to Mr. Roy's statement there is absolutely no 
> overlap with H.225.0 Annex G since the protocol specification 
> is removed from Annex G and replaced by a reference to H.22x. 
> The protocol itself is fully backwards compatible with Annex 
> G version 1.
> 
> It is now up to the work group to decide how to proceed, 
> either in the present way with an external protocol 
> specification in H.22x or in the former way with the protocol 
> specification integrated in H.225.0 Annex G. In the latter 
> case Annex G version 2 would have to include some extensions 
> needed by H.MMS.1 and H.235 Annex G.
> 
> Whatever the decision will be, H.MMS.1 will hardly be 
> affected. The implications for H.225.0 annex G v2 and H.MMS.0 
> would be bigger: both of these documents will either simply 
> refer to H.22x or contain their own (yet very similar) 
> protocol specification. 
> 
> In any case, we should try our best to finalize H.MMS.1 in 
> February. This means the protcol must be finalized as well, 
> whether it's H.22x or H.225.0 Annex G v2.
> 
> Kind Regards, 
> 
> Ernst Horvath 
> Siemens AG 
> 
> 
> > -----Ursprüngliche Nachricht----- 
> > Von: Meyer, Greg W [ mailto:greg.w.meyer at INTEL.COM] 
> > Gesendet am: Freitag, 11. Jänner 2002 21:35 
> > An: ITU-SG16 at echo.jf.INTEL.COM 
> > Betreff: Report of Q.5 (mobility) phone conference, December 
> > 18th, 200 1 
> > 
> > -----Original Message----- 
> > From: Roy, Radhika R, ALASO [ mailto:rrroy at att.com] 
> > Sent: Friday, January 11, 2002 9:02 AM 
> > To: BOUGANT François FTRD/DAC/ISS; ITU-SG16 at echo.jf.INTEL.COM 
> > Cc: Meyer, Greg W 
> > Subject: RE: Report of Q.5 (mobility) phone conference, 
> December 18th, 
> > 200 1 
> > 
> > 
> > (Mr. Greg Meyer: Kindly forward the mail to the SG16 mailing list.) 
> > 
> > Further to my earlier email, I like to add a summary. The 
> > main reason is 
> > that H.22x is almost a duplicate set of H.225.0 Annex G 
> > protocol except few 
> > parameters related to mobility (what can be done through 
> > extending H.225.0 
> > Annex G). 
> > 
> > Please note that we have developed as modular sets that are 
> > decoupled as 
> > follows: 
> > 
> > H.225.0 RAS - Pre-call setup (among the terminals, GKs, and GWs) 
> > H.225.0 Q.931 - Call setup (among the terminals, GKs, and GWs) 
> > H.225.0 Annex G - among the BEs 
> > H.245 Call/media control (terminals, media-aware GKs, GWs) 
> > 
> > The proposed H.22x overlaps completely with H.225.0 Annex G 
> except few 
> > mobility related parameters. Here lies the fundamental confusions. 
> > 
> > Best regards, 
> > 
> > Radhika R. Roy 
> > rrroy at att.com 
> > 
> > -----Original Message----- 
> > From: Roy, Radhika R, ALASO 
> > Sent: Friday, January 11, 2002 11:42 AM 
> > To: 'BOUGANT François FTRD/DAC/ISS'; ITU-SG16 at echo.jf.INTEL.COM 
> > Cc: 'Meyer, Greg W' 
> > Subject: RE: Report of Q.5 (mobility) phone conference, 
> December 18th, 
> > 200 1 
> > 
> > 
> > (Mr. Greg Meyer: Kindly forward the mail to the SG16 mailing list.) 
> > 
> > Hi, Mr. Francois and All: 
> > 
> > The fundamental arguments have been that a protocol is 
> > defined with its own 
> > characteristics. For example, H.323 protocol has its own 
> entities like 
> > terminals, GKs, BEs, and GWs. Whatever protocol is used by 
> > these entities 
> > among themselves is known as H.323 protocol suit: For 
> > example, H.225.0 Annex 
> > G among BEs. So, the argument is that whatever protocol is 
> > used among the 
> > BEs is known as H..25.0 Annex G. The question is: How can we 
> > define another 
> > protocol like H.22x among the same BEs of H.323? Is it not 
> > contradictory to 
> > the fundamentals for development of the protocol? Will it 
> not confuse 
> > everything? (An analogy: How can we say that let us develop another 
> > protocol, say, H.ZZZ to be used among terminals, GKs, and GWs 
> > in addition to 
> > H.323?) 
> > 
> > The solution that we have been discussed among ourselves is 
> > as follows (I am 
> > providing a copy): 
> > 
> > -------------------------------------------------------------- 
> > -------------- 
> > ------------------------------------------- 
> > 1. We are developing a new protocol where no protocol exists 
> > and the same 
> > can used by all applications to solve the mobility related 
> > problems. For 
> > example, no protocol exits among BE/AMFE, VLF, HLF, and AuF. 
> > Here where we 
> > are defining a new "generic" protocol. This is not specific 
> > to the H.323 
> > protocol. (Whether VLF, HLF, and AuF will be colocated with 
> > the BE/AMFE is a 
> > matter of implementation.) 
> > 
> > 2. We have the H.225.0 Annex G protocol that allows us to 
> > communicate among 
> > the H.323 BEs. This is specific to H.323. All we need to do 
> > is to extend 
> > this protocol to serve our purposes. (An analogy can be 
> > provided. It should 
> > be done in a way what Paul Reddy has done for H.xxx Annex E.) 
> > 
> > 3. We have the H.225.0 (RAS + Q.931) protocol that is used 
> > among the H.323 
> > Terminals, GKs, and GWs. This is specific to H.323. All we 
> > need to do is to 
> > extend this protocol to serve our purposes. (An analogy can 
> > be provided. It 
> > should be done in a way what Paul Reddy has done for H.xxx 
> Annex E.) 
> > 
> > The questions that I have to you all: Why do you want to 
> > develop a generic 
> > protocol (if it is not H.323 specific) for items 2 and 3? If 
> > you want to do 
> > so, how do you definite the generic functional entities like 
> > terminals, GKs, 
> > BEs, GWs, etc? (Please also note that H.324 and H.310 do 
> not have the 
> > concept of functional entities like GKs.) 
> > 
> > My assumption has been that the same (items 2 and 3) can also 
> > be done for 
> > H.324, H.310, or other protocol while all protocols can use 
> the same 
> > "generic" protocol as developed in item 1. 
> > 
> > Please also note that if we develop a "generic" protocol for 
> > items 2 and 3 
> > instead of being making protocol-specific extension, we will 
> > force each 
> > protocol (H.323, H.324, H.310, etc.) to use the DUPLICATE 
> > sets of protocols 
> > (protocol specific + generic) among all its functional 
> > entities. Is it nor 
> > wastage of resources? 
> > 
> > -------------------------------------------------------------- 
> > -------------- 
> > ----------------------------------------- 
> > 
> > It is not that we cannot develop many fency things like 
> H.22x, but it 
> > contradicts the fundamental goals of the protocol development. 
> > 
> > Best regards, 
> > 
> > Radhika R. Roy 
> > rrroy at att.com 
> > 
> > -----Original Message----- 
> > From: BOUGANT François FTRD/DAC/ISS 
> > [ mailto:francois.bougant at RD.FRANCETELECOM.COM] 
> > Sent: Friday, January 11, 2002 10:32 AM 
> > To: ITU-SG16 at echo.jf.INTEL.COM 
> > Subject: Re: Report of Q.5 (mobility) phone conference, 
> December 18th, 
> > 200 1 
> > 
> > 
> > Dear all, 
> > 
> > During the last rapporteur's meeting (Dublin - Ireland), it 
> > was expressed 
> > that defining H.22x (designed on the basis of H.225 annex G 
> v2 at the 
> > current state - the backward compatibility with H.225 annex G 
> > v1 would be 
> > necessary) as a protocol used on BE--BE and BE--{Backend 
> > service entities} 
> > interfaces (other interfaces implying GKs could be 
> > considered) and stopping 
> > H.225 annex G would be a better way than defining a new 
> > protocol used on 
> > BE--{Backend service entities} interfaces and going on H.225 v2. 
> > 
> > A significant argument is : in the latter case, the BE would 
> > support two 
> > application-layer protocols that may evolve separatly in the 
> > future. This 
> > would tend to make BE functionalities harder to implement. 
> > A second one is : if the H.22x "body" includes the H.225 
> > annex G protocol , 
> > it can be used for information exchange on BE--BE interface 
> > even in the 
> > H.323 mobility management context. 
> > 
> > To my understanding, H.22X would not contain any functional 
> > architecture 
> > description. This would be specifically described in every 
> > H.MMS.x draft, 
> > depending on the application context (H.323 specific, etc.). 
> > To give an 
> > example, the definition of generic entities would be 
> > contained in H.MMS.0. 
> > Specific entities such as GKs would be described in H.MMS.1. 
> > Then, mobility management implies a limited set of 
> > information exchanges 
> > that are independants from the application (although the type 
> > of exchange 
> > data depends on the application). These are related to the 
> > same actions at 
> > least : user registration/deregistration, location update, 
> > authentication, 
> > information update (e.g. user service profile transfer, 
> > update), location 
> > information request. So I think it is possible to define a 
> > "simple" generic 
> > protocol. 
> > 
> > Best regards, 
> > 
> > François Bougant 
> > France Telecom 
> > 
> > -----Message d'origine----- 
> > De : Roy, Radhika R, ALASO [ mailto:rrroy at att.com] 
> > Envoyé : mercredi 9 janvier 2002 16:16 
> > À : BOUGANT François FTRD/DAC/ISS; ITU-SG16 at echo.jf.INTEL.COM 
> > Cc : Meyer, Greg W 
> > Objet : RE: Report of Q.5 (mobility) phone conference, 
> December 18th, 
> > 2001 
> > 
> > 
> > Hi, Mr. Francois and All: 
> > 
> > In addition, we also had some email correspondences among the 
> > conference 
> > participants and few interested folks including Mr. Jones and 
> > Mr. Reddy. It 
> > has been opined that H.22x is NOT needed because the 
> extensions of the 
> > existing application-specific protocol (e.g., H.225.0 Annex 
> > G) for mobility 
> > will serve the purpose. 
> > 
> > Copies of the emails are enclosed below. 
> > 
> > Best regards, 
> > 
> > Radhika R. Roy 
> > rrroy at att.com 
> > 
> > PS: I would highly appreciate if Mr. Greg Meyer would send 
> > the email to the 
> > SG16 reflector as you know that I can receive the mail from 
> > the reflector, 
> > but cannot send it because of problems in filtering. 
> > 
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.packetizer.com/pipermail/sg16-avd/attachments/20020121/2d1b1c50/attachment-0001.htm>


More information about the sg16-avd mailing list