- sg16-avd - lists.packetizer.com

Re: IP Type of Service
by Christian Groves 09 May '01

09 May '01

I think that any work on QoS parameters should be aligned with the work occuring in ETSI Tiphon, ITU SG16, ITU SG11 etc. There's been a considerable amount of effort in trying to come up with common parameters for QoS. Any solution should tap into this. Cheers, Christian "Petros N. Mouchtaris" wrote: > > Brian, > > Actually there was a long discussion on this topic last year on the mailing > list i.e. whether MGC should be able to signal an MG which TOS bit to use. > The whole topic ended up being dropped. Check the archive for e-mails with > title "MG and DiffServ". > > By the way, Flemming had volunteered to do some work but I assume it didn't > have high enough priority. > > Excerpt from e-mail: > > "Tom-PT Taylor wrote: > > > You are correct that packages should be drawn up (and/or SDP defined) to > > allow QOS parameter setting. Volunteers? > > Sure - I can put a package proposal together. > > -- Flemming > > Petros > > "Rosen, Brian" <Brian.Rosen(a)marconi.com> on 05/08/2001 03:29:44 PM > > To: "'Tom-PT Taylor'" <taylor(a)nortelnetworks.com>, "'Madhu Babu > Brahmanapally'" <madhubabu(a)kenetec.com>, "Rosen, Brian" > <Brian.Rosen(a)marconi.com>, "'Chuong Nguyen'" > <Chuong.Nguyen(a)usa.alcatel.com>, megaco <megaco(a)fore.com> > cc: (bcc: Petros N. Mouchtaris/Telcordia) > Subject: RE: IP Type of Service > > I'll look into this. I agree. > > Brian > > -----Original Message----- > From: Tom-PT Taylor [mailto:taylor@nortelnetworks.com] > Sent: Tuesday, May 08, 2001 10:07 AM > To: 'Madhu Babu Brahmanapally'; 'Rosen, Brian'; 'Chuong Nguyen'; megaco > Subject: RE: IP Type of Service > > That makes sense. > > -----Original Message----- > From: Madhu Babu Brahmanapally [mailto:madhubabu@kenetec.com] > Sent: Tuesday, May 08, 2001 10:08 AM > To: 'Rosen, Brian'; Taylor, Tom-PT [NORSE:B881:EXCH]; 'Chuong Nguyen'; > megaco > Subject: RE: IP Type of Service > > Hi All, > Another suggestion. Why cant the SDP be extended to incorporate a TOS > parameter/attribute so that all the protocols(SIP,Megaco,MGCP) that use SDP > need not define extra properties/parameter for supporting this. > > Regards > Madhubabu > > -----Original Message----- > From: owner-megaco(a)pit.comms.marconi.com > [mailto:owner-megaco@pit.comms.marconi.com]On Behalf Of Rosen, Brian > Sent: Tuesday, May 08, 2001 9:24 AM > To: 'Madhu Babu Brahmanapally'; 'Tom-PT Taylor'; 'Chuong Nguyen'; > megaco(a)fore.com > Subject: RE: IP Type of Service > > I don't agree. The TOS for a particular stream should be set on that > stream, not > on the MG as a whole. For example, if I have a multimedia MG, I will want > to set > the priority of voice higher than video, and video higher than normal. If > I > implement a > Multilevel Pre-emption and Priority scheme, some calls will have higher > priority than > others. The TOS/frame priority has to be per stream. > > Brian > > -----Original Message----- > From: Madhu Babu Brahmanapally [mailto:madhubabu@kenetec.com] > Sent: Tuesday, May 08, 2001 9:24 AM > To: 'Rosen, Brian'; 'Tom-PT Taylor'; 'Chuong Nguyen'; megaco(a)fore.com > Subject: RE: IP Type of Service > > Hi All, > > The default TOS type should be defined on the ROOT termination for the > default TOS used for all media packets generated from the MG. There should > be a method (might be through some property) of specifying stream level TOS > bits. > > I'm interested to work on RSVP. > > Regards > Madhubabu > > -----Original Message----- > From: owner-megaco(a)pit.comms.marconi.com > [mailto:owner-megaco@pit.comms.marconi.com]On Behalf Of Rosen, Brian > Sent: Tuesday, May 08, 2001 8:10 AM > To: 'Tom-PT Taylor'; 'Chuong Nguyen'; 'megaco(a)fore.com' > Subject: RE: IP Type of Service > > TOS should not be ignored at the edge router if the router is configured to > enable DiffServ. > > It would be pretty simple to create one package that had the appropriate > controls for > DiffServ and 802.1p. RSVP needs it's own package because there is > messaging, > and you at least an event or two > > The former could be an enumeration: QosMarking, that had values None, TOS > and > FramePriority, plus another integer, Value. That would suffice I think, > although you > could conceivably get more clever with DiffServ. > > Shall I write something up along those lines? > > RSVP takes some more work. Any volunteers? > > Brian > > -----Original Message----- > From: Tom-PT Taylor [mailto:taylor@nortelnetworks.com] > Sent: Monday, May 07, 2001 9:15 PM > To: 'Chuong Nguyen'; 'megaco(a)fore.com' > Subject: RE: IP Type of Service > > No such package has yet been defined. > > Various QOS architectures can be imagined. Each would give rise to its own > package, since the MGC-MG information flow would differ from one > architecture to the next. One question: unless the MG is itself the edge > router, won't the ToS be ignored when the media packets reach the latter? > > -----Original Message----- > From: Chuong Nguyen [mailto:Chuong.Nguyen@usa.alcatel.com] > Sent: Monday, May 07, 2001 5:14 PM > To: 'megaco(a)fore.com' > Subject: IP Type of Service > > All > > In MGCP, MGC can specify IP Type of Service to the MG. > Do we have an equivalent in Megaco? > > Is there or has anyone defined a package for IP Type of Service? > > Thanks > Chuong > > -- > > Alcatel USA, Inc Internet: Chuong.Nguyen(a)usa.alcatel.com > > 1000 Coit Road Plano, Texas 75075 Phone: (972) 519-4613 > > **** The opinions expressed are not those of Alcatel USA, Inc **** > > ------------------------------------------------------------------------ > Name: att1.htm > att1.htm Type: Hypertext Markup Language (text/html) > Encoding: base64

1 0

H.323 Books and Others
by Paul E. Jones 08 May '01

08 May '01

Folks, I have received requests to bring to the attention of the H.323 community the fact that a couple of H.323 books have recently been published. Paul Long put together a nice page showing those books and other IP Telephony books on Packetizer. You can find the link here: http://www.packetizer.com/bookshelf/list.html Happy Reading! Paul ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

How to get the heel of RAS Message.
by Delphi 08 May '01

08 May '01

Hi, all: I have two problems concerning H.323 ASN.1. 1> H.323 ASN.1 states as follows: >>>>>>>>> H323-UserInformation::=SEQUENCE { h323-uu-pdu H323-UU-PDU, user-data SEQUENCE { protocol-discriminator INTEGER (0..255), user-information OCTET STRING (SIZE(1..131)), ..... }OPTIONAL, .... } <<<<<<<<<< My question is," What's the use of "user-date" field and what its protocol-discriminator field stand for? " Can anyone present me an example? 2> The H.323 ASN.1 tells us that following the path "H323-UserInformation>>h323-uu-pdu>>h323-message-body", we can get and set UUIE of Q931 messages. But how can we do the same thing with RAS messages? Or, what are the "ABSOLUTE PATH", the root, of the messages? Thanks, -Delphi

2 2

H.248 Implementors' Guide Additions V5 Update
by Christian Groves 07 May '01

07 May '01

G'Day all, I have come up with an interim version of the H.248 Implementors' Guide Additions v5. It contains additional correction to ones reviewed at the SG16 Launceston meeting. It can be found at: ftp://standard.pictel.com/avc-site/Incoming/ filenames: TD-xxx_H248_Implementors_Additions_v5.doc TD-xxx_H248_Implementors_Additions_v5.pdf Please check it for correctness and that it contains the points discussed on the list. There were also some corrections added that were not discussed on the list. If you have an issue please propose a solution giving the wording that you would like to see. As mentioned in the introduction this document is liable to change until final approval. v4 was my own edition and was not published to any external network/list so please don't look for it. Let the editor bashing begin. Cheers, Christian

5 6

Re: [wg5-3: 3592] H.323 annex D
by Francois Audet 07 May '01

07 May '01

Also check H.323 Annex D in version 4. It has the call signaling flows. Version 4 includes switching from voice to fax. > -----Original Message----- > From: chimura730(a)AINET.OKI.CO.JP [mailto:chimura730@AINET.OKI.CO.JP] > Sent: Sunday, May 06, 2001 9:08 PM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: Re: [wg5-3: 3592] H.323 annex D > > > Hi, Arie > > The Fax call flow diagram is described on T.38 Appendix II. > > Best Regards, > > Yasubumi CHIMURA > OKI Electric industry Co.,Ltd. > e-mail: chimura730(a)oki.co.jp > -----Original Message----- > ·ol : Arie Rehes <rehes(a)GADLINE.COM> > ^¶æ : ITU-SG16(a)MAILBAG.INTEL.COM <ITU-SG16(a)MAILBAG.INTEL.COM> > "úZz : 13"N2OEZ20"ú OEß'O 12:54 > OE-¼ : [wg5-3: 3592] H.323 annex D > > > >Hello, > > > >Do you know when I can see an example for Fax call flow diagram > > > >Thank you all. > > > >Arie Reches > >Program Manager > >Voice Systems Division, Com21 > >P.O Box 45138 > >Jerusalem 91450 > >Israel > > > >Tel : +972 2 541 1568 > >Fax: +972 2 586 7590 > >E-mail: areches(a)com21.com > > > >~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > >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

Re: [wg5-3: 3592] H.323 annex D
by çº Û¶ 07 May '01

07 May '01

Hi, Arie The Fax call flow diagram is described on T.38 Appendix II. Best Regards, Yasubumi CHIMURA OKI Electric industry Co.,Ltd. e-mail: chimura730(a)oki.co.jp -----Original Message----- ·ol : Arie Rehes <rehes(a)GADLINE.COM> ¶æ : ITU-SG16(a)MAILBAG.INTEL.COM <ITU-SG16(a)MAILBAG.INTEL.COM> ú : 13N220ú ßO 12:54 ¼ : [wg5-3: 3592] H.323 annex D >Hello, > >Do you know when I can see an example for Fax call flow diagram > >Thank you all. > >Arie Reches >Program Manager >Voice Systems Division, Com21 >P.O Box 45138 >Jerusalem 91450 >Israel > >Tel : +972 2 541 1568 >Fax: +972 2 586 7590 >E-mail: areches(a)com21.com > >~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >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

Call for Participation: NOSSDAV 2001
by Henning Schulzrinne 06 May '01

06 May '01

CALL FOR PARTICIPATION The 11th International Workshop on Network and Operating Systems Support for Digital Audio and Video (NOSSDAV 2001) Sponsored by the Association for Computing Machinery In cooperation with USENIX, ACM SIGCOMM, ACM SIGMM, ACM SIGOPS Technically cosponsored by the IEEE Communications Society (pending) June 25-26, 2001 Danfords on the Sound, Port Jefferson, New York http://www.nossdav.org/2001 The 11th International Workshop on Network and Operating Systems Support for Digital Audio and Video (NOSSDAV 2001) will bring together participants from academia and industry to present and discuss new ideas and future directions in networking and operating system support for multimedia. Exponential improvements in networking bandwidth, cost, and ubiquity coupled with the growing availability and use of streaming media content pose new networking and operating system research opportunities and challenges at the global systems level. Papers on streaming media, quality of service, multicast, mobile multimedia, Internet telephony, and collaboration will be presented. Peter Danzig will deliver a keynote address on "Ideas for Next Generation Content Delivery". Important Dates: ================ Early registration deadline: May 19, 2001 Registration deadline: June 15, 2001 Workshop: June 25-27, 2001 NOSSDAV 2001 Organizing Committee: ================================= Chairs: Jason Nieh, Columbia University Henning Schulzrinne, Columbia University Kevin Almeroth, UCSB Peter Danzig, Akamai Christophe Diot, Sprint Advanced Technology Labs Wu-chi Feng, Ohio State University Anoop Gupta, Microsoft Research Chuck Kalmanek, AT&T Research Sneha Kasera, Lucent Technologies Duane Northcutt, Sun Microsystems Larry Peterson, Princeton University Dan Rubenstein, Columbia University Larry Rowe, University of California, Berkeley Brian Schmidt, Sun Microsystems Doug Shepherd, Lancaster University Chuck Yoo, Korea University Zhi-Li Zhang, University of Minnesota ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

H323 TOPICS
by Rogelio SIlva (CVS) 06 May '01

06 May '01

Could you please add my e-mail id to your mailing list on any H323 topics? Thanks, Rogelio Silva Director CVS Mexico Corporate Videoconferencing Services "Su oficina virtual en todo el mundo" www.cvs.com.mx Tel (525) 208-0690

1 0

DRQ and pre-granted ARQ
by Francois Audet 05 May '01

05 May '01

Guys, When pre-granted ARQ is used on a call (on either the originating or the terminating side), do we assume that DRQ is not required when clearing a call? Couldn't find it in H.323 or H.225.0. Thanks. ---- François AUDET, Nortel Networks mailto:audet@nortelnetworks.com <mailto:audet@nortelnetworks.com> , tel:+1 408 495 3756

2 1

Re: Emergency Services and Service classes
by Roy, Radhika R, ALCOO 03 May '01

03 May '01

Hi, Gary: OK, now I understand your proposal and appreciate it. Let me suggest how we can achieve the common goal: 1. Tom Taylor is analyzing the requirements of the emergency services. We will be able to take care of the "priority" levels that have been proposed by you. 2. Mike Buckley is working for QOS and we will be able to meet the requirements of "quality" levels proposed by you. However, the solutions of both depend on solving the bigger problems. That is, we have to create the overall framework especially for the QOS. Mike, myself, and other members of the SG16 are working for a long time on QOS and you are hereby requested to participate in those discussions. AT&T is also bringing contributions along the line for QOS and I have a proposal how we can meet your proposed requirements as well. Again, I appreciate your proposal because it helps to drive for finding a common solution. Best regards, Radhika -----Original Message----- From: Gary Thom [mailto:gthom@delta-info.com] Sent: Thursday, May 03, 2001 1:42 PM To: Roy, Radhika R; ITU-SG16(a)mailbag.cps.INTEL.COM Subject: RE: Emergency Services and Service classes Radhika, I agree, lets try to harmonize all the requirements for service class signalling. I would be happy to include other requirements, but I will need input from others. I tried to make this generic, and extensible. And not specific for emergency services. In particular, I have tried to abstract priority and quality (of media streams) from quality of service signalling. I understand that there is work being done on QOS signalling, and I am not trying to replace that, but maybe be one level above that. Gary -------------------------------------------- Name : Gary A. Thom Company: Delta Information Systems, Inc. Address: 300 Welsh Rd., Bldg 3 Horsham, PA 19044 USA Phone : +1-215-657-5270 x123 Fax : +1-215-657-5273 E-mail : gthom(a)delta-info.com Website: www.delta-info.com -------------------------------------------- -----Original Message----- From: Roy, Radhika R, ALCOO [mailto:rrroy@att.com] Sent: Thursday, May 03, 2001 11:58 AM To: gthom(a)delta-info.com; ITU-SG16(a)mailbag.cps.INTEL.COM Subject: RE: Emergency Services and Service classes Hi, Gary: I provided some comments before. So, the same comments remain true. The point is that we can accommodate the service class within the framework of other requirements along with the specific requirements that you have proposed. For example, priority can be: 1. MLLP, 2. Emergency Services (as proposed by you), and 3. Other standards/proposals. Similarly, quality proposed by you can also be accommodated: 1. IETF (guaranteed, controlled, best-effort), 2. TIPHON (Best, High, Medium, Best-Effort - as proposed by you), 3. Other ISTU-T SGs, and 3. Other standard bodies/forums. In addition, there are other things as well. For example, there is a relationship (or dependency) between the priority and QOS at the call level. RAS Messages only provide the pre-call level scenarios. This also needs to be translated into call level scenarios. So, the point that I like to point out is this: Let us address this from the general framework point of view so that all cases are satisfied including yours without "hard-wired" to any particular solution. AT&T is bringing contributions along this line for the QOS and others. Best regards, Radhika R. Roy -----Original Message----- From: Gary Thom [mailto:gthom@delta-info.com] Sent: Thursday, May 03, 2001 11:07 AM To: ITU-SG16(a)MAILBAG.INTEL.COM Subject: Emergency Services and Service classes All, Attached is a preliimary copy of a contribution to the upcomming Brazil meeting. It still needs US approval. It defines service classes using the generic extensible framework, and should be more applicable than just emergency services. Extension markers were put in to allow addition of new priority and quality values. Let me know if you have any comments, suggestions, or questions. Thanks Gary -------------------------------------------- Name : Gary A. Thom Company: Delta Information Systems, Inc. Address: 300 Welsh Rd., Bldg 3 Horsham, PA 19044 USA Phone : +1-215-657-5270 x123 Fax : +1-215-657-5273 E-mail : gthom(a)delta-info.com Website: www.delta-info.com -------------------------------------------- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

Re: Emergency Services and Service classes
by Roy, Radhika R, ALCOO 03 May '01

03 May '01

Hi, Gary: I provided some comments before. So, the same comments remain true. The point is that we can accommodate the service class within the framework of other requirements along with the specific requirements that you have proposed. For example, priority can be: 1. MLLP, 2. Emergency Services (as proposed by you), and 3. Other standards/proposals. Similarly, quality proposed by you can also be accommodated: 1. IETF (guaranteed, controlled, best-effort), 2. TIPHON (Best, High, Medium, Best-Effort - as proposed by you), 3. Other ISTU-T SGs, and 3. Other standard bodies/forums. In addition, there are other things as well. For example, there is a relationship (or dependency) between the priority and QOS at the call level. RAS Messages only provide the pre-call level scenarios. This also needs to be translated into call level scenarios. So, the point that I like to point out is this: Let us address this from the general framework point of view so that all cases are satisfied including yours without "hard-wired" to any particular solution. AT&T is bringing contributions along this line for the QOS and others. Best regards, Radhika R. Roy -----Original Message----- From: Gary Thom [mailto:gthom@delta-info.com] Sent: Thursday, May 03, 2001 11:07 AM To: ITU-SG16(a)MAILBAG.INTEL.COM Subject: Emergency Services and Service classes All, Attached is a preliimary copy of a contribution to the upcomming Brazil meeting. It still needs US approval. It defines service classes using the generic extensible framework, and should be more applicable than just emergency services. Extension markers were put in to allow addition of new priority and quality values. Let me know if you have any comments, suggestions, or questions. Thanks Gary -------------------------------------------- Name : Gary A. Thom Company: Delta Information Systems, Inc. Address: 300 Welsh Rd., Bldg 3 Horsham, PA 19044 USA Phone : +1-215-657-5270 x123 Fax : +1-215-657-5273 E-mail : gthom(a)delta-info.com Website: www.delta-info.com -------------------------------------------- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

2 1

AW: Emergency Services and Service classes
by Horvath Ernst 03 May '01

03 May '01

Gary, after skimming over your contribution, two immediate comments: 1) QoS signalling within your serviceClass may overlap (or even conflict) with what will eventually appear in H.323 annex N. We should try to have QOS information in one place only. ServiceClass is one possible place, but then we should make sure that it covers also the requirements of annex N. 2) For the terminating side, the primary goal should be protection. In other words, the called party would be protected against calls below a certain class of service ("do not disturb unless it's urgent"), and existing calls would not be affected unless resources are needed for a call with higher priority. It may even be worthwhile to specify separate protection levels separate from priority levels. For example, the call intrusion supplementary service recently approved by SG16 (Rec. H.450.11) follows such a concept: the caller is only allowed to intrude on an established call if his capability level is higher than the combined protection levels of the called party and the remote party of the established call. Ernst Horvath Siemens AG > -----Ursprüngliche Nachricht----- > Von: Gary Thom [mailto:gthom@delta-info.com] > Gesendet am: Donnerstag, 03. Mai 2001 17:07 > An: ITU-SG16(a)mailbag.cps.INTEL.COM > Betreff: Emergency Services and Service classes > > All, > > Attached is a preliimary copy of a contribution to the > upcomming Brazil > meeting. It still needs US approval. > > It defines service classes using the generic extensible framework, and > should be more applicable than just emergency services. > Extension markers > were put in to allow addition of new priority and quality values. > > Let me know if you have any comments, suggestions, or questions. > > Thanks > Gary > > -------------------------------------------- > Name : Gary A. Thom > Company: Delta Information Systems, Inc. > Address: 300 Welsh Rd., Bldg 3 > Horsham, PA 19044 USA > Phone : +1-215-657-5270 x123 > Fax : +1-215-657-5273 > E-mail : gthom(a)delta-info.com > Website: www.delta-info.com > -------------------------------------------- >

1 0

Emergency Services and Service classes
by Gary Thom 03 May '01

03 May '01

I would like to re-open the discussion started at the Nov 2000 Geneva meeting and continued at the March 2001 Launceston meeting relating to Emergency Services. In order to support Emergency Services, there are three services that are desired: 1)Priority Dial Tone - this is a line or endpoint dedicated to emergency calls. 2)Priority Call Setup - this allows an emegency call to be made from any endpoint. 3)Priority Call transit through packet network - this requires interworking existing ISUP high probability of completion call marking with H.323, H.323 Annex M.2, h.246 Annex C, and H.248. An emergency call may be pre-emptive or may just improve the probability of call completion without pre-emption depending on national policy. Authentication issues also need to be worked out. Currently, in the US, this is handled like a calling card authentication. At the Geneva meeting, it was decided that this work was closely related to contribution D.4 from Cicso on reserving resources and also Annex N/H.323 on QOS. Also included were liaison statements from SG11 on QOS for BICC, and an ETSI TIPHON document on signaling end-to-end-qos. All of these items require a method of signaling the desired quality of service. One way of doing this that seems to be common to all requirements is to specify a Service Class parameter and to send this parameter in the various RAS and Call Signaling exchanges. 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 } } 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. The quality field is taken from the ETSI TIPHON QOS Class definitions, and relate to bitrate, codec type, and voice or video quality. High or emergency priority calls may not require best audio quality, medium may be sufficient (even prefered because of the lower bandwidth requirement), while normal priority calls may desire high or best audio quality. The Service Class parameter would then be added to the necessary RAS and Call Signalling messages. At a minimum this would include the ARQ and Setup messages, but might also be applied to others. It is necessary in the ARQ and Setup messages so that High Probability of Completion calls comming into the network from the PSTN can be given priority treatment. For priority dial tone, perhaps the Service Class should be included in the RRQ to indicate the desired priority, once authenticated by the Gatekeeper and confirmed in the RCF, this endpoint could then include that Service Class in subsequent ARQ and Setup messages. Is a token required from the Gatekeeper to indicate that the endpoint has been granted priority status???? For priority call completion, an authentication authority and procedure needs to be defined. One approach is for the call to be made to an access number, the user is then queried for a PIN and the called endpoint number. After authentication, the call would be transfered to the called endpoint. The transfered call would be placed using the Service Class provided by the athentication authority. This would be the same procedure for any calling card call made on the packet network. The Service Class would be based on teh service level agreement between the card user and the provider. In the case of an emergency caller, the SLA would indicate Emergency Priority. How are calling card calls handled on packet networks now???? Is this consistent??? I would appreciate any input that you could provide. Gary -------------------------------------------- Name : Gary A. Thom Company: Delta Information Systems, Inc. Address: 300 Welsh Rd., Bldg 3 Horsham, PA 19044 USA Phone : +1-215-657-5270 x123 Fax : +1-215-657-5273 E-mail : gthom(a)delta-info.com Website: www.delta-info.com -------------------------------------------- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 1

Re: The use of statusDeterminationNumber in masterSlaveDeterminat ion
by Mike Nilsson 03 May '01

03 May '01

Frank, I do not see any conflict between the text that you have quoted and the figure. I do not understand how you can say using modulo arithmetic has no effect. For example, 1 - 2 = -1, but 1 - 2 modulo 2^24 is 2^24 - 1. The absolute value of the difference between local and received values can not be used as this would be the same at both ends, hence both would conclude to being the master (or both the slave). Best regards Mike Nilsson -------------------- Mike Nilsson Advanced Video Services > BTexact Technologies > Callisto House, B81 Room 102 pp14 Adastral Park, Martlesham Heath, Ipswich, IP5 3RE, UK Tel: +44 1473 645413 Mobile: +44 7808 635412 Fax: +44 1473 646589 Email: mike.nilsson(a)bt.com BTexact Technologies is a trademark of British Telecommunications plc Registered office: 81 Newgate Street London EC1A 7AJ Registered in England no. 1800000 This electronic message contains information from British Telecommunications plc which may be privileged or confidential. The information is intended to be for the use of the individual(s) or entity named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information is prohibited. If you have received this electronic message in error, please notify us by telephone or email (to the numbers or address above) immediately. > -----Original Message----- > From: frank.derks(a)philips.com [SMTP:frank.derks@philips.com] > Sent: Thursday, May 03, 2001 3:23 PM > To: mike.nilsson > Cc: itu-sg16 > Subject: RE: The use of statusDeterminationNumber in > masterSlaveDeterminat ion > > Mike, > > the figure only partly solves the problem. The text that I referred > to does not reflect what is in the figure, so this should be corrected. > > Furthermore, since the values that statusDeterminationNumber can take > on are in the range 0..(2^24-1). The "modulo operation" with 2^24 > has no effect whatsoever. > > It would seem that the real intent is that the _absolute_ value of the > difference between the received statusDeterminationNumber and the > locally generated statusDeterminationNumber determines which party is > to become the master and which party is to becomes the slave. If the > difference is smaller than 2^23 then the party that received the > masterSlaveDetermination message becomes the master. Otherwise it > becomes the slave. In the case that the two numbers are equal, the > result is indeterminate. > > Regards, > > Frank > > > ----------------------------------------------------- > Frank Derks |Tel +31 35 6893238 | > ServWare |Fax +31 35 6891030 | > Philips Business Communications|P.O. Box 32 | > |1200 JD Hilversum | > |The Netherlands | > ----------------------------------------------------| > E-mail: mailto:frank.derks@philips.com | > WWW: http://www.sopho.philips.com | > ----------------------------------------------------- > > > > > > mike.nilsson(a)bt.com on 03-05-2001 16:04:45 > To: Frank Derks/HVS/BE/PHILIPS@EMEA2 > cc: > Subject: RE: The use if statusDeterminationNumber in > masterSlaveDeterminat ion > Classification: > > > Frank, > > The answer is in Figure C.4(v) of H.245. > > Best regards > > Mike Nilsson > > -------------------- > Mike Nilsson > Advanced Video Services > > BTexact Technologies > > > Callisto House, B81 Room 102 pp14 > Adastral Park, Martlesham Heath, Ipswich, IP5 3RE, UK > Tel: +44 1473 645413 > Mobile: +44 7808 635412 > Fax: +44 1473 646589 > Email: mike.nilsson(a)bt.com > > > BTexact Technologies is a trademark of British Telecommunications plc > Registered office: 81 Newgate Street London EC1A 7AJ > Registered in England no. 1800000 > > This electronic message contains information from British > Telecommunications > plc which may be privileged or confidential. The information is intended > to > be for the use of the individual(s) or entity named above. If you are not > the intended recipient be aware that any disclosure, copying, distribution > or use of the contents of this information is prohibited. If you have > received this electronic message in error, please notify us by telephone > or > email (to the numbers or address above) immediately. > > > > -----Original Message----- > > From: Frank Derks [SMTP:frank.derks@PHILIPS.COM] > > Sent: Thursday, May 03, 2001 1:51 PM > > To: ITU-SG16(a)MAILBAG.INTEL.COM > > Subject: The use if statusDeterminationNumber in > > masterSlaveDetermination > > > > 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 > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

Re: The use of statusDeterminationNumber in masterSlaveDeterminat ion
by Frank Derks 03 May '01

03 May '01

Mike, the figure only partly solves the problem. The text that I referred to does not reflect what is in the figure, so this should be corrected. Furthermore, since the values that statusDeterminationNumber can take on are in the range 0..(2^24-1). The "modulo operation" with 2^24 has no effect whatsoever. It would seem that the real intent is that the _absolute_ value of the difference between the received statusDeterminationNumber and the locally generated statusDeterminationNumber determines which party is to become the master and which party is to becomes the slave. If the difference is smaller than 2^23 then the party that received the masterSlaveDetermination message becomes the master. Otherwise it becomes the slave. In the case that the two numbers are equal, the result is indeterminate. Regards, Frank ----------------------------------------------------- Frank Derks |Tel +31 35 6893238 | ServWare |Fax +31 35 6891030 | Philips Business Communications|P.O. Box 32 | |1200 JD Hilversum | |The Netherlands | ----------------------------------------------------| E-mail: mailto:frank.derks@philips.com | WWW: http://www.sopho.philips.com | ----------------------------------------------------- mike.nilsson(a)bt.com on 03-05-2001 16:04:45 To: Frank Derks/HVS/BE/PHILIPS@EMEA2 cc: Subject: RE: The use if statusDeterminationNumber in masterSlaveDeterminat ion Classification: Frank, The answer is in Figure C.4(v) of H.245. Best regards Mike Nilsson -------------------- Mike Nilsson Advanced Video Services > BTexact Technologies > Callisto House, B81 Room 102 pp14 Adastral Park, Martlesham Heath, Ipswich, IP5 3RE, UK Tel: +44 1473 645413 Mobile: +44 7808 635412 Fax: +44 1473 646589 Email: mike.nilsson(a)bt.com BTexact Technologies is a trademark of British Telecommunications plc Registered office: 81 Newgate Street London EC1A 7AJ Registered in England no. 1800000 This electronic message contains information from British Telecommunications plc which may be privileged or confidential. The information is intended to be for the use of the individual(s) or entity named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information is prohibited. If you have received this electronic message in error, please notify us by telephone or email (to the numbers or address above) immediately. > -----Original Message----- > From: Frank Derks [SMTP:frank.derks@PHILIPS.COM] > Sent: Thursday, May 03, 2001 1:51 PM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: The use if statusDeterminationNumber in > masterSlaveDetermination > > 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 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

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