Suggestion for future contributions

Paul Long plong at PACKETIZER.COM
Sat Nov 4 11:54:50 EST 2000


Paul(s),

I think that the requirement to send TCS as a first message may be
ambiguous, or lead to interworking problems.

An H.323 EP may not be in a position to send TCS at all times, particularly
if it is an Interworking Facility (IWF) such as a Signalling Gateway which
does not participate in RTP. The same may also be true of a Media Gateway
Controller, which must await advice from the MG as to current capabilities
before sending TCS.

H.245 operations, such as CESE and MSDE, have timeouts. If an EP can't
acknowledge a procedure initiated by the other end, until it has sent TCS,
then timeouts are a possibility. I would expect that responses before TCS
would be required, and that TCS should be the first _request_, although I
don't see a good reason why an EP can't do MSDE before it has TCS to send.

Similarly, if each end sends TCS simultaneously, then each end will receive
TCS before TCSAck. But if one EP is not ready to send TCS, it has the
problem that if it does not ack the TCS received, it may timeout and the
call fail. So an EP should be able to ack a received message, even before
sending TCS.

Thoughts?

Douglas

At 11:32 02/11/2000 -0500, Paul E. Jones wrote:
>Paul,
>
>If the called endpoint sends a TCS message as the first tunneled message,
>did it understand the field in the Setup message that is used as part of
>what we call "Early H.245" or did it send that as part of the normal H.245
>tunneling?
>
>This is why we say that, to acknowledge the Early H.245, the first message
>much be an ack-- we have to have some distinguishing mechanism. If the first
>message received from the calling endpoint is a TCS, we know that the Early
>H.245 mechanism was not understood.
>
>It does seem, though, that the first sentence should be restricted to say
>that the first two message the calling endpoint sends are TCS and MSDet.
>Would that help?  We may need to change the few sentences to make this
>clearer.
>
>BTW, I corrected the section numbers-- the APC posted this morning should be
>correct, but if not, let me know!  (Francois beat you to the punch :-) )
>
>Paul
>
>----- Original Message -----
>From: "Paul Long" <plong at PACKETIZER.COM>
>To: <ITU-SG16 at mailbag.cps.intel.com>
>Sent: Thursday, November 02, 2000 1:38 AM
>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 at mailbag.intel.com
>>
>
>~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
>For help on this mail list, send "HELP ITU-SG16" in a message to
>listserv at mailbag.intel.com
>
>

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
For help on this mail list, send "HELP ITU-SG16" in a message to
listserv at mailbag.intel.com



More information about the sg16-avd mailing list