January 1999 - sg16-avd - lists.packetizer.com

Re: Relationship of H.323 and H.245 versions
by Chris Purvis 22 Jan '99

22 Jan '99

Paul, The problem with this is that with the way certain stacks work an application (such as a gatekeeper) can not necessarily get hold of things that weren't fully decoded ASN.1-wise, and therefore can not relay them onwards. What would happen when, for instance, the Madge gatekeeper (H.323v2), received a message from (say) a v4 endpoint containing "new" mandatory fields, is that it would be able to forward only that part of the message which is understood in the (v2) ASN.1 of which it is aware. To do anything different for future versions may or may not be possible (my understanding of PER encoding isn't quite up to being definitive on this) but if it is possible it would require many stack vendors and people with their own stacks to do some significant rewriting. I think Jim's right, much as it would be nice to be cleverer. Chris > -----Original Message----- > From: Paul Long [mailto:Plong@SMITHMICRO.COM] > Sent: 21 January 1999 10:21 > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: Re: Relationship of H.323 and H.245 versions > > > From: Jim Toga [SMTP:jim.toga@INTEL.COM] > This is getting close. One potential > problem surrounds > intermediaries > (for example GKs in a GK-routed call). We > need to indicate > what exactly is > the expected behaviour of 'M' entities when > they get 'N' type > messages > (that look like 'M' messages with extentions.) > > I would contend that the reality of the > situation is that all > we can > stipulate, is that the 'M' entities don't crash in the > presense of 'N' > messages. We can't mandate that 'M's pass new > (uninterpreted/not-understood) data on. > Obviously if there is > an existing > opaque field defined, this _shall_ be forwarded. > > comments? > > I thought I addressed this in the last sentence, "In > addition, if a >product > is relaying an ASN.1 value, it shall encode the same value > that it >decoded, > regardless of its own version or the version of the value's > sender." This is > for intermediate entities such as gatekeepers that relay, or > route, call > signaling and control messages between entities. My company > is not in the > gatekeeper business, so with my lack of familiarity I could > be off base here, > but I believe this statement is necessary to mitigate the > earlier statement, > "Each product shall _encode_ and decode the H.245 and H.225.0 > ASN.1 syntax > trees defined in their respective version of H.323." The last sentence > sanctions, for example, a v1 gatekeeper relaying v2 messages. > I assume this is > a requirement and that we can indeed mandate it. > > Was I not clear, or did I simply not address your concern? > > Paul Long > Smith Micro Software, Inc. >

1 0

Re: APC Numbers: ITU-T Q.11-15 Meeting
by Sakae OKUBO 22 Jan '99

22 Jan '99

Dear Mr. Roy, > Kindly issue APC numbers for the following three contributions for the > upcoming meeting: The follwoing APC numbers have been allocated to your three contributions: APC-1492 H.323 Differentiated Services and Their Protocol Architectures APC-1493 Viewgraphs presentation for "H.323 Differentiated Services and Their Protocol Architectures" APC-1494 TIA/EIA IS-641 Enhanced Full-Rate Speech Codec for H.323 Best regards, Sakae OKUBO (Mr.) *********************************************************** Waseda Research Center Telecommunications Advancement Organization of Japan (TAO) 5th Floor, Nishi-Waseda Bldg. 1-21-1 Nishi-Waseda, Shinjuku-ku, Tokyo 169-0051 Japan Tel: +81 3 5286 3830 Fax: +81 3 5287 7287 e-mail: okubo(a)giti.or.jp ***********************************************************

1 0

Re: Multiple aliases in ARQ destinationInfo
by Paul Long 21 Jan '99

21 Jan '99

From: Santo Wiryaman [SMTP:swiryaman@VIDEOSERVER.COM] Personally, my preference is for #1. Keep it simple. The reason is that an ACF from a GK does not necessarily mean that the endpoint is registered with the GK. In other words, when a GK receives an ARQ and does not find the alias registered, it has to look somewhere else: other GK's (using LRQ), some GK's lookup in ILS servers, DNS, etc.. When the ARQ has an ordered list of aliases, what should the GK do? What if alias #1 is found in a different zone2, alias #2 is found in zone3, and alias #3 is registered locally in zone1? Which IP address should the GK return in the ACF? Further more, the LRQ process (and other address lookup procedures) are asynchronous. The LCF for alias #2 might come back before the LCF from alias #1. Having the LCF for alias #2, does the GK have to wait around for the LCF of alias #1 (which may never arrive). Simple, return the transport address of the first resolved alias. What's wrong with that? The ordered list of aliases indicates a _preferred_ search order. In practice, I doubt whether users will consciously place aliases in a particular order, so returning the address of any alias will most likely be satisfactory. This could be a quality-of-implementation issue, too. A GK could be configured to delay admission a bit in an attempt to return the address of the earliest-possible alias in the list. In practice, could you tell us an example of a widely deployed communication system where you can "dial" multiple destinations (e.g. home phone, work phone, cell phone, fax number, emailID) at once and "it" will get you the most suitable destination? Hey, it's a brave new world out there. :-) How about a universal mailbox? I think having multiple types of aliases (e164, h323-ID, url-ID, transportID, email-ID, partyNumber(publicNumber, privateNumber,nationalStandardPartyNumber) ) is confusing enough. Placing multiple aliases in an ARQ would further complicate matters. The facility is already in the Recommendation for this. We can't take it out. EP and GK vendors can decide what makes sense to them. If you only want to look at the first alias, go ahead. If I am not mistaken, the original reason for defining destinationInfo in ARQ as a sequence of aliases is to convey two (or more) phonenumbers to use for a single call. For example, to make an H.323 to an H.320 call via an ISDN GW using 2B lines, there can be two aliases: "918005551212" and "918005551213". Therefore, all aliases in the field are used for the same call; it is not a list of alternative aliases in prefered order. I believe you are mistaken. The second alias goes in the ARQ's destExtraCallInfo field: 7.11.1/H.225.0v2: "destExtraCallInfo - contains external addresses for multiple calls." The field of the same name in the Setup message is used for the same thing: 7.3.10/H.225.0v2: "destExtraCallInfo - needed to make possible additional channel calls, i.e. for a 2*64 Kbps call on the WAN side. Shall only contain E.164 addresses and shall not contain the number of the initial channel." As a side note, some H.323 systems (e.g. an MCU, a GK-routed GK) look into the destinationAddress field in the SETUP message to see where to further route the call. Presumably, if there is a list of aliases in the ARQ, there would also be a list of aliases in the SETUP. How should these systems interpret the list of aliases? Is an EP required to use the exact same alias list in the Setup that it used in the ARQ? I don't think so. Sounds like it should use the alias list sent back in the ACF's destinationInfo field, which would presumably contain only the alias(es) that resolved into the provided transport address. Good point, though. Needs more thought. What if more than one alias resolved into the same address and the GK returned all of the resolved aliases? But then, maybe we're trying to over-engineer the problem. Maybe it just makes good sense to the users in these situations to provide a single alias, and everything just works... :-) Paul Long Smith Micro Software, Inc.

1 0

Re: Multiple aliases in ARQ destinationInfo
by Santo Wiryaman 21 Jan '99

21 Jan '99

Hi Paul, Thanks for bringing up this interesting subject. The original reason for having multiple aliases may have been forgotten by many (more on this). Personally, my preference is for #1. Keep it simple. The reason is that an ACF from a GK does not necessarily mean that the endpoint is registered with the GK. In other words, when a GK receives an ARQ and does not find the alias registered, it has to look somewhere else: other GK's (using LRQ), some GK's lookup in ILS servers, DNS, etc.. When the ARQ has an ordered list of aliases, what should the GK do? What if alias #1 is found in a different zone2, alias #2 is found in zone3, and alias #3 is registered locally in zone1? Which IP address should the GK return in the ACF? Further more, the LRQ process (and other address lookup procedures) are asynchronous. The LCF for alias #2 might come back before the LCF from alias #1. Having the LCF for alias #2, does the GK have to wait around for the LCF of alias #1 (which may never arrive). In practice, could you tell us an example of a widely deployed communication system where you can "dial" multiple destinations (e.g. home phone, work phone, cell phone, fax number, emailID) at once and "it" will get you the most suitable destination? I can imagine a smart phonebook/dialer which would take the addresses and "dial" one number at a time until it gets connected. But the smarts is in the application, not in the "switch" (in our case the GK). I think having multiple types of aliases (e164, h323-ID, url-ID, transportID, email-ID, partyNumber(publicNumber, privateNumber,nationalStandardPartyNumber) ) is confusing enough. Placing multiple aliases in an ARQ would further complicate matters. If I am not mistaken, the original reason for defining destinationInfo in ARQ as a sequence of aliases is to convey two (or more) phonenumbers to use for a single call. For example, to make an H.323 to an H.320 call via an ISDN GW using 2B lines, there can be two aliases: "918005551212" and "918005551213". Therefore, all aliases in the field are used for the same call; it is not a list of alternative aliases in prefered order. As a side note, some H.323 systems (e.g. an MCU, a GK-routed GK) look into the destinationAddress field in the SETUP message to see where to further route the call. Presumably, if there is a list of aliases in the ARQ, there would also be a list of aliases in the SETUP. How should these systems interpret the list of aliases? Currently, GW's interpret the multiple aliases as the phone numbers to dial out to the ISDN network (to be more precise, the first number is usually in the CalledPartyNumber and the second in the destExtraCallInfo, but that's a different story). It would be interesting to hear opinions from other implementors. Regards, Santo wiryaman VideoServer Inc. > -----Original Message----- > From: Paul Long [SMTP:Plong@SMITHMICRO.COM] > Sent: Thursday, January 21, 1999 2:39 PM > To: ITU-SG16(a)mailbag.cps.intel.com > Subject: Multiple aliases in ARQ destinationInfo > > Hello, > > At the last interop I noticed that when an endpoint is placing a call, > gatekeepers treated the presence of multiple aliases in the ARQ > destinationInfo field in the following, different ways. > > 1. Always use the first, ignore the rest. > 2. Respond with ARJ if more than one alias. > 3. Respond with ACF only if all aliases are registered to the same > endpoint. > 4. Respond with ACF if at least one alias is registered, starting > with > the first one. > > While the Recommendations are silent on the semantics of multiple aliases, > and > vendors are therefore free to do whatever they want in this regard, I > believe > that the 4th interpretation is what was intended and should be encouraged. > A > "should" clause might be added to a future version of H.225.0. The reason > that > the first two don't make sense is that destinationInfo is after all a > _list_ > of aliases. That implies there is _some_ meaning to multiple aliases-if > only > one alias was intended, the ASN.1 component would have been defined as a > single alias. The 3rd interpretation is questionable because > destinationInfo > is a sequence-of and not a set-of aliases. Consider 3.8.46/X.680: > > "...each value in the sequence-of type is an _ordered_ list of zero, one > or > more values of the component type. [emphasis mine]" > > I take this to mean that not all aliases in destinationInfo are to be > treated > equal, and it is obvious to me that the order indicates search order. To > reinforce the choice of the 4th interpretation, consider 7.11.1/H.225.0v2: > > "destinationInfo - sequence of alias addresses for the destination, such > as > E.164 addresses or H323_IDs. When sending the ARQ to answer a call, > destinationInfo indicates the destination of the call (the answering > endpoint). ... > "srcInfo - sequence of alias addresses for the source endpoint, such as > E.164 > addresses or H323_IDs. When sending the ARQ to answer a call, srcInfo > indicates the originator of the call." > > This means that srcInfo and destinationInfo are swapped when answering a > call, > relative to placing a call, and that they are therefore probably > constructed > similarly. Since srcInfo often has multiple aliases with which the caller > wishes to be associated (one at a time, not as a single aggregate alias as > in > #3, above), it makes sense that destinationInfo also contains multiple > aliases > with which the callee may be associated. > > In practice, let's say I want to call someone who has a couple of E.164 > aliases, an email alias, and an H.323-id alias, not all of which may be > registered at any one time. My phonebook has all four aliases listed for > this > person, possibly in some meaningful order. As a user, the only thing I'm > interested in when I place the call, is that I want the gatekeeper to find > the > person. It makes sense to me for the gatekeeper to search the aliases in > order > until it finds one that is registered and then return a call-signaling > transport address to which I can connect to establish the call. > > I believe that the 4th interpretation is preferred but also that a > gatekeeper > may allow the administrator to configure this aspect in any number of > ways, > including the other three presented above. > > Paul Long > Smith Micro Software, Inc.

2 1

Re: Relationship of H.323 and H.245 versions
by Paul Long 21 Jan '99

21 Jan '99

From: Jim Toga [SMTP:jim.toga@INTEL.COM] This is getting close. One potential problem surrounds intermediaries (for example GKs in a GK-routed call). We need to indicate what exactly is the expected behaviour of 'M' entities when they get 'N' type messages (that look like 'M' messages with extentions.) I would contend that the reality of the situation is that all we can stipulate, is that the 'M' entities don't crash in the presense of 'N' messages. We can't mandate that 'M's pass new (uninterpreted/not-understood) data on. Obviously if there is an existing opaque field defined, this _shall_ be forwarded. comments? I thought I addressed this in the last sentence, "In addition, if a >product is relaying an ASN.1 value, it shall encode the same value that it >decoded, regardless of its own version or the version of the value's sender." This is for intermediate entities such as gatekeepers that relay, or route, call signaling and control messages between entities. My company is not in the gatekeeper business, so with my lack of familiarity I could be off base here, but I believe this statement is necessary to mitigate the earlier statement, "Each product shall _encode_ and decode the H.245 and H.225.0 ASN.1 syntax trees defined in their respective version of H.323." The last sentence sanctions, for example, a v1 gatekeeper relaying v2 messages. I assume this is a requirement and that we can indeed mandate it. Was I not clear, or did I simply not address your concern? Paul Long Smith Micro Software, Inc.

1 0

Multiple aliases in ARQ destinationInfo
by Paul Long 21 Jan '99

21 Jan '99

Hello, At the last interop I noticed that when an endpoint is placing a call, gatekeepers treated the presence of multiple aliases in the ARQ destinationInfo field in the following, different ways. 1. Always use the first, ignore the rest. 2. Respond with ARJ if more than one alias. 3. Respond with ACF only if all aliases are registered to the same endpoint. 4. Respond with ACF if at least one alias is registered, starting with the first one. While the Recommendations are silent on the semantics of multiple aliases, and vendors are therefore free to do whatever they want in this regard, I believe that the 4th interpretation is what was intended and should be encouraged. A "should" clause might be added to a future version of H.225.0. The reason that the first two don't make sense is that destinationInfo is after all a _list_ of aliases. That implies there is _some_ meaning to multiple aliases-if only one alias was intended, the ASN.1 component would have been defined as a single alias. The 3rd interpretation is questionable because destinationInfo is a sequence-of and not a set-of aliases. Consider 3.8.46/X.680: "...each value in the sequence-of type is an _ordered_ list of zero, one or more values of the component type. [emphasis mine]" I take this to mean that not all aliases in destinationInfo are to be treated equal, and it is obvious to me that the order indicates search order. To reinforce the choice of the 4th interpretation, consider 7.11.1/H.225.0v2: "destinationInfo - sequence of alias addresses for the destination, such as E.164 addresses or H323_IDs. When sending the ARQ to answer a call, destinationInfo indicates the destination of the call (the answering endpoint). ... "srcInfo - sequence of alias addresses for the source endpoint, such as E.164 addresses or H323_IDs. When sending the ARQ to answer a call, srcInfo indicates the originator of the call." This means that srcInfo and destinationInfo are swapped when answering a call, relative to placing a call, and that they are therefore probably constructed similarly. Since srcInfo often has multiple aliases with which the caller wishes to be associated (one at a time, not as a single aggregate alias as in #3, above), it makes sense that destinationInfo also contains multiple aliases with which the callee may be associated. In practice, let's say I want to call someone who has a couple of E.164 aliases, an email alias, and an H.323-id alias, not all of which may be registered at any one time. My phonebook has all four aliases listed for this person, possibly in some meaningful order. As a user, the only thing I'm interested in when I place the call, is that I want the gatekeeper to find the person. It makes sense to me for the gatekeeper to search the aliases in order until it finds one that is registered and then return a call-signaling transport address to which I can connect to establish the call. I believe that the 4th interpretation is preferred but also that a gatekeeper may allow the administrator to configure this aspect in any number of ways, including the other three presented above. Paul Long Smith Micro Software, Inc.

2 1

Re: Relationship of H.323 and H.245 versions
by Paul Long 21 Jan '99

21 Jan '99

Dave, Pete, et al., We need to be very clear about how products of different versions can be interoperable. Terms such as "compatible," "backward compatible," and "supports" are too ambiguous to be useful in normative text. Here's my attempt at splitting hairs. The first paragraph is taken straight from Dave's email. Products claiming compliance with Version 2 of H.323 shall comply with all of the mandatory requirements of this document, H.323 (1998), which references H.225.0 (1998) and H.245 (1998). The protocol identifiers used in messages defined in H.225.0 (1998) and H.245 (1998) are specified in those recommendations. Interoperability between products of possibly different versions is assured by the following. Note that what is commonly referred to as a "message" is an ASN.1 component of a choice type of typically the first or second level of an ASN.1 syntax tree. Therefore, in the following paragraph, a "message" that is not a component of the extension root is treated the same as any other choice extension addition. Assume that an H.323vM product and an H.323vN product are in communication with each other, where M and N are version numbers and M <= N. The H.323 version number shall be taken to be the same as the version number indicated in the H.225.0 protocolIdentifier field. Each product shall encode and decode the H.245 and H.225.0 ASN.1 syntax trees defined in their respective version of H.323. The H.323vM product shall behave according to H.323vM and shall assume that the H.323vN product also behaves according to H.323vM, with these two exceptions: * the H.323vN product encodes values for the protocolIdentifier fields for H.323vN, not H.323vM, and * the H.323vN product encodes ASN.1 sequence and choice extension additions defined in H.323vN that may not be defined in H.323vM. Although the H.323vM product shall parse extension additions defined in later versions of H.323 (as prescribed by ASN.1), it shall not recognize or otherwise act upon them. Therefore, the H.323vN product shall not rely on behavior in the H.323vM product that is based on the value or presence of extension additions defined in H.323vN but not H.323vM. This in effect forces the H.323vN product to behave like an H.323vM product. In addition, if a product is relaying an ASN.1 value, it shall encode the same value that it decoded, regardless of its own version or the version of the value's sender. Paul Long Smith Micro Software, Inc.

2 1

Agenda for Monterey meeting
by Matthew Dragiff 21 Jan '99

21 Jan '99

Has an agenda been published yet? Can anyone point me to it? Thanks.

2 1

cc:Mail Link to SMTP Undeliverable Message
by admin0 21 Jan '99

21 Jan '99

Message is undeliverable. Reason: A platform specific error occurred while writing to a file. Likely disk full. Original text follows: --------------------- Received: from senda.ari.es by internet.amperdatos.es (ccMail Link to SMTP R6.01.01) ; Thu, 21 Jan 99 17:48:14 +0100 Return-Path: <ITU-SG16(a)mailbag.cps.intel.com> Received: from chico.rediris.es (chico.rediris.es [130.206.1.3]) by senda.ari.es (8.9.1/8.9.1) with ESMTP id RAA17893; Thu, 21 Jan 1999 17:45:47 +0100 Received: from chico.rediris.es (130.206.1.3) by chico.rediris.es (LSMTP for Solaris v1.1b) with SMTP id <13.00001FDE(a)chico.rediris.es>; Thu, 21 Jan 1999 17:45:29 +0100 Received: from MAILBAG.INTEL.COM by MAILBAG.INTEL.COM (LISTSERV-TCP/IP release 1.8c) with spool id 44754 for ITU-SG16(a)MAILBAG.INTEL.COM; Thu, 21 Jan 1999 08:47:17 -0800 Received: from pluto.nko.com (faxjetsmtp.faxjet.com [206.125.250.242] (may be forged)) by mailbag.cps.intel.com (8.8.6/8.8.5) with ESMTP id IAA02479 for <itu-sg16(a)mailbag.intel.com>; Thu, 21 Jan 1999 08:37:15 -0800 (PST) Received: from apollo.nko.com ([206.125.248.124]) by pluto.nko.com (Post.Office MTA v3.5 release 215 ID# 0-54139U100L2S100V35) with SMTP id com for <itu-sg16(a)mailbag.intel.com>; Thu, 21 Jan 1999 11:41:28 -0500 Received: by apollo.nko.com(Lotus SMTP MTA Internal build v4.6.2 (651.2 6-10-1998)) id 85256700.005C21B7 ; Thu, 21 Jan 1999 11:46:19 -0500 X-Lotus-FromDomain: FAXJET Mime-Version: 1.0 Content-type: text/plain; charset=us-ascii Content-Disposition: inline Message-ID: <85256700.005C21A5.00(a)apollo.nko.com> Date: Thu, 21 Jan 1999 11:37:29 -0500 Reply-To: Mailing list for parties associated with ITU-T Study Group 16 <ITU-SG16(a)mailbag.cps.intel.com> Sender: Mailing list for parties associated with ITU-T Study Group 16 <ITU-SG16(a)mailbag.cps.intel.com> From: Matthew Dragiff <mdragiff(a)NKO.COM> Subject: Agenda for Monterey meeting To: ITU-SG16(a)mailbag.cps.intel.com Has an agenda been published yet? Can anyone point me to it? Thanks.

1 0

Re: Relationship of H.323 and H.245 versions
by Pete Cordell 20 Jan '99

20 Jan '99

Dave, Comments interleaved... > >Pete, > >I understand what you're trying to do, but I'm a little concerned >about allowing a v2 entity to support any version of H.245, >including unspecified future versions which may or may not be >compatible with what we have now. As an ITU requirement any future H.245 version must be backward compatible with an earlier one so this shouldn't (in theory) be an issue. > >So let me propose the following paragraph as replacement text for >the offending portion of the H.323 Version 2 Summary section (which >begins in the same way). One reason for suggesting new text is that I wanted a fairly definitive statement on this issue and the summary doesn't seem the right place for such normative text (i.e. it's a summary and everything it says should be in the main body of the document and so doesn't have any normative value by itself). However, if the text you describe were copied to a normative part of the document, subject to changing 'other versions' to 'more recent versions' (as I have attempted to indicate below) I would be happy. (Also I would like to add a note that the version of H.245 that they end up connected to may change as a call evolves, as it seems churlish not to mention a particular gotcha if we know about it. I've attempt to add text for this below.) > >"Products claiming compliance with Version 2 of H.323 shall comply >with all of the mandatory requirements of this document, H.323 (1998), >which references H.225.0 (1998) and H.245 (1998). The protocol >identifiers used in messages defined in H.225.0 (1998) and H.245 >(1998) are specified in those recommendations. An H.323 Version 2 >compliant product may also be compliant with (other)->(more recent) versions >of these >recommendations, but should not send messages or invoke procedures >defined in a newer version of a recommendation than a peer has identified itself as supporting. () ->(Implementations must also be aware that, due to the procedures for 'Third party initiated pause and re-routing,' they may be connected to different versions of H.245 at >different times during the life of a call.)" > >Regards, > >Dave Walker >Mitel Corporation >Ontario, CANADA Regards, Pete ================================= Pete Cordell BT Labs E-Mail: pete.cordell(a)bt-sys.bt.co.uk Tel: +44 1473 646436 Fax: +44 1473 645499 =================================

2 1