- sg16-avd - lists.packetizer.com

Output documents of the Shenzhen meeting
by OKUBO Sakae 19 Mar '07

19 Mar '07

Dear Experts of Q.2,3,4,5,21,22,24,25 and 29/16, Editorial refinement has been made to the output documents of the Shenzhen meeting. Please see the following for the updated list: <http://ftp3.itu.ch/av-arch/avc-site/2005-2008/0703_She/0703_She.html> Please note that the integrated meeting report AVD-3098 and the final list of participants TD-22a will be made available as soon as completed. Document site <http://ftp3.itu.ch/av-arch/avc-site/2005-2008/0703_She/> <ftp://ftp3.itu.int/avc-site/2005-2008/0703_She> User ID: avguest Password: Avguest (Note the uppercase 'A') -- Best regards, OKUBO Sakae e-mail: okubo(a)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 ******************************************************************

1 0

Q1/16 meeting has concluded: report and documents
by Patrick Luthi 15 Mar '07

15 Mar '07

Dear experts, The Rapporteur meeting of Q.1/16 has just concluded. The meeting report can be found here: http://ftp3.itu.int/av-arch/lbc-site/0703_Shenzhen/q1g17.doc The final list of documents is available here: http://ftp3.itu.ch/av-arch/lbc-site/0703_Shenzhen/q1g00r2.doc Best regards, Patrick Luthi Rapporteur for Q.1/16

1 0

Two new RFCs to keep an eye on for Media Type Registration
by simao.campos＠ITU.INT 09 Mar '07

09 Mar '07

They obsolete RFC 3555 - RFC 4855 on Media Type Registration of RTP Payload Formats - RFC 4856 on Media Type Registration of Payload Formats in the RTP Profile for Audio and Video Conferences Cheers, Simão

1 0

Re: FW: ITU Website feedback (Recommendation H.450.4 call hold
by OKUBO Sakae 08 Mar '07

08 Mar '07

Dear Simao and all, At 16:38 -0500 07/03/08, <simao.campos(a)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(a)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(a)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(a)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

1 0

FW: ITU Website feedback (Recommendation H.450.4 cal hold supplementary service)
by simao.campos＠ITU.INT 08 Mar '07

08 Mar '07

Dear all, for your consideration. Simão -----Original Message----- From: neil.seymour(a)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(a)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? I\'ll 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 machine\'s 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

1 0

Documents for the Shenzhen meeting
by OKUBO Sakae 08 Mar '07

08 Mar '07

Dear WP2/16 experts, I have uploaded all the documents submitted so far. They are available at the following place: Site <http://ftp3.itu.ch/av-arch/avc-site/2005-2008/0703_She/> <ftp://ftp3.itu.int/avc-site/2005-2008/0703_She> User ID: avguest Password: Avguest (Note the uppercase 'A') Document list <http://ftp3.itu.ch/av-arch/avc-site/2005-2008/0703_She/0703_She.html> Please note that TD-01 <http://ftp3.itu.ch/av-arch/avc-site/2005-2008/0703_She/TD-01.zip> contains initial timetables for the meeting in two rooms. Please also note that some documents have been revised with "a" in the document number. -- Best regards, OKUBO Sakae e-mail: okubo(a)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 ******************************************************************

1 0

Documents for the next week meeting of Q.1
by Patrick Luthi 07 Mar '07

07 Mar '07

Dear experts, Almost all meeting documents have been posted: http://ftp3.itu.int/av-arch/lbc-site/0703_Shenzhen ftp://ftp3.itu.int/lbc-site/0703_Shenzhen user: avguest, password: Avguest The list of documents is available here: http://ftp3.itu.ch/av-arch/lbc-site/0703_Shenzhen/q1g00r1.doc Best regards, Patrick Luthi Rapporteur for Q.1/16

1 0

Re: Documents for the Shenzhen meeting
by OKUBO Sakae 06 Mar '07

06 Mar '07

Dear all, At 21:18 -0500 07/03/05, OKUBO Sakae wrote: >At this moment, it looks the server (ftp3.itu.int) is down. I have >sent a trouble report to TSB. I cannot check the documents uploaded >to the /Incoming after Monday 14:00 UTC. I also cannot upload those >documents received by e-mail. I expect the access to the server will >recover when the people come to the office in Geneva. Now the server is working. I have uploaded all (as far as I believe) the submitted documents to the Shenzhen meeting directory. Please check the site and advise me if anything is wrong with your document. Site <http://ftp3.itu.ch/av-arch/avc-site/2005-2008/0703_She/> <ftp://ftp3.itu.int/avc-site/2005-2008/0703_She> User ID: avguest Password: Avguest (Note the uppercase 'A') Document list <http://ftp3.itu.ch/av-arch/avc-site/2005-2008/0703_She/0703_She.html> -- Best regards, OKUBO Sakae e-mail: okubo(a)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 ******************************************************************

1 0

Documents for the Shenzhen meeting
by OKUBO Sakae 05 Mar '07

05 Mar '07

Dear experts of Q2,3,4,5,21,22,24,25,29, At this moment, it looks the server (ftp3.itu.int) is down. I have sent a trouble report to TSB. I cannot check the documents uploaded to the /Incoming after Monday 14:00 UTC. I also cannot upload those documents received by e-mail. I expect the access to the server will recover when the people come to the office in Geneva. The most recent list of the documents (without reflecting those at /Incoming) is attached for your information. -- Best regards, OKUBO Sakae e-mail: okubo(a)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 ******************************************************************

1 0

Re: [WP2/16] Proposals to Q21 and Q22[AVD-3081 3082 3083].
by OKUBO Sakae 05 Mar '07

05 Mar '07

Dear Dong WANG, This is to acknowledge the receipt of your 3 documents. I will uploade them to the Shenzhen meeting directory as soon as the connection to the server has recovered (it looks down at the moment). -- Best regards, OKUBO Sakae e-mail: okubo(a)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 ******************************************************************

1 0