Subject: Comments on MEGACO protocol

From: "Drage, Keith" <[email-masked]>
Date: Tue, 7 Mar 2000 16:29:28 +0000

Attached please find a number of editorial comments on the Geneva output
document, which we also understand is identical to the MEGACO last call
document. These points are not intended to be controversial. In the event
that discussion is required to resolve such a comment, then we will withdraw
the comment in order to allow the document to proceed.

1)      Abbreviations. "BRI" is never used and therefore should be removed
from the list of abbreviations.

2)      References. Q.724 is never used and should be removed.

3)      References and annex C. Where a reference is only used in annex C,
we believe in general in most cases these should be undated (i.e. the latest
version of the referenced document applies). This in particular applies to
Q.931, Q. 2931, Q.763 where ITU-T SG11 have no intention of changing
codepoints to different values, but do reserve the right to add new values.
Surely the whole ethos of annex C is that new values do get automatically
incorporated.

4)      References (and annex C if comment 3 not accepted). Some of the
dates are incorrect. Q.761-4 have a date of December 1999 as that was
decided last year. Q.2931 should reflect the date of the latest amendment
(4) which we believe is also December 1999.

5)      Annex A. We could not find the module header, or an exports
statement, for the ASN.1. The module header is mandatory parts of the ASN.1,
and gives that module an object identifier, which is needed for inport to
anything else.

6)      Annex C, C.8, generic identifier transport. We are not sure how you
fit this into four octets. Is there some subset of the generic identifier
transport information element that is being used? Various codings of this
information element get very, very long.

7)      Annex C, C.9, ITC has a reference to a note 2, which is not in the
table. Is this a spurious inport from the referenced standard? If so, we
believe it can be deleted.

8)      Annex C, C.9. References to Q.931 need to identify that the
references are to the encoding in the Bearer capability information element,
and not to the Low layer information element. The latter has identical
fields with the same code values, but has a more extensive range of values
assigned. This is because some values (particularly at layer 3) are only
defined for end user to addressed end user usage. I believe in H.248 only
the more restricted list in the Bearer capability information element would
be valid.

Keith Drage

> ---------------------------------------------------------------
> Keith Drage ([email-masked])
> Siemens Communications Limited,
> Technology Drive, Beeston, Nottingham NG9 1LA, UK
> Tel: +44 115 943 4991   Fax: +44 115 943 4992
> ---------------------------------------------------------------
> Internet communications are not secure and therefore Siemens
> Communications Limited does not accept legal responsibility for the
> contents of this message. Any views or opinions presented are solely those
> of the author and do not necessarily represent those of Siemens
> Communications Limited unless otherwise specifically stated.
>
>

---

From: John Segers <[email-masked]>
Date: Mon, 13 Mar 2000 08:44:17 +0100

Keith,

Most of the changes you request are ok.  There's a couple that I don't
know about:
- (Re. 3) I thought that references to ITU Rec. have to be specific
(i.e., including a date).  I asked Glen, and he's not sure either.
We'll check.
- (Re. 5) What headers are missing according to you?  The current ASN.1
starts with "MEDIA-GATEWAY-CONTROL DEFINITIONS AUTOMATIC TAGS::=".  I
checked the syntax with the OSS tools and didn't find a problem.
- (Re. 6) I believe this was brought in through MSF and I never
checked.  Having looked up Q.2941.1 now, I agree that 4 octets is
restrictive.

John

--
John Segers                                  email: [email-masked]
Lucent Technologies                                        Room HE 306
Dept. Forward Looking Work                      phone: +31 35 687 4724
P.O. Box 18, 1270 AA  Huizen                      fax: +31 35 687 5954

---

From: Christian Groves <[email-masked]>
Date: Wed, 15 Mar 2000 04:58:31 +0100

G'Day Keith and John,

Regarding 6 the intention was to use this as a binding reference
(BNCid). Annex C should refer to octet 5 and above. For the BNCid the
length as per the GIT would be 6 octets. Make sense?

Cheers, Christian

---

From: John Segers <[email-masked]>
Date: Wed, 15 Mar 2000 16:10:49 +0100

Christian,

I believe it makes sense when it is used for binding reference.  If we
only use octet 5 and above, and only use the GIT parameter for this
specific case, we should rethink the name of the parameter.  Using GIT
with a reference to Q.2941.1 will undoubtedly lead to confusion.

John

---

From: Christian Groves <[email-masked]>
Date: Thu, 16 Mar 2000 09:58:59 +1000

G'Day John,

The property name is BIR.

Perhaps the following change might work?

BNCid   8000    6 OCTETS        GIT (Generic Identifier Transport)
                                BNCid (Octet 5a and above)
                                Ref.: Recommendation Q.2941.1 (09/97)

Cheers, Christian