- sg16-avd - lists.packetizer.com

Annex G Conference Call
by Orit Levin 09 Jul '98

09 Jul '98

Hello again! What happened to the Conference Call? Was it my fault? Did I talk too much (sorry about that)? My last words were (I am not sure you could hear) there are two things to do: 1. Intel's proposal can be adopted (as "an interim" solution for specific "address resolution" problem) , but in order to be interoperable and useful it should be, in my opinion, more tide: - less flexible syntax - defined push mechanism Jim, do you mind send to you some concrete remarks? What do you think about using NAI instead? 2. In parallel, I believe, we have start working towards the more complete solution, starting from the "architectural" definition and things that we want to accomplish "as far as we can see now". Orit Levin RADVision Inc., 575 Corporate Drive - Suite 420 Mahwah, NJ 07430 Tel: 201-529-4300 (230) Fax: 201-529-3516

2 1

H.235 & Implementors Guide
by Orit Levin 09 Jul '98

09 Jul '98

Jim! Just before the closure of Implementors Guide regarding the 4.2 EP-GK Authentication (Non-Subscription Based) Is our understanding of the XOR'ing algorithm right? See below: 1. Take the GK Id (GKID) as a sequence of BMP characters (each 16 bit long) of length N. 2. Take the 16 bit long Random value (RND) N times to build the string of the same length as GKID above. 3. Take the 16 bit long requestSeqNum (SQN) N times to build the string of the same length as GKID above. 4. XOR bitwise three of these same length bit strings. GKID !BMP1 !BMP2 !BMP3 !BMP4 !BMP5 ! XOR RND 16 bit !RND16!RND16!RND16!RND16 !RND16! XOR SQN 16 bit !SQN16!SQN16!SQN16!SQN16!SQN16! May be it would be useful to put such an explanation into the Implementors Guide? Orit Levin RADVision Inc., 575 Corporate Drive - Suite 420 Mahwah, NJ 07430 Tel: 201-529-4300 (230) Fax: 201-529-3516

1 0

Re: H.225 clarifications
by Orit Levin 08 Jul '98

08 Jul '98

Glen! (1) and (2) together (filled with zeros) Definitely not (3), since V.2 is already deployed. Orit Levin RADVision Inc., 575 Corporate Drive - Suite 420 Mahwah, NJ 07430 Tel: 201-529-4300 (230) Fax: 201-529-3516 >>Item 2: >>The callIdentifier field is not currently optional in the IRQ. I see >>these possibilities for callIdentifier in the case of a request for >>information about all calls: >> >>1) state that if callReferenceValue is 0, this field is to be ignored >>but filled with some data >> >>2) state that callIdentifier should be set to some dummy value, such as >>all zeros >> >>3) change the ASN.1 definition so that callIdentifier is OPTIONAL, and >>add appropriate text regarding its use in the field definition >> >>Since callIdentifier is defined as a SEQUENCE to allow possible future >>expansion, I'd suggest option 1. >> >>Please comment. >>

1 0

Re: H.324 and laptop kits
by Jong Kim 07 Jul '98

07 Jul '98

Dear Mathieu: If you got some information on teleconferencing camera, would you possibly forward it to me? I am developing teleconferencing product on PC, so your information will be very appreciated. Thanks. Jong-il Accelerix Inc., http://www.accelerix.com Austin Texas > -----Original Message----- > From: Mathieu Weill [SMTP:Mathieu_Weill@INMARSAT.ORG] > Sent: July 1, 1998 10:39 AM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: H.324 and laptop kits > > Currently testing some H.324 and H.323 applications, and how they > interwork, I > am looking for H.324 compliant videoconferencing kits, with camera, > software, > modem and so on that would be available in Europe. Has anyone details > about such > products? > > I also want to set up a demonstration of H.323 or H.324 using a notebook > and I'm > looking for a kit that could be adapted to both standards, the main > concern > being the H.324 compatibility of the modem and its tying to the software. > > Any information would be most valuable > > Thanks > > Mathieu Weill > Mathieu_Weill(a)inmarsat.org > > Reply by email please

1 0

ICV: A request for closure...
by Jim Toga 07 Jul '98

07 Jul '98

All interested parties.... I feel as though we are quite far from reaching a solution to the ICV coding problem. There were a number of proposals made some providing solutions that may or may not have been backward compatible. As I have approximately 72 hours to get this into the white paper of the Implementers guide... we need to come to closure. An alternative is to 'fix' this in rev3 of H.225.0 (when and/if we include non-repudiation). One argument for this is that if you want ICV/non-repudiation you may run IPSec or some other security 'tunnel' which keeps the complexitites from H.225.0 and ASN.1 Thoughts?.... (clock is ticking) jimt. ***************************************************** *** +1-503-264-8816(voice) Intel - Hillsboro, OR. *** *** mailto:jim.toga@intel.com mailto:james.toga@ties.itu.int *** *** PGP keyID 36 07 86 49 7D 74 DF 57 50 CB BA 32 08 9C 7C 41 *** *****************************************************

1 0

H.225.0 Annex G discussion
by Glen Freundlich 07 Jul '98

07 Jul '98

There will be a conference call on Thursday, 9 July, at 7:00am Pacific Time (10:am Eastern Time) to discuss H.225.0 Annex G. We've reserved an audio bridge with enough ports to handle the number of people who responded to the first notice of this topic. The bridge number is +1 916 356 9200, passcode 9774794 (conference name is "H.323 Annex G", chair is Jim Toga). This call will be limited to 1 hour. Minutes from the call will be published to the SG16 email list. The goal of this call will be to get work going on Annex G. A tentative agenda is: - review the work that's been done so far - terms of reference - system organization - definitions - APC-1422 - what's up with Diameter - decide what we'd like to see for determination in September (i.e., set the initial scope of work) - enumerate open issues - set some kind of work plan - prioritize open issues - decide who will work specific issues - calls every 2 weeks Good preparation material would be the existing Annex G (APC-1375 from Cannes), APC-1422, APC-1385, APC-1407, APC-1414, TD-27, and the terms of reference from the Yokosuka meeting (TD-17 from Yokosuka). Glen Freundlich ggf(a)lucent.com Lucent Technologies office: +1 303 538 2899 11900 N. Pecos fax: +1 303 538 3907 Westminster, Colorado 80234 USA

1 0

Next pass of Implementers Guide
by Jim Toga 06 Jul '98

06 Jul '98

Greetings, Attached please find the updated Rev2 Implementers Guide. All of the changes highlighted in gray text are post Cannes meeting. I have not incorporated any of the ICV changes as it doesn't seem like we have reached any clear solution...... Please get feedback to me before Thursday PM, as I need to send the white document into the TSB. Best Regards, jimt. ***************************************************** *** +1-503-264-8816(voice) Intel - Hillsboro, OR. *** *** mailto:jim.toga@intel.com mailto:james.toga@ties.itu.int *** *** PGP keyID 36 07 86 49 7D 74 DF 57 50 CB BA 32 08 9C 7C 41 *** *****************************************************

1 0

H.225.0 clarifications
by Glen Freundlich 06 Jul '98

06 Jul '98

A couple clarifications may be needed regarding the IRQ message in H.225.0. Item 1: The definition of callReferenceValue currently states "If zero, this message is interpreted as a request for an IRR for each call the terminal is active on." The IRR defines perCallInfo as a SEQUENCE OF SEQUENCE and I seem to recall that the original intent was to be able to pass information about multiple calls within a single IRR message. So, I'd suggest changing the definition to "If zero, this message is interpreted as a request for perCallInfo for every call that is active at the endpoint, and which may be sent in one or more IRRs". Item 2: The callIdentifier field is not currently optional in the IRQ. I see these possibilities for callIdentifier in the case of a request for information about all calls: 1) state that if callReferenceValue is 0, this field is to be ignored but filled with some data 2) state that callIdentifier should be set to some dummy value, such as all zeros 3) change the ASN.1 definition so that callIdentifier is OPTIONAL, and add appropriate text regarding its use in the field definition Since callIdentifier is defined as a SEQUENCE to allow possible future expansion, I'd suggest option 1. Please comment. Glen Freundlich ggf(a)lucent.com Lucent Technologies office: +1 303 538 2899 11900 N. Pecos fax: +1 303 538 3907 Westminster, Colorado 80234 USA

2 1

Re: ASN.1 accross revisions
by Pete Cordell 03 Jul '98

03 Jul '98

Bancroft and others, I take your point that putting a second piece of ASN.1 into the UUIE may jeopardize backwards compatibility. I have to admit that I have to try quite hard to read H.225 in such a way that it allows me to do this (but it is possible!!!). The basic issue is whether having read and decoded the ASN.1 in the UUIE, implementations check whether all characters in the UUIE have been used. I guess only a poll of vendors would determine whether this is the case. An alternative to adding on an extra piece of ASN.1 in the case of the Q.931 side would be to hi-jack one of the other IEs that we are unlikely to use, and use that for the signature values. For example one that we might use is "Packet Layer Binary Parameters" which has an IE value of 0x44. Pete ================================= Pete Cordell BT Labs E-Mail: pete.cordell(a)bt-sys.bt.co.uk Tel: +44 1473 646436 Fax: +44 1473 645499 ================================= >---------- >From: Bancroft Scott[SMTP:baos@oss.com] >Sent: 30 June 1998 21:21 >To: Pete Cordell >Cc: 'ITU-SG16(a)MAILBAG.INTEL.COM' >Subject: RE: ASN.1 accross revisions > >On Tue, 30 Jun 1998, Pete Cordell wrote: > >> I admit that I am only just hanging in there with this debate, but I >> think I have a possible solution 5 to throw in as a contender. >> >> Looking at the problem a bit laterally, we have RasMessage in UDP >> packets that we want to sign, and H323-UserInformation in the UUIE that >> we want to sign. Currently these are the only chunks of ASN.1 in these >> fields. >> >> We could add a second piece of ASN.1 into these fields (UDP packet and >> UUIE) that contains the signatures, such as: >> >> H323Extra ::= CHOICE >> { >> icv ICV, >> ... >> } >> >> This would be a separate ASN.1 tree. Therefore in a RAS UDP packet you >> would get: >> >> RasMessage chunk of ASN.1 >> H323Extra chunk of ASN.1 typically containing signature >> >> Similarly in the UUIE, you would have >> >> H323-UserInformation chunk of ASN.1 >> H323Extra chunk of ASN.1 >> >> Note that all the key ids and time stamps etc., would remain in the >> RasMessage and H323-UserInformation parts (so they get signed). >> >> I agree this is not beautiful, but it does not require multiple ASN.1 >> encodings, and doesn't radically change the format of the message >> depending on whether you want to sign it or not (as solution 4 seems >> to). > >This crossed my mind a couple days ago, but it is not clear how this >would >be backward compatible. That is, how would an older version handle >this >added information that comes after the H323-UserInformation? I like >the >general idea, but if I am not mistaken it is not backward compatible. > >I have an idea as to how to do as you suggest in a backward compatible >manner, but before I go down that path I need to know the answer to >the question: Are the most recent implementations that know of H.323 >required to transmit an ICV with each RasMessage or >H323-UserInformation? > >------------------------------------------------------------------------ >-- >Bancroft Scott Toll Free >:1-888-OSS-ASN1 >Open Systems Solutions, Inc. >International:1-609-987-9073 >baos(a)oss.com Tech Support >:1-732-249-5107 >http://www.oss.com Fax >:1-732-249-4636 > >

1 0

H.225.0 Annex G discussion
by Glen Freundlich 02 Jul '98

02 Jul '98

I'd like to get some traction on Annex G, and so would like to propose holding a brief (no more than 1 hour) conference call on Thursday, July 9 beginning at 7:00 am Pacific Time in the U.S. (10:00 am Eastern Time, is that 16:00 in the U.K.?). I'll send out an agenda on Monday, July 6. If you are interested in joining this call, please let me know by Monday, July 6, 14:00 Mountain Time in the U.S. so that I can arrange for a bridge with a sufficient number of ports. Glen Freundlich ggf(a)lucent.com Lucent Technologies office: +1 303 538 2899 11900 N. Pecos fax: +1 303 538 3907 Westminster, Colorado 80234 USA

1 0