Re: LogicalChannelRate Messages
Aseem, Paul and all,
LogicalChanelRate SDL should be very similar to any request/response pair like Paul mentioned. This was an Intel contribution for controlling video/data channel bitrate. I will consider bringing a clarification contribution to version 6 maybe and the implementers guide in an upcoming Rapporteur meeting. Yes releaseComplete should have a cookie to address the active SDL. I didn't want to deviate from the legacy :). I will address this issue as well. Thanks for the reminder. regards,
Hani
-----Original Message----- From: Paul Long [mailto:plong@SMITHMICRO.COM] Sent: Wednesday, November 10, 1999 10:57 AM To: ITU-SG16@MAILBAG.INTEL.COM Subject: Re: LogicalChannelRate Messages
Aseem,
Good point. Looks like an oversight. Using the other signaling entities, or SEs, as a guide, it appears that when there is a single SE per call, as is the case with CESE, no other information is required; however, when there can be multiple SEs per call, as is the case with CLCSE, RMSE, _and our "LCRSE"_, one must identify which instance of the incoming SE in the remote EP is being released.
As a practical matter, I would say that upon receipt of LogicalChannelRateRelease as it is currently defined in H.245v5, an EP should release _all_ incoming SEs. At the earliest opportunity, we should add a logical-channel-number extension addition to this message, i.e.,
LogicalChannelRateRelease ::=SEQUENCE { ..., logicalChannelNumber LogicalChannelNumber }
BTW, If we had gone to the trouble of defining an SE for these messages, I bet this oversight would have been caught in time.
Paul Long Smith Micro Software, Inc.
-----Original Message----- From: Aseem Agarwal [mailto:aseem@trillium.com] Sent: Wednesday, November 10, 1999 12:40 PM To: plong@SMITHMICRO.COM Cc: h323implementors@imtc.org Subject: Re: LogicalChannelRate Messages
hi Paul
A related question. There are no "sequence number and logical channel number" information elements in LogicalChannelRateRelease message. How will a receiving entity correctly associate this message to the request message received earlier in case multiple such requests are pending ?
regards, aseem
Hani,
I forgot to note that the new component should be OPTIONAL:
LogicalChannelRateRelease ::=SEQUENCE { ..., logicalChannelNumber LogicalChannelNumber OPTIONAL }
We should also add wording to the effect that if logicalChannelNumber is not present, this message applies to _all_ LogicalChannelRateRequests for which replies have not yet been sent. This would remove the current ambiguity from H.245v5 and v6.
Paul Long Smith Micro Software, Inc.
-----Original Message----- From: El-Gebaly, Hani [mailto:hani.el-gebaly@INTEL.COM] Sent: Wednesday, November 10, 1999 1:13 PM To: ITU-SG16@MAILBAG.INTEL.COM Subject: Re: LogicalChannelRate Messages
Aseem, Paul and all,
LogicalChanelRate SDL should be very similar to any request/response pair like Paul mentioned. This was an Intel contribution for controlling video/data channel bitrate. I will consider bringing a clarification contribution to version 6 maybe and the implementers guide in an upcoming Rapporteur meeting. Yes releaseComplete should have a cookie to address the active SDL. I didn't want to deviate from the legacy :). I will address this issue as well. Thanks for the reminder. regards,
Hani
-----Original Message----- From: Paul Long [mailto:plong@SMITHMICRO.COM] Sent: Wednesday, November 10, 1999 10:57 AM To: ITU-SG16@MAILBAG.INTEL.COM Subject: Re: LogicalChannelRate Messages
Aseem,
Good point. Looks like an oversight. Using the other signaling entities, or SEs, as a guide, it appears that when there is a single SE per call, as is the case with CESE, no other information is required; however, when there can be multiple SEs per call, as is the case with CLCSE, RMSE, _and our "LCRSE"_, one must identify which instance of the incoming SE in the remote EP is being released.
As a practical matter, I would say that upon receipt of LogicalChannelRateRelease as it is currently defined in H.245v5, an EP should release _all_ incoming SEs. At the earliest opportunity, we should add a logical-channel-number extension addition to this message, i.e.,
LogicalChannelRateRelease ::=SEQUENCE { ..., logicalChannelNumber LogicalChannelNumber }
BTW, If we had gone to the trouble of defining an SE for these messages, I bet this oversight would have been caught in time.
Paul Long Smith Micro Software, Inc.
-----Original Message----- From: Aseem Agarwal [mailto:aseem@trillium.com] Sent: Wednesday, November 10, 1999 12:40 PM To: plong@SMITHMICRO.COM Cc: h323implementors@imtc.org Subject: Re: LogicalChannelRate Messages
hi Paul
A related question. There are no "sequence number and logical channel number" information elements in LogicalChannelRateRelease message. How will a receiving entity correctly associate this message to the request message received earlier in case multiple such requests are pending ?
regards, aseem
Hi Paul
IMO, SequenceNumber and LogicalChannelNumber, both the elements are required in LogicalChannelRateRelease message to take care of cases when multiple LogicalChannelRateRequest messages are pending on a single logical channel.
Both these elements should be mandatory like in other LogicalChannelRate message.
thanks, aseem
Hani,
I forgot to note that the new component should be OPTIONAL:
LogicalChannelRateRelease ::=SEQUENCE { ..., logicalChannelNumber LogicalChannelNumber OPTIONAL }
We should also add wording to the effect that if logicalChannelNumber is not present, this message applies to _all_ LogicalChannelRateRequests for which replies have not yet been sent. This would remove the current ambiguity from H.245v5 and v6.
Paul Long Smith Micro Software, Inc.
-----Original Message----- From: El-Gebaly, Hani [mailto:hani.el-gebaly@INTEL.COM] Sent: Wednesday, November 10, 1999 1:13 PM To: ITU-SG16@MAILBAG.INTEL.COM Subject: Re: LogicalChannelRate Messages
Aseem, Paul and all,
LogicalChanelRate SDL should be very similar to any request/response pair like Paul mentioned. This was an Intel contribution for controlling video/data channel bitrate. I will consider bringing a clarification contribution to version 6 maybe and the implementers guide in an upcoming Rapporteur meeting. Yes releaseComplete should have a cookie to address the active SDL. I didn't want to deviate from the legacy :). I will address this issue as well. Thanks for the reminder. regards,
Hani
-----Original Message----- From: Paul Long [mailto:plong@SMITHMICRO.COM] Sent: Wednesday, November 10, 1999 10:57 AM To: ITU-SG16@MAILBAG.INTEL.COM Subject: Re: LogicalChannelRate Messages
Aseem,
Good point. Looks like an oversight. Using the other signaling entities, or SEs, as a guide, it appears that when there is a single SE per call, as is the case with CESE, no other information is required; however, when there can be multiple SEs per call, as is the case with CLCSE, RMSE, _and our "LCRSE"_, one must identify which instance of the incoming SE in the remote EP is being released.
As a practical matter, I would say that upon receipt of LogicalChannelRateRelease as it is currently defined in H.245v5, an EP should release _all_ incoming SEs. At the earliest opportunity, we should add a logical-channel-number extension addition to this message, i.e.,
LogicalChannelRateRelease ::=SEQUENCE { ..., logicalChannelNumber LogicalChannelNumber }
BTW, If we had gone to the trouble of defining an SE for these messages, I bet this oversight would have been caught in time.
Paul Long Smith Micro Software, Inc.
-----Original Message----- From: Aseem Agarwal [mailto:aseem@trillium.com] Sent: Wednesday, November 10, 1999 12:40 PM To: plong@SMITHMICRO.COM Cc: h323implementors@imtc.org Subject: Re: LogicalChannelRate Messages
hi Paul
A related question. There are no "sequence number and logical channel number" information elements in LogicalChannelRateRelease message. How will a receiving entity correctly associate this message to the request message received earlier in case multiple such requests are pending ?
regards, aseem
Aseem,
I disagree. None of the other SEs include sequenceNumber in the release message. This is because sequenceNumber is used solely to uniquely identify a response as belonging to a request for the benefit of the _initiator_ of the procedure. The receiver of the request message only needs to return the sequenceNumber in its replies--it does not need it to identify an incoming SE. In the case of our "LCRSE," the logicalChannelNumber uniquely identifies the incoming SE instance.
Just like the LCSE, there is one SE per channel, not one SE per request. (C.4.1/H.245v5: "At each of the outgoing and incoming sides there is one instance of the LCSE for each uni-directional logical channel.") One SE per request, which is essentially what you are proposing, would make our stacks needlessly complex.
As evidenced by the other SEs which we successful use all the time, logicalChannelNumber is sufficient to identify which incoming SE to release.
Paul Long Smith Micro Software, Inc.
-----Original Message----- From: Aseem Agarwal [mailto:aseem@TRILLIUM.COM] Sent: Wednesday, November 10, 1999 8:02 PM To: ITU-SG16@MAILBAG.INTEL.COM Subject: Re: LogicalChannelRate Messages
Hi Paul
IMO, SequenceNumber and LogicalChannelNumber, both the elements are required in LogicalChannelRateRelease message to take care of cases when multiple LogicalChannelRateRequest messages are pending on a single logical channel.
Both these elements should be mandatory like in other LogicalChannelRate message.
thanks, aseem
Hani,
I forgot to note that the new component should be OPTIONAL:
LogicalChannelRateRelease ::=SEQUENCE { ..., logicalChannelNumber LogicalChannelNumber OPTIONAL }
We should also add wording to the effect that if logicalChannelNumber
is not
present, this message applies to _all_ LogicalChannelRateRequests for
which
replies have not yet been sent. This would remove the current
ambiguity from
H.245v5 and v6.
Paul Long Smith Micro Software, Inc.
-----Original Message----- From: El-Gebaly, Hani [mailto:hani.el-gebaly@INTEL.COM] Sent: Wednesday, November 10, 1999 1:13 PM To: ITU-SG16@MAILBAG.INTEL.COM Subject: Re: LogicalChannelRate Messages
Aseem, Paul and all,
LogicalChanelRate SDL should be very similar to any request/response pair like Paul mentioned. This was an Intel contribution for
controlling
video/data channel bitrate. I will consider bringing a clarification contribution to version 6 maybe and the implementers guide in an upcoming Rapporteur meeting. Yes releaseComplete should have a cookie
to
address the active SDL. I didn't want to deviate from the legacy :). I will address this issue as well. Thanks for the reminder. regards,
Hani
-----Original Message----- From: Paul Long [mailto:plong@SMITHMICRO.COM] Sent: Wednesday, November 10, 1999 10:57 AM To: ITU-SG16@MAILBAG.INTEL.COM Subject: Re: LogicalChannelRate Messages
Aseem,
Good point. Looks like an oversight. Using the other signaling
entities,
or SEs, as a guide, it appears that when there is a single SE per call,
as
is the case with CESE, no other information is required; however, when there can be multiple SEs per call, as is the case with CLCSE, RMSE, _and
our
"LCRSE"_, one must identify which instance of the incoming SE in the remote EP is being released.
As a practical matter, I would say that upon receipt of LogicalChannelRateRelease as it is currently defined in H.245v5, an EP should release _all_ incoming SEs. At the earliest opportunity, we should add a logical-channel-number extension addition to this message, i.e.,
LogicalChannelRateRelease ::=SEQUENCE { ..., logicalChannelNumber LogicalChannelNumber }
BTW, If we had gone to the trouble of defining an SE for these
messages,
I bet this oversight would have been caught in time.
Paul Long Smith Micro Software, Inc.
-----Original Message----- From: Aseem Agarwal [mailto:aseem@trillium.com] Sent: Wednesday, November 10, 1999 12:40 PM To: plong@SMITHMICRO.COM Cc: h323implementors@imtc.org Subject: Re: LogicalChannelRate Messages
hi Paul
A related question. There are no "sequence number and logical channel number" information elements in LogicalChannelRateRelease message. How will a receiving entity correctly associate this message to the
request
message received earlier in case multiple such requests are pending ?
regards, aseem
participants (3)
-
Aseem Agarwal
-
El-Gebaly, Hani
-
Paul Long