- sg16-avd - lists.packetizer.com

List of contributions for the Ottawa meeting of Q.1/16
by Patrick Luthi 20 Aug '06

20 Aug '06

Dear Q.1/16 experts, The deadline to register contributions was last night at 23.59 and this is the current list of registered contributions for the Ottawa meeting (29-31 August 2006). The deadline for submitting your contributions is 23:59 UTC on Tuesday 22 August 2006. The documents will be available through this URL: http://ftp3.itu.int/av-arch/lbc-site/0608_Ottawa/ Please advise me if your contribution is not listed here: Q1-F00 Q1/16 Rapporteur List of Documents for Meeting F of the ITU-T SG16 Q.1 Experts Group Q1-F01 Nortel Invitation for Questions 1,2,3,4,5,21,22,24,25,29 Experts Group in Ottawa, Canada --> Ott_Invitation.doc Q1-F02 Q1/16 Rapporteur Meeting announcement for Meeting F of Q.1/16 Experts Ottawa, Canada, 29-31 August 2006 Q1-F03 Q1/16 Rapporteur Meeting report of Working Party 2 of ITU-T Study Group 16, Geneva, 3-13 April 2006 Q1-F04 AHG Chair Report of the H.324 text conversation Ad-hoc Group Q1-F05 Editors Draft new H.gamma Q1-F06 Editor Draft new H.324 Annex Text Conversation Q1-F07 Editor Draft revised T.120 Q1-F08 Editor Draft revised T.123 Q1-F09 France Telecom Videotelephony Requirements Q1-F10 Polycom Comments on Videotelephony Requirements Q1-F11 NEC Comments and proposed clarifications to H.324 Annex K Q1-F12 PacketVideo H.324 Annex K - Some issues for discussion I am looking forward meeting with you in Ottawa next week. Best regards, Patrick Luthi Rapporteur for Q.1/16

1 0

Document numbers allocated
by Paul E. Jones 19 Aug '06

19 Aug '06

Dear Experts, I have assigned all document numbers to those who have requested numbers. If you sent an e-mail requesting a number, but did not get a reply, please re-submit your request. We presently have more than 100 documents registered for this meeting, so we will be quite busy during this meeting. I will get a final document list posted within 36 hours. I will post all of the documents I have received either via e-mail or via the FTP server this weekend. All other documents will be posted within 24 hours, so all documents should be posted by Tuesday morning in Asia. I have a couple of incoming liaison statements that may be a little delayed, but I'll try to get those posted as soon as possible. Paul

1 0

RE: 1 more; RE: Further numbers; Re: Document number requests
by Paul E. Jones 19 Aug '06

19 Aug '06

Albrecht, Please use AVD-2940. Thanks! Paul > -----Original Message----- > From: Albrecht.Schwarz(a)alcatel.de [mailto:Albrecht.Schwarz@alcatel.de] > Sent: Friday, August 18, 2006 9:31 AM > To: Paul E. Jones > Subject: 1 more; RE: Further numbers; Re: Document number requests > > > Paul, > > we got a last Alcatel contribution: > > AVD-29xx "H.Sup7.CtrlAssoc ?§ 6.2.3 ServiceChange.reply inclusive > ServiceChangeMgcID" > > Thanks > Albrecht

1 0

RE: Request for Document Number AVD-nnnn allocation in ITU-T SG16 WP2 Expert Meeting
by Paul E. Jones 19 Aug '06

19 Aug '06

Kang, Please use AVD-2938 and AVD-2939 for the documents as you have them listed. Paul > -----Original Message----- > From: ??? [mailto:tgkang@etri.re.kr] > Sent: Friday, August 18, 2006 7:03 AM > To: paulej(a)packetizer.com > Cc: ??? > Subject: Request for Document Number AVD-nnnn allocation in ITU-T SG16 WP2 > Expert Meeting > > Hello, > > I would like to send you two document titles for their Document Number > AVD-nnnn allocation. > > 1. Document AVD-xxxx, > Title: A Proposal on Codec Negotiation across Multiple Networks for > End-to-End QoS > Question: 24/16 > Source: ETRI > > 2. Document AVD-yyyy, > Title: A Proposal on Veriable Codec Bit Rates Control for End-to-End > QoS > Question: 24/16 > Source: ETRI > > Please, could you allocate the two documents number(AVD-xxxx and AVD-yyyy) > for me ? > > with best regards > > Kang > ---------------------------------- > ETRI, Multimedia Communications Team > BcN Core Technology Group > Broadband Convergence Network Research Division > Principal Member of Engineering Staff > Ph.D, Professional Engineer > Kang Tae-Gyu > tgkang(a)etri.re.kr <mailto:tgkang@etri.re.kr> > +82-42-860-5232, FAX:+82-42-860-5440, 016-451-2968 > ---------------------------------- >

1 0

RE: [rac] Audio T.140 evaluation?
by Paul E. Jones 19 Aug '06

19 Aug '06

Arnoud, I feel compelled to reply to just one point: If Paul wants audio/t140c so much Personally, I do not care whether audio/t140c or text/t140 is adopted as the industry standard. It makes absolutely no difference to me, as I view both as a viable means of delivering real-time text in a way that we can use it. What has mattered to me is delivering real-time text capability at all, which was incredibly hard in the face of constant customer requests for instant messaging. Ive given both technical and business reasons why text/t140 cannot be universally deployed today and the near future. Ive given other business reasons why text/t140 is not favored presently (cost factors). Working within those constraints, I wrote the audio/t140c document. I might be blamed for creating something evil (and I have been accused of trying to screw over deaf people), but the truth is that I tried to create something that is a stepping stone that will allow us to deploy RTT universally and will not exclude legacy TTY devices: the roadmap that I have proposed is easier (and therefore more likely to succeed) than taking the bigger leap to text/t140, in my opinion. (Note: text/t140 is now 6 years old, so I do not think my assessment is wrong.) Ive said before that I think text/t140 is where we want to be. How do you suggest we get there? 1) We can simply demanding text/t140 support on platforms. Some platforms cannot support it. Some platforms could support it, but would require coordination with other products that also need to implement it (e.g., softswitches, firewalls, NAT devices, and policy enforcement devices). You end up having an end-to-end tug of war between product teams who wait for the others to take the first step. Worse, you isolate anybody using a technology that simply cannot do it. (How long until the last MGCP or NCS gateway is decommissioned?) 2) Shall we demand that service providers deploy special text gateway devices and just use V.152 to those gateways? (That pushes all of the cost and burden onto the service provider, rather than GW vendors. However, it also presents special dialing requirements or line provisioning requirements. For reasons that would require another full page of text, I will say this will not work unless we remove the requirement that users be able to go anywhere with their TTY devices.) 3) Shall we just forget about TTY devices and move everybody to IP, letting those with TTY devices just limp along until such time as theyre tired of being isolated or things not working part of the time? Other ideas? Paul _____ From: Arnoud van Wijk [mailto:arnoud@annies.nl] Sent: Friday, August 18, 2006 6:02 AM To: Rac(a)lists.wisc.edu Subject: RE: [rac] Audio T.140 evaluation? And that is so absolutely true. Audio/t140c is a very dangerous genie that is almost out of the bottle now. And once deployed outside its limited purpose, we will get a big mess with fragmentation dangers. You only have to look at what has happened to the different text telephone protocols, or the different IM protocols. If it is up to me, I want audio/t140c erased from existence. It will be hard enough to get text/t140 deployed. Now as I always say, audio/t140c is ok in gateway-gateway connections. IP terminals must never be mandated to support audio/t140c. Audio/y140c could be added as a special PSTN functionality. But such IP terminal MUST have text/t140. What about gateways? They must support text/t140 and if they wantaudio/t140c. You will get a number of scenarios all from IP side starting: (gateway supports both text/t140 and audio/t140c) 1. call has audio/t140c and text/t140 in the SDP, nice for the gateway, it selects audio/t140c. No issue here. 2. call has text/t140 in the SDP plus an indicator that text must be used. No issues here. 3. call has text/t140 in the SDP, there is no indicator if text must be used. There are a few possibilities: a: set up text in a reinvite if a key or text telephony is detected. b: set up text/t140 port anyway and close this port if no text input is detected after 60 seconds, it can always then reinvite for text if any text is detected later. So, if Paul wants Audio/t140c so much. OK but only mandate gateways to support both. Text/140 is the universal lina franca real-time text protocol and will also be set for interconnectivity between any text to any text networks. With the coming of WiMax, rural areas will be able to get high speed internet. Sprint is starting to roll out such network. The range is 50 kilometers in rural areas and 2-3 kilometers in cities. So this is quite promising. TTY users should be one of the first to switch then. Perhaps that is the best way to investigate where the move to IP is impossible. Perhaps we can mandate in the US that ToIP must be able to pass through any operators network, and find a way to ensure we have ata boxes for TTY connectivity. Such box can support audio/t140c and text/t140. Just my 2 cents and a bit. Arnoud A. T. van Wijk AnnieS New Technology <http://www.AnnieS.nl> www.AnnieS.nl Mobile textphone (SIP): <mailto:arnoud@annies.nl> arnoud(a)annies.nl _____ From: Gunnar Hellstrom [mailto:gunnar.hellstrom@omnitor.se] Sent: donderdag 17 augustus 2006 21:34 To: Norman Williams; Rac(a)Lists.Wisc.Edu Subject: RE: [rac] Audio T.140 evaluation? Norman, I hope you will get a sample, and a gateway to use it with. audio/t140c should have very good opportunities to work well, at least for pure text and for alternating text and voice. And that is as far as it needs to be used with the applications that are proposed. As usual, there are many opportunities to do the application integration with different ambition levels. If you find issues, they may have a source in the surrounding software or environment but not in the standard itself. The issues are more on an IP service architecture plane. You simply should not call other media "audio" just for sake of convenience even if it seems to work. We got the RFC classified "historic", and we had to put in a lot of words about how the use was restricted to gateway applications. This is a copy of the words we got from the IETF area director Allison Mankin explaining why it got deemed "historic" from the beginning: --------------------------------------------------------- Gunnar, Paul, t140c was approved today, with the IESG finding it in perfect shape. The only discussion was about the Historic designation. We discussed the Last Call comments, the GEN-ART comment, and my rationale (including the announcement text I wrote in the tracker and my report on the Chairs' views). First, congratulations to you both on the excellent quality of the document as a document. It made it easy to work with. The purpose of making it Historic is not to condemn trunking gateways, it is to avoid setting precedent with a PS for calling text data an audio type. This document does so due to implementation pressures of SDP in these gateways. RFC 4103 has the example (text/t140) we want people to follow. The impact of going to Historic should not block the goals you and Paul have described: the payload specification is in an RFC-to-be, the media type being registered with no blockage from any media experts (which it would have gotten with a different designation on the document!). There is no internal text that says the RFC is Historic. So the only meaning of this designation is for later, when someone pops up with an audio major type with data that is not audio, the AVT or other working group can press back for a very tight applicability statement and cite precedent, or if there's no deployment, ask them to go to a different design. A few more bits inline. I hope this is more understandable now. Let me underline again the point about the problem of media type expert review if we had not gone Historic. With my best regards, Allison --------------------------------------------------------------- I find it very hard to go against these words and strt to use it between terminals. I find it easy and perfectly OK to use it between gateways. To use it between gateways and terminals is a grey area. The words in the RFC does not totally forbid that application, even if it is clearly stated that the intention is for trunking gateways. However accepting it between gateways and terminals makes the idea of media declarations in SIP collapse and the architecture of IP múltimedia to become a mess. I do not want to contribute to that. These issues will not be visible when you try it, but certainly something we, as a global advisory group will need to consider. Gunnar ---------------------------------------------------------------------------- - Gunnar Hellström, Omnitor gunnar.hellstrom(a)omnitor.se Mob: +46 708 204 288 Phone: +46 8 556 002 03 www.omnitor.se -----Original Message----- From: Norman Williams [mailto:norman.williams@gallaudet.edu] Sent: Thursday, August 17, 2006 8:19 PM To: Rac(a)Lists.Wisc.Edu Subject: [rac] Audio T.140 evaluation? Hi, I forgot to bring this topic to the phone conference we had recently. Is there a way for us to evaluate audio T.140 to see if there are issues? Do we have a working audio T.140 solution? Norman --- You are currently subscribed to rac as: gunnar.hellstrom(a)omnitor.se. To unsubscribe click here: https://lists.wisc.edu/u?id)14436N&n=l=c&o455168 or send a blank email to leave-3455168-2914436N(a)lists.wisc.edu --- You are currently subscribed to rac as: arnoud(a)annies.nl. To unsubscribe click here: https://lists.wisc.edu/u?id)14433R&n=l=c&o456252 or send a blank email to leave-3456252-2914433R(a)lists.wisc.edu --- You are currently subscribed to rac as: paulej(a)packetizer.com. To unsubscribe click here: https://lists.wisc.edu/u?id)14439J&n=l=c&o463578 or send a blank email to leave-3463578-2914439J(a)lists.wisc.edu --- You are currently subscribed to rac as: paulej(a)packetizer.com. To unsubscribe click here: https://lists.wisc.edu/u?id)14439J&n=T&l=rac&o474178 or send a blank email to leave-3474178-2914439J(a)lists.wisc.edu

1 0

RE: Document number allocation request
by Paul E. Jones 18 Aug '06

18 Aug '06

Takashima-san, Please use AVD-2935. Thanks! Paul > -----Original Message----- > From: youichi.takashima(a)ubin.jp [mailto:youichi.takashima@ubin.jp] > Sent: Friday, August 18, 2006 4:33 AM > To: Paul Jones > Cc: Noboru Koshizuka; Ishikawa, Chiaki > Subject: Document number allocation request > > Dear Paul, > > Could you allocate a document number to the following contribution? > > Source: YRP Ubiquitous Networking Laboratory > Title: Analysis of Information Delivery Applications using Networked ID > Question: 22 > > This is a "proposal" document. > > Best regards, > ---------------------------------------------------------------------- > Youichi TAKASHIMA > YRP Ubiquitous Networking Laboratory > Phone +81 3 5437 2270 > Facsimile +81 3 5437 2329 > 2-20-1 Nishi-Gotanda, Shinagawa-ku, Tokyo 141-0031 JAPAN > >

1 0

Document number allocation request
by youichi.takashima＠ubin.jp 18 Aug '06

18 Aug '06

Dear Paul, Could you allocate a document number to the following contribution? Source: YRP Ubiquitous Networking Laboratory Title: Analysis of Information Delivery Applications using Networked ID Question: 22 This is a "proposal" document. Best regards, ---------------------------------------------------------------------- Youichi TAKASHIMA YRP Ubiquitous Networking Laboratory Phone +81 3 5437 2270 Facsimile +81 3 5437 2329 2-20-1 Nishi-Gotanda, Shinagawa-ku, Tokyo 141-0031 JAPAN

1 0

RE: LSs from SG11 and TIPSAN; Re: Document number requests
by Paul E. Jones 18 Aug '06

18 Aug '06

If they get posted, I will grab them. Otherwise, do you think it will present an issue if we do not review them until the November meeting? Paul > -----Original Message----- > From: Albrecht.Schwarz(a)alcatel.de [mailto:Albrecht.Schwarz@alcatel.de] > Sent: Thursday, August 17, 2006 10:17 AM > To: Paul E. Jones > Cc: itu-sg16(a)external.cisco.com > Subject: RE: LSs from SG11 and TIPSAN; Re: Document number requests > > > Both meetings took place in July. > Don't know the LS handling process by the EDH. > Would be surprised if they were not already in the pipeline. > - Albrecht > > > > > "Paul E. Jones" > <paulej@packetiz To: Albrecht > SCHWARZ/DE/ALCATEL@ALCATEL > er.com> cc: <itu- > sg16(a)external.cisco.com> > Subject: RE: LSs from SG11 > and TIPSAN; Re: Document number requests > 17.08.2006 15:50 > > > > > > Albrecht, > > I have been watching the liaison statements that have been made available > for SG16 since the last meeting. > > I did not see these. Were those just released? > > Paul > > > -----Original Message----- > > From: Albrecht.Schwarz(a)alcatel.de [mailto:Albrecht.Schwarz@alcatel.de] > > Sent: Thursday, August 17, 2006 5:49 AM > > To: Paul E. Jones > > Cc: itu-sg16(a)external.cisco.com > > Subject: LSs from SG11 and TIPSAN; Re: Document number requests > > > > > > Paul, > > this email is only fyi. > > I'm aware of 3 LSs from SG11 & ETSI, submitted to Q.3 and Q.23 (see > > below), > > which are not yet in our Ottawa contributions list. > > Guess that the LSs will appear as GEN-xxx-16 input sometime. > > > > Regards, Albrecht > > > > > > > > Reference: T05-SG11-060724-TD-PLEN-0105!!MSW-E > > > |-------+-----------+----------------------+------------------------ > > ------------------| > > | 1 | 3/11 | ITU-T SG 16 (Q.23/16)|Media Codec > requirements > > in NGN | > > > |-------+-----------+----------------------+------------------------ > > ------------------| > > | 2 | 5/11 | ITU-T SG 16 (Q.3/16) |H.248 items related to > > Draft ITU-T Rec. | > > | | | |Q.rcp3.2 "H.248 Rw > > Profile" | > > > |-------+-----------+----------------------+------------------------ > > ------------------| > > > > > > > > > > > > ETSI reference: 11TD045; > > > > http://docbox.etsi.org/tispan/tispan/50-20060711-Sophia- > > P11/11TD045%20LSreply_to_ITUTSG16_on_H248packages.doc > > > > > > > > > > > > > > >

2 1

RE: Request for AVD number
by Paul E. Jones 17 Aug '06

17 Aug '06

Dave, Please use AVD-2932. Thanks! Paul > -----Original Message----- > From: Dave Lindbergh [mailto:lindbergh@92F1.com] > Sent: Thursday, August 17, 2006 10:22 AM > To: Paul Jones > Subject: Request for AVD number > > Question(s): 1, 2, 21 > > Source*: Polycom, Inc. > > Title: Comments on Videotelephony Requirements > > Purpose: Discussion > > > ---------- > Dave Lindbergh > Polycom, Inc. > 100 Minuteman Road > Andover MA 01810 USA > Voice: +1 978 292 5366 > Video: +1 978 292 2004 > Email: lindbergh(a)92F1.com >

1 0

RE: LSs from SG11 and TIPSAN; Re: Document number requests
by Albrecht.Schwarz＠alcatel.de 17 Aug '06

17 Aug '06

Both meetings took place in July. Don't know the LS handling process by the EDH. Would be surprised if they were not already in the pipeline. - Albrecht "Paul E. Jones" <paulej@packetiz To: Albrecht SCHWARZ/DE/ALCATEL@ALCATEL er.com> cc: <itu-sg16(a)external.cisco.com> Subject: RE: LSs from SG11 and TIPSAN; Re: Document number requests 17.08.2006 15:50 Albrecht, I have been watching the liaison statements that have been made available for SG16 since the last meeting. I did not see these. Were those just released? Paul > -----Original Message----- > From: Albrecht.Schwarz(a)alcatel.de [mailto:Albrecht.Schwarz@alcatel.de] > Sent: Thursday, August 17, 2006 5:49 AM > To: Paul E. Jones > Cc: itu-sg16(a)external.cisco.com > Subject: LSs from SG11 and TIPSAN; Re: Document number requests > > > Paul, > this email is only fyi. > I'm aware of 3 LSs from SG11 & ETSI, submitted to Q.3 and Q.23 (see > below), > which are not yet in our Ottawa contributions list. > Guess that the LSs will appear as GEN-xxx-16 input sometime. > > Regards, Albrecht > > > > Reference: T05-SG11-060724-TD-PLEN-0105!!MSW-E > |-------+-----------+----------------------+------------------------ > ------------------| > | 1 | 3/11 | ITU-T SG 16 (Q.23/16)|Media Codec requirements > in NGN | > |-------+-----------+----------------------+------------------------ > ------------------| > | 2 | 5/11 | ITU-T SG 16 (Q.3/16) |H.248 items related to > Draft ITU-T Rec. | > | | | |Q.rcp3.2 "H.248 Rw > Profile" | > |-------+-----------+----------------------+------------------------ > ------------------| > > > > > > ETSI reference: 11TD045; > > http://docbox.etsi.org/tispan/tispan/50-20060711-Sophia- > P11/11TD045%20LSreply_to_ITUTSG16_on_H248packages.doc > > > >

1 0