November 2000 - sg16-avd - lists.packetizer.com

APC-1991 withdrawn
by Michaely, Boaz 02 Nov '00

02 Nov '00

Dear Mr. Okubo, experts, APC-1991 was intended to propose a way to expand the negotiation capabilites in 'desiredProtocols', accompanying APC-1990 which elaborates why it is important to provide all the call related information during AccessRequest (in H.225.0 Annex G). During the discussion on the list, it was pointed out that while the idea 'is meritorious' this specific structure may be problematic to take a ride on.. Well, I guess this can wait until Video Call Answering becomes more popular. APC-1991 is hereby withdrawn. See you next week, Boaz Michaely http://people.itu.int/~michaely ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

APC-1990 uploaded - Service Zone support in Annex G
by Michaely, Boaz 02 Nov '00

02 Nov '00

Dear Mr. Okubo, experts, I have uploaded APC-1990 to ftp://standard.pictel.com/avc-site/incoming "H.225.0 Annex Gv2: Support for Service Zone" This contribution proposes to expand the call related information to be used in AccessRequest for the purpose of Inter-Zone communications with a Service Zone. See you next week, Boaz Michaely http://people.itu.int/~michaely ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

Re: fastStart element in all Q.931 messages up to and including C onnect
by Francois Audet 02 Nov '00

02 Nov '00

It is illegal to change fastStart mid-stream. Period. Finito. We can't change that. It would break some existing implementations. So look at the first one and ignore the others. (That being said, it would have been useful to allow for making a call to a hunt group, and in-band ringing would be provided until a real person could respond). > -----Original Message----- > From: van Schelven, Richard [mailto:Richard.VanSchelven@MARCONI.COM] > Sent: Thursday, November 02, 2000 1:57 AM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: Re: fastStart element in all Q.931 messages up to > and including > C onnect > > > Can anybody enlighten me: > > 1. Why would an endpoint change fastStart elements in mid > stream? How would > you implement that in real life. > 2. Why are things so complicated? Why not have a fastStart > element in a > Setup and Connect only. All the other things are complicating > matters and > IMHO unnecessarily. > > Faststart is suppose to be fast, clean (simple) and crisp solution. > > Ries van Schelven > Principal Engineer > Marconi > 100 Upper Georges Street > Dun Laoghaire > Co. Dublin > Ireland > > > > -----Original Message----- > > From: Paul E. Jones [mailto:paulej@PACKETIZER.COM] > > Sent: Thursday, November 02, 2000 7:08 AM > > To: ITU-SG16(a)mailbag.cps.intel.com > > Subject: Re: fastStart element in all Q.931 messages up to > > and including > > Connect > > > > > > Bob, > > > > This opens a whole can of worms. Essentially, I can't agree > > that fastStart > > may be modified and re-transmitted. The calling endpoint may > > have freed > > resources and certainly may not be prepared to accept the > > newly modified > > proposals. > > > > Paul > > > > ----- Original Message ----- > > From: "Bob Gilman" <rrg(a)AVAYA.COM> > > To: <ITU-SG16(a)mailbag.cps.intel.com> > > Sent: Wednesday, November 01, 2000 12:03 PM > > Subject: Re: fastStart element in all Q.931 messages up to > > and including > > Connect > > > > > > > Francois and Paul - > > > I agree with François' change to "shall react to the first > > > fastStart element", but I would suggest that "ignore" be > > > replaced by "may ignore" for any subsequent fastStart elements. > > > (If a called endpoint changes fastStart elements in mid-stream, > > > then it's the caller's choice whether it reacts or not.) > > > BTW, doesn't this overlap with the redirection problem in which > > > we perhaps should say that the called endpoint "shall" react to > > > any subsequent [different] fastStart element? > > > -Bob > > > ---------------------------------------------------- > > > Bob Gilman rrg(a)avaya.com +1 303 538 3868 > > > > > > > > > ----- Original Message ----- > > > From: Francois Audet > > > To: h323implementors > > > Sent: Tuesday, October 31, 2000 1:32 PM > > > Subject: RE: fastStart element in all Q.931 messages > > up to and > > including > > > C onnect > > > > > > Change the should to a shall then: > > > > > > The called endpoint accepts a proposed channel > > by returning > > the > > > corresponding > > > OpenLogicalChannel structure in a Q.931 > message sent in > > response to > > > Setup, up to and including Connect. > > > <NEW>A called endpoint may choose to repeat the > > exact same > > fastStart > > > element in all subsequent message up to > > > and including Connect. Calling endpoints shall > > react to the > > first > > > fastStart element received in a response message > > > to the Setup message and ignore any eventual > subsequent > > fastStart > > > elements. > > > > > > If somebody manages to get it wrong after that, they > > deserve to be > > taken > > > out of business. > > > > > > I completely disagree with your assertion that we > must choose > > either one > > > or many. Currently some implementations send one, > > > others send many, and we don't see > interoperability problems. > > > > > > > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > > 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 > > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > For help on this mail list, send "HELP ITU-SG16" in a message to > listserv(a)mailbag.intel.com >

1 0

Re: TCS is always first message, not TCSAck
by Francois Audet 02 Nov '00

02 Nov '00

That seems like a minor editorial mistake that should be very easy to fix. > -----Original Message----- > From: Paul Long [mailto:plong@PACKETIZER.COM] > Sent: Wednesday, November 01, 2000 10:39 PM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: TCS is always first message, not TCSAck > > > This one concerns me a great deal. > > H.323 has always required that an EP send TCS as the very first H.245 > message regardless of whether the EP is the calling or called EP > (8.2/H.323v4: "...the H.245 terminalCapabilitySet message ... > shall be the > first H.245 message sent."). No exceptions. (There are two > sections labeled > "8.2.3", so I'll call the second one, "8.2.3+".) And > 8.2.3+/H.323v4 even > reiterates this ("As detailed in section 8.2, the first two > H.245 messages > sent by an endpoint on the H.245 Control Channel are the > terminalCapabilitySet message and the > masterSlaveDetermination messages."). > However, 8.2.3+/H.323v4 goes on to say that the called EP sends TCSAck > first, which clearly contradicts 8.2 and itself! Therefore, > in order to > resolve this contradiction and restore backwards > compatibility with previous > versions of H.323, the fix is to simply say that _TCS_ is the > first message > sent by the called EP and not _TCSAck_. Here are the three > necessary mods > ("[...]" means insert; "<...>" means delete). > > 1. 8.2.3+/H.323v4: "To indicate that the called > entity understands the > earlyH245Control field, the first H.245 message that the > called entity sends > shall be the terminalCapabilitySet<Ack> message tunneled in > the H.225.0 Call > Signalling Channel." > > 2. Table 41/H.323v4: > <TerminalCapabilitySetAck(calling endpoint) > TerminalCapabilitySet(called endpoint)> > [TerminalCapabilitySet(called endpoint) > TerminalCapabilitySetAck(calling endpoint)] > > 3. 8.2.3+/H.323v4: "The calling entity shall > recognize that the > earlyH245Control field was not understood when either it > receives a Connect > message and still has not received a< response to the initial> > terminalCapabilitySet message, the first H.245 message > received from the > called entity is not a tunneled terminalCapabilitySet<Ack> message, or > fastStart or fastConnectRefused is received and< no response has been > received for the>[ a] terminalCapabilitySet message [has not been > received]." > > Paul Long > ipDialog > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > For help on this mail list, send "HELP ITU-SG16" in a message to > listserv(a)mailbag.intel.com >

1 0

APC 2022 (H.323 Annex P Draft) uploaded
by Danny Wolfstein 02 Nov '00

02 Nov '00

Hi, APC 2022 (Draft for H.323 Annex P - modem relay over H.323 systems) has been uploaded to the PictureTel site. Thanks Danny Wolfstein ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 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

H.323 watershed
by Paul Long 02 Nov '00

02 Nov '00

I think I'm going to puke. :-@ Built-in, purposeful non-backwards compatibility! Alright! We've come close in the past, but this time we hit it on the nail: 8.1.7.2 "An H.323 Version 4 or higher entity that uses Fast Connect in a call shall use H.245 tunneling when an H.245 Control Channel is required and shall always set the h245Tunneling field to TRUE. The process for switching to a separate H.245 connection is described in 8.2.3 and may be used by Version 3 or older entities or by newer H.323 entities when communicating with Version 3 or older entities for the purpose of maintaining backward compatibility." First of all, "...when an H.245 Control Channel is required..." is redundant and should be removed because an H.245 channel is _always_ required: 6.2.8/H.323v4: "The endpoint shall establish exactly one H.245 Control Channel for each call that the endpoint is participating in." But mainly, v4 and post-v4 EPs are not interoperable with pre-v4 EPs that do not support Fast Connect. Wave goodbye to NetMeeting! :-) Paul Long ipDialog ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

2 1

Re: fastStart element in all Q.931 messages up to and including C onnect
by van Schelven, Richard 02 Nov '00

02 Nov '00

Can anybody enlighten me: 1. Why would an endpoint change fastStart elements in mid stream? How would you implement that in real life. 2. Why are things so complicated? Why not have a fastStart element in a Setup and Connect only. All the other things are complicating matters and IMHO unnecessarily. Faststart is suppose to be fast, clean (simple) and crisp solution. Ries van Schelven Principal Engineer Marconi 100 Upper Georges Street Dun Laoghaire Co. Dublin Ireland > -----Original Message----- > From: Paul E. Jones [mailto:paulej@PACKETIZER.COM] > Sent: Thursday, November 02, 2000 7:08 AM > To: ITU-SG16(a)mailbag.cps.intel.com > Subject: Re: fastStart element in all Q.931 messages up to > and including > Connect > > > Bob, > > This opens a whole can of worms. Essentially, I can't agree > that fastStart > may be modified and re-transmitted. The calling endpoint may > have freed > resources and certainly may not be prepared to accept the > newly modified > proposals. > > Paul > > ----- Original Message ----- > From: "Bob Gilman" <rrg(a)AVAYA.COM> > To: <ITU-SG16(a)mailbag.cps.intel.com> > Sent: Wednesday, November 01, 2000 12:03 PM > Subject: Re: fastStart element in all Q.931 messages up to > and including > Connect > > > > Francois and Paul - > > I agree with François' change to "shall react to the first > > fastStart element", but I would suggest that "ignore" be > > replaced by "may ignore" for any subsequent fastStart elements. > > (If a called endpoint changes fastStart elements in mid-stream, > > then it's the caller's choice whether it reacts or not.) > > BTW, doesn't this overlap with the redirection problem in which > > we perhaps should say that the called endpoint "shall" react to > > any subsequent [different] fastStart element? > > -Bob > > ---------------------------------------------------- > > Bob Gilman rrg(a)avaya.com +1 303 538 3868 > > > > > > ----- Original Message ----- > > From: Francois Audet > > To: h323implementors > > Sent: Tuesday, October 31, 2000 1:32 PM > > Subject: RE: fastStart element in all Q.931 messages > up to and > including > > C onnect > > > > Change the should to a shall then: > > > > The called endpoint accepts a proposed channel > by returning > the > > corresponding > > OpenLogicalChannel structure in a Q.931 message sent in > response to > > Setup, up to and including Connect. > > <NEW>A called endpoint may choose to repeat the > exact same > fastStart > > element in all subsequent message up to > > and including Connect. Calling endpoints shall > react to the > first > > fastStart element received in a response message > > to the Setup message and ignore any eventual subsequent > fastStart > > elements. > > > > If somebody manages to get it wrong after that, they > deserve to be > taken > > out of business. > > > > I completely disagree with your assertion that we must choose > either one > > or many. Currently some implementations send one, > > others send many, and we don't see interoperability problems. > > > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > 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 > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

2 1

APC 2009 uploaded
by Espen Skj�ran 02 Nov '00

02 Nov '00

Hi all, APC 2009 (Use of Call Independent Signalling for Service Control) has now been uploaded to the Incoming directory on the pictel site. It proposes some minor additions to Annex K in order to mention the possible use of a call independent connection to transport the URLs. Regards, Espen Skjæran ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

v4 dependent on v2?
by Paul Long 02 Nov '00

02 Nov '00

(While reviewing H.323v4 for a tunneling thread over on the implementors reflector, I noticed a few unrelated things that concern me to varying degrees. I'll discuss them in separate emails to make it easier to follow the ensuing threads.) Annexes E and F in H.323v4 are dependent on normative behavior defined in H.323v2 (see below for examples). Besides being rather strange, is this even possible because the ITU-T only publishes a single version of a Recommendation at any one time. For example, when v4 is Decided and published, there is no v3, v2 or v1. How can one implement H.323v4 when v2 (or v3 or v1) is not officially available or even in existence? Annex E: "H.245 shall be transmitted using the H.323 version 2 (1998) H.245 Tunnelling procedures." Annex F: "If further H.245 signalling is required, they shall perform tunnelling as defined in Recommendation H.225.0 (1998)." Paul Long ipDialog ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

2 2

Tunneling in fastStart?
by Paul Long 02 Nov '00

02 Nov '00

This sentence doesn't make sense to me. It seems to be saying that H.245 Tunneling involves the use of the fastStart component whereas H.245 Tunneling and Fast Connect are actually completely independent facilities. Is it just using the term, "tunneling," in a general sense and not in reference to "H.245 Tunneling?" Annex F.10/H.323v4: "NOTE All these messages are transmitted as tunnelled H.245 messages; i.e. the resulting bit patterns are encoded as a single OCTET STRING of the SEQUENCE in the fastStart component of a H323-UU-PDU." Paul Long ipDialog ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0