September 1997 - sg16-avd - lists.packetizer.com

Re: A scenario that cannot be solved without APC-1280 or deferred "Connect"
by Benjamin Y C Tang 09 Sep '97

09 Sep '97

Gur, Your observation leads to the general question that whether it is necessary to support the opening of a media channel during the Q931 call signaling procedure. This concerns other scenario as well. For example, when an H323 endpoint calls a POTS user via a gateway, while the Q931 call signaling is in progress it may be required to have a voice channel opened between the endpoint and gatweay to forward a PSTN special announcement ("sorry, the number you dialed is not in service") back to the endpoint. As I remebered, a while ago there was a decision made from this subject group about h323 implementation, that no capability exchange will take place before the Q931 signaling is completed. I am not sure about the rational behind it, but maybe that can be brought up again for discussion. I looked at APC-1280 and found no descriptions for the procedure of using the Progress-UUIE which is proposed to solve the above-mentioned problem. Will this be added later on? Ben Tang Lucent Technologies btang(a)lucent.com

1 0

CRV
by Lior Moscovici 09 Sep '97

09 Sep '97

The latest H.323 draft says that the CRV used on the RAS channel is different from the one used on the Q.931 signalling channel of the same call. However in the latest H.225 draft the matters remain vague, and I quote (8.11.1 - ARQ, and in many other places): callReferenceValue - the CRV from Q.931 for this call; only local validity. This is used by a gatekeeper to associate the ARQ with a particular call. Is it, or is it not the same as in Q.931? Or just the structure is the same? Does H.225 need some clarification? Sincerely, Lior Moscovici

1 0

APC-1289 available
by Robert Webber 09 Sep '97

09 Sep '97

Dear Mr Okubo, Mr Thom, Mr Skran, and SG 16 colleagues: The document APC-1289, H.MediaMIB Progress Report and Draft, has been transmitted to the APC ftp site's Incoming directory. I apologize for the extreme lateness of this contribution. Bob Webber

1 0

A scenario that cannot be solved without APC-1280 or deferred "Connect"
by Gur Kimchi 08 Sep '97

08 Sep '97

When a 323 EndPoint calls an POTS Gateway, the gateway may want to answer and open an audio channel so it can start sending IVR's (such as "Please wait while xxx" or "Thank you for calling the XXX gateway"). Such a call has not yet begun to be billed, as the remote endpoint has not been reached - we are still in the signaling stage. The user will get very angry at the end of the month if he/she gets billed for all the un answered/uncompleted calles he/she made... I do agree that this can also be achieved by exactly documenting the ability to complete 245 negotiation first, and only then send (at some future time, when the POTS phone picks up) the Connect message. Gur Kimchi VocalTec Communications Ltd gur(a)vocaltec.com

1 0

Two reasons to support APC-1276
by Gur Kimchi 08 Sep '97

08 Sep '97

APC-1276 Presents the idea that the IP transport address of the sender can be replaced with 0.0.0.0. there were a few opposing opinions regarding this contribution, but I wanted to share two more reasons why this contribution is required. 1. currently, it is impossible to do End-to-End security in 225/245, as the transport address resides in the PDU itself, by placing 0.0.0.0, this limitation is removed. 2. When an EndPoint is running on a PPP or DHCP on portables, the IP address can change behind the back of the EndPoint - The PPP link may drop, or the Portable may go to sleep and it's DHCP lease expires. While it is complicated to find one's own IP address, it is even more complicated to find out when the IP address changed behind the EndPoint's back. Gur Kimchi VocalTec Communication Ltd gur(a)vocaltec.com

1 0

Re: No concensus for ASN.1 extension support (was: Re: APC-1265)
by Paul Long 07 Sep '97

07 Sep '97

Joerg Ott wrote: > I am wondering whether you are missing the point here. Hey, it could happen. :-) > - H.225.0 signaling carries a protocol identifier in the mandatory part > of all relevant PDUs (RAS as well as call signaling channel) You're right. However, this is a tenuous relationship that should perhaps be documented. Even though H.225.0 is integral to H.323, we need to be extra careful with future versions of these Recommendations to assure that the numbers of associated versions are always the same. The only mention I could find in either H.323 or H.225.0 is editorial, not normative. 6.1/H.225.0: "...both the discovery and registration sequences contain an H.245 style OBJECT IDENTIFIER that allows the vintage to be determined in terms of the version of H.323 implemented." I don't know, maybe such a thing cannot be normative. > - H.323/H.225.0 describe in each revesion explicitly which version of > H.245 to use When I first started on H.323 last year, I asked Jim Toga which version of H.245 to use. He said to use version 2 but that this wasn't documented anywhere. I see now that it is. > and which features of this to implement. As I said in my previous email, H.323 does not specify which ASN.1 extension fields are required. It states which messages and procedures are required but not which extensions are required. This is still a big problem and the principal one that I was addressing in this thread. An endpoint has no way of knowing whether the remote endpoint will recognize a particular extension. This _will_ cause problems like the one I described concerning opening a logical channel. > (And, for clarity, this is *NOT* done in the ASN.1, but in the > references section of the document!) I justed looked, and versions 1 and 2 of both Recommendations cite H.245 version 1--not version 2--in terms of the year of decision (1995 vs 1997). I assume this should be fixed. > Hence you can deduce the H.245 version from the H.225.0 version number > which is determined IN-BAND in the first PDU exchange between any two > H.323 systems. I see this now. Thanks. > And, of course, you cannot add anything to H.245 without > this being appropriate reflected in the H.323/H.225.0 specification. Maybe I misunderstood him, but it sounded like Jim was saying just the opposite, that an H.323 endpoint could use H.245 constructs in a version of H.245 after the version identified in the H.323 Recommendation. See for yourself. What do you think? "If vendors want to utilize some of the constructs from v2 in their v1 implementations (and other entities recognize and respond to them) there is no 'rule' against this." > Also: you are talking about no H.323 version signaling? H.225.0 and H.323 > go together at all times! H.225.0 defines the protocol syntax and H.323 > the procedures; so there is no difference between an H.225.0 and an H.323 > version number! Well, there is a difference, because they are separate Recommendations. However, as long as we have people like you around that know that they must have the same version number, we'll be okay, but there is technically nothing preventing them from having different version numbers. -- Paul Long___________________________http://www.cmpu.net/public/plong Smith Micro Software, Inc.__________http://www.smithmicro.com/

1 0

Re: No concensus for ASN.1 extension support (was: Re: APC-1265)
by Joerg Ott 06 Sep '97

06 Sep '97

Paul, I am wondering whether you are missing the point here. Jim and Mark have stated clearly how things are supposed to work: - H.225.0 signaling carries a protocol identifier in the mandatory part of all relevant PDUs (RAS as well as call signaling channel) - H.323/H.225.0 describe in each revesion explicitly which version of H.245 to use and which features of this to implement. (And, for clarity, this is *NOT* done in the ASN.1, but in the references section of the document!) Hence you can deduce the H.245 version from the H.225.0 version number which is determined IN-BAND in the first PDU exchange between any two H.323 systems. And, of course, you cannot add anything to H.245 without this being appropriate reflected in the H.323/H.225.0 specification. Also: you are talking about no H.323 version signaling? H.225.0 and H.323 go together at all times! H.225.0 defines the protocol syntax and H.323 the procedures; so there is no difference between an H.225.0 and an H.323 version number! But you are right that we should pay attention problems that might arise from version conflicts and to clearly specify how systems are to behave if they encounter that their peer runs a lower version number. Joerg ---------------------------------------------------------------------------- --- Joerg Ott jo(a)tzi.org Universitaet Bremen, Germany fax + 49 421 218-2085 TELES AG voice + 49 421 218-7000

1 0

[Q15-ALL] Meeting Updates
by Gary Sullivan 05 Sep '97

05 Sep '97

To all Q15/16 participants and interested parties from Q11-14/16: I have updated the Sunriver Q15 meeting plan and placed it on the Q15 ftp site (file: q15bT2r2.doc). A copy of our document registration list is also available there (file: q15b00r1.doc). The Q15 ftp site is at: ftp://standard.pictel.com/video-site/ and these documents for Sunriver are found in the sunriver.sep97 directory. Within section 2.2 of the meeting plan document is a list of all issues and documents which appear relevant to the joint sessions of Q.11-15/16 which are scheduled for Tuesday and Thursday. The list is meant to be inclusive, so we may not necessarily want to discuss all those topics in the joint sessions. Among those issues and documents, the ones which pertain to white document contributions for the January meeting of SG16 should probably be given the top priority (e.g., H.245v3 and H.263+ issues). My own impression of our current status is that I am disappointed not to have seen more work done on H.245 for H.263+. Apparently the people who have devoted their time and energy toward designing the H.263+ video coding enhancements have not seen fit to ensure that their new video codec is adopted properly into the terminals that are intended to use it (with the exception of those working on Annex N of H.263). This is mystifying, because a video coding standard is not much good if it isn't used in anything, and H.245 is not that hard to understand. I hope that we can improve the H.245 content substantially in Sunriver. I want to encourage all concerned to have a look at that issue and to think about what is needed. We will need to assess the state of our work on this issue as the Sunriver meeting progresses. A copy of the current draft of H.245v3 can be found at: ftp://standard.pictel.com/avc-site/9706_Her/APC-1192.zip (within which can be found h245wcma.ww2). Best Wishes, Gary Sullivan PictureTel Corp. M/S 635 Tel: +1 978 623 4324 100 Minuteman Road Fax: +1 978 749 2804 Andover MA 01810 USA Email: garys(a)pictel.com

1 0

Re: No concensus for ASN.1 extension support (was: Re: APC-1265)
by Paul Long 05 Sep '97

05 Sep '97

Mark Reid wrote: > A H.323 Version 2 terminal will use H.225.0 Version 2 which does have a > protocol identifier which is carried in all of the Q.931 messages. > A terminal which is H.323 Version 2 will use H.245 Version 3 and will have > to support H.245 features which are called out in H.323 as mandatory. So are you saying that an endpoint can deduce the H.323 version of the remote endpoint based on the version of the underlying H.225.0 or H.245? The last time I looked, H.323 version 1 does not specify which version of H.245 it requires. We all know (out-of-band, of course) that it has to be at least version 2, but one cannot deduce the H.323 version based on the H.245 version--a version-1 H.323 endpoint could use any version of H.245. I believe that this is also the case for H.225.0. Assuming that an endpoint cannot know the H.323 version of the remote endpoint, consider this theoretical requirement added to H.323 version 2: "An endpoint shall do X in response to message Y," and Y is represented as an ASN.1 choice extension of UserInputIndication in H.245. What if the sending endpoint relies on the X behavior, a special form of DTMF signaling via Y? The endpoint has no way of knowing whether the remote endpoint will in fact do X, because it doesn't know the H.323 version of the remote endpoint. If it knew that the remote endpoint was in fact a version-1 H.323 endpoint, it might have used fall-back DTMF signaling via message Z which is in the root extension and therefore recognized by all endpoints. And, for several reasons, the endpoint cannot rely on receiving a FunctionNotSupported indication to tell it that the remote endpoint didn't recognize Y. > H.323 > is the document which says what parts of H.245 are mandatory ... not H.245 > ... as it is used by H.310, H.324 ....etc. Now for the second problem. There is not sufficient detail in these prescriptions. For example, "H.323 endpoints shall support the syntax, semantics, and procedures of ... Logical Channel Signaling." Okay, that's clear, but what if the following happens between two version-2 H.323 terminals: A terminal specifies a capability represented by a field is not in the root extension (let's say one of those for H.263+) in an OpenLogicalChannel request, the remote terminal does not recognize extension additions up to that field and acks the open even though it does not support that capability. Whoops! The channel is established and the endpoint transmits a stream that the remote terminal cannot decode. These kinds of things will happen unless we require that endpoints support all of the ASN.1 syntax of the version of H.245 that it indicates in its protocolIdentifier field. > Version 2 lives! The sky is falling! :-) -- Paul Long___________________________http://www.cmpu.net/public/plong Smith Micro Software, Inc.__________http://www.smithmicro.com/

1 0

None
by Sakae Okubo 05 Sep '97

05 Sep '97

's message of Wed, 3 Sep 1997 10:48:47 +0200 <308240572791420003WIPLIEZ*/G=Christian/S=Wipliez/OU=lannion/PRMD=cnet/ADMD=ATLAS/C=FR/@MHS> Subject: Overhead projector BCC: okubo Dear Mr. Wipliez, >>For the Sun River meeting, I will bring slides of the CNET >>contribution. Is it OK for presenting these slides with a >>projector? Assuming you mean an overhead projector (not 35mm slide projector), I have received the meeting host's confirmation that the meeting room is equipped with it. Best regards, Sakae OKUBO (Mr.) ******************************************************************** Graphics Communication Laboratories Phone: +81 3 5351 0181 6F ANNEX TOSHIN BLDG. Fax: +81 3 5351 0184 4-36-19 Yoyogi, Shibuya-ku, Tokyo e-mail: okubo(a)gctech.co.jp 151 Japan ********************************************************************

1 0