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 …
[View More]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(a)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(a)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(a)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(a)tlv.radvision.com>
> To: "Paul E. Jones" <paulej(a)packetizer.com>
> Cc: <ITU-SG16(a)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(a)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(a)tlv.radvision.com>
> > To: <ITU-SG16(a)mailbag.cps.intel.com>
> > Cc: "Orit Levin" <orit(a)radvision.com>; <paulej(a)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:
> > >
> > > 1. 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.
> > >
> > > 2. 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(a)radvision.rad.co.il
> > > ***********************************************
> > >
> > >
> > >
> >
>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> For help on this mail list, send "HELP ITU-SG16" in a message to
> listserv(a)mailbag.intel.com
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
For help on this mail list, send "HELP ITU-SG16" in a message to
listserv(a)mailbag.intel.com
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
For help on this mail list, send "HELP ITU-SG16" in a message to
listserv(a)mailbag.intel.com
[View Less]
Hi Paul
Yes, I think that using the same number for the both LCNs of the
bi-directional channel is the best solution for this problem. And I agree
with the text that clarifies this.
Sasha
-----Original Message-----
From: Paul E. Jones [mailto:paulej@PACKETIZER.COM]
Sent: Saturday, December 16, 2000 9:48 AM
To: ITU-SG16(a)mailbag.cps.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, …
[View More]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(a)TLV.RADVISION.COM>
To: <ITU-SG16(a)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(a)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(a)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(a)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(a)tlv.radvision.com>
> > To: "Paul E. Jones" <paulej(a)packetizer.com>
> > Cc: <ITU-SG16(a)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(a)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(a)tlv.radvision.com>
> > > To: <ITU-SG16(a)mailbag.cps.intel.com>
> > > Cc: "Orit Levin" <orit(a)radvision.com>; <paulej(a)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:
> > > >
> > > > 1. 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.
> > > >
> > > > 2. 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(a)radvision.rad.co.il
> > > > ***********************************************
> > > >
> > > >
> > > >
> > >
> >
> > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> > For help on this mail list, send "HELP ITU-SG16" in a message to
> > listserv(a)mailbag.intel.com
>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> For help on this mail list, send "HELP ITU-SG16" in a message to
> listserv(a)mailbag.intel.com
>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> For help on this mail list, send "HELP ITU-SG16" in a message to
> listserv(a)mailbag.intel.com
>
[View Less]
The Megaco Working Group met on Wednesday morning, December 13. Tom Taylor
[taylor(a)nortelnetworks.com] chaired.
1. Agenda Bashing
The proposed agenda was as sent to the list (6/12/2000) with two additions:
a brief presentation of work on Bearer Independent Call Control (BICC) and
the proposed H.248 packages resulting from it, and presentation of
draft-ietf-megaco-fmtdeterm-00.txt. The agenda as proposed was accepted.
2. ITU-T Study Group 16 Status Report
==================================…
[View More]===
Tom Taylor provided an update on the status of work in Study Group 16.
He reported that the ITU-T has introduced a new alternative decision
procedure
-- like Last Call
-- if all issues not resolved, fall back on existing procedure.
Scott Bradner added that the purpose in part was to make it easier to
synchronize ITU-T and IETF decision processes.
At the Study Group 16 meeting of 13-17 November the following items were
decided under the old procedures:
Annex F: Call discrimination, FAX, text telephony
Annex G: User interface elements
Annex H: SCTP transport
Annex I: ATM transport
Annex J: Dynamic tone generation
Annex K: Announcements
In addition, the meeting approved the first issue of the H.248v1
Implementor's Guide.
Question 14/16 is now renamed Question 3/16 for the new Study Period. Q.
3/16 now has in hand the following additional official work items relating
to H.248. There is no date set yet for completion of these items, but the
two Annexes have been determined.
-- H.248v2
-- Annex L: Error codes and ServiceChange reasons
-- Annex M: Advanced audio server
The following additional work items have been accepted, but are in an early
state of maturity:
-- Annex N: load control package (APC-2000)
-- Annex O: data transport on analogue lines
-- SDL appendix (informative). The contributors are looking for more help.
-- H.324 package.
Finally, the following H.248v2 items accepted, either at the Portland
Rapporteur's meeting in August or at the November meeting:
-- ServiceChange to indicate change of capabilities (APC-1911)
-- Finer discrimination in audits (APC-1913)
-- signal on ROOT.
The APC numbers refer to document numbers on the informal SG 16 FTP site
(ftp://standards.pictel.com/avc-site /<meeting place and date>) Tom noted
that ITU-T versions are more like protocol extensions than protocol
modifications. Successive versions are intended to be backwards compatible.
Tom asked a process question: do we republish decided material as
Informational or Standards Track? If the latter, presumably IETF comments
go into the ITU-T Implementor's Guide.
Flemming Andreasen [fandreas(a)cisco.com] identified the matter of how the
IETF coordinates with the ITU-T in the development of H.248v2 as a major
issue. This point should be considered in the rechartering discussion.
Scott Bradner advised that no clear resolution of this point had been
reached in discussions with Study Group 16 management.
Further process discussion elicited the view that decided items of interest
to the IETF should be taken through the complete IETF process and targeted
for Standards Track RFCs. The list should decide which items should go this
route. Scott Bradner instructed the Chair to get explicit permission from
the ITU-T TSB before republishing the decided material, since it is not
clear whether our agreement on H.248 extends beyond the initial protocol
document.
3. Completion Of Charter Items
==============================
(a) Megaco MIB
----------
Matt Holdrege [matt(a)IPVERSE.COM] provided a status report on the development
of the Megaco MIB. He emphasized that the main purpose of the present draft
was to get objects on the table for discussion. He estimated at least two
recycles before the draft is in reasonable shape. He presented a long list
of detailed issues to be worked through. [Presentation will be attached to
published minutes]. There was no discussion at the meeting.
(b) NAS Package
-----------
Tom Taylor briefly summarized the status of the NAS packages. [Presentation
to be attached to final minutes.] He pointed out that complementary work on
indication of TDM bearer capability remained to be done. In his opinion
this would be an SDP extension in the spirit of the ATM SDP extension. The
hum in favour of moving this work forward was practically imperceptible: it
is left to the list to decide. The Chair will be soliciting comment from
the list on whether this should be a Standards Track item.
4. Well-Aged Package Drafts
========================
Michael Brown [C.Michael.Brown(a)nortelnetworks.com] presented all drafts
under this heading, as co-author. (The presentation was actually
interrupted but is documented here as if it had proceeded according to
original plan.)
(a) draft-boyle-megaco-tonepkgs-01.txt
----------------------------------
This document provides a number of specialized tone packages. [Presentation
will be attached to minutes.] Michael noted that Study Group 11 (the BICC
group) had asked for an optional directionality parameter for tones and
announcements. Its use is to direct signals inwards to the context; it
optimizes an operation which would otherwise require individual modification
of all of the other terminations in the context or treatment of an
announcement or tone source as a termination in its own right. The authors
of draft-boyle-megaco-tonepkgs-01.txt propose to recycle the draft to
include this parameter.
Brian Rosen [Brian.Rosen(a)MARCONI.COM] expressed his view that the use of a
directionality parameter for signals should be approved on the list. Glen
Freundlich [ggf(a)avaya.com] noted that Study Group 16 added such a parameter
to the new Annex K announcement package.
The meeting agreed that the directionality parameter discussion is required,
but otherwise the draft is ready for list Last Call.
(b) draft-boyle-megaco-alerting-00.txt
----------------------------------
This package provides capabilities related to CLASS signalling. There is an
overlap in scope with the proposed Annex O, but the latter has a finer level
of detail which in Michael's opinion may result in timing difficulties.
Brian Rosen asked if there had been coordination of approach between this
work and automatic number identification (ANI/DNIS). Michael responded that
the problems were similar, but not the same.
The meeting agreed that before this draft moves forward there should be a
discussion and resolution on the list of the respective content of this
draft and the SG 16 Annex O proposal. Action: Chair to arrange for
publication of current draft of Annex O as an I-D to aid the discussion.
(c) draft-cornel-megaco-enhancedd-00.txt
------------------------------------
This draft defines an enhanced DTMF digit collection capability, designed
particularly for mid-call digit collection. The package includes a modified
digit map completion event.
Scott Bradner noted with respect to this and previous items that
non-response is not enough to justify standardization. The Chair must
solicit discussion if necessary before deciding to move forward.
(d) draft-scoggins-megaco-pktnetpkg-00.txt
--------------------------------------
This package proposal is withdrawn in favour of packages included in the
Q.1950 (BICC) work.
5. ITU-T Study Group 11 BICC Status
================================
Greg Ratta [gratta(a)lucent.com] SG 11 Vice Chairman in the area of
IP-related signalling work, provided an introduction to Bearer Independent
Call Control work dealing with IP networks. [Presentation charts will be
attached to official minutes.] The presentation showed the basic
architecture and listed two sets of packages: those picked up directly from
H.248, and those developed by the BICC group specifically to suit their
needs. The key architectural points are that call signalling is based on
ISUP, with modifications to support an abstract interface to the media
bearers. The protocol interface between the call server and lower-layer
functions features a strict separation between bearer-related information
and media-related information.
Brian Rosen commented that he had read the BICC documents quickly and had
come away with the sense that they violated the spirit of the H.248
protocol. He thought that SG 11 might need more H.248 expertise. He looked
for a way to share our knowledge, with the intent of preserving a single
protocol. Greg responded by recalling to Brian that Frame Relay, as an
example, eventually saw application far beyond its original conception. He
was open to the use of channels for the exchange of information between the
two groups. The time for Megaco to get involved is definitely now, given
that the documents have been determined and a final editing meeting has been
scheduled for the latter half of February.
Michael Ramalho [mramalho(a)cisco.com] seconded Brian's thoughts about the
pooling of knowledge. However, he wondered why a project which seemed to be
aimed at reproducing SS7 in the IP network should aim beyond that by
emphasizing the separation between call control and bearer control. Greg
responded that the main aim is to allow traditional networks to operate over
new transport. The impetus for the call control/bearer control separation
comes from the mobile area.
Michael Brown noted that he had been somewhat involved in Study Group 11's
work on BICC. The architecture forces transport of information differently
from how H.248 does it. He raised the possibility that an alternative
architecture would allow H.248 to operate as usual. He advised those
present that, besides draft Q.1950, they should look at draft Q.1990 and the
BICC requirements and architecture documents. Q.1950 is the document which
Study Group 11 has just determined, and which will be the subject of the
February editing meeting.
Ian Rytina [ian.rytina(a)ericsson.com.au] warned that Megaco should not come
barging into the midst of the BICC work shouting "All wrong!" without
reflection. Study Group 16 people have been involved in BICC almost from
the beginning.
6. ISDN
====
Bouwen Jan [jan.bouwen(a)alcatel.be] presented
draft-bouwen-megaco-isdn-bcp-00.txt, draft-bouwen-megaco-isdn-data-00.txt,
and draft-bouwen-megaco-isdn-pack-00.txt. [Presentation to be attached to
official minutes.] The content has not changed significantly from the
original draft, but it was broken into these three documents to make it
easier to understand.
Brian Rosen, commenting on the -isdn-pack draft, suggested that we need
group consensus on the use of signals vs. the use of properties for
management-type functions. We should decide one way or the other and
enforce the chosen style in package definitions. Action is on the Chair to
initiate list discussion. Related items in Study Group 16 are the proposed
signal on ROOT for heartbeat messages, and proposed audio segment management
operations in draft Annex M (Advanced Audio Server).
Brian saw the BCP as a necessary document. However, naming patterns should
go into profiles. He also wondered whether the modem descriptor should be
used for D-channel data. The basic feeling was that the drafts other than
the BCP document should move forward on Standards Track, but only after
there had been more list discussion. The Chair undertook to focus
discussion on the ISDN drafts in the coming week.
Peter Blatherwick [blather(a)nortelnetworks.com] wondered whether the BCP
document should actually be a profile.
7. CAS Design Team Report
======================
Michael Brown reported. draft-manyfolks-megaco-caspackage is on its way.
The interest in channel-associated signalling (CAS) is large; the design
team grew through word of mouth after it had been set up.
The team sees the need for the following packages:
- Basic CAS
- Robbed bit signalling (wink/seizure)
- MF generation and detection
- Operator services
The draft will be published shortly. List comment is encouraged.
8. Other Proposals
===============
(a) draft-rosen-megaco-namepatterns-00.txt
--------------------------------------
Brian Rosen presented. The mechanism is intended to help control the volume
of information retrieved on audits. The intent is that the MGC retrieve
this one property on ROOT, then walk through the patterns to retrieve
information on groups of terminations.
Tom Taylor noted that the mechanism allowed more precise designation than
the one in the proposed NASROOT package. There is a need to reconcile the
latter with Brian's proposals. Aside from the basic mechanism, a list
debate is needed on whether ROOT packages should be defined in the manner of
NASROOT to associate naming patterns with termination classes. This relates
to the old problem of finding out about the MG's capabilities for ephemerals
before any of the latter have been created.
Michael Brown noted that the naming pattern in the MG may be purely physical
(e.g. shelf/slot), and may not relate to the type of card (hence the
termination class) provisioned there.
(b) draft-cutler-megaco-recvpkg-01.txt
----------------------------------
Wayne Cutler [wayne.cutler(a)marconi.com] presented. The general intent is to
allow the MGC to store state against individual terminations on MGs to allow
a cleaner recovery from call failures.
Flemming Andreasen termed the proposal bizarre at first sight. He asked
whether the data to be stored included call state. Wayne indicated not, but
that the data would be call-related. Flemming asked what would happen if
multiple MGCs were involved. Wayne asked for clarification of whether
Flemming meant multiple MGCs acting as a single logical MGC. Flemming
complained of lack of generality. Brian Rosen stepped in to point out that
the proposal is general with respect to content. Obviously a length limit
would be needed. Scott Bradner noted that the author is simply asking for a
cookie mechanism. The only concern is that it is defined too specifically.
Clearly a matter for further discussion on the list.
(c) draft-levy-megaco-mgdiscovery-01.txt
------------------------------------
Thomas LEVY [thomas.levy(a)ms.alcatel.fr] presented. The draft is intended to
provide further information from the MG in support of load balancing. He
reviewed the available alternatives and came up with a specific
recommendation. Brian Rosen suggested that this work had the same time
frame as SDPng, and thus the latter is the preferred route to a solution.
Thomas responded that the expected incompatibility between SDP and SDPng
made it desirable to find a solution independent of either. Scott Bradner
suggested that we check out other resource capability work being done in the
IETF.
(d) draft-ietf-megaco-fmtdeterm-00.txt
----------------------------------
The Chair overlooked this item as the meeting was running out of time. It
will be taken to the list for Last Call (Informational).
9. Interoperability
================
Brian Rosen reported on the results of the August interoperability event and
gave some information on the next one.
10. Rechartering Discussion
=======================
Scott Bradner led off discussion of the future of the Working Group by
saying that WGs normally have a finite life. Working Groups are justified
when they need meeting time to discuss open issues. He had not seen much
evidence of such discussion at this meeting -- only a series of
presentations.
Brian Rosen spoke of a need to continue our work on packages. The lack of
controversy at the present meeting was because the packages presented were
well-baked. He also saw the need for an official working group to provide
impedance to Study Group 16. The WG itself should not be working on a new
version of Megaco -- only on packages. Matt Holdrege picked up the argument
that Megaco is needed to provide legitimacy because the work it is involved
in reaches beyond the IETF.
Peter Blatherwick agreed that the group should continue its work on
packages. He would also like to see more work on profiles, to provide rules
for profile definition, how to do "inheritance", whether the MG can support
multiple profiles at a time. This item was intentionally deferred earlier
in the progress of WG, but there is serious risk of profiles getting out of
control. Flemming Andreasen disagreed with this proposal.
Scott Bradner called for a show of hands on continuing the Working Group.
There were a fair number in favour of continuation and none in favour of
going dormant. Scott instructed the Chair to take a draft charter to the
list. The IESG might consider extension of the group's life, but the
charter must contain concrete deliverables.
Tom Taylor
Ph. +1 613 736 0961
taylor(a)nortelnetworks.com
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
For help on this mail list, send "HELP ITU-SG16" in a message to
listserv(a)mailbag.intel.com
[View Less]
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 …
[View More]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(a)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(a)tlv.radvision.com>
To: "Paul E. Jones" <paulej(a)packetizer.com>
Cc: <ITU-SG16(a)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(a)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(a)tlv.radvision.com>
> To: <ITU-SG16(a)mailbag.cps.intel.com>
> Cc: "Orit Levin" <orit(a)radvision.com>; <paulej(a)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:
> >
> > 1. 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.
> >
> > 2. 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(a)radvision.rad.co.il
> > ***********************************************
> >
> >
> >
>
[View Less]
Hi, Chris and Charles:
I guess that the third party registration will be helpful in a situation
where the first does not want to do this job and may want to delegate this
to the third party (e.g., secretary). Another situation can be that an IWF
is registering many entities on behalf of many endpoints and the IWF does
not want to be a party anymore once the registration is done.
Let us define the requirements of the third party registration as follows:
1. The third party wants to register …
[View More]the first party.
2. The third party shall not be any party once the registration is done.
That is, any information related to the first party needs to be obtained
from other sources once the registration is done by the third party.
Based on the above two criteria, let us see what needs to be done in H.323
to perform the third party registration.
Hope this helps.
Best regards,
Radhika
-----Original Message-----
From: Chris Wayman Purvis [mailto:cwp@ISDN-COMMS.CO.UK]
Sent: Friday, December 15, 2000 4:38 AM
To: ITU-SG16(a)MAILBAG.INTEL.COM
Subject: Re: Third party registration/group registration
Charles,
Ref your "some value":
I would bring this down to configuration of the gatekeeper. You could
have/configure/write!? a gatekeeper which has "default registrations" -
calls
for known people go by default to an answering machine unless that
individual
is actually registered.
What I don't understand is how "third-party registration" helps - you're
missing out too many steps in your explanation!
Regards,
Chris
"Agboh, Charles" wrote:
>
> That is a good questions. I would say this;
>
> 3rd party registration is when; The target endpoint (called party ) may
not
> be the Registering Entity (IWF/BE) based on the binding between alias and
> transport address; AND the entity receving the RRQ is aware that this is a
> 3rd-party RRQ ( a registers b).
>
> This needs to be clearly defined but before that we must be sure there is
> value in defining 3rd party registration (like third party call control:
> GK-initiated call control (re-routing...))
>
> some value:
>
> - In this case I do not have to hunt for a "line" at the GK (so at the
> GK, I would know that a call was for a registered EP b (registered by
> registering entity a) and send the call to the transport address which b's
> alias is binded to (called party is b's alias address); which may be a's
> transport address depending on the time). With the alternateEndpoint
> structure, I would reach b only after hunting.
>
> Best regards,
> charles
> -----Original Message-----
> From: Roy, Radhika R, ALCOO [mailto:rrroy@ATT.COM]
> Sent: Tuesday, December 12, 2000 9:52 PM
> To: ITU-SG16(a)MAILBAG.INTEL.COM
> Subject: Re: Third party registration/group registration
>
> I guess that it is a good observation by Bob. It can be thought a "kind"
of
> third party activities. However, a BE becomes a "party" in this process
> because people have now have a place to go to have the information. And
that
> place is the BEs themselves.
>
> So the basic question remains: What is the basic definition of the "third"
> party registration in H.323?
>
> Thanks Bob for his important observation.
>
> Best regards,
> Radhika
>
> -----Original Message-----
> From: Callaghan, Robert [mailto:Robert.Callaghan@ICN.SIEMENS.COM]
> Sent: Tuesday, December 12, 2000 3:41 PM
> To: ITU-SG16(a)MAILBAG.INTEL.COM
> Subject: Re: Third party registration/group registration
>
> I might interject that H.225.0 Annex G can be thought of as a form of
Third
> Party registration. This protocol allows a Border Element (or Gatekeeper)
> to registers its endpoints with other Border Elements (or Gatekeepers).
>
> I do not know is this adds to the discussion, or not.
>
> Bob
>
> --------------------------------------------------------------
> Robert Callaghan
> Siemens Enterprise Networks
> 5500 Broken Sound Blvd, Boca Raton, Fl 33487
> Tel: +1 561 923-1756 Fax: +1 561 923-1403
> Email: Robert.Callaghan(a)ICN.Siemens.com
> -----------------------------------------------------------------
>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> For help on this mail list, send "HELP ITU-SG16" in a message to
> listserv(a)mailbag.intel.com
>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> For help on this mail list, send "HELP ITU-SG16" in a message to
> listserv(a)mailbag.intel.com
>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> For help on this mail list, send "HELP ITU-SG16" in a message to
> listserv(a)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(a)mailbag.intel.com
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
For help on this mail list, send "HELP ITU-SG16" in a message to
listserv(a)mailbag.intel.com
[View Less]
That is a good questions. I would say this;
3rd party registration is when; The target endpoint (called party ) may not
be the Registering Entity (IWF/BE) based on the binding between alias and
transport address; AND the entity receving the RRQ is aware that this is a
3rd-party RRQ ( a registers b).
This needs to be clearly defined but before that we must be sure there is
value in defining 3rd party registration (like third party call control:
GK-initiated call control (re-routing...))
…
[View More]some value:
- In this case I do not have to hunt for a "line" at the GK (so at the
GK, I would know that a call was for a registered EP b (registered by
registering entity a) and send the call to the transport address which b's
alias is binded to (called party is b's alias address); which may be a's
transport address depending on the time). With the alternateEndpoint
structure, I would reach b only after hunting.
Best regards,
charles
-----Original Message-----
From: Roy, Radhika R, ALCOO [mailto:rrroy@ATT.COM]
Sent: Tuesday, December 12, 2000 9:52 PM
To: ITU-SG16(a)MAILBAG.INTEL.COM
Subject: Re: Third party registration/group registration
I guess that it is a good observation by Bob. It can be thought a "kind" of
third party activities. However, a BE becomes a "party" in this process
because people have now have a place to go to have the information. And that
place is the BEs themselves.
So the basic question remains: What is the basic definition of the "third"
party registration in H.323?
Thanks Bob for his important observation.
Best regards,
Radhika
-----Original Message-----
From: Callaghan, Robert [mailto:Robert.Callaghan@ICN.SIEMENS.COM]
Sent: Tuesday, December 12, 2000 3:41 PM
To: ITU-SG16(a)MAILBAG.INTEL.COM
Subject: Re: Third party registration/group registration
I might interject that H.225.0 Annex G can be thought of as a form of Third
Party registration. This protocol allows a Border Element (or Gatekeeper)
to registers its endpoints with other Border Elements (or Gatekeepers).
I do not know is this adds to the discussion, or not.
Bob
--------------------------------------------------------------
Robert Callaghan
Siemens Enterprise Networks
5500 Broken Sound Blvd, Boca Raton, Fl 33487
Tel: +1 561 923-1756 Fax: +1 561 923-1403
Email: Robert.Callaghan(a)ICN.Siemens.com
-----------------------------------------------------------------
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
For help on this mail list, send "HELP ITU-SG16" in a message to
listserv(a)mailbag.intel.com
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
For help on this mail list, send "HELP ITU-SG16" in a message to
listserv(a)mailbag.intel.com
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
For help on this mail list, send "HELP ITU-SG16" in a message to
listserv(a)mailbag.intel.com
[View Less]
Dear Mr. Li, Experts,
as mentioned at the ITU meeting in Geneva there
are several open questions concerning the proposal of
UCLA.
APC 2018 "Protection Procedure"
c) If the protection is actually done with level p-1 why do one has
to keep level p somehow ? In opposition to the written text is
packet #3 in your figure.
d) Can you please explain the meaning of "packet" in
every case it is mentioned within this paragraph ?
Best Wishes
Gero Baese
------------------------------------…
[View More]----------------------
Gero Bäse Tel.: +49 89 636 53193
Corporate Research Fax: +49 89 636 52393
Networks and Multimediacommunication ZT IK 2
----------------------------------------------------------
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
For help on this mail list, send "HELP ITU-SG16" in a message to
listserv(a)mailbag.intel.com
[View Less]
-----Original Message-----
From: Agboh, Charles
Sent: Tuesday, December 12, 2000 6:41 PM
To: ITU-SG16(a)MAILBAG.INTEL.COM
Subject:
Hi Paul, all;
What is the maximum frame per second for H.261 and H.263? Is this indicated
in the TCS? if yes, where in the OLC messages do I indicate the actual
frame rate.
Regards,
charles
-----Original Message-----
From: Paul Long [mailto:plong@PACKETIZER.COM]
Sent: Tuesday, December 12, 2000 5:34 PM
To: ITU-SG16(a)MAILBAG.INTEL.COM
Subject: Re: audio …
[View More]clock rate
Charles,
H.323 doesn't care what the audio clock rate is. That's specific to the
audio encoding:
A.5.1/H.225.0v4: "The clock frequency is dependent on the format of data
carried as payload and is specified statically in the profile or payload
format specification that defines the format, or may be specified
dynamically for payload formats defined through non-RTP means."
A.12/H.225.0v4: "For each payload type defined, the profile must specify the
RTP timestamp clock rate to be used..."
Paul Long
ipDialog, Inc.
-----Original Message-----
From: Agboh, Charles [mailto:Charles.Agboh@GTS.COM]
Sent: Tuesday, December 12, 2000 8:21 AM
To: ITU-SG16(a)MAILBAG.INTEL.COM
Subject: audio clock rate
Hi,
How can H.323 support audio clock rates higher than 8khz.
Regards,
charles
------------8-)-----------
Charles Agboh
GTS
RFC822: charles.agboh(a)gts.com
Tel: +32 (0) 2 658 4243
mobile: +32 495 58 52 67
Fax: +32(0) 2 658 5118
http://www.gtsgroup.com
Quan Yin Method
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
For help on this mail list, send "HELP ITU-SG16" in a message to
listserv(a)mailbag.intel.com
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
For help on this mail list, send "HELP ITU-SG16" in a message to
listserv(a)mailbag.intel.com
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
For help on this mail list, send "HELP ITU-SG16" in a message to
listserv(a)mailbag.intel.com
[View Less]
Dear Mr. Li, Experts,
according our mandate of the last ITU meeting we further improved
our test conditions document. It is now easier to read and we did
several steps to defuse possibly controversial subjects.
For example, to be as close as possible to the reality the UMTS
bearer services are designed to meet user data rates of 64kbit/s
and 128kbit/s respectively.
We are looking forward to see your comments or questions.
Mr. Li, you requested explicitely H.263 to be included in the …
[View More]tests,
some points for clarification are remaining still.
The Interactive and Streaming Wireless Profile 3 of H.263 is much more
suitable for equal erasure protection. Here we can reduce the workload
or take the advantage to show that both proposals are also useful
for this special case within unequal erasure protection.
What do you prefer ?
We are supposed to perform the test reproducible for everybody else
within the standardization community. Which public available software
for H.263 we are going to use ?
Best Wishes
Gero Baese
<<APC-1993r1.doc>>
----------------------------------------------------------
Gero Bäse Tel.: +49 89 636 53193
Corporate Research Fax: +49 89 636 52393
Networks and Multimediacommunication ZT IK 2
----------------------------------------------------------
[View Less]
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 …
[View More]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(a)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(a)tlv.radvision.com>
To: <ITU-SG16(a)mailbag.cps.intel.com>
Cc: "Orit Levin" <orit(a)radvision.com>; <paulej(a)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:
>
> 1. 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.
>
> 2. 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(a)radvision.rad.co.il
> ***********************************************
>
>
>
[View Less]
