April 1998 - sg16-avd - lists.packetizer.com

PLEASE REVIEW: meeting report Q13, revised TD-14, TD-15 upload to ftp site
by Dale L. Skran 20 Apr '98

20 Apr '98

Yokosuka meeting attendees: I have just uploaded to the incoming directory of ftp site the following documents: td-14-sg8-annxB-liaision-v2-chgs-accepted.doc the doc below with changes accepted td-14-sg8-annxB-liaision-v2.doc change marks showing changes discussed on the final day of the meeting td-15-revised-chgs-accep-323 annex D.doc the doc below with changes accepted td-15-revised-323 annex D.doc change marks showing changes discussed on the final day of the meeting td-17-yokosuka-v2.doc revised Q13 meeting notes with change marks Please review all these documents and send your comments to the mailing list. I would like to finalize the meeting report this week, and recall that we have a May 11 white paper deadline for H.323 Annex D. URGENT ISSUE: In the meeting report, I note a problem with forward references in T.38 Annex B to H.245 version 5 (and also in H.323 Annex D even if it was delayed). As you recall, at the meeting we decided to move the T.38 related changes from V4 to V5; I believe that this was over-hasty and that the changes should go in the H.245 V4 white paper. Comments? Dale Skran Q13 Rapporteur

2 1

add to list
by Randy Pope 20 Apr '98

20 Apr '98

Randy_Pope(a)stg.sel.sony.com

2 1

(no subject)
by Liang Jun Ming 19 Apr '98

19 Apr '98

I'm a student of FuDan University,Shanghai,China. I want to get some information and application on T.105(SBV Application Layer Protocol and BIS). Could you give me some advice? I appreciate for your lift!

1 0

Documentation of the Yokosuka meeting
by Sakae OKUBO 18 Apr '98

18 Apr '98

Dear Q.12-14 colleagues, All the APC-numbered documents and Temporary Documents are now avialable at ftp://standard.pictel.com/avc-site/9804_Yok/. 9804_Yok.html is their index. Please note, however, that some output TDs such as meeting report of each Question need be revised to incorporate the discussion at the closing session last Friday. They will be uploaded with indication such as r, r1, ... Please also note that APC-1372 will be the integrated meeting report assembling TD-24(general), TD-16(Q.12), TD-17(Q.13), TD-18(Q.14). 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(a)gctech.co.jp 151-0053 Japan or okubo(a)mxz.meshnet.or.jp ********************************************************************

1 0

June meeting date
by Joerg Ott 15 Apr '98

15 Apr '98

Toby, TD-1 of this meeting specifies 8-11 June in Cannes. I haven't heard anything during this week that this should change (again). Joerg At 12:32 15.04.98 -0700, you wrote: >Do we have definite dates and location for the June Q12-14 meeting? > > -- Toby >___________________________________________________________ >Toby L. Nixon, Senior Business Development Manager >Microsoft Corporation, ICU - OEM & SI Group >One Microsoft Way, Redmond WA 98052 USA >+1 (425) 936-2792 Fax: +1 (425) 936-7329 >mailto:tnixon@microsoft.com > >

1 0

Re[2]: Far-end camera control for H.323
by Roni Even 15 Apr '98

15 Apr '98

Vineet, In H.281 each new message is replacing the previous one if it came from the same source with the same action. If you send a start pan right with timeout 300msec and the next message is continue the same action for 100 msec, the receiver upon getting the continue message restart the timer. Regards Roni Even _______________________ Reply Separator _______________________ Subject: Re: Far-end camera control for H.323 Author: <ITU-SG16(a)MAILBAG.INTEL.COM> at internet Date: 15/4/98 9:37 I agree that Acks are not needed and we should not try to over-engineer. But there needs to be a mechanism so that the user can stop the camera motion within a reasonable time after issuing STOP. This can be accomplished by having the receiver (one with the camera) look-ahead for STOP messages in its receive buffer. When it sees the STOP message it should ignore any CONTINUE messsages in its buffer which are ahead of the STOP. What I have described above is not something to be standarized but we could include it as a guidance to the implementors. vineet ______________________________ Reply Separator _________________________________ Subject: Far-end camera control for H.323 Author: Dave Lindbergh [SMTP:lindbergh@itu.ch] at MSXGATE Date: 4/14/98 11:58 PM Dear SG16 colleagues, Just to repeat and amplify our Yokosuka comments on APC-1356 (Intel) and APC-1366 (Accord) regarding Far End Camera Control (FECC) for H.323: In general, PictureTel supports the idea of basing H.323 FECC on H.281. We think the following points are important: 1) A general goal should be that H.323 FECC should be interoperable via a gateway with H.281-based FECC on H.320 systems (note that H.324 also uses H.281 FECC) 2) H.281 should be sent over UDP as a separate media stream, and not over TCP (such as H.245). We believe that H.281 must be transported using techniques suitable for a media stream, thus preserving the real-time relationships between control activation, hold, and deactivation which are represented by the H.281 Start, Continue, and Stop messages. 3) Any solution must address capability exchange including which endpoints have controllable cameras, how many cameras, what controls are available (pan, tilt, zoom, focus, etc.), preset positions available, etc. The existing H.281 system uses H.224 for capability exchanges of this sort. One solution would be to perform a similar function using H.245 cap exchange. Another would be to simply encapsulate the entire H.224/H.281 stack within a UDP media stream (this would simplify gateways). 4) Any solution must address multipoint use. One possibility is to adopt a solution similar to V.CHAT/T.CHAT: A simple H.281 UDP encapsulation for point-to-point use, and a very simple T.120 "wrapper" around H.281 for multipoint use. Note that the T.120 could reside either in endpoints or be proxied from the point-to-point mode at the MC. 5) To improve reliability on congested networks, rather than using TCP, redundant transmission of H.281 messages via UDP might be used. 6) To support future applications such as machine-driven pointing and operation on highly congested networks, the H.281 message set should be extended to add new absolute and/or relative positioning commands (probably in units of field of view rather than angular units). Long-term, a migration to these new commands could occur, while retaining compatibility with the existing H.281 start/stop motion model. 7) We are unsure how adding ACKs to Start/Continue/Stop messages (as suggested by Intel) is helpful. --Dave Lindbergh, PictureTel ------------------------------------------------------------------- Dave Lindbergh Email: lindbergh(a)pictel.com PictureTel Corporation Voice: +1 978 623 4351 100 Minuteman Road - M/S 635 Fax: +1 978 749 2804 Andover MA 01810 USA H.320 video by arrangement PGP fingerprint: C8 3E 28 69 53 0A 4B 87 EF E0 11 CD AC 87 4D CD -------------------------------------------------------------------

1 0

Re: Far-end camera control for H.323
by Toby Nixon 15 Apr '98

15 Apr '98

Do we have definite dates and location for the June Q12-14 meeting? -- Toby ___________________________________________________________ Toby L. Nixon, Senior Business Development Manager Microsoft Corporation, ICU - OEM & SI Group One Microsoft Way, Redmond WA 98052 USA +1 (425) 936-2792 Fax: +1 (425) 936-7329 mailto:tnixon@microsoft.com

1 0

Re: Far-end camera control for H.323
by Kumar, Vineet 15 Apr '98

15 Apr '98

I agree that Acks are not needed and we should not try to over-engineer. But there needs to be a mechanism so that the user can stop the camera motion within a reasonable time after issuing STOP. This can be accomplished by having the receiver (one with the camera) look-ahead for STOP messages in its receive buffer. When it sees the STOP message it should ignore any CONTINUE messsages in its buffer which are ahead of the STOP. What I have described above is not something to be standarized but we could include it as a guidance to the implementors. vineet ______________________________ Reply Separator _________________________________ Subject: Far-end camera control for H.323 Author: Dave Lindbergh [SMTP:lindbergh@itu.ch] at MSXGATE Date: 4/14/98 11:58 PM Dear SG16 colleagues, Just to repeat and amplify our Yokosuka comments on APC-1356 (Intel) and APC-1366 (Accord) regarding Far End Camera Control (FECC) for H.323: In general, PictureTel supports the idea of basing H.323 FECC on H.281. We think the following points are important: 1) A general goal should be that H.323 FECC should be interoperable via a gateway with H.281-based FECC on H.320 systems (note that H.324 also uses H.281 FECC) 2) H.281 should be sent over UDP as a separate media stream, and not over TCP (such as H.245). We believe that H.281 must be transported using techniques suitable for a media stream, thus preserving the real-time relationships between control activation, hold, and deactivation which are represented by the H.281 Start, Continue, and Stop messages. 3) Any solution must address capability exchange including which endpoints have controllable cameras, how many cameras, what controls are available (pan, tilt, zoom, focus, etc.), preset positions available, etc. The existing H.281 system uses H.224 for capability exchanges of this sort. One solution would be to perform a similar function using H.245 cap exchange. Another would be to simply encapsulate the entire H.224/H.281 stack within a UDP media stream (this would simplify gateways). 4) Any solution must address multipoint use. One possibility is to adopt a solution similar to V.CHAT/T.CHAT: A simple H.281 UDP encapsulation for point-to-point use, and a very simple T.120 "wrapper" around H.281 for multipoint use. Note that the T.120 could reside either in endpoints or be proxied from the point-to-point mode at the MC. 5) To improve reliability on congested networks, rather than using TCP, redundant transmission of H.281 messages via UDP might be used. 6) To support future applications such as machine-driven pointing and operation on highly congested networks, the H.281 message set should be extended to add new absolute and/or relative positioning commands (probably in units of field of view rather than angular units). Long-term, a migration to these new commands could occur, while retaining compatibility with the existing H.281 start/stop motion model. 7) We are unsure how adding ACKs to Start/Continue/Stop messages (as suggested by Intel) is helpful. --Dave Lindbergh, PictureTel ------------------------------------------------------------------- Dave Lindbergh Email: lindbergh(a)pictel.com PictureTel Corporation Voice: +1 978 623 4351 100 Minuteman Road - M/S 635 Fax: +1 978 749 2804 Andover MA 01810 USA H.320 video by arrangement PGP fingerprint: C8 3E 28 69 53 0A 4B 87 EF E0 11 CD AC 87 4D CD -------------------------------------------------------------------

1 0

Re: Far-end camera control for H.323
by Roni Even 15 Apr '98

15 Apr '98

Dear SG16 Colleagues, I read Dave Lindbergh's comments and found them important in order to go on with a solution for FECC. Following are my remarks to the points below. 1. I agree with this point. 2. I want to mention that if we are going to use one TCP connection for multiple calls ( See Lucent's APC) than there may be a problem with real time in the H.245 channel. Like my APC mentioned I think that both ways will work. 3. If a UDP channel is the solution than we can use the open logical channel ack message to send the FECC capabilities (see APC-1366). 4. In a multipoint environment using a UDP solution we can open this channel directly between the end points that want to have an FECC session. The exception will be in centralised conferences or centralised video conferences. We can add a "chair control" service requiring the end point who wants to start an FECC session to ask permission from the active MC. 5. OK 6. There was an APC from IBM for h.281 in the past addressing this issue. 7. I agree that ACKs is not needed. If a UDP solution is what we are going to do, does it mean that we need a new h.xxx. Roni Even Accord Video Telecommunication. ______________________________ Reply Separator _________________________________ Subject: Far-end camera control for H.323 Author: <ITU-SG16(a)MAILBAG.INTEL.COM> at internet Date: 4/15/98 2:58 AM Dear SG16 colleagues, Just to repeat and amplify our Yokosuka comments on APC-1356 (Intel) and APC-1366 (Accord) regarding Far End Camera Control (FECC) for H.323: In general, PictureTel supports the idea of basing H.323 FECC on H.281. We think the following points are important: 1) A general goal should be that H.323 FECC should be interoperable via a gateway with H.281-based FECC on H.320 systems (note that H.324 also uses H.281 FECC) 2) H.281 should be sent over UDP as a separate media stream, and not over TCP (such as H.245). We believe that H.281 must be transported using techniques suitable for a media stream, thus preserving the real-time relationships between control activation, hold, and deactivation which are represented by the H.281 Start, Continue, and Stop messages. 3) Any solution must address capability exchange including which endpoints have controllable cameras, how many cameras, what controls are available (pan, tilt, zoom, focus, etc.), preset positions available, etc. The existing H.281 system uses H.224 for capability exchanges of this sort. One solution would be to perform a similar function using H.245 cap exchange. Another would be to simply encapsulate the entire H.224/H.281 stack within a UDP media stream (this would simplify gateways). 4) Any solution must address multipoint use. One possibility is to adopt a solution similar to V.CHAT/T.CHAT: A simple H.281 UDP encapsulation for point-to-point use, and a very simple T.120 "wrapper" around H.281 for multipoint use. Note that the T.120 could reside either in endpoints or be proxied from the point-to-point mode at the MC. 5) To improve reliability on congested networks, rather than using TCP, redundant transmission of H.281 messages via UDP might be used. 6) To support future applications such as machine-driven pointing and operation on highly congested networks, the H.281 message set should be extended to add new absolute and/or relative positioning commands (probably in units of field of view rather than angular units). Long-term, a migration to these new commands could occur, while retaining compatibility with the existing H.281 start/stop motion model. 7) We are unsure how adding ACKs to Start/Continue/Stop messages (as suggested by Intel) is helpful. --Dave Lindbergh, PictureTel ------------------------------------------------------------------- Dave Lindbergh Email: lindbergh(a)pictel.com PictureTel Corporation Voice: +1 978 623 4351 100 Minuteman Road - M/S 635 Fax: +1 978 749 2804 Andover MA 01810 USA H.320 video by arrangement PGP fingerprint: C8 3E 28 69 53 0A 4B 87 EF E0 11 CD AC 87 4D CD -------------------------------------------------------------------

1 0

Far-end camera control for H.323
by Dave Lindbergh 15 Apr '98

15 Apr '98

Dear SG16 colleagues, Just to repeat and amplify our Yokosuka comments on APC-1356 (Intel) and APC-1366 (Accord) regarding Far End Camera Control (FECC) for H.323: In general, PictureTel supports the idea of basing H.323 FECC on H.281. We think the following points are important: 1) A general goal should be that H.323 FECC should be interoperable via a gateway with H.281-based FECC on H.320 systems (note that H.324 also uses H.281 FECC) 2) H.281 should be sent over UDP as a separate media stream, and not over TCP (such as H.245). We believe that H.281 must be transported using techniques suitable for a media stream, thus preserving the real-time relationships between control activation, hold, and deactivation which are represented by the H.281 Start, Continue, and Stop messages. 3) Any solution must address capability exchange including which endpoints have controllable cameras, how many cameras, what controls are available (pan, tilt, zoom, focus, etc.), preset positions available, etc. The existing H.281 system uses H.224 for capability exchanges of this sort. One solution would be to perform a similar function using H.245 cap exchange. Another would be to simply encapsulate the entire H.224/H.281 stack within a UDP media stream (this would simplify gateways). 4) Any solution must address multipoint use. One possibility is to adopt a solution similar to V.CHAT/T.CHAT: A simple H.281 UDP encapsulation for point-to-point use, and a very simple T.120 "wrapper" around H.281 for multipoint use. Note that the T.120 could reside either in endpoints or be proxied from the point-to-point mode at the MC. 5) To improve reliability on congested networks, rather than using TCP, redundant transmission of H.281 messages via UDP might be used. 6) To support future applications such as machine-driven pointing and operation on highly congested networks, the H.281 message set should be extended to add new absolute and/or relative positioning commands (probably in units of field of view rather than angular units). Long-term, a migration to these new commands could occur, while retaining compatibility with the existing H.281 start/stop motion model. 7) We are unsure how adding ACKs to Start/Continue/Stop messages (as suggested by Intel) is helpful. --Dave Lindbergh, PictureTel ------------------------------------------------------------------- Dave Lindbergh Email: lindbergh(a)pictel.com PictureTel Corporation Voice: +1 978 623 4351 100 Minuteman Road - M/S 635 Fax: +1 978 749 2804 Andover MA 01810 USA H.320 video by arrangement PGP fingerprint: C8 3E 28 69 53 0A 4B 87 EF E0 11 CD AC 87 4D CD -------------------------------------------------------------------

1 0