question about MCU cascade

Tue Mar 16 20:59:31 EST 1999

Dear multimedia experts.

In my efforts to establish the simple IP voice and text telephone Text SET,
I came across a section in H.323 Annex F (Simple Endpoint Type, TD11 in
Monterey) that I feel is causing a functional obstacle also to the voice
users. Can anyone clarify if I am correct and why it is specified the way
it is.

In section 7.6.1 and 7.6.2 it is specified:"  The Audio SET device shall
then resume transmitting its media stream(s) to the transport address(es)
newly indicated in the OpenLogicalChannel structures."
I understand that this means that you cannot re-negotiate audio coding, and
you cannot add text conversation after rerouting the call from a Voice only
SET to a Text SET.

Re-negotiating the audio coding will probably be a desired function, e.g.
when rerouting from a fixed to a wireless IP phone.
Adding a data channel for text will also be a desired function, after
answering a call in an audio-only SET, and then rerouting it to a
text-capable SET.
That action is very common in today's text telephone usage, and I would
expect it to be just as common in the IP telephony world. You first receive
the call in the terminal that is closest to you, and then you get a reason
to start text mode. Then you transfer the call to another device with text
capabilities, where you can switch mode.


1. Is that kind of call transfer that is handled by the mechanisms in 7.61
and 7.6.2?

2. Are my conclusion right about the limitations?

3. Is this limitation a consequence of using Fast Connect?

4. Do you see any possibility to avoid the negative effects of it - to make
re-negotiation possible?

5. Is the specified functionality acceptable in the voice world? If two
devices have agreed on a voice coder, is it likely that the third device
supports it? Will this not create a lot of unsuccessful call transfers
where the users will have a no chance to understand why they fail?


Another question area:

6. When selecting the transport protocol for the text conversation, the
current draft (APC 1504) specifies TCP or UDP. I realize that there are
situations where TCP must be avoided. One such situation is a sub-titled
H.332 transmission. Also other multi-casting situations is better off with
a UDP based transport protocol.
I am therfore now leaning towards using RTP as the transport for text
conversation. With RTP we can discover dropped frames and possibly invent a
mechanism to mark that event in the text stream for T.140 to display. If we
have less than 3 % dropped frames, I think the users would accept it.

6.1 Do you agree that there are situations when TCP should be avoided, and
a UDP based protocol preferred?

6.2 Do you agree that RTP is a good alternative, with a thin protocol for
error indications to the user?

6.3 Most packets will carry only 1-4 characters . Can anyone give me an
indication on the expected packet loss rates in different situations for
such packets. Or a document giving such figures. Is max 3% loss reachable?

Please give your view on these questions.

Best regards

Gunnar Hellström
Gunnar Hellstrom
Representing Ericsson in ITU-T

E-mail gunnar.hellstrom at
Tel +46 751 100 501
fax +46 8 556 002 06

More information about the sg16-avd mailing list