- sg16-avd - lists.packetizer.com

RE: Outcome of the San Jose meeting (H.245)
by mike.nilsson＠BT.COM 24 Sep '04

24 Sep '04

I have uploaded a new version of H.245 (H245WCMY.zip) to the avc site incoming directory. Please review this for consistency with the decisions made at the San Jose meeting. Best regards Mike -------------------- Mike Nilsson Multimedia Analysis and Coding Sirius House (B54-MH), Room 124 Adastral Park, Martlesham Heath, Ipswich, IP5 3RE, UK Tel: +44 1473 645413 Mobile: +44 7808 635412 Fax: +44 1908 862365 Email: mike.nilsson(a)bt.com British Telecommunications plc Registered office: 81 Newgate Street London EC1A 7AJ Registered in England no. 1800000 This electronic message contains information from British Telecommunications plc which may be privileged and confidential. The information is intended to be for the use of the individual(s) or entity named above. If you are not the intended recipient, be aware that any disclosure, copying, distribution or use of the contents of this information is prohibited. If you have received this electronic message in error, please notify us by telephone or email (to the number or address above) immediately. Activity and use of the British Telecommunications plc email system is monitored to secure its effective operation and for other lawful business purposes. Communications using this system will also be monitored and may be recorded to secure effective operation and for other lawful business purposes. -----Original Message----- From: OKUBO Sakae [mailto:okubo@mxz.mesh.ne.jp] Sent: 04 September 2004 06:57 To: itu-sg16(a)external.cisco.com Subject: Outcome of the San Jose meeting Dear WP2/16 experts, The San Jose meeting of Questions F, G, K, 1-5/16 has successfully finished with participation of 29 experts. I would like to thank all the participants for their contributions as well as Cisco Systems for kindly hosting this meeting. The outcome of the meeting can be found at the following place: http://ftp3.itu.int/av-arch/avc-site/0408_San/ ftp://avguest:Avguest@ftp3.itu.int/avc-site/0408_San/ or ftp://ftp3.itu.int/avc-site/0408_San/ user: avguest password: Avguest Q.F report -- TD-10a Q.G report -- TD-11a Q.K report -- TD-12 Q.2 report -- TD-13a Q.3 report -- TD-14a Q.4 report -- TD-15 Q.4 report -- TD-16a General topics -- TD-55a List of outgoing liaison statements -- TD-57 (Note: Document list -- TD-02) They will be integrated and issued as AVD-2586. Please note that Q.1 report can be found at the following place: http://ftp3.itu.int/av-arch/lbc-site/0408_Sanjose/q1c19r1.doc ftp://avguest:Avguest@ftp3.itu.int/lbc-site/0408_Sanjose/q1c19r1.doc or ftp://ftp3.itu.int/lbc-site/0408_Sanjose/q1c19r1.doc user: avguest password: Avguest Best regards, OKUBO Sakae e-mail: sokubo(a)waseda.jp Visiting Professor Graduate School of Science and Engineering 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 SG16 meeting in November
by OKUBO Sakae 24 Sep '04

24 Sep '04

Dear SG16 experts, Related to Mr. Li's posting on draft requirements for NAT traversal of H.323 multimedia systems, you have seen the following message from Mr. Campos-Neto, ITU-TSB about the submission of your contributions to the SG16 (SGF or whatever) meeting in November: At 15:08 +0200 04/09/21, simao.campos(a)itu.int wrote: >please note that as the next Q.5 meeting will take place in November >04 as part of the main SG 16 meeting, any documents to be reviewed >at the meeting must be submitted using the formal submission >procedures of contributions (at this point in time, actually >"delayed" contributions), in your case I believe through the Chinese >administration. Please take a look at TSB Collective Letter 8/16 >announcing the SG 16 meeting (see >www.itu.int/md/meetingdoc.asp?type=sitems&parent=T01-SG16-COL-0008) > >Of course, the version you emailed can be discussed in the email >reflector, which is a positive factor towards progressing the work. >But as I said, for the proposal to be seen at the SG 16 meeting it >would need to be submitted formally through the appropriate channels. Submission to ITU-TSB through your national channel is a mandatory process for the meeting in November. Optionally, you are also encouraged to make your documents, even their drafts, available at the avc-site for earlier review and discussion by the experts. For this purpose, I have prepared the following directory: http://ftp3.itu.int/av-arch/avc-site/2001-2004/0411_Gen/ and taken my liberty to place Mr. Li's draft there as Draft_H.fwreq_040921.zip. -- Best regards, OKUBO Sakae e-mail: sokubo(a)waseda.jp Visiting Professor Graduate School of Science and Engineering 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

Reorganization of directories
by OKUBO Sakae 24 Sep '04

24 Sep '04

Dear avc-site users, I have reorganized the avc-site <http://ftp3.itu.int/av-arch/avc-site/> with the following directories: 1993-1996/ 1997-2000/ 2001-2004/ 2005-2008/ It means that the document location becomes one directory deeper. For example, the recent San Jose meeting documents are now available at: http://ftp3.itu.int/av-arch/avc-site/2001-2004/0408_San/ instead of http://ftp3.itu.int/av-arch/avc-site/0408_San/. This action has been taken to allow unchanging links to the stored documents. There is a short description of this site at: http://ftp3.itu.int/av-arch/avc-site/0-about_this_site.txt -- Best regards, OKUBO Sakae e-mail: sokubo(a)waseda.jp Visiting Professor Graduate School of Science and Engineering 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: Call Diversion Override
by Mpierce1＠AOL.COM 22 Sep '04

22 Sep '04

In a message dated 9/19/2004 2:16:17 PM Eastern Standard Time, lilo(a)nullpointer.de writes: > Take an ACD system as an example: Someone calls the system, which in > turn alerts a group of users. As soon as one of those users picks up > the phone, the other calls that were generated are disconnected > automatically. > > Something as simple as a CFNR to a voicemail system might disrupt > operation of this service, as now the voicemail system will pick up the > call. > [MAP] I'm confused by your example. This is not what I think of as an "ACD" system. I think it goes by a different name. I understand such a service might be used for emergency notification, where the desire is to reach the first person who will answer. Anyway, here again, the desire is to prevent an answering machine/voicemail system from answering, which I understand. It is not to prevent forwarding. If I am one of the intended recipients of such as service, I may activate Call Forwarding Unconditional or Busy because I want such calls forwarded to where I am or to another phone on my desk. If I know that my number is on such a calling list (maybe for emergency notification), then it is my responsibility to ensure that calls to it will not be answered by a machine. ------------------------------------------------------------------------------ ------------------------------ > By using CDOR, the call distribution system could indicate to the called > group of endpoints, that no diversion to a voicemail system would be > allowed for this call. Still, it could indicate, that it wishes > diversions to other users to take place. So, this would not impede any > normal operations. > [MAP] If the desire is to prevent answering by a voicemail system, then lets work on that specific problem. In general, systems do not know whether they are forwarding to another person or to an answering service. ------------------------------------------------------------------------------ --------------------------------------------- > It's clear that a diverting entity doesn't always know if the call is > forwarded to another subscriber or to a voicemail system. Certainly, > CDOR wouldn't be too useful in such an environment. But there are > highly integrated telephony systems, where this is known in advance -- > and CDOR would provide users with means to utilize this information to > their advantage. > [MAP] My argument is that it doesn't work in a system that doesn't know that a call is being forwarded to voicemail, and a system that does know this probably isn't really doing "Call Forwarding". So it's not a "Diversion Override" service. It's a "prevent voicemail" service. ------------------------------------------------------------------------------ --------------------------------------------- > CDOR doesn't state what happens, if a diversion is inhibited. It's > possible to either continue to alert the user or to clear the call. > (There's a special message defined for the latter case.) > [MAP] Part of the objection was based on specific operation described in Section 9.2.1 which says "the called endpoint ... instead alerts the called subscriber" (instead of invoking Call Forwarding or releasing the call). It then says the call is cleared by the calling endpoint "due to the callled subscriber not responding". I presume this means the calling person hangs up when the called person does not answer. That is, the called person who turned on Call Forwarding Unconditional still gets rung. ------------------------------------------------------------------------------ ------------------------------------------------- > So, as it was before, the full control still lies with the called > endpoint (or the Gatekeeper working on behalf of it), there's just an > option for the caller to indicate preference. > [MAP] Then I suggest that the only data to include in the SETUP is things like: Prefer not to be answered by voicemail Prefer not to be answered by someone else etc which would then require that indication of these conditions be added to other services in order for this to work. It's just not "diversion override". It's not "override" in any sense if the "full control still lies with the called endpoint". (Reminds me of the "Caller Preferences" work in the IETF, which has generally led to unending discussions.) Mike Pierce

1 0

[SUSPECT ATTACHMENT] the requirements for NAT traversal of H.323 multimedia systems
by Jianfang Li 21 Sep '04

21 Sep '04

Hi, all ITU-T SG16 members: We would like to submit a requirement document for H.fwreq assigned by Q5 of ITU-T SG16. this document will focus on both Service provider configuration and enterprise configuration for NAT traversal of H.323 multimedia systems. If you have any suggestion for this document, please feel free to send feedbacks and comments to me. Thanks a lot. Best Regards Jianfang Li ------------------------------------------------------------------------- Warning: This message has an attachment that could contain executable code. Please review the attachment carefully to ensure you do not inadvertently execute embedded programs. We suggest you review the following URL to stay up-to-date with current virus threats: http://wwwin.cisco.com/support/library/mcafee/virus_info.shtml ------------------------------------------------------------------------- For further reference information about viruses and email antivirus efforts within Cisco, please visit: http://wwwin.cisco.com/it/ems/services/antiviral If your concern isn't addressed by the information in this notification or the above web page, you may open a support request: http://wwwin.cisco.com/support/ Select "Messaging", "Email-Related", "Mail Routing" Please include in the text of your case the following information: * Full headers of the message. Documentation on displaying the full headers is available at this URL: http://wwwin.cisco.com/support/library/faqs/solution002471.html * This unique quarantine identifier: i8LCoowp024714 If the matter is urgent, you may follow up by calling one of the below referenced numbers. Please make every effort to provide the above requested information via the support web tool prior to calling as it will greatly aid the resolution of your issue. Americas: 1 408 526 8888 Asiapac +61 2 8446 8888 EMEA +31 20 485 4888 Japan +81 3 5549 6888 US (Toll Free) 1| 800| 888| 8187| (ext.68888) Thank you for your cooperation, Enterprise Messaging Services Cisco Systems, Inc

1 0

Directory structure of avc-site
by OKUBO Sakae 20 Sep '04

20 Sep '04

Dear users of the avc-site, As we are approaching the end of current study period, administrators of the avc-site (Paul Jones and myself) have considered rearranging the directory structure of the ftp site. There are two requirements; one is that we need permanent directories to allow stable linking from other pages, the other is that the most recent directory should appear on top of the list. A proposal is as follows: n_0501-0812/ <== the first meeting directory will be here from the start p_0101-0412/ <== all the meetings during this period q_9608-0012/ <== current till_0012 r_9501-9607/ <== current till_9607 The starting alphabet is to meet the second requirement. Probably we should avoid i, l, o to avoid confusion with numbers. In case we need to store older documents, we can create s_, t_ ... directories, and we have a sufficient number of letters for the future. Please advise me if you see any problems in this plan. I would like to carry out this rearrangement immediately so that the San Jose meeting report can include unchanging links. -- Best regards, OKUBO Sakae e-mail: sokubo(a)waseda.jp Visiting Professor Graduate School of Science and Engineering 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

Call Diversion Override
by Danilo Kempf 19 Sep '04

19 Sep '04

Dear Experts, reading the report of the meeting in San Jose, it has come to my attention that some concerns were raised regarding our draft H.460.cdor "Call Diversion Override" document. I think that all of those concerns are warranted and I'd like to take the time to address them here. Excerpts from the meeting report are quoted. > This specification is intended to work around unconditional call > forwarding, for instance. But, why should a calling device be able > to work around unconditional call forward? [ ... ] > Why does the endpoint not > contain the policy for what calls get forwarded and which do not? > People felt like there was a real danger in simply allowing any > calling endpoint to override call diversion. There seems to be some confusion whether there's an actual justification for having a service for overriding call forwarding. First, this is not meant as some sort of "poor man's MLPP" or similar. It's not an emergency service per se, it's only a mechanism for an endpoint to indicate that it doesn't wish a call to be subject of any/some call diversions. Being able to indicate this might actually be useful for the user to inhibit being connected to a voice-mail system after a CFB has taken place. It might also be useful for an Operator and of course it might be helpful with emergency services. Primarily, however, this service is intended to be an aid for automated systems, such as call-distribution systems, voicemail- and alarming systems -- in short any automated system that does a "call back" to an actual user. Take an ACD system as an example: Someone calls the system, which in turn alerts a group of users. As soon as one of those users picks up the phone, the other calls that were generated are disconnected automatically. Something as simple as a CFNR to a voicemail system might disrupt operation of this service, as now the voicemail system will pick up the call. By using CDOR, the call distribution system could indicate to the called group of endpoints, that no diversion to a voicemail system would be allowed for this call. Still, it could indicate, that it wishes diversions to other users to take place. So, this would not impede any normal operations. There are a lot of other examples, where CDOR could be useful. If you feel that you need more justification for such a service, I'd be happy to provide some more. It's clear that a diverting entity doesn't always know if the call is forwarded to another subscriber or to a voicemail system. Certainly, CDOR wouldn't be too useful in such an environment. But there are highly integrated telephony systems, where this is known in advance -- and CDOR would provide users with means to utilize this information to their advantage. Please note, that we intended to define a mechanism for overriding call forwarding and that there's no policy in there. Personally, I can't see a good reason for overriding CFU as well, but we certainly should provide users with the means to do so, if they desire (and the called endpoints policy agrees). CDOR doesn't state what happens, if a diversion is inhibited. It's possible to either continue to alert the user or to clear the call. (There's a special message defined for the latter case.) So, as it was before, the full control still lies with the called endpoint (or the Gatekeeper working on behalf of it), there's just an option for the caller to indicate preference. > There was some concern that this feature would open the door to > "spamming". Making spamming easier certainly wasn't the intent of the document. While I'm sure one may conceivably come up with with a scenario where CDOR may indeed be used in such a way, I don't think that this is in any way specific to CDOR only. I firmly believe that almost all services may be used in such a way, as long as there is neither authentication nor authorization taking place. Thus, the same concern might apply also to already established services, such as "Call Intrusion" or "Call Priority Designation". There are established mechanisms for both authentication and authorization in H.323, so these would apply to CDOR as well. > There should be an option in these procedures to allow the called > device to reject the diversion override service. So, the calling > device must have permission from the called device before invoking > this service. I agree. Maybe too much emphasis was laid on "overriding" diversions in the document. Currently there'd be no way for a called endpoint to reject the service. I think, a proper fix for this would be swapping the capability and protection levels. Currently, there are 4 protection levels and only 3 capability levels, allowing the calling endpoint to "always override". If this would be exchanged, it would allow the called endpoint to "always divert". I will change this in the document. > In 7.4, it was noted that behavior in H.460.1 was changed. Perhaps > this should be "should" rather than "shall". What is the exact > wording in H.460.1 that conflicts with this? I assume, that this point applies to the following clause from our draft document: > Intermediate entities shall, in contrast to the procedures specified > by the base H.460.1 specification, not remove the CDORRequest message > from the GenericData element of the Setup message before passing it on > to the next intermediate entity or the called endpoint, as this would > effectively disable the CDOR Service. In fact, I think there's some bad wording in our document. No part of H.460.1 is changed here. This paragraph was just addressing the GEF section of H.323, where it's declared that intermediate entities may remove parts of the GenericData element and not pass it through to the destination endpoint, if the intermediate entity can/will handle the described feature by itself. Removing a CDORRequest could be counter-productive, as the destination endpoint wouldn't even know that the CDOR service was to be invoked, so this sentence merely was meant as an "encouragement" to not remove the message from the GenericData element. I agree, that it should say "should not ... if policy allows" or similar. I'll update the document accordingly. > However, we should describe how this interacts with other things, such > as MLPP (H.460.14). My stance on this is, that there's no interaction with MLPP and MLPP takes precedence, as it's clearly an emergency service. I will add this to the document. I hope that I could address all of your concerns here. I'm very much interested in comments our further discussion. And, of course, I still hope, that you might find the CDOR service useful. With best regards, Danilo Kempf (TE-SYSTEMS GmbH)

1 0

QB report of the San Jose meeting
by OKUBO Sakae 14 Sep '04

14 Sep '04

Dear WP2/16 experts, The subject report has been placed at the avc-site: http://ftp3.itu.int/av-arch/avc-site/0408_San/AVD-2587.zip The document list (0408_San.html, TD-02i) has also been updated accordingly. -- Best regards, OKUBO Sakae e-mail: sokubo(a)waseda.jp Visiting Professor Graduate School of Science and Engineering 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

FW: Cybersecurity Symposium, Florianópoli
by simao.campos＠ITU.INT 14 Sep '04

14 Sep '04

Dear colleagues Please find attached some information about the Cybersecurity Symposium that will take place in Brazil, 4 October 2004, on the eve of the WTSA-04 opening day. Please feel free to attend and/or pass it along to colleagues that may be interested in participating. Best regards, Simão -----Original Message----- From: sebek(a)itu.int [mailto:sebek@itu.int] Sent: mardi, 14. septembre 2004 16:57 To: tsg17wpb(a)ties.itu.int; tsg17qg(a)ties.itu.int; tsg17qh(a)ties.itu.int; tsg17qi(a)ties.itu.int; tsg17qj(a)ties.itu.int; tsg17qk(a)ties.itu.int; tsg17ql(a)ties.itu.int; tsg17qm(a)ties.itu.int; tsg17qe(a)ties.itu.int Subject: Cybersecurity Symposium, Florianópolis, Brazil - 4 October 2004 Dear all, you may be interested in attending the ITU-T Cybersecurity Symposium to be held on 4 October 2004, the day prior to the start of the World Telecommunication Standardization Assembly (WTSA-04) in Florianópolis, Brazil. The programme for the Symposium, practical information and a registration form are available at: www.itu.int/ITU-T/worksem/cybersecurity/index.html Please feel free to forward this information to your colleagues or other interested experts. The Cybersecurity Symposium is open to non ITU-T members and participation is free of charge. Best regards Georges Sebek

1 0

List of San Jose meeting participants
by OKUBO Sakae 07 Sep '04

07 Sep '04

Dear participants of the San Jose meeting, The subject list is available as avc-site/0408_San/Attendees_0408_San.pdf. Please advise me if anything wrong is there. -- Best regards, OKUBO Sakae e-mail: sokubo(a)waseda.jp Visiting Professor Graduate School of Science and Engineering 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