Re: Fast Connect & Bi Directional channels
Hi Bob
First of all I disagree that the caller determine the logicalChannelNumber for the channels from callee to caller, H.323 in 8.1.7.1 states: ..... When accepting a proposed channel for transmission from called endpoint to calling endpoint, the called endpoint shall return the corresponding OpenLogicalChannel structure to the calling endpoint, inserting a unique forwardLogicalChannelNumber into the OpenLogicalChannel structure ... .....
And the standard states nothing about forwardLogicalChannelNumber in the proposal for such channel.
So the calling entity allocates forwardLCN for channels transmitted on which it will transmit. The caller that wants to associate the accepted OLC with proposed OLC may do this only using dataType parameter and BTW this is one of the reasons why this parameter should be never changed by called entity. ---------------------------------------------------------------------------- --------------------------------------------------------- BUT, From the other hand I do agree that making forward and reverse LCN equal will work. And to be honest this is probably the least ugly solution known till know.
Unfortunately, it will require from the implementation of callee the sophisticated LCN allocation mechanism that allows allocation of LCNs while taking into account the fact that some of LCNs were preallocated for bi directional channels by the caller. Fortunately, as for now, there is just one such LCN possible!
Sasha
-----Original Message----- From: Bob Gilman [mailto:rrg@AVAYA.COM] Sent: Wednesday, December 13, 2000 7:43 PM To: ITU-SG16@mailbag.cps.intel.com Subject: Re: Fast Connect & Bi Directional channels
Sasha- I have the following comments about your four proposals: 1. Do we really loose the reverse LCN with this option, or is it just the same as the forward LCN? With this latter view, we could then invoke H.245 later on the forward and/or the reverse channels. This should work because, at the time Fast Connect is used, there would be no other channel numbers assigned to interfere. I'd hate to lose the uniqueness of the channel numbers within the offered/accepted OLCs. Also, this is exactly the same as what we do now with unidirectional channels: the caller determines the channel numbers for both the forward (calller to callee) and the reverse (callee to caller) channels. I don't believe there is any restriction in H.245 that requires the forward channel numbers to be different from the reverse channel numbers; the asymmetry of the commands and responses makes the coding unique. 2. I think using the replacementFor field should be avoided because this can adversely affect SETs. 3. I agree. 4. It's tough to add a new field at this stage - especially since it would be in H.245! What do you think? -Bob ---------------------------------------------------- Bob Gilman rrg@avaya.com +1 303 538 3868
Sasha Ruditsky wrote:
Hi Paul
First of all I want to be completely certain about the value of the forwardLogicalChannelNumber in the response to the bi-directional channel proposal.
If we agree that it should be the same value as in the corresponding field from the proposal OLC then following solutions are possible (and no one is perfect):
1 Leave everything as it is. (Loosing the ReverseLCN as I already described). 2 Use OLC.reverseLogicalChannelParameters.replacementFor as (RLCN). For me it is a little bit ugly, but excelent solution. I am almost certain that it breaks nothing in nonSET H.323. But it probably may cause problems to SET with multiple fast
starts.
3 I would really not want to do this through nonStansard fields. 4 To add new field: OLC.reverseLogicalChannelParameters.reverseLogicalChannelNumber. The only problem with this is that we need to change the H.245 syntax. In addition this field is difficult to explain from the H.245
point
of view. (I do not think we've had ever before a precedent of changing
H.245
as a result of fast start needs)
I really do not know which one I prefer.
Sasha
-----Original Message----- From: Paul E. Jones [mailto:paulej@packetizer.com] Sent: Wednesday, December 13, 2000 6:57 AM To: Sasha Ruditsky Cc: ITU-SG16@mailbag.cps.intel.com Subject: Re: Fast Connect & Bi Directional channels
Sasha,
Yes, I see your point now.. thanks for clarifying this issue for me.
This makes life more interesting, doesn't it?
So I suppose the question is one of whether we feel we need to provide
this
information or whether we do not. To keep life simpler for the H.245
state
machine, I would guess that we should do something to allow the called endpoint to return the LCN for the reverse channel. However, there
doesn't
seem to be a real clean place to provide that information. We could
always
do strange things, such as use nonStandard fields or use the "replacementFor" field in the OLC.reverseLogicalChannelParameters
structure.
What's your preference?
I would guess that the proponents of this text (who wanted it for Annex
Dv2
primarily) should have something to say regarding this.
Paul
----- Original Message ----- From: "Sasha Ruditsky" sasha@tlv.radvision.com To: "Paul E. Jones" paulej@packetizer.com Cc: ITU-SG16@mailbag.cps.intel.com Sent: Tuesday, December 12, 2000 3:28 AM Subject: RE: Fast Connect & Bi Directional channels
Hi Paul
When we open T.120 or any other bi-directional channel through the H.245 then openLogicalChannelAck message carries 2 LCNs: 1st in the forwardLogicalChannelNumber field 2nd in the reverseLogicalChannelParameters.reverseLogicalChannelNumber
field
So when opening the real H.245 channel there is no problem.
With fast start the problem exists because the openLogicalChannel
message
(the response for fast start case) has just one LCN field -- the forwardLogicalChannelNumber.
It should be decided what should be the value of this field. Currently standard says nothing about this field specifically. The H.323 states in 8.1.7.1 : "When accepting a proposed bi-directional channel for transmission between the calling endpoint and the called endpoint, the called endpoint shall return the corresponding OpenLogicalChannel structure to the calling endpoint.". In the same section before there is note: "The called endpoint is only allowed to alter fields in a proposed OpenLogicalChannel structure as specified in this section".
I believe that from the lawyer point of view the aforementioned means:
"the
forwardLogicalChannelNumber" should not be changed.
I do not know if this was exactly the intent, but if it was, it is OK
with
me, except the fact that we do not have the reverseLogicalChannelNumber field for such channel. In most cases it does work OK. The only case that may cause problem is inheritance of such channel by H.245. The reverse direction of the bi-directional H.245 channel opened in such way will not be able to be a subject of the H.245 commands and indications. I know no H.245 commands
and
indications that is impossible to work without when working with fax channel. So I do not think that we have specific problem which may
affect
fax channels opened in such way.
From other hand the procedure is (a little bit, but) broken. So at
least
this should be understood and mentioned in the standard.
--------------------------------------------------------------------------
--
The possible alternative (of cause if we do agree that the standard is unclear in this point) is two put the reverseLogicalChannelNumber into
the
forwardLogicalChannelNumber field of the accepted bi-directional
channel.
This solves the problem, but requires the caller to implement more complicated mechanism to identify to the proposed OLC for the received accepted OLC.
--------------------------------------------------------------------------
--
But in any case I just want to be able to implement this so it should be agreed what is the proper value to be put in this field.
Sasha
-----Original Message----- From: Paul E. Jones [mailto:paulej@packetizer.com] Sent: Monday, December 11, 2000 11:10 PM To: Sasha Ruditsky; ITU-SG16@mailbag.cps.intel.com Cc: Orit Levin Subject: Re: Fast Connect & Bi Directional channels
Sasha,
This logic was borrowed from the way that we open bi-directional T.120 channels, I believe. Either endpoint may signal the opening of a T.120 channel, but only one side provides the LCN. Is this same logic not sufficient?
Paul
----- Original Message ----- From: "Sasha Ruditsky" sasha@tlv.radvision.com To: ITU-SG16@mailbag.cps.intel.com Cc: "Orit Levin" orit@radvision.com; paulej@PACKETIZER.COM Sent: Monday, December 11, 2000 8:04 AM Subject: Fast Connect & Bi Directional channels
Hi
It looks like there is yet another bug in the fast start procedure. It is related to bi-directional channels establishment.
Standard says that in each bi-directional channel proposal there
should
be
unique forwardLogicalChannelNumber. Standard says nothing about the value of this field in the accepted bi-directional OLC.
It is known that bi-directional channels need 2 logical channel
numbers
(forward and reverse). I see 2 options for the value of forwardLogicalChannelNumber field in
the
accepted bi-directional OLC:
- It may be the same value as the forwardLogicalChannelNumber in the
corresponding proposal. In this case we do not have the logical channel number for the reverse direction. This works OK till we are in fast start, but after H.245 connection establishment it will be impossible to perform H.245 actions on the reverse
direction
of
the channel.
- It may be the unique logical channel number that is provided by
calling
party and identifies the channel -- the reverseLogicalChannelNumber. The problem with this is that caller does not know to which proposal
this
channel belongs. BTW The same problem exists with the unidirectional channels from
callee
to
caller and the solution is just to find the corresponding proposal, using different channel characteristics.
I personally prefer the second option because it is more correct from
the
H.245 point of view. But, In any case it should be decided which is the standard one .
Sasha
Alexander(Sasha) Ruditsky RADVision Ltd. 24 Raul Wallenberg St. Tel Aviv 69719 Israel
Tel: +972-3-645-5220 Fax: +972-3-644-2903 Direct: +972-3-645-5273 sasha@radvision.rad.co.il
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
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv@mailbag.intel.com
Sasha- Thanks for your reply. Comments below. -Bob
Sasha Ruditsky wrote:
Hi Bob
First of all I disagree that the caller determine the logicalChannelNumber for the channels from callee to caller, H.323 in 8.1.7.1 states: ..... When accepting a proposed channel for transmission from called endpoint to calling endpoint, the called endpoint shall return the corresponding OpenLogicalChannel structure to the calling endpoint, inserting a unique forwardLogicalChannelNumber into the OpenLogicalChannel structure ... .....
You're right. I missed that. What do most implementations do now for unidirectional channels? Do they pick their own (different) channel number when they return the chosen OLC; do they always pick '1', say; or do they return the number supplied by the caller? Our implementation picks its own number (always the same, but who's looking), and that seems to be accepted by most other implementations we've tested with.
And the standard states nothing about forwardLogicalChannelNumber in the proposal for such channel.
You're right again. The statement about unique channel numbers for each offered OLC is in the paragraph on caller-to-callee channels, and may be assumed to apply only to them. Perhaps we need to make this clear as well (I think we send different channel numbers in all offered OLCs.) I'd like to know what most implementations actually do before we make any changes.
So the calling entity allocates forwardLCN for channels transmitted on which it will transmit. The caller that wants to associate the accepted OLC with proposed OLC may do this only using dataType parameter and BTW this is one of the reasons why this parameter should be never changed by called entity.
This applies to the offered callee-to-caller channels because the called endpoint may change the (unspecified) forwardLCN to its own choice. That means that all proper implementations are using the dataType to make the association, so why not make the same assumption for a bidirectional channel (for which, BTW, the OLC will contain both forward and reverse logical channel parameters, I presume, since both must be given (generally) for both ends.) This would suggest that the called party could change the "forward" LCN to pass back the "reverse" LCN (and the caller can use the dataType to recognize this. I'll bet this will work in most, if not all, implementations because it would look like the callee was changing the forwardLCN in a reverse OLC, which it normallly can do. (Murphy's law says the caller would think the callee was changing the LCN on a forward-channel OLC and get really upset!)
BUT, From the other hand I do agree that making forward and reverse LCN equal will work. And to be honest this is probably the least ugly solution known till know.
Well, maybe we just do this and avoid any problems that changing the forwardLCN would cause. (Can we be assured that the callee has no other logical channels up that might conflict with the offered LCN?)
Unfortunately, it will require from the implementation of callee the sophisticated LCN allocation mechanism that allows allocation of LCNs while taking into account the fact that some of LCNs were preallocated for bi directional channels by the caller. Fortunately, as for now, there is just one such LCN possible!
Well, one for each bidirectional media stream, anyway.
Sasha
..... I suppose we should ask Paul Jones (are you listening, Paul) whether or not this might be handled in the implementors' guide.
-Bob ---------------------------------------------------- Bob Gilman rrg@avaya.com +1 303 538 3868
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv@mailbag.intel.com
Sasha, et al.,
Sorry for the last e-mail on this subject. I had not seen this one, yet. So, it appears that you agree that for bi-directional channels we can use the forward LCN as the value of the reverse LCN. I have attached the most recent documents containing corrections to H.323v4 and H.225.0v4, which includes a proposal for this item.
Please review the text and give me comments.
Best Regards, Paul
----- Original Message ----- From: "Sasha Ruditsky" sasha@TLV.RADVISION.COM To: ITU-SG16@mailbag.cps.intel.com Sent: Thursday, December 14, 2000 2:35 AM Subject: Re: Fast Connect & Bi Directional channels
Hi Bob
First of all I disagree that the caller determine the logicalChannelNumber for the channels from callee to caller, H.323 in 8.1.7.1 states: ..... When accepting a proposed channel for transmission from called endpoint to calling endpoint, the called endpoint shall return the corresponding OpenLogicalChannel structure to the calling endpoint, inserting a unique forwardLogicalChannelNumber into the OpenLogicalChannel structure ... .....
And the standard states nothing about forwardLogicalChannelNumber in the proposal for such channel.
So the calling entity allocates forwardLCN for channels transmitted on
which
it will transmit. The caller that wants to associate the accepted OLC with proposed OLC may
do
this only using dataType parameter and BTW this is one of the reasons why this parameter should be never changed by called entity.
--
BUT, From the other hand I do agree that making forward and reverse LCN equal will work. And to be honest this is probably the least ugly solution known till know.
Unfortunately, it will require from the implementation of callee the sophisticated LCN allocation mechanism that allows allocation of LCNs
while
taking into account the fact that some of LCNs were preallocated for bi directional channels by the caller. Fortunately, as for now, there is just one such LCN possible!
Sasha
-----Original Message----- From: Bob Gilman [mailto:rrg@AVAYA.COM] Sent: Wednesday, December 13, 2000 7:43 PM To: ITU-SG16@mailbag.cps.intel.com Subject: Re: Fast Connect & Bi Directional channels
Sasha- I have the following comments about your four proposals:
- Do we really loose the reverse LCN with this option, or is it just the same as the forward LCN? With this latter view, we could then invoke H.245 later on the forward and/or the reverse channels. This should work because, at the time Fast Connect is used, there would be no other channel numbers assigned to interfere. I'd hate to lose the uniqueness of the channel numbers within the offered/accepted OLCs. Also, this is exactly the same as what we do now with unidirectional channels: the caller determines the channel numbers for both the forward (calller to callee) and the reverse (callee to caller) channels. I don't believe there is any restriction in H.245 that requires the forward channel numbers to be different from the reverse channel numbers; the asymmetry of the commands and responses makes the coding unique.
- I think using the replacementFor field should be avoided because this can adversely affect SETs.
- I agree.
- It's tough to add a new field at this stage - especially since it would be in H.245!
What do you think?
-Bob
Bob Gilman rrg@avaya.com +1 303 538 3868
Sasha Ruditsky wrote:
Hi Paul
First of all I want to be completely certain about the value of the forwardLogicalChannelNumber in the response to the bi-directional
channel
proposal.
If we agree that it should be the same value as in the corresponding
field
from the proposal OLC then following solutions are possible (and no one
is
perfect):
1 Leave everything as it is. (Loosing the ReverseLCN as I already described). 2 Use OLC.reverseLogicalChannelParameters.replacementFor as (RLCN). For me it is a little bit ugly, but excelent solution. I am almost certain that it breaks nothing in nonSET H.323. But it probably may cause problems to SET with multiple fast
starts.
3 I would really not want to do this through nonStansard fields. 4 To add new field: OLC.reverseLogicalChannelParameters.reverseLogicalChannelNumber. The only problem with this is that we need to change the H.245 syntax. In addition this field is difficult to explain from the H.245
point
of view. (I do not think we've had ever before a precedent of changing
H.245
as a result of fast start needs)
I really do not know which one I prefer.
Sasha
-----Original Message----- From: Paul E. Jones [mailto:paulej@packetizer.com] Sent: Wednesday, December 13, 2000 6:57 AM To: Sasha Ruditsky Cc: ITU-SG16@mailbag.cps.intel.com Subject: Re: Fast Connect & Bi Directional channels
Sasha,
Yes, I see your point now.. thanks for clarifying this issue for me.
This makes life more interesting, doesn't it?
So I suppose the question is one of whether we feel we need to provide
this
information or whether we do not. To keep life simpler for the H.245
state
machine, I would guess that we should do something to allow the called endpoint to return the LCN for the reverse channel. However, there
doesn't
seem to be a real clean place to provide that information. We could
always
do strange things, such as use nonStandard fields or use the "replacementFor" field in the OLC.reverseLogicalChannelParameters
structure.
What's your preference?
I would guess that the proponents of this text (who wanted it for Annex
Dv2
primarily) should have something to say regarding this.
Paul
----- Original Message ----- From: "Sasha Ruditsky" sasha@tlv.radvision.com To: "Paul E. Jones" paulej@packetizer.com Cc: ITU-SG16@mailbag.cps.intel.com Sent: Tuesday, December 12, 2000 3:28 AM Subject: RE: Fast Connect & Bi Directional channels
Hi Paul
When we open T.120 or any other bi-directional channel through the
H.245
then openLogicalChannelAck message carries 2 LCNs: 1st in the forwardLogicalChannelNumber field 2nd in the reverseLogicalChannelParameters.reverseLogicalChannelNumber
field
So when opening the real H.245 channel there is no problem.
With fast start the problem exists because the openLogicalChannel
message
(the response for fast start case) has just one LCN field -- the forwardLogicalChannelNumber.
It should be decided what should be the value of this field. Currently standard says nothing about this field specifically. The H.323 states in 8.1.7.1 : "When accepting a proposed
bi-directional
channel for transmission between the calling endpoint and the called endpoint, the called endpoint shall return the corresponding OpenLogicalChannel structure to the calling endpoint.". In the same section before there is note: "The called endpoint is only allowed to alter fields in a proposed OpenLogicalChannel structure as specified in this section".
I believe that from the lawyer point of view the aforementioned means:
"the
forwardLogicalChannelNumber" should not be changed.
I do not know if this was exactly the intent, but if it was, it is OK
with
me, except the fact that we do not have the
reverseLogicalChannelNumber
field for such channel. In most cases it does work OK. The only case that may cause problem is inheritance of such channel by H.245. The reverse direction of the bi-directional H.245 channel opened in such way will not be able to be
a
subject of the H.245 commands and indications. I know no H.245
commands
and
indications that is impossible to work without when working with fax channel. So I do not think that we have specific problem which may
affect
fax channels opened in such way.
From other hand the procedure is (a little bit, but) broken. So at
least
this should be understood and mentioned in the standard.
--
The possible alternative (of cause if we do agree that the standard is unclear in this point) is two put the reverseLogicalChannelNumber into
the
forwardLogicalChannelNumber field of the accepted bi-directional
channel.
This solves the problem, but requires the caller to implement more complicated mechanism to identify to the proposed OLC for the received accepted OLC.
--
But in any case I just want to be able to implement this so it should
be
agreed what is the proper value to be put in this field.
Sasha
-----Original Message----- From: Paul E. Jones [mailto:paulej@packetizer.com] Sent: Monday, December 11, 2000 11:10 PM To: Sasha Ruditsky; ITU-SG16@mailbag.cps.intel.com Cc: Orit Levin Subject: Re: Fast Connect & Bi Directional channels
Sasha,
This logic was borrowed from the way that we open bi-directional T.120 channels, I believe. Either endpoint may signal the opening of a
T.120
channel, but only one side provides the LCN. Is this same logic not sufficient?
Paul
----- Original Message ----- From: "Sasha Ruditsky" sasha@tlv.radvision.com To: ITU-SG16@mailbag.cps.intel.com Cc: "Orit Levin" orit@radvision.com; paulej@PACKETIZER.COM Sent: Monday, December 11, 2000 8:04 AM Subject: Fast Connect & Bi Directional channels
Hi
It looks like there is yet another bug in the fast start procedure. It is related to bi-directional channels establishment.
Standard says that in each bi-directional channel proposal there
should
be
unique forwardLogicalChannelNumber. Standard says nothing about the value of this field in the accepted bi-directional OLC.
It is known that bi-directional channels need 2 logical channel
numbers
(forward and reverse). I see 2 options for the value of forwardLogicalChannelNumber field
in
the
accepted bi-directional OLC:
- It may be the same value as the forwardLogicalChannelNumber in
the
corresponding proposal. In this case we do not have the logical channel number for the
reverse
direction. This works OK till we are in fast start, but after H.245 connection establishment it will be impossible to perform H.245 actions on the reverse
direction
of
the channel.
- It may be the unique logical channel number that is provided by
calling
party and identifies the channel -- the reverseLogicalChannelNumber. The problem with this is that caller does not know to which proposal
this
channel belongs. BTW The same problem exists with the unidirectional channels from
callee
to
caller and the solution is just to find the corresponding proposal, using different channel characteristics.
I personally prefer the second option because it is more correct
from
the
H.245 point of view. But, In any case it should be decided which is the standard one .
Sasha
Alexander(Sasha) Ruditsky RADVision Ltd. 24 Raul Wallenberg St. Tel Aviv 69719 Israel
Tel: +972-3-645-5220 Fax: +972-3-644-2903 Direct: +972-3-645-5273 sasha@radvision.rad.co.il
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.comFor help on this mail list, send "HELP ITU-SG16" in a message to listserv@mailbag.intel.com
Paul,
To be perfectly clear, I recommend inserting the text below into the new sentence you added to 8.1.7.2.
"The ***called*** endpoint shall use the proposed logical channel number in the forwardlogicalChannelNumber element as the logical channel number of the ***forward and*** reverse channel."
Paul Long ipDialog, Inc.
-----Original Message----- From: Paul E. Jones [mailto:paulej@PACKETIZER.COM] Sent: Saturday, December 16, 2000 1:48 AM To: ITU-SG16@MAILBAG.INTEL.COM Subject: Re: Fast Connect & Bi Directional channels
Sasha, et al.,
Sorry for the last e-mail on this subject. I had not seen this one, yet. So, it appears that you agree that for bi-directional channels we can use the forward LCN as the value of the reverse LCN. I have attached the most recent documents containing corrections to H.323v4 and H.225.0v4, which includes a proposal for this item.
Please review the text and give me comments.
Best Regards, Paul
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv@mailbag.intel.com
Paul,
Agreed. I have changed the text accordingly.
Paul
----- Original Message ----- From: "Paul Long" plong@PACKETIZER.COM To: ITU-SG16@mailbag.cps.intel.com Sent: Sunday, December 17, 2000 12:24 PM Subject: Re: Fast Connect & Bi Directional channels
Paul,
To be perfectly clear, I recommend inserting the text below into the new sentence you added to 8.1.7.2.
"The ***called*** endpoint shall use the proposed logical channel number
in
the forwardlogicalChannelNumber element as the logical channel number of
the
***forward and*** reverse channel."
Paul Long ipDialog, Inc.
-----Original Message----- From: Paul E. Jones [mailto:paulej@PACKETIZER.COM] Sent: Saturday, December 16, 2000 1:48 AM To: ITU-SG16@MAILBAG.INTEL.COM Subject: Re: Fast Connect & Bi Directional channels
Sasha, et al.,
Sorry for the last e-mail on this subject. I had not seen this one, yet. So, it appears that you agree that for bi-directional channels we can use the forward LCN as the value of the reverse LCN. I have attached the most recent documents containing corrections to H.323v4 and H.225.0v4, which includes a proposal for this item.
Please review the text and give me comments.
Best Regards, Paul
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 (4)
-
Bob Gilman -
Paul E. Jones -
Paul Long -
Sasha Ruditsky