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

simao.campos at ITU.INT simao.campos at ITU.INT
Fri Mar 9 05:26:24 EST 2007

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:


Best regards,

e-mail: okubo at
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

>-----Original Message-----
>From: neil.seymour at [mailto:neil.seymour at]
>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 Website feedback
>Neil Seymour
>Recommendation H.450.4 cal hold supplementary service
>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 for a Return Error 
>Yours faithfully,
>Neil Seymour

More information about the sg16-avd mailing list