- sg16-avd - lists.packetizer.com

Re: Fast Connect & Bi Directional channels
by Sasha Ruditsky 17 Dec '00

17 Dec '00

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

4 4

RE: Fast Connect & Bi Directional channels
by Sasha Ruditsky 17 Dec '00

17 Dec '00

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, 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 >

1 0

Draft IETF49 Megaco Minutes
by Tom-PT Taylor 15 Dec '00

15 Dec '00

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 ===================================== 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

1 0

RE: Fast Connect & Bi Directional channels
by Sasha Ruditsky 15 Dec '00

15 Dec '00

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 > > *********************************************** > > > > > > >

3 2

Re: Third party registration/group registration
by Roy, Radhika R, ALCOO 15 Dec '00

15 Dec '00

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 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

1 0

Re: Third party registration/group registration
by Agboh, Charles 15 Dec '00

15 Dec '00

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

2 1

H.323 Annex I: questions
by Baese Gero 14 Dec '00

14 Dec '00

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 ---------------------------------------------------------- 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

1 0

Re: Video Framerate in TCS & OLC
by Agboh, Charles 13 Dec '00

13 Dec '00

-----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 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

1 0

H.323 Annex I: test conditions
by Baese Gero 13 Dec '00

13 Dec '00

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 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 ----------------------------------------------------------

1 0

RE: Fast Connect & Bi Directional channels
by Sasha Ruditsky 12 Dec '00

12 Dec '00

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 > *********************************************** > > >

2 1