Re: Force remote to start H.245 session?
Chris,
I think you see my point, then. Now that I think about it, an EP _is_ required to at least send its TCS, if it has not already, if it receives an H.245 request message. Specifically, it cannot send the TCSAck until it has sent its own TCS, according to the following:
8.2/H.323v3: "Endpoint system capabilities are exchanged by transmission of the H.245 terminalCapabilitySet message. This capability message shall be the first H.245 message sent."
And then there's the following. I think it means that if an EP receives TCS without already having sent TCS itself, it shall do so now. Is that your understanding?
8.2/H.323v3: "An endpoint which receives a terminalCapabilitySet message from a peer prior to initiating capabilities exchange shall respond as required by 6.2.8.1, and should initiate and successfully complete capabilities exchange with that peer prior to initiating any other procedure."
So if an EP initiates H.245 procedures, the remote is forced to also perform H.245 procedures. Okay, that's what I was looking for. Maybe it just means that it has to perform the cap exchange. You know, both sides don't really need to initiate the MSD. It's enough that the side that first wanted to use H.245 procedures has performed it, so TCS alone is enough of a prelude to get the H.245 session up and running. Do you think this needs clarification text?
Paul Long Smith Micro Software, Inc.
-----Original Message----- From: Chris Wayman Purvis [mailto:cwp@isdn-comms.co.uk] Sent: Monday, April 03, 2000 8:00 AM To: Paul Long Subject: Re: Force remote to start H.245 session?
Paul,
First of all, sorry for the fact that this seems to be a week-old mail I'm finally responding to...
I may have misunderstood, but I don't understand why this is necessary. If both endpoints have expressed willingness to use tunnelled H.245, why can an endpoint not simply start sending H.245 messages (of COURSE starting with TCS, and potentially tunnelled in purpose-built FACILITY messages) when it wishes to start a tunnelled H.245 session? I would have thought that would be a pretty clear indication of intent to start a tunnelled H.245 session!
FACILITY/reason=startH245 is required for separate H.245 connections because an endpoint may not know an address at its interlocutor to use to initiate an H.245 connection. This problem doesn't exist in tunnelled H.245, so I see no necessity for the extra interpretation!
We may want some extra text specifying behaviour at the start of an H.245 session, to ensure that the destination of the initial tunnelled H.245 message actually does something constructive (sends a TCS) rather than non-constructive (merely Acking the TCS it's been sent and not advancing anything useful).
Regards, Chris
Paul,
I think you see my point, then. Now that I think about it, an EP _is_ required to at least send its TCS, if it has not already, if it receives an H.245 request message. Specifically, it cannot send the TCSAck until it has sent its own TCS, according to the following:
8.2/H.323v3: "Endpoint system capabilities are exchanged by transmission of the H.245 terminalCapabilitySet message. This capability message shall be the first H.245 message sent."
That's what I thought, although I didn't have the reference to hand...
And then there's the following. I think it means that if an EP receives TCS without already having sent TCS itself, it shall do so now. Is that your understanding?
8.2/H.323v3: "An endpoint which receives a terminalCapabilitySet message from a peer prior to initiating capabilities exchange shall respond as required by 6.2.8.1, and should initiate and successfully complete capabilities exchange with that peer prior to initiating any other procedure."
Let's just say that your interpretation is not so much my "understanding" of that text as its "intention" when Dave Walker and I wrote that passage...
So if an EP initiates H.245 procedures, the remote is forced to also perform H.245 procedures. Okay, that's what I was looking for. Maybe it just means that it has to perform the cap exchange. You know, both sides don't really need to initiate the MSD. It's enough that the side that first wanted to use H.245 procedures has performed it, so TCS alone is enough of a prelude to get the H.245 session up and running. Do you think this needs clarification text?
As long as MSD is completed that's fine. I agree there's no point in it being initiated by each side. Is that required somewhere? The intention was that one should always do one's best to get MSD out of the way "as soon as possible", but TCS must happen (or at least start...!) first.
Regards, Chris -- 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
Chris,
Hey, we're in luck! Only one side is required to initiate MSD:
8.2/H.323v3: "Master-slave determination shall be advanced (by sending either MasterSlaveDetermination or MasterSlaveDeterminationAck as appropriate) in the first H.245 message after Terminal Capability Exchange has been initiated."
So we're all set. If an EP initiates TCS, regardless of the transport, the remote EP is required to respond in kind if it has not previously done so. Since the remote EP is not required to initiate its own MSD, the EP that initiated TCS should also then initiate MSD. Once the two MSDAcks are done, the H.245 session is up.
Note, however, that section 8.2 indicates that an EP cannot respond to the TCS message without first having sent its own TCS. Guessing how most stacks are probably written, it would probably not cause interoperability problems to first respond to the TCS then send your own TCS.
Paul Long Smith Micro Software, Inc.
-----Original Message----- From: Chris Wayman Purvis [mailto:cwp@ISDN-COMMS.CO.UK] Sent: Tuesday, April 04, 2000 4:40 AM To: ITU-SG16@MAILBAG.INTEL.COM Subject: Re: Force remote to start H.245 session?
Paul,
I think you see my point, then. Now that I think about it, an EP _is_ required to at least send its TCS, if it has not already, if it
receives an
H.245 request message. Specifically, it cannot send the TCSAck until
it has
sent its own TCS, according to the following:
8.2/H.323v3: "Endpoint system capabilities are exchanged by
transmission of
the H.245 terminalCapabilitySet message. This capability message shall
be
the first H.245 message sent."
That's what I thought, although I didn't have the reference to hand...
And then there's the following. I think it means that if an EP
receives TCS
without already having sent TCS itself, it shall do so now. Is that
your
understanding?
8.2/H.323v3: "An endpoint which receives a terminalCapabilitySet
message
from a peer prior to initiating capabilities exchange shall respond
as
required by 6.2.8.1, and should initiate and successfully complete capabilities exchange with that peer prior to initiating any other procedure."
Let's just say that your interpretation is not so much my "understanding" of that text as its "intention" when Dave Walker and I wrote that passage...
So if an EP initiates H.245 procedures, the remote is forced to also
perform
H.245 procedures. Okay, that's what I was looking for. Maybe it just
means
that it has to perform the cap exchange. You know, both sides don't
really
need to initiate the MSD. It's enough that the side that first wanted
to use
H.245 procedures has performed it, so TCS alone is enough of a prelude
to
get the H.245 session up and running. Do you think this needs
clarification
text?
As long as MSD is completed that's fine. I agree there's no point in it being initiated by each side. Is that required somewhere? The intention was that one should always do one's best to get MSD out of the way "as soon as possible", but TCS must happen (or at least start...!) first.
Regards, Chris -- 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
Paul,
Hey, we're in luck! Only one side is required to initiate MSD:
8.2/H.323v3: "Master-slave determination shall be advanced (by sendingeither MasterSlaveDetermination or MasterSlaveDeterminationAck as appropriate) in the first H.245 message after Terminal Capability Exchange has been initiated."
So Dave and I got it right in Monterey. Thank heavens for that!
Note, however, that section 8.2 indicates that an EP cannot respond to the TCS message without first having sent its own TCS. Guessing how most stacks are probably written, it would probably not cause interoperability problems to first respond to the TCS then send your own TCS.
Take the usual line about being strict about what you do and lax about what you understand...
Regards, Chris -- 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
participants (2)
-
Chris Wayman Purvis -
Paul Long