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@mailbag.intel.com
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@PACKETIZER.COM To: ITU-SG16@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 theearlyH245Control 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@mailbag.intel.com
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv@mailbag.intel.com
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@PACKETIZER.COM To: ITU-SG16@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 understandsthe
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 theearlyH245Control 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@mailbag.intel.comFor help on this mail list, send "HELP ITU-SG16" in a message to listserv@mailbag.intel.com
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv@mailbag.intel.com
Douglas,
TCS-first has always been required, and I don't think it can be stated any clearer than it already is ("...the H.245 terminalCapabilitySet message ... shall be the first H.245 message sent.") That said, however, it is, IMO, an artificial requirement as evidence by the fact that many implementations ignore it and do indeed ack the remote's TCS before sending their TCS without causing any apparent interoperability problems. That doesn't mean it is okay to do this, just that I do not know of a problem this has caused, which is not to say that it hasn't caused problems or will not in the future.
Speaking of the future, I'd be willing to bet that this _will_ cause problems for Early H.245 because a v4+ EP might misinterpret the TCSAck-first from a non-compliant pre-v4 EP--and there are lots of them out there--as accepting Early H.245. It was probably not a good idea to use something so subtle as whether TCS or TCSAck is the first message to indicate acceptance of Early H.245.
Paul Long ipDialog
-----Original Message----- From: Douglas Clowes [mailto:dclowes@DINGOBLUE.NET.AU] Sent: Friday, November 03, 2000 6:05 PM To: ITU-SG16@MAILBAG.INTEL.COM Subject: Re: TCS is always first message, not TCSAck
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
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv@mailbag.intel.com
Paul and Douglas,
I want to make sure there are no problems with the text defined in 8.2.4/H.323v4 ("Early H.245").
The Early H.245 field is in a special field inside the Setup message typically used only with Fast Connect. If the called endpoint understands this, it shall reply with a TCSAck as the first H.245 message: that is a requirement in that section of text. If it does not understand that field, it may reply with something else.
If we were using one of the pre-existing fields in v3/2/1, I'd agree that the order of messages would be problematic, but this field can only be interpreted by a V4 device and the order of messages is explicit (I hope). Do you believe that there are problem? It seems solid to me.
Paul
----- Original Message ----- From: "Paul Long" plong@PACKETIZER.COM To: ITU-SG16@mailbag.cps.intel.com Sent: Saturday, November 04, 2000 12:21 PM Subject: Re: TCS is always first message, not TCSAck
Douglas,
TCS-first has always been required, and I don't think it can be stated any clearer than it already is ("...the H.245 terminalCapabilitySet message
...
shall be the first H.245 message sent.") That said, however, it is, IMO,
an
artificial requirement as evidence by the fact that many implementations ignore it and do indeed ack the remote's TCS before sending their TCS without causing any apparent interoperability problems. That doesn't mean
it
is okay to do this, just that I do not know of a problem this has caused, which is not to say that it hasn't caused problems or will not in the future.
Speaking of the future, I'd be willing to bet that this _will_ cause problems for Early H.245 because a v4+ EP might misinterpret the TCSAck-first from a non-compliant pre-v4 EP--and there are lots of them
out
there--as accepting Early H.245. It was probably not a good idea to use something so subtle as whether TCS or TCSAck is the first message to indicate acceptance of Early H.245.
Paul Long ipDialog
-----Original Message----- From: Douglas Clowes [mailto:dclowes@DINGOBLUE.NET.AU] Sent: Friday, November 03, 2000 6:05 PM To: ITU-SG16@MAILBAG.INTEL.COM Subject: Re: TCS is always first message, not TCSAck
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
For help on this mail list, send "HELP ITU-SG16" in a message to listserv@mailbag.intel.com
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv@mailbag.intel.com
Paul,
Oh, I see. A pre-v4 EP would not even see the Early H.245 TCS, so it could never--even by mistake--respond to Setup with a tunneled TCSAck. I would still like it reiterated in H.323v4 that TCSAck-first is not normal behavior because this might be lost on some people, e.g., those who currently (incorrectly) do TCSAck-first, while implementing v4.
For example, after this sentence in the 4th paragraph of 8.2.4/H.323v4: "This response message should be sent by the called entity at the same time that fastConnectRefused or fastStart is sent to the calling entity.", add this sentence: "Note that if an endpoint is not indicating that it understands the earlyH245Control field, it shall abide by section 8.2 and send TerminalCapabiltySet and not TerminalCapabilitySetAck as the first H.245 message."
We also need to change 8.2/H.323v4 in the following way ("[...]"=insert): "This capability message shall be the first H.245 message sent[ unless the endpoint is indicating that it understands the earlyH245Control field (see section 8.2.4)]."
Regarding Douglas' concern, regardless of whether "an EP _should_ be able to ack a received message, even before sending TCS" (emphasis mine), the fact remains that it _shall not_ do this, except when indicating that it understands earlyH245Control. The solution to the particular problem he mentions is for the endpoint to send an "almost empty" TCS, or "TCS=0.5" :-). All it contains is sequenceNumber, protocolIdentifier, and--here's the important part--multiplexCapability. In particular, it doesn't need to contain capabilityTable or capabilityDescriptors, and the multiplexCapability can provide only minimal information. Including multiplexCapability means that it is not an empty TCS and therefore cannot be mistaken for one, but the endpoint also does not need to know its eventual capabilities at call-startup time.
Paul Long ipDialog
-----Original Message----- From: Paul E. Jones [mailto:paulej@packetizer.com] Sent: Saturday, November 04, 2000 8:21 PM To: plong@ipdialog.com; ITU-SG16@mailbag.cps.intel.com Cc: Douglas Clowes; François Audet Subject: Re: Re: TCS is always first message, not TCSAck
Paul and Douglas,
I want to make sure there are no problems with the text defined in 8.2.4/H.323v4 ("Early H.245").
The Early H.245 field is in a special field inside the Setup message typically used only with Fast Connect. If the called endpoint understands this, it shall reply with a TCSAck as the first H.245 message: that is a requirement in that section of text. If it does not understand that field, it may reply with something else.
If we were using one of the pre-existing fields in v3/2/1, I'd agree that the order of messages would be problematic, but this field can only be interpreted by a V4 device and the order of messages is explicit (I hope). Do you believe that there are problem? It seems solid to me.
Paul
----- Original Message ----- From: "Paul Long" plong@PACKETIZER.COM To: ITU-SG16@mailbag.cps.intel.com Sent: Saturday, November 04, 2000 12:21 PM Subject: Re: TCS is always first message, not TCSAck
Douglas,
TCS-first has always been required, and I don't think it can be stated any clearer than it already is ("...the H.245 terminalCapabilitySet message
...
shall be the first H.245 message sent.") That said, however, it is, IMO,
an
artificial requirement as evidence by the fact that many implementations ignore it and do indeed ack the remote's TCS before sending their TCS without causing any apparent interoperability problems. That doesn't mean
it
is okay to do this, just that I do not know of a problem this has caused, which is not to say that it hasn't caused problems or will not in the future.
Speaking of the future, I'd be willing to bet that this _will_ cause problems for Early H.245 because a v4+ EP might misinterpret the TCSAck-first from a non-compliant pre-v4 EP--and there are lots of them
out
there--as accepting Early H.245. It was probably not a good idea to use something so subtle as whether TCS or TCSAck is the first message to indicate acceptance of Early H.245.
Paul Long ipDialog
-----Original Message----- From: Douglas Clowes [mailto:dclowes@DINGOBLUE.NET.AU] Sent: Friday, November 03, 2000 6:05 PM To: ITU-SG16@MAILBAG.INTEL.COM Subject: Re: TCS is always first message, not TCSAck
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
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv@mailbag.intel.com
Paul,
Ugly! That leaves open the decision, for the receiver of the TCS, of when you give up on a call because you do not have compatible capabilities.
I can see that an empty-ish TCS could be distinguished from a TCS that isn't empty, but contains codecs I can't match. But how many EPs out there would already appreciate the distinction? If I send TCS 0.5, will my peer drop the call?
Ugly!
Douglas
At 21:13 04/11/2000 -0600, Paul Long wrote:
Regarding Douglas' concern, regardless of whether "an EP _should_ be able to ack a received message, even before sending TCS" (emphasis mine), the fact remains that it _shall not_ do this, except when indicating that it understands earlyH245Control. The solution to the particular problem he mentions is for the endpoint to send an "almost empty" TCS, or "TCS=0.5" :-). All it contains is sequenceNumber, protocolIdentifier, and--here's the important part--multiplexCapability. In particular, it doesn't need to contain capabilityTable or capabilityDescriptors, and the multiplexCapability can provide only minimal information. Including multiplexCapability means that it is not an empty TCS and therefore cannot be mistaken for one, but the endpoint also does not need to know its eventual capabilities at call-startup time.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv@mailbag.intel.com
Douglas,
Sorry, but this is the only compliant, backward-compatible solution I can think of.
Paul Long ipDialog
-----Original Message----- From: Douglas Clowes [mailto:dclowes@DINGOBLUE.NET.AU] Sent: Sunday, November 05, 2000 6:31 AM To: ITU-SG16@MAILBAG.INTEL.COM Subject: Re: TCS is always first message, not TCSAck
Paul,
Ugly! That leaves open the decision, for the receiver of the TCS, of when you give up on a call because you do not have compatible capabilities.
I can see that an empty-ish TCS could be distinguished from a TCS that isn't empty, but contains codecs I can't match. But how many EPs out there would already appreciate the distinction? If I send TCS 0.5, will my peer drop the call?
Ugly!
Douglas
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv@mailbag.intel.com
Doug,
If you don't like Paul's solution (it does have the flaw that a device controlled by UIIs looks like something that doesn't terminate the call - not that I see WHY that is a problem), then you do have an alternative. If you don't know the capabilities of the final destination of the call by this point you won't lose a lot by using good old-fashioned H.245-in-a-separate-TCP-stream!
Regards, Chris
Douglas Clowes wrote:
Paul,
Ugly! That leaves open the decision, for the receiver of the TCS, of when you give up on a call because you do not have compatible capabilities.
I can see that an empty-ish TCS could be distinguished from a TCS that isn't empty, but contains codecs I can't match. But how many EPs out there would already appreciate the distinction? If I send TCS 0.5, will my peer drop the call?
Ugly!
Douglas
At 21:13 04/11/2000 -0600, Paul Long wrote:
Regarding Douglas' concern, regardless of whether "an EP _should_ be able to ack a received message, even before sending TCS" (emphasis mine), the fact remains that it _shall not_ do this, except when indicating that it understands earlyH245Control. The solution to the particular problem he mentions is for the endpoint to send an "almost empty" TCS, or "TCS=0.5" :-). All it contains is sequenceNumber, protocolIdentifier, and--here's the important part--multiplexCapability. In particular, it doesn't need to contain capabilityTable or capabilityDescriptors, and the multiplexCapability can provide only minimal information. Including multiplexCapability means that it is not an empty TCS and therefore cannot be mistaken for one, but the endpoint also does not need to know its eventual capabilities at call-startup time.
For help on this mail list, send "HELP ITU-SG16" in a message to listserv@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@mailbag.intel.com
Another option is a TCS 0.6 which contains a token Transmit capability, say G.711. Endpoints should accept this as they might have ended up connected to an announcement IVR.
Pete.
============================================= Pete Cordell Tech-Know-Ware pete@tech-know-ware.com +44 1473 635863 =============================================
----- Original Message ----- From: Douglas Clowes dclowes@DINGOBLUE.NET.AU To: ITU-SG16@mailbag.cps.intel.com Sent: 05 November 2000 12:30 Subject: Re: TCS is always first message, not TCSAck
Paul,
Ugly! That leaves open the decision, for the receiver of the TCS, of when you give up on a call because you do not have compatible capabilities.
I can see that an empty-ish TCS could be distinguished from a TCS that isn't empty, but contains codecs I can't match. But how many EPs out there would already appreciate the distinction? If I send TCS 0.5, will my peer drop the call?
Ugly!
Douglas
At 21:13 04/11/2000 -0600, Paul Long wrote:
Regarding Douglas' concern, regardless of whether "an EP _should_ be able
to
ack a received message, even before sending TCS" (emphasis mine), the
fact
remains that it _shall not_ do this, except when indicating that it understands earlyH245Control. The solution to the particular problem he mentions is for the endpoint to send an "almost empty" TCS, or "TCS=0.5" :-). All it contains is sequenceNumber, protocolIdentifier, and--here's
the
important part--multiplexCapability. In particular, it doesn't need to contain capabilityTable or capabilityDescriptors, and the multiplexCapability can provide only minimal information. Including multiplexCapability means that it is not an empty TCS and therefore
cannot
be mistaken for one, but the endpoint also does not need to know its eventual capabilities at call-startup time.
For help on this mail list, send "HELP ITU-SG16" in a message to listserv@mailbag.intel.com
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv@mailbag.intel.com
participants (5)
-
Chris Wayman Purvis -
Douglas Clowes -
Paul E. Jones -
Paul Long -
Pete Cordell