Once or twice is a mistake. When the mistake is continually repeated I
wonder...
Cisco is NOT an author of MGCP. Referring to MGCP as
"Telcordia/Cisco MGCP" denigrates the hard work of the many people that
actually did author the draft as well as the many people and companies that
contributed.
Maybe it isn't convenient to call it Telcordia/Level 3/RSL COM/Vertical/ MGCP?
Chip
At 06:44 PM 6/16/99 -0400, Nancy-M Greene wrote:
...snip...
>mechanism. We need to choose one. There are two …
[View More]proposals on the table:
>1) the UDP + timers method in the Telcordia/Cisco MGCP -
>draft-huitema-megaco-mgcp-v0r1-05.txt, and
...snip...
--------------------------------------------------
Chip Sharp voice: +1 (919) 851-2085
Cisco Systems Consulting Eng. - Telco
Reality - Love it or Leave it.
--------------------------------------------------
[View Less]
I'd support this as well: some additional text regarding backward
compatibility (use of GIT instead of B-HLI) is required. Along the
lines of what was done for H.310 which went throught the same
change.
François Audet
> Hi everyone,
>
> One of the proposals we are planning to bring to the Berlin
> meeting is for
> modifications to Annex C. If the additional text is approved
> in Berlin will it
> be possible to add it to H.323 V3? This is quite important
> text since …
[View More]it deals
> with backward compatibility of Annex C in H.323 V3 and H.323 V2.
>
> Regards,
> Kaynam Hedayat
[View Less]
Hi everyone,
One of the proposals we are planning to bring to the Berlin meeting is for
modifications to Annex C. If the additional text is approved in Berlin will it
be possible to add it to H.323 V3? This is quite important text since it deals
with backward compatibility of Annex C in H.323 V3 and H.323 V2.
Regards,
Kaynam Hedayat
"Paul E. Jones" <paul.jones(a)TIES.ITU.INT> on 06/28/99 08:20:51 PM
Please respond to Mailing list for parties associated with ITU-T Study Group 16
…
[View More] <ITU-SG16(a)mailbag.cps.intel.com>
To: ITU-SG16(a)mailbag.cps.intel.com
cc: (bcc: Kaynam Hedayat/PicTel)
Subject: H.323v3 for decision in September
Folks,
We may attempt to decide H.323v3 in September and determine version 4 in
February. Mr. Skran has asked that I post the current draft so that people
can review the document. This document must be delivered to the ITU by 30
June 1999. (Please note that Annex C/H.323 is also a candidate for decision
in Septemer.)
This document contains only minor editorial changes to the document that was
determined in Santiago. Nonetheless, I encourage you to review the document
for any errors or omissions.
The change marks indicate all changes that have been made since version 2.
Please direct any comments on the document to me.
The document can be found here:
ftp://standards.pictel.com/avc-site/Incoming/H.323v3-990628.doc
Best Regards,
Paul E. Jones
DataBeam Corporation
[View Less]
One issue I was discussing with my BT colleagues was installing an open
framework for extensibility and feature negotiation into H.323v3. The
motivation for this was to enable transport of SS7, but also other protocols
such as DPNSS, (is CAS a digital one?) and so on. If we were to go ahead I
guess we would have presented something in Berlin.
Given that September is fast approaching waiting for such a scheme to
transport things like SS7 does not seem too onerous.
Unfortunately my colleagues …
[View More]are out this week, but I will attach the latest
text so that people can have early sight of it.
Regards,
Pete
=============================================
Pete Cordell
pete(a)tech-know-ware.com
=============================================
-----Original Message-----
From: Paul E. Jones <paul.jones(a)TIES.ITU.INT>
To: ITU-SG16(a)MAILBAG.INTEL.COM <ITU-SG16(a)MAILBAG.INTEL.COM>
Date: 29 June 1999 01:25
Subject: H.323v3 for decision in September
>Folks,
>
>We may attempt to decide H.323v3 in September and determine version 4 in
>February. Mr. Skran has asked that I post the current draft so that people
>can review the document. This document must be delivered to the ITU by 30
>June 1999. (Please note that Annex C/H.323 is also a candidate for
decision
>in Septemer.)
>
>This document contains only minor editorial changes to the document that
was
>determined in Santiago. Nonetheless, I encourage you to review the
document
>for any errors or omissions.
>
>The change marks indicate all changes that have been made since version 2.
>
>Please direct any comments on the document to me.
>
>The document can be found here:
>
>ftp://standards.pictel.com/avc-site/Incoming/H.323v3-990628.doc
>
>Best Regards,
>Paul E. Jones
>DataBeam Corporation
>
[View Less]
Roni,
The reason for the addition of this text to H.323v3 was the death of what
was formerly known as H.450.8 (SS-CoC, Conference out of Consultation),
which I will refer to hereafter as H.450.CoC for convenience. H.450.CoC
described an alternative method for setting up conferences out of
consultation which, if decided, would have left us with alternative,
incompatible methods of achieving the same feature. I wrote documents on
the subject for the Monterey meeting (one APC, one TD, if I …
[View More]remember
rightly), and a revised version for Santiago, explaining how the behaviour
required by H.450.CoC could be achieved without it. It was felt that
setting out the procedure in a standard was a useful thing to do, but that
H.450.CoC was unnecessarily heavyweight. The natural conclusion of that was
to write up the procedures allowed by earlier versions of the standard
explicitly in H.323v3.
Hence:
1. It IS a minor change, because it doesn't actually change anything (beyond
the addition of a single releaseCompleteReason) - it merely sets out how
protocol already in existence can be used to achieve a particular aim.
2. Although the text was not agreed in Monterey as part of H.323v3, its
basis was discussed at other points in the Monterey meeting as well as at
Santiago.
3. It must have some use in the standard, to clear up misconceptions. The
writers of H.450.CoC (who are extremely familiar with the H.323 family of
standards) obviously felt H.450.CoC was necessary (or they wouldn't have put
in the significant effort of writing it!) - whereas you're saying that the
text being added was already part of the protocol (with which I agree).
I find it hard to see your argument as self-consistent incidentally - if, as
you say, the added text is "just a procedure that is already part of the
previous text" (with which I agree), then surely as such it constitutes a
minor change!?
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
> -----Original Message-----
> From: Roni Even [mailto:Roni_e@ACCORD.CO.IL]
> Sent: 29 June 1999 8:24
> To: ITU-SG16(a)MAILBAG.INTEL.COM
> Subject: Re: H.323v3 for decision in September
>
>
> Hi,
> As far as I see in the Santiago meeting summary the decision was to
> decide H.323V3 in 2/00. Where will we decide on 9.99 I did not see any
> meeting scheduled. A lot of text was added during the Santiago meeting
> about Conference out of Consultation which I see as just a procedure
> that already is part of the previous text and I cannot see why it was
> added at the first place. I intend to submit an APC about this for the
> Berlin meeting. I think that adding two pages of text to the document
> that was agreed in Monterey is not a minor change.
>
> **********************************************
> Roni Even
> VP Product Marketing
> Accord Video Telecommunication
> Email: roni_e(a)accord.co.il
> Tel: +972-3-9251412
> Fax: +972-3-9211571
> ***************************************************
>
> > -----Original Message-----
> > From: Paul E. Jones [SMTP:paul.jones@TIES.ITU.INT]
> > Sent: Tuesday, June 29, 1999 2:21 AM
> > To: ITU-SG16(a)MAILBAG.INTEL.COM
> > Subject: H.323v3 for decision in September
> >
> > Folks,
> >
> > We may attempt to decide H.323v3 in September and determine
> version 4
> > in
> > February. Mr. Skran has asked that I post the current draft so that
> > people
> > can review the document. This document must be delivered to the ITU
> > by 30
> > June 1999. (Please note that Annex C/H.323 is also a candidate for
> > decision
> > in Septemer.)
> >
> > This document contains only minor editorial changes to the document
> > that was
> > determined in Santiago. Nonetheless, I encourage you to review the
> > document
> > for any errors or omissions.
> >
> > The change marks indicate all changes that have been made since
> > version 2.
> >
> > Please direct any comments on the document to me.
> >
> > The document can be found here:
> >
> > ftp://standards.pictel.com/avc-site/Incoming/H.323v3-990628.doc
> >
> > Best Regards,
> > Paul E. Jones
> > DataBeam Corporation
>
[View Less]
Hi,
As far as I see in the Santiago meeting summary the decision was to
decide H.323V3 in 2/00. Where will we decide on 9.99 I did not see any
meeting scheduled. A lot of text was added during the Santiago meeting
about Conference out of Consultation which I see as just a procedure
that already is part of the previous text and I cannot see why it was
added at the first place. I intend to submit an APC about this for the
Berlin meeting. I think that adding two pages of text to the document
that …
[View More]was agreed in Monterey is not a minor change.
**********************************************
Roni Even
VP Product Marketing
Accord Video Telecommunication
Email: roni_e(a)accord.co.il
Tel: +972-3-9251412
Fax: +972-3-9211571
***************************************************
> -----Original Message-----
> From: Paul E. Jones [SMTP:paul.jones@TIES.ITU.INT]
> Sent: Tuesday, June 29, 1999 2:21 AM
> To: ITU-SG16(a)MAILBAG.INTEL.COM
> Subject: H.323v3 for decision in September
>
> Folks,
>
> We may attempt to decide H.323v3 in September and determine version 4
> in
> February. Mr. Skran has asked that I post the current draft so that
> people
> can review the document. This document must be delivered to the ITU
> by 30
> June 1999. (Please note that Annex C/H.323 is also a candidate for
> decision
> in Septemer.)
>
> This document contains only minor editorial changes to the document
> that was
> determined in Santiago. Nonetheless, I encourage you to review the
> document
> for any errors or omissions.
>
> The change marks indicate all changes that have been made since
> version 2.
>
> Please direct any comments on the document to me.
>
> The document can be found here:
>
> ftp://standards.pictel.com/avc-site/Incoming/H.323v3-990628.doc
>
> Best Regards,
> Paul E. Jones
> DataBeam Corporation
[View Less]
Hi,
We have some queries related to Fax support at Gateway using H.323 Annex-D and
T.38.
- How the originating gateway (after detecting CNG) tells/informs the
destination
Gateway, that the call is a fax call [assuming two gateways are communicating
using H.323]
- How do we open logical channels for fax communication (T.38)
- Annex-D tells that openLogicalChannel can specify TCP/UDP option in the
OLC structure
- which parameter tells TCP/UDP option in OLC? is it the media …
[View More]transport
type
in transport capability ?
- what kind of capability is specified for fax
- is it voice/data ? or a separate capability structure?
Any kind of information, help or pointer would be highly appreciated....
Regards,
Ravi Kiran
Sunil Mahajan
[View Less]
Folks,
As many of you know, the latest T.35 document supports more than 254 country
codes. In the newest document, T.35 says that one or two octets may be used
to indicate the country code. If the first octet contains 1111 1111, the
second octet will contain the country code.
Unfortunately, the syntax in H.245 does not utilize extension markers, so
there is no place to hold second octet for the country code. Therefore, I
would like to propose that, both for H.225.0 and H.245, we change the
…
[View More]comments in the ASN.1 from:
t35CountryCode INTEGER(0..255), -- country, as per T.35
t35Extension INTEGER(0..255), -- assigned nationally
manufacturerCode INTEGER(0..65535), -- assigned nationally
to the following
t35CountryCode INTEGER(0..255), -- country, as per T.35 Annex A
t35Extension INTEGER(0..255), -- assigned nationally, unless the
-- t35CountryCode is 1111 1111, in
-- which case this field shall
-- contain the country code found
-- in T.35 Annex B
manufacturerCode INTEGER(0..65535), -- assigned nationally
This may be a perversion of the t35Extension field, but we have a limited
number of options if we wish to support the usage of two octets for a
country code in H.245.
What are your opinions?
Best Regards,
Paul
[View Less]
Jin and Liao,
I will like to inform you that ITU-sg16 has open up two
new annexs in H.323 to support mobility.
H.323 Mobile Annex
It was agreed during the joint meeting with Q11 to
create a mobile Annex for H.323. This would take
the form of a document or documents that address
mobility issues, including:
Mobility, including user and service mobility
Mobile issues including
Layer 2 issues & timers
Header compression
Handoffs and the H.323 system architecture
Next Meeting Decision
H.…
[View More]323 Annex H (User and Service Mobility in H.323)
E. Martinez (Motorola)
H.323 Annex I (Terminal Mobility in H.323)
(Toshiba)
Attached is the meeting information.
I resent this message because the attachments fail to deliver.
--
Subject: Re: comments on DTR07001v1_1_2r1
Date: Sun, 27 Jun 1999 07:57:36 +0800 (CST)
From: Wan-jiun Liao <wjliao(a)cc.ee.ntu.edu.tw>
To: "Edgar Martinez [1]" <martinze(a)cig.mot.com>
CC: "Yang, Jin (Jin)" <jinyang(a)lucent.com>, TIPHON_WG7(a)LIST.ETSI.FR,
Vli(a)eee.hku.hk, Wan-jiun Liao <wjliao(a)cc.ee.ntu.edu.tw>
Dear Edgar and Jin,
Thanks for your valuable comments on the part of mobile extensions
to
h.323. I am the author of this section. The point we would like address
for our h.323 mobile extension is that we would like to demonstrate
that h.323 provides an excellent environment for mobility support and
thus tend to make modifications as few as possible to h.323 for mobility
support. In fact, the article has been revised and
extended (from infocom'99 one) since I came back from TiPHON
meeting at Bangkok in May. Attached please find a copy of new revised
version of mh323. Some of your questions may have answered.
Re. the following sentences,
> My thoughts, rather then propose/add all the mobility extensions to
> H.323.
> I rather work on how to Tunnel Mobility Management (MM) messages from
> the RAN
> to a Wireless Call Server (WCS) via H.323. While in the same context
> work-out the
> WCS interface to the Gatekeeper to Tunnel through the TCAP/MAP messages
> to and
> from the IP network and the GSM MSC and HLR for interworking.
We have a work currently going on with a similar idea to this
one. However, we still stick on making as less as possible modification
to
current h.323 for mobility support. The new work is almost done and will
be able to support the IP network and the GSM (or DECT) MSC and HLR for
interworking. We may presnet our new work at the next TiPHON's meeting
then.
Thanks for your comments.
Best Reagrds,
Wanjiun Liao
On Sat, 26 Jun 1999, Edgar Martinez [1] wrote:
> Dear Jin,
>
> I am not the author of the section but I have some comments to add:
>
> "Yang, Jin (Jin)" wrote:
> >
> > Dear WG7 "roamers",
> >
> > I am reading the DTR07001 draft on the part of "mobile extension to H323",
> > section 5.11 with the following comments (I will not be able to attend the
> > next meeting, so post my comments here):
> >
> > .....
> > "With H.323, data, voice, and video in an IP call are transmitted using the
> > Real-time Transport Protocol [21]. "
> >
> > data is not using RTP. voice and video does.
>
> If we change the wording like the following will it be OK?
>
> "With H.323, voice-data, and video-data in an IP call are transmitted
> using the
> Real-time Transport Protocol [21]. "
>
>
> > .....
> > "Call setup and other call control signaling messages are carried
> > out-of-band, sent through different paths other than those for the payload
> > traffic. "
> >
> > not necessarily different path.
>
> We can change the text to read:
>
> "In a reliable network Call setup and other call control signaling
> messages
> could be sent through different paths other than those for the payload
> traffic. "
>
> --
> *A reliable network are system that have a backup link connection
> running a reliable transport protocol like sigtran's CTP.
>
>
> >
> > .......
> > "Under the current version of H.323 service scope, however, host mobility is
> > forbidden, resulting from the underlying IP mechanism that implicitly
> > assumes that a host is fixed. "
> >
> > Is this true? H323 is OK for mobile hosts if the mobility is provided at
> > lower layers, which can be mobile IP based, or replying on layer2,e.g.
> > wireless LAN layer 2 mobility support. H323, as an application layer
> > protocol can be transparent.
> > ......
>
> Yes,
>
> I propose to take out the foolowing:
>
> >"Under the current version of H.323 service scope, however, host mobility is
> >forbidden, resulting from the underlying IP mechanism that implicitly
> >assumes that a host is fixed. "
>
> And replace it with:
>
> "H323 could support mobile hosts if the mobility is provided at
> lower layers e.g., using IPv6, which can be mobile IP based,
> or replying on layer2 wireless LAN layer 2 mobility support.
> H323, as an application layer protocol can be transparent."
>
> I tend to agreed with you and hope to see support of TCAP/MAP
> support on top of IPv6.
> oops!
>
>
> > "Moreover, Voice over IP service is a real-time connection-oriented service
> > over packet-switched IP-based networks. Neither the circuit-switched
> > cellular phone approach nor the connectionless Mobile IP mechanism is
> > capable of providing mobile Internet telephony service. "
> >
> > why? connection-oriented applications do not necessarily require
> > connection-oriented transport. Although Mobile IP, as it is defined at this
> > stage, has its limitations/issues for real-time applications in a highly,
> > global mobile environment, people are working on it to resove them.
> >
>
> Iam looking towards 3GPP or TIPHON to provide us the option to send VoIP
> on
> the RAN IU-ps link. Reference to Liassion Statement sent to WG7 Bangkok
> 13TD146. As a first step.
>
> > ....
> > "New approaches are required for mobile IP telephony.
> > Through proper call setup signaling with the H.323 Gatekeeper, the address
> > of the target endpoint (i.e., callee or called party) can be resolved before
> > call establishment, enabling the service redirection to be completely
> > handled in the application layer. Thus, it realizes mobile IP telephony
> > services with IP. This approach enables mobility support without the need
> > for additional new entities and with minimal modifications to the H.323
> > standard, allowing such mobile IP telephony service to be a valued-added
> > feature in the existing H.323-compliant Internet telephony systems."
> >
> > what is the extension, at the end?
> >
>
> My thoughts, rather then propose/add all the mobility extensions to
> H.323.
> I rather work on how to Tunnel Mobility Management (MM) messages from
> the RAN
> to a Wireless Call Server (WCS) via H.323. While in the same context
> work-out the
> WCS interface to the Gatekeeper to Tunnel through the TCAP/MAP messages
> to and
> from the IP network and the GSM MSC and HLR for interworking.
>
> >
> > -------------------------------------------------------------------
> > Mail archive for TIPHON_WG7 can be browsed at the following url :
> >
> > http://www.etsi.org/tiphon/mailing.htm
> > -------------------------------------------------------------------
>
--
Edgar Martinez - Principal Staff Engineer
Email mailto:martinze@cig.mot.com
FAX 1-847-632-3145 - - Voice 1-847-632-5278
1501 West Shure Drive, Arlington Hgts. IL 60004
Public: TIPHON & Other Stds - http://people.itu.int/~emartine/
Private:TIPHON & Other Stds - http://www.cig.mot.com/~martinze/
Subject: Notice of the Berlin meeting
Date: Fri, 25 Jun 1999 15:14:57 +0900
From: Sakae OKUBO <okubo(a)GITI.OR.JP>
Reply-To: Mailing list for parties associated with ITU-T Study Group 16
<ITU-SG16(a)mailbag.cps.intel.com>
To: ITU-SG16(a)mailbag.cps.intel.com
To Experts of ITU-T SG16 Q.12/16, Q.13/16 and Q.14/16
Cc Mr. P-A. Probst, Chairman of SG16
Mr. G. Helder, Vice-Chairman of SG16
Mr. F. Tosco, Chairman of WP2/16
Mr. F. Bigi, ITU-TSB
Mr. T. Geary, Rapporteur for Q.11/16
Mr. G. Sullivan, Rapporteur for Q.15/16
Mr. J. Ott, Teles
Mr. S. Wenger, Teles
De Sakae OKUBO
Rapporteur for Q.12/16 in ITU-T SG16
TAO Waseda Research Center
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
Dale SKRAN
Rapporteur for Q.13/16 in ITU-T SG16
Ascend Communications, Inc.
621 Shrewsbury Avenue
Shrewsbury, NJ 07702
USA
Tel: +1 908 450 1635
Fax: +1 908 450 1611
E-mail: Dale.Skran(a)ascend.com
Glen Freundlich
Rapporteur for Q.14/16 in ITU-T SG16
Lucent Technologies
11900 N. Pecos
Westminster, Colorado 80234
USA
Tel: +1 303 538 2899
Fax: +1 303 538 3907
E-mail: ggf(a)lucent.com
----------------------------------------------------------
Subject: Notice of Q.12-14/16 Rapporteur Meeting in Berlin
Date: 25 June 1999
----------------------------------------------------------
Dear Q.12-14/16 experts,
The subject meeting of ITU-T SG16 experts will be held in Berlin, Germany at
the kind invitation of TELES AG.
Please note that Q.11/16 and Q.15/16 will meet concurrently at the same
place and have joint sessions with Q.12-14/16.
1. Date
^^^^^^^
2 (Monday) - 6 (Friday) August 1999
starting at 9:00 on the first day
2. Venue
^^^^^^^^
GRAND HOTEL ESPLANADE BERLIN
Luetzowufer 15
10785 Berlin-Tiergarten
Voice: +49 30 254 78-0
Fax: +49 30 265 1171
EMail: info(a)esplanade.de
WWW: http://www.esplanade.de/eframe.htm
3. Topics (tentative)
^^^^^^^^^^^^^^^^^^^^^
1) Review of the relevant group meetings
2) Q.12/16 B-ISDN multimedia systems and terminals
- White contribution for H.222.0 Amendment 7
- H.321 v2 Implementers Guide
- H.310 v2 Implementers Guide
- Work with Q.13 on high quality video transmission over IP
- Future AV communication systems
3) Q.13/16 Packet switched multimedia systems and terminals
- Finalize white contributions for:
* H.323 V3
* H.225.0 V3
* H.450.8 (Name Identification)
* H.323 Annex G (Text SET)
- Update H.323 Implementers guide
- Further Develop:
* H.323 Annex F (Secure SET)
* H.323 Annex H (User/Service Mobility)
* H.323 Annex I (Terminal Mobility)
* H.450.9 (Call Completion on Busy)
- Work with Q.14 on H.GCP white paper
- Work with Q.14 on H.246 Annex C white paper
- Work with Q.14 on H.246 Annex D
4) Q.14/16 Common protocols, MCUs and protocols for interworking with
H.300-series terminals
- Finalize white contributions for:
* Prepare H.gcp
* Prepare H.246 Annex C
* Prepare H.245 V6
* Prepare H.243 V2
* Prepare H.224 V2
- Progress work on IN-H.323 interface (H.246 Annex D)
- Update implementers guide
5) Coordination with Q.11/16 and Q.15/16
- System aspects
- Video coding aspects
6) Interaction with other groups
7) Future work plan
4. Documents
^^^^^^^^^^^^
/// Registration of the document: by 23 July (Friday) ///
/// Distribution of the document: by 26 July (Monday) ///
/// Use the ftp site (or e-mail reflector) for distribution ///
1) When you are going to submit a document, please notify S.
Okubo as soon as possible, by 23 July (Friday) at the latest.
Document number (APC-1nnn) will be allocated. Early indication of
your submission plan is welcome and encouraged.
Note - Prefix "APC" comes from Atm (Q.12/16), Packet based (Q.13/16)
and Common protocols (Q.14/16) based on the coordination with Q.1
("Q1City"), Q.3 ("T120"), Q.11 ("Q11"), Q.15 ("Q15") groups.
2) You are advised to include a header as follows:
------------------------------------------------------------------
| |
| ITU Telecommunication Standardization Sector Document APC-{1nnn}|
| Study Group 16 {Version m if relevant}|
| Q.12-14/16 Rapporteur Meeting {Date}|
| Berlin, 2-6 August 1999 |
| |
| SOURCE*: { } |
| TITLE : { } |
| PURPOSE: {Proposal, Discussion, Information, Report, etc.} |
| |
| _________________________ |
| |
| |
| |
| *Contact: Name, e-mail |
------------------------------------------------------------------
3) All the contributors are requested to distribute their
documents as early as possible, at least 7 calendar days in advance
of the meeting (26 July or before) by posting them at either of the
following:
- PictureTel ftp site (please advise S. Okubo of your posting)
Site: standard.pictel.com/avc-site
Login name: anonymous
Directory: Incoming
- Q.12-14/16 experts reflector
e-mail address: itu-sg16(a)mailbag.jf.intel.com
Please avoid the use of reflector when your document is
voluminous.
4) Input documents can be retrieved from /9908_Ber directory of
the ftp site.
5) Please bring 80 copies of your document to Berlin if it should be
in hardcopy. Your cooperation is needed to start the meeting with all
the documents at hand; please note that the copying capacity at the
meeting site is very limited and expensive.
6) The document distribution / presentation at the meeting
will be electronic (i.e. participants must bring their laptops along).
5. Logistic information
^^^^^^^^^^^^^^^^^^^^^^^
Please see the invitation distributed by the meeting host
(http://standard.pictel.com/ftp/avc-site/9908_Ber/Invitation.txt)
6. Registration
^^^^^^^^^^^^^^^
To confirm your meeting attendance, please reply directly to TELES
using the registration form distributed by the host
(http://standard.pictel.com/ftp/avc-site/9908_Ber/registration-form.doc)
up to and including 1 July for early regsitration with a meeting fee of DEM
500,00. Please note that after this date, the registration fee becomes
DEM 650,00.
In addition, please send a separate e-mail registration to Mr. Ott and copy
the Rapporteurs on this e-mail. Please use the subject and message body
format shown below.
To: jo(a)teles.de
Cc: okubo(a)giti.or.jp, dskran(a)ascend.com, ggf(a)lucent.com,
tom.geary(a)conexant.com, garysull(a)microsoft.com
Subject: Berlin meeting registration
NAME:
COMPANY:
EMAIL:
ARRIVAL:
DEPARTURE:
Please attach a *small* photograph of yourself as GIF or JPG format and
send this to jo(a)teles.de attached to the registration mail.
7. Hotel Room Reservation
^^^^^^^^^^^^^^^^^^^^^^^^^
Please directly contact GRAND HOTEL ESPLANADE BERLIN mentioning "ITU-
Meeting" to obtain the special rate; DEM 280,00 -- approximately USD 150
-- per night including a breakfast buffet for a single/double room. You
need to guarantee the room reservation with your credit card.
CUTOFF DATE for the special room rate is Thursday, 1 July 1999.
We are looking forward to meeting with you in Berlin.
Sincerely yours,
Sakae OKUBO
Dale SKRAN
Gary THOM
----------
[View Less]
Tom,
If you haven't had a chance to read it yet, I think my internet-draft covers
off a lot of the syntactic issues on messaging.
(Accessible at:
http://www.tech-know-ware.com/draft-cordell-messaging-00.txt)
On the semantics side, I like the SIP "Require:" construct. This indicates
packages or parameters that must be understood. Anything else is optional.
The transaction is cancelled if the server doesn't understand something that
is required. It's essentially equivalent to 'comprehension …
[View More]required' in
Q.931 although its more expressive in what needs to be understood. This is
a simple technique, but is actually very powerful.
Regards,
Pete
=============================================
Pete Cordell
pete(a)tech-know-ware.com
=============================================
-----Original Message-----
From: Tom-PT Taylor <taylor(a)NORTELNETWORKS.COM>
To: ITU-SG16(a)MAILBAG.INTEL.COM <ITU-SG16(a)MAILBAG.INTEL.COM>
Date: 24 June 1999 19:59
Subject: Interoperability and Extensibility
>We face a continuing tension between the requirement to ensure
>interoperability and the desirability of minimizing the size of the core
>protocol, particularly at the MG. We also have to make sure our protocol
>has well-defined procedures for adding both ad hoc (i.e. proprietary or
>experimental) and formal extensions. This note suggests some principles
>which we should follow in response to these considerations.
>
>There are really two levels of interoperability to deal with: syntactic
(can
>the message be parsed?) and semantic (can the message recipient perform the
>actions which the sender is requesting?).
>
>At the syntactic level, I believe that we can agree on these principles:
>
>I-1: Every message must be fully parsable down to a certain level of
detail,
>even if it contains extensions unsupported by the recipient.
>
>I-2: Our protocol document must specify the syntax by means of which
>extensions are identified.
>
>I-3: The protocol must provide the means for the recipient to identify in
>its response to any message all unsupported extensions it encountered in
>that message.
>
>There is an open issue here: what is the minimal parsability level we want
>to specify? Suggestion: all messages are parsable down to the command and
>parameter level at a minimum. Here I use the term "parameter" to imply
>either a simple data value or a potentially complex data structure
>identified as a syntactic element in our API definitions. The implication
>of this suggestion is that extensions can add no new commands, no new
>command parameters, only new possible values for command parameters and new
>event packages. I'm sure others will have comments on this.
>
>Now we get to the interesting part: semantic interoperability. I'll start
>with what I hope are a couple of obvious statements.
>
>I-4: Not all implementations will support all event packages, all possible
>parameter values, or whatever else we allow to be extended.
>
>I-5: The protocol definition must include a specification of what the
>receiver does if a message contains an unsupported extension.
>
>On this latter point, do we enforce the transaction concept at all levels
>and fail the transaction, requiring the sender to reissue the command
>without the offending value? This is definitely a workable solution. We
>could go further and introduce the ability to say in a message whether a
>given field is a transaction-stopper, but I'm not sure that capability
would
>be used in practice -- it wasn't when we had it in IPDC.
>
>Now for the crucial question: if I-4 is true, what criteria do we use to
say
>what features MUST be supported by any given implementation? Can we
>distinguish between required support in MGC implementations, versus
required
>support in MG implementations? How does each side of the Megaco interface
>determine what the other side supports, other than by parsing transaction
>rejections? Here are some propositions to use as a basis for discussion:
>
>I-6: The Megaco/H.GCP specification should be organized into a basic
>protocol specification which must be satisfied by all implementations, plus
>annexes which are conditionally mandatory. The conditions under which an
>annex is mandatory will be stated within the annex itself, to make it
>self-contained.
>
>Some annexes will constitute extensions of the protocol (e.g. event package
>specifications) and must therefore be identifiable as such at the syntactic
>level. Other annexes may be more like profiles, stating, for example, what
>extensions must be supported by an MG or MGC which supports a given
>application. An extension identifier for the complete profile is a
>"nice-to-have", but would be used only as shorthand in Audit responses, not
>in other commands.
>
>Looking to the future, extensions could be created:
>-- by joint Megaco/ITU action, added as new annexes to H.GCP
>-- by action of the ITU on its own, added as new annexes to H.GCP or as new
>Recommendations.
>-- by the IETF on its own, added as new RFCs
>In all cases, I suggest that the extensions be registered with IANA in
>accordance with procedures and criteria defined in the base protocol
>document.
>
>I-7: As a general principle in deciding what each implementation must
>support, MGs should be assumed to be more specialized than MGCs. For
>example, we may decide (though I doubt it) that all MGCs must support all
>applications documented in the initial Megaco/H.GCP specification, but MGs
>may support an arbitrary subset of them.
>
>This is a debatable principle -- some vendors probably have a different
view
>of the architecture. I suspect it is the consensus view, however.
>
>I-8: If at all possible, MGs should hide the details of national and
>regional variations in channel-associated signalling from the MGC.
>
>This is more debatable than I-7. I propose it as a principle on the
grounds
>that MGs are more likely to be serving customers in only one country or
>region than are MGCs, so they will be the more logical point of
>specialization. I have a concrete suggestion for our event packages which
>may help to support this principle: event descriptor syntax should include
>both the abstract event names and specialization identifiers which
indicate,
>for instance, that the MG should provide busy tone for Country A rather
than
>Country B to this particular termination. That way the MGC can pass down
>information it has received from signalling, while the physical details are
>known only to the MG.
>
>
>
>
>
>
>Tom Taylor
>Advisor -- IPConnect Standards
>E-mail: taylor(a)nortelnetworks.com (internally, Tom-PT Taylor)
>Phone and FAX: +1 613 736 0961
>
[View Less]
