H.323 v1 problem

Paul E. Jones paulej at PACKETIZER.COM
Fri Apr 13 02:15:43 EDT 2001


I should preface my reply with a personal comment: people should seriously
consider discontinuing support for H.323v1 devices within a few years-- the
sooner the better, in my opinion.  H.323v1 devices seem to be rare these
days (from what I have seen) and they do introduce a number of issues that
complicate the development of newer H.323 entities.  While I am generally
not in favor of deprecating (and, arguably, one cannot deprecate) a
standard, we as implementers would be much better off :-)

The destination address is not so important, but the source address is.  The
scenario you describe is, indeed, a problem and it is the reason why the
sourceCallSignalAddress field was added.

The Gatekeeper can populate that address with a unique port number for every
call that it places outbound.  It can then use that information coming in
via the ARQ to match the outbound call with the incoming ARQ.


----- Original Message -----
From: "Nehru, Archana" <archie at TRILLIUM.COM>
To: <ITU-SG16 at mailbag.cps.INTEL.COM>
Sent: Thursday, April 12, 2001 8:34 PM
Subject: H.323 v1 problem

> hi all,
> I have a doubt about ARQ message in H.323 -V1.  The H.323 specs for V1 say
> that "srcCallSignalAddress" and "destCallSignalAddress" are optional. But
> there were some mails exchanged somtime back on the mailing list which
> that these two fields are MANDATORY for v1, since without these fields it
> not possible to identify a call in H.323 V1.
> E.g:
> Let us say we have an endpoint EP1, and EP2 and a GK and a call is
> Gk-routed.
> When EP1 wants to make a connection to EP2, it finishes RAS with GK and
> sends a SETUP to GK. When EP2 receives the incoming SETUP from the GK, it
> send an ARQ to the GK. At this point the Gk needs to identify the "call "
> associated with the incoming ARQ. As there was no "callId" in V1, the only
> parameters that can give the GK a clue are the "srcCallSignalAddress" and
> "destCallSignalAddress" tuple. But if these are treated optional, then
> parameters can the GK use to find the "associated call"?
> I believe for this reason it was suggested that  "srcCallSignalAddress"
> "destCallSignalAddress" would always be present in ARQ from a V1. Can
> someone please confirm this?.
> Many thanks,
> -Archana
> Archana Nehru,
> Engineering Project Manager,
> Trillium Digital Systems Inc., an Intel Company.
> http://www.trillium.com
> Ph:310-481-5525
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> For help on this mail list, send "HELP ITU-SG16" in a message to
> listserv at mailbag.intel.com

For help on this mail list, send "HELP ITU-SG16" in a message to
listserv at mailbag.intel.com

More information about the sg16-avd mailing list