Report of Q.5 (mobility) phone conference, December 18th, 200 1
Meyer, Greg W
greg.w.meyer at INTEL.COM
Thu Jan 10 14:58:37 EST 2002
Forwarded per Mr. Roy's request...
From: Roy, Radhika R, ALASO [mailto:rrroy at att.com]
Sent: Wednesday, January 09, 2002 7:16 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,
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.
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.
From: BOUGANT François FTRD/DAC/ISS
[mailto:francois.bougant at RD.FRANCETELECOM.COM]
Sent: Wednesday, January 09, 2002 9:25 AM
To: ITU-SG16 at 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.
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.
More information about the sg16-avd