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

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

Q.G: AVD-2046 uploaded
by Euchner Martin 23 Feb '01

23 Feb '01

Please find AVD-2046.zip (Workplan for Question "Security of Multimedia Systems and Services") uploaded to the Incoming directory ftp://standard.pictel.com/avc-site/Incoming/ <ftp://standard.pictel.com/avc-site/Incoming/> The file will be moved to ftp://standard.pictel.com/avc-site/0103_Lau/ <ftp://standard.pictel.com/avc-site/0103_Lau/> in a while. Note: AVD-2046 (without zip) has possibly been corrupted during upload. You can safely ignore that fragment. Kind Regards Martin Euchner. ----------------------------------------------------------------------- | Dipl.-Inf. Phone: +49 89 722 55790 | Martin Euchner Fax : +49 89 722 46841 | Siemens AG | ICN M NT 5 mailto:Martin.Euchner@icn.siemens.de <mailto:Martin.Euchner@icn.siemens.de> | mailto:martin.euchner@ties.itu.int <mailto:martin.euchner@ties.itu.int> | Hofmannstr. 51 Intranet: http://intranet.icn.siemens.de/marketing/network_technology/security/pki.htm | D-81359 Muenchen Internet: http://www.siemens.de <http://www.siemens.de> | __________________ | Germany ----------------------------------------------------------------------- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

AVD-2080 uploaded
by Klaghofer Karl ICN EN HC SE 81 23 Feb '01

23 Feb '01

Dear all, I have uploaded AVD-2080 (Liaison from ECMA TC32, Title: "Draft ECMA Standard on basic call interworking between H.323 and QSIG") to the "Incoming" directory. Thanks. Karl Klaghofer, Siemens AG ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

AW: Video codec for H.323 Annex I
by Baese Gero 23 Feb '01

23 Feb '01

Dear Mr. Li, experts, we provided you with the draft of the technical comparison document. A lot of time elapsed and now you don't consider it realistic anymore to do this joint work. We regret your resistance. The consequence would be wasting the time of the group at the meeting with what we were supposed to do in advance. Please reconsider your answer and the time delay caused by you with it. The document attached to your last email by mistake I guess was an old collection of values. The more comprehensive test scenario document is APC-1993r2, attached to this email. It will be provided as document AVD-2059 at the next meeting. Best Wishes Gero Baese > -----Ursprüngliche Nachricht----- > Von: Adam Li [mailto:adamli@icsl.ucla.edu] > Gesendet am: Donnerstag, 22. Februar 2001 11:55 > An: Baese Gero; ITU-SG16(a)mailbag.cps.INTEL.COM > Cc: Tao Tian; Jay Fahlen; John D. Villasenor; Barry Aronson; Paul E. > Jones; Jeong-Hoon Park; So Youg Kim; Yung Lyul Lee > Betreff: RE: Video codec for H.323 Annex I > > Mr. Baese, experts, > > For the testing condition document, I believe we have settled > on most of the > issues. So here is the testing document, and please take a > look and let me > know if there is anything else that we need to discuss. > > About the feature comparison document, I suggest that we both draft > documents for the point to point comparisons with the > technical reasoning. > From the current schedule situation, it seems that it is more > realistic for > us to submit two independent documents. We can go over them > at the meeting, > and combine them then if necessary. > > Regards, > > Adam > > > > ---------- > Adam H. Li > Image Communication Lab (310) 825-5178 (Lab) > University of California, Los Angeles (310) 825-7928 (Fax) >

2 1

Registering documents for the upcoming ITU-T meeting
by Paul E. Jones 23 Feb '01

23 Feb '01

Folks, As you know, requests for document numbers for the upcoming Rapporteur's meeting are due by 23 February 2001. Unfortunately, I will be traveling on that day, so I will not be able to reply to requests received on that day. Most likely, I will not get a chance to reply until the 25th-- I do apologize. However, please be assured that I will respond to your request at my earliest opportunity. Thanks, Paul ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

Q: H.245 and RTP Dynmaic Payload Types
by Douglas Clowes 22 Feb '01

22 Feb '01

Could some kind soul please point me to the definitive guide to the use of RTP dynamic payload types in H.245. I've looked and can't seem to find any adequate coverage. If anybody has firm ideas how it's done, I would be pleased to receive the benefit of their knowledge. The documentation talks about the use of dynamic payload types in the use of alternative packetisation for video, but there seems to be a need for dynamic payload types in audio codecs which have H.245 code points, but not RTP static payload types (such as GSM HR and EFR). Dynamic payload types are being used for mode specification in SDP as well, with some MGs using them to specify the desired rate for G.723.1 (High or Low). IMHO, the standard needs to be expanded on the use of dynamic paylaod types, with particular reference to interworking with SDP based MGs and SIP. Cheers, Douglas Clowes ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

2 1

Re: Protocol version re-negotiation
by Paul Rheaume 22 Feb '01

22 Feb '01

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

1 0

AVD-2033 and AVD-b2034, H.248 Annex F corrections
by Gunnar Hellstrom 22 Feb '01

22 Feb '01

I have uploaded the following documents to the avc-site/incoming for the coming Q.3/16 meeting: AVD-2033.zip H.248 Annex F corrections. AVD-2034.zip H.248 Annex F Implementor´s guide proposal. The contributions proposes correction of errors in assigned numeric parameter values. (Annex F is the Fax, Text, Call discrimination packages ) Regards Gunnar Hellström **************************************** Gunnar Hellström Ericsson Radio Systems AB tel´+46 708 204 288 gunnar.hellstrom(a)era.ericsson.se ***************************************** ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

a query
by Alok Dubey (OCS-BLRAKS-AVS) 22 Feb '01

22 Feb '01

hi im sorry for posing this query out here but i needed this answer asap.. Im basically more of an implementor than a protocol developer and all my job is above the layer 3.. ie socket programming etc. Right now while going thru the specs, I could not find any reasonable explanation on how u prioritise traffic for call setup? for eg are u sending callsetup info over RTP ports too..? if yes, i still have to figure out how to use Voice Activity Detection to conserve bandwidth a feature which lets us drop voice packets below a certain db level .., if no this basically means that setting up a call could take a long time and the traffic associated with it cannot be controlled/prioritised.. can anyone refer me to any good specs Sorry to be wasting ur time on such a query.. but i couldnt think of a better place to pose this question. Rgds Alok ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

2 1