Two new RFCs to keep an eye on for Media Type Registration

[simao.campos at ITU.INT]

Dear Simao and all,

At 16:38 -0500 07/03/08, <simao.campos at 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 at 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 at selex-comms.com [mailto:neil.seymour at 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 at 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