-----Ursprüngliche Nachricht-----
Von: Paul E. Jones [SMTP:paul.jones@TIES.ITU.INT]
Gesendet am: Donnerstag, 18. März 1999 18:57
An: ITU-SG16@mailbag.cps.intel.com
Betreff: Re: AW: Call hold and transfer in H.323 AnnexF. Too
limited??
Unfortunately, I will have to disagree with your comments. While it is
true
that the H.450 supplementary services could be utilized in a SET device,
I
believe that introducing H.450 into a SET breaks the spirit of that work.
The goal of Annex F is to define a "Simple Endpoint Type". There are
simpler ways to put a call on hold and to transfer a call. Introducing
H.450 introduces a lot more complexity that I believe we want to have.
If
Annex F is not sufficiently clear on how to simply transfer a call or put
a
call on hold, we should work on that text-- I will absolutely disagree
with
introducing H.450 into a SET device.
[Klaghofer, Karl PN VS LP3] Whatever you mean with
"introducing" -
H.450 as I sayd in my previous mail is a way of providing supplementary
services like call hold and call transfer to a SET device. It IS already
part of the H.323 Annex F!
Paul
-----Original Message-----
From: Klaghofer Karl ICN IB NL IP 7 <Karl.Klaghofer@ICN.SIEMENS.DE>
To: ITU-SG16@MAILBAG.INTEL.COM <ITU-SG16@MAILBAG.INTEL.COM>
Date: Wednesday, March 17, 1999 3:27 PM
Subject: AW: Call hold and transfer in H.323 AnnexF. Too limited??
Gunnar,
You are referring to call hold and transfer in conjunction with H.323
Annex
F SETs (Audio or Text) and clause 7.6 of H.323 Annex F.
Talking about call hold, clause 7.6 of H.323 Annex F is not needed for a
SET
at all. Call Hold works for a SET as it is defined in H.450.4.
Talking about Call Transfer, clause 7.6 of H.323 Annex F is not needed
for
a
SET, if the transfer is executed by the endpoints as defined in H.450.2.
Codec re-negotiation you are referring to is no problem and takes place
between the transferred and the transferred-to endpoint. This may cover
your
case with wireless endpoints being involved.
For call transfer, section 7.6 of H.323 Annex F is only needed if the
gatekeeper or a proxy acts on behalf of the transferred SET endpoint B.
However, media re-negotiation also should work here as part of the
fastStart
method.
Regards,
Karl
------------------------------------------------
Karl Klaghofer, Siemens AG, Dpmt. ICN IB NL IP7
Hofmannstr. 51, D-81359 Munich, Germany
Tel.: +49 89 722 31488, Fax.: +49 89 722 37629
e-mail: karl.klaghofer@icn.siemens.de
-----Ursprüngliche Nachricht-----
Von: Gunnar Hellstrom [SMTP:gunnar.hellstrom@OMNITOR.SE]
Gesendet am: Dienstag, 16. März 1999 23:01
An: ITU-SG16@mailbag.cps.intel.com
Betreff: Call hold and transfer in H.323 AnnexF. Too limited??
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,