- sg16-avd - lists.packetizer.com

Re: SG16, Bruges meeting, doc registration
by OKUBO Sakae 20 May '02

20 May '02

Dear Mr. Whitehead, Thank you for your registration. This is the first except for liaison statements from other SGs. At 13:11 +0100 02/05/20, martin.j.whitehead(a)bt.com wrote: >I intend to submit the latest revision of: H.248.11 Media Gateway Overload >Control Package, at the Bruges SG16 meeting 24-28 June. AVD-2195 has been allocated to your contribution. Best regards, OKUBO Sakae ********************************************************* Global Information and Telecommunication Institute (GITI) Waseda University 29-7 Waseda University Bldg. 1-3-10 Nishi-Waseda, Shinjuku-ku, Tokyo 169-0051 Japan e-mail: okubo(a)giti.waseda.ac.jp Tel: +81 3 3204 8194 Fax: +81 3 5286 3832 *********************************************************

1 0

Liaison statements from SG15
by OKUBO Sakae 18 May '02

18 May '02

Dear SG16 experts, The following four liaison statements from SG15 have been uploaded to the ftp site: using browser http://standard.pictel.com/ftp/avc-site/0206_Bru/ using ftp tool ftp://standard.pictel.com/avc-site/0206_Bru/ AVD-2191 3 Clarification on Automatic Level Control vs. Gain Control SG15 AVD-2192 2, 3 Channel multiplexing protocol for IP-CME application - G.769/Y.1242 SG15 AVD-2193 D, F, 2, 3, 4, 5 Transport of IPv6 Jumbo Frames SG15 AVD-2194 All New versions of the Access Network Transport (ANT) Standardization Plan and Work Plan SG15 Best regards, OKUBO Sakae ********************************************************* Global Information and Telecommunication Institute (GITI) Waseda University 29-7 Waseda University Bldg. 1-3-10 Nishi-Waseda, Shinjuku-ku, Tokyo 169-0051 Japan e-mail: okubo(a)giti.waseda.ac.jp Tel: +81 3 3204 8194 Fax: +81 3 5286 3832 *********************************************************

1 0

Rec. H.501 and "GEF" parameter repository
by Horvath Ernst 16 May '02

16 May '02

Dear experts, my H.501 final draft contained a placeholder "annex B" for collecting "generic data" (i.e. standardized GEF identifier values). Upon advice by TSB, this annex will be removed in the published version 1 of H.501 since it contained no useful text. The initial idea was to include here material from H.225.0 annex G as soon as version 2 of annex G is finished. But now I have some doubts whether H.501 is the right place for such a data register. A repository of generic data should at least include also values assigned in GEF standards (H.460.x). Wouldn't the H.460 series be a better place for this? At the top level we have assigned so far: - feature ID "0" for H.225.0 Annex G profiles - feature IDs "n" for H.460.n (is this the complete list?) Each top-level feature ID opens a local name space for EnumeratedParameter-IDs specified for that specific feature. Since these are defined locally there is no danger of collisions. At least the top-level IDs should be maintained at a central place to avoid collisions, especially if such IDs can be assigned outside H.460.n standards as well (is this generally the case, or is H.225.0 annex G the only exception?). Of course such a repository could also list the locally assigned EnumeratedParameter-IDs for each registered feature, to provide a quick reference. So the question is, do people see the need for a generic-data register, and if yes, in which form? H.460.x? Or in an IG? H.501 does not seem to be the proper place. Regards, Ernst Horvath Siemens AG

4 3

Re: Rec. H.501 and "GEF" parameter repository
by Campos, Simao 16 May '02

16 May '02

Paul/Ernst: Two questions for my clarification: - How frequently would such contents be updated? - Is the intent for such material to be normative or informative? Simao -----Original Message----- From: Paul E. Jones [mailto:paulej@PACKETIZER.COM] Sent: jeudi, 16. mai 2002 05:52 To: ITU-SG16(a)echo.jf.INTEL.COM Subject: Re: Rec. H.501 and "GEF" parameter repository Ernst, I do agree that we need a single place to list these. In the past, the thinking was to list such things in the Implementers Guide, but I'm more inclined to argue that H.460.1, perhaps Annex A (non-existent) would be the right place. Paul ----- Original Message ----- From: Horvath Ernst <mailto:ernst.horvath@SIEMENS.COM> To: ITU-SG16(a)echo.jf.INTEL.COM <mailto:ITU-SG16@echo.jf.INTEL.COM> Sent: Wednesday, May 08, 2002 8:08 AM Subject: Rec. H.501 and "GEF" parameter repository Dear experts, my H.501 final draft contained a placeholder "annex B" for collecting "generic data" (i.e. standardized GEF identifier values). Upon advice by TSB, this annex will be removed in the published version 1 of H.501 since it contained no useful text. The initial idea was to include here material from H.225.0 annex G as soon as version 2 of annex G is finished. But now I have some doubts whether H.501 is the right place for such a data register. A repository of generic data should at least include also values assigned in GEF standards (H.460.x). Wouldn't the H.460 series be a better place for this? At the top level we have assigned so far: - feature ID "0" for H.225.0 Annex G profiles - feature IDs "n" for H.460.n (is this the complete list?) Each top-level feature ID opens a local name space for EnumeratedParameter-IDs specified for that specific feature. Since these are defined locally there is no danger of collisions. At least the top-level IDs should be maintained at a central place to avoid collisions, especially if such IDs can be assigned outside H.460.n standards as well (is this generally the case, or is H.225.0 annex G the only exception?). Of course such a repository could also list the locally assigned EnumeratedParameter-IDs for each registered feature, to provide a quick reference. So the question is, do people see the need for a generic-data register, and if yes, in which form? H.460.x? Or in an IG? H.501 does not seem to be the proper place. Regards, Ernst Horvath Siemens AG

2 1

Re: H.450.1 ASN.1 interoperability issue
by Sasha Ruditsky 15 May '02

15 May '02

Hi I just want to rewrite the same to be sure we are in sync. 6.6.1.3 of the V4 implementors guide does not CHANGE/CONTRADICT ASN.1 of H.450.1 it EXPLAINS how to encode values correctly according to ASN.1 definitions of H.450.1 And this correct encoding is: (as written in 6.6.1.3) invoke.invokeId shall be encoded as INTEGER(0..65535) returnResult.invokeId and returnError.invokeId shall be encoded as INTEGER Sasha -----Original Message----- From: Horvath Ernst [mailto:ernst.horvath@SIEMENS.COM] Sent: Monday, May 13, 2002 8:49 AM To: ITU-SG16(a)echo.jf.INTEL.COM Subject: AW: H.450.1 ASN.1 interoperability issue Mark, there was no intention to change any ASN.1 definition in H.450.1. The note was added just to make implementers aware that the InvokeID is encoded differently in the "invoke" APDU and in the "returnResult/returnError" APDUs: in the first case it is constrained by InvokeIdSet, in the second case it is not constrained. This is not an incosistency, just a consequence of the way Packed Encoding Rules were designed. Please also note that "InvokeIdSet" is used in two different meanings: in table 4 it is the name of a parameter of the parameterized structure ROS (i.e. a placeholder), whereas in table 3 it is an "actual" value-set of integers. The brackets in the new note (InvokeIdSet = 0..65535) are not an ASN.1 definition, just an indication what the effective constraint is, namely 0..65535. Table 3 is still the (unchanged) formal definition of the actual "InvokeIdSet". Ernst Horvath Siemens AG > -----Ursprüngliche Nachricht----- > Von: Mark Brown [ mailto:Mark.Brown@ED.ACULAB.COM <mailto:Mark.Brown@ED.ACULAB.COM> ] > Gesendet am: Freitag, 10. Mai 2002 17:29 > An: ITU-SG16(a)echo.jf.INTEL.COM > Betreff: H.450.1 ASN.1 interoperability issue > > We've been experiencing some fairly serious interoperability problems > with some systems due to confusion over what exactly the ASN.1 for > H.450.1 is and were hoping someone could clarify things for us. The > problem stems from section 6.6.1.3 of the V4 implementors guide which > adds a note below table 4: > > In the Invoke APDU, the invokeID is an INTEGER constrained by a > PER-visible constraint (InvokeIdSet = 0..65535) and is therefore > encoded as a *constrained* INTEGER (16 bits, no length field). In > the ReturnResult and ReturnError APDUs, however, the invokeID is > encoded as an *unconstrained* integer (with explicit length field) > because the applicable constraint... is not PER-visible. > > However, in H.450.1 table 3 (on page 8) defines InvokeIdSet to be: > > InvokeIdSet INTEGER ::= {InvokeIds,...} > InvokeIDs ::= INTEGER (0..65535) > > which does not gel with the text in the IG and causes interoperability > issues since the two versions of the ASN.1 for InvokeIdSet are not > encoded identically. This text appears to be unchanged from the > prepublished edition on Packetizer. > > Our understanding of the text added in the IG is that the > intent was to > emphasise that the encoding of the invokeID is not consistent between > the various APDUs and that the no change to the ASN.1 was intended. > This is particularly the case since the IG doesn't modify table 3 as > would be expected if it were correcting the ASN.1 there. Others read > things differently and are using the definition of > InvokeIdSet given in > the IG. > > What is the intention here? If the intention is to redefine the ASN.1 > then some clarification as to why this was done would be very much > appreciated. >

2 1

Meeting Announcement: June 24-28, Bruges
by Paul E. Jones 15 May '02

15 May '02

Dear Experts, At the Kind invitation of Belgacom, we have been invited to Belgium to hold a Rapporteur's meeting the week of June 24 in Bruges, Belgium. This meeting will be held at the same location as the ETSI TIPHON meeting and on the first day, we will have a special meeting with TIPHON called the "TIPHON-NGN Summit". Attached to this e-mail, please find the meeting announcement (the TXT file) and the invitation letter from Belgacom (DOC file). Both contain important information on reserving your hotel room, registering for the meeting, and submitting documents, but each also has unique information, so please read both. I am serving as meeting manager for this meeting, so if you have any questions for clarification, please feel free to ask and, if you feel your question is of general interest, please also address the mailing list so others can benefit from the answer. One outstanding question I have right now is the deadline for the hotel reservations. I will try to get that information and post it to the reflector as soon as possible. However, the best advise is "don't delay". On behalf of all of the Rapporteurs, we look forward to seeing you in Bruges! Best Regards, Paul E. Jones Rapporteur, ITU-T Q2/16 Cisco Systems, Inc.

2 1

AW: H.450.1 ASN.1 interoperability issue
by Horvath Ernst 13 May '02

13 May '02

Mark, there was no intention to change any ASN.1 definition in H.450.1. The note was added just to make implementers aware that the InvokeID is encoded differently in the "invoke" APDU and in the "returnResult/returnError" APDUs: in the first case it is constrained by InvokeIdSet, in the second case it is not constrained. This is not an incosistency, just a consequence of the way Packed Encoding Rules were designed. Please also note that "InvokeIdSet" is used in two different meanings: in table 4 it is the name of a parameter of the parameterized structure ROS (i.e. a placeholder), whereas in table 3 it is an "actual" value-set of integers. The brackets in the new note (InvokeIdSet = 0..65535) are not an ASN.1 definition, just an indication what the effective constraint is, namely 0..65535. Table 3 is still the (unchanged) formal definition of the actual "InvokeIdSet". Ernst Horvath Siemens AG > -----Ursprüngliche Nachricht----- > Von: Mark Brown [mailto:Mark.Brown@ED.ACULAB.COM] > Gesendet am: Freitag, 10. Mai 2002 17:29 > An: ITU-SG16(a)echo.jf.INTEL.COM > Betreff: H.450.1 ASN.1 interoperability issue > > We've been experiencing some fairly serious interoperability problems > with some systems due to confusion over what exactly the ASN.1 for > H.450.1 is and were hoping someone could clarify things for us. The > problem stems from section 6.6.1.3 of the V4 implementors guide which > adds a note below table 4: > > In the Invoke APDU, the invokeID is an INTEGER constrained by a > PER-visible constraint (InvokeIdSet = 0..65535) and is therefore > encoded as a *constrained* INTEGER (16 bits, no length field). In > the ReturnResult and ReturnError APDUs, however, the invokeID is > encoded as an *unconstrained* integer (with explicit length field) > because the applicable constraint... is not PER-visible. > > However, in H.450.1 table 3 (on page 8) defines InvokeIdSet to be: > > InvokeIdSet INTEGER ::= {InvokeIds,...} > InvokeIDs ::= INTEGER (0..65535) > > which does not gel with the text in the IG and causes interoperability > issues since the two versions of the ASN.1 for InvokeIdSet are not > encoded identically. This text appears to be unchanged from the > prepublished edition on Packetizer. > > Our understanding of the text added in the IG is that the > intent was to > emphasise that the encoding of the invokeID is not consistent between > the various APDUs and that the no change to the ASN.1 was intended. > This is particularly the case since the IG doesn't modify table 3 as > would be expected if it were correcting the ASN.1 there. Others read > things differently and are using the definition of > InvokeIdSet given in > the IG. > > What is the intention here? If the intention is to redefine the ASN.1 > then some clarification as to why this was done would be very much > appreciated. >

1 0

H.450.1 ASN.1 interoperability issue
by Mark Brown 10 May '02

10 May '02

We've been experiencing some fairly serious interoperability problems with some systems due to confusion over what exactly the ASN.1 for H.450.1 is and were hoping someone could clarify things for us. The problem stems from section 6.6.1.3 of the V4 implementors guide which adds a note below table 4: In the Invoke APDU, the invokeID is an INTEGER constrained by a PER-visible constraint (InvokeIdSet = 0..65535) and is therefore encoded as a *constrained* INTEGER (16 bits, no length field). In the ReturnResult and ReturnError APDUs, however, the invokeID is encoded as an *unconstrained* integer (with explicit length field) because the applicable constraint... is not PER-visible. However, in H.450.1 table 3 (on page 8) defines InvokeIdSet to be: InvokeIdSet INTEGER ::= {InvokeIds,...} InvokeIDs ::= INTEGER (0..65535) which does not gel with the text in the IG and causes interoperability issues since the two versions of the ASN.1 for InvokeIdSet are not encoded identically. This text appears to be unchanged from the prepublished edition on Packetizer. Our understanding of the text added in the IG is that the intent was to emphasise that the encoding of the invokeID is not consistent between the various APDUs and that the no change to the ASN.1 was intended. This is particularly the case since the IG doesn't modify table 3 as would be expected if it were correcting the ASN.1 there. Others read things differently and are using the definition of InvokeIdSet given in the IG. What is the intention here? If the intention is to redefine the ASN.1 then some clarification as to why this was done would be very much appreciated.

1 0

Re: "Early media" with fast connect
by Douglas Clowes 09 May '02

09 May '02

Frank, Actually, media with PI=8 (inband tones and announcements) is probably a good thing, and I would expect it. The intention of "prepared to receive" is because it could receive valid media before it knows if it's associated with a connect or progress (PI=8) so it should play it. Indeed, this will often be the case over real networks, where RTP media is expedited ahead of regular TCP traffic. The intention is to not clip the media. The MG, being a "dumb" box should probably be provided with a "trigger" to stop local ringback on receipt of first media, and/or notify the MGC of "first media received". The MGC thus provides the logic of when, or if, to stop the local ringback. As for the "mediaWaitForConnect", what if there never will be a Connect? I assume that an announcement server, which sends Progress(PI=8) and plays media, will send media without sending Connect. The receiving endpoint should play it. The normal thing would be to establish media in the backward direction before sending Setup, so media would be played, and connect the forward media direction on receipt of Connect. Regards, Douglas At 11:42 02/05/2002 +0200, frank.derks(a)PHILIPS.COM wrote: >>>> <fontfamily><param>Courier</param>Ernst,</fontfamily> <fontfamily><param>Courier</param>obviously, conflict situations could arise if both a Progress indicator #1 or #8, in</fontfamily> <fontfamily><param>Courier</param>combination with actual media being transmitted by the called endpoint would occur, </fontfamily> <fontfamily><param>Courier</param>but this does not seem to be a likely event. </fontfamily> <fontfamily><param>Courier</param>The fact the calling endpoint "must be prepared to receive media" is not the same</fontfamily> <fontfamily><param>Courier</param>thing as "expecting to receive media". You have a valid point, though, that at some</fontfamily> <fontfamily><param>Courier</param>stage a switch-over from locally provided media to the media provided by the called</fontfamily> <fontfamily><param>Courier</param>endpoint must occur. When this occurs is governed by the Progress indicator and the</fontfamily> <fontfamily><param>Courier</param>mediaWaitForConnect.</fontfamily> <fontfamily><param>Courier</param>Regards,</fontfamily> <fontfamily><param>Courier</param>Frank </fontfamily> <fontfamily><param>Courier</param>Dear experts, there seems to be a possible conflict with early media during call establishment using fast connect. </fontfamily> <fontfamily><param>Courier</param>Clause 8.1.7.1 of H.323 clearly says that the calling endpoint must be prepared to receive media right away on the ports it indicated in fastStart, and that the called endpoint may start transmitting media as soon as it accepts a fastStart proposal (unless, of course, the calling endpoint indicated also "mediaWaitForConnect"). This is independent of any Progress indicator.</fontfamily> <fontfamily><param>Courier</param>Clause 8.1.7.4, on the other hand, requires that the calling endpoint provides tones like ringback locally if it did not receive a Progress indicator #1 or #8. So the calling endpoint is obliged to interrupt/ignore possible media streams from the called endpoint and replace them with its own tones. Isn't this a conflict situation?</fontfamily> <fontfamily><param>Courier</param>I would like to hear your opinion or any experience from implementations. </fontfamily> <fontfamily><param>Courier</param>Kind Regards, Ernst Horvath Siemens AG </fontfamily> <<<<<<<<

1 0

Documents for the Bruges meeting
by OKUBO Sakae 09 May '02

09 May '02

Dear Q.D, F, G, 2-5 experts, I have uploaded the attached liaison statements at the following place: using browser http://standard.pictel.com/ftp/avc-site/0206_Bru/ using ftp tool ftp://standard.pictel.com/avc-site/0206_Bru/ Best regards, OKUBO Sakae ********************************************************* Global Information and Telecommunication Institute (GITI) Waseda University 29-7 Waseda University Bldg. 1-3-10 Nishi-Waseda, Shinjuku-ku, Tokyo 169-0051 Japan e-mail: okubo(a)giti.waseda.ac.jp Tel: +81 3 3204 8194 Fax: +81 3 5286 3832 ********************************************************* Document List for the Bruges Joint Q.D, F, G, 2, 3, 4, 5 Rapporteurs $B!G (B Meeting (24-28 June 2002) AVD-number Questions Title Source AVD-2175 D, 2, 3, 4 PROPOSED NEW QUESTION ON "Syntax language for the support of PSTN/ISDN services within IP session control protocols" SG11 AVD-2176 G Liaison Statement on Multimodality and Multimediality - Ref: A morphological model for multi-sensory technologies and coherence in security SG17 AVD-2177 G, ets Response to Liaison Statement to ITU-T Study Groups on Telecommunication Reliability and Security SG17 AVD-2178 ets Response to Liaison Statement to draft new Question Q.ets/16 on Emergency Telecommunications Service (ETS) SG17 AVD-2179 G Liaison on the Compendia of Communication Systems Security SG17 AVD-2180 All Liaison statement on the User Requirements Notation (URN) SG17 AVD-2181 2, 3 Liaison Statement to Working Parties 6E, 6S and 8A , Joint Task Group 1-6-8-9, and ITU-T Study Groups 9, 13 and 16 on the Sixth revision of the working document for diagrammatic interrelations of Recommendations for interactive broadcasting services and their summaries ITU-R Working Party 6M AVD-2182 F Consent of Draft New Recommendation M.2301 (ex-M.23ip) - PERFORMANCE OBJECTIVES AND PROCEDURES FOR provisioning AND MAINTENANCE OF ip-based networks Working Party 1/4 (Designations, Performance and Test Equipment) AVD-2183 3 CLARIFICATIONS TO H.246 ANNEX C SG 11 (Q11/11) AVD-2184 All Consent of M.3030, telecommunications Markup Language (tML) Framework SG 4 AVD-2185 ets Response to Study Group 16 Liaison on Draft New Question Qets/16 for Emergency Telecommunications Service (ETS) SG 4 AVD-2186 ets Response to SG16 Liaison on International Emergency Services SG 4 AVD-2187 F Response to SG 16 on Use of the CORBA in the TMN WP 4/4, Geneva, 8 $B%_ (B 19 April 2002 AVD-2188 All SG 4 Report and Request in its role as Lead SG on TMN SG 4 (Geneva, 8 $B%_ (B 19 April 2002) AVD-2189 2, 3, F Progress of the discussion on generic end-to-end QoS service requirements SG 11 AVD-2190 D, ets International Emergency Services SG 11 ----------

1 0

Re: h235v2
by Euchner Martin ICN M SR 3 07 May '02

07 May '02

Wu, thanks for your good observation. I read the two paragraphs together in conjunction with chapter 7 and can indeed agree with you that there is a mismatch. As a resolution, I will prepare a proposal for the H.323 Implementors Guide that recommends to delete the incorrect "logical", as shown below. Assuming that the connection procedures in the previous clause (Connection establishment procedures) indicate a secure mode of operation, the negotiated handshake and authentication shall occur for the H.245 channel before any other H.245 messages are exchanged. If negotiated, any exchange of certificates shall occur using any mechanism appropriate for the H-Series terminal(s). After completing the securing of the H.245 channel, the terminals use the H.245 protocol in the same manner that they would in an insecure mode. With kind regards Martin Euchner. ----------------------------------------------------------------------- | Dipl.-Inf. Rapporteur Q.G/SG16 | Martin Euchner Phone: +49 89 722 55790 | Siemens AG.....................Fax : +49 89 722 47713 | ICN M SR 3 mailto:Martin.Euchner@icn.siemens.de | mailto:martin.euchner@ties.itu.int | Hofmannstr. 51 Intranet: http://intranet.icn.siemens.de/marketing/cs27/topics/security/ | D-81359 Muenchen Internet: http://www.siemens.de/ | __________________ | Germany ----------------------------------------------------------------------- -----Original Message----- From: wu.yongming(a)ZTE.COM.CN [mailto:wu.yongming@ZTE.COM.CN] Sent: Friday, April 26, 2002 5:15 AM To: ITU-SG16(a)echo.jf.INTEL.COM Subject: h235v2 hi,all experts is the following i marked by <<<>>> a error? i think it should possibly be H.245 control channe. 8.1 Secure H.245 channel operation Assuming that the connection procedures in the previous clause (Connection establishment procedures) indicate a secure mode of operation, the negotiated handshake and authentication shall occur for the <<<H.245 logical channel>>> before any other H.245 messages are exchanged. If negotiated, any exchange of certificates shall occur using any mechanism appropriate for the H-Series terminal(s). After completing the securing of the H.245 channel, the terminals use the H.245 protocol in the same manner that they would in an insecure mode. special to paul,because i am not sure this mail can get to the maillist,so i have send a copy to your address.if it is a trouble,please forgive me about that. regards, wu.y.m

1 0

FW: Question about the use of alternateEndpoints in ACF
by Lyons, Terry 05 May '02

05 May '02

> H.225 v4 contains this text: > "7.11.2 AdmissionConfirm (ACF) > ... alternateEndpoints - A sequence of prioritized endpoint alternatives > for destCallSignalAddress or destinationInfo." > > The feature seems intended to support robustness through redundancy in > large networks, > where there may be more than one media gateway capable of serving the same > AdmissionRequest (ARQ). > This would accord with the support for alternate gatekeepers in H.323 v4: > "7.2.6 Alternate gatekeeper procedures > For the purposes of ensuring system availability, redundancy, and > scalability, the Gatekeeper may provide the RAS signalling function by > utilizing multiple physical or logical devices, referred to as Alternate > Gatekeepers. If the endpoint supports the Alternate Gatekeeper procedures > defined in this section, it should include the supportsAltGK field in the > GRQ and RRQ messages. > When an endpoint initiates communication with the Gatekeeper, it may be > provided with a list of Alternate Gatekeepers via the GCF message. If the > Gatekeeper does not respond to the subsequent RRQ, the endpoint shall > attempt to register with the Gatekeeper using the list of Alternate > Gatekeepers provided in the GCF. If no Alternate Gatekeeper responds, the > endpoint shall reinitiate the Gatekeeper discovery process." > > The problem is that there are no procedures specified for the use of > alternateEndpoints. > What is it that causes a caller to terminate its Setup attempt to one > destination and to initiate a Setup attempt to the next destination in > priority order? > > Can we presume that the critical event is receiving a ReleaseComplete? > Then how do we determine whether the release reason or cause code is final > (no further Setup should be sent) or not (try another destination)? > Some calls should end after an announcement is played, eg. "The number you > are calling has been disconnected", > and will never succeed no matter how many alternative endpoints are > attempted. > > If the intention of alternateEndpoints has already been clarified > somewhere, please point me to it and excuse my ignorance. > > - TLyons(a)sonusnet.com +1 732 625-3003 ext 212 >

3 2

"Early media" with fast connect
by Horvath Ernst 02 May '02

02 May '02

Dear experts, there seems to be a possible conflict with early media during call establishment using fast connect. Clause 8.1.7.1 of H.323 clearly says that the calling endpoint must be prepared to receive media right away on the ports it indicated in fastStart, and that the called endpoint may start transmitting media as soon as it accepts a fastStart proposal (unless, of course, the calling endpoint indicated also "mediaWaitForConnect"). This is independent of any Progress indicator. Clause 8.1.7.4, on the other hand, requires that the calling endpoint provides tones like ringback locally if it did not receive a Progress indicator #1 or #8. So the calling endpoint is obliged to interrupt/ignore possible media streams from the called endpoint and replace them with its own tones. Isn't this a conflict situation? I would like to hear your opinion or any experience from implementations. Kind Regards, Ernst Horvath Siemens AG

3 2

Fast Connect and terminating a call
by frank.derks＠PHILIPS.COM 02 May '02

02 May '02

Experts, 8.1.7.3/H.323 states that when Fast Connect is used to establish a call and no initiation of the H.245 procedures took place, the call _may_ be terminated by sending a RELEASE COMPLETE message. First of all, there is no reference to 8.1.7.3/H.323 in section 8.5/H.323, which describes the call termination procedure. This may lead the reader to believe that the procedures from 8.5/H.323 always apply and that the H.245 procedures must be initiated first (I.e. at a minimum the exchange of the terminal capability sets) to be able to send an EndSessionCommand message. Secondly, by stating that the call _may_ be terminated by sending a RELEASE COMPLETE message the reader may think that there are other ways of terminating the call. Obviously, there are (as described above, for example), but this would not seem the logical thing to do. Why not state that the call SHALL be terminated by sending a RELEASE COMPLETE message? Regards, Frank

1 0

Re: "Early media" with fast connect
by frank.derks＠PHILIPS.COM 02 May '02

02 May '02

Ernst, obviously, conflict situations could arise if both a Progress indicator #1 or #8, in combination with actual media being transmitted by the called endpoint would occur, but this does not seem to be a likely event. The fact the calling endpoint "must be prepared to receive media" is not the same thing as "expecting to receive media". You have a valid point, though, that at some stage a switch-over from locally provided media to the media provided by the called endpoint must occur. When this occurs is governed by the Progress indicator and the mediaWaitForConnect. Regards, Frank Dear experts, there seems to be a possible conflict with early media during call establishment using fast connect. Clause 8.1.7.1 of H.323 clearly says that the calling endpoint must be prepared to receive media right away on the ports it indicated in fastStart, and that the called endpoint may start transmitting media as soon as it accepts a fastStart proposal (unless, of course, the calling endpoint indicated also "mediaWaitForConnect"). This is independent of any Progress indicator. Clause 8.1.7.4, on the other hand, requires that the calling endpoint provides tones like ringback locally if it did not receive a Progress indicator #1 or #8. So the calling endpoint is obliged to interrupt/ignore possible media streams from the called endpoint and replace them with its own tones. Isn't this a conflict situation? I would like to hear your opinion or any experience from implementations. Kind Regards, Ernst Horvath Siemens AG

1 0

ITU-T SG16 Rapporteurs Meeting in June
by Paul E. Jones 27 Apr '02

27 Apr '02

Folks, As was previously mentioned, we are planning to hold the ITU-T SG16 meeting in Brugges, Belgium 24-28 June 2002. We are still working on the specifics of the meeting and I am not prepared to send a meeting announcement at this time with details, but what I would like to request is that you send me e-mail if you plan to attend the meeting. Please provide: Family Name, Given Name, Company, E-mail Address As a reminder-- as always, the Rapporteur's meetings are open to both ITU members and non-members. There will be a meeting fee for this meeting, which will be used to cover the costs of transportation to and from the meeting facilities, as well as to cover the cost of lunch and other meeting costs. At this time, I do not know what the amount of the meeting fee will be, but I expect it to be reasonable. I want to try to get a rough estimate of the number of people who will be attending the meeting, so I would definitely appreciate it if you can let me know if you will be attending. Best Regards, Paul

1 0

h235v2
by wu.yongming＠ZTE.COM.CN 25 Apr '02

25 Apr '02

hi,all experts is the following i marked by <<<>>> a error? i think it should possibly be H.245 control channe. 8.1 Secure H.245 channel operation Assuming that the connection procedures in the previous clause (Connection establishment procedures) indicate a secure mode of operation, the negotiated handshake and authentication shall occur for the <<<H.245 logical channel>>> before any other H.245 messages are exchanged. If negotiated, any exchange of certificates shall occur using any mechanism appropriate for the H-Series terminal(s). After completing the securing of the H.245 channel, the terminals use the H.245 protocol in the same manner that they would in an insecure mode. special to paul,because i am not sure this mail can get to the maillist,so i have send a copy to your address.if it is a trouble,please forgive me about that. regards, wu.y.m

1 0

H.460.1 editorial correction
by Paul E. Jones 25 Apr '02

25 Apr '02

Dear Experts, I received a consultation from the TSB regarding H.460.1, as to whether it would be proper to introduce a clarification for text in the third paragraph of Section 7.2. Specifically, the proposed change is from "If the feature is defined using ASN.1, then it is recommended that the PER encoding rules be used. ..." to "If the feature is defined using ASN.1, then it is recommended that the basic aligned variant of the PER encoding rules be used. ..." I personally support the correction since all H.323 equipment uses the basic aligned variant for PER encoding and using anything else would be incorrect. I would like to give the OK to the TSB for implementing this editorial correction, but would like to confirm with you whether there are any concerns with this change. We could of course incorporate it via an Implementers Guide later on, but we have the opportunity to have it right from the start. If you have concerns, please let me know ASAP but preferably not later than April 29, 2002. Best Regards, Paul

2 1

Re: Do we have any MMS Recommendations in the works
by Reddy, Paul K 19 Apr '02

19 Apr '02

Dear Campos-Neto, Q2/16, Q5/16 under WP2 have work items on Multimedia Instant Messaging and Presence Services. Very little progress has been made so far. Visit URL http://standar.pictel.com/ftp/avc-site for more information on the prevoius meeting documents. Regards, Paul Rapporteur of Q5/16 -----Original Message----- From: Campos, Simao [mailto:simao.campos@ITU.INT] Sent: Friday, April 19, 2002 8:37 AM To: ITU-SG16(a)echo.jf.INTEL.COM Subject: Do we have any MMS Recommendations in the works Dear colleagues, I would appreciate to hear from you if any MMS work is planned or being undertaken in WP2. Thanks, Simão Campos-Neto -----Original Message----- From: gregory.gamboa(a)toshiba-trel.com [mailto:gregory.gamboa@toshiba-trel.com] Sent: lundi, 15. avril 2002 18:01 To: pressinfo(a)itu.int Subject: [form2email] MMS This mail has been sent from the ITU web site to pressinfo(a)itu.int : SubjectMMS Bonjour, Do you have any recommandations/specifications on MULTIMEDIA MESSAGE SERVICE (MMS) FOR MOBILE PHONES. Merci, Greg.

1 0

Do we have any MMS Recommendations in the works
by Campos, Simao 19 Apr '02

19 Apr '02

Dear colleagues, I would appreciate to hear from you if any MMS work is planned or being undertaken in WP2. Thanks, Simão Campos-Neto -----Original Message----- From: gregory.gamboa(a)toshiba-trel.com [mailto:gregory.gamboa@toshiba-trel.com] Sent: lundi, 15. avril 2002 18:01 To: pressinfo(a)itu.int Subject: [form2email] MMS This mail has been sent from the ITU web site to pressinfo(a)itu.int : SubjectMMS Bonjour, Do you have any recommandations/specifications on MULTIMEDIA MESSAGE SERVICE (MMS) FOR MOBILE PHONES. Merci, Greg.

1 0

Application-Specific Megaco Error Codes
by Tom-PT Taylor 15 Apr '02

15 Apr '02

It has been bothering me for quite a while that we have no guidelines for the numbering of error codes, so they could be all over the map. For example, I created codes in the NAS packages starting with 100, simply because this was the first example of package-documented error codes. Since these codes were not yet registered with IANA, it may not be too late to enforce the following convention, following the precedent set by H.,248 Annex M.1: Proposal: application-specific error codes are assigned consecutive values starting at 600. Following on this proposal, I am changing the NAS error codes to 613-616 from 100-103. Comments? Tom Taylor taylor(a)nortelnetworks.com Ph. +1 613 736 0961 (ESN 396 1490)

3 2

Q.D,F,G,2-5 Rapporteur meeting
by OKUBO Sakae 11 Apr '02

11 Apr '02

Dear SG16 experts, After some discussions and negotiations, the next Rapporteur meeting date and place have been settled to 24th-28th June in Bruges, Belgium. Mr. Paul Jones will act as meeting organizer, and myself as document manager for this meeting. Paul will shortly post a preliminary announcement. Best regards, OKUBO Sakae ********************************************************* Global Information and Telecommunication Institute (GITI) Waseda University 29-7 Waseda University Bldg. 1-3-10 Nishi-Waseda, Shinjuku-ku, Tokyo 169-0051 Japan e-mail: okubo(a)giti.waseda.ac.jp Tel: +81 3 3204 8194 Fax: +81 3 5286 3832 *********************************************************

1 0

Re: Question
by Even, Roni 02 Apr '02

02 Apr '02

Gregory, The question is general. You need an MCU which is a multipoint control unit that serves as the conference bridge. You can have one MCU that everyone will use or two MCUs one in Brussels and the other in San Diego. The MCUs will be cascaded to have one conference. The cascading can be done using IP or ISDN. Regards Roni Even -----Original Message----- From: Gregory [mailto:gregoryduez@BELGACOM.NET] Sent: Friday, March 29, 2002 1:32 PM To: ITU-SG16(a)echo.jf.INTEL.COM Subject: Question Hi, I would like to implement a VC through the net between two companies one located in Brussels and the other in San Diego. What would be the best solution ? You have to take into account that 5 to 10 people would attend at each remote site ! Thanks for your help, Greg

1 0

Re: [imtch323implementors] Question
by Anatoli Levine 29 Mar '02

29 Mar '02

Gregory, your question is too broad to be answered easily : ). Effectively, there is a lot of solutions on the market today which will allow you to do it - but the real issues are the bandwidth you can have between the 2 sites, presence of firewalls/NATs, security requirements and so on. In general, I would suggest that you will take a look at the products list on H.323 Forum site (http://www.packetizer.com/iptel/h323/products.html) - depending on your specific requirements you should be able to find a solution there. Cheers, Anatoli Gregory wrote: > Hi,I would like to implement a VC through the net between two > companies one located in Brussels and the other in San Diego.What > would be the best solution ?You have to take into account that 5 to 10 > people would attend at each remote site !Thanks for your help, Greg--- > > You are currently subscribed to imtch323implementors as: > alevine(a)radvision.com > To unsubscribe send a blank email to > leave-imtch323implementors-6060E(a)mail.imtc.org

1 0

Question
by Gregory 29 Mar '02

29 Mar '02

Hi, I would like to implement a VC through the net between two companies one located in Brussels and the other in San Diego. What would be the best solution ? You have to take into account that 5 to 10 people would attend at each remote site ! Thanks for your help, Greg

1 0