- sg16-avd - lists.packetizer.com

Documents for the coming meeting in Geneva
by OKUBO Sakae 04 Nov '04

04 Nov '04

Dear SG16 experts, The following delayed contributions have been placed at the avc-site for your advance review: France Telecom: Location Number for H.323 http://ftp3.itu.int/av-arch/avc-site/2001-2004/0411_Gen/FT-location_number.… Waseda University: Phase synchronization of video sources http://ftp3.itu.int/av-arch/avc-site/2001-2004/0411_Gen/Waseda-video_phase_… PS If you have already submitted your documents to ITU-TSB, please send them to me. I will make them available at the avc-site to facilitate advance review by the experts. -- 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

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