May 2001 - sg16-avd - lists.packetizer.com

Switching to H.245
by Francois Audet 17 May '01

17 May '01

Guys, H.323/8.1.7.2 says : After establishment of a call using the Fast Connect procedure, either endpoint may determine that it is necessary to invoke call features that require the use of H.245 procedures. Either endpoint may initiate the use of H.245 procedures at any point during the call, using tunnelling as described in 8.2.1 (if h245Tunnelling remains enabled) or a separate H.245 connection. The process for switching to a separate H.245 connection is described in 8.2.3.<?xml:namespace prefix = o ns = "urn:schemas-microsoft-com:office:office" /> 8.2.3 says: When H.245 encapsulation or Fast Connect is being used, either endpoint may choose to switch to using the separate H.245 connection at any time. There seem to be some contradiction in there: is it "after establishment" or "at any time"? Do you have to wait for after CONNECT to establish a separate H.245 channel or not? The case I'm interested in would be to send SETUP with fastStart, then receive ALERTING with fastStart. Then can either end initiate H.245 before CONNECT? If so, what if third party pause and redirection is initiated before CONNECT? ---- François AUDET, Nortel Networks mailto:audet@nortelnetworks.com <mailto:audet@nortelnetworks.com> , tel:+1 408 495 3756

2 1

Documents for the Porto Seguro meeting
by OKUBO Sakae 17 May '01

17 May '01

Dear SG16 experts, For your review, the following 7 documents have been placed at http://standard.pictel.com/ftp/avc-site/0105_Por/ Draft_H323_Annex_O.zip -- Draft H.323 Annex O by the Editor sip-for-video.zip -- Sip for video from delegation of Israel H323_the_need_for_presence.doc -- The imperative need for Presence functionality in various H.323 Systems from delegation of Israel H323_to_enable_presence.doc -- Alternatives for delivery of Presence Information from and to H.323 End Users from delegation of Israel End_to_End_QoS_Control_H323.zip -- SOURCE: Mike Buckley, Rapporteur Q.F/16 TITLE: An Application Level Control of End-to-End QOS Annex_N_May_2001.zip -- SOURCE: Mike Buckley, Editor H.323 Annex N. TITLE: New draft of H.323 Annex N TD-xxx_AnnexR.zip SOURCE: Rapporteur Q.2/16 (P. Jones) TITLE: H.323 Annex R: Robustness Methods for H.323 Entities 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 ********************************************************* ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

Re: RTCP support in H.248? [RE: RTCP support in H.323]
by Tom-PT Taylor 17 May '01

17 May '01

H.248/Megaco does not have to mention RTCP because support of RTCP at the Media Gateway is implicit. There are a number of statistics related to the RTP package which would be very difficult to gather without the use of RTCP. > -----Original Message----- > From: Horvath Ernst [mailto:ernst.horvath@SIEMENS.AT] > Sent: Thursday, May 17, 2001 4:53 AM > To: ITU-SG16(a)mailbag.cps.INTEL.COM > Subject: RTCP support in H.248? [RE: RTCP support in H.323] > > > And what is the situation in H.248/Megaco? I did not find any > reference to > RTCP in this recommendation. > > Ernst Horvath > Siemens AG > > -----Ursprüngliche Nachricht----- > Von: Rex Coldren [mailto:coldrenr@agcs.com] > Gesendet am: Dienstag, 08. Mai 2001 19:40 > An: ITU-SG16(a)mailbag.cps.INTEL.COM > Betreff: RTCP support in H.323 > All, > I'll be lazy and ask rather than looking through the ASN.1 > to find it... > Is there support in H.323 for signaling to use RTCP? > > There is a current thread on the IETF AVT e-mail reflector where > talk is of making RTCP mandatory (i.e.-changing it from a SHOULD > to a MUST in the RTP specification). The last I heard was that the > MUST would apply to implementing RTCP, and not necessarily to > using it. Presumably the application level call signaling > protocol can > be responsible for signaling whether RTCP was to be used. > > If an endpoint implemented RTCP it should at least benignly ignore > received RTCP reports and would not need to send any. So a given > operator could specify that RTCP not be signaled if it were not > practical in their network. Obvious examples would be wireless > networks and cable networks where there are access bandwidth > constraints. > > > Cheers, > Rex > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > For help on this mail list, send "HELP ITU-SG16" in a message to > listserv(a)mailbag.intel.com >

1 0

RTCP support in H.248? [RE: RTCP support in H.323]
by Horvath Ernst 17 May '01

17 May '01

And what is the situation in H.248/Megaco? I did not find any reference to RTCP in this recommendation. Ernst Horvath Siemens AG -----Ursprüngliche Nachricht----- Von: Rex Coldren [mailto:coldrenr@agcs.com] Gesendet am: Dienstag, 08. Mai 2001 19:40 An: ITU-SG16(a)mailbag.cps.INTEL.COM Betreff: RTCP support in H.323 All, I'll be lazy and ask rather than looking through the ASN.1 to find it... Is there support in H.323 for signaling to use RTCP? There is a current thread on the IETF AVT e-mail reflector where talk is of making RTCP mandatory (i.e.-changing it from a SHOULD to a MUST in the RTP specification). The last I heard was that the MUST would apply to implementing RTCP, and not necessarily to using it. Presumably the application level call signaling protocol can be responsible for signaling whether RTCP was to be used. If an endpoint implemented RTCP it should at least benignly ignore received RTCP reports and would not need to send any. So a given operator could specify that RTCP not be signaled if it were not practical in their network. Obvious examples would be wireless networks and cable networks where there are access bandwidth constraints. Cheers, Rex ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

Annex R TD
by Terry L Anderson 16 May '01

16 May '01

I have submitted the latest draft of H.323 Annex R to the TSB to be included as a rapporteur's TD. But to give earlier access, I have also uploaded it to the incoming directory of the avc-site. TD-xxx_AnnexR.doc Mr Okubo - there is a similarly named file "TDxxx-AnnexR.doc" in the incoming directory that failed to completely upload and should be discarded. -- ------------------------------------------------------------ Terry L Anderson mailto:tla@lucent.com Tel:908.582.7013 Fax:908.582.6729 Lucent Technologies/INS/Voice Over IP Access Networks Rm 2B-121, 600 Mountain Av, Murray Hill, NJ 07974 http://its.lucent.com/~tla (Lucent internal) http://www.gti.net/tla

1 0

Re: H.248 TerminationID
by Tom-PT Taylor 16 May '01

16 May '01

I'm afraid we don't have an FAQ yet, though it's probably time to start one. Most questions of this sort get asked on the Megaco list <megaco(a)fore.com>. Anyway, the syntax for a text terminationID requires that it start with an ALPHA, possibly preceded by a "*" wildcard. The basic idea is that you can combine "*" or "$" wildcards with string segments to request selection of all terminations matching the pattern ("*") or any one termination matching the pattern ("$") as the case may be. > -----Original Message----- > From: Leano, Bob [mailto:Bob.Leano@ICN.SIEMENS.COM] > Sent: Tuesday, May 15, 2001 12:27 PM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: H.248 TerminationID > > > The megaco call flow examples do not give a rendition for > creating the TerminationId field which consist of a wildcard > and an Id. If I want to specify a particular id, say 1234, and > not want to specify a choose or all, what should my wildcard be? > > Is there an ftp site that clarifies implementation questions > like mine? > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > For help on this mail list, send "HELP ITU-SG16" in a message to > listserv(a)mailbag.intel.com >

1 0

Tow documents uploaded
by OKUBO Sakae 16 May '01

16 May '01

Dear CHAPRON Jean-Emmanuel, Takashi Suzuki and all, The following two contributions have been placed at the Porto Seguro meeting directory of the ftp site: SOURCE: Rapporteur for Q.3/16 TITLE: H.248 packages for transmission of data over analog lines http://standard.pictel.com/ftp/avc-site/0105_Por/TD_H248_package_analog_lin e.zip SOURCE: NTT DoCoMo, Inc. TITLE: Proposal for the new Annex M.4/H.248 http://standard.pictel.com/ftp/avc-site/0105_Por/Delayed_H248AnnexM4.zip 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 ********************************************************* ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

Comments on H.245v8 & H.263 Annex X
by Dave Lindbergh 15 May '01

15 May '01

Mike/all, A couple of minor comments on the draft H.245v8 in GEN-009 for Brazil: 1) We've some concern that, given the complexity of the current (pre-v8) H.263 caps, a "new vendor" unfamiliar with the history of H.245 and H.263 will be tempted to signal _only_ the new Annex X/H.263 Generic Caps (H.263 profiles) instead of the existing H.263 caps that all current equipment use. If this happens, a video call will fall back all the way to H.261. To avoid this, I suggest adding the following as a "Note" to the H.263 generic cap in Table VIII.1/H.245: <begin text> Note - Use of this capability to signal H.263 "Profiles and Levels" per Annex X/H.263 should always be accompanied in parallel by the signaling of the same modes in H263VideoCapability. This is necessary to ensure that systems which do not recognize the H.263 generic capabilities continue to interwork with newer systems. <end text> I think this is an issue _only_ for H.245, and not for Annex X/H.263 in general, since any new use of H.263 (not involving H.245) will have no such backward-compatibility issue. 2) In the title for Table VIII.1/H.245, the words "capability" and "organizations" are misspelled. If you (as editor) and the list members agree, I suggest these be included in a "corrections" TD for Brazil. Regards, --Dave Lindbergh, PictureTel Corp. ------------------------------------------------------------------- Dave Lindbergh Email: lindbergh(a)pictel.com PictureTel Corporation Voice: +1 978 292 4351 100 Minuteman Road, MS 713 Fax: +1 978 292 3328 Andover MA 01810 USA H.320 video by arrangement PGP fingerprint: C8 3E 28 69 53 0A 4B 87 EF E0 11 CD AC 87 4D CD ------------------------------------------------------------------- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

H.248 TerminationID
by Leano, Bob 15 May '01

15 May '01

The megaco call flow examples do not give a rendition for creating the TerminationId field which consist of a wildcard and an Id. If I want to specify a particular id, say 1234, and not want to specify a choose or all, what should my wildcard be? Is there an ftp site that clarifies implementation questions like mine? ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

Re: Documents for the SG16 meeting in Porto Seguro
by OKUBO Sakae 15 May '01

15 May '01

Dear Mr. Gilman, Mr. Sayer and all, Your contributions have been placed at the /0105_Por directory of the ftp site. SOURCE: Avaya TITLE: Basic H.248 Packages for Support of External Signal Sources http://standard.pictel.com/ftp/avc-site/0105_Por/extsigpkg.zip SOURCE: Lucent Technologies TITLE: Multimedia Support Using the Decomposed H.323/H.3XX Gateway Architecture http://standard.pictel.com/ftp/avc-site/0105_Por/DelayedConLucentToQ3.zip 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 ********************************************************* ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

2 1