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

23 Mar 1999

      Paul,
Agreed.
Karl
...
-----Ursprüngliche Nachricht-----
Von:  Paul E. Jones [SMTP:paul.jones@ties.itu.int]
Gesendet am:  Montag, 22. März 1999 18:42
An:   Klaghofer Karl ICN IB NL IP 7; ITU-SG16@mailbag.cps.intel.com
Betreff:      Re:      AW: AW: Call hold and transfer in H.323 AnnexF. Too
limited??
Karl,
Currently, the use of H.450 in a SET is optional, as is most of the
various
pieces and parts of the H.323 specifications.  When I said "by introducing
it", I meant that I would object to making H.450 mandatory in a SET
device.
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: Thursday, March 18, 1999 5:09 PM
Subject: AW: AW: Call hold and transfer in H.323 AnnexF. Too limited??
...
See comment below.
Karl
...
-----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??
Karl,
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:

Is that kind of call transfer that is handled by the mechanisms

in
...
...
7.61
...
...
and 7.6.2?

Are my conclusion right about the limitations?

Is this limitation a consequence of using Fast Connect?

Do you see any possibility to avoid the negative effects of it -

to
...
...
...
...
make
re-negotiation possible?

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:

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

Klaghofer Karl ICN IB NL IP 7

Gunnar Hellström

tags (0)

participants (1)