- sg16-avd - lists.packetizer.com

The use if statusDeterminationNumber in masterSlaveDetermination
by Frank Derks 03 May '01

03 May '01

C.2.1.4/H.245 states the following: "If the terminal type numbers are the same, the statusDeterminationNumbers are compared using modulo arithmetic to determine which is master If both terminals have equal terminalType field values and the difference between statusDetermination field values modulo 2^24 is 0 or 2^23, an indeterminate result is obtained" The first sentence states that "modulo arithmetic" must be used to compare the numbers. I would say that that's a rather vague way of describing how the comparison must be done. Furthermore it does not tell me what the result must be for a terminal to be determined to be the master! According to the second sentence, I know how to obtain an indeterminate result. So any result that is not any of the two specified values is not indeterminate, but I still do not know what the meaning of the result is. "Modulo arithmetic" is, however, introduced, but it is not clear whether this is the modulo arithmetic referred to in the first sentence. Furthermore, what is the significance of a result of 2^23? I assume that the same rules that apply to the comparison of the terminalType field apply (i.e. the terminal with the higher value becomes the master), but this is not stated explicitly. Regards, Frank ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

FREE ACTIVATION!!!!
by tom.slick97854＠VERIZON.NET 02 May '01

02 May '01

How about your choice of FREE CELLULAR PHONES? AND FREE ACTIVATION? UP TO 3000 MINUTES A MONTH? You are pre-approved for the best digital cellular service on the market. We offer the best wireless service, with no strings attached. That means NO HIDDEN FEES, NO PROMOTIONS, NO ACTIVATION FEES, NO EQUIPMENT FEES, and NO EXTRA MONTHLY CHARGES!!! To find out more, please visit our website at: http:\\www.KDWireless.com With your activation on any of our monthly rate plans, you will receive your choice of 6 different PCS Phones for FREE, and ALL of the following options: ~ Free Access to the Wireless Web~ ~ Free PCS Voice Command ~ ~ Free Roaming ~ ~ Free Long Distance ~ ~ Free Caller Id ~ ~ Free 3 Way Calling ~ ~ Free Voicemail ~ ~ Free Paging ~ ~ Free Detailed Billing ~ ~ Free 24 Hr Web Support ~ ~ Free 24 Hr Toll Free Support ~ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

Re: Latest H.245
by OKUBO Sakae 30 Apr '01

30 Apr '01

Dear Mike and all, >Dear Mr Bigi, > >Please find attached text for H.245 version 8. Please enter this as a WP2TD. > >As usual the zip file contains clean text, full delta document and minimal >delta document. Changes are relative to version 7. > >Best regards The file H245_P.zip has been placed at the 0105_Por directory. Best regards, Sakae OKUBO ********************************************************** Global Information and Telecommunication Institute (GITI) Waseda University Waseda University Bldg. 29-7 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: Binary Encoding of H.245 Related Properties given in Table C/ H.248
by Tom-PT Taylor 30 Apr '01

30 Apr '01

H.248 Annex C uses BER. > -----Original Message----- > From: Muhammad Mukarram Bin Tariq [mailto:mmukarrams@YAHOO.COM] > Sent: Monday, April 16, 2001 6:53 PM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: Binary Encoding of H.245 Related Properties given in Table > C/H.248 > > > Dear All, > > My question is regarding the encoding of the H.245 related > properties listed in > Table C/H.248. I presume that all these property values are > encoded according > to PER. Also that the entire MultimediaSystemControlPDU is > encoded, instead of > just the message structure. e.g to encode an OLC, we should > encode the entire > MultimediaSystemControlPDU that contains the OLC message, or > just the OLC > message structure. > > I am asking this question because in the presence of "Tags" > it is quite > possible to live without encoding the entire > MultimediaSystemControlPDU. > > Regards, > > Muhammad Mukarram Bin Tariq > > > > __________________________________________________ > Do You Yahoo!? > Get email at your own domain with Yahoo! Mail. > http://personal.mail.yahoo.com/ > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > For help on this mail list, send "HELP ITU-SG16" in a message to > listserv(a)mailbag.intel.com >

3 2

Re: FW: Emergency Services and Service classes
by Folts, Harold 30 Apr '01

30 Apr '01

Ken, Many thanks for your comments. I think that they are very important to be inclusive of the many considerations for emergency communications including 911/999/211 calls as well MLPP (preemption). I am also sending this to the SG16 experts list as there has been quite a bit of discussion to Gary's Email there. Hal > -----Original Message----- > From: Ken Carlberg [mailto:K.Carlberg@cs.ucl.ac.uk] > Sent: Thursday, April 26, 2001 5:20 AM > To: Folts, Harold > Cc: Gary Thom (E-mail) > Subject: Re: FW: Emergency Services and Service classes > > > > Hello, > > My apologies for the tardiness of this response. In looking at Gary's > original message, I thought I might chime in and introduce some food > for thought. > > in Gary's message, he suggested the following: > > > I would like to propose the following Service Class parameter. > > > > ServiceClass ::= SEQUENCE > > { > > priority CHOICE > > { > > emergency, > > high, > > normal, > > low > > } > > quality CHOICE ;per TIPHON definition > > { > > best, > > high, > > medium, > > bestEffort > > } > > } > > I was thinking that it may be better to add another value in the > 'priority' field in order to distinguish 'authorized' emergency calls > like GETS, versus generic emergency calls like 911 that would be used > by the general public and not require special PIN numbers, or other > additional measures to denote authentication and authorization. > > so, perhaps one might have something like: > > > priority CHOICE > > { > > authorized-emergency, > > emergency, > > high, > > normal, > > low > > } > > also, would it be of value to have a separate field that distinguishes > "classification" of priority? For instance, the above would be the > generic > type used for global/national PSTN. But there is also the MLPP (from > ANSII?) that has 5 levels of priority, but is not used in the > PSTN, but > rather private voice nets like Autovon. > > My feeling is that having a separate field that differentiates normal > PSTN versus private-MLPP may be helpful and less confusing than having > a single "priority" field that covers all defined values of priority. > > However, if you think this may be too cumbersome, then maybe we should > look into adding 5 additional values that relate directly to MLPP, > thus having a field of 10 values in the above. > > For the following... > > > The priority field is used to indicate the importance of the > > call. This is > > used not only for assuring that resources can be allocated, > > but also to > > improve the probability of completion of the call. > > I was wondering if it might be better to start off by saying that > the values in the priority field denote a "distinction" of the types > of calls that can be made. The reason I state this is that there may > be cases where traffic engineering separates the routes that calls > make, but does not place any additional resources per type. This > line of thinking would reflect the cases where preemption is not used, > but rather higher probability is. > > After stating the point on distinction, then one could talk about > the allocation of resource with respect to preemption and quality, > on which you talk about next. > > > > quality CHOICE ;per TIPHON definition > > { > > best, > > high, > > medium, > > bestEffort > > } > > for the above, you may want to inc;ude a value called > "BelowBestEffort". > I have a paper that makes an arguement for doing this at times, and I > have recently come across others that are trying to promote this. In > addition, it may correlate nicely to the above priority of "low". It > may also correlate to the drop precedence field in IP packets (for > diff-serv) when a flow/call exceeds the traffic rate originally > negotiated for it. > > regards, > > -ken > > > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

Re: version
by Al Varney 27 Apr '01

27 Apr '01

1 0

Re: version
by Michael Brown 27 Apr '01

27 Apr '01

Based on the date on the download page at the ITU site, the English version was posted Feb 8, 2001. They have PDF, Word and zipped Word files. For those interested, the French and Spanish versions are also available at that site. The cost shown for the document is 55 Swiss Francs. -----Original Message----- From: Rosen, Brian [mailto:Brian.Rosen@marconi.com] Sent: Friday, April 27, 2001 10:51 AM To: Brown, Michael [NC1:GW10:EXCH]; megaco(a)fore.com Cc: ITU-SG16(a)mailbag.cps.intel.com Subject: RE: version Really? When did that happen? Brian -----Original Message----- From: Michael Brown [mailto:C.Michael.Brown@nortelnetworks.com] Sent: Friday, April 27, 2001 9:55 AM To: megaco(a)fore.com Subject: RE: version Actually, I was looking at the ITU web site and noticed that H.248 has now been published. -----Original Message----- From: Rosen, Brian [ mailto:Brian.Rosen@marconi.com <mailto:Brian.Rosen@marconi.com> ] Sent: Friday, April 27, 2001 8:51 AM To: 'mu lj'; megaco(a)fore.com Subject: RE: version RFC3015 is the only "official" released version of Megaco/H.248, and is called "Version 1". Recommendation H.248 has not yet emerged from the publication queue at ITU, but is identical (except for boilerplate) to RFC3015. Brian > -----Original Message----- > From: mu lj [ mailto:dtxlymlj@hotmail.com <mailto:dtxlymlj@hotmail.com> ] > Sent: Friday, April 27, 2001 5:22 AM > To: megaco(a)fore.com > Subject: version > > > hi > which h.248's version refer to rfc3015. > which's h.248's version now. > > Regards > Lingjiang Mu > ______________________________________________________________ > ___________ > Get Your Private, Free E-mail from MSN Hotmail at > http://www.hotmail.com <http://www.hotmail.com> . >

1 0

Re: version
by Rosen, Brian 27 Apr '01

27 Apr '01

Really? When did that happen? Brian -----Original Message----- From: Michael Brown [mailto:C.Michael.Brown@nortelnetworks.com] Sent: Friday, April 27, 2001 9:55 AM To: megaco(a)fore.com Subject: RE: version Actually, I was looking at the ITU web site and noticed that H.248 has now been published. -----Original Message----- From: Rosen, Brian [ mailto:Brian.Rosen@marconi.com <mailto:Brian.Rosen@marconi.com> ] Sent: Friday, April 27, 2001 8:51 AM To: 'mu lj'; megaco(a)fore.com Subject: RE: version RFC3015 is the only "official" released version of Megaco/H.248, and is called "Version 1". Recommendation H.248 has not yet emerged from the publication queue at ITU, but is identical (except for boilerplate) to RFC3015. Brian > -----Original Message----- > From: mu lj [ mailto:dtxlymlj@hotmail.com <mailto:dtxlymlj@hotmail.com> ] > Sent: Friday, April 27, 2001 5:22 AM > To: megaco(a)fore.com > Subject: version > > > hi > which h.248's version refer to rfc3015. > which's h.248's version now. > > Regards > Lingjiang Mu > ______________________________________________________________ > ___________ > Get Your Private, Free E-mail from MSN Hotmail at > http://www.hotmail.com <http://www.hotmail.com> . >

1 0

AW: B.3.1/H.245v8 - Error in the description of the encryptionSyn c field
by Euchner Martin 27 Apr '01

27 Apr '01

Frank, below is the full text what H.245 Section B.3.1 says about the encryptionSync field: The encryptionSync field shall be used by the master when acknowledging the opening of a channel by a slave. It is used to provide the encryption key value and the synchronization point at which the key should be used. For H.323, the syncFlag shall be set to the RTP dynamic payload number which matches the key. H.235 Section 8.5 describes the use and purpose of encryptionSync: During the protocol exchange that establishes the logical channel, the encryption key shall be passed from the master to the slave (regardless of who initiated the OpenLogicalChannel). For media channels opened by an endpoint (other than the master), the master shall return the initial encryption key and the initial synchronization point in the OpenLogicalChannelAck (in the encryptionSync field). For media channels opened by the master, the OpenLogicalChannel shall include the initial encryption key and the synchronization point in the encryptionSync field. My understanding is that encryptionSync is part of the OLC-Ack message. As such, encryptionSync implicitly acknowledges the OpenLogicalChannel, although of course actually the OpenLogicalChannelAck is intended to explicitly acknowledge the OpenLogicalChannel. Thus, I do not really see an error. Does this answer your question? Do you see need for further clarification of either passage? 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 ----------------------------------------------------------------------- -----Ursprüngliche Nachricht----- Von: Frank Derks [SMTP:frank.derks@PHILIPS.COM] Gesendet am: Freitag, 27. April 2001 10:44 An: ITU-SG16(a)mailbag.cps.INTEL.COM Betreff: B.3.1/H.245v8 - Error in the description of the encryptionSync field B.3.1/H.245 describes the use of fields in the openLogicalChannel message. The text about the encryptionSync field looks like a literal copy of the corresponding text for the OpenLogicalChannelAck message. This would not seem to be correct, because it talks about the acknowledgement of the opening of a channel by the slave. Shouldn't the text read: "The encryptionSync field is (shall?) used by the master to provide the ebcryption key value and the synchronization point at which the key should be used. ....." Regards, Frank ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 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

B.3.1/H.245v8 - Error in the description of the encryptionSync field
by Frank Derks 27 Apr '01

27 Apr '01

B.3.1/H.245 describes the use of fields in the openLogicalChannel message. The text about the encryptionSync field looks like a literal copy of the corresponding text for the OpenLogicalChannelAck message. This would not seem to be correct, because it talks about the acknowledgement of the opening of a channel by the slave. Shouldn't the text read: "The encryptionSync field is (shall?) used by the master to provide the ebcryption key value and the synchronization point at which the key should be used. ....." Regards, Frank ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0