Call hold and transfer in H.323 AnnexF. Too limited??

[Gunnar Hellstrom]

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.

Questions:

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 omnitor.se
Tel +46 751 100 501
fax +46 8 556 002 06