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

Clarification needed - H245 Specification
by Venkata Nanduri 29 Oct '04

29 Oct '04

Hi, I want a clarification about the H245 Annex I defined for AMR codec: What is the parameter "bitRate" defined for? Is it defined for AMR mode change out-of-band? I want to know how the AMR mode changes can be performed out-of-band using H245? For example, assume that we are having a voice call with 12.2kbps and during the call, how can we change it to 7.4kbps using H245? Please let me know at the earliest... Thanks Venkata

1 0

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

19 Oct '04

Venkata, they could be added as optional parameters to the existing defintions for AMR in H.245 Annex I. AMR is defined as a generic capability, which is extensible. Just make sure that the additional parameters use new identifiers. There should also be some text describing the meaning and usage of the new parameters, and if applicable, their relationship with existing parameters. This would require sending a delayed contribution to the next SG16 meeting (note the deadline - 4 November 2004 - and the procedural aspects - Paul Jones may be able to advice you). If accepted, the changes could still be edited into the draft for H.245 version 11. Ernst -----Original Message----- From: Venkata Nanduri [mailto:vnanduri@cisco.com] Sent: Montag, 18. Oktober 2004 19:18 To: Horvath Ernst Cc: paulej(a)cisco.com; itu-sg16(a)external.cisco.com; vdukki(a)cisco.com Subject: RE: Clarification needed about AMR codec support Hi, If that is the case, how those parameters can be negotiated using H245? Any information in this regard is highly appreciated... Similar parameters for SIP are defined in RFC3267, Section 8.1. Thanks Venkata At 10:01 AM 10/18/2004 -0400, Horvath Ernst wrote: 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 <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

RE: Clarification needed about AMR codec support
by Venkata Nanduri 18 Oct '04

18 Oct '04

Hi, If that is the case, how those parameters can be negotiated using H245? Any information in this regard is highly appreciated... Similar parameters for SIP are defined in RFC3267, Section 8.1. Thanks Venkata At 10:01 AM 10/18/2004 -0400, Horvath Ernst wrote: >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

Question on T.38 bandwidth
by faisal.siyavudeen＠cisco.com 18 Oct '04

18 Oct '04

Hi All, H.323 Annex D (D.6) <quote> When TCP is used for T.38 fax transmission, maxBitRate in the ARQ/BRQ does not include the fax data rate, and if a voice link is switched off when the fax session starts, a BRQ shall be used to indicate to the Gatekeeper that the bandwidth has changed. When UDP is used for T.38 fax transmission, maxBitRate in the ARQ/BRQ does include the bit rate needed for the fax session. The endpoint (terminal, gateway) shall send BRQs to the Gatekeeper as bandwidth needs change during the call. </quote> Is there any specific reason why we do not include the fax data rate in the requested bandwidth for TCP? If TCP is the transport protocol, what will be the bandwidth value that is requested in ARQ/BRQ? rgds Faisal

1 0

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 08 Oct '04

08 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 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