- sg16-avd - lists.packetizer.com

Re: [H.323 Mobility:] Reservation of MD-107 and MD-108 & upload o f MD -100
by Roy, Radhika R, ALCOO 23 Oct '00

23 Oct '00

Hi, Jaakko: Let us keep one thing in mind that 3GPP cases are only a part of the overall H.323 mobility. That is, high-speed mobile wireless environments like wireless LANs, indoor Pico- and micro-cells, and others are NOT covered by 3GPP architectures. Best regards, Radhika R. Roy AT&T -----Original Message----- From: Jaakko Sundquist [mailto:jaakko.sundquist@nokia.com] Sent: Thursday, October 19, 2000 4:14 AM To: ITU-SG16(a)MAILBAG.INTEL.COM Subject: [H.323 Mobility:] Reservation of MD-107 and MD-108 & upload of MD -100 Hi all, I reserve the MD-numbers: MD-107 and MD-108 for myself. The contributions are: MD-107 "3Gfication of H.323 Annex H Terms and Definitions" MD-108 "Comparison of 3GPP R'00 (v4) and H.323 Annex H Architectures". I will upload these contributions to the server probably next week. I will also upload MD-100 "List of MDs", containing the list of currently reserved MD-numbers to the Mobility-AHG folder in the incoming directory of the pictel ftp-site. ------------------------------------------------ Jaakko Sundquist * +358 50 3598281 * Audere est Facere! jaakko.sundquist(a)nokia.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

AW: test conditions provided
by Baese Gero 23 Oct '00

23 Oct '00

Dear experts and Mr. Li, thank you for your suggestions to further improve the testing conditions. > (1) Video codec > Profile 3 - H.263v2 Interactive and Streaming Wireless Profile > Profile 4 - H.263v3 Interactive and Streaming Wireless Profile It makes a lot of sense to incorporate both of the wireless profiles. There is no problem to remove Annex O from the list as well. > (2) Lower layer testing condition If you read the test conditions carefully you will see we nowhere propose to implement the whole protocol stack. Instead we are using a model with two parameters to keep it uncomplex but realistic. These two parameters are the loss rate of the radio frame and the length of it. Acting on our suggestion makes it easy to generate comparable results quickly. Furthermore, the situation is not as simple as you depicted it. It is not sufficient to only use the frame loss rate p because there is a strong dependency on the length as well. Therefore we proposed the described model. Again, everybody interested in this work is requested to contribute with questions, comments and suggestions. Best Wishes Gero Baese ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

H248 Implementors' Guide Draft v3
by Christian Groves 23 Oct '00

23 Oct '00

G'Day all, Attached is a copy of the H.248 Implementors' Guide v3. It "hopefully" contains the corrections and clarifications that have been discussed on the Megaco mailing list until the 19/10/2000. If anything is missed or erroneous please let me (and the list) know. The file will also be upload to the pictel server: ftp://standard.pictel.com/avc-site/incoming/H248_Implementors_Guide_v3.zip Both PDF and Word versions are available. My intention is to make one more update (v4) before sending to the Nov Sg16 meeting for approval. Cheers, Christian PS: Please forgive me sending a 98k file to the list but the Pictel server has been down.

2 3

Re: [H225 Annex G] When to create a new service ID
by Michael Fortinsky 22 Oct '00

22 Oct '00

Paul, Maybe I don't understand your point - I am not sure what you mean when you say "a new ServiceRequest". (I think this is the heart of the matter - what determines what is a NEW ServiceRequest?) New service ID's are allocated and returned in the ServiceConfirmation message, not in the ServiceRequest message. Therefore, it is up to the border element that receives the ServiceRequest message to decide whether to allocate a new service ID or not. The question still remains - how are "keepAlive" ServiceRequests to be treated? Another way of looking at the issue is as follows (maybe this is clearer): If a BE sends a ServiceRequest message that does NOT contain a serviceID field, a new service ID is returned in the ServiceConfirmation message and a new service relationship is defined. If a BE sends a ServiceRequest message that DOES contains a serviceID field, the BE that received the ServiceRequest must determine whether to return the same serviceID or a new one (ie, is there going to be a new service relationship or not) - if the service parameters in the ServiceRequest are the same as those in the existing service relationship, this ServiceRequest message is a refresh of the existing service relationship and the ServiceConfirmation is returned with the same service ID as was in the ServiceRequest - if the service parameters are different, then: - if the BE want to accept the new parameters, it sends a ServiceConfirmation that contains a NEW serviceID - this also indicates that the previous service relationship has ended - if the BE does not want to accept the new parameters, it sends a ServiceRejection (that contains the serviceID from the ServiceRequest message) indicating that the new terms are rejected - the old service relationship is still in effect according to the old service parameters (as per section 1.8.2.7/H.225 Annex G) Comments? Mike "Paul E. Jones" <paulej(a)packetizer.com> 10/22/00 04:02 AM To: <Michael_Fortinsky(a)VOCALTEC.COM>, <ITU-SG16(a)mailbag.cps.intel.com>, <h323implementors(a)imtc.org>, <h323implementors(a)pulver.com> cc: Subject: Re: [H225 Annex G] When to create a new service ID Michael, My opinion is that, given that there is a ServiceRequest and a ServiceRelease and that one can initiate a new service relationship before terminating a previous service relationship, a new service ID shall be introduced with a ServiceRequest message and a BE should not send a new ServiceRequest with the same ID without first releasing the previous relationship. I believe that's in alignment with your interpretation. Paul ----- Original Message ----- From: Michael_Fortinsky(a)VOCALTEC.COM To: ITU-SG16(a)mailbag.cps.intel.com ; h323implementors(a)imtc.org ; h323implementors(a)pulver.com Sent: Wednesday, October 18, 2000 5:40 AM Subject: [H225 Annex G] When to create a new service ID I would like to hear people's interpretation of when a new service ID should be created in H.225.0 Annex G. (A service ID is used to identify a service relationship between two border elements). There are three cases to consider: Case #1: - a BE (border element) receives a ServiceRequest message from a BE with which it does not yet have a service relationship Case #2: - a BE receives a ServiceRequest message from a BE with which it already does have a service relationship, but the terms of the service relationship are to be changed (eg, different security parameters) Case #3: - a BE receives a ServiceRequest message from a BE with which it already does have a service relationship (ie, this ServiceRequest is refreshing the service relationship), and the terms of the service relationship are identical to the previous terms (eg, same security parameters) My impression is that the following should happen in each case: Case #1 - create a new serviceID in the ServiceConfirmation Case #2 - create a new serviceID because we are changing the parameters of the service relationship (it's becoming a new service relationship) Case #3 - do NOT create a new serviceID - the existing relationship is being refreshed, so we should continue to use the same serviceID However, the wording of H.225.0 Annex G does not seem to say this. It seems that in ALL cases, a new serviceID should be created. To me, this seems to be incorrect, and I'm not sure that the original intent took into account case #3. I think that in case #3, we should not be creating a new service ID. The following sections from H.225.0 Annex G are relevant: [from section 1.8.2] service ID - This identifer identifies a particular service relationship session between two border elements. Whenever a border element receives a ServiceRequest message, it allocates a globally unique service ID and returns it to the sender of the ServiceRequest message in the ServiceConfirm message. [from section 1.8.2.5] A border element may send a ServiceRequest message to a border element with which it has an existing relationship, with the intent that the terms of the original relationship be terminated and replaced with the new terms. Service relationships may have limited time to live. A border element may refresh the relationship by sending a new Service Request. [from section 1.8.2.6] Every new service relationship is identified by a service identifier. Whenever a border element receives a new ServiceRequest message, it allocates a unique service ID and returns it to the sender of the service request message in the "service confirm" message. If the border element already has a service relationship with the border element that sent the ServiceRequest message, sending ServiceConfirmation indicates that the terms of the original relationship are terminated and replaced with the new terms. Any comments? If people agree that the wording needs to be changed to unambiguously handle case #3, now is the time to speak up. The deadline for contributions for the Geneva meeting is fast approaching. Michael Fortinsky ----------------------------------------------------------------- Senior Program Manager, IP Telephony Group, VocalTec Communications Ltd. Email: mike(a)vocaltec.com Tel: 972 9 9707768 Fax: 972 9 9561867

2 1

Re: Rapporteur meeting on 9-10 November in Geneva
by Sakae OKUBO 22 Oct '00

22 Oct '00

Dear Mr. Jones, In response to your requests, the following APC numbers have been allocated to your five contributions: APC-1969 Editor (P Jones) Editorial and Technical Corrections to H.323v4 APC-1970 Cisco Systems Signalling of ingress and egress Carrier/Circuit Identifier information in H.225.0 Messages and Annex G Messages APC-1971 Cisco Systems Third Party Re-routing of a Fast Connect Initiated Call APC-1972 Cisco Systems Ported Number Indications in H.225.0 messages APC-1973 Cisco Systems Reserving Resources for Calls Best regards, Sakae OKUBO *********************************************************** Waseda Research Center Telecommunications Advancement Organization of Japan (TAO) 5th Floor, Nishi-Waseda Bldg. 1-21-1 Nishi-Waseda, Shinjuku-ku, Tokyo 169-0051 Japan Tel: +81 3 5286 3830 (to be transferred) +81 3 3204 8194 (direct) Fax: +81 3 5287 7287 e-mail: okubo(a)giti.or.jp *********************************************************** ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

Error in H.323v3 ASN.1
by Paul E. Jones 22 Oct '00

22 Oct '00

XuPeili and other H.323 Developers, This does appear to be in error. Unfortunately, this was published this way in the H.225.0v3 Recommendation. However, you are correct that a previous H.323v2 Implementers Guide was published which contained the aliasesInconsistent field. So, we have an issue to contend with. I must ask the developer community-- I do not want to make this change without wide support for making such a change. Since the Version 2 field was added via the Implementers Guide, it is entirely possible that H.323v2 vendors did not even include it in their ASN.1 So, I need to hear from all of the developers on this issue. This may have been addressed, but I don't have notes on this matter. A similar issue with the LocationRejectReason was found and I corrected that back in June when discussing with everybody that "I would never change the ASN.1 and more". Well, unfortunately, it appears that we have one last error-- honestly, I'm quite shocked this one slipped through. So... should the "aliasesInconsistent" field be moved above the "routeCallToSCN" element in the AdmissionRejectReason sequence as shown in an earlier H.323v2 Implementers Guide? Please post and debate this publicly. We need to resolve this matter quickly so as to minimize impact on everybody. Best Regards, Paul ----- Original Message ----- From: "XuPeili" <xupeili(a)huawei.com> To: "Paul E. Jones" <paulej(a)packetizer.com> Cc: <h323implementors(a)imtc.org> Sent: Tuesday, October 03, 2000 9:42 PM Subject: ;X84: Multiple Call Proceedings in a H.323 call > hi Paul, > > In the H225.0v3.asn downloaded form www.packetizer.com > the ARJ is specified like this > > AdmissionRejectReason ::= CHOICE > { > calledPartyNotRegistered NULL, -- cannot translate address > invalidPermission NULL, -- permission has expired > requestDenied NULL, -- no bandwidth available > undefinedReason NULL, > callerNotRegistered NULL, > routeCallToGatekeeper NULL, > invalidEndpointIdentifier NULL, > resourceUnavailable NULL, > ..., > securityDenial NULL, > qosControlNotSupported NULL, > incompleteAddress NULL, > routeCallToSCN SEQUENCE OF PartyNumber, > aliasesInconsistent NULL -- multiple aliases in request identify distinct > people > } > > Since the routeCallToSCN is a new choice in H.225.0v3, I think it should be > placed > after the aliasesInconsistent choice which is already exist in v2. > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

7 17

[H225 Annex G] When to create a new service ID
by Michael Fortinsky 21 Oct '00

21 Oct '00

I would like to hear people's interpretation of when a new service ID should be created in H.225.0 Annex G. (A service ID is used to identify a service relationship between two border elements). There are three cases to consider: Case #1: - a BE (border element) receives a ServiceRequest message from a BE with which it does not yet have a service relationship Case #2: - a BE receives a ServiceRequest message from a BE with which it already does have a service relationship, but the terms of the service relationship are to be changed (eg, different security parameters) Case #3: - a BE receives a ServiceRequest message from a BE with which it already does have a service relationship (ie, this ServiceRequest is refreshing the service relationship), and the terms of the service relationship are identical to the previous terms (eg, same security parameters) My impression is that the following should happen in each case: Case #1 - create a new serviceID in the ServiceConfirmation Case #2 - create a new serviceID because we are changing the parameters of the service relationship (it's becoming a new service relationship) Case #3 - do NOT create a new serviceID - the existing relationship is being refreshed, so we should continue to use the same serviceID However, the wording of H.225.0 Annex G does not seem to say this. It seems that in ALL cases, a new serviceID should be created. To me, this seems to be incorrect, and I'm not sure that the original intent took into account case #3. I think that in case #3, we should not be creating a new service ID. The following sections from H.225.0 Annex G are relevant: [from section 1.8.2] service ID - This identifer identifies a particular service relationship session between two border elements. Whenever a border element receives a ServiceRequest message, it allocates a globally unique service ID and returns it to the sender of the ServiceRequest message in the ServiceConfirm message. [from section 1.8.2.5] A border element may send a ServiceRequest message to a border element with which it has an existing relationship, with the intent that the terms of the original relationship be terminated and replaced with the new terms. Service relationships may have limited time to live. A border element may refresh the relationship by sending a new Service Request. [from section 1.8.2.6] Every new service relationship is identified by a service identifier. Whenever a border element receives a new ServiceRequest message, it allocates a unique service ID and returns it to the sender of the service request message in the "service confirm" message. If the border element already has a service relationship with the border element that sent the ServiceRequest message, sending ServiceConfirmation indicates that the terms of the original relationship are terminated and replaced with the new terms. Any comments? If people agree that the wording needs to be changed to unambiguously handle case #3, now is the time to speak up. The deadline for contributions for the Geneva meeting is fast approaching. Michael Fortinsky ----------------------------------------------------------------- Senior Program Manager, IP Telephony Group, VocalTec Communications Ltd. Email: mike(a)vocaltec.com Tel: 972 9 9707768 Fax: 972 9 9561867

2 1

Re: Request for APC numbers
by Sakae OKUBO 20 Oct '00

20 Oct '00

Dear Mr. Euchner, Dear Mr. Anderson, In response to your requests, the following APC numbers have been allocated to your contributions: At 09:09 +0200 00/10/20, Euchner Martin wrote: >The following block of contributions relate to corrections of the H.235 >Version 2 white text for decision: APC-1961 >Source Title >Editor Resolution of an inconsistency in Draft H.235 Version 2 >regarding Section B.4.3 APC-1962 >Editor Resolution of an inconsistency in Draft H.235 Version 2 >regarding the use of the password and shared secret APC-1963 >Editor Clarification on the use of sendersID and generalID in >white Draft H.235 Version 2 APC-1964 >Editor REVISED ITU-T RECOMMENDATION H.235 VERSION 2 - SECURITY AND >ENCRYPTION FOR H-SERIES (H.323 AND OTHER H.245-BASED) MULTIMEDIA TERMINALS >- CORRECTED VERSION FOR DECISION >The following block of contributions relate to the new H.235 Version 3: APC-1965 >Source Title >Editor Draft H.235 Version 3 - Security and encryption for >H-Series (H.323 and other H.245-based) multimedia terminals APC-1966 >Editor Draft H.235v3 Annex F: "Hybrid Security Profile" APC-1967 >Editor Draft H.235v3 Annex G: "Security for H.323 Annex H in H.323 >Mobile Environments" At 14:53 -0400 00/10/20, Terry L Anderson wrote: >Please assign me an APC number for APC-1968 >Title: Draft H323 Annex R. >Source: Editor Best regards, Sakae OKUBO *********************************************************** Waseda Research Center Telecommunications Advancement Organization of Japan (TAO) 5th Floor, Nishi-Waseda Bldg. 1-21-1 Nishi-Waseda, Shinjuku-ku, Tokyo 169-0051 Japan Tel: +81 3 5286 3830 (to be transferred) +81 3 3204 8194 (direct) Fax: +81 3 5287 7287 e-mail: okubo(a)giti.or.jp *********************************************************** ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

Re: QOS signaling in RAS
by Roy, Radhika R, ALCOO 20 Oct '00

20 Oct '00

Hi, Ilyya and Mike: Please see H.323 Appendix II - Transport Level Resource Reservation Procedure. The "transportQOS" field simply provides a mechanism who "controls" the transport level resource reservation: Endpoint or GK. Accordingly, the resource reservation is made by that particular entity. Then each entity can use couple of things related to the resource reservation: 1. BRQ/BCF/BRJ and 2. RSVP (plus ATM QOS for the ATM network as well). Now, items 1 and 2 are independent. Item 1 is in RAS (pre-call setup phase) and item 2 is in H.245 (call setup phase). Here is my own interpretation: Item 1 has the abstraction of bandwidth (generic) that can be used on end-to-end basis. That is, this abstraction is independent of the lower transport network. In other words, the total bandwidth that is required for the H.323 application (audio, video, and data) is expressed in the bandwidth field. However, item 2 is network specific. If there is a single network (either IP or ATM), it may work. If there are two networks (IP + ATM) between the two H.323 endpoints, we have problems to use either RSVP or ATM QOS on end-to-end basis. In addition, H.323 also provides the abstraction of "circuits: DS0s, etc. (indirectly bandwidth)" in the context of the PSTN-Packet network in Q.931 call setup phase. H.323 Annex N is addressing this problem to provide end-to-end QOS not only for the bandwidth parameter, but for all other parameters including delay, jitter, bit-error-rate/packet losses for both: 1. Pre-call setup phase (RAS) and 2. Call setup phase (Q.931/H.245). AT&T is bringing a contribution related to QOS in the upcoming SG16 November'00 meeting. Best regards, Radhika R. Roy AT&T +1 732 420 1580 -----Original Message----- From: Mike Buckley [mailto:mikebuckley@44COMMS.COM] Sent: Friday, October 20, 2000 6:16 AM To: ITU-SG16(a)MAILBAG.INTEL.COM Subject: Re: QOS singaling in RAS Ilya, We are presently reviewing QoS support in H.323 and a new Annex N to H.323 is in preparation. The current H.323 assumes homogeneity of network transport and QoS mechanisms so the only issues to be considered in H.323 are what type if QoS mechanism is supported in the end point. The new work recognises that transport may involve a variety of transport mechanisms e.g. ATM, IP FR, as well as QoS mechanism, e.g. RSVP, DiffServ, MPLS, some of which may be hidden from the end user. Maybe other experts could comment on your specific query. Regards, Mike Buckley Editor Annex N +44-1457-877718 (T) +44-1457-877721 (F) mikebuckley(a)44comms.com ----- Original Message ----- From: "Ilya Freytsis" <ifreytsis(a)CETACEANNETWORKS.COM> To: <ITU-SG16(a)MAILBAG.INTEL.COM> Sent: Thursday, October 19, 2000 7:46 PM Subject: QOS singaling in RAS > Dear experts, > One of the choices of the RegistrationRejectReason (h225 v3) is > "transportQOSNotSupported NULL, -- endpoint QOS not supported". How it should be interpreted since it seems there is nothing > related to transport QOS in registration request PDU itself? > > Ilya Freytsis > Cetacean Networks > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > 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

QOS singaling in RAS
by Ilya Freytsis 20 Oct '00

20 Oct '00

Dear experts, One of the choices of the RegistrationRejectReason (h225 v3) is "transportQOSNotSupported NULL, -- endpoint QOS not supported". How it should be interpreted since it seems there is nothing related to transport QOS in registration request PDU itself? Ilya Freytsis Cetacean Networks ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

2 1