October 2004 - sg16-avd - lists.packetizer.com

New Editor for H.225.0 and the H.323-Series IG
by Paul E. Jones 08 Oct '04

08 Oct '04

Folks, I am pleased to announce that Faisal Siyavudeen of Cisco has volunteered to assume editorial responsibility of ITU-T Recommendation H.225.0 and the H.323-Series Implementers Guide. He plans to attend the upcoming SG16 meeting and I hope you will join me in giving him support as he accepts this important responsibility in SG16. Best Regards, Paul E. Jones Rapporteur, ITU-T Q2/16

2 1

Re: San Jose meeting report AVD-2586
by OKUBO Sakae 07 Oct '04

07 Oct '04

Dear Mr. Carmichael, At 09:42 +0100 04/10/07, Rob Carmichael wrote: >This link is broken in IE6SP1 and throws up an error in Firefox PR1. >You can correct this by removing the "avguest@" from the link. >[...] > > The integrated version of San Jose meeting report is now available at >> the following place: >> > > >http://avguest@ftp3.itu.int/av-arch/avc-site/2001-2004/0408_San/AVD-2586.zip Thank you for your advice. The following URL should work: http://ftp3.itu.int/av-arch/avc-site/2001-2004/0408_San/AVD-2586.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

San Jose meeting report AVD-2586
by OKUBO Sakae 07 Oct '04

07 Oct '04

Dear SG16 experts, The integrated version of San Jose meeting report is now available at the following place: http://avguest@ftp3.itu.int/av-arch/avc-site/2001-2004/0408_San/AVD-2586.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

Re: Call Diversion Override
by Mpierce1＠AOL.COM 06 Oct '04

06 Oct '04

In a message dated 9/27/2004 5:17:15 PM Eastern Standard Time, lilo(a)nullpointer.de writes: > > > [MAP] 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. > > Certainly, in this case we'd like to prevent the call from going to a > voicemail system. In my book however, I think that's what "Call > Forwarding" really is: When I, as the intended recipient of the call, > fail to pick up my phone in time, the call somehow is "diverted" or > "forwarded" to my voicemail. This may happen by just about any > mechanism -- be it H.450.3 or a routing GK playing tricks -- I still > [MAP] No, call forwarding and voice mail are two different services. It just happens that switching systems that do not implement voice mail internally have to use Call Forwarding to send the call to another piece of equipment (like another line) which is the voice mail system. A system can provide voice mail (on no answer or immediately, without calling it "Call Forwarding") just like a system can provide Call Forwarding which is not to voice mail. > > In practice, I don't really think there are too many systems not knowing > [MAP} If that were ture, then we should be able to define a parameter as "Don't forward to voicemail" and accomplish exactly what you want. > > > This assumption, however, doesn't always hold true. Take an alarming > system as an example. If this system is triggered, it might > systematically call all endpoints in a building and play back an > announcement. This system certainly wouldn't bother with following a > [MAP] If I was still in the building with my cell phone, but not where my wired phone is, I would certainly want this warning call forwarded to me! If I was not in the building, I might still want it. > > Finally, CDOR might be used to inhibit a call forwarding to external > (and thus possibly costly) numbers. This, of course, isn't specified > in our document, as in general it's not known, whether a number is > external or not. In the future, however, I think such an extension > [MAP} This would be a very useful service, if the calling party would have to pay for the extra cost. And of course the forwarding point must have some concept of what "external" or "long distance" is. > > > From the meeting report it was clear, that in our draft there was too > much control with the calling endpoint. In my previous e-mail I > pointed out, that this will be changed to give the "final say" back to > the called endpoint. I think, with these changes incorporated into the > > > What we want to achieve is giving the caller some preference over where > the call finally terminates -- without removing any control from the > called endpoint or any entity in between. I think, CDOR would be a > [MAP} The fundamental choice is: - If the real control is given to the calling party, then it's "Call Diversion Override". - If the real control is given to the called party, then the service you're defining is "Caller Preferences". > Regarding the "voicemail" topic: Perhaps there really should be a > simple service for a voicemail-system to identify itself during call > set up. [MAP] That's exactly what happens today. The caller hears the voice mail prompt and may hang-up. Don't get me wrong, I think a capability for the calling party to prevent a call being answered by a voice-mail system would be a very useful service. Mike Pierce

1 0

RE: [SUSPECT ATTACHMENT] the requirements for NAT traversal of H.
by Euchner Martin 05 Oct '04

05 Oct '04

Dear Jianfang Li, I found your document posted and uploaded and tried to figure out what has been changed since the original submission. There is a statement in the document that says that "Changes are against AVD-2476 from the Beijing SG16 Q.5 Rapporteurs' meeting.", but I cannot see any change marks or other clues what exactly has changed, and what remained unchanged. It is somehow possible to outline the changes? Thanks. With kind regards Martin Euchner. ----------------------------------------------------------------------- | Dipl.-Inf. Rapporteur Q.G/SG16 | Martin Euchner Phone: +49 89 722 55790 | Siemens AG.....................Fax : +49 89 722 62366 | ICN M SR 3 mailto:Martin.Euchner@siemens.com | mailto:martin.euchner@ties.itu.int | Hofmannstr. 51 Intranet: http://ietf.icn.siemens.de/sr3/Standardisation_Topics/security/ | D-81359 Muenchen Internet: http://www.siemens.de/ | __________________ | Germany ----------------------------------------------------------------------- -----Original Message----- From: Jianfang Li [mailto:lijianfang@mail.ritt.com.cn] Sent: Dienstag, 21. September 2004 14:51 To: itu-sg16(a)external.cisco.com Subject: [SUSPECT ATTACHMENT] the requirements for NAT traversal of H.323 multimedia systems 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