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

Re: Ad Hoc Mobility Group
by Roy, Radhika R, ALARC 20 Feb '00

20 Feb '00

Hi, Everyone: I missed one point in the last email. We would also like to thank Ed for his excellent effort as an editor of H.323 Annex H in a difficult time when the idea H.323 mobility was yet to be clearer differentiating itself from lower layer IP and wireless mobility. More importantly, Ed will be around with us as a contributor which is the most important need for H.323 Annex H. Best regards, Radhika R. Roy, AT&T H.323 Ad Hoc Mobility Group PS: Paul Guram - It is OK for me for the conf call on March 20, 22, 23, & 24 (NOT on March 21). -----Original Message----- From: Roy, Radhika R, ALARC Sent: Sunday, February 20, 2000 1:28 PM To: ITU-SG16(a)MAILBAG.INTEL.COM Subject: Re: Ad Hoc Mobility Group Hi, Everyone: Let us all welcome Paul in his effort to continue the work of H.323 Annex H for arranging the conference calls between now and the next Rap. meeting to be held on May 15-19 so that we can determine this important document in November 2000. Let us also welcome Jaakko to work as the editor of Annex H as well as Paul Reddy for his excellent job for performing his work related to H.246 Annex E which had been determined in the last Feb 7-18 SG16 meeting. Now we have set a mark that H.323 is becoming ready to support mobility. The next important thing is that we have to complete H.323 Annex H first. As Paul pointed out: Let us start with a scenario of H.323 - Roaming within an H.323 Network. In the meantime, I also have a plan to send an email to Jean-Claude related to VLF and HLF information flows in the context H.323 mobility. I guess that this will also provide an opportunity to all how this problem can be addressed in the context of H.323 mobility. The time in the conference call is very precious and we only be able to hold few conferences before the next Rap. meeting. We definitely have to make decisions more quickly in the conf calls for putting more stuffs by the editor so that the document can take a reasonable shape for determination in November 2000. We hope that we have crossed the first phase of our understanding how we can address H.323 mobility problems. Any discussions via emails will expedite our understanding more quickly because the time in the conference calls is very short. I would also request Paul to clarify how the contributions for the conference calls could be sent(I guess that the editor will be the right person). Editor can provide the URL and contribution number as we did in the past. Best Regards, Radhika R. Roy AT&T +1 732 420 1580 rrroy(a)att.com -----Original Message----- From: Guram Paul-LPG019 [mailto:lpg019@EMAIL.MOT.COM] Sent: Saturday, February 19, 2000 6:06 PM To: ITU-SG16(a)MAILBAG.INTEL.COM Subject: Ad Hoc Mobility Group Hello SG16 ad hoc mobility group members, The following is a report on the current status and future plan of this ad hoc group. If I have missed out on any important points please respond to the group. 1. To ensure rapid completion of sufficient work in Annex H such that it can be considered for determination at the earliest opportunity, Paul Guram (Motorola) has been elected to chair future meetings of the mobility ad hoc group. It is planned to hold a number of conference calls, kindly facilitated by IMTC (as before), between now and the Rapporteurs meeting in May in Osaka. The group will always endeavour to reach quick agreed conclusions, after appropriate debate, to help the editor of Annex H to complete his task. 2. Ed Martinez (Motorola) has indicated that, due to his time being taken up by other work in his company, he is unable to additionally carry out the duties of the editorship for Annex H. The ad group will miss Ed and would like to thank him for the work he did and the leadership he showed in making mobility part of the overall H.323 agenda. Jaakko Sundquist (Nokia), who performed the editor's work in the Geneva meeting because of Ed's absence, has accepted to become the new editor for Annex H. This will, no doubt, be officially confirmed by Dale Skran (Q13 Rapporteur) in due course. 3. The next conference call is planned to be during the week beginning 20 March. Please inform me personally, i.e. not via the reflector, as to which dates (20 March to 24 March) are suitable for you to attend, and I will then arrange for the meeting to take place on the most appropriate date. The agenda of this meeting is as below. The main objective is to (a) define mobility scenarios, and (b) to agree on the scenario that we will pursue first for Annex H. This will help to focus on our work of defining all the aspects of this chosen scenario under the guidelines of our agreed terms of reference at the Geneva meeting. (To help in defining the scenarios, a look at the ETSI Tiphon scenarios may be useful. However, typical example scenarios are "roaming within an H.323 network", "inter-working between PSTN and H.323 networks for terminals" etc. etc. Contributions (with diagrams) on the scenario topics are to be sent via the reflector by Friday the 10th March. This will give all the participants enough time to consider the proposals for the meeting. This will allow discussion on items already seen and studied by the participants, thus saving time on lengthy presentations by the contributors, and secondly allowing participants, who may not to be able to take part in the live discussions, to have the opportunity to communicate their comments via email. Agenda: 1. Brief Introductions and agreement of agenda 2. Mobility Scenarios for Annex H 3. Adoption of the first scenario to study (in its entirety) 4. Issues related to the progress on Annex I, and H.246 Annex E 5. Report back from other mobility groups (3GPP, 3G.IP, IMT2000, MWIF, etc.). (this will be given by any participant who attends/has access to the appropriate group, and information will be that relevant to our work) 6. Any other business 7. Agenda and date of next conference call 4. On 17 February morning there was a joint ad hoc meeting with the JQG4 from SG11. See the notes below which are also being sent to JQG4. Interaction between JQG4 and our ad hoc group will continue at appropriate times in order to advance our respective work in the two groups. Notes of a Joint Ad Hoc Meeting between SG11/ JQG4 and SG16/Ad hoc Mobility Group, on Thursday 17 February 2000 in Geneva Present: Jean-Claude Samou France Telecom Frederic Delmond France Telecom Janusz Dobrowaski Lucent Technologies Vineet Kumar INTEL Paul Reddy INTEL Nicolas Tran Alcatel CIT Tatiana Tchaika ITU-T Paul Guram Motorola JQG4 Issue Manager Jean-Claude Samou explained that there are five JQGs in the IMT2000 area: JQG1 deals with radio aspects. Matters on the air interface are directly handled by other bodies such as 3GPP, JQG2 did not start, JQG3 deals with VHE scenarios and protocols. Since this is IN related, Question 22 of SG11 progresses the work, JQG4 deals with the Mobility Management aspects, and JQG5 deals with the bearer control protocol and moves are afoot to move this work into WP2 of SG11. There is work in the IMT2000 area which could help the work in the SG16 mobility ad hoc group: H.246 Annex E defines the NNI between H.323 and GSM/ANSI-41. Work on the development of a common mobility management protocol is going on in IMT2000. We need to look at how each group can help each other in this respect, and see if the common set of operations could be adopted for the SG16. A generic state machine being developed Q22/11 should be studied to help the SG16 ad hoc group to see if it can be applicable to the packet network. The relevant recommendations for study are Q.1751 and Q.1721. Mr Delmond presented the following output document. This was seen as very useful input into the later work to be done within Annex H. <<JQG4 Output Geneva 9910 v5.1.doc>> Regards Paul

2 1

Re: Ad Hoc Mobility Group
by Roy, Radhika R, ALARC 20 Feb '00

20 Feb '00

Hi, Everyone: Let us all welcome Paul in his effort to continue the work of H.323 Annex H for arranging the conference calls between now and the next Rap. meeting to be held on May 15-19 so that we can determine this important document in November 2000. Let us also welcome Jaakko to work as the editor of Annex H as well as Paul Reddy for his excellent job for performing his work related to H.246 Annex E which had been determined in the last Feb 7-18 SG16 meeting. Now we have set a mark that H.323 is becoming ready to support mobility. The next important thing is that we have to complete H.323 Annex H first. As Paul pointed out: Let us start with a scenario of H.323 - Roaming within an H.323 Network. In the meantime, I also have a plan to send an email to Jean-Claude related to VLF and HLF information flows in the context H.323 mobility. I guess that this will also provide an opportunity to all how this problem can be addressed in the context of H.323 mobility. The time in the conference call is very precious and we only be able to hold few conferences before the next Rap. meeting. We definitely have to make decisions more quickly in the conf calls for putting more stuffs by the editor so that the document can take a reasonable shape for determination in November 2000. We hope that we have crossed the first phase of our understanding how we can address H.323 mobility problems. Any discussions via emails will expedite our understanding more quickly because the time in the conference calls is very short. I would also request Paul to clarify how the contributions for the conference calls could be sent(I guess that the editor will be the right person). Editor can provide the URL and contribution number as we did in the past. Best Regards, Radhika R. Roy AT&T +1 732 420 1580 rrroy(a)att.com -----Original Message----- From: Guram Paul-LPG019 [mailto:lpg019@EMAIL.MOT.COM] Sent: Saturday, February 19, 2000 6:06 PM To: ITU-SG16(a)MAILBAG.INTEL.COM Subject: Ad Hoc Mobility Group Hello SG16 ad hoc mobility group members, The following is a report on the current status and future plan of this ad hoc group. If I have missed out on any important points please respond to the group. 1. To ensure rapid completion of sufficient work in Annex H such that it can be considered for determination at the earliest opportunity, Paul Guram (Motorola) has been elected to chair future meetings of the mobility ad hoc group. It is planned to hold a number of conference calls, kindly facilitated by IMTC (as before), between now and the Rapporteurs meeting in May in Osaka. The group will always endeavour to reach quick agreed conclusions, after appropriate debate, to help the editor of Annex H to complete his task. 2. Ed Martinez (Motorola) has indicated that, due to his time being taken up by other work in his company, he is unable to additionally carry out the duties of the editorship for Annex H. The ad group will miss Ed and would like to thank him for the work he did and the leadership he showed in making mobility part of the overall H.323 agenda. Jaakko Sundquist (Nokia), who performed the editor's work in the Geneva meeting because of Ed's absence, has accepted to become the new editor for Annex H. This will, no doubt, be officially confirmed by Dale Skran (Q13 Rapporteur) in due course. 3. The next conference call is planned to be during the week beginning 20 March. Please inform me personally, i.e. not via the reflector, as to which dates (20 March to 24 March) are suitable for you to attend, and I will then arrange for the meeting to take place on the most appropriate date. The agenda of this meeting is as below. The main objective is to (a) define mobility scenarios, and (b) to agree on the scenario that we will pursue first for Annex H. This will help to focus on our work of defining all the aspects of this chosen scenario under the guidelines of our agreed terms of reference at the Geneva meeting. (To help in defining the scenarios, a look at the ETSI Tiphon scenarios may be useful. However, typical example scenarios are "roaming within an H.323 network", "inter-working between PSTN and H.323 networks for terminals" etc. etc. Contributions (with diagrams) on the scenario topics are to be sent via the reflector by Friday the 10th March. This will give all the participants enough time to consider the proposals for the meeting. This will allow discussion on items already seen and studied by the participants, thus saving time on lengthy presentations by the contributors, and secondly allowing participants, who may not to be able to take part in the live discussions, to have the opportunity to communicate their comments via email. Agenda: 1. Brief Introductions and agreement of agenda 2. Mobility Scenarios for Annex H 3. Adoption of the first scenario to study (in its entirety) 4. Issues related to the progress on Annex I, and H.246 Annex E 5. Report back from other mobility groups (3GPP, 3G.IP, IMT2000, MWIF, etc.). (this will be given by any participant who attends/has access to the appropriate group, and information will be that relevant to our work) 6. Any other business 7. Agenda and date of next conference call 4. On 17 February morning there was a joint ad hoc meeting with the JQG4 from SG11. See the notes below which are also being sent to JQG4. Interaction between JQG4 and our ad hoc group will continue at appropriate times in order to advance our respective work in the two groups. Notes of a Joint Ad Hoc Meeting between SG11/ JQG4 and SG16/Ad hoc Mobility Group, on Thursday 17 February 2000 in Geneva Present: Jean-Claude Samou France Telecom Frederic Delmond France Telecom Janusz Dobrowaski Lucent Technologies Vineet Kumar INTEL Paul Reddy INTEL Nicolas Tran Alcatel CIT Tatiana Tchaika ITU-T Paul Guram Motorola JQG4 Issue Manager Jean-Claude Samou explained that there are five JQGs in the IMT2000 area: JQG1 deals with radio aspects. Matters on the air interface are directly handled by other bodies such as 3GPP, JQG2 did not start, JQG3 deals with VHE scenarios and protocols. Since this is IN related, Question 22 of SG11 progresses the work, JQG4 deals with the Mobility Management aspects, and JQG5 deals with the bearer control protocol and moves are afoot to move this work into WP2 of SG11. There is work in the IMT2000 area which could help the work in the SG16 mobility ad hoc group: H.246 Annex E defines the NNI between H.323 and GSM/ANSI-41. Work on the development of a common mobility management protocol is going on in IMT2000. We need to look at how each group can help each other in this respect, and see if the common set of operations could be adopted for the SG16. A generic state machine being developed Q22/11 should be studied to help the SG16 ad hoc group to see if it can be applicable to the packet network. The relevant recommendations for study are Q.1751 and Q.1721. Mr Delmond presented the following output document. This was seen as very useful input into the later work to be done within Annex H. <<JQG4 Output Geneva 9910 v5.1.doc>> Regards Paul

1 0

Some questions regarding H.341
by Michaela Goffri 20 Feb '00

20 Feb '00

Hi, Can anyone answer the following questions regarding H.341: Procedural: 1. What is the status of the document: is it scheduled to become a standard and if yes, when? 2. Is there any mailing lists/discussion forums to get clarifications/suggestions? Following are the technical questions: 1. In the proposed model (Figure 2), when the entire GW is represented as an interface, what type this interface is? Are RAS/H.225/H.245 represented as a separate ifIndex entries and if yes of what type and what is the ifStack model for them? 2. Should a linkUp/linkDown/coldStart traps be sent for this interface or it is implementation dependent? 3. In the MmTerminalDataCapability textual convention there is no t38fax. How to report the t38? H.225 in GW: 4. Should the callsignalStatsTable be implemented in the GW? Most (if not all) counters will be incremented for both incoming and outgoing directions. Is this the intention? Which side is considered as "In" and which side is considered as "Out" for GW? 5. Why callSignalConfigT303 and callSignalConfigT3031 do not have a DEFVAL as defined in H225. RAS in GW: 6. rasConfigurationGatekeeperIdentifier is defined as read-only. As such, it is impossible to remotely configure a desired GK. Shouldn't it be RW? 7. rasConfigurationGatekeeperDiscoveryAddress: the purpose is not clear. Is it a configured (by user) GK address or it is the GK address, resulted from discovery process? In the first case, shouldn't it be RW? 8. rasRegistrationTable : how many entries are in this table for a GW? Just one? 9. rasRegistrationAliasTable : for the GW it is the list of all aliases it registered in the GK? 10. rasRegistrationAliasTable : What is the intention for GW? To keep entry in the table for every call? If yes, how the calls are represented: those, coming from the lan, have the source address of the endpoint and destination of a GW and those, coming from the SCN vice versa? 11. rasConfigurationTable : the description says ".... The number of entries equals to the number of configuration parameters." If the table is indexed by the ifIndex, why the number of parameters is relevant? H.245 in GW: 12. h245ConfigurationTable : the description says "..The number of entries equals to the number of H.245 stacks in a system.". Why there supposed to be several H.245 stacks in the system? For different versions of H.245? 13. h245CapExchangeStatsTable : is this table applicable for a GW? Gateway 14.h323GwSystemTable : all entries in the table (except ..LocalTime) are read only. It seems others could be made read-write in order to allow remote changes (like location, contact person, country code). 15. h323GwConfigurationH323Table : h323GwConfigurationH323CallSignalingAddressTag and h323GwConfigurationH323CallSignalingAddress are defined read-only. It seems if they where defined read-write, it would allow change of this address to a non-standard value. Otherwise, they either contain a well-known address or an address which is configured by other means (like RS232). having these entries RW, would allow easy remote management . On the other hand, h323GwConfigurationH323GatekeeperAddressTag and h323GwConfigurationH323GatekeeperAddress are defined as read-write. Isn't it in contradiction with the description of this variable? Why to allow to the user to change the address of the gatekeeper, this GW is registered with? 16. h323GwCapabilitiesPstnTotalPorts : is it the total number of say, E1/T1 ports this GW supports? 17. h323GwConnectionsCommand : why it is read-write? To allow manager to control the call state remotely? In which cases it might be useful? 18. h323GwConnectionsPstnTable : Currently the table contains only an index. What else supposed to be defined there? Thanks, Michaela

1 0

Ad Hoc Mobility Group
by Guram Paul-LPG019 19 Feb '00

19 Feb '00

Hello SG16 ad hoc mobility group members, The following is a report on the current status and future plan of this ad hoc group. If I have missed out on any important points please respond to the group. 1. To ensure rapid completion of sufficient work in Annex H such that it can be considered for determination at the earliest opportunity, Paul Guram (Motorola) has been elected to chair future meetings of the mobility ad hoc group. It is planned to hold a number of conference calls, kindly facilitated by IMTC (as before), between now and the Rapporteurs meeting in May in Osaka. The group will always endeavour to reach quick agreed conclusions, after appropriate debate, to help the editor of Annex H to complete his task. 2. Ed Martinez (Motorola) has indicated that, due to his time being taken up by other work in his company, he is unable to additionally carry out the duties of the editorship for Annex H. The ad group will miss Ed and would like to thank him for the work he did and the leadership he showed in making mobility part of the overall H.323 agenda. Jaakko Sundquist (Nokia), who performed the editor's work in the Geneva meeting because of Ed's absence, has accepted to become the new editor for Annex H. This will, no doubt, be officially confirmed by Dale Skran (Q13 Rapporteur) in due course. 3. The next conference call is planned to be during the week beginning 20 March. Please inform me personally, i.e. not via the reflector, as to which dates (20 March to 24 March) are suitable for you to attend, and I will then arrange for the meeting to take place on the most appropriate date. The agenda of this meeting is as below. The main objective is to (a) define mobility scenarios, and (b) to agree on the scenario that we will pursue first for Annex H. This will help to focus on our work of defining all the aspects of this chosen scenario under the guidelines of our agreed terms of reference at the Geneva meeting. (To help in defining the scenarios, a look at the ETSI Tiphon scenarios may be useful. However, typical example scenarios are "roaming within an H.323 network", "inter-working between PSTN and H.323 networks for terminals" etc. etc. Contributions (with diagrams) on the scenario topics are to be sent via the reflector by Friday the 10th March. This will give all the participants enough time to consider the proposals for the meeting. This will allow discussion on items already seen and studied by the participants, thus saving time on lengthy presentations by the contributors, and secondly allowing participants, who may not to be able to take part in the live discussions, to have the opportunity to communicate their comments via email. Agenda: 1. Brief Introductions and agreement of agenda 2. Mobility Scenarios for Annex H 3. Adoption of the first scenario to study (in its entirety) 4. Issues related to the progress on Annex I, and H.246 Annex E 5. Report back from other mobility groups (3GPP, 3G.IP, IMT2000, MWIF, etc.). (this will be given by any participant who attends/has access to the appropriate group, and information will be that relevant to our work) 6. Any other business 7. Agenda and date of next conference call 4. On 17 February morning there was a joint ad hoc meeting with the JQG4 from SG11. See the notes below which are also being sent to JQG4. Interaction between JQG4 and our ad hoc group will continue at appropriate times in order to advance our respective work in the two groups. Notes of a Joint Ad Hoc Meeting between SG11/ JQG4 and SG16/Ad hoc Mobility Group, on Thursday 17 February 2000 in Geneva Present: Jean-Claude Samou France Telecom Frederic Delmond France Telecom Janusz Dobrowaski Lucent Technologies Vineet Kumar INTEL Paul Reddy INTEL Nicolas Tran Alcatel CIT Tatiana Tchaika ITU-T Paul Guram Motorola JQG4 Issue Manager Jean-Claude Samou explained that there are five JQGs in the IMT2000 area: JQG1 deals with radio aspects. Matters on the air interface are directly handled by other bodies such as 3GPP, JQG2 did not start, JQG3 deals with VHE scenarios and protocols. Since this is IN related, Question 22 of SG11 progresses the work, JQG4 deals with the Mobility Management aspects, and JQG5 deals with the bearer control protocol and moves are afoot to move this work into WP2 of SG11. There is work in the IMT2000 area which could help the work in the SG16 mobility ad hoc group: H.246 Annex E defines the NNI between H.323 and GSM/ANSI-41. Work on the development of a common mobility management protocol is going on in IMT2000. We need to look at how each group can help each other in this respect, and see if the common set of operations could be adopted for the SG16. A generic state machine being developed Q22/11 should be studied to help the SG16 ad hoc group to see if it can be applicable to the packet network. The relevant recommendations for study are Q.1751 and Q.1721. Mr Delmond presented the following output document. This was seen as very useful input into the later work to be done within Annex H. <<JQG4 Output Geneva 9910 v5.1.doc>> Regards Paul

1 0

FW: Protocol Action: RTP Payload for Text Conversation to Proposed Standard
by Gunnar Hellstrom 18 Feb '00

18 Feb '00

As you see below, RTP-Text for transport of T.140 text conversation in IP environments is approved by the IESG. An RFC number will be assigned soon. This was a prerequisite for approval of H.323 Annex G Text Conversation and Text SET. Best regards Gunnar Hellström ------------------------------------------ Gunnar Hellstrom LM Ericsson E-mail gunnar.hellstrom(a)omnitor.se Tel +46 8 556 002 03 Mob +46 708 204 288 fax +46 8 556 002 06 -----Original Message----- From: scoya(a)cnri.reston.va.us [mailto:scoya@cnri.reston.va.us]On Behalf Of The IESG Sent: Friday, February 18, 2000 6:21 PM To: IETF-Announce: ; Cc: RFC Editor; Internet Architecture Board; rem-conf(a)es.net Subject: Protocol Action: RTP Payload for Text Conversation to Proposed Standard The IESG has approved the Internet-Draft 'RTP Payload for Text Conversation' <draft-ietf-avt-rtp-text-05.txt> as a Proposed Standard. This document is the product of the Audio/Video Transport Working Group. The IESG contact persons are Scott Bradner and Vern Paxson. Technical Summary This document defines a way to carry low-rate text in RTP packets, in accordance with ITU-T Recommendation T.140. The payload format provides for non-duplicated, in-order delivery, with loss detection and optional limited loss recovery via redundancy. Working Group Summary The initial draft was revised as a result of input from the working group and there is good working group consensus for publishing the document. Protocol Quality Vern Paxson reviewed the the spec for the IESG. Note to RFC Editor: The IESG requests that the Revision History section at the end of the document be removed prior to publication as an RFC.

1 0

Re: Guidance from the Dalai Lama and Abba Eban
by Gösta Linder (LME) 18 Feb '00

18 Feb '00

Another wise comment by Abba Ebban 1915 that still might be relevant; "History teaches us that men and nations behave wisely once they have exhausted all other alternatives." Be happy/Gösta -----Original Message----- From: Greg Ratta [mailto:gratta@lucent.com] Sent: den 18 februari 2000 15:42 To: ITU-SG16(a)mailbag.cps.intel.com Subject: Guidance from the Dalai Lama As we are finishing the ITU-T SG 16 meeting and observing the recent activity moving forward ITU-T Recommendation H.248 / Megaco, I found this gem attributed to be from the Dalai Lama. I hope you find it as enjoyable and relevant as I did. My only regret is that this did not pass my way two weeks ago. I N S T R U C T I O N S F O R L I F E 1. Take into account that great love and great achievements involve great risk. 2. When you lose, don't lose the lesson. 3. Follow the three Rs: - Respect for self - Respect for others and - Responsibility for all your actions. 4. Remember that not getting what you want is sometimes a wonderful stroke of luck. 5. Learn the rules so you know how to break them properly. 6. Don't let a little dispute injure a great friendship. 7. When you realize you've made a mistake, take immediate steps to correct it. 8. Spend some time alone every day. 9. Open your arms to change, but don't let go of your values. 10. Remember that silence is sometimes the best answer. 11. Live a good, honorable life. Then when you get older and think back, you'll be able to enjoy it a second time. 12. A loving atmosphere in your home is the foundation for your life. 13. In disagreements with loved ones, deal only with the current situation. Don't bring up the past. 14. Share your knowledge. It's a way to achieve immortality. 15. Be gentle with the earth. 16. Once a year, go someplace you've never been before. 17. Remember that the best relationship is one in which your love for each other exceeds your need for each other. 18. Judge your success by what you had to give up in order to get it. 19. Approach love and cooking with reckless abandon. Greg Ratta, Vice Chairman, ITU-T WP 1/11, Broadband Signalling Lucent Technologies Tel: +1 732 332 5174, Fax: +1 732 949 1196, gratta(a)lucent.com

1 0

Guidance from the Dalai Lama
by Greg Ratta 18 Feb '00

18 Feb '00

As we are finishing the ITU-T SG 16 meeting and observing the recent activity moving forward ITU-T Recommendation H.248 / Megaco, I found this gem attributed to be from the Dalai Lama. I hope you find it as enjoyable and relevant as I did. My only regret is that this did not pass my way two weeks ago. I N S T R U C T I O N S F O R L I F E 1. Take into account that great love and great achievements involve great risk. 2. When you lose, don't lose the lesson. 3. Follow the three Rs: - Respect for self - Respect for others and - Responsibility for all your actions. 4. Remember that not getting what you want is sometimes a wonderful stroke of luck. 5. Learn the rules so you know how to break them properly. 6. Don't let a little dispute injure a great friendship. 7. When you realize you've made a mistake, take immediate steps to correct it. 8. Spend some time alone every day. 9. Open your arms to change, but don't let go of your values. 10. Remember that silence is sometimes the best answer. 11. Live a good, honorable life. Then when you get older and think back, you'll be able to enjoy it a second time. 12. A loving atmosphere in your home is the foundation for your life. 13. In disagreements with loved ones, deal only with the current situation. Don't bring up the past. 14. Share your knowledge. It's a way to achieve immortality. 15. Be gentle with the earth. 16. Once a year, go someplace you've never been before. 17. Remember that the best relationship is one in which your love for each other exceeds your need for each other. 18. Judge your success by what you had to give up in order to get it. 19. Approach love and cooking with reckless abandon. Greg Ratta, Vice Chairman, ITU-T WP 1/11, Broadband Signalling Lucent Technologies Tel: +1 732 332 5174, Fax: +1 732 949 1196, gratta(a)lucent.com

1 0

One endpoint with multiple Connections.
by Hans Viens 18 Feb '00

18 Feb '00

Hi Folks! I have an endpoint that support 3 ports for H.323 connections and 1 port that support PSTN. Then I introduce the PSTN/H.323 gateway functionnality. Now, I would like to register that endpoint to a GK. How could I do this for the GK to know that I support 1 gateway port and 3 H.323 connections ??? Thanks for your support, Hope to get some news soon, Hans ------------------------------------------------ Hans Viens, Ing. St. Concepteur en logiciel / Software Designer Mediatrix Peripherals, Inc. / Mediatrix Telecom, Inc. 4229 Garlock Street, Sherbrooke QC J1L 2C8 Canada Tel.: (819) 829-8749 ext. 255, Fax: (819) 829-5100 E-Mail: hviens(a)mediatrix.com

2 1

Re: Q15: H.245 for videoFastUpdateMB, videoFastUpdateGOB, videoNo tDecodedM Bs (Was Q15: Date: Sat, 12 Feb 2000 19:24:45 -0800)
by Gary Sullivan 17 Feb '00

17 Feb '00

Ari, I suppose it is understandable that it might be difficult to reconcile videoFastUpdateMBs with H.263 Annex K or with MPEG-4, since videoFastUpdateMB was specified years before either one of those existed. That's history, not politics. In the case of MPEG-4 visual, I'm not sure whether specifying a macroblock number is sufficiently explicit. Even the "simple" profile of MPEG-4 requires support of more than one "visual object". I am not sure how you would know which "visual object" you were referring to when you sent the command. I'm not an expert on how MPEG-4 is handled in the system. I believe the intent is for MPEG-4 visual to be able to be handled either by carrying an MPEG-4 Systems stream or by H.245 itself without MPEG-4 Systems, but I'm not sure just how. -Gary S. +> -----Original Message----- +> From: ari.hourunranta(a)NOKIA.COM [mailto:ari.hourunranta@NOKIA.COM] +> Sent: Wednesday, February 16, 2000 12:59 AM +> To: ITU-SG16(a)MAILBAG.INTEL.COM +> Subject: Re: Q15: H.245 for videoFastUpdateMB, videoFastUpdateGOB, +> videoNo tDecodedM Bs (Was Q15: Date: Sat, 12 Feb 2000 19:24:45 -0800) +> +> +> Hi +> +> I am not giving any answers, but rather pointing out more +> problems related +> to the topic. +> +> In videoFastUpdateMBs, the statement saying that firstGOB is +> only relative +> to H.263 and firstMB is only relative to H.261 sounds weird. +> You could +> interpret it so that if you are using H.263 Annex K +> (slices), you should +> still request updates for GOBs, although MB-level start +> index would be much +> more natural. In case of MPEG-4 visual, use of +> videoFastUpdateMBs seems to +> be forbidden, although there is no technical reason why it +> should be (maybe +> political?). I am sure most of the implementors use common sense when +> interpreting the specifications, but still it wouldn't harm if the +> specification would be understandable. +> +> Regards, +> +> Ari +> +> ------------------------------------------------------------ +> Ari Hourunranta +> Nokia Mobile Phones +> ari.hourunranta(a)nokia.com +> ------------------------------------------------------------ +>

1 0

Re: question on video transcoder or gateway
by Gary Sullivan 17 Feb '00

17 Feb '00

Weiming Shen et al, The only real way to translate in either direction in general is to decode (including IDCT) and then re-encode. This is because H.261 cannot represent the half-pel motion used in H.263, and H.263 cannot represent the loop filter in H.261. Unless you can somehow stop the original encoder from using features that aren't found in both standards, you're stuck doing real transcoding. The re-encoding complexity can be reduced significantly by re-using the motion vectors and prediction mode selections from the incoming video rather than doing a new motion estimation in the re-encoder. Since motion estimation and mode selection can take a lot of processing power, getting rid of some of that can help. For best performance it would be good to have the re-encoder do a local refinement of the incoming motion vectors and to try different prediction modes. There are standards for gateways and multipoint conferencing units. I don't think they give much advice in them about this issue. I don't recall which standards those are, but if you look at a list of the H-series standards list at www.itu.int <http://www.itu.int> you'll probably spot them. -Gary -----Original Message----- From: wmshen [mailto:wmshen@PUBLIC.WH.HB.CN] Sent: Tuesday, February 15, 2000 7:04 PM To: ITU-SG16(a)MAILBAG.INTEL.COM Subject: question on video transcoder or gateway Hello, all experts, I am a Ph.D student working on video communication. I am wondering about how the video transcoder/gateway works between H.261 and H.263, and between IP network and PSTN or ISDN, in paticular i wonder whether there is a method by which bitstreams can be translated directly between H.261 and H.263 format. Who knows the technique details on above topics or where may i get some useful reference infomation? Any help will be approciated. Weiming Shen

1 0