Chris,
In ASN.1-speak, being able to pass an ASN.1 value, typically transparently, is
called "relaying" [1]. Luckily, the PER encoding used by both H.245 and
H.225.0 are relay-safe [2]. An H.323 entity is therefore technically able [3]
to route a message originally encoded using an abstract syntax other than the
one it uses itself.
Frankly, I don't see how it could be otherwise. Are you saying, for example,
that a v4 EP and a v5 EP routed via a v2 GK are both relegated to using v2?
Will the …
[View More]GK modify all protocol identifiers to indicate this reduction, or
will the EPs continue to think they can use v4 signaling? It's a real shame if
the GK becomes the weakest link when there is no normative reason for this.
Our stack can support relaying, but then I wrote it myself... :-) Maybe you
should have a talk with your stack vendor.
[1] 3.8.23/X.691(1994): "relay-safe encoding: A complete encoding of an
abstract syntax value which can be decoded (including any embedded encodings)
without knowledge of the presentation layer defined context set that formed
the environment in which the encoding was performed."
[2] 7.3/X.691(1994): "PER encodings are always relay-safe provided the
abstract values of the types EXTERNAL, EMBEDDED PDV and CHARACTER STRING are
constrained to prevent the carriage of presentation context identifiers."
[3] C.2(Non-normative)/X.691(1994): "Where an abstract syntax value contains
embedded material that is encoded using a transfer or abstract syntax
different from that associated with the abstract syntax value, it is strongly
recommended that the embedded material be encoded in a relay-safe manner."
Paul Long
Smith Micro Software, Inc.
-----Original Message-----
From: Chris Purvis [SMTP:CPurvis@MADGE.COM]
Sent: Friday, January 22, 1999 1:55 AM
To: ITU-SG16(a)MAILBAG.INTEL.COM
Subject: Re: Relationship of H.323 and H.245 versions
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.
>
[View Less]
-----Original Message-----
From: Santo Wiryaman [SMTP:swiryaman@VIDEOSERVER.COM]
Sent: Friday, January 22, 1999 7:51 AM
To: ITU-SG16(a)mailbag.cps.intel.com
Subject: Re: Multiple aliases in ARQ destinationInfo
I truly wanted to know if Paul knows of any system out there
where
you can "blast" dial with multiple numbers and hope to get
connected to one
of them.
No, I …
[View More]don't know of any.
I share Chris' concern about such a "blast" dial system which
is
non-determinism.
My primary interest is in raising awareness of this issue among GK vendors. As
primarily an EP vendor, we don't want our users to experience the kind of
variance in behavior that I experienced at the last interop. My secondary
interest is in having a normative or at least consensus-based agreement about
what is the right thing to do in light of the ambiguity in the
Recommendations. Lastly, I believe that interpretation 4 or possibly Chris'
improvement makes the most sense.
Paul Long
Smith Micro Software, Inc.
[View Less]
Time for me to wade in on a couple of points here too, I'm afraid...
First let me say what we've implemented so far:
4. Respond with ACF if at least one alias is registered, starting with
the first one.
Having said that, I'm not certain that's how things should be. I believe
the "right" answer is none of those Paul suggests. My starting point,
though, is that at this stage of placing a call, line-hunting is the job of
the gatekeeper, not the endpoint. If one wants to do line-hunting …
[View More]at the
endpoint, one should be sending a number of ARQs - note that there's no
reason an endpoint can't have multiple ARQs outstanding at the same time, so
this should not add significantly to call setup latency.
Hence what I believe SHOULD happen is that the gatekeeper
1. If it can match anything within its zone, should ensure that different
aliases in the ARQ do not point to different destinations within the zone.
If there is such disagreement, the GK should return ARJ.
Either:
2a. Repeat the same policy at any other levels of search that it engages in
(LRQs etc).
or (probably "better" from the point of view of call setup times, although
less deterministic):
2b. If a search procedure needs to be done outside of the zone, use the
first positive reply you get
One use I see for these multiple aliases, is to avoid the abomination of
dial-prefixes for dialing out through gateways. The first alias should
point to a gateway (probably by name rather than number), subsequent aliases
in a setup message should tell the gateway what to do. Clever gatekeepers
may want to have policy on what outside lines are permitted to certain
users, and therefore need to see this information at this stage.
Unfortunately nobody seems to use multiple aliases like this...
In answer to a couple of other specific points:
[Santo]
>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).
Are you suggesting that if such a thing hasn't been done before it is not a
"good" thing to do?
Incidentally the start of such a thing does exist, at least in the UK. I
have friends for whom I can dial a single number. They tell the server for
this number where they are at any given time, and when I dial their
"personal numebr" I talk to the person, whether they happen to be at home
(on their home number), at work (on their work number) or elsewhere (on
their mobile phone). We have a huge opportunity to improve users'
experience.
[Paul]
>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... :-)
The ACF's destinationInfo field only appears in version 2, but yes this is
certainly what you should use where present (if it's absent, you can't do
anything other than use what you used in the setup message). Do any
endpoints complain when they see extra, superfluous aliases in setup
messages addressed to them? I doubt it. Even gateways should surely use
what they can make sense of and ignore anything else. The question mark is
how the destinationInfo, destExtraCallInfo and remoteExtensionAddress fields
in ACF should be mapped to the various fields in the setup message
(CalledPartyNumber, CalledPartySubAddress, destinationAddress,
DestExtraCallInfo, remoteExtensionAddress). I seem to remember hearing at
some point that they should be mapped into the fields of the same name,
except that the first destinationInfo that is a phone number is moved into
CalledPartyNumber, and CalledPartySubAddress. I believe if implemented this
is a potential source of incompatibility with TIPHON however, because (again
from memory - no doubt I'll be corrected if I'm wrong!) TIPHON equipment is
instructed to ignore CalledPartyNumber. Whatever "correct" procedure is,
though, it should be agreed and documented.
[Paul]
>Simple, return the transport address of the first resolved alias. What's
wrong
>with that?
Possible non-determinism (see 2b above).
Regards,
Chris
--
Dr Chris Purvis - Senior Development Engineer, WAVE CC Software
Madge Networks Ltd, Wexham Springs, Framewood Road, Wexham, Berks. ENGLAND
Phone: +44 1753 661 359 email: cpurvis(a)madge.com
[View Less]
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 …
[View More]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.
>
[View Less]
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.)
*********************************…
[View More]**************************
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
***********************************************************
[View Less]
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 …
[View More]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.
[View Less]
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..
…
[View More]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.
[View Less]
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 '…
[View More]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.
[View Less]
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 …
[View More]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.
[View Less]
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.…
[View More]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.
[View Less]
