- sg16-avd - lists.packetizer.com

H.225.0 V2 decided and Anenx D to H.323 determined
by Sakae Okubo 17 Mar '98

17 Mar '98

Dear SG16 colleagues, The subject documents are available at the following locations: ftp://itu-t:sg15!avc@ftp.gctech.co.jp/9801_Gen/H2250v2w.zip ftp://standard.pictel.com/avc-site/9801_Gen/H2250v2w.zip ftp://itu-t:sg15!avc@ftp.gctech.co.jp/9801_Gen/h323-annexD.zip ftp://standard.pictel.com/avc-site/9801_Gen/h323-annexD.zip 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-0053 Japan ********************************************************************

1 0

Upcoming SG16 experts meetings in Yokosuka
by Kiyoshi SAKAI 17 Mar '98

17 Mar '98

Dear SG16 Q.11, Q.12-14 Experts, As we have announced earlier, March 20 is the deadline for the registration and hotel reservation for the SG16 Yokosuka meeting. If you plan to attend the meeting, please register as soon as possible according to the following directions; 1) Registration form should be sent to "harasaki(a)ccm.cl.nec.co.jp" with copy to Rapporteurs. 2) Hotel reservation form should be faxed to Yokosuka Prince Hotel. Block room reservation will expire on March 20, however, the hotel will continue to accept your reservation at the same price after the deadline only if the rooms are available. Registration and hotel reservation forms are attached to this mail. Best regards, Hidenobu Harasaki, NEC Corporation Kiyoshi Sakai, Fujitsu Laboratories LTD. ********************************************************************** Kiyoshi Sakai Media Processing Laboratory Multimedia Systems Labs. FUJITSU LABORATORIES LTD. Tel. : +81 44 754 2679 Fax. : +81 44 754 2347 E-mail : sakai(a)flab.fujitsu.co.jp **********************************************************************

1 0

New files on q11-site (lbc-site)
by Tom Geary 17 Mar '98

17 Mar '98

Forwarded to the ITU email reflector for SG16/Q.11in hopes that some if not all of the ITU member experts will get it during the time the normal q.11 reflector is not operating. Thanks, Tom Geary -------------------- Forwarded by Tom A Geary/RSS/Rockwell on 16-03-98 22:42 --------------------------- Tom A Geary 14-03-98 21:04 To: sg16.lbc(a)research.kpn.com, webberr(a)pictel.com cc: Subject: New files on q11-site (lbc-site) Dear SG16 Q.11 Experts: I have uploaded files for the proposed agendas for Yokosuka and Tampere Q.11 experts meetings, q11dtd2.doc an q11etd2.doc. Also I have assigned a number to the invitation (and in the case of Tampere, the registration) letters from our gracious hosts and have uploaded these as well, q11d01.doc for Yokosuka and q11e01.doc along with q11e05.doc for Tampere. I have also uploaded a document for each meeting, q11d04.doc and q11e04.doc which is the updated SG16 Q.11 meeting report (with change marks from the one presented in the WP2 meeting in Geneva adding missing TD numbers and revising the agenda of the Yokosuka and Tampere meetings) as discussed in the WP2 meeting. Mr. Webber: Can you move all files with q11dnn.ccc names to the /yokosuka.April98 folder and all with q11enn.ccc names to the /tampere.April98 folder. (Also you can delete file Q11_trac from the /lbc-site/dropbox, it was just a reference file for the Q.11 documents to the January Geneva meeting and .) Also please move files h223c_13_details.zip and h324c_21_details.zip to the /lbc-site/LBCmobile/documents directory. Thanks, Tom Geary

1 0

IETF iptel working group
by Scott Bradner 13 Mar '98

13 Mar '98

fyi - the IETF IPTEL working group has been formed and will be meeting during the IETF meeting in LA the end of the month. The charter for the working group, along with information about subscribing to the mailing list can be found at http://www.ietf.org/html.charters/iptel-charter.html Scott

1 0

Migration Indication
by Euchner Martin ZT IK 3 13 Mar '98

13 Mar '98

------------------------------- Die MS Mail Adresse Ihres Teilnehmers "Euchner Martin ZT IK 3" ist nur noch bis Juni 98 gueltig und wurde an die neue Exchange Adresse weitergeleitet. Sie finden die neue Exchange Adresse im Adressbuch - des MS Mail Clients unter "Globaler Adressliste -> Euchner Martin(Exchange)" - des Exchange Clients unter "Globaler Adressliste -> Euchner Martin". Passen Sie ggf. Ihr pers. Adressbuch an. MfG SBS CS

1 0

None
by Stefan.Leuenberger＠ASCOM.CH 13 Mar '98

13 Mar '98

subscribe itu-sg16

1 0

Request for APC-Numbers
by Sakae Okubo 12 Mar '98

12 Mar '98

Dear Mr. Korpi, In response to your request, the following APC numbers have been allocated to your three contributions: APC-1328 Proposal for Call Hold Supplementary service in H.323 (H.450.Hold) APC-1329 Proposal for Call Park/Call Pickup supplementary service in H.323 (H.450.Park+Pickup APC-1330 Proposal for Call Waiting Supplementary Service H.323 (H.450.CallWaiting) 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-0053 Japan ********************************************************************

1 0

Fast Connect and mediaChannel
by Orit Levin 12 Mar '98

12 Mar '98

> Toby, Jim, Pete and all others! > > During the implementation of Fast Connect Procedure, we found two > pitfalls regarding the use of Transport Addresses as it are currently > defined. For compatibility sake I provide following > clarifications for your revision: > > 1. In chapter 8.1.7.1 Proposal, Selection, and Opening of Media > Channels is written: > "The mediaChannel element shall be set appropriately according to the > calling endpoint requirements; different values may be used in > alternative proposals if desired." > > As a part of the "Fast Connect Procedure", it is the responsibility of > the called endpoint to decide about the coupling of proposed incoming > and outgoing media streams for each SessionId. According to RTP/RTCP > specifications, such a couple uses a common RTCP channel. Besides > there are implementations, that rely on dependency between RTP and > RTCP ports values. > As a result of all that, "different values" for proposed (by the > calling endpoint) mediaChannels can NOT be used within the same > SessionId. > It means that in the SETUP message all alternative OpenLogicalChannel > structures, that propose a channel for transmission from the called > endpoint to the calling endpoint, shall contain not only the same > sessionID value but also the same mediaChannel value. > > 2. The "Fast Connect Procedure" doesn't explicitly define how the RTCP > port values are provided. In order to support the general case > (including one direction media transmission) and in accordance with > (1) above, the following procedures shall be performed in addition to > the described in H.323. > > In the SETUP message, each OpenLogicalChannel which proposes a channel > for transmission from the calling endpoint to the called endpoint, > shall contain mediaControlChannel element (indicating the reverse RTCP > channel) into the H2250LogicalChannelParameters element of the > forwardLogicalChannelParameters structure. > In the SETUP message, each OpenLogicalChannel which proposes a channel > for transmission from the called endpoint to the calling endpoint, > shall contain mediaControlChannel element (indicating the RTCP channel > going in the same direction) into the H2250LogicalChannelParameters > element of the reverseLogicalChannelParameters structure. > All mediaControlChannel elements inserted by the calling endpoint for > the same sessionID for both directions shall have the same value. > > When accepting a proposed channel for transmission from the calling > endpoint to the called endpoint, the called endpoint shall return the > corresponding OpenLogicalChannel structure to the calling endpoint, > inserting a valid mediaControlChannel element (indicating the RTCP > channel going in the same direction) into the > H2250LogicalChannelParameters element of the > forwardLogicalChannelParameters structure. > When accepting a proposed channel for transmission from the called > endpoint to the calling endpoint, the called endpoint shall return the > corresponding OpenLogicalChannel structure to the calling endpoint, > inserting a valid mediaControlChannel element (indicating the reverse > RTCP channel) into the H2250LogicalChannelParameters element of the > reverseLogicalChannelParameters structure. > All mediaControlChannel elements inserted by the called endpoint for > the same sessionID for both directions shall have the same value. > > I propose that we put such sort of clarifications into H.323 > Implementers Guide. > What is your opinion and what is the procedural way to do that? > > Best Regards, Orit Levin RADVision Inc. E Mail: orit(a)radvision.com 575 Corporate Dr., Suite 420 Tel: 201-529-4300 ext. 230 Mahwah, NJ 07430 Fax: 201-529-3516

1 0

Re: GK-handled call diversion.
by Korpi Markku PN VS LP3 11 Mar '98

11 Mar '98

See my in-line comments below: --Markku Korpi >-----Original Message----- >From: Michele Bozier WVdevmt-WS [SMTP:mbozier@MADGE.COM] >Sent: Wednesday, March 11, 1998 6:19 PM >To: ITU-SG16(a)mailbag.jf.intel.com >Subject: Fwd: GK-handled call diversion. > >Hi all, > >I have a question about the H450.3 Call Diversion recommendation when the >gatekeeper handles the diversion. > >Figure 12 in section 10 shows the signalling flow for Call forwarding >unconditional being handled by a gatekeeper. My concern is that the figure >shows the gatekeeper informing the 'called' user that the call has been >diverted away from it, using an H.225 Setup message. In order for this not >to create confusion, the gatekeeper must know that the called user >understands H450.2 (e.g. if the called user were a Version 1 endpoint then >it would surely wrongly interpret this Setup as an incoming call). >[MKo] The Notification Setup of H.450.2 contains in the Bearer >Capability/Octet 3 "call independent signaling connection". Since the BC is >a mandatory IE in H.323 version 1, the correct response should be Release >Complete message with Cause=Mandatory information element error. Therefore >the interpretation of the Notification as an incoming call is not legal >according to H.323 V.1. > >The text in the standard which relates to the sending of this information to >the called user (H450.2 APDU divertingLegInformation4), states that this >message is sent by the gatekeeper only if the option 'served user >notification' applies. As far as I can see, this option is a local >configuration matter at the served endpoint. My question is, how does a >gatekeeper work out whether or not this option is set in a standard way? >[MKo] The GK would have some network management functions, by means of which >the local configuration can be influenced either by the user or by the >network manager or by both. >Therefore we do not need signaling capabilities in the H.450.3 for this >purpose. > >Thanks for your help >Michele >---------------------------------------- >Michele Bozier >Principal Development Engineer >Madge Networks, Wexham Springs, Framewood Rd, Wexham, >Slough SL3 6PJ, England >Tel: +44(0)1753 661331 Fax: +44(0)1753 661011 >email:mbozier@madge.com

1 0

Fwd: Re: Signalling required SCN call bandwidth
by Michele Bozier WVdevmt-WS 11 Mar '98

11 Mar '98

All, Apologies if you've already seen this email before. So far, the only suggestion I've received is that no endpoints really use the multirate info correctly and so MCUs/ gateway manufacturers have to have knowledge of the type of H.320 call to make, based on the called number. It strikes me that having the ability to at least signal the required bandwidth for the call in the H.225 Setup message, even if you don't include WAN specific call setup parameters such as bonding/H.221-aggregration/Hybrid call, could be of value. What does everyone else think? Michele ---------------------------------------- Michele Bozier Principal Development Engineer Madge Networks, Wexham Springs, Framewood Rd, Wexham, Slough SL3 6PJ, England Tel: +44(0)1753 661331 Fax: +44(0)1753 661011 email:mbozier@madge.com ---------------------------------------- Hi all, I have a question about how to signal a multiple 'B' channel SCN call from an H.323 endpoint. The bearer capability information element in standard Q.931 allows you to signal a Multirate call and then specify the bandwidth (in multiples of 64Kbps) using the optional rate multiplier octet (octet # 4.1). My question is how do I signal an n * 'B' channel call from my H.323 endpoint, where the channels are aggregated using H.221 framing or Bonding? Reading the H.225 standard, the description of the Rate multiplier field indicates that it 'shall' be present if the call is Multirate as per standard Q.931. It then goes on to say that: 'For a call originated from an H.323 endpoint, this SHALL be used to indicate the bandwidth to be used for this call'. Is this field only mandatory if I am doing Multirate, or is the intention that it should be used to indicate the number of 'B' channels irrespective of how the ISDN call is placed (Multirate,multi-H.221 or Bonded)? (My understanding of pure Q.931 is that it really only ought to be present in the Multirate case). If I can't use the rate multiplier octet in the non-Multirate case, is there a standard way I can signal a 2 * B, or 6 * B channel call? Thanks in advance for your help! Michele Bozier

1 0

Fwd: GK-handled call diversion.
by Michele Bozier WVdevmt-WS 11 Mar '98

11 Mar '98

Hi all, I have a question about the H450.3 Call Diversion recommendation when the gatekeeper handles the diversion. Figure 12 in section 10 shows the signalling flow for Call forwarding unconditional being handled by a gatekeeper. My concern is that the figure shows the gatekeeper informing the 'called' user that the call has been diverted away from it, using an H.225 Setup message. In order for this not to create confusion, the gatekeeper must know that the called user understands H450.2 (e.g. if the called user were a Version 1 endpoint then it would surely wrongly interpret this Setup as an incoming call). The text in the standard which relates to the sending of this information to the called user (H450.2 APDU divertingLegInformation4), states that this message is sent by the gatekeeper only if the option 'served user notification' applies. As far as I can see, this option is a local configuration matter at the served endpoint. My question is, how does a gatekeeper work out whether or not this option is set in a standard way? Thanks for your help Michele ---------------------------------------- Michele Bozier Principal Development Engineer Madge Networks, Wexham Springs, Framewood Rd, Wexham, Slough SL3 6PJ, England Tel: +44(0)1753 661331 Fax: +44(0)1753 661011 email:mbozier@madge.com

1 0

Re: Far End Camera Control in H.323
by Roni Even 11 Mar '98

11 Mar '98

Hi, FECC is not defined yet in the standards. In the Geneva meeting the decision was to supply basic AVC through the H.323 protocols. One of the areas to be discussed in the Japan Q.13/Q.14 meeting is FECC, contributions are welcome. Roni Even Accord Video Telecommunication email:roni_e@accord.co.il ______________________________ Reply Separator _________________________________ Subject: Far End Camera Control in H.323 Author: <ITU-SG16(a)MAILBAG.INTEL.COM> at internet Date: 3/4/98 4:40 PM Hello all, I have some questions pertaining to Far End Camera Control in H.323. I would appreciate it much if someone could please answer them. Is FECC going to be done through the T.120 channel? If so, then is H.281 encapsulated within t.120 stack? Or has the Standards committee come up with a different scheme to do Far End Camera Control? Thanks in advance, Anupama Phone: 408-922-4785 email: anupama(a)vtel.com

1 0

new job Mascha van Dort
by Dort, M. van 11 Mar '98

11 Mar '98

Dear SG16 colleagues, As from next monday I'll start at a new job at PTT Telecom. I would like to thank you for working together - it's been a pleasure. Maybe we'll meet somewhere. Since my email address will cease to exist, can someone please remove it from the list? regards, Mascha van Dort >temporary email address: mascha(a)happy.demon.nl

1 0

H.323 Annex D in the Incoming directory of gctech ftp site
by Tirtsa Hochberg 11 Mar '98

11 Mar '98

Hello, My name is Tirtsa and I'm working in IBM Haifa with Yoav Meidan and Haim Nelken. I'm interested in reading "The determined version of H.323 Annex D (Real Time Facsimile over H.323)". I tried looking for the gctech ftp site with no success. Do you have a better pointer as of the location of this version? If you do' I will appriciate it if you could send it to me. Thanks Tirtsa Hochberg HRL.

1 0

Re: this may be of interest to this group
by Scott Bradner 10 Mar '98

10 Mar '98

-- This is definitely in the realm of the work that TIPHON is doing. Are there any liaisons between the groups? -- not now but I'd like there to be Scott

1 0

Re: this may be of interest to this group
by Pedro Colaco 10 Mar '98

10 Mar '98

This is definitely in the realm of the work that TIPHON is doing. Are there any liaisons between the groups? By the way, I think we should make an active effort to standardize language. In the voice world the party you refer as "callee" is the "Calling party". The "calling party" calls the "called party". Does this make sense, and if so should we use these terms consistently thorughout all the working groups dealing with IP Telephony (IMTC, ITU, ETSI, IETF)? Best regards Pedro Colaco Sr. Product Manager - InterXpress IP Telephony Product Line Siemens

1 0

H.323 Annex D in the Incoming directory of gctech ftp site
by Vineet Kumar 09 Mar '98

09 Mar '98

Dear Colleagues, The determined version of H.323 Annex D (Real Time Facsimile over H.323) has been posted to the Incoming directory of the gctech ftp site. A number of issues are documented in this draft and I prefer to resolve them before the Yokusuka meeting. Please send your comments/solutions/etc. on this reflector. Thanks. vineet kumar intel corporation (+1) 503-264-3439

1 0

H.323 and NAT
by Annika Kilegran 09 Mar '98

09 Mar '98

Network Address Translation (NAT) is used as a solution to the problem of few available IPv4 addresses. The idea is to use private addresses within a domain and when IP traffic leaves or enters the internal network the address fields are translated between the public IP addresses and the corresponding private address. A private address is only associated with a public address when the node communicates externally. By using this mechanism it is possible to have many more IP nodes in the private domain then the number of assigned public IP addresses to that domain. NAT is a defacto solution to connect for big groups of users. The combination of NAT and applications exchanging IP addresses in the protocol (like H.323 does) creates problems. The applications are either broken, or gets more difficult to run. There are different solutions for how to be able to run these application in combination with NAT. We list the alternatives in the bottom of this mail. Does anybody on the mailing have an opinion? For instance, a Gatekeeper might have to interact with the NAT (co-located), and possibly act as an application gateway. By the way the question might com up on the DAVIC meeting next week. Best regards, Annika Kilegran ********************************************************************** Telia Research S-136 80 HANINGE, Sweden Tel +46 8 707 55 15 Fax +46 8 707 53 10 Email: annika.w.kilegran(a)telia.se *********************************************************************** The differnt alternatives: ----------------------------- 1) Use an Application layer gateway, that translates addresses in the application protocol. Used today for FTP. Will work, but will be quite complex for H.323. The Application layer gateway would typically be co-located with the NAT-box. 2) Use the location of servers, and the configuration of servers and clients to overcome the problem. DNS is handled this way today. Seems not to work for H.323. 3) A combination of alternatives1 and 2 should be possible, and may acheive a lesser complexity than 1. 4) NAT bypass using tunneling over the local network. The global address is available in the host and is used in the application, removing the problem. This kind of solution have been proposed in contributions to IETF. 5) Skip NAT altogether. Instead use IPv.6, or something like NNAT (No NAT) for IPv.4. NNAT will completely replace NAT, and uses DHCPv.6 for assigning global addresses. NNAT remains to be specified for IPv.4 operation.

2 1

this may be of interest to this group
by Scott Bradner 09 Mar '98

09 Mar '98

If you have comments please send them to me Scott ---

1 0

Re: H.323 and NAT
by Scott Bradner 09 Mar '98

09 Mar '98

Just to let you know - the IETF has just created a new working group to look at NAT issues. If anyone on this list would like to join the mailing list the instructions are in the working group charter ( http://www.ietf.org/html.charters/nat-charter.html ) Following Annika's questions - if you have any worries or suggestions for the IETF WG to keep in mind relative to H.323 please send them to the NAT mailing list thanks Scott

1 0

Re: H.323 and NAT
by Tom-PT Taylor 09 Mar '98

09 Mar '98

How about a protocol that allows applications to discover NAT operating in front of them and obtain external/local address pairs in advance of use? > -----Original Message----- > From: Annika Kilegran [SMTP:Annika.W.Kilegran@TELIA.SE] > Sent: Monday, March 09, 1998 4:06 AM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: H.323 and NAT > > Network Address Translation (NAT) is used as a solution to the > problem of few available IPv4 addresses. The idea is to use private > addresses within a domain and when IP traffic leaves or enters the > internal network the address fields are translated between the public > IP > addresses and the corresponding private address. A private address is > only associated with a public address when the node communicates > externally. By using this mechanism it is possible to have many more > IP > nodes in the private domain then the number of assigned public IP > addresses to that domain. NAT is a defacto solution to connect for big > groups of users. > > > The combination of NAT and applications exchanging IP addresses in the > protocol (like H.323 does) creates problems. > The applications are either broken, or gets more difficult to run. > There are different solutions for how to be able to run these > application in combination with NAT. We list the > alternatives in the bottom of this mail. > > Does anybody on the mailing have an opinion? > For instance, a Gatekeeper might have to interact with the NAT > (co-located), and possibly act as an application gateway. > By the way the question might com up on the DAVIC meeting next week. > > Best regards, > > Annika Kilegran > > ********************************************************************** > Telia Research > S-136 80 HANINGE, Sweden > Tel +46 8 707 55 15 > Fax +46 8 707 53 10 > Email: annika.w.kilegran(a)telia.se > ********************************************************************** > * > > > The differnt alternatives: > ----------------------------- > 1) Use an Application layer gateway, that translates addresses in the > application protocol. Used today for FTP. > Will work, but will be quite complex for H.323. The Application layer > gateway would typically be co-located with the NAT-box. > > 2) Use the location of servers, and the configuration of servers and > clients to overcome the problem. > DNS is handled this way today. Seems not to work for H.323. > > 3) A combination of alternatives1 and 2 should be possible, and may > acheive a lesser complexity than 1. > > 4) NAT bypass using tunneling over the > local network. The global address is > available in the host and is used in the application, removing the > problem. This kind of solution have been > proposed in contributions to IETF. > > 5) Skip NAT altogether. Instead use IPv.6, or something like NNAT (No > NAT) for IPv.4. NNAT will completely replace NAT, and uses DHCPv.6 for > assigning global addresses. NNAT remains to be specified for > IPv.4 operation.

1 0

Re: XRS RequestSeqNum can't be zero
by Jim Toga 06 Mar '98

06 Mar '98

Paul, I'm not positive, (it was in a galaxy far, far away...) I believe the original intent behind not having 0, was so that implementations could recognize a mal-formed or illegal value. The usefulness of this may be debated.... jimt. At 08:48 AM 3/6/98 -0800, you wrote: >>---------- >>From: Ernst Horvath[SMTP:Ernst.Horvath@SIEMENS.AT] >>A clean fix for the problem you discovered would be to allow 0 as a >>special value in RequestSeqNum: >> >> RequestSeqNum ::= INTEGER (0|1..65535) >> -- 0 reserved for XRS if the received message could not be decoded > >This isn't so clean. This would produce a different, non-interoperable >encoding. For example, the value, 8, would produce an ASN.1 PER encoding >of 8 instead of 7. The encoding syntax would stay the same (same number >of bits, etc.), but the semantics would change (values are normalized >differently). An alternative would be INTEGER (1..65535|65536), but even >though normalization is now the same (1-based instead of 0-based), the >new, reserved value, 65536, would cause a semantic decode error in an >ASN.1 decoder still using the old range, 1..65535. I don't see any clean >way to fix it. > >BTW, does anyone know why RequestSeqNum wasn't defined as INTEGER >(0..65535) in the first place? This would have provided a much more >natural wrap-around from 65535 to 0. Not a big deal, though. Just >wondering. > >Paul Long >Smith Micro > > ************************************************************************* *** +1-503-264-8816(voice) +1-503-264-3485(fax) *** *** jtoga(a)ideal.intel.com Intel - Hillsboro, OR. *** *** PGP keyID 36 07 86 49 7D 74 DF 57 50 CB BA 32 08 9C 7C 41*** *************************************************************************

1 0

ad hoc Multipoint Conference - about Gatekeeper routing
by Vincent Chen 06 Mar '98

06 Mar '98

Dear All, Is it a must for the Gatekeeper to route the Call Signalling Channel and H.245 Control Channel in order to support ad hoc Multipoint Conference? If it is a must, what shall the Gatekeeper and MC do? Is it correct that Gatekeeper shall pass (redirect)the transport address of the two endpoints to MC and let MC to start the Capability exchange procedure (TerminalCapabilitySet) with them? So that the previous H.245 channel between the two endpoint can becomes two H.245 between the two endpoint and the MC? GateKeeper / \ One H.245 Control Channel between / \ Endpoint1 and Endpoint2 / \ routed by Gatekeeper Endpoint1 Endpoint2 MC / \ Two H.245 Control Channels between / \ the two endpoint and MC / \ Endpoint1 Endpoint2 Thank you for answering my question! Best Regards, Vincent Chen E-mail: VincentSHChen(a)acer.com.tw

2 1

RAS timeToLive not fixed
by Paul Long 06 Mar '98

06 Mar '98

I noticed that timeToLive is still defined in H.225.0v2 (h2250v2w-final-w6.doc) as INTEGER (1..4294967296). Wasn't the max supposed to have been changed in v2 to 4294967295 before Decision? As it is, this field has the distinction of being the only INTEGER field in all of H.32x-dom that won't fit in a 32-bit variable. :-( I think I'll change our ASN.1 syntax to 4294967295. -- Paul Long___________________________http://www.cmpu.net/public/plong Smith Micro Software, Inc.__________http://www.smithmicro.com/

1 0

Re: XRS RequestSeqNum can't be zero
by Paul Long 06 Mar '98

06 Mar '98

>---------- >From: Ernst Horvath[SMTP:Ernst.Horvath@SIEMENS.AT] >A clean fix for the problem you discovered would be to allow 0 as a >special value in RequestSeqNum: > > RequestSeqNum ::= INTEGER (0|1..65535) > -- 0 reserved for XRS if the received message could not be decoded This isn't so clean. This would produce a different, non-interoperable encoding. For example, the value, 8, would produce an ASN.1 PER encoding of 8 instead of 7. The encoding syntax would stay the same (same number of bits, etc.), but the semantics would change (values are normalized differently). An alternative would be INTEGER (1..65535|65536), but even though normalization is now the same (1-based instead of 0-based), the new, reserved value, 65536, would cause a semantic decode error in an ASN.1 decoder still using the old range, 1..65535. I don't see any clean way to fix it. BTW, does anyone know why RequestSeqNum wasn't defined as INTEGER (0..65535) in the first place? This would have provided a much more natural wrap-around from 65535 to 0. Not a big deal, though. Just wondering. Paul Long Smith Micro

1 0