Dear Simao and all, At 16:38 -0500 07/03/08, <simao.campos@ITU.INT> wrote:

for your consideration.

This message has been uploaded as TD-25 of the Shenzhen meeting to the avc-site: <http://ftp3.itu.ch/av-arch/avc-site/2005-2008/0703_She/TD-25.zip> Best regards, OKUBO Sakae e-mail: okubo@aoni.waseda.jp Visiting Professor Global Information and Telecommunication Institute (GITI) Waseda University ****************************************************************** Waseda University, YRP Ichibankan 312 Tel: +81 46 847 5406 3-4 Hikarinooka, Yokosuka-shi, Kanagawa-ken Fax: +81 46 847 5413 239-0847 Japan H.323 videoconferencing: arranged by advice ******************************************************************

Sim黍

-----Original Message----- From: neil.seymour@selex-comms.com [mailto:neil.seymour@selex-comms.com] Sent: mercredi, 7. mars 2007 17:10 To: Sales, ITU; Sales, ITU Subject: [form2email] ITU Website feedback (recommendation H.450.4 cal hold supplementary service) Importance: High This mail has been sent from the ITU web site to sales@itu.int : Subject ITU Website feedback

UserLanguage English MessageType Suggestion Name Neil Seymour Subject Recommendation H.450.4 cal hold supplementary service Comments

I have some suggestions/corrections to submit regarding H.450.4. Perhaps you would be kind enough to forward this to the appropriate department as necessary? Ill start with a very minor suggestion: 1) It might be better to title section 11 as Dynamic description for call hold because sub-section 11.1.1 covers Near-end call hold and 11.1.2 covers Remote-end call hold, thus section 11 covers both near-end and remote-end call hold. 2) If a new state called Hold_RE_Holding were introduced, this could simplify a state machines implementation because it would prevent a held User retrieving the held call because the remoteRetrieve.req would then only be accepted when in the Hold_RE_Holding state. Thus only the served user would be able to retrieve the call. 3) Figure 18a refers to state Hold_RE_Held at the holding side and shows that if the served endpoint sends a remoteHold.req primitive then the state changes to Hold_RE_Retrieve_Req even though call retrieval has not been requested! I would have anticipated that the state would remain unchanged and so the state machine would still be waiting to receive a valid remoteRetrieve.req primitive. 4) Figure 18b in the central branch receives a remoteRetrieve.rr message. (This eventuality is already covered by the left hand branch.) It ought to say remoteRetrieve.re for a Return Error APDU.

Yours faithfully, Neil Seymour