G'Day John,

Thanks for the comments. Please see my resonses below [CHG].

Cheers, Christian

John Segers wrote:

Christian,

Having read your draft implementors' guide, I have a couple of comments.

1. In section 8.6 of the IG, you say that existing descriptors are

retained with the Move command. I agree with the intent, but find the phrasing awkward. Strictly speaking, descriptors are defined as groups of parameters to commands. So I think it would be better to say something like

"The Move command does not affect the properties of the Termination on which it operates, except those properties explicitly modified by descriptors included in the Move command."

[CHG] OK. This wording is more specific.

2. Section 8.7 proposes a correction to E.6.4. If I'm not mistaken, it

is actually a correction to E.6.2, and you should add "..."-dots between "Section E.6.2 Events" and "DigitMap Completion Event". In that correction there is an undefined reference that should be replaced by a reference to 7.1.14.

[CHG] Your not mistaken. I was. I'll update accordingly.

3. Section 8.10 proposes that event and signal parameters starting with

"SPA" and "EPA" be forbidden. I have to think whether this is the best resolution to the problem of ambiguity, but until I have done so, I want to point out a mistake in the proposed addition to 13.1. This addition implies that package names must not start with "SPA" or "EPA". However, the ambiguity is not related to package names but to parameters of signals and events. Instead of your proposed change to 13.1, I propose that additional text be added to 12.2:

[Begin Correction] 12.1 Guidelines to defining Properties, Statistics and Parameters to Events and Signals

Parameter Name: only descriptive ParameterID: Is an identifier. The textual ParameterID of parameters to Events and Signals shall not start with "EPA" and "SPA", respectively. [End Correction]

[CHG] Sounds reasonable. I really just added this text to get a reaction from people.

4. Section 9.3 proposes clarifying text for the use of wildcarded

responses in audits. The final example shows that the reply to

Context=*{W-Audit=t1/*{Audit{Packages}}

is

Context=*{W-Audit=t1/*{Packages{aaa,bbb,ccc,ddd}}

although Terminations t1/1 and t1/2 only implement packages aaa and bbb. So the ",ccc,ccc" part has to be removed from the response, or example has to be changed to something like

Context=*{W-Audit=*/*{Audit{Packages}}

returns

Context=*{W-Audit=*/*{Packages{aaa,bbb,ccc,ddd}}

Cheers,

[CHG] Correct. This slipped in when I added t1/.

John

Christian Groves wrote:

...

G'Day all,

Attached is a copy of the H.248 Implementors' Guide v3. It "hopefully" contains the corrections and clarifications that have been discussed on the Megaco mailing list until the 19/10/2000.

If anything is missed or erroneous please let me (and the list) know.

The file will also be upload to the pictel server: ftp://standard.pictel.com/avc-site/incoming/H248_Implementors_Guide_v3.zip Both PDF and Word versions are available.

My intention is to make one more update (v4) before sending to the Nov Sg16 meeting for approval.

Cheers, Christian

PS: Please forgive me sending a 98k file to the list but the Pictel server has been down.

---

                                 Name: H248_Implementors_Guide_v3.zip

H248_Implementors_Guide_v3.zip Type: Winzip32 File (application/x-zip-compressed) Encoding: base64

-- John Segers email: jsegers@lucent.com Lucent Technologies Room HE 303 Dept. Forward Looking Work phone: +31 35 687 4724 P.O. Box 18, 1270 AA Huizen fax: +31 35 687 5954

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

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