- sg16-avd - lists.packetizer.com

AVD-2083.zip
by BOUGANT Fran�ois FTRD/DAC/ISS 27 Feb '01

27 Feb '01

Dear experts, Please find enclosed the AVD-2083 contribution in zip format. Sorry for my late ! Cordially, François BOUGANT & France Télécom R&D FTR&D/DAC/ACE e-mail :francois.bougant@francetelecom.fr 38, 40 rue du Général Leclerc 92794 Issy Moulineaux Cedex 9 Phone : (33) 1 45 29 51 84 Fax : (33) 1 46 29 31 42

1 0

AVD-2078 and AVD-2094 uploaded
by Terry L Anderson 27 Feb '01

27 Feb '01

I have uploaded AVD-2079 H.323 Annex R draft and AVD-2094 Using RFC 2833 for DTMF in H.323 Fast Connect -- ------------------------------------------------------------ Terry L Anderson mailto:tla@lucent.com Tel:908.582.7013 Fax:908.582.6729 Pager:800.759.8352 pin 1704572 1704572(a)skytel.com Lucent Technologies/ Voice Over IP Access Networks/ Applications Grp Rm 2B-121, 600 Mountain Av, Murray Hill, NJ 07974 http://its.lucent.com/~tla (Lucent internal) http://www.gti.net/tla

1 0

AVD-2053 uploaded
by Horvath Ernst 27 Feb '01

27 Feb '01

AVD-2053 (contribution for H.323 annex H) has been uploaded to avc-site/Incoming. Regards, Ernst Horvath ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

Uploading AVD-2045
by OKUBO Sakae 26 Feb '01

26 Feb '01

Dear Paul and all, I have uploaded the following contribution to /Incoming: AVD-2045 Source: Rapporteur for Question 4 /16 (Sakae OKUBO) Title: Workplan for Q4/16 "Video and data conferencing using Internet supported services" Purpose: Discussion Any comments and suggestions are welcome. Best regards, OKUBO Sakae *********************************************************** 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 (to be transferred) +81 3 3204 8194 (direct) Fax: +81 3 5287 7287 e-mail: okubo(a)giti.or.jp *********************************************************** ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

4 3

AVD-2093.zip
by Craig Blasberg 26 Feb '01

26 Feb '01

1 0

Re: H.248 Syntax im H.323 Annex L
by Paul, Manoj 26 Feb '01

26 Feb '01

Hi John, Is it not that we are just emulating MGCP model in the Stimuls COntrol Protocol provided by H.323 Annex L? I mean, the way a MGC controls an MG using H.248, an Annex L Feature Server controls an H.323 endpoint. According to my understanding it is just that H.248 is used "as is" for the later. Why do we need to tunnel H.248 and between what entities in the network? I shall appreciate your comments in this. thanks Manoj. -----Original Message----- From: Li, John [mailto:John.Li@Dialogic.com] Sent: Monday, February 26, 2001 12:15 PM To: 'Paul, Manoj' Subject: RE: H.248 Syntax im H.323 Annex L I think, By doing that, H.248 information can be tunneled within h.245 messages, so the H.248 section can be processed by a MEGACO entity directly for interoperability. Although BER was not a optimal solution (nor was SDP) for encoding in MEGACO, SIG 16 allows it to be used. John -----Original Message----- From: Paul, Manoj [mailto:mpaul@TRILLIUM.COM] Sent: Monday, February 26, 2001 2:13 PM To: ITU-SG16(a)mailbag.cps.INTEL.COM Subject: H.248 Syntax im H.323 Annex L Hi All, Could someone point out the reason for keeping h248Message codepoint as OCTET STRING in stimulusControl IE in H.323 Version 4 for Annex L support. H.323 Annex L specifies h248Message as OCTET STRING in stimulusControl code point. This surely saves importing H.248 ASN.1 syntax in H.323, but it does require the user to encode/decode H.248 PDUs as text/BER. And then re-encode the H248 message as an OCTET STRING using PER in H.323 UUPDU. Was there any reason why the specific H.248 codepoints were not imported in H.323 so that the user may have to use only PER encode scheme to encode simulusControl IE. Does not the earlier approach necessiates the user to have H.248 implementation with H.323 to support Annex L? Thanks for your time, Manoj Paul. Trillium Digital Systems, Inc. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

H.248 Syntax im H.323 Annex L
by Paul, Manoj 26 Feb '01

26 Feb '01

Hi All, Could someone point out the reason for keeping h248Message codepoint as OCTET STRING in stimulusControl IE in H.323 Version 4 for Annex L support. H.323 Annex L specifies h248Message as OCTET STRING in stimulusControl code point. This surely saves importing H.248 ASN.1 syntax in H.323, but it does require the user to encode/decode H.248 PDUs as text/BER. And then re-encode the H248 message as an OCTET STRING using PER in H.323 UUPDU. Was there any reason why the specific H.248 codepoints were not imported in H.323 so that the user may have to use only PER encode scheme to encode simulusControl IE. Does not the earlier approach necessiates the user to have H.248 implementation with H.323 to support Annex L? Thanks for your time, Manoj Paul. Trillium Digital Systems, Inc. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

Re: Quick question on a Request for package registration
by Tom-PT Taylor 26 Feb '01

26 Feb '01

3GPP is a public forum, and I believe their packages would be viewed as public. I'll note that it is desirable that the packages be considered technically stable (though perhaps subject to some editing and minor adjustment) before they are registered. I've copied various parties for coordination purposes. > -----Original Message----- > From: IANA [mailto:iana@iana.org] > Sent: Friday, February 23, 2001 5:28 PM > To: Taylor, Tom-PT [NORSE:B881:EXCH] > Subject: FW: Quick question on a Request for package registration > > > Tom, > > Quick question. Which range should these packages be registered in? > Do I need to ask the applicants if these are public or private? > > From the RFC: > Public packages MUST be given serial numbers in the range 0x0001 to > 0x7fff. Private packages MUST be given serial numbers in the range > 0x8000 to 0xffff. > > Thanks for any help. If there is someone better to ask, please let me > know. Don't want to bug you :) > > Michelle > IANA > > ************************************************************** > *********** > > Hi there > > I am the editor for a 3rd Generation Partnership Project > (3GPP) protocol > specification which defines extensions to the H.248/MeGaCo > protocol; I have > pasted in a copy of the "Scope" clause of this specification below. > > "The present document describes the protocol to be used on > the Media Gateway > Controller (MGC) - Media Gateway (MGW) interface. The Media Gateway > Controllers covered in this specification are the MSC server > and the GMSC > server. The basis for this protocol is the H.248/MEGACO protocol as > specified in ITU-T and IETF. The BICC architecture as > described in ITU-T > Q.1902 [7]-[11] and 3G TS 23.205 [3] defines the usage of > this protocol. > This specification describes the changes to H.248/MEGACO > which are needed to > handle 3GPP specific traffic cases. This is done by using the > H.248/MEGCO > standard extension mechanism. > The present document is valid for a 3rd generation PLMN > (UMTS) complying > with Release 2000 and later. " > We need to define three new packages for this specification, > and as the > custodians of the package identifiers you are the people I > need to contact > to ask for the package numbers! > > I have pasted in the first part of the definition of each > package below. > > 13.1.1 IuUP package. > PackageID: 3giuup (0x####) > [Editor's note: PackageID to be allocated by IANA] > Version: 1 > Extends: None > This package identifies that the Iu User Plane is used for > the termination. > It also contains some parameters for the Iu User Plane > functions in the MGW. > The Iu User Plane is active in both directions independently > of the Stream > Mode. > 13.1.2 Circuit Switched Data package > PackageID: 3gcsd (0x####) > [Editor's note: PackageID to be allocated by IANA] > Version: 1 > Extends: None > This package contains the information needed to be able to > support GSM and > UMTS Circuit Switched Data from the media gateway. > 13.1.3 TFO package > PackageID: 3gtfoc (0x####) > [Editor's note: PackageID to be allocated by IANA] > Version: 1 > Extends: None > This package defines events and properties for Tandem Free > Operation (TFO) > control. TFO uses inband signalling and procedures for > Transcoders to enable > compressed speech to be maintained between a tandem pair of > transcoders. > This package allows an MGW which has inserted a transcoder to > support TFO. > Can you please let me know how I should go on from here to > have the package > numbers allocated? If you need any further information, > please contact me. > > Best regards > > Ian Park > > ___________________________________________________ > Ian Park > Chief Engineer, Core Network Signalling Standards > Vodafone Limited > *T: +44 1635 673 527 > *F: +44 1635 233 562 > *E: ian.park(a)vf.vodafone.co.uk > ___________________________________________________ > > >

1 0

AVD-2085 uploaded
by Folts, Harold 23 Feb '01

23 Feb '01

Greetings, Please find AVD-2085.doc, Framework for Supporting IEPS/IEMS in IP Telephony uploaded to the Incoming directory ftp://standard.pictel.com/avc-site/Incoming/ The file will soon be moved to ftp://standard.pictel.com/avc-site/0103_Lau/. See you all in Launceston. Hal * * * * * * * * * * * * * * * * * * * * * * * * * * * Hal Folts * Senior Systems Engineer * Priority Services - Internet * Technology and Programs Division (N2) * National Communications System * 701 South Courthouse Road * Arlington, VA 22204-2198 * Tel: +1 703 607-6186 Fax: +1 703 607-4830 * * * * * * * * * * * * * * * * * * * * * * * * * * ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

Re: Protocol version re-negotiation
by Rosen, Brian 23 Feb '01

23 Feb '01

It's unlikely that we will do anything that adds new features by edits to the implementor's guide. It's reasonable to have explanatory text in such a document that is not normative. I think you failover, upgrade, and failover back with this version of the protocol. Brian > -----Original Message----- > From: Paul Rheaume [mailto:paul.rheaume@alcatel.com] > Sent: Thursday, February 22, 2001 1:00 PM > To: ITU-SG16 Mail List > Cc: megaco(a)fore.com > Subject: Re: Protocol version re-negotiation > > > Folks, > > Where is the appropriate list to discuss this issue? > > We feel that version negotiation and the version upgrade > process is not > well specified and needs to be discussed and properly defined at the > latest in version 2 of the specification. That means looking at this > very soon. > > I think this issue belongs to the next version of the Implementor's > Guide. > > Regards, > Paul > > Nancy Devin wrote: > > > > How does a non-redundant MG upgrade to a new > > Megaco version without affecting service? How > > does a redundant MG upgrade to a new Megaco > > version without affecting service? > > > > It is mentionned in RFC3015 that Protocol version > > negotiation can be done at Restart, Failover, and > > Handoff serviceChanges. It is not mentionned > > explicitly how version protocol re-negotiation is > > done after the MG has registered with the MGC. in > > both situation > > > > This could be done in at least two different ways > > as listed bellow. > > > > 1- Protocol version negotiation could be > > initiated using the Failover serviceChange. A > > Failover serviceChange with a protocol version > > would indicate that the MG has been configured > > with a new H.248 protocol version. Sent from the > > MG to the MGC, it indicates that the MG has been > > configured with a new H.248 protocol version. > > This serviceChange shall not indicate Failure of > > the working MG. This would require that for > > non-redundant MGs, both the primary IP address and > > the secondary IP address be the same. > > > > 2- Protocol version negotiation could be > > intiated using a new serviceChange method: > > VersionNegotiation (Method 7 of the serviceChange > > command as defined in RFC3015) This serviceChange > > would be sent from the MG to the MGC to initiate > > protocol version initiation. It indicates that > > the MG has been configured with a new H.248 > > protocol version. Sent from the MGC to the MG, it > > indicates that the MGC has been configured with a > > new H.248 protocol version. > > > > Comments please. > > Nancy > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

4 3