- sg16-avd - lists.packetizer.com

APC document number
by Noriko Hosokawa 12 Jul '99

12 Jul '99

Dear Mr. Roy In response to your request, APC-1568 has been allocated to your contribution. APC-1568 Source: Lucent and AT&T > Title: H.245 Generic Capabilities Definition and H.225 Packetization Specification for the North American Cellular/PCS TDMA Vocoders (ACELP and US1) 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 *********************************************************** Documents for Q.12-14/16 Rapporteur meeting in Berlin (2-6 August 1999) ------------------------------------------------------------------------ APC- Source Title ------------------------------------------------------------------------ 1555 ITU-T SG8 Recommendation T.38 Indications in Recommendation H.245 (TD1/WP2 of the SG16 Santiago meeting) 1556 ITU-T SG11 Support of IN services for H.323 and other IP Network based terminals (TD4/WP2 of the SG16 Santiago meeting) 1557 ITU-T SG9 Draft New Rec. J.Web "Distribution of Sound and Television Programmes over the Internet "Webcasting"" (TD22/WP2 of the SG16 Santiago meeting) 1558 ITU-T SG2 Routing of Multimedia Connections When Interworking with PSTN, ATM, and IP Networks (TD24/GEN of the SG16 Santiago meeting) 1559 SG16 WP2 Proposed Organisation going forward to new Study Period 1560 Editor (E Martinez) Annex-H (User and Service Mobility in H.323) Proposed Architecture 1561 Editor (G Hellstrom) H.323 Annex G Text Conversation and Text SET 1562 L M Ericsson H.gcp Modification proposals for Text Conversation 1563 L M Ericsson First draft of a H.246 Annex for text conversation and text telephony 1564 L M Ericsson H.224 Modified for text conversation 1565 (P Jones) T.35 (1999) country codes 1566 Editor H.243 Draft revised ITU-T Recommendation H.243 (white doc.) 1567 L M Ericsson Generic Service ControlTransport 1568 Lucent and H.245 Generic Capabilities Definition and AT&T H.225 Packetization Specification for the North American Cellular/PCS TDMA Vocoders (ACELP and US1) ------------------------------------------------------------------------

1 0

remoteExtensionAddress field in SETUP and ACF ...........
by Aparna Saha 12 Jul '99

12 Jul '99

Hi, Why is the remoteExtensionAddress field in SETUP and FACILITY messages of H.225 specified as AliasAddress whereas the same field in ACF, LCF has been specified as SEQUENCE OF AliasAddress? The flexibility given by the ACF message has been taken away in the subsequent H.225 messages. For example, the sequence of the AliasAddress fields for a remote endpoint may include its E.164 address and its TransportAddress. However, when sending the SETUP message, the originating terminal can send only one of these. Now, when the intermediate Gateway (proxy or similar application) receives this message, either it would not know to whom to connect to (if the TransportAddress has not been specified) or its CDRs would not have the complete information (they require the E.164 address). Also, an additional overhead would be incurred in re-resolving the Alias! Is this an oversight or was it intentional? Could somebody let me know why such a decision had been taken? Regards, Aparna.

1 0

Information from the SG16 management
by Sakae OKUBO 11 Jul '99

11 Jul '99

Dear Q.12-14/16 experts, 1. Annex G to H.225.0 was approved. See the following Circular letter: http://www.itu.int/itudoc/itu-t/com16/circ/202_ww7.doc 2. H.GCP has been given the number H.248. 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

APC document number
by Noriko Hosokawa 11 Jul '99

11 Jul '99

Dear Mr.Espen.Skjaeran In response to your request, APC-1567 has been allocated to your contribution. APC-1567 Source: L M Ericsson Title : "Generic Service ControlTransport" 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 *********************************************************** Documents for Q.12-14/16 Rapporteur meeting in Berlin (2-6 August 1999) ------------------------------------------------------------------------ APC- Source Title ------------------------------------------------------------------------ 1555 ITU-T SG8 Recommendation T.38 Indications in Recommendation H.245 (TD1/WP2 of the SG16 Santiago meeting) 1556 ITU-T SG11 Support of IN services for H.323 and other IP Network based terminals (TD4/WP2 of the SG16 Santiago meeting) 1557 ITU-T SG9 Draft New Rec. J.Web "Distribution of Sound and Television Programmes over the Internet "Webcasting"" (TD22/WP2 of the SG16 Santiago meeting) 1558 ITU-T SG2 Routing of Multimedia Connections When Interworking with PSTN, ATM, and IP Networks (TD24/GEN of the SG16 Santiago meeting) 1559 SG16 WP2 Proposed Organisation going forward to new Study Period 1560 Editor (E Martinez) Annex-H (User and Service Mobility in H.323) Proposed Architecture 1561 Editor (G Hellstrom) H.323 Annex G Text Conversation and Text SET 1562 L M Ericsson H.gcp Modification proposals for Text Conversation 1563 L M Ericsson First draft of a H.246 Annex for text conversation and text telephony 1564 L M Ericsson H.224 Modified for text conversation 1565 (P Jones) T.35 (1999) country codes 1566 Editor H.243 Draft revised ITU-T Recommendation H.243 (white doc.) 1567 L M Ericsson Generic Service ControlTransport ------------------------------------------------------------------------

1 0

Re: 14TD058
by Matt Holdrege 10 Jul '99

10 Jul '99

The meeting runs from July 21-29, but remember that TIPHON has a joint meeting with SPS3 on the 20th. You should make your case there. At 04:47 AM 7/9/99 -0400, Edgar Martinez [1] wrote: >Matt, > >Can we get more details on the meeting dates start and end date. >I am attending a SG16 rapporteur's meeting in Berlin from Aug. 2-6. We are >looking at the same Liaison statement that SG11/Q5 has provide >to TIPHON. Basically I asked SG16 to use the TIPHON reference architecture >in the response back to SG11/Q5. We will have a final reply from SG16 to SG11 >by the end of the Berlin meeting. So I will like to keep SG16 informed. > >Regards, >Ed > >Matt Holdrege wrote: > > > I tried to include TIPHON architectural issues in the 5/11 architecture at > > the last 5/11 meeting. We couldn't come to a full agreement during the > > meeting and asked for contributions for the next rapporteur's meeting. > > > > Unfortunately the next 5/11 meeting is during the next TIPHON meeting. I > > was thinking about leaving TIPHON early and going to the 5/11 meeting which > > starts on the 21st. But I'm not sure of my schedule yet. > > > > If anyone in TIPHON is going to the WP4/11 meeting, let us know if you can > > represent our architecture. > > > > At 03:46 PM 7/8/99 -0400, Edgar Martinez [1] wrote: > > >Dear all, > > > > > >The following document has been uploaded onto Inbox: > > > > > >Document: > > >TITLE:Clarification on where the SG11/Q5 IN components > > > may fit in the Tiphon Reference Architecture. > > > > > >Regards, > > >Ed > > > > > > > > >-- > > >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/ > > > > > >------------------------------------------------------------------- > > >Mail archive for TIPHON 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/

1 0

Re: [Fwd: [Fwd: [Fwd: Re: 14TD058]]]
by Edgar Martinez [1] 09 Jul '99

09 Jul '99

John, see comments below: John Talbot wrote: > Edgar, > > Could you clarify whether your contribution represents an agreed TIPHON > position. > My contribution is a request for Clarification on where the SG11/Q5 IN or in general where does IN components fit in the Tiphon IP Reference Architecture. So we can get some work done before we meet in Berlin. > > Also, it should also be noted that the ITU-T SG11 functional architecture > which you refer to in your contribution does not reflect the decomposed > media gateway architecture. The diagram I provided in 14TD058 shows the SG, MGC and MGW TIPHON's decomposed gateway. In SG11/Q5 they refer to the old C Ref. on a non-decomposed GW. This the type of understanding SG11 has and we need to work together to get agreement and bring very one upto date. > The potential impact this would have on the > location of the CCF does not appear to have been considered by the ITU-T > liaison. The CCF that SG11/Q5 provided in the liaison statement diagram shows the CCF on the IN side, the CCF for IN suspends the calls and/or report events to the SSF. Looking at it from the Tiphon or Megaco IP side the MGW provides the same CCF function using the N interface to report to the MCG. From the SG11/Q5 diagram it is referred to as Call/Bearer (C/B) GF with a C Ref. point to H.323 GK F. I think the information we get from TIPHON and SG16 will help to work out these misunderstandings. Regards, Ed > > > Cheers > > John Talbot > Nortel Networks > > > -----Original Message----- > > From: Edgar Martinez [1] [SMTP:martinze@CIG.MOT.COM] > > Sent: 09 July 1999 10:17 > > To: ITU-SG16(a)MAILBAG.INTEL.COM > > Subject: [Fwd: [Fwd: [Fwd: Re: 14TD058]]] > > > > Dear All, > > > > Some TIPHON work going on to address Q5/11 > > Requirements for the Functional Architecture > > for IN support of IP-networks. Tiphon-14 meeting > > is from July 18-24. The Documents are in: > > > > http://docbox.etsi.org/tech-org/tiphon/Document/tiphon/05-9907-Amsterdam/ > > > > If you are interested. > > > > Regards, > > Ed > > > > -------- Original Message -------- > > Subject: Re: 14TD058 > > Date: Fri, 09 Jul 1999 04:47:24 -0400 > > From: "Edgar Martinez [1]" <martinze(a)cig.mot.com> > > Organization: NSS-NAT > > To: Matt Holdrege <matt(a)ascend.com> > > CC: TIPHON(a)LIST.ETSI.FR > > References: <3782F084.E48DC7D5(a)cig.mot.com> > > <199907090807.DAA01209(a)alba.cig.mot.com> > > > > Matt, > > > > Can we get more details on the meeting dates start and end date. > > I am attending a SG16 rapporteur's meeting in Berlin from Aug. 2-6. > > We are looking at the same Liaison statement that SG11/Q5 > > has provided to TIPHON. Basically, I asked SG16 to use the T > > IPHON reference architecture in the response back to SG11/Q5. > > We will have a final reply from SG16 to SG11 > > by the end of the Berlin meeting. > > So I will like to keep SG16 informed. > > > > Regards, > > Ed > > > > Matt Holdrege wrote: > > > > > I tried to include TIPHON architectural issues in the 5/11 architecture > > at > > > the last 5/11 meeting. We couldn't come to a full agreement during the > > > meeting and asked for contributions for the next rapporteur's meeting. > > > > > > Unfortunately the next 5/11 meeting is during the next TIPHON meeting. I > > > was thinking about leaving TIPHON early and going to the 5/11 meeting > > which > > > starts on the 21st. But I'm not sure of my schedule yet. > > > > > > If anyone in TIPHON is going to the WP4/11 meeting, let us know if you > > can > > > represent our architecture. > > > > > > > >At 03:46 PM 7/8/99 -0400, Edgar Martinez [1] wrote: > > > >Dear all, > > > > > > > >The following document has been uploaded onto Inbox: > > > > > > > >Document: > > > >TITLE:Clarification on where the SG11/Q5 IN components > > > > may fit in the Tiphon Reference Architecture. > > > > > > > >Regards, > > > >Ed > > > > > > > > > > > >-- > > > >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/ > > > > > > > >------------------------------------------------------------------- > > > >Mail archive for TIPHON 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/ -- 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: [Fwd: [Fwd: [Fwd: Re: 14TD058]]]
by John Talbot 09 Jul '99

09 Jul '99

Edgar, Could you clarify whether your contribution represents an agreed TIPHON position. Also, it should also be noted that the ITU-T SG11 functional architecture which you refer to in your contribution does not reflect the decomposed media gateway architecture. The potential impact this would have on the location of the CCF does not appear to have been considered by the ITU-T liaison. Cheers John Talbot Nortel Networks > -----Original Message----- > From: Edgar Martinez [1] [SMTP:martinze@CIG.MOT.COM] > Sent: 09 July 1999 10:17 > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: [Fwd: [Fwd: [Fwd: Re: 14TD058]]] > > Dear All, > > Some TIPHON work going on to address Q5/11 > Requirements for the Functional Architecture > for IN support of IP-networks. Tiphon-14 meeting > is from July 18-24. The Documents are in: > > http://docbox.etsi.org/tech-org/tiphon/Document/tiphon/05-9907-Amsterdam/ > > If you are interested. > > Regards, > Ed > > -------- Original Message -------- > Subject: Re: 14TD058 > Date: Fri, 09 Jul 1999 04:47:24 -0400 > From: "Edgar Martinez [1]" <martinze(a)cig.mot.com> > Organization: NSS-NAT > To: Matt Holdrege <matt(a)ascend.com> > CC: TIPHON(a)LIST.ETSI.FR > References: <3782F084.E48DC7D5(a)cig.mot.com> > <199907090807.DAA01209(a)alba.cig.mot.com> > > Matt, > > Can we get more details on the meeting dates start and end date. > I am attending a SG16 rapporteur's meeting in Berlin from Aug. 2-6. > We are looking at the same Liaison statement that SG11/Q5 > has provided to TIPHON. Basically, I asked SG16 to use the T > IPHON reference architecture in the response back to SG11/Q5. > We will have a final reply from SG16 to SG11 > by the end of the Berlin meeting. > So I will like to keep SG16 informed. > > Regards, > Ed > > Matt Holdrege wrote: > > > I tried to include TIPHON architectural issues in the 5/11 architecture > at > > the last 5/11 meeting. We couldn't come to a full agreement during the > > meeting and asked for contributions for the next rapporteur's meeting. > > > > Unfortunately the next 5/11 meeting is during the next TIPHON meeting. I > > was thinking about leaving TIPHON early and going to the 5/11 meeting > which > > starts on the 21st. But I'm not sure of my schedule yet. > > > > If anyone in TIPHON is going to the WP4/11 meeting, let us know if you > can > > represent our architecture. > > > > >At 03:46 PM 7/8/99 -0400, Edgar Martinez [1] wrote: > > >Dear all, > > > > > >The following document has been uploaded onto Inbox: > > > > > >Document: > > >TITLE:Clarification on where the SG11/Q5 IN components > > > may fit in the Tiphon Reference Architecture. > > > > > >Regards, > > >Ed > > > > > > > > >-- > > >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/ > > > > > >------------------------------------------------------------------- > > >Mail archive for TIPHON 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/

1 0

Call_id for H.245 messages
by Sunil Mahajan 09 Jul '99

09 Jul '99

Hi, We are new to this list and need some clarification related to H.245 call signaling on TCP/IP channel.. Considering a separate H.245 connection is required per call implies that each connection shall have a separate port to associate H.245 messages with its call. This requires the endpoint application to maintain an association between ports and the call_id/call_ref value. Isn't it useful to have some correlation_id or call_ref (or call_id) value in each of the H.245 messages to associate H.245 messages with call instances at the endpoints (gateways). Regards, Ravi Kiran Sunil Mahajan

1 0

[Fwd: [Fwd: [Fwd: Re: 14TD058]]]
by Edgar Martinez [1] 09 Jul '99

09 Jul '99

Dear All, Some TIPHON work going on to address Q5/11 Requirements for the Functional Architecture for IN support of IP-networks. Tiphon-14 meeting is from July 18-24. The Documents are in: http://docbox.etsi.org/tech-org/tiphon/Document/tiphon/05-9907-Amsterdam/ If you are interested. Regards, Ed -------- Original Message -------- Subject: Re: 14TD058 Date: Fri, 09 Jul 1999 04:47:24 -0400 From: "Edgar Martinez [1]" <martinze(a)cig.mot.com> Organization: NSS-NAT To: Matt Holdrege <matt(a)ascend.com> CC: TIPHON(a)LIST.ETSI.FR References: <3782F084.E48DC7D5(a)cig.mot.com> <199907090807.DAA01209(a)alba.cig.mot.com> Matt, Can we get more details on the meeting dates start and end date. I am attending a SG16 rapporteur's meeting in Berlin from Aug. 2-6. We are looking at the same Liaison statement that SG11/Q5 has provided to TIPHON. Basically, I asked SG16 to use the T IPHON reference architecture in the response back to SG11/Q5. We will have a final reply from SG16 to SG11 by the end of the Berlin meeting. So I will like to keep SG16 informed. Regards, Ed Matt Holdrege wrote: > I tried to include TIPHON architectural issues in the 5/11 architecture at > the last 5/11 meeting. We couldn't come to a full agreement during the > meeting and asked for contributions for the next rapporteur's meeting. > > Unfortunately the next 5/11 meeting is during the next TIPHON meeting. I > was thinking about leaving TIPHON early and going to the 5/11 meeting which > starts on the 21st. But I'm not sure of my schedule yet. > > If anyone in TIPHON is going to the WP4/11 meeting, let us know if you can > represent our architecture. > >At 03:46 PM 7/8/99 -0400, Edgar Martinez [1] wrote: > >Dear all, > > > >The following document has been uploaded onto Inbox: > > > >Document: > >TITLE:Clarification on where the SG11/Q5 IN components > > may fit in the Tiphon Reference Architecture. > > > >Regards, > >Ed > > > > > >-- > >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/ > > > >------------------------------------------------------------------- > >Mail archive for TIPHON 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/

1 0

Re: H.323v3 for decision in September
by Callaghan, Robert 09 Jul '99

09 Jul '99

Dale, This discussion has introduced a degree of confusion. The meeting report from Santiago clearly states that H.323v3 and H.225.0v3 will be decided in 2/00. Now we are discussing a decision of 9/99. Which is correct? Are all the additions people feel are needed immediately going to be provided in Berlin for inclusion in v3? Will be have a full meeting including Q.13, Wp2, and SG16 in September? If so, how many days are scheduled for the meeting? Another words --- What's happening. Bob ------------------------------------------------------------------ Robert Callaghan Siemens Information & Communication Networks Enterprise Switching Networks, Architecture Tel: +1.561.997.3756 Fax: +1.561.997.3403 Email: Robert.Callaghan(a)ICN.Siemens.com ------------------------------------------------------------------ -----Original Message----- From: Paul E. Jones [mailto:paul.jones@TIES.ITU.INT] Sent: Tuesday, June 29, 1999 11:38 AM To: ITU-SG16(a)mailbag.cps.intel.com Subject: Re: H.323v3 for decision in September Pete, I would venture to say that, given the nature of this work, it would not be included in H.323v3. However, it could certainly be included in H.323v4, which, as I noted below, will be determined in February. There are actually a number of new features people want to add to H.323, which is one reason for adjusting the schedule. By deciding v3 in September, we can focus our attention on v4, which will give us the time to enrich H.323 in a reasonable timeframe. It would be nearly impossible to properly add all of the new features to v3 between now and February. Would you be willing to bring that document as a contribution toward v4? Paul ----- Original Message ----- From: Pete Cordell <pete(a)TECH-KNOW-WARE.COM> To: <ITU-SG16(a)MAILBAG.INTEL.COM> Sent: Tuesday, June 29, 1999 4:01 AM Subject: Re: H.323v3 for decision in September > 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 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 > > >

2 1

APC document number
by Noriko Hosokawa 08 Jul '99

08 Jul '99

Dear Mr. Luthi In response to your request, APC-1566 has been allocated to your contribution. APC-1566 > Source: Editor H.243 > Title: Draft revised ITU-T Recommendation H.243 (white doc.) > Purpose: Draft > Question: 14 > 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 *********************************************************** Documents for Q.12-14/16 Rapporteur meeting in Berlin (2-6 August 1999) ------------------------------------------------------------------------ APC- Source Title ------------------------------------------------------------------------ 1555 ITU-T SG8 Recommendation T.38 Indications in Recommendation H.245 (TD1/WP2 of the SG16 Santiago meeting) 1556 ITU-T SG11 Support of IN services for H.323 and other IP Network based terminals (TD4/WP2 of the SG16 Santiago meeting) 1557 ITU-T SG9 Draft New Rec. J.Web "Distribution of Sound and Television Programmes over the Internet "Webcasting"" (TD22/WP2 of the SG16 Santiago meeting) 1558 ITU-T SG2 Routing of Multimedia Connections When Interworking with PSTN, ATM, and IP Networks (TD24/GEN of the SG16 Santiago meeting) 1559 SG16 WP2 Proposed Organisation going forward to new Study Period 1560 Editor (E Martinez) Annex-H (User and Service Mobility in H.323) Proposed Architecture 1561 Editor (G Hellstrom) H.323 Annex G Text Conversation and Text SET 1562 L M Ericsson H.gcp Modification proposals for Text Conversation 1563 L M Ericsson First draft of a H.246 Annex for text conversation and text telephony 1564 L M Ericsson H.224 Modified for text conversation 1565 (P Jones) T.35 (1999) country codes 1566 Editor H.243 Draft revised ITU-T Recommendation H.243 (white doc.) ------------------------------------------------------------------------

1 0

Re: Defining what is a TCS=0 for the IG
by Pete Cordell 08 Jul '99

08 Jul '99

Dear All, We are happy to go with an empty TCS being just the protocol identifier and sequence number AS LONG AS we can send immediately prior to that a cap set delta that removes all existing capabilities WITHOUT waiting for it to be acked. i.e. something like: EP A EP B -- TCS delta to zero --> -- TCS prot and seq only --> ..(transmission delay etc)... <-- TCS Ack for delta --- <-- TCS Ack for prot and seq only -- We want to do this as we feel that the removal of the capabilities should result in the majority of the TCS0 functionality on well behaved H.245 endpoints that don't know about TCS0 (although there is an issue as to whether there are any such terminals!) whereas the other form of TCS will have no effect. If this is acceptable to people, then I will write up some text to say that an empty cap set consists only of protocol identifier and sequence number. Regards, Pete ============================================= Pete Cordell pete(a)tech-know-ware.com =============================================

1 0

APC document numbers
by Sakae OKUBO 08 Jul '99

08 Jul '99

Dear Mr. Hellstrom, Dear Mr. Jones, GH> Please register the following documents for the Berlin meeting, GH> and return APC numbers. APC-1561, 1562, 1563 have been allocated. GH> Note that the H.224 document is probably handled by Q11. Do they have GH> their own document handling? Mr. Geary will also allocate a Q11-J-nn number to your contribution, I expect. APV-1561--------------------------------- > Title: H.323 Annex G Text Conversation and Text SET. > > Source: Gunnar Hellstr $BSN (B, L M Ericsson > > Abstract: The Text Annex to H.323 with modifications reflecting progress in > IETF about RTP Payload format and genreral editorials. > > Purpose: Proposal for white doc. > > ---------------------------------------------------------------------------- APC-1562--------------------------------- > Title: H.gcp Modification proposals for Text Conversation. > > Source: Gunnar Hellstr $BSN (B, L M Ericsson > > Abstract: Modification proposals to H.gcp to define text conversation and > text telephone support. > > Purpose: Proposal to include in white doc. > ---------------------------------------------------------------------------- APC-1563--------------------------------- > Title: H.246 Annex Text > > Source: Gunnar Hellstr $BSN (B, L M Ericsson > > Abstract: First draft of a H.246 Annex for text conversation and text > telephony > > Purpose: Discussion > ---------------------------------------------------------------------------- APC-1564--------------------------------- > Title: H.224 Modified for text conversation > > Source: Mickey Nasiri, L M Ericsson > > Abstract: White doc proposal for H.224 with added standard client ID for > T.140 text and correction for an old data syntax description error. > > Purpose: Proposal > ---------------------------------------------------------------------------- PJ> I would like to request an APC number for a contribution PJ> on the topic of addressing T.35 (1999) country codes. APC-1565 has been allocated to your contribution. 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 *********************************************************** Documents for Q.12-14/16 Rapporteur meeting in Berlin (2-6 August 1999) ------------------------------------------------------------------------ APC- Source Title ------------------------------------------------------------------------ 1555 ITU-T SG8 Recommendation T.38 Indications in Recommendation H.245 (TD1/WP2 of the SG16 Santiago meeting) 1556 ITU-T SG11 Support of IN services for H.323 and other IP Network based terminals (TD4/WP2 of the SG16 Santiago meeting) 1557 ITU-T SG9 Draft New Rec. J.Web "Distribution of Sound and Television Programmes over the Internet "Webcasting"" (TD22/WP2 of the SG16 Santiago meeting) 1558 ITU-T SG2 Routing of Multimedia Connections When Interworking with PSTN, ATM, and IP Networks (TD24/GEN of the SG16 Santiago meeting) 1559 SG16 WP2 Proposed Organisation going forward to new Study Period 1560 Editor (E Martinez) Annex-H (User and Service Mobility in H.323) Proposed Architecture 1561 Editor (G Hellstrom) H.323 Annex G Text Conversation and Text SET 1562 L M Ericsson H.gcp Modification proposals for Text Conversation 1563 L M Ericsson First draft of a H.246 Annex for text conversation and text telephony 1564 L M Ericsson H.224 Modified for text conversation 1565 (P Jones) T.35 (1999) country codes ------------------------------------------------------------------------

1 0

Moving on
by Chris Purvis 07 Jul '99

07 Jul '99

All, I will be leaving Madge Networks at the end of the week, and with it (at least for the moment) the H.323 arena - so don't be surprised that I'll no longer be posting to these lists! Although I've enjoyed working with you all, a new opportunity beckons... Regards, Chris -- Until Friday 9th July 1999: 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 >From Monday 12th July 1999: Dr Chris Purvis - Development Manager ISDN Communications Ltd, The Stable Block, Ronans, Chavey Down Road, Winkfield Row, Berkshire RG42 6LY. ENGLAND Phone: +44 1344 899 007 email: Chris.Purvis(a)isdn-comms.co.uk ------------------------------------------------------------------------- for list subscription instructions, send email to h323implementors-request(a)imtc.org with text "info"

2 1

Re: H.323v3 for decision in September - Annex G Text
by Michael Sung 07 Jul '99

07 Jul '99

How do I unsubscribe from this list? -----Original Message----- From: Gunnar Hellstrom [mailto:gunnar.hellstrom@OMNITOR.SE] Sent: Tuesday, June 29, 1999 2:59 PM To: ITU-SG16(a)MAILBAG.INTEL.COM Subject: Re: H.323v3 for decision in September - Annex G Text It might be wise to tie in Annex G Text Conversation and Text SET with a few words into the body of H.323 V3. Do we have a policy to introduce Annexes with some text in the main body or can it hang loose as it does now? I am not ready with the RTP payload type for text in IETF until later this year, and was aiming at a February decision for H.323 V3 with Annex G. Regards Gunnar Hellström At 20:20 1999-06-28 -0400, Paul E. Jones wrote: >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 > > ----------------------------------------------- Gunnar Hellstrom LM Ericsson E-mail gunnar.hellstrom(a)omnitor.se Tel +46 751 100 501 fax +46 8 556 002 06

1 0

Packet Video 2000 - Call for Papers
by pv2000 07 Jul '99

07 Jul '99

===================================================================== PRELIMINARY CALL FOR PAPERS ====================================================================== PACKET VIDEO 2000 The 10th International Packet Video Workshop Date: 1-2 May 2000 Venue: Forte Village Resort, Cagliari, Italy Web site: http://www.diee.unica.it/pv2000/ Organization: Francesco G.B. De Natale and Daniele D. Giusto, University of Cagliari Technical sponsors: EURASIP, IEEE Signal Processing Society (IMDSP and MMSP Technical Committees) ====================================================================== The tenth edition of the International Packet Video Workshop (PV 2000) will be held at the Forte Village Resort, Cagliari, Italy. The workshop is devoted to present technological advancements and innovations in video communications over packet networks, in particular, the Internet. Packet Video Workshops have been unique in providing a common ground for people from video coding and networking fields. Presentations on theory and practice, standards activities, and business and consumer applicatons are encouraged. We cordially invite you to take part in this workshop by submitting your work and look forward to seeing you in Sardinia in May 2000 for what will be a most rewarding and exciting experience! ====================================================================== TECHNICAL PROGRAM Chairs: Leonardo Chiariglione, CSELT, Turin Maurizio Decina, Cefriel and Polytechnic of Milan The technical program of Packet Video 2000 will consist of invited talks, submitted paper presentations, poster sessions and demos Topics of interest include, but are not limited to: Video processing and transmission Video streaming over the Internet Network adaptive video coding and transport Packetized video for home LANs Packetized video for wireless/mobile systems Layered coding for error resilience and heterogeneous networks Packet loss resilient coding and transport Terminal and server architectures for Internet TV Efficient transcoding for heterogeneous networks Congestion control Error concealment Pre and post-processing for picture quality enhancement Statistical multiplexing for greater network and terminal utilization Traffic shaping for efficient network and terminal utilization Interstream synchronization for multiple video presentations Performance modeling and evaluation Picture quality evaluation Rate control for VBR video International Standards: MPEG-4, MPEG-7, H.263, RTP, RTSP, SIP, SDP Multicasting, MBONE applications Implementations and commercial applications ====================================================================== Best Paper Award The author of the best paper will receive a $250 prize and a diploma suitable for framing. ====================================================================== Please submit an electronic manuscript written in HTML, not exceeding 7 Mbytes and 10 printed pages. We will produce a CD-ROM containing all the accepted papers. Electronic components accompanying your submission are strongly encouraged. Submit your work in ONE of the following forms: 1) a set of HTML files organized in a single directory OR 2) as a URL (you must have the rights to all the material there, and guarantee stability of the files until the conference). to: pv2000(a)diee.unica.it Detailed instructions for authors and help with manuscript preparation with HTML can be found on the conference web page. Deadlines: paper submission: December 15, 1999, notification of acceptance: February 29, 2000 final paper delivery: March 31, 2000 ====================================================================== Publication and local arrangements Luigi Atzori Dept. of Electrical and Electronic Engineering University of Cagliari Piazza d'Armi, 19 09123 Cagliari, Italy gigi(a)diee.unica.it

1 0

Re: Moving on
by Roy, Radhika R, ALCOO 07 Jul '99

07 Jul '99

Hi Chris: We have been delighted to see the contributions that you made during your participation in H.323. However, I am sad to see that you are leaving the H.323 arena. With a hope to have a bright career in your new opportunity, Radhika > -----Original Message----- > From: Chris Purvis [SMTP:Chris.Purvis@MADGE.COM] > Sent: Wednesday, July 07, 1999 6:03 AM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: Moving on > > All, > > I will be leaving Madge Networks at the end of the week, and with it (at > least for the moment) the H.323 arena - so don't be surprised that I'll no > longer be posting to these lists! > Although I've enjoyed working with you all, a new opportunity beckons... > > Regards, > Chris > -- > Until Friday 9th July 1999: > 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 > > From Monday 12th July 1999: > Dr Chris Purvis - Development Manager > ISDN Communications Ltd, The Stable Block, Ronans, Chavey Down Road, > Winkfield Row, Berkshire RG42 6LY. ENGLAND > Phone: +44 1344 899 007 email: Chris.Purvis(a)isdn-comms.co.uk

1 0

Docuement download
by Edgar Martinez [1] 07 Jul '99

07 Jul '99

2 1

Use of GIT instead of B-HLI in H.310 and H.323 Annex C
by Sakae OKUBO 03 Jul '99

03 Jul '99

Dear Mr. Hedayat, Dear Mr. Audet, FA> I'd support this as well: some additional text regarding backward FA> compatibility (use of GIT instead of B-HLI) is required. Along the FA> lines of what was done for H.310 which went throught the same FA> change. What happened to H.310 as I recollect are as follows: 1. H.310 Version 1 (approved in November 1996) Use of GIT was included in the Q.2931 SETUP message table for the H.245 resource/correlation number to associate the logical channel and ATM VC. But GIT was noted as "under development". 2. H.310 V1 Implementors Guide approved in March 1997 As part of detailing and clarifying the use of DSS2 call signalling, it was specified that H.310 correlation ID (H.245 resourceID in the H222LogicalChannelParameters) shall be coded according to Q.2941.1 (GIT) in the Q.2931 SETUP message. At the same time, it was also specified that "Optionally, the H.310 correlationID may also be sent in the Broadband High Layer IE (B-HLI) as follows. ... In the case where either of the terminals do not support the GIT information element, the B-HLI information element shall be used to convey the H.310 correlationID." Appendix II for extended use of Q.2931 Release 1 describes how to use B-HLI for the H.310 Correlation ID with the note "These accommodations are provisional, the Generic Identifier Transport Information Element should be used to convey the H.310 correlation ID when the relevant Q.2931 specifications have been implemented." 3. H.310 Version 2, determined in February 1998 At this meeting, SG16 received a liaison statement from SG11 advising that the use of B-HLI for the purpose of conveying the H.310 Correlation ID was inappropriate. Hence in the process of integrating the H.310 V1 Impelmentors Guide into draft H.310 V2, the option of B-HLI use was totally deleted. Instead, according to the SG11 suggestion, the following one line sentence was added: "Optionally, the H.310 correlationID may also be sent in the user-to-user information IE." However, there is no description of how to use the user-to-user information IE for this purpose. 4. H.310 Version 2, decided in September 1998 Compared to Version 1, the following were added: - H.310 V1 IG except for the above mentioned optional B-HLI use for H.310 Correlation ID - Correction approved in February 1998 for the H.320/H.321 stack for the RAST-5 terminal - Procedures for the interworking procedures between RAST-1 and RAST-5 terminals which were developed in the experts group work. I hope this information may be of some use for considering the text for H.323 Annex C regarding the use of GIT instead of B-HLI, though the situations appears to be not completely the same between H.310 and H.323 Annex C. KH> If the additional text is approved in Berlin will it KH> be possible to add it to H.323 V3? We should respect the guideline that officially the Rapporteur meeting cannot re-address the matters in the White Contribution for decision (in the spirit of determination based on maturity). However, the rule allows that based on written contributions SG16 meeting in September may modify the draft Recommendation submitted as White Contribution. Once the consensus is obtained at the Berlin meeting, a delayed contribution should be submitted by Administration(s) or ITU-T Sector member organization(s). 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

Re: H.323v3 for decision in September
by Pete Cordell 02 Jul '99

02 Jul '99

Paul, The reason for proposing the extensibility framework changes is to make future additions to H.323 easier. Indeed, V4 extensions could be implemented as annexes which exploit the extensibility framework. They would then have a standardisation cycle of their own, and each new implementation of a version is not loaded with baggage that is potentially not of interest to it. Therefore post-poning them to V4 is highly un-desirable. People have made contribution plans based on the previous dead-lines. Quickly dropping a half-baked version of H.323 that then forces as to wait another 2 years for any revisions makes little sense. 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 16:52 Subject: Re: H.323v3 for decision in September >Pete, > >I would venture to say that, given the nature of this work, it would not be >included in H.323v3. However, it could certainly be included in H.323v4, >which, as I noted below, will be determined in February. > >There are actually a number of new features people want to add to H.323, >which is one reason for adjusting the schedule. By deciding v3 in >September, we can focus our attention on v4, which will give us the time to >enrich H.323 in a reasonable timeframe. It would be nearly impossible to >properly add all of the new features to v3 between now and February. > >Would you be willing to bring that document as a contribution toward v4? > >Paul > >----- Original Message ----- >From: Pete Cordell <pete(a)TECH-KNOW-WARE.COM> >To: <ITU-SG16(a)MAILBAG.INTEL.COM> >Sent: Tuesday, June 29, 1999 4:01 AM >Subject: Re: H.323v3 for decision in September > > >> 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 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 >> > >> >

2 1

Q.16-17/16 Rapporteur meeting
by Sakae OKUBO 02 Jul '99

02 Jul '99

Dear Q.12-14/16 experts, Attached please find the notice of the subject meeting held in Geneva during 25-27 August 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 *********************************************************** Subject: Convocation of the Rapporteur's meeting on Q16 and 17/16 Date: Thu, 1 Jul 1999 15:18:37 +0200 Importance: high X-Priority: 1 MIME-Version: 1.0 Dear Colleagues, As agreed at Santiago a Rapporteur meeting regarding Qs 16 and 17/16 will take place in Geneva at the ITU premises from 25 to 27 August 1999 (inclusive), with the following agenda: 1. Opening 2. Approval of the agenda 3. Discussion/proposals a) for the project "MEDIA COM 2004" b) possible information to TSAG c) communication with other SGs 4. Preparation of the meeting of IP experts of SG 13 (Geneva, 30 August - 10 September 1999) 5. GII projects under the responsibility of SG 16 7. Miscellaneous 8. Future work 9. Closing The meeting will open at 09.30 hours on the first day. Detailed information concerning the meeting rooms will be displayed on screens at the entrances to ITU headquarters. The results of this meeting will also serve as preparation for the review of Questions for the next study period. This activity will very likely take place in a meeting organized on 30 September (afternoon session), 1 October and 2 October (if needed), with the participation of the management of SG 16 and the Rapporteurs. Contributions to the August meeting should reach TSB as soon as possible and will be posted in Q16/16 and Q17/16 informal ftp area. A copy of contributions should be sent to the Rapporteur Mr. M. Matsumoto at e-mail: matumoto(a)tom.comm.waseda.ac.jp Would you be so kind as to confirm your participation to the August meeting of Q16 and 17/16 by return e-mail, and in any case prior to 15 August 1999. Yours faithfully Fabio Bigi TSB Senior Counsellor

1 0

Re: PDU & ASN parser
by Pete Cordell 01 Jul '99

01 Jul '99

Dear All, I support the principle that only one H.225 call signalling message should be sent per TPKT. Firstly I believe it was agreed between early implementers that this is the way they would work. Secondly, even though it is possible to send multiple PER messages per TPKT there are other reasons why this is not totally desirable. In our case of working on a high volume GK, we only need to process a fraction of H.245 messages. If there is only one message per TPKT we can easily work out what the message is by looking at the first few bytes. However, if there are multiple messages per packet we have no choice but to decode each and every message. In most cases this represents a totally unnecessary processing overhead and is therefore best avoided. Pete ============================================= Pete Cordell pete(a)tech-know-ware.com ============================================= -----Original Message----- From: Paul Long <Plong(a)SMITHMICRO.COM> To: 'h323implementors(a)imtc.org' <h323implementors(a)imtc.org> Cc: ITU-SG16(a)mailbag.cps.intel.com <ITU-SG16(a)mailbag.cps.intel.com> Date: 30 June 1999 17:53 Subject: RE: PDU & ASN parser >Guntram, > >I raised this issue over a year ago. In addition, H.225.0 does not address >this issue regarding RAS (it does regarding call signaling), so I suppose one >could pack multiple RAS messages per unreliable-transport PDU. As you say, it >doesn't make sense to pack messages, and I don't think anyone does it. We >should probably add something like the following to section 6.1 of the next >revision of H.225.0. > >"When messages are sent on the H.225.0 RAS channel, only one whole message >shall be sent within the boundaries defined by the transport; there shall be >no fragmentation of H.225.0 RAS messages across transport PDUs." > >We should also insert the indicated text, below, into existing text in the >same section. > >"When messages are sent on the reliable H.245 control channel, >>>exactly one >message should be sent but<<< more than one message may be sent within the >boundaries defined by the reliable transport PDU as long as whole messages are >sent;" > >Paul Long >Smith Micro Software, Inc. > > -----Original Message----- > From: Guntram Diehl [SMTP:gdiehl@innovaphone.com] > Sent: Wednesday, June 30, 1999 4:14 AM > To: 'Bancroft Scott'; 'Srikanth Nayani' > Cc: 'h323implementors(a)imtc.org' > Subject: RE: PDU & ASN parser > > Yes this can be done, but does any implementation actually do it? Why > would anyone want to do this, it just saves 4 bytes tpkt header per > additional H.245 message and it does not change the fragmentation of >the > whole thing by IP. > > Or is there another reason why this was specified in the standard this > way? > > Guntram > > -----Original Message----- > From: Bancroft Scott [mailto:baos@OSS.COM] > Sent: Wednesday, June 30, 1999 3:54 AM > To: Srikanth Nayani > Cc: h323implementors(a)imtc.org > Subject: Re: PDU & ASN parser > > > On Tue, 29 Jun 1999, Srikanth Nayani wrote: > > > In the H.225 document chapter 6 mentions that multiple messages >can be > > sent over the reliable H.245 control channel within the boundaries >of the > > reliable transport channel . Does that mean that two H.245 PDUs >encoded > > using PER and whose total encoded length is within the boundary of >the > > H.245 TCP channel can be merely concatenated and sent as a single >payload > > of the H.245 TCP channel. > > If so how does a ASN.1 decoder know that there are two >messages in the > > payload and the offset at which the second message starts. > > An PER decoder does not know that there are two messages in the >payload. > It does know where the first message ends, so the location of the next > message can be derived from this knowledge. > > >------------------------------------------------------------------------ > -- > Bancroft Scott Toll Free > :1-888-OSS-ASN1 > Open Systems Solutions, Inc. > International:1-609-987-9073 > baos(a)oss.com Tech Support > :1-732-249-5107 > http://www.oss.com Fax > :1-732-249-4636 > > >------------------------------------------------------------------------ > - > for list subscription instructions, > send email to h323implementors-request(a)imtc.org with text "info" > > >------------------------------------------------------------------------- > for list subscription instructions, > send email to h323implementors-request(a)imtc.org with text "info" >------------------------------------------------------------------------- >for list subscription instructions, >send email to h323implementors-request(a)imtc.org with text "info" > >

1 0

Re: New T.35
by Paul Long 30 Jun '99

30 Jun '99

Paul, Could we run into problems with some country actually using the extension field? (I think the US always defines it to be zero.) I don't see any other alternative, though. Paul Long Smith Micro Software, Inc. -----Original Message----- From: Paul E. Jones [SMTP:paul.jones@TIES.ITU.INT] Sent: Monday, June 28, 1999 9:31 AM To: ITU-SG16(a)MAILBAG.INTEL.COM Subject: New T.35 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 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

5 5

Re: MGCP reference (was Re: Megaco/H.gcp conference call)
by Tom-PT Taylor 30 Jun '99

30 Jun '99

It's for real. Honestly speaking, there is much wariness on the IETF side, but so long as the outcome continues to be sensible the agreement is holding. > -----Original Message----- > From: Chip Sharp [SMTP:chsharp@cisco.com] > Sent: Wednesday, June 30, 1999 1:40 PM > To: Taylor, Tom-PT [CAR:5V00-I:EXCH]; ITU-SG16(a)mailbag.cps.intel.com > Subject: Re: MGCP reference (was Re: Megaco/H.gcp conference call) > > At 09:53 AM 6/30/99 -0400, Tom-PT Taylor wrote: > >Here's a brief history, from my point of view -- others are free to add > >their viewpoints. > > > ...snip... > > > >May 1998: formal Megaco/H.GCP cooperative arrangement announced. > ...snip... > I believe the arrangement announced in Santiago has not actually been > formalized or confirmed. At least that was the impression I got from > Scott's mail. Of course, just because there is no formal arrangement > doesn't mean megaco and Q.14 aren't working toward common protocol. > > Since you brought it up though, :-), what is the status of the > arrangement? > > Chip > > -------------------------------------------------- > Chip Sharp Consulting Engineering > Cisco Systems Telco Bio-region > Reality - Love it or Leave it. > --------------------------------------------------

1 0

Re: PDU & ASN parser
by Sherlock, Stuart 30 Jun '99

30 Jun '99

Would someone please unsubscribe me. Thanks Stuart Sherlock -----Original Message----- From: Paul Long [mailto:Plong@SMITHMICRO.COM] Sent: Wednesday, June 30, 1999 9:28 AM To: ITU-SG16(a)MAILBAG.INTEL.COM Subject: Re: PDU & ASN parser Guntram, I raised this issue over a year ago. In addition, H.225.0 does not address this issue regarding RAS (it does regarding call signaling), so I suppose one could pack multiple RAS messages per unreliable-transport PDU. As you say, it doesn't make sense to pack messages, and I don't think anyone does it. We should probably add something like the following to section 6.1 of the next revision of H.225.0. "When messages are sent on the H.225.0 RAS channel, only one whole message shall be sent within the boundaries defined by the transport; there shall be no fragmentation of H.225.0 RAS messages across transport PDUs." We should also insert the indicated text, below, into existing text in the same section. "When messages are sent on the reliable H.245 control channel, >>>exactly one message should be sent but<<< more than one message may be sent within the boundaries defined by the reliable transport PDU as long as whole messages are sent;" Paul Long Smith Micro Software, Inc. -----Original Message----- From: Guntram Diehl [SMTP:gdiehl@innovaphone.com] Sent: Wednesday, June 30, 1999 4:14 AM To: 'Bancroft Scott'; 'Srikanth Nayani' Cc: 'h323implementors(a)imtc.org' Subject: RE: PDU & ASN parser Yes this can be done, but does any implementation actually do it? Why would anyone want to do this, it just saves 4 bytes tpkt header per additional H.245 message and it does not change the fragmentation of the whole thing by IP. Or is there another reason why this was specified in the standard this way? Guntram -----Original Message----- From: Bancroft Scott [mailto:baos@OSS.COM] Sent: Wednesday, June 30, 1999 3:54 AM To: Srikanth Nayani Cc: h323implementors(a)imtc.org Subject: Re: PDU & ASN parser On Tue, 29 Jun 1999, Srikanth Nayani wrote: > In the H.225 document chapter 6 mentions that multiple messages can be > sent over the reliable H.245 control channel within the boundaries of the > reliable transport channel . Does that mean that two H.245 PDUs encoded > using PER and whose total encoded length is within the boundary of the > H.245 TCP channel can be merely concatenated and sent as a single payload > of the H.245 TCP channel. > If so how does a ASN.1 decoder know that there are two messages in the > payload and the offset at which the second message starts. An PER decoder does not know that there are two messages in the payload. It does know where the first message ends, so the location of the next message can be derived from this knowledge. ------------------------------------------------------------------------ -- Bancroft Scott Toll Free :1-888-OSS-ASN1 Open Systems Solutions, Inc. International:1-609-987-9073 baos(a)oss.com Tech Support :1-732-249-5107 http://www.oss.com Fax :1-732-249-4636 ------------------------------------------------------------------------ - for list subscription instructions, send email to h323implementors-request(a)imtc.org with text "info" ------------------------------------------------------------------------- for list subscription instructions, send email to h323implementors-request(a)imtc.org with text "info"

2 1