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 …
[View More]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
[View Less]
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 …
[View More]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
[View Less]
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 …
[View More]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.
>>
[View Less]
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
>
> …
[View More]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
[View Less]
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-…
[View More]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 ***
*****************************************************
[View Less]
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 …
[View More]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
[View Less]
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.
***…
[View More]
*** 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 ***
*****************************************************
[View Less]
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
…
[View More]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
[View Less]
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 …
[View More]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
>
>
[View Less]
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 …
[View More] ggf(a)lucent.com
Lucent Technologies office: +1 303 538 2899
11900 N. Pecos fax: +1 303 538 3907
Westminster, Colorado 80234 USA
[View Less]
