- sg16-avd - lists.packetizer.com

unreadable APC-1266 now in Incoming on gctech ftp site
by Greg Goodknight 10 Sep '97

10 Sep '97

Dale, The very late submission, APC-1266 "Using H.323 call control for Fax over IP", dated "Tue Sep 10 15:49:00 1996" [1996 is not a typo on my part], APC-1266.doc, just now downloaded onto ftp://itu-t:sg15!avc@ftp.gctech.co.jp/Incoming/ is not readable by either my Wordviewer version 7.1 or by Word for Win 95 7.0. -Greg _____________________________________________________ Greg Goodknight Software Engineer Cisco Systems Global Alliance Engineering *****************ggoodkni(a)cisco.com***************** Direct: 408 527 9358 Home Office: 916 274 0443 San Jose,CA Nevada City, CA

1 0

Audio packetization schemes
by Smita Gupta x5499 10 Sep '97

10 Sep '97

I am looking for information on audio packetization schemes for H.323 terminals. In particular I would like to find out if RTP audio packetization schemes exist for any of the audio encoders - G.728, G.722, G.711, G.723.1, G.729 etc. and if so where can I find the documentation. Thanks Smita Gupta _________________________________________________________________ Smita Gupta VTEL Corp., 350 E. Plumeria Avenue Mail Stop 1-1R San Jose, CA 95134-1900 e-mail: smita(a)vtel.com Phone: (408) 922-5499 FAX: (408) 232-6165 __________________________________________________________________

2 1

Re: A scenario that cannot be solved without APC-1280 or deferred "Connect"
by Scott Petrack 09 Sep '97

09 Sep '97

Ben, Discussion in Sun River brought out that a careful reading of H.225, H.245, and H.323 implies the following: 1. It is allowed to start H.245 negotiation as soon as the CallSetup message is received. 2. Once H.245 negotiation begins, it can proceed to open logical channels at it's own pace. 3. Once an open logical channel is opened and acknowledged, media streaming should begin right away. So it seems to be entirely possible to do media streaming before a CONNECT message, and the CONNECT message can retain its usual Q.921 meaning. You can call this "deferred Connect", but it'd be better not to give it any special name. It's just a compliant H.323 implementation. The CONNECT isn't deferred, it comes at just the right time -- when the endpoint wants to signal that the call has connected.... This may or may not be after some media has been streamed. Scott Petrack Principal Technologist VocalTec Communications Ltd. petrack(a)vocaltec.com btang(a)LUCENT.COM on 09/09/97 04:50:36 PM Please respond to ITU-SG16(a)mailbag.jf.intel.com To: ITU-SG16(a)mailbag.jf.intel.com cc: (bcc: Scott Petrack) Subject: Re: A scenario that cannot be solved without APC-1280 or deferred "Connect" 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

IRR Fields
by Lior Moscovici 09 Sep '97

09 Sep '97

I have some questions/remarks regarding the IRR fields as defined in H.225: There is an inconsistency between the ASN.1 definition and the textual description in 8.15.2. The ASN.1 is more up to date. Specifically, the perCallInfo field is missing in 8.15.2. According to the ASN.1 definition: can a single IRR really refer to more than one call? As perCallInfo is a SEQUENCE of SEQUENCES, one per call, it seems to be so, but the callIdentifier is outside the perCallInfo field, and thus there is only one of it. To which of the calls is it supposed to refer to? Sincerely, Lior Moscovici

1 0

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