- sg16-avd - lists.packetizer.com

Re: Conflicting text in H.323 concerning the requirement for esta blishing a H.245 control channel??
by Agboh, Charles 20 Mar '01

20 Mar '01

Chris, Part of establishing a "point-to-point" call involves opening 2 TCP connnections using the Fast Connect procedure as you described it. If that is the case, then the extract from H.323v2 below is misleading(I believe). H.323v2: 8.1.7 Fast Connect Procedure "..... The Fast Connect procedure allows the endpoints to establish a basic point-to-point call with as few as one round-trip message exchange, enabling immediate media stream delivery upon call connection." BR, Charles > -----Original Message----- > From: Chris Wayman Purvis [mailto:cwp@ISDN-COMMS.CO.UK] > Sent: Tuesday, March 20, 2001 5:47 PM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: Re: Conflicting text in H.323 concerning the requirement for > esta blishing a H.245 control channel?? > > > Charles, > > It does NOT defeat ANY of the stated aims of FastConnect. > These aims were to get agreed media channels in both > directions open as > quickly as possible. Doing FastStart AND H.245 gives you your media > quickly, and means you have the power of H.245 thereon. > > In-band DTMF transfer may be used. If you happen to be using > a codec that > supports it. If you assume it when you're using an > unsuitable codec you'll > have a problem. Which is a reason for using H.245 capability > negotiation. > > Regards, > Chris > > Agboh, Charles wrote: > > > which defeats the whole point of having a Fast Connect > procedure (FS + > > H.245). Why isn't in-band- DTMF transfer used instead (in FS)? > > > > -Charles > > > > > >> -----Original Message----- > >> From: Frank Derks [mailto:frank.derks@PHILIPS.COM] > >> Sent: Tuesday, March 20, 2001 4:40 PM > >> To: ITU-SG16(a)MAILBAG.INTEL.COM > >> Subject: Re: Conflicting text in H.323 concerning the > requirement for > >> establishing a H.245 control channel?? > >> > >> > >> Chris, > >> > >> I thought I was being clear enough, so let me try again. > >> 6.2.8/H.323 states > >> that an enpoint must open one (and exactly one) H.245 control > >> channel. When > >> Fast Connect is being used, I assume that the intention is > >> that no such control > >> channel is opened. > >> > >> To be compliant with 6.2.8/H,323 I would have to open a H.245 > >> control channel > >> irrespective of which type of H.245 procedures I will be > >> using. So if I intend > >> to use Fast Start (and assuming that the other party also > >> supports this), I > >> still have to open a H.245 control channel. > >> > >> Frank > >> > >> > >> > >> > >> > >> > >> cwp(a)isdn-comms.co.uk on 20-03-2001 15:17:14 > >> To: Frank Derks/HVS/BE/PHILIPS@EMEA2 > >> cc: ITU-SG16@mailbag.cps.INTEL.COM@SMTP > >> Subject: Re: Conflicting text in H.323 concerning the > >> requirement for establishing a H.245 control channel?? > >> Classification: > >> > >> Frank, > >> > >> Why do you consider this text to be "conflicting"? > >> Specifically, with what does it conflict? > >> > >> Regards, > >> Chris > >> > >> > >>> 6.2.8/H.323 states: "The endpoint shall establish exactly > one H.245 > >>> Control Channel for each call that the endpoint is > >> > >> participating in." > >> > >>> 8.1.7/H.323 never states that when Fast Connect is being > used such a > >>> control channel should be established. As far as I understand the > >>> mechanism this is only required to switch to "normal" H.245 > >> > >> procedures. > >> > >>> It would seem that section 6.2.8 should be rephrased to > >> > >> make clear that > >> > >>> the H.245 control channel shall only be established when > >> > >> "normal" H.245 > >> > >>> procedures are being followed and not in the fast connect case. > >>> > >>> Frank > >> > >> -- > >> Dr Chris Purvis -- Development Manager > >> ISDN Communications Ltd, The Stable Block, Ronans, Chavey Down Road > >> Winkfield Row, Berkshire. RG42 6LY ENGLAND > >> Phone: +44 1344 899 007 > >> Fax: +44 1344 899 001 > >> > >> > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > >> For help on this mail list, send "HELP ITU-SG16" in a message to > >> listserv(a)mailbag.intel.com > >> > > > > > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > For help on this mail list, send "HELP ITU-SG16" in a message to > > listserv(a)mailbag.intel.com > > > -- > Dr Chris Purvis -- Development Manager > ISDN Communications Ltd, The Stable Block, Ronans, Chavey Down Road > Winkfield Row, Berkshire. RG42 6LY ENGLAND > Phone: +44 1344 899 007 > Fax: +44 1344 899 001 > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > For help on this mail list, send "HELP ITU-SG16" in a message to > listserv(a)mailbag.intel.com > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

3 2

Re: Conflicting text in H.323 concerning the requirement for esta blishing a H.245 control channel??
by Francois Audet 20 Mar '01

20 Mar '01

Fast start sole purpose is to get you talking as fast as possible. It is not to get you inputing digits as fast as possible. > -----Original Message----- > From: Agboh, Charles [mailto:charles.agboh@EBONE.COM] > Sent: Tuesday, March 20, 2001 7:49 AM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: Re: Conflicting text in H.323 concerning the requirement for > esta blishing a H.245 control channel?? > > > which defeats the whole point of having a Fast Connect procedure (FS + > H.245). Why isn't in-band- DTMF transfer used instead (in FS)? > > -Charles > > > -----Original Message----- > > From: Frank Derks [mailto:frank.derks@PHILIPS.COM] > > Sent: Tuesday, March 20, 2001 4:40 PM > > To: ITU-SG16(a)MAILBAG.INTEL.COM > > Subject: Re: Conflicting text in H.323 concerning the > requirement for > > establishing a H.245 control channel?? > > > > > > Chris, > > > > I thought I was being clear enough, so let me try again. > > 6.2.8/H.323 states > > that an enpoint must open one (and exactly one) H.245 control > > channel. When > > Fast Connect is being used, I assume that the intention is > > that no such control > > channel is opened. > > > > To be compliant with 6.2.8/H,323 I would have to open a H.245 > > control channel > > irrespective of which type of H.245 procedures I will be > > using. So if I intend > > to use Fast Start (and assuming that the other party also > > supports this), I > > still have to open a H.245 control channel. > > > > Frank > > > > > > > > > > > > > > cwp(a)isdn-comms.co.uk on 20-03-2001 15:17:14 > > To: Frank Derks/HVS/BE/PHILIPS@EMEA2 > > cc: ITU-SG16@mailbag.cps.INTEL.COM@SMTP > > Subject: Re: Conflicting text in H.323 concerning the > > requirement for establishing a H.245 control channel?? > > Classification: > > > > Frank, > > > > Why do you consider this text to be "conflicting"? > > Specifically, with what does it conflict? > > > > Regards, > > Chris > > > > > 6.2.8/H.323 states: "The endpoint shall establish exactly > one H.245 > > > Control Channel for each call that the endpoint is > > participating in." > > > 8.1.7/H.323 never states that when Fast Connect is being > used such a > > > control channel should be established. As far as I understand the > > > mechanism this is only required to switch to "normal" H.245 > > procedures. > > > > > > It would seem that section 6.2.8 should be rephrased to > > make clear that > > > the H.245 control channel shall only be established when > > "normal" H.245 > > > procedures are being followed and not in the fast connect case. > > > > > > Frank > > -- > > Dr Chris Purvis -- Development Manager > > ISDN Communications Ltd, The Stable Block, Ronans, Chavey Down Road > > Winkfield Row, Berkshire. RG42 6LY ENGLAND > > Phone: +44 1344 899 007 > > Fax: +44 1344 899 001 > > > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > For help on this mail list, send "HELP ITU-SG16" in a message to > > listserv(a)mailbag.intel.com > > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > For help on this mail list, send "HELP ITU-SG16" in a message to > listserv(a)mailbag.intel.com >

1 0

Re: Conflicting text in H.323 concerning the requirement for esta blishing a H.245 control channel??
by Agboh, Charles 20 Mar '01

20 Mar '01

which defeats the whole point of having a Fast Connect procedure (FS + H.245). Why isn't in-band- DTMF transfer used instead (in FS)? -Charles > -----Original Message----- > From: Frank Derks [mailto:frank.derks@PHILIPS.COM] > Sent: Tuesday, March 20, 2001 4:40 PM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: Re: Conflicting text in H.323 concerning the requirement for > establishing a H.245 control channel?? > > > Chris, > > I thought I was being clear enough, so let me try again. > 6.2.8/H.323 states > that an enpoint must open one (and exactly one) H.245 control > channel. When > Fast Connect is being used, I assume that the intention is > that no such control > channel is opened. > > To be compliant with 6.2.8/H,323 I would have to open a H.245 > control channel > irrespective of which type of H.245 procedures I will be > using. So if I intend > to use Fast Start (and assuming that the other party also > supports this), I > still have to open a H.245 control channel. > > Frank > > > > > > > cwp(a)isdn-comms.co.uk on 20-03-2001 15:17:14 > To: Frank Derks/HVS/BE/PHILIPS@EMEA2 > cc: ITU-SG16@mailbag.cps.INTEL.COM@SMTP > Subject: Re: Conflicting text in H.323 concerning the > requirement for establishing a H.245 control channel?? > Classification: > > Frank, > > Why do you consider this text to be "conflicting"? > Specifically, with what does it conflict? > > Regards, > Chris > > > 6.2.8/H.323 states: "The endpoint shall establish exactly one H.245 > > Control Channel for each call that the endpoint is > participating in." > > 8.1.7/H.323 never states that when Fast Connect is being used such a > > control channel should be established. As far as I understand the > > mechanism this is only required to switch to "normal" H.245 > procedures. > > > > It would seem that section 6.2.8 should be rephrased to > make clear that > > the H.245 control channel shall only be established when > "normal" H.245 > > procedures are being followed and not in the fast connect case. > > > > Frank > -- > Dr Chris Purvis -- Development Manager > ISDN Communications Ltd, The Stable Block, Ronans, Chavey Down Road > Winkfield Row, Berkshire. RG42 6LY ENGLAND > Phone: +44 1344 899 007 > Fax: +44 1344 899 001 > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > For help on this mail list, send "HELP ITU-SG16" in a message to > listserv(a)mailbag.intel.com > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

2 1

Re: Conflicting text in H.323 concerning the requirement for establishing a H.245 control channel??
by Frank Derks 20 Mar '01

20 Mar '01

Chris, I thought I was being clear enough, so let me try again. 6.2.8/H.323 states that an enpoint must open one (and exactly one) H.245 control channel. When Fast Connect is being used, I assume that the intention is that no such control channel is opened. To be compliant with 6.2.8/H,323 I would have to open a H.245 control channel irrespective of which type of H.245 procedures I will be using. So if I intend to use Fast Start (and assuming that the other party also supports this), I still have to open a H.245 control channel. Frank cwp(a)isdn-comms.co.uk on 20-03-2001 15:17:14 To: Frank Derks/HVS/BE/PHILIPS@EMEA2 cc: ITU-SG16@mailbag.cps.INTEL.COM@SMTP Subject: Re: Conflicting text in H.323 concerning the requirement for establishing a H.245 control channel?? Classification: Frank, Why do you consider this text to be "conflicting"? Specifically, with what does it conflict? Regards, Chris > 6.2.8/H.323 states: "The endpoint shall establish exactly one H.245 > Control Channel for each call that the endpoint is participating in." > 8.1.7/H.323 never states that when Fast Connect is being used such a > control channel should be established. As far as I understand the > mechanism this is only required to switch to "normal" H.245 procedures. > > It would seem that section 6.2.8 should be rephrased to make clear that > the H.245 control channel shall only be established when "normal" H.245 > procedures are being followed and not in the fast connect case. > > Frank -- Dr Chris Purvis -- Development Manager ISDN Communications Ltd, The Stable Block, Ronans, Chavey Down Road Winkfield Row, Berkshire. RG42 6LY ENGLAND Phone: +44 1344 899 007 Fax: +44 1344 899 001 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

2 1

Conflicting text in H.323 concerning the requirement for establishing a H.245 control channel??
by Frank Derks 20 Mar '01

20 Mar '01

6.2.8/H.323 states: "The endpoint shall establish exactly one H.245 Control Channel for each call that the endpoint is participating in." 8.1.7/H.323 never states that when Fast Connect is being used such a control channel should be established. As far as I understand the mechanism this is only required to switch to "normal" H.245 procedures. It would seem that section 6.2.8 should be rephrased to make clear that the H.245 control channel shall only be established when "normal" H.245 procedures are being followed and not in the fast connect case. Frank ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

2 1

Rapporteurs/Editors Manual - 1 Feb 2001 version
by OKUBO Sakae 20 Mar '01

20 Mar '01

Dear Fellow Rapporteurs, Editors and all, I have received from ITU-TSB the subject manual and placed it at the ftp site: http://standard.pictel.com/ftp/avc-site/manual21-02-01.zip Please carefully read it. I can say from the past experiences that the manual will help us when we face difficulty. Best regards, OKUBO Sakae *************************************************** Global Information and Telecommunication Institute Waseda University 29-7 Waseda University Bldg. 1-3-10 Nishi-Waseda, Shinjuku-ku, Tokyo 169-0051 Japan e-mail: sokubo(a)mn.waseda.ac.jp Tel: +81 3 3204 8194 Fax: +81 3 5286 3832 **************************************************** ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

Re: A problem involving sending fast-start element in a facility message.
by Paul, Manoj 19 Mar '01

19 Mar '01

Praneeth, Refer to section 8.2.2 of H.323 Version 4. The last paragraph states that the reason should be set to "forwardedElements" as you indicated in your mail. -Manoj -----Original Message----- From: pmreddy(a)HSS.HNS.COM [mailto:pmreddy@HSS.HNS.COM] Sent: Wednesday, March 14, 2001 9:42 PM To: ITU-SG16(a)mailbag.cps.INTEL.COM Subject: A problem involving sending fast-start element in a facility message. Hi, I'm stuck with a particular problem, in the implementation of fast-start in the h323v2 implementation. The following are the details. If anybody is certain about the solution please do respond. Consider the scenario in which both calling end-point(A) and called end-point(B) support and prefer fast-start. Calls are gk-routed. A sends Setup message containing a fast-start element, to the Gatekeeper, which fowards it to B. Gatekeeper sends Call-Proceeding to A. B responds to the Setup sent by A, with a Call-Proceeding containing a fast-start element. Now, the Gatekeeper maps the fast-start element to a faststart element in the facility message. NOW, WHAT REASON SHOULD THE FACILITY MESSAGE HAVE?? I feel it should be "forwarded elements". But I am not very sure. If anybody knows about this, please respond immediately. Thanks Praneeth ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

Re: FW: [VoIP-list] FW: [Fwd: AVT WG last call on RTP spec and pr ofil e]
by Roni Even 19 Mar '01

19 Mar '01

Glen, Were do I have to plea, Roni Even Acccord Networks -----Original Message----- From: Glen Freundlich [mailto:ggf@AVAYA.COM] Sent: Thursday, March 15, 2001 8:54 PM To: ITU-SG16(a)MAILBAG.INTEL.COM Subject: Re: FW: [VoIP-list] FW: [Fwd: AVT WG last call on RTP spec and profil e] I've made my plea to retain the G.723.1 payload format and codepoint, and would suggest that other vendors do the same. We may have some data collected from the IMTC H.323 interop test events that would reflect the number of vendors that have successfully interoperated using G.723.1 (and probably H.263, possibly the GSM coders), and might be able to provide those numbers. But, it's better for vendors to identify themselves. Glen Tom-PT Taylor wrote: It's simply a matter of implementors reporting. The key point is that the Working Group Chair has to know exactly which features of the RFC were tested and which not. In the case of the G723 payload type, there are no options to worry about: it's simply a matter of different implementations agreeing on RTP payload type 4 and subsequently transmitting RTP-encapsulated packets in accordance with G.723.1, using one frame (30 ms) per packet or such other value as specified by the A:ptime attribute. -----Original Message----- From: Rex Coldren [ mailto:coldrenr@AGCS.COM <mailto:coldrenr@AGCS.COM> ] Sent: Wednesday, March 14, 2001 2:37 PM To: ITU-SG16(a)MAILBAG.INTEL.COM Subject: Re: FW: [VoIP-list] FW: [Fwd: AVT WG last call on RTP spec and profil e] Francois, I believe you are correct. However, I am not familiar with how the IETF determines "interoperable implementations". Is is simply a matter of vendors reporting with whom they interoperate or is there some IETF-sponsored interop event that needs to be attended? Rex Francois Audet wrote: Guys,This payload type = 4 for G.723.1 has been in H.225.0 for many years. Don't we have many interoperable H.323 products using PT=4 for G.723?Won't it be a major interoperability problem if this payload type is removed from the A/V specification?????> -----Original Message----- > From: Simao Campos-Neto [ mailto:simao.campos@LABS.COMSAT.COM <mailto:simao.campos@LABS.COMSAT.COM> > < mailto:simao.campos@LABS.COMSAT.COM <mailto:simao.campos@LABS.COMSAT.COM> > ] > Sent: Friday, March 09, 2001 8:27 AM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: [Fwd: AVT WG last call on RTP spec and profile] > > > Dear colleagues, > > please see in the attached that audio payload formats for G.723.1, > called there "G723", has been removed from the latest RTP A/V profile > because of the lack on information that interoperable implementations of > them exist. Other audio payload formats have also been removed, e.g. > H263 (this is not the same as H263-2000), GSM-HR, GSM-EFR, If you know > of such implementations, there is still some VERY short time (less than > 2 weeks) before the IETF issues the repeat WG last call. Please provide > any such information directly to Stephen Casner <casner(a)acm.org>. > > Best regards, > Simao.

2 1

Report of the Launceston meeting AVD-2100
by OKUBO Sakae 19 Mar '01

19 Mar '01

Dear SG16 experts, The subject document has been uploaded to the /Incoming directory of the ftp site. It is an integration of Question reports and other administrative materials with editorial refinements. http://standard.pictel.com/ftp/avc-site/Incoming/AVD-2100.zip Please review it and return your advice if anything is wrong by the end of this week. Then it will be placed at /0103_Lau directory with status of "confirmed be the participants." Best regards, OKUBO Sakae *************************************************** Global Information and Telecommunication Institute Waseda University Waseda University Bldg. 29-7 1-3-10 Nishi-Waseda, Shinjuku-ku, Tokyo 169-0051 Japan e-mail: okubo(a)giti.waseda.ac.jp Tel: +81 3 3204 8194 Fax: +81 3 5286 3832 **************************************************** ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

I know it's been a while, but... 16921
by Kristie_S＠TEAMZEZZ.COM 19 Mar '01

19 Mar '01

1 0