- sg16-avd - lists.packetizer.com

Re: H.245v6 ASN.1 tree?
by Paul Long 12 Aug '99

12 Aug '99

Mike, Oh, yeah, you're right! I gotta get used to genericCapabilities. Without looking closely at the other TDs, I thought they introduced new syntax. Thanks. So even though H.323v3 is Decided, we may modify the syntax for H.245v6, based on SG8's response regarding T.38? Paul Long Smith Micro Software, inc. -----Original Message----- From: mike.nilsson(a)BT.COM To: ITU-SG16(a)MAILBAG.INTEL.COM Sent: 8/12/99 1:56 AM Subject: Re: H.245v6 ASN.1 tree? Paul, The only change to the syntax for V6 that I am aware of is the change given below (from TD69/PLEN of Santiago), where ** is used to label additions. MediaTransportType ::=CHOICE { ip-UDP NULL, ip-TCP NULL, atm-AAL5-UNIDIR NULL, -- virtual circuits used as unidirectional atm-AAL5-BIDIR NULL, -- virtual circuits used as bidirectional ..., ** atm-AAL5-compressed SEQUENCE ** { ** variable-delta BOOLEAN , ** ... ** } } At the Berlin meeting there were discussion regarding the T.38 fax codepoints - we had received a liaison from SG8 that showed that there were differences between T.38 Annex B and H.245 V5. We replied to them suggesting a syntax addition to H.245 (V6) to allow the additional fields in T.38 Annex B to be signalled. I am assuming that we will not include these changes in H.245 until we have received a response from SG8. I have not made a new syntax - it did not seem worth the effort - and I am not aware of anyone else doing so. Best regards Mike

1 0

Re: H.245v6 ASN.1 tree?
by mike.nilsson＠BT.COM 12 Aug '99

12 Aug '99

Paul, The only change to the syntax for V6 that I am aware of is the change given below (from TD69/PLEN of Santiago), where ** is used to label additions. MediaTransportType ::=CHOICE { ip-UDP NULL, ip-TCP NULL, atm-AAL5-UNIDIR NULL, -- virtual circuits used as unidirectional atm-AAL5-BIDIR NULL, -- virtual circuits used as bidirectional ..., ** atm-AAL5-compressed SEQUENCE ** { ** variable-delta BOOLEAN , ** ... ** } } At the Berlin meeting there were discussion regarding the T.38 fax codepoints - we had received a liaison from SG8 that showed that there were differences between T.38 Annex B and H.245 V5. We replied to them suggesting a syntax addition to H.245 (V6) to allow the additional fields in T.38 Annex B to be signalled. I am assuming that we will not include these changes in H.245 until we have received a response from SG8. I have not made a new syntax - it did not seem worth the effort - and I am not aware of anyone else doing so. Best regards Mike ********************************************************************** * Mike Nilsson Tel: +44 1473 645413 * * Applications Technology Group Fax: +44 1473 645011 * * Internet and Multimedia Applications Email: mike.nilsson(a)bt.com * * BT Advanced Communications Technology Centre [B54 Room 94] * * Adastral Park * * Martlesham Heath * * Ipswich IP5 3RE * * UK * ********************************************************************** > -----Original Message----- > From: Paul Long [SMTP:Plong@SMITHMICRO.COM] > Sent: Thursday, August 12, 1999 5:04 AM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: H.245v6 ASN.1 tree? > > Has a complete ASN.1 syntax been put together for H.245v6, the version > used > by H.323v3? If so, where I can find it online? I guess it would be H.245v5 > with the Santiago TDs applied. I can combine them on my own, but I'd like > something with which to corroborate my result. > > Paul Long > Smith Micro Software, Inc.

1 0

Berlin meeting report APC-1644
by Sakae OKUBO 12 Aug '99

12 Aug '99

Dear Q12-14/16 experts, Draft meeting report of the Berlin meeting has been placed at the PictureTel ftp site as: ftp://standard.pictel.com/avc-site/Incoming/APC-1644.zip or http://standard.pictel.com/ftp/avc-site/Incoming/APC-1644.zip I have edited this document by integrating TD-20, 21, 22, 23 and other relevant materials. Though there are still some points needing confirmation of Q13 and Q14 Rapporteurs (as indicated with yellow marks), please review this draft, list of participants in particular, and return your corrections in two weeks time - by 26 August. Best regards, Sakae OKUBO (Mr.) *********************************************************** Waseda Research Center Telecommunications Advancement Organization of Japan (TAO) 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 ***********************************************************

1 0

Fwd: TD-27a
by Sakae OKUBO 12 Aug '99

12 Aug '99

Dear Q12-14/16 experts, In response to Mr. Coldren's request as attached, TD-27a.zip has been placed at the /9908_Ber directory. TD-27.zip there will be removed. The convention for the file name is as follows: TD-nn.zip - initial submission TD-nna.zip - first revision TD-nnb.zip - second revision etc. whatever name the file had when posted. Best regards, Sakae OKUBO (Mr.) *********************************************************** Waseda Research Center Telecommunications Advancement Organization of Japan (TAO) 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 *********************************************************** Posted-Date: Wed, 11 Aug 1999 16:59:40 -0700 (MST) Date: Wed, 11 Aug 1999 17:00:47 -0700 From: "Rex Coldren" <coldrenr(a)agcs.com> Reply-To: coldrenr(a)agcs.com Organization: AG Communication Systems X-Accept-Language: en MIME-Version: 1.0 To: okubo(a)giti.or.jp CC: pauljones(a)ties.itu.int Subject: TD-27a Mr. Okubo, Please accept TD-27a to the Berlin directory. The abstract of this TD follows: Following are modifications to TD-27 to address issues raised when the TD was discussed in the Friday morning meeting of SG16 in Berlin. The modifications are all intended to show that APC-1581, as amended by TD-27, should be included in H.323 v4 and H.225 v4 rather than in v3. APC-1581 and TD27 show changes against the v3 specifications since the v4 specs were not available at the time of writing of these contributions Thank you, Rex Coldren

1 0

H.245v6 ASN.1 tree?
by Paul Long 12 Aug '99

12 Aug '99

Has a complete ASN.1 syntax been put together for H.245v6, the version used by H.323v3? If so, where I can find it online? I guess it would be H.245v5 with the Santiago TDs applied. I can combine them on my own, but I'd like something with which to corroborate my result. Paul Long Smith Micro Software, Inc.

1 0

Full Network Harmonization
by Edgar Martinez [1] 11 Aug '99

11 Aug '99

Dear All I have updated TD-09 network picture on figure 3 to include some of the ideas that Tiphon and other groups are working on. Regards, -- 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/

1 0

Re: is cross-posting really necessary?
by Edgar Martinez [1] 11 Aug '99

11 Aug '99

Dear Nancy, I too support Christian, the MEGACO list is a heavy hitter when it comes to an overload of messages in a mail box. Plus not all issues are common, and one needs only a shap shot to get the idea where it is going. The issues with Sigtan would have been better understood if we had the same service. Thank you, Ed "Callaghan, Robert" wrote: > Nancy, > > I thank Christian for advising the SG16 mailing list as to the MEGACO > activities. I don't monitor the MEGACO list because I simply do not have > time for all the detailed work. However, I do believe that SG16 people > should be kept informed as to the general activities that are performed in > the name of SG16. > > Abrogating the coding agreement from Berlin because it is inconvenient > should not be keep hidden from the SG16 group. The AD/Chair may determine > consensus for IETF, but not for ITU. In ITU, consensus is determined by the > Rapporteur, and that is not Tom Taylor. > > The agreed proposal for dual coding standards was an attempt to finesse the > unresovable disagreement over the coding standards. Abrogating this > agreement may only extend the discussion. This can only impede a JOINT > standard. > > Bob > > ------------------------------------------------------------------ > Robert Callaghan > Siemens Business Communication Systems > Tel: +1.561.997.3756 Fax: +1.561.997.3403 > Email: Robert.Callaghan(a)ICN.Siemens.com > ------------------------------------------------------------------ > > -----Original Message----- > From: Nancy-M Greene [mailto:ngreene@NORTELNETWORKS.COM] > Sent: Tuesday, August 10, 1999 12:03 PM > To: ITU-SG16(a)mailbag.cps.intel.com > Subject: is cross-posting really necessary? > > Christian Groves writes: > > As this issue affects both SG16 and MEGACO I ask that people cross > > post their responses to both SG16 and MEGACO lists. > > ITU-SG16(a)mailbag.cps.intel.com > > megaco(a)standards.nortelnetworks.com > > > > Christian > > > Christian, > I don't know if others agree, but I would suggest that the conversation > remain on just ONE mailing list so that people on both lists do not receive > two of everything. > > If there is interest from SG16 members to follow this discussion, you can > either join the Megaco mailing list, or consult the Megaco mailing list > archives. Then cross-posting is not needed. > > The Megaco list archives are at: http://standards.nortelnetworks.com > > To join the Megaco mailing list, send an email to > listserv(a)standards.nortelnetworks.com with > > subscribe megaco > > in the msg body (no subject needed). > > Nancy > -------------------------------------------------------------------------- > Nancy M. Greene > Internet & Service Provider Networks, Nortel Networks > T:514-271-7221 (internal:ESN853-1077) E:ngreene@nortelnetworks.com -- 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/

2 1

Re: is cross-posting really necessary?
by Callaghan, Robert 10 Aug '99

10 Aug '99

Nancy, I thank Christian for advising the SG16 mailing list as to the MEGACO activities. I don't monitor the MEGACO list because I simply do not have time for all the detailed work. However, I do believe that SG16 people should be kept informed as to the general activities that are performed in the name of SG16. Abrogating the coding agreement from Berlin because it is inconvenient should not be keep hidden from the SG16 group. The AD/Chair may determine consensus for IETF, but not for ITU. In ITU, consensus is determined by the Rapporteur, and that is not Tom Taylor. The agreed proposal for dual coding standards was an attempt to finesse the unresovable disagreement over the coding standards. Abrogating this agreement may only extend the discussion. This can only impede a JOINT standard. Bob ------------------------------------------------------------------ Robert Callaghan Siemens Business Communication Systems Tel: +1.561.997.3756 Fax: +1.561.997.3403 Email: Robert.Callaghan(a)ICN.Siemens.com ------------------------------------------------------------------ -----Original Message----- From: Nancy-M Greene [mailto:ngreene@NORTELNETWORKS.COM] Sent: Tuesday, August 10, 1999 12:03 PM To: ITU-SG16(a)mailbag.cps.intel.com Subject: is cross-posting really necessary? Christian Groves writes: > As this issue affects both SG16 and MEGACO I ask that people cross > post their responses to both SG16 and MEGACO lists. > ITU-SG16(a)mailbag.cps.intel.com > megaco(a)standards.nortelnetworks.com > > Christian > Christian, I don't know if others agree, but I would suggest that the conversation remain on just ONE mailing list so that people on both lists do not receive two of everything. If there is interest from SG16 members to follow this discussion, you can either join the Megaco mailing list, or consult the Megaco mailing list archives. Then cross-posting is not needed. The Megaco list archives are at: http://standards.nortelnetworks.com To join the Megaco mailing list, send an email to listserv(a)standards.nortelnetworks.com with subscribe megaco in the msg body (no subject needed). Nancy -------------------------------------------------------------------------- Nancy M. Greene Internet & Service Provider Networks, Nortel Networks T:514-271-7221 (internal:ESN853-1077) E:ngreene@nortelnetworks.com

1 0

is cross-posting really necessary?
by Nancy-M Greene 10 Aug '99

10 Aug '99

Christian Groves writes: > As this issue affects both SG16 and MEGACO I ask that people cross > post their responses to both SG16 and MEGACO lists. > ITU-SG16(a)mailbag.cps.intel.com > megaco(a)standards.nortelnetworks.com > > Christian > Christian, I don't know if others agree, but I would suggest that the conversation remain on just ONE mailing list so that people on both lists do not receive two of everything. If there is interest from SG16 members to follow this discussion, you can either join the Megaco mailing list, or consult the Megaco mailing list archives. Then cross-posting is not needed. The Megaco list archives are at: http://standards.nortelnetworks.com To join the Megaco mailing list, send an email to listserv(a)standards.nortelnetworks.com with subscribe megaco in the msg body (no subject needed). Nancy -------------------------------------------------------------------------- Nancy M. Greene Internet & Service Provider Networks, Nortel Networks T:514-271-7221 (internal:ESN853-1077) E:ngreene@nortelnetworks.com

1 0

[Fwd: Re: Text vs. Binary (was Re: Results from the ITU SG16 Berlin mtg)]
by Christian Groves 10 Aug '99

10 Aug '99

FYI for SG16, a part of a thread on the outcome of Berlin. As this issue affects both SG16 and MEGACO I ask that people cross post their responses to both SG16 and MEGACO lists. ITU-SG16(a)mailbag.cps.intel.com megaco(a)standards.nortelnetworks.com Christian -------- Original Message -------- Subject: Re: Text vs. Binary (was Re: Results from the ITU SG16 Berlin mtg) Date: Mon, 9 Aug 1999 22:47:52 +0200 From: Chip Sharp <chsharp(a)CISCO.COM> Reply-To: Chip Sharp <chsharp(a)CISCO.COM> To: MEGACO(a)STANDARDS.NORTELNETWORKS.COM References: <4.1.19990809163617.03ef1760(a)dogwood.cisco.com><F033F6FEF3F1D111BD150000F8CD1431025B5F9E(a)zcard007.ca.norte l.com> At 05:09 PM 8/9/99 -0700, Matt Holdrege wrote: >At 05:56 PM 8/9/99 +0200, Chip Sharp wrote: >>At 10:20 PM 8/8/99 -0400, Nancy-M Greene wrote: >> >> >It is expected that industry forums would define profile for use of H.248 >> >and this would include whether text vs binary is used, as well as which >> >packages would be used, etc. In Section 6.3.4, sentences added: "MGCs should >> >support both encoding formats. MGs may support both formats." >> > >>...snip... >> >>I propose that megaco should continue with its Oslo agreement and >>concentrate on the text encoding. Therefore, the IETF document would >>contain the text version of the protocol but not the binary version. Since >>the parameter encoding is so tightly bound with the encoding, the IETF >>version would specify the SDP encoding of parameters but not the other >>proposal. > >As has been noted here several times, MEGACO did not in any way agree to >use text. A coin was flipped at an ad hoc meeting and the issue was not >discussed during the main meeting. As Tom has pointed out, it is up to the megaco WG chair to declare consensus. I should say "Oslo proposal". I can say for sure that megaco has not agreed to do both a binary and text encoding. I am making a proposal. I would actually like to hear more people venture their opinion about this other than the 5 to 10 people that seem to create most of the mail on this list. >One thing we agreed on at least from the AD/Chair level was that MEGACO >would pen the requirements in cooperation with SG16 and SG16 would pen the >protocol in cooperation with MEGACO. I see no reason we can't continue with >that method. I believe what Scott sent to the list was: "The gist of the proposal is that the two groups would agree to some form of double veto process where by both groups have to agree to the final wording for the protocol before either group would publish it." I haven't heard anything further. This may seem rather abrupt after the SG16 meeting, but it has to be addressed as to whether or not megaco will agree to both a binary and text encoding. I'd rather have the discussion sooner than later. So the question is, does megaco agree with the SG16 proposal to have both a binary and text encoding of the protocol as described in the draft Nancy mentioned? Chip -------------------------------------------------- Chip Sharp Consulting Engineering Cisco Systems Telco Bio-region Reality - Love it or Leave it. --------------------------------------------------

1 0

RAS to INAP
by Edgar Martinez [1] 10 Aug '99

10 Aug '99

Dear All, Attached is part of a document I presented in TIPHON 13 and the Santiago ITU-SG16 meeting to support INAP interworking in H.323. Which help to start the groups (TIPHON and SG16), to look at INAP-IPT interworking. The reason I sending this out I promise some reps. from TSG11 to send the Mapping of the RAS to INAP messages as a start. Regards, -- 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/

1 0

Short Report on SG11 & SG16
by Edgar Martinez [1] 10 Aug '99

10 Aug '99

Dear Tiphoners ITU-SG11 and IMT-2000 ----------------------------------- ITU-SG11 issued a liaison statement which I hand carried to SG-16. I have attached the liaison statementit to this email. The sum of the statement is that SG11 will support and work together with SG16 to support the INAP interworking in the IP network. I had the luck in meeting some Representatives from IMT-2000 and (informal), presented my proposal on support for H.323 mobility and GSM interworking which was well received. ITU-SG16 last stop in standards tour. ---------------------------------------------------- First of all, provide H.323 mobility recommentions, then non-h323 wireless IWF, e.g., GSM Terminal and MAP interworking in the IP network, the proposals where accepted in the TOR. Attached is are the TORs for H.323 mobile and IN on IPT. Best regards, -- 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/

1 0

Re: overlapped Sending in h.323
by Sudharsana Krishnan 10 Aug '99

10 Aug '99

Christian The Gatekeeper in my opinion cannot resolve absence of destination alias to any valid address. You will always receive a ARJ. The first ARQ you sent should have had the incomplete dest alias and not NULL. You follow the ARJ with additional ARQs as and when you keep getting additional information about the destination and when finally the gatekeeper can translate this address, it will send you a ACF with either its own Call sigannling address (Gk routed) or any other. For eg. Lets assume Ep1 is a terminal connected to a LAN and supports H.323 with overlapped sending. The User wants to dial 91-80-5598615. As and when the user dials each digit (or a set of digits) it sends out a ARQs to its Gatekeeper with destination alias set to say 9 (first ARQ) , 91 (second ARQ) , and so on. Lets assume that the Ep1's gatekeeper has an entry that maps 91-80 (prefix) to a Gateway's call signalling address, the Gatekeeper sends an ACF for the ARQ that contains "91-80" as the destination alias. The ACf can contain the Gatekeeper's Call Signalling address (if the Gatekeeper routes the call) or the Gateway's Call signalling address, and then the Setup, setup acknowlegde, information message sequence takes over. Hence the setup goes only after the ACF is received and only one ACF is received by Ep1 and not two as you have indicated Hope this helps Regards Sudharshan -----Original Message----- From: Christian Geng <christian.geng(a)detewe.de> To: ITU-SG16(a)mailbag.cps.intel.com <ITU-SG16(a)mailbag.cps.intel.com> Date: Tuesday, August 10, 1999 1:29 PM Subject: overlapped Sending in h.323 >Dear Sir or Madam, > >I try to be H.323 conform in the folowing: >I want to support overlap sending within gatekeeper-routed calls. >My session starts with a ARQ from enpoint_1 to GK without any >destination alias. After receaving ACF endpoint_1 sends SETUP without >any destination alias, but with canQverlapSend is TRUE. GK will answer >with a SETUP ACKNOWLEDGE. Endpoint_1 will then send digit by digit of >alias in destinationInfo field of ARQs. By each sending the total >cumulative addressing information is transmitted in destinationInfo >field. GK responds each time with an ARJ until recept full destination >alias, in this case it answers with ACF. I hope I am right until now? >Reading clause 8.1.12 of ITUs H.323 I thought endpoint_1 shall then send >a SETUP message to GK? This will be the second SETUP, because enpoint_1 >allready did. Can't GK send now a SETUP to endpoint_2 with the >ip-address belonging to the destination alias put in the >destCallSignalAddress field? > >I thank you much for an answer to solv my problem. > >Cincerely > >Christian Geng >

1 0

overlapped Sending in h.323
by Christian Geng 10 Aug '99

10 Aug '99

Dear Sir or Madam, I try to be H.323 conform in the folowing: I want to support overlap sending within gatekeeper-routed calls. My session starts with a ARQ from enpoint_1 to GK without any destination alias. After receaving ACF endpoint_1 sends SETUP without any destination alias, but with canQverlapSend is TRUE. GK will answer with a SETUP ACKNOWLEDGE. Endpoint_1 will then send digit by digit of alias in destinationInfo field of ARQs. By each sending the total cumulative addressing information is transmitted in destinationInfo field. GK responds each time with an ARJ until recept full destination alias, in this case it answers with ACF. I hope I am right until now? Reading clause 8.1.12 of ITUs H.323 I thought endpoint_1 shall then send a SETUP message to GK? This will be the second SETUP, because enpoint_1 allready did. Can't GK send now a SETUP to endpoint_2 with the ip-address belonging to the destination alias put in the destCallSignalAddress field? I thank you much for an answer to solv my problem. Cincerely Christian Geng

1 0

Berlin TDs
by Noriko Hosokawa 09 Aug '99

09 Aug '99

Dear Q.12-14/16 experts, Berlin TDs have been uploaded to the /9908_Ber directory. Please note that TD-11 and TD-45 are vacant. Best regards, Sakae OKUBO (Mr.) ********************************************************** Waseda Research Center Telecommunications Advancement Organization of Japan (TAO) 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 ***********************************************************

1 0

Final TDs for the report of the meeting
by Sakae OKUBO 08 Aug '99

08 Aug '99

Dear Q.12-14/16 experts, I have placed a zipped file at the Incoming directory of the PictureTel ftp site: ftp://standard.pictel.com/avc-site/Incoming/Berlin_report.zip or http://standard.pictel.com/ftp/avc-site/Incoming/Berlin_report.zip which contains the following files: TD-20 Q12 report TD-21 Q13 report TD-22 Q14 report TD-23 Report - General These and other materials will be integrated into a complete report as APC-1644 soon. Best regards, Sakae OKUBO (Mr.) *********************************************************** Waseda Research Center Telecommunications Advancement Organization of Japan (TAO) 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 ***********************************************************

1 0

FW: Results from the ITU SG16 Berlin mtg
by Nancy-M Greene 08 Aug '99

08 Aug '99

I've uploaded to the nortel ftp site (see URL below) TD-44, with diff marks against TD-8 (which is the file referenced in the internet-draft <draft-ietf-megaco-protocol-03.txt>), and made the following summary of the changes made in Berlin. If any of you think I have mis-represented the outcome, or if I have forgotten anything, please speak up on the Megaco mailing list. I hope that with a few days discussion, we will have a draft that both the IETF and the ITU agree on, and can move towards going for Last Call. Nancy -------------------------------------------------------------------------- Nancy M. Greene Internet & Service Provider Networks, Nortel Networks T:514-271-7221 (internal:ESN853-1077) E:ngreene@nortelnetworks.com > ---------- > From: Greene, Nancy-M [CAR:5N10:EXCH] > Sent: Sunday, August 08, 1999 10:20 PM > To: 'megaco(a)standards.nortelnetworks.com' > Subject: Results from the ITU SG16 Berlin mtg > > ITU-T SG16 Q12-14 held a Rapporteurs' meeting in Berlin Aug 2-6/99. They > reviewed the current draft of the Megaco/H.248 protocol contained in > <draft-ietf-megaco-protocol-03.txt>, and produced a document containing > all changes they propose to make. > > Much of the text as it appears in <draft-ietf-megaco-protocol-03.txt> has > been accepted. All the suggested additions and clarifications need > discussion on the Megaco mailing list in order to continue the ITU/IETF > cooperation, and to get the protocol ready for Megaco WG last call. > > This document was accepted by SG16 in Berlin as the current draft of > H.248. The document is available at > ftp://standards.nortelnetworks.com/megaco/docs/Wash99 - with filenames > MegacoH248v9Chgs.doc > MegacoH248v9Chgs.pdf > MegacoH248v9Chgsdoc.zip > MegacoH248v9Chgspdf.zip > > The Word document has diff marks against MegacoHGCPv9itu.doc, and NOTE > that the itu macro is on - switch it to the ietf macro to see the ietf > text. > If you have any trouble getting/reading these files, please let me know > (ngreene(a)nortelnetworks.com) > > After discussion on the Megaco mailing list, the editors of Megaco/H.248 > (Brian Rosen (brosen(a)eng.fore.com) as the IETF editor, and John Segers > (jsegers(a)lucent.com) as the ITU-T editor) will incorporate appropriate > changes and then (I expect) issue it as a new internet-draft. > > ****IF ANY POINTS NEED DISCUSSION, please send each > ****point in a separate email, and, if applicable, propose > ****exact text changes you would make. > > Below is a summary of these changes, technical and editorial, as well as a > few questions. Points marked with "***" require work. > > Technical additions/changes/issues > ---------------------------------------------------- > T1) Section 6.2.2.2: Intercept: added a topology descriptor as a context > parameter, to allow operator intercept, wiretapping - satisfies the > regulatory requirement of only allowing the tapping of one side. Also, > removed InterceptToken from ABNF - this is done using context parameters > instead. ***Need to review this topology descriptor proposal to see > whether it works, and whether it could be covered already in another way, > using the muxing descriptor for example. > > T2) Section 6.2.3.3: TerminationIds - Changed "arbitrary string" to > "arbitrary schema" so it is not tied to a text encoding (there may be a > better word). Note that there is NO special meaning about the / character. > Added "In a text encoding of this protocol". Added sentence > "TerminationIDs of physical Terminations are provisioned in the Media > Gateway". Re-included text describing use of hierarchical terminationIds. > > T3) Section 6.2.3.5: ***Make sure the parameter tables from the Santiago > text go in an annex as parameters of one of the basic packages. These > parameters would be included in the LocalDescriptor. > > T4) Section 6.2.3.5: ***There is still an issue with tx and rx descriptor > names: when you do an add on the RTP termination, in the response you will > get params for RxDescriptor (local information). BUT it is also a transmit > descriptor. So, there is still a wish to call rxDescriptor the > localDescriptor, and txDescriptor the remoteDescriptor. Note added. > > T5) Section 6.2.3.6: ***Issue with ROOT TerminationId - It seems a bit of > a kludge to use a special ROOT terminationId to refer to the entire MG - > can we make TerminationId optional in AuditValue, AuditCapability? then we > would not need ROOT. Check effect to ServiceChange. > > T6) Section 6.3.2.11: ***Need to add a way to configure the level of > embedding of signals/events descriptor, and MGC needs to be able to find > out the level of embedding. > > T7) Section 6.3.2.11: Re-added the sentence saying at least one level of > embedding should be supported. (Why was it removed?) > > T8) Sectio 6.3.2.15: DigitMapDescriptor - Added a start timer, ***still > need to add text for naming/use of transient digit maps. ***Also need to > make sure that if the MG fails to load a digit map, event notification > continues anyway. > > T9) Section 6.3.2.15: Re-added some of the text in digitMapDescriptor on > wildcarding. > > T10) After Section 6.3.3.8: Put/Delete removed - they are for future > consideration. > > T11) Section 6.3.2.10, 6.3.4, Annex A, B, C: Text vs binary: Annex A added > for modified ASN.1 that describes the protocol syntax, Annex B for the > ABNF, and the translation mechanism, and Annex C for the binary and the > binary translation mechanism. > > Agreements: ABNF remains normative. ASN.1 and compiler to compile into the > ABNF already written, will also be added as normative when they are > available. Sentence added: " This compiler is a living tool that will > likely be enhanced over time. To start, this tool should be tested to > verify that syntax can be compiled to the ABNF defined below. > > It is expected that industry forums would define profile for use of H.248 > and this would include whether text vs binary is used, as well as which > packages would be used, etc. In Section 6.3.4, sentences added: "MGCs > should support both encoding formats. MGs may support both formats." > > T12) Section 6.3.2.10, Annex D: A new proposal has been added for native > encoding of StreamDescriptors (SDP codepoint is still there). Changes made > to ABNF, reference made to SDP RFC, and to native encoding. ***Media > descriptor parameter and value tables put into Annex D - this annex still > needs work. ***Need to add in the sentence: "It is recommended that the > native encoding method for stream descriptors be used when encoding is > binary, and the SDP method be used when the protocol encoding is > text-based." > > T13) Section 6.4.1, 6.4.3.1,6.4.3.2, 6.4.3.3: Simplify transaction > semantics - changes to text and to ABNF (Annex B) made: removed the > concept of rollback on transactions - the document did not define how you > could roll back commands that actually cause physical changes on the MG, > e.g., sending of a signal, subtracting a termination from a context. > > It was decided that in fact, all a transaction does, is ensure that > commands occur in a particular order, and that no commands after a command > that fails, gets executed. In a TransactionAccept, need to say what a > response is - added sentence on this. In a TransactionReject, the command > that failed has error code, all the rest of the commands are not executed. > > T14) Section 6.4.1: Transaction figure - renamed "action" to "contextId". > > T15) Section 6.5: ***An example use case for text telephony will be added > (need to move all examples to an informative appendix). > > T16) Section 6.6: Transport: Proposed text added - it does not change > current transport functionality in draft-ietf-megaco-protocol-03.txt. > ***Editorial changes to this section will be suggested. > > T17) Section 6.7: Security section - some clarifications to text added - > you do not have to implement AH-in-Megaco/H.248 if you have IPSEC. Only > ONE of the two schemes is used at one time - if IPSEC is on both MGC and > MG, it is used, otherwise AH-in-Megaco/H.248 is used. Proposed text: "The > MG need only support IPSEC if it is capable. Otherwise it must support > AH-within-Megaco/H.248." ***Section too long, needs rewording. > > T18) Section 6.7: *** Security: request clarification on how the MGC knows > what the security mechanism is that the MG is using, and vice versa. > > T19) Section 7: Packages: a proposal for the writing of base packages, > along with proposals for the base packages will be turned into an > internet-draft and submitted for comment. > > T20) Section 7.2: Text added for IANA registration of packages. ***Text > still needs work. Agreed that IANA is the place to register ALL packages. > Suggestion that procedures should say that for ITU-T packages, we would > standardize the first few characters of the package name, and that a > public document describing the packages are not necessarily required. > > T21) Annex B: ***AuditCapabilities - need to allow multiple copies of > descriptors to be returned. ABNF needs to be updated. > > T22) Annex D, SDP: ***Need to be able to pass a QoS parameter to the MG. > (Note: Place to define this would be in the Package that defines > parameters to the LocalDescriptor. Also needed in SDP.) > > > > Editorial changes > ------------------------- > E1) Section 1: Have an ITU scope, and an IETF scope. Text that is there is > the ITU scope. > > E2) Architecture: Change architecture section back to Santiago determined > version of the text, and move it to H.323, instead of having it as an > annex to H.248. If architecture is moved out, all definitions (section 3) > that pertain to the architecture section and not the protocol, for > example, GK, can be deleted. (Note - there is still an issue of where the > architecture section will live, but in any case, it will NOT be in the > IETF version of the protocol). > > E3) ***Section 3: Add definition for stream, signal, event (not done yet). > > E4) Requirements section (old section 6) is removed. No need to reference > requirements doc in this document. > > E5) Section 6.1:Removed reference to "interface A". > > E6) Section 6.2.1, 6.2.3.1: Terminations Basic Concepts, and Overview - > some wording changes. For example, in the case of intercept for > wiretapping, a third termination in a context does not make the context a > conference bridge. Also conference replaced by association. > > E7) ***Section 6.2.2.1: Context general - wording changes, still needs > work. > > E8) Section 6.2.3.1 Change Audit to AuditValue just before Termination > Dynamics section. A few other changes to paragraph describing muxing. > > E9) section 6.2.3.5, 6.2.3.8: The "Support" columns in several tables have > been removed (not relevant now). This makes it look like those entire > tables have been changed - in fact it is just that a column has been > removed. > > E10) Section 6.3.2.12: Clarifications made to definition of "brief": "no > timeout value is needed". > > E11) Section 6.3.3: Clarified text in Command API describing the syntax > used. > > E12) Section 6.3.3.1: Add command - MediaDescriptor now marked as optional > in the text. > > E13) section 6.2.3.5: Some clarifications made in the section on > Termination Properties and Descriptors. > > E14) Section 6.2.3.7: Added section for templates, and marked it for > further study. > > E15) Section 6.2.3.8: Added section for scripting descriptors (marked for > further study). Make sure we can add them later to the protocol, e.g. make > > sure it can be used as an alternative way of describing digit maps. > > E16) Section 6.3.2.9: LocalDescriptor - mode not defined well - sentence > removed. > > E17) Section 6.3.2.11: ***Question: does loop in eventBuffer mean that > event is returned each time it occurs without having to resend an > EventsDescriptor - need to make text clearer. > > E18) Section 6.3.5: ***Need to renumber error codes (Need to discuss this > - may be better to leave them with the numbering they have.) > > E19) Section 7.2: ***Verify that all places that require IANA registration > in one place are grouped - error codes, packages, - (Events and signals do > NOT need to be registered - they are defined in packages). > > > > Questions > -------------- > Q1) What is the media type parameter of a termination? Is it in the stream > descriptor? or is it at the termination level? In describing the > muxDescriptor, it is stated that the media type of a termination included > in a mux is set to mux... > > Q2) Check semantics in embedded signals - what happens if one of the > signals fails - is the next signal applied or is it an error? > > Q3) Check that you can put two signals on a line and they are mixed. > > Q4) How does MGC to find out if MG supports digit maps? By just sending > them, and the MG ignores them if it wants to? > -------------- > > Nancy > > > -------------------------------------------------------------------------- > Nancy M. Greene > Internet & Service Provider Networks, Nortel Networks > T:514-271-7221 (internal:ESN853-1077) E:ngreene@nortelnetworks.com >

1 0

I will be back after September 7th
by Romeo.Zwart＠ATT.COM 08 Aug '99

08 Aug '99

Hi, I am currently on vacation. I will be back on September 7th. For any business that needs to be handled directly, you'd best send a message to The ICoE team: icoe(a)icoe.att.com Kind regards, Romeo Zwart AT&T Internetworking Center of Expertise

1 0

SG16 meeting on 30 September 1999
by Sakae OKUBO 08 Aug '99

08 Aug '99

Dear Q.12-14/16 experts, The following information on the subject matter is available at the ITU web site: Collective letter http://www.itu.int/itudoc/itu-t/com16/coll/006_ww7.doc Circular http://www.itu.int/itudoc/itu-t/com16/circ/207_ww7.doc Please note that the deadline for submitting Delayed Contributions is 20 September 1999. Best regards, Sakae OKUBO (Mr.) *********************************************************** Waseda Research Center Telecommunications Advancement Organization of Japan (TAO) 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 ***********************************************************

1 0

question belonging to h.245
by Christian Geng 06 Aug '99

06 Aug '99

Dear Sir or Madame, In the ITU-T Recommendation H.225.0 I found about h245Address: used in Alerting-UUIE, Call Proceeding-UUIE, Progress-UUIE, or Connect-UUIE: "This is a specific transport address on which the called endpoint or gatekeeper handling the call would like to establish H.245 signalling." used in Setup-UUIE: "This is a specific transport address on which the calling endpoint or gatekeeper handling the call would like to establish the H.245 signalling. This should only be provided by the sender if it is capable of handling H.245 procedures before receiving a CONNECT on the Call Signalling channel." My question is: I want to start H.245-Signaling after recept of Connect-message. Receiving the Connect-message, I get the transport address on which the called endpoint or gatekeeper handling the call would like to establish H.245 signalling. How can H.245-signaling run, if no h.245-address for calling endpoint or gatekeeper was defined before. I thought it has been done in Setup-UUIE. But what happens, if the sender of Setup-UUIE is not capable of handling H.245 procedures before receiving a CONNECT on the Call Signalling channel? Please can you help me to understand? I am looking specially for Gatekeeper-routet calls. Thank you very much. Cincerely Christian geng

1 0

Re: Article on H.323 Supplementary Services
by Paul Long 04 Aug '99

04 Aug '99

IEEE members (only) can access the article online at http://207.127.135.8/ci1/private/1999/jul/Korpi.html Paul Long Smith Micro Software, inc. -----Original Message----- From: Kaynam Hedayat [SMTP:Kaynam_Hedayat@PICTEL.COM] Sent: Wednesday, July 21, 1999 6:52 PM To: ITU-SG16(a)mailbag.cps.intel.com; h323implementors(a)imtc.org Subject: Article on H.323 Supplementary Services Hello everyone, I would like to bring your attention to a very good article by Vineet Kumar and Markku Korpi on H.323 Supplementary Services. The article appears in the July issue of the IEEE Communications Magazine with the title "Supplementary Services in the H.323 IP Telephony Network". Regards, Kaynam Hedayat ------------------------------------------------------------------------- for list subscription instructions, send email to h323implementors-request(a)imtc.org with text "info"

5 4

A paper on DMN
by S.G. Kim 04 Aug '99

04 Aug '99

Dear Experts: We are pleased to inform that a paper on Dynamic Multicast Network has been accepted for presentation at the IEEE TENCON'99 Conference in Cheju, Korea. If you interest in this topic, please send a e-mail. Thank you. Sincerly yours, SG Kim KTR&DG E-mail:sgk@kt.co.kr

1 0

Address Change Assistance Required
by Matthew Sickles 02 Aug '99

02 Aug '99

Why are you getting this message? Recently Nortel Networks changed the domain name to nortelnetworks.com. As a result of this change, mailing lists are consistently sending mail to some of our older domain addresses. In an attempt to reduce the mail volume to these legacy domains, we are trying to contact the administrators of list-servers for assistance. What can you do? If you could please review your address databases and change the addresses that have the following domain names to nortelnetworks.com: nt.com nortel.com nortel.ca bnr.ca bnr.co.uk nortel.ie northern.co.uk nortel.co.uk Why should you assist us? Beginning in October we will start sending an NDR (non-delivery report) for all messages sent to older domains. In preparing ahead of time, we can prevent hundreds and thousands of messages from being sent to an incorrect address. What if you do not find any addresses in your database? Please disregard this message. If in future mailings you keep getting messages from me and you are annoyed, please contact me and we can work out these issues one-on-one. What if you find older Nortel Networks domains in your database? Thank you so much for your assistance, send me an e-mail with the list of addresses and I will forward you a Thank You Gift from Nortel Networks for your assistance. We appreciate your help and always appreciate the co-operation of postmasters, mailing-list and list-server administrators. Sincerely, Matthew W. Sickles Sr. Project Manager Nortel Networks Messaging Service _____ Matthew W. Sickles Nortel Networks 919.303.6656 [ESN] 455.6656 [voice] 919.303.8850 [ESN] 455.8850 [fax]

1 0

apc1641 has been uploaded to incoming
by Dale L. Skran 31 Jul '99

31 Jul '99

This document concerns interoperability between H.323 systems using G.711 and SD/CNG. It is also applicable to any other system such as H.248/MEGACOP that uses G.711 and RTP. Dale Skran

1 0

Re: H.323 Annex E optional?
by Paul Long 31 Jul '99

31 Jul '99

Paul, Let me phrase it another way. Are you saying that a v3 EP _must_ support Annex E? Even though an EP indicates that it does not support it in its RRQ, can a GK force it to use Annex E? Paul Long Smith Micro Software, Inc. -----Original Message----- From: Paul E. Jones [mailto:paul.jones@TIES.ITU.INT] Sent: Thursday, July 29, 1999 10:59 PM To: ITU-SG16(a)MAILBAG.INTEL.COM Subject: Re: H.323 Annex E optional? Paul, The endpoint does not indicate a preference-- it is to indicate capability. The gatekeeper may force an endpoint to use Annex E by setting the flag in the RCF. Paul

2 1