Re: Section_8.3_rev to include point-to-multipoint VC connection
Dear Mr. Harasaki, Thanks for your confidence in me. The followings are my comments regarding Section_8.3. If you think using Section_8.3 for both point-to-point and point-to-multipoint configurations is ok, I can modify this specific section to reflect your comments.
Since initial VC is used for a transport of H.245 messages, it must be >bi-directional point-to-point VC connection.
Yes, you are right.
Either MCU or aterminal can initiate the call.
In the root-initiated point-to-multipoint case, it's still MCU who should initiated the call since the addditional VC is setup by the calling party, the party who initiated the first VC (Do I understand H.310 procedure right?)
A point-to-multipoint VC connection can only be used in an additional >VC setup phase. The additional VC is used for AV communication.
You are right. I should only put change in the addtional VC setup.
We may need to put some guidelines for selecting point-to-point and >point-to-multipoint VC. In the case of one SOT and many ROTs case >shown in Figure 3 (b), MCU shall initiate point-to-multipoint VC >connection as an additional
I agree. But I don't want to make it mandatory.
I would like to add something like below in Section 7 or 8.
"MCU shall use point-to-multipoint VC connection for all receive only >terminals. ROT terminals are always receive only.
I understand that it's more efficent to use point-to-multipoint VC connection for ROTs but I am not so sure about making this mandatory. I do not want to exclude the case, where for some reason, MCU does not support Q.2971 but still want to support ROTs. Then in this case, MCU should be able to use point-to-point connection to support ROTS.
If I understand correctly, Information Elements that are used for point-to-multipoint VC setup is exactly same as a uni-directional point-to-point VC setup, except user plane configuration field of B-BC and Endpoint Reference IE.
I will cut from Table B.3/H.310, modify it and paste the revised table into Annex A.
This is good enough for me. Li Yan **************************************************************** Lucent Technologies Phone: 732-957-3877 2E-433, 200 Laurel Ave., Fax: 732-957-5627 Middletown, NJ, 07733 E-amil:lyan@lucent.com U.S.A. ****************************************************************
Dear Ms. Li Yan, Thank you for your prompt reply.
Either MCU or a terminal can initiate the call.
In the root-initiated point-to-multipoint case, it's still MCU who should initiated the call since the addditional VC is setup by the calling party, the party who initiated the first VC (Do I understand H.310 procedure right?)
Only initial VC (the call) can be initiated by either MCU or a terminal. An additional VC can be initiated by either MCU or a terminal if the VC is point-to-point. A point-to-multipoint additional VC shall be initiated by MCU. I am not quite sure that point-to-point additional VC can be initiated by a terminal after H.245 negotiation, though.
We may need to put some guidelines for selecting point-to-point and >point-to-multipoint VC. In the case of one SOT and many ROTs case >shown in Figure 3 (b), MCU shall initiate point-to-multipoint VC >connection as an additional
I agree. But I don't want to make it mandatory.
I supposed that I may have this kind of objection, i.e. not mandatory.
I would like to add something like below in Section 7 or 8.
"MCU shall use point-to-multipoint VC connection for all receive only >terminals. ROT terminals are always receive only.
I understand that it's more efficent to use point-to-multipoint VC connection for ROTs but I am not so sure about making this mandatory. I do not want to exclude the case, where for some reason, MCU does not support Q.2971 but still want to support ROTs. Then in this case, MCU should be able to use point-to-point connection to support ROTS.
I am also afraid that some ROTs may not be able to receive a point-to-multipoint VC properly. In this case MCU should have a fall back mechanism to retry with a point-to-point VC. Okay. We will change "shall" to "may". Hideh Hidenobu Harasaki harasaki@ccm.CL.nec.co.jp Principal Researcher C&C Media Research Labs., NEC Corporation Phone: +81 44 856 8083 Fax: +81 44 856 2232
Dear Mr. Harasaki, HH>> >Either MCU or a terminal can initiate the call. HH>> HH>> In the root-initiated point-to-multipoint case, it's still MCU who HH>> should initiated the call since the addditional VC is setup by the HH>> calling party, the party who initiated the first VC (Do I understand HH>> H.310 procedure right?) HH> HH>Only initial VC (the call) can be initiated by either MCU or a terminal. HH>An additional VC can be initiated by either MCU or a terminal if the VC HH>is point-to-point. A point-to-multipoint additional VC shall be HH>initiated by MCU. HH> HH>I am not quite sure that point-to-point additional VC can be initiated HH>by a terminal after H.245 negotiation, though. Please note that Section 7.1.1/H.310 specifies as follows: Phase A3 (Additional VC Setup) In this phase, and based on the communication mode determined above, the calling terminal, that is, the one that initiated the first VC SETUP message, shall firstly indicate the characteristics of the additional VC(s) to the remote end using the H.245 NewATMVCIndication message, and then shall setup the additional VC(s) with the appropriate parameters, such as bitrate and AAL type, for the transfer of the audiovisual and other data between the two H.310 terminals. NOTE - This allows the remote end to receive the H.245 NewATMVCIndication message before responding to the VC setup message. Best regards, Sakae OKUBO (Mr.) ******************************************************************** Graphics Communication Laboratories Phone: +81 3 5351 0181 6F ANNEX TOSHIN BLDG. Fax: +81 3 5351 0184 4-36-19 Yoyogi, Shibuya-ku, Tokyo e-mail: okubo@gctech.co.jp 151 Japan ********************************************************************
Dear Ms. Li Yan, Mr. Okubo and other Q.12 experts, I put revised Annex A for H.bmultipoint in the incoming directory of ftp.gctech.co.jp. The Annex A now includes Information Element tables for a point-to-multipoint SETUP message. The file name is "hbmultAnnexA-rev.doc". Please review it, and let me know if we need any correction or need add more texts on the annex. Hideh Hidenobu Harasaki harasaki@ccm.CL.nec.co.jp Principal Researcher C&C Media Research Labs., NEC Corporation Phone: +81 44 856 8083 Fax: +81 44 856 2232
participants (3)
-
Hidenobu Harasaki -
Li Yan -
Sakae Okubo