- sg16-avd - lists.packetizer.com

RE: Clarification needed about AMR codec support
by Horvath Ernst 18 Oct '04

18 Oct '04

Venkata, D-284 was a contribution to the October-2002 meeting of SG16, but Question 3/16 did not accept the proposed text because of conflicts with the existing AMR definitions in H.245. The editor of D-284 was invited to bring a revised proposal to the next meeting, which seemingly did not happen. That's the reason why the parameters proposed in D-284 never became a part of H.245. Hope this solves your doubts. Ernst -----Original Message----- From: Venkata Nanduri [mailto:vnanduri@cisco.com] Sent: Donnerstag, 14. Oktober 2004 23:41 To: itu-sg16(a)external.cisco.com Cc: paulej(a)cisco.com Subject: Clarification needed about AMR codec support Hi, This email is regarding a clarification needed about a document submitted to SG16(SG 16 - Delayed contribution 284). In the Document titled "Update on AMR speech codec support for H.245", Table X.4 a parameter "octetAlign" is mentioned. But the same is missing from the latest H245 formal specification. As per the document(Delayed contribution 284), "octetAlign" parameter can be used to specify whether the bandwidth efficient or Octet aligned mode of operation is used. Since, In the formal spec, this parameter is missing, how should we negotiate whether we want to use Bandwidth efficient or Octet aligned operation. I also see other parameters(modeSet, ModeChangePeriod, ModeChangeNeighbour, Crc, robustSorting and interleaving) mentioned in your document, but are missing from the formal spec. Any information about how to negotiate those parameters? Thanks Venkata

1 0

Clarification needed about AMR codec support
by Venkata Nanduri 14 Oct '04

14 Oct '04

Hi, This email is regarding a clarification needed about a document submitted to SG16(SG 16 - Delayed contribution 284). In the Document titled "Update on AMR speech codec support for H.245", Table X.4 a parameter "octetAlign" is mentioned. But the same is missing from the latest H245 formal specification. As per the document(Delayed contribution 284), "octetAlign" parameter can be used to specify whether the bandwidth efficient or Octet aligned mode of operation is used. Since, In the formal spec, this parameter is missing, how should we negotiate whether we want to use Bandwidth efficient or Octet aligned operation. I also see other parameters(modeSet, ModeChangePeriod, ModeChangeNeighbour, Crc, robustSorting and interleaving) mentioned in your document, but are missing from the formal spec. Any information about how to negotiate those parameters? Thanks Venkata

1 0

Re: Templates for November Geneva Meeting
by OKUBO Sakae 12 Oct '04

12 Oct '04

Dear Tyler, At 14:13 -0400 04/10/12, Tyler Johnson wrote: >Do you have a document template for AVDs for the Geneva meeting coming up? > >We have several contributions. Please note that the November meeting is an official Study Group meeting, hence all the documents are managed by TSB, Mr. Campos-Neto. You can find the template at http://www.itu.int/ITU-T/studygroups/templates/index.html ITU-T basic template. Please also note that you need go through US National procedures if your documents are delayed contributions by UNC. If they are Editor's documents, you can submit them directly to TSB. -- 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: Re: the requirements for NAT traversal ofH.323 multimedia systems
by Jianfang Li 09 Oct '04

09 Oct '04

Dear Mr. Sakae: I am so happy to receive much suggestion from you. And we will carefully think about all of these . The following is our some consideration for disscuss. Thanks for your suggestion. Best Regards Jianfang Li >>Thank you for your draft. Here are some suggestions for your >>consideration, mostly for clarifying the description. >> >>1/ I assume this document addresses requirements for the technical >>solution of H.323 NAT/firewall traversal, but some statements in >>Section 9 might be addressing requirements for the study (or >>guidelines), I feel. Though both are important, we need distinction. >> Ok. We will think carefully about how to solve this question. > >>2/ I see the following expressions that may already state solutions. >> >>- In order to simplify scenarios in figure 2, it is recommended all >>realm including GKs are connected by VPN. (Section 7.1) >>- In these case , it is recommended that all GKs are connected by >>VPN, (Section 8.1.2) >>- If a enterprise realm includes more than one GK, it is >>recommended that all realms including GKs are connected by VPN. >>(Section 8.2) >>- If GKs is more than one realms, it is recommended that all realms >>including GKs are connected by VPN. (Section 9.1.1) >>- If H.323 endpoints are in the same realm and in the same >>multi-level realm, it is recommended that media streams directly go >>through between H.323 endpoints. (Section 9.3) >> >>I wonder if these are rather assumptions for this requirement document. >> Yes, Indeed, there maybe have some other solutions for these scenarios, Therefore, we will revise them and provide no specific solution for them. > >>3/ In each scenario of Section 8, there is a statement "Each H.323 >>endpoint can act on a caller or a callee. " This looks the >>requirement for the NAT/firewall traversal. It could be stated in >>Section 9 like "Each H.323 endpoint shall be able to act as a caller >>or a callee." > Yes, It is right. We will add this basic requirement in section 9. >>4/ I wonder if there are essential requirements (stated with "shall") >>and optional ones (stated with "should"). > OK. we will state more carelly about essential requirements by "Shall"and optional ones by "Should". > >> >>5/ I see the term "realm" is one of key words here. It should be >>defined in the terminology section and hopefully relevance to "zone" >>or "domain" used in other H.323 documents should be stated. > In this document, we use "realm" as many IETF documents do. do you mean we should use "domain" or "zone" rather than "realm"? > >> >>-- >>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: [imtch323implementors] conflict resolution in simultaneous H245 connections
by Paul E. Jones 08 Oct '04

08 Oct '04

Laurent, This is certainly true. For these reasons, devices behind NATs should really do H.245 tunneling to avoid the problem. Alternatively, the NAT ALG handling the H.323 signaling could just discard the H.245 address received from, say, the calling party. In that case, only one side can initiate the H.245 connection. Discarding the called side's H.245 address is probably dangerous. Anyway, these are just ideas... not necessarily the best solution. Certainly, this would be a good topic for discussion in Q5/16. (Copying the SG16 list.) Paul > -----Original Message----- > From: Laurent Barbero [mailto:barbero@col.bsf.alcatel.fr] > Sent: Thursday, September 30, 2004 5:06 AM > To: imtch323implementors(a)mail.imtc.org > Subject: [imtch323implementors] conflict resolution in simultaneous H245 > connections > > Hi all, > H323 recommandation says in case of separate H245 connections conflicts > that the > GW/Enpoint with the numerically smaller h245address shall close the TCP > connection it > opened to keep only one control channel. > > If you have both ends A and B, each in a private network and H323 NAT in > the middle, > and if the address translation gives : > > private H245address of A < translated H245address of B > private H245address of B < translated H245address of A > > Both H245connections are closed. > > Is there a common implementation workaround except control policy of the > H323 address > translation in the NAT to avoid such an issue. > > Thanks in advance. > Best regards. > L.B > > --- > Check out the IMTC Current News and Events! > http://www.imtc.org/press/press_releases.asp

1 0

Re: New Editor for H.225.0 and the H.323-Series IG
by OKUBO Sakae 07 Oct '04

07 Oct '04

Dear Paul and Faisal, At 13:06 -0400 04/10/07, Paul E. Jones wrote: >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. This is to thank Cisco for its support of the ITU-T SG16 works. Welcome Faisal to the H.323 team, I wish you all the best. -- Best regards, OKUBO Sakae, WP2/16 Chair 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

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

07 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 06 Oct '04

06 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

Re: Call Diversion Override
by Danilo Kempf 28 Sep '04

28 Sep '04

Bob, thank you very much for your comments. I think you're right pointing out that allowing or disallowing CDOR taking place for certain kinds of redirections (such as CFU) is a question of configuration/policy. > If, on the other hand, the idea of CDOR is to send the call to a > "known" location (e.g., to warn everyone in a particular building - a > reverse 911), then it would override every redirection feature. > Maybe we need some parameter to clarify the particular intent. That's a good idea, but I'm not too sure whether adding such an "intent" parameter would do the trick here. With CDOR you have the possibility to specify "don't follow any redirection at all". To stay with your example, your switch in this case would inhibit any re-routing due to the "Call Coverage" feature but still invoke any re-routings due to the "Call Forward" feature. To alter this behaviour (in order to even inhibit the "Call Forward" re-routings), we certainly could add such an "intent" field. I think, however, that combining CDOR with other services, such as H.460.14 (MLPP), H.460.4 (Call Priority) or even H.450.11 (Call Intrusion) might be more useful here. This would keep our CDOR document small and wouldn't duplicate any behaviour. On the other hand, let's assume a calling endpoint invokes both "Call Priority Designation" (setting a high priority) and CDOR at the same time. What should be the outcome? When a call rerouting is attempted, we'd still have to decide whether it's okay to divert or not. The elevated priority perhaps wouldn't be too helpful in making a decision. So perhaps adding an intent-parameter ("call the person" or "call the endpoint") might be helpful anyway -- but still, this is already indicated by sending the request for "no re-routings at all". I'm a bit undecided here and need to do some more reading regarding this issue. If you have any ideas here, they are certainly welcome! With best regards, Danilo Kempf (TE-SYSTEMS GmbH)

1 0

Re: Call Diversion Override
by Robert R. Gilman 27 Sep '04

27 Sep '04

Danilo and Mike - If we agree that the use of Call Diversion Override is to maximize the chance that the call is answered by the intended party, then we should look at the situations in which this might (or might not) be the case. I think this means we need to look at each vendor's system individually. In other words, the vendor must implement the feature in the way that makes sense for that vendor. For example, in our (Avaya's) switches, we have two basic forms of call redirection: Call Forwarding - this is usually means "I'm not here, try to reach me at this other number." Call Coverage - this usually means "I'm not here, this other persom will take my calls in that case." Unfortunately, this isn't always the case: Call Forward Busy/Don't Answer is more like call coverage (and was used as such before the coverage feature was implemented.) Call-Forward All is clearly in the first camp. Now, for our switches, it would make sense, I'd think, for us to implement CDOR in such a way that it overrode call coverage, but followed call forwarding. That gives the user some flexibility to "inform" the system about how CDOR should behave. If, on the other hand, the vendor's switch has only Call Forward-All and Call Forward-Busy/Don't-Answer, then the separation might be made between the two: the former can be used to say "I'm over at this other number now", while the latter is more like "if I'm not here, or I'm busy, send the call to somebody/something else." If, on the other hand, the idea of CDOR is to send the call to a "known" location (e.g., to warn everyone in a particular building - a reverse 911), then it would override every redirection feature. Maybe we need some parameter to clarify the particular intent. In any case, I think it is up to the vendor and the customer to decide how the CDOR feature should interact with the vendor's features, based on the customer's needs. -Bob ---------------------------------------------------- Bob Gilman rrg(a)avaya.com +1 303 538 3868 Danilo Kempf wrote: > Mike, > > thanks a lot (again!) for your comments. Please excuse that it took me > so long to respond, I unexpectedly had to travel a little. > > >>>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. > > > Well, if the term "ACD" system applies here, it's certainly not a really > sophisticated one. What I described should merely serve as a > simplified example, but I know of several similar (somewhat more > complicated, though) systems used in practice. > > >>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 > think we could call that "Call Forwarding". > > I think it's understandable that a calling party may want to (indicate > preference to) impede this. > > >>>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. > > >>[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. > > > You are right, it wouldn't work in cases where it's not known that the > destination is a voicemail system. CDOR (in this case) is clearly > intended as somewhat of a "niche"-service, but I think that'd be ok, as > implementing a H.460.x-service isn't mandatory either. > > In practice, I don't really think there are too many systems not knowing > that the destination is a voicemail. > > In general, CDOR wasn't only intended as a "prevent voicemail" service > and we had/have some more applications in mind. There are some more > legitimate reasons of preventing a call forwarding: (Now, this is the > point where my English skills start to leave me, so I hope you'll > understand what I'm trying to say.) > > The examples we had until now only addressed the cases where an > endpoint/a phone was bound to a certain person. The assumption was, > that when I'm dialling your number I'm trying to reach you as a person. > The call diversions you've set up might certainly be helpful in this > case. (Except, of course, for the CFNR/CFB to your voicemail...) > > 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 > call diversion to my cellphone. > > This, which might be considered an emergency service, plays a little bit > into the MLPP-domain. I think it even goes as far as being able to > supplement your specification in that point, as it might alter the > behaviour of MLPP vs. CFU/CFB behaviour specified in H.460.14. > > 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 > might be desirable. > > >>>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. > > > You are right with that interpretation, but I think you've missed > something here: The called endpoint would have had the opportunity to > release the call. The calling endpoint indicates preference to inhibit > the call diversion. After matching that request with it's internal > policy, the called endpoint decides, that the diversion shouldn't be > invoked. It now has the opportunity to either continue to alert the > called person or to clear the call. For the latter case, there's even > a special notification message defined with CDOR. > > The bad part here is, that this wasn't really clear from the example. > If nothing else, at least the example should be updated. > > 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 > document this example should be a bit clearer. > > >>>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". > > > I'm not sure I understand you here. What else if not "prefer not to be > answered by ..." is included in the SETUP with CDOR? Are we arguing > whether it's an actual "call forwarding" or just "something similar to, > but not quite, call forwarding"? > > 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 > right way to go here. > > Regarding the "voicemail" topic: Perhaps there really should be a > simple service for a voicemail-system to identify itself during call > set up. The calling party then could still decide to clear the call. > > The voicemail-system, in turn, could have taken a look at the > CDORRequest message transmitted by the calling party. If this > indicated that the calling party didn't wish to be forwarded to a > voicemail system AND the call was diverted before, the call could be > "proactively" cleared by the voicemail. This would basically achieve > the same effect as described above, without any diverting entity > knowing that it actually diverts to a voicemail systems. > > >>(Reminds me of the "Caller Preferences" work in the IETF, which has >>generally led to unending discussions.) > > > I really do not want to stir up an endless discussion. If you don't > think, a CDOR service is worth having or our CDOR document isn't > well-received in general, there's always the option of withdrawing it. > > I just wanted to point out, why I still think it's a rather good idea. > (But, of course, I don't have a really impartial opinion on that topic > either...) > > Again, thank you very much for your comments. > > Best regards, > > Danilo Kempf > (TE-SYSTEMS GmbH) >

1 0

Re: Call Diversion Override
by Danilo Kempf 27 Sep '04

27 Sep '04

Mike, thanks a lot (again!) for your comments. Please excuse that it took me so long to respond, I unexpectedly had to travel a little. > > 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. Well, if the term "ACD" system applies here, it's certainly not a really sophisticated one. What I described should merely serve as a simplified example, but I know of several similar (somewhat more complicated, though) systems used in practice. > 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 think we could call that "Call Forwarding". I think it's understandable that a calling party may want to (indicate preference to) impede this. > > 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. > [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. You are right, it wouldn't work in cases where it's not known that the destination is a voicemail system. CDOR (in this case) is clearly intended as somewhat of a "niche"-service, but I think that'd be ok, as implementing a H.460.x-service isn't mandatory either. In practice, I don't really think there are too many systems not knowing that the destination is a voicemail. In general, CDOR wasn't only intended as a "prevent voicemail" service and we had/have some more applications in mind. There are some more legitimate reasons of preventing a call forwarding: (Now, this is the point where my English skills start to leave me, so I hope you'll understand what I'm trying to say.) The examples we had until now only addressed the cases where an endpoint/a phone was bound to a certain person. The assumption was, that when I'm dialling your number I'm trying to reach you as a person. The call diversions you've set up might certainly be helpful in this case. (Except, of course, for the CFNR/CFB to your voicemail...) 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 call diversion to my cellphone. This, which might be considered an emergency service, plays a little bit into the MLPP-domain. I think it even goes as far as being able to supplement your specification in that point, as it might alter the behaviour of MLPP vs. CFU/CFB behaviour specified in H.460.14. 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 might be desirable. > > 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. You are right with that interpretation, but I think you've missed something here: The called endpoint would have had the opportunity to release the call. The calling endpoint indicates preference to inhibit the call diversion. After matching that request with it's internal policy, the called endpoint decides, that the diversion shouldn't be invoked. It now has the opportunity to either continue to alert the called person or to clear the call. For the latter case, there's even a special notification message defined with CDOR. The bad part here is, that this wasn't really clear from the example. If nothing else, at least the example should be updated. >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 document this example should be a bit clearer. > > 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". I'm not sure I understand you here. What else if not "prefer not to be answered by ..." is included in the SETUP with CDOR? Are we arguing whether it's an actual "call forwarding" or just "something similar to, but not quite, call forwarding"? 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 right way to go here. Regarding the "voicemail" topic: Perhaps there really should be a simple service for a voicemail-system to identify itself during call set up. The calling party then could still decide to clear the call. The voicemail-system, in turn, could have taken a look at the CDORRequest message transmitted by the calling party. If this indicated that the calling party didn't wish to be forwarded to a voicemail system AND the call was diverted before, the call could be "proactively" cleared by the voicemail. This would basically achieve the same effect as described above, without any diverting entity knowing that it actually diverts to a voicemail systems. > (Reminds me of the "Caller Preferences" work in the IETF, which has > generally led to unending discussions.) I really do not want to stir up an endless discussion. If you don't think, a CDOR service is worth having or our CDOR document isn't well-received in general, there's always the option of withdrawing it. I just wanted to point out, why I still think it's a rather good idea. (But, of course, I don't have a really impartial opinion on that topic either...) Again, thank you very much for your comments. Best regards, Danilo Kempf (TE-SYSTEMS GmbH)

1 0

RE: Outcome of the San Jose meeting (H.245)
by OKUBO Sakae 24 Sep '04

24 Sep '04

Dear Mike and all, At 06:56 -0400 04/09/24, <mike.nilsson(a)BT.COM> wrote: >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. This has been moved to the following place: http://ftp3.itu.int/av-arch/avc-site/2001-2004/0411_Gen/H245WCMY.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: 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 23 Sep '04

23 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 23 Sep '04

23 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 06 Sep '04

06 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