I'm not sure if this is the right email address,
but here goes...
We at Starvision are developing a broadband MCU
product. The first phase of our product is now complete.
It is a prototype which performs parallel real-time video
processing on up to 10 video streams. Some features
currently implemented are arbitrary scaling, panning,
positioning, z-buffering, alpha-blending, chroma-keying,
text overlay and graphics overlay. The platform can
support any combination of # of conferences
and # per …
[View More]conference up to a total of 10.
Currently control of the A/V feature set
is proprietary.
The next phase of our development is to increase
the number of user streams supported in the MCU,
to provide transport over ATM and to conform as close
as we can to current and developing ITU standards.
Among many of the issues we're investigating, one of
the items in question is the issue of the overlap in
functionality between H.245 and T.120.
Our MCU has many audio/video processing features currently
not defined in either H.245 or T.130. In H.323, Section 6.6,
it is stated that "criteria for which [video] sources
and how many are mixed is determined by the MC until
other controls are defined. The use of the T.120-Series
Recommendations for these control functions is for
further study."
Is there anywhere I can be pointed to for information
and discussion regarding these multipoint A/V control functions?
I would think that this is not something that would go into
the H.245 spec. Is the current thought to use T.130?
Any info is much appreciated.
--
Ray Jang
Technical Leader, R&D
Starvision Multimedia
http://www.starvision.com
[View Less]
Dear SG16 colleagues,
Attached is a revised (dated 1997-08-25) version of the H.245
appendix (non-normative) and H.245/H.323 text (normative) for
"ReplacementFor". It is just 3 pages long.
I plan to request an APC number and post the final version late
this week; I'll try to incorporate any comments in that version.
The main changes from the 1997-07-30 version are:
1) H.323 RSVP procedures are mentioned in the appendix, based
on the Cisco proposals.
2) The new LC transport addresses …
[View More]are required to be the same
as the original transport addresses, to allow changing the
RSVP bandwidth before getting the OLCAck.
I've _not_ mentioned anything about Flow Control to support
RSVP, as this seems to be unrelated to RepFor; whatever is
defined for this will apply equally whether RepFor is used
or not.
For those who read the 1997-07-30 version, I've marked the
changes in yellow highlight; this will be removed from the
final APC document.
--Dave L.
-------------------------------------------------------------------
Dave Lindbergh Email: lindbergh(a)pictel.com
Manager, Technical Standards Group Voice: +1 508 623 4351
PictureTel Corporation Fax: +1 508 749 2804
100 Minuteman Road - M/S 635 H.320: +1 508 437 0265 (twice)
Andover MA 01810 USA http://standards.pictel.com
PGP fingerprint: C8 3E 28 69 53 0A 4B 87 EF E0 11 CD AC 87 4D CD
-------------------------------------------------------------------
[View Less]
Mike, Hussein, (and all),
Thanks for your comments on the ReplacmentFor text. I'm trying
to wrap up a revised contribuiton for SunRiver this week. I
would appreciate your thoughts on the following:
At 02:44 PM 8/14/97 +0100, nilsson_m_e(a)bt-web.bt.co.uk wrote:
>I am concerned about adding a FlowControl field to the
>OpenLogicalChannelAck message. This could make things very complicated
>in the future when people start to use this for something else,
>something that was not …
[View More]intended and something that we have not even
>thought about yet.
I propose to not mention this issue in the ReplacementFor text,
since I think it is a generic issue with RSVP support and has
nothing to do with ReplacementFor in particular. We can modify
the appendix example text in SunRiver (or even after) based on
however the group decides to handle this.
>From Dave's document REPFR_AP.DOC, concerned with the replacementFor
>mechanism, the reason for creating this mechanism is quite clear, and
>it is very useful.
>
>However, I think we should clarify how much flexibility is allowed.
>In particular, how long can the transmitter wait before sending
>CloseLogicalChannel for the first channel? Can it delay sending this
>for sometime, and switch between the two channels?
No, this is not intended to be allowed. It's purely for a one-time
mode switch.
>in his example is
>it possible to start with G.723, then send G.711-OpenLogicalChannel with
>replacementFor=G.723, switch to G.711, then at some later time switch
>to G.723 again, and then perhaps back to G.711?
No this should not be allowed. I'll clarify both the example appendix
and the proposed normative semantics for H.245 on this point.
>If we want to allow this then we should clarify this in the proposed
>appendix, and perhaps change the terminology replacementFor to, say,
>alternativeTo. If we do not, then we should ensure some strong
>normative wording is added about sending CloseLogicalChannel
>immediately after receiving the other OpenLogicalChannelAck, and add a
>note specifically outlawing this scenario.
I'll propose some text along the lines you suggest. (That we do
not want to allow this.)
-------------------------------------------------------------------
Dave Lindbergh Email: lindbergh(a)pictel.com
Manager, Technical Standards Group Voice: +1 508 623 4351
PictureTel Corporation Fax: +1 508 749 2804
100 Minuteman Road - M/S 635 H.320: +1 508 437 0265 (twice)
Andover MA 01810 USA http://standards.pictel.com
PGP fingerprint: C8 3E 28 69 53 0A 4B 87 EF E0 11 CD AC 87 4D CD
-------------------------------------------------------------------
[View Less]
Okubo-san and SG16 colleagues,
I have uploaded all but one of our contributions. APC-1278 should be ready
within a day or two. I have altered a few of the titles from what I asked
of Okubo-san earlier. Okubo-san, if it is possible to change the titles in
the text file and the html file in accordance with the titles below, I
should be very grateful indeed. I am sorry for the trouble this might
cause.
APC-1273 A URL for H.323 Calls
APC-1274 A URL for RAS requests
APC-1275 ACF & LCF …
[View More]messages should contain Endpoint Type
APC-1276 Using the transport layer address within H.323 PDUs for
Transparent Firewall Operation
APC-1277 DTMF Signaling with H.323
APC-1278 Access Tokens within H.323 (to be uploaded soon)
APC-1279 Dynamic Change of IP Address in Registration
APC-1280 A Progress UUIE for Answer Supervision
APC-1281 ICF Message to Enable Reliability and Security
APC-1282 Announcing a Q.931 message within an IRR
APC-1283 H.245 Support for GSM Speech Codecs
APC-1284 Corrections to the Endpoint Structure
Here is a one-line summary of each contribution:
1. APC-1273 A URL for H.323 Calls
(A set of requirements for the H.323 URL and a proposal. Our
solution ensures that any remote info can be coded, but also allow for
user-friendly URLs where possible).
2. APC-1274 A URL for RAS requests
(A similar proposal for RAS requests. We need ras: URLs to
enable sending LRQs from Web Pages, and also to allow Web-based call
management).
3.APC-1275 ACF & LCF messages should contain Endpoint Type
(Need to be able to tell if you?re calling a gateway or
terminal and which vendor and version)
4.APC-1276 Using the transport layer address within H.323 PDUs for
Transparent Firewall Operation
(A PDU can set transport addresses to 0.0.0.0, meaning use
the address from the transport layer. Needed for transparent
proxies/firewalls/GKs and for apps that don?t know their own address).
5. APC-1277 DTMF Signaling with H.323
(Contains a much simplified version of Microsoft's proposal
with similar semantics)
6.APC-1278 Access Tokens within H.323
(The semantics of AccessTokens within H.323)
7.APC-1279 Dynamic Change of IP Address in Registration
(reregistration in the event of an crash)
8.APC-1280 A Progress UUIE for Answer Supervision
(To signal to caller that ?you can talk now?)
9.APC-1281 ICF Message to Enable Reliability and Security
(An option to ack unsolicited IRRs)
10.APC-1282 Announcing a Q.931 message within an IRR
(An option for direct calls to inform the GK that a message
was sent or received)
11.APC-1283 H.245 Support for GSM Speech Codecs
(The audio caps structure for GSM)
12.APC-1284 Corrections to the Endpoint Structure
(destExtraCallInfo and remoteExtensionAddress need to be
added to the Endpoint structure)
Note that 8,9, and 10 offer an alternative to Ascend?s contribution
(APC-1264) about "call accounting." We are very sympathetic to Ascend's
concern, but have real problems with their proposed solution. Our solution
contains theirs, but we believe avoids some pitfalls. Our contributions
were written before we saw APC-1264, but we added some text to relate them
directly to APC-1264.
Scott
[View Less]
