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

Revised H.248 Annex M (Advanced Audio Server packages)
by Tom-PT Taylor 09 Nov '00

09 Nov '00

Dear Dr. Okubo-san: I have uploaded a new draft of H.248 Annex M (Advanced Audio Server packages) in the Incoming directory of the PictureTel site. I realize it is too late for consideration at the present meeting, but please assign an APC number so it can be reviewed at a future date. Tom Taylor +1 613 736 0961 taylor(a)nortelnetworks.com

2 1

�ظ�: About "FACILITY message"
by XuPeili 08 Nov '00

08 Nov '00

hi kadota, -----Original Message----- ��: $BLgED (B $B=_ (B <kadota(a)REL.TRL.MEI.CO.JP>) < $BLgED (B $B=_ (B <kadota(a)REL.TRL.MEI.CO.JP>)> �ռ��: ITU-SG16(a)MAILBAG.INTEL.COM <ITU-SG16(a)MAILBAG.INTEL.COM> ��: 2000��11��8�� 16:03 ��: About "FACILITY message" >Might I ask a question ? >I read "8.2.1 Encapsulation of H.245 Messages within Q.931 Messages" >in ITU-T RECOMMENDATION H.323. > >The document says, > >"When tunneling is active, one or more H.245 messages can be encapsulated in >any Q.931 message. If tunneling is being utilized and there is no need for >transmission of a Q.931 message at the time an H.245 message must be >transmitted, then a FACILITY message shall be sent with h323-message-body >set to empty." > >The encapsulation of H.245 messages is done in the Fast Connect Procedure. >Most of the H.245 channel establishment is accomplished in the Fast Connect >procedure. Fast Connect is totally different from H.245 tunneling, they can not coexist. > But there may be H.245 messages that may occur after call >establishment that may be sent using the Facility message. > >I want to know exactly what are such H.245 messages. >Would you tell me those or where in documents to be searched ? > The tunneled H.245 procedure such as MasterSlaveDetermination and CapabilityExchange is not necessarily complete before the Q.931 Call is established. Suppose we want to answer the MasterSlaveDeterminationRequest after Connect is already sent out, where can we tunnle the MasterSlaveDeterminationAck ? So in this situation, we should use Facility. >And, How is the typical sequence of the Fast Connect Procedure >including FACILITY messages ? > Facility is not necessary to FastConnect procedure, but if we happen to send a Facility message during the Q.931 call estabilishment procedure,we can put faststart infomation in it. >Best Regards >Atsushi Kadota >mailto: kadota(a)rel.trl.mei.co.jp > >~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >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

None
by Yaron Bartal 08 Nov '00

08 Nov '00

Sincerely, Yaron Bartal ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

About "FACILITY message"
by $BLgED＠paris.packetizer.org 08 Nov '00

08 Nov '00

Might I ask a question ? I read "8.2.1 Encapsulation of H.245 Messages within Q.931 Messages" in ITU-T RECOMMENDATION H.323. The document says, "When tunneling is active, one or more H.245 messages can be encapsulated in any Q.931 message. If tunneling is being utilized and there is no need for transmission of a Q.931 message at the time an H.245 message must be transmitted, then a FACILITY message shall be sent with h323-message-body set to empty." The encapsulation of H.245 messages is done in the Fast Connect Procedure. Most of the H.245 channel establishment is accomplished in the Fast Connect procedure. But there may be H.245 messages that may occur after call establishment that may be sent using the Facility message. I want to know exactly what are such H.245 messages. Would you tell me those or where in documents to be searched ? And, How is the typical sequence of the Fast Connect Procedure including FACILITY messages ? Best Regards Atsushi Kadota mailto: kadota(a)rel.trl.mei.co.jp ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 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 andincludingCon nect
by Callaghan, Robert 07 Nov '00

07 Nov '00

Paul, An additional consideration on this subject: In order to have a working early H.245 tunnel, I would like to make CALL PROCeeding and PROGRESS messages as mandatory understood when received in v4. Otherwise, the user will be forced to use a FACILITY message along with these messages which will increase the used bandwidth. Bob -------------------------------------------------------------- Robert Callaghan Siemens Enterprise Networks 5500 Broken Sound Blvd, Boca Raton, Fl 33487 Tel: +1 561 923-1756 Fax: +1 561 923-1403 Email: Robert.Callaghan(a)ICN.Siemens.com ----------------------------------------------------------------- -----Original Message----- From: Paul E. Jones [mailto:paulej@PACKETIZER.COM] Sent: Saturday, November 04, 2000 9:06 PM To: ITU-SG16(a)mailbag.cps.intel.com Subject: Re: fastStart element in all Q.931 messages up to andincludingConnect Bob, [snip Annex F section ] OK.. it seemed pretty clear that fastStart could be sent multiple times to reconfigure the streams. > I suppose the rule would be: if you're not a SET, ignore; if you are, react. > > (As you know, I'd like to see every endpoint process the subsequent messages > - then the SET wouldn't be so special, and the redirection problem would be > solved.) This might be ideal, but we can't even seem to come to an agreement on whether a single reply is required or multiple replies are required for fastStart. Worse, I believe people have implemented it differently, which makes the situation even more difficult. (I assume you have been observing the "debate" on the H.323 Implementers list.) Now, what was this about Fast Open again? :-) Paul ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 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

TCS is always first message, not TCSAck
by Paul Long 07 Nov '00

07 Nov '00

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

5 9

Re: fastStart element in all Q.931 messages up to andincludingCon nect
by Callaghan, Robert 06 Nov '00

06 Nov '00

Paul, First, a non-v4 endpoint would not reply to a v4 feature of early H.245 tunnel, so it cannot be lost. Second, a lost message in a GK is not good; and will result in a failure to establish the early H.245. I would still like to see this as a v4 mandatory. For then there is a possibility to have migration in support of early network features. Bob -------------------------------------------------------------- Robert Callaghan Siemens Enterprise Networks 5500 Broken Sound Blvd, Boca Raton, Fl 33487 Tel: +1 561 923-1756 Fax: +1 561 923-1403 Email: Robert.Callaghan(a)ICN.Siemens.com ----------------------------------------------------------------- -----Original Message----- From: Paul Long [mailto:plong@PACKETIZER.COM] Sent: Monday, November 06, 2000 8:53 AM To: ITU-SG16(a)mailbag.cps.intel.com Subject: Re: fastStart element in all Q.931 messages up to andincludingConnect Bob, ...and what if the EP is in communication with a pre-v4 EP or GK?. Paul Long ipDialog -----Original Message----- From: Callaghan, Robert [mailto:Robert.Callaghan@ICN.SIEMENS.COM] Sent: Monday, November 06, 2000 7:38 AM To: ITU-SG16(a)MAILBAG.INTEL.COM Subject: Re: fastStart element in all Q.931 messages up to andincludingCon nect Paul, An additional consideration on this subject: In order to have a working early H.245 tunnel, I would like to make CALL PROCeeding and PROGRESS messages as mandatory understood when received in v4. Otherwise, the user will be forced to use a FACILITY message along with these messages which will increase the used bandwidth. Bob ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 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-2026 is uploaded - Draft H.225.0 v4
by Rich Bowen 05 Nov '00

05 Nov '00

Mr. Okubo, All, APC-2026 (Draft H.225.0 v4) is uploaded to the Incoming directory. Sorry this is late ... my laptop died on Thursday and it took a couple of days to get everything restored and working again. Regards, Rich ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

Suggestion for future contributions
by Paul Long 04 Nov '00

04 Nov '00

RE: fastStart element in all Q.931 messages up to and including ConnectPaul, I have an idea about how to improve H.323 interoperability and inter-version compatibility or at least raise the visibility of these issues early in the standards process. You know how IETF RFCs and IDs are required to discuss security considerations, even if there are none? Here's the description of this in RFC2223: 9. Security Considerations Section All RFCs must contain a section near the end of the document that discusses the security considerations of the protocol or procedures that are the main topic of the RFC. How about requiring or at least strongly recommending that authors add a section to all APCs and TDs that discusses Interoperability Considerations? For example, the APC that proposed requiring v4 EPs to use H.245 Tunneling when Fast Connect is used would have had a section something like this: x. Interoperability Considerations This proposal precludes v4 and subsequent EPs from interoperating with pre-v4 EPs that support Fast Connect but do not support H.245 Tunneling. This proposal also prevents pre-v4 EPs from dependably interoperating with v4 and subsequent EPs when switching from H.245 Tunneling to a separate H.245 channel because a v4-or-subsequent EP may or may not support this switching and a pre-v4 EP which attempts to switch has no way of knowing this ahead of time. The author believes that these implementations are either non-existent or extremely rare and therefore impact on interoperability is minimized. This section would force an author to stop and consider interoperability (not that they aren't already). He or she might then reconsider submitting the contribution altogether, might modify the proposal to improve interoperability, or at least would be more aware of the impact it would have on this critical issue. It would also improve understanding by the contribution's audience because the author would presumably have a better understanding of the issues than the reader. At minimum, this should be the placeholder in all contributions: x. Interoperability Considerations Interoperability considerations are not discussed in this contribution. And this indicates that there are no problems, which would hopefully be the rule: x. Interoperability Considerations There are no known interoperability considerations. This section should be added to boilerplates. If found missing during presentation, the editor or another attendee might point this out in order to prompt discussion or a follow-up TD on interoperability. Paul Long ipDIalog

2 1

Re: fastStart element in all Q.931 messages up to and including C onnect
by Paul E. Jones 04 Nov '00

04 Nov '00

RE: fastStart element in all Q.931 messages up to and including ConnectFrancois, Noted... I'll add that to my list of corrections for H.323v4 unless somebody screams loudly. This should also be inserted into the Implementers Guide, too, I suppose. Paul ----- 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. -----Original Message----- From: Danail Kirov [mailto:DanailK@vertical.com] Sent: Tuesday, October 31, 2000 10:17 AM To: Audet, Francois [SC2:4K02:EXCH]; 'Paul E. Jones'; 'Anatoli Levine'; Paul Long Cc: h323implementors Subject: RE: fastStart element in all Q.931 messages up to and including C onnect It seems bullet-prone to me. If the called endpoint may choose to repeat the exact same fastStart element in all subsequent message up to and including Connect, then The calling endpoint may choose to expect the fastStart in Connect only. At the same time the called endpoint is not required to send fastStart in Connect and may choose not to send fastStart in Connect and as a result the calling endpoint may never get fastStart in Connect and fast connect may fail miserably. Isn't it clear that those are two mutually exclusive choices? 1.. The called endpoint is required to include the fastStart element in only one Q.931 message. 2.. The called endpoint is required to repeat the exact same fastStart element in all subsequent message up to and including Connect. There is no middle ground and no mix and matches are allowed, if we want to have bulletproof fast connect procedure. Any correction in the standard must make it clear and definite that it is either choice 1, or choice 2, but not both at the same time. Danail Kirov -----Original Message----- From: Francois Audet [mailto:audet@nortelnetworks.com] Sent: Tuesday, October 31, 2000 8:47 AM To: 'Paul E. Jones'; 'Anatoli Levine'; Paul Long Cc: h323implementors Subject: RE: fastStart element in all Q.931 messages up to and including C onnect I have not problem with your proposed addition. It seems bullet-proof to me. -----Original Message----- From: Paul E. Jones [mailto:paulej@packetizer.com] Sent: Monday, October 30, 2000 10:34 PM To: Audet, Francois [SC2:4K02:EXCH]; 'Anatoli Levine'; Paul Long Cc: h323implementors Subject: Re: fastStart element in all Q.931 messages up to and including C onnect Francois, You proposed the following textual changes (see enclosed in <NEW></NEW>): ---------------------------------------------------------------------------- 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 should react to the first fastStart element received in a response message to the Setup message and ignore any eventual subsequent fastStart elements.</NEW> ---------------------------------------------------------------------------- I don't have any problem inserting this text into H.323, but I do fear that people will rely on such repetitions and they may not happen. Indeed, I would state that an H.323 entity shall not expect more than one response to Fast Connect. I don't disagree with this text, because I always encourage developers to be very tolerant of "noise" on the wire-- and I consider repetitive data like this to be "noise". :-) You call these religious arguments... they might be, but we really need closure on this issue. Unlike the MGCP vs H.248 debates, the world can live with two media gateway control protocols. However, I don't want to see vendors split on implementation issues relating to H.323: that's not good for anybody at all. If we don't come to an agreement on it here and now, you know that we'll be correcting it as a customer fumes over interoperability issues later on. I'd much rather see us agree to something than to bring grief upon our customers. Can everyone live with the above textual changes? Do we need more? Is it well understood that there may be one and only one response containing fastStart? Paul ----- Original Message ----- From: Francois Audet To: 'Anatoli Levine' Cc: h323implementors(a)imtc.org Sent: Monday, October 30, 2000 5:51 PM Subject: RE: fastStart element in all Q.931 messages up to and including C onnect > I disagree with your claim that the stack which sends > multiple Fast Start > responses (as long as they are identical) is not compliant > with the standard - > none of the citations you used claim that ONLY ONE Q.931 > message can carry Fast > Start information. I believe that the wording should be > changed to explicitly > allow Fast Start elements to be sent in every Q.931 message > up to Connect as > long as information in those messages stays the same. Correct. That was my proposal too. I didn't keep the exact wording I had. Paul Jones probably still has it. These religious arguments over "one" or "many" are getting nowhere. It seems that sending one and sending many are a fait accomplit. Not much we can do about it except tell the implementor about it.

2 6