Forwarded per Mr. Roy's request... Greg Meyer -----Original Message----- From: Roy, Radhika R, ALASO [mailto:rrroy@att.com] Sent: Wednesday, January 09, 2002 7:16 AM To: BOUGANT François FTRD/DAC/ISS; ITU-SG16@echo.jf.INTEL.COM Cc: Meyer, Greg W Subject: 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@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. -----Original Message----- From: BOUGANT François FTRD/DAC/ISS [mailto:francois.bougant@RD.FRANCETELECOM.COM] Sent: Wednesday, January 09, 2002 9:25 AM To: ITU-SG16@echo.jf.INTEL.COM Subject: Report of Q.5 (mobility) phone conference, December 18th, 2001 Report of Q.5/SG16 (Mobility) conference call on December 18th, 2001 (prepared by Francois Bougant) Participants: Messrs. Gleason (Cisco), Euchner (Siemens), Horvath (Siemens), Reddy (Intel), Roy (AT&T), Bougant (FT). Available documents: New drafts of H.235 Annex G, H.MMS.0 and H.MMS.1; temporary documents TD-EH-01, TD-EH-02, TD-EH-03, TD-EH-04 and TD-FB-02. Results: Most of the time was spent on TD-EH-04 (H.22x draft) 1) the messages defined to ensure security in signalling exchanges have been discussed. It has been proposed to remove the set of definitions related to Access Request/Confirm/Reject messages from H.22x because security requirements on interaces between heterogeneous systems must be identified. Another discussion was about to add optional fields in Service Request/Confirm/reject messages, because such these messages would be used to start a relationship between entities from heterogeneous systems and with different signalling capabilities. Mr. Orvath proposed to make a separate work on these issues. 2) The next discussion was about the version number of ASN.1 coding of H.22x. " The version number is the only real issue. This is an object identifier which contains "itu-t recommendation h 2250 ..." at the moment. Two solutions seem possible: a) Use application specific version numbers. In Annex G V2 the version number will remain "itu-t recommendation h 2250 ...", in H.MMS.x it will use another object-ID root. b) Use the current object identifier (i.e. just increment the version number) for all applications even if they have nothing to do with Annex G." (extracted from TD-EH-04) Contributions are needed to solve this issue. 3) The next discussion was about to extend the current structures (MessageBody choice and message sequences) in order to support additional data and message formats according to H.MMS.0 requirements. It has been notified that the current H.22x design allows these extensions. The next call conference will be on January 25, 2002. Best regards, Francois Bougant France Telecom