Errors / ambiguities / problems found in specs at last week's interop

[Johan Gerhardsson (ETX)]

Hi folks,

To clarify things:

It seems that my writing was a bit sloppy when I wrote the problems about TTL and SEQUENCE OF... on the interop. I intended to describe two different problems:

1) GK cannot increase TTL in RCF.
2) Mandatory parameters of type SEQUENCE OF ... can have empty list.

1)
h323v2, 7.2.2:
"The Gatekeeper may respond with an RCF containing the same timeToLive or a shorter timeToLive.".
As I see it, according to this, a GK is not allowed to increase the timeToLive value proposed by the endpoint in RRQ, regardless if the endpoint makes a full registration or a keep-alive registration.

I think it should be possible for the gk to do it.


Sorry about the late answer and confusion.


Best regards
/Johan

Johan Gerhardsson
Software developer
Ericsson Telecom AB
Data networks, IP telephony

Phone:  +46 (0)8 719 2396
ECN:    850 92396
email: Johan.Gerhardsson at etx.ericsson.se



-----Original Message-----
From: Paul E. Jones [mailto:paul.jones at TIES.ITU.INT]
Sent: den 2 mars 2000 08:01
To: ITU-SG16 at mailbag.cps.intel.com
Subject: Re: Errors / ambiguities / problems found in specs at last
week's interop


Reinhard,

Thanks for raising these issues.  I'll throw out a few responses and let
folks debate a little.  If the points are confusing, I'll bring the issues
to the next meeting for inclusion in the Implementers Guide.

> - Terminal capabilities for G.729 and G.729 Annex A. Though mutually
> compatible, TCS often fails if vendors only specify support for one or
> the other. E.g. 729 <--> 729a should work but TCS fails.

Folks have responded to this issue:  it definitely needs correction.

> - H323: GK cannot increase TTL in RCF. Mandatory parameters of type
> SEQUENCE OF ... can have empty list.

It is definitely true that the GK may not return a higher TTL value.  As for
the rest of that sentence, are you referring to a different problem or
something related to TTL?

> - H.225 says that call reference value should be same in ARQ and SETUP.
> H.323 says that call reference value should be different in ARQ and SETUP.

Can you give me the reference in H.323.  The CRV in the ARQ and the SETUP
message are supposed to be the same.  If H.323 says something to the
contrary, it is wrong. You may be referring to this sentence in 7.4:
``There is one CRV for the Call Signalling Channel and an independent CRV
for the RAS channel.''

That sentence does not mean that the values are different, it's just that
they are logically independent.  On the calling side, the CRVs are the same
value (as specified in H.225.0).  On the called side, the CRVs on the Call
Signaling Channel and the RAS channel are indeed different values.

7.4 of H.323 also say to "refer to Recommendation H.225.0", as it is the
protocol that specifies the assignment of those CRVs.

> - In H.323, the destination address in UUIE in SETUP is mandatory, in
> H.225.0 it is not.

If that information is available, it is supposed to be provided according to
H.225.0.  Can you refer me to the specific clauses that are controdictory?

> - H.245: if a capability being sent includes G.711 "20 msec", the other
> side may think that the sender supports both "20 msec" and "10 msec"
> rates. But it can be that the originator supports only 20 msec. Ambiguity.

Perhaps I don't understand the issue here.  What is conveyed in H.245, I
believe, is the maximum number of audio frames per RTP packet.  So, if one
endpoint says it can support 2 frames and other states that it can support 4
frames, the common modes would be 1 or 2 frames per packet.  Is that not
correct?

> - MCU should probably also have "prefix", not just the gateway.

That might be desireable.  H.323v4, however, has added some new fields that
will probably make this a non-issue.

> - Need BE message formats so that packet dumps can be quickly interpreted.

I'm not sure I understand the question here.  BE?  Are you referring to an
Annex G Border Element or something else?  (It's now approaching 2AM my
time, so I may not be thinking as clearly as I should :-)


> - When using a GK, should the CRV in the admission and setup be the same?

Yes.  However, they called party will select a unique CRV when it
communicates with its GK to accept the call.

Best Regards,
Paul