AW: Call Forward too!... RE: AW: Call hold and transfer in H.323 Anne xF. Too limited??

23 Mar 1999

      I do not see a limitation in H.450.3.
If a called endpoint B is out of service (which is very likely for a PC
based H.323 endpoint but which may be more an exceptional case for other
endpoint types like "black phones"), a proxy function has to act on behalf
of the endpoint B, provided you want to successfully establish the call.
This is not specific to H.450.3 call diversion but applies to H.323 Basic
call functions as well.
This proxy function may e.g. be co-located with the gatekeeper or may be
located within an other endpoint (with the gk just performing routing to the
proxy). The latter one may allow more flexibility and scalability.  Anyway,
this is an issue of your architecture and does not need to be standardized.
As an example, FIGURE 5/H.450.3 shows the forwarding function (i.e. the
"served signalling entity") possibly being provided by a proxy function
(e.g. for cases where the endpoint is out of service). Of course the proxy
function needs knowledge about the activated supplementary services for a
given user for which the proxy is acting, which again is an implementation
issue.
Regards,
Karl
...
-----Ursprüngliche Nachricht-----
Von:  Chris Purvis [SMTP:Chris.Purvis@MADGE.COM]
Gesendet am:  Montag, 22. März 1999 12:07
An:   ITU-SG16@mailbag.cps.intel.com
Betreff:      Call Forward too!... RE: AW: Call hold and transfer in H.323
Anne xF. Too limited??
Frank, Karl, Anyone else who's interested,
A limitation in H.450.3 (Call Forward) recently became clear to me, and
the
solution may arrive through the sorts of things Frank's suggesting.
Background:
What I see as a problem arises from the endpoint-centric nature of CFU
(Call
Forward Unconditional), especially in the case where the endpoint being
forwarded is PC-based (probably NOT a SET).
The specific problem:
I would regard as a prime use for CFU to be the ability to set up
forwarding
and then switch off my PC, so that all my calls would then go (for
example)
to a colleague.  Everything seems to be there in H.450.3 to allow this to
happen in the gatekeeper-routed model (obviously the GK-routed model is
likely to be required, because the GK appears to be the only "live" entity
that can do the forwarding), with the exception of the transaction between
my PC and its gatekeeper.
The solution:
I don't know.  Maybe an H.450.3 extension (which has dangers because a GK
is
not normally a callable entity), maybe a new RAS transaction type (but we
don't want proliferation of RAS messages)?
The plea:
I'd like to see some serious suggestions on this, and really drive some
solution towards standardisation, either as an Annex to H.450.3 or
elsewhere.  It seems to me that this is possibly the most important
application of Call Forwarding, so it seems a shame that it is missing.
If consensus works towards a RAS-based solution, we may be able to do this
in a way that will also suit Frank's ideas?
Regards,
Chris
...
-----Original Message-----
From: Derks, Frank [mailto:F.Derks@PBC.BE.PHILIPS.COM]
Sent: 22 March 1999 10:43
To: ITU-SG16@MAILBAG.INTEL.COM
Subject: Re: AW: Call hold and transfer in H.323 AnnexF. Too limited??
Folks,
when talking about a Simple Endpoint Type, I think we should
aim for it to
be something that closely resembles a black phone. This way
it becomes a lot
easier to define what its capabilities are and it makes life
easy on the
users and on those companies that will actually make
(physical) IP-phones.
These phones should probably look and act like the normal
phones that are
currently being used. Looking at how most supplementary services are
accessed in both the public and the private (PBX) networks, I
think it is
safe to say that in most cases we are talking about "stimulus
protocols".
I.e. DTMF digits are sent to an exchange and the exchange
interprets certain
digit sequences as being the invocation of some service
rather than a number
to be dialled. The big advantage over functional protocols
(like H.450.x)
being that services can be added from the exchange side, without the
terminal having to be modified as well.
Functional protocols never became a success in  the ISDN
world and this may
end up to be the same in the IP world. However, having said
this, there is a
lot more potential for easy upgrading of e.g. terminal
software in this
domain, which reduces the side effects of functional protocols.
It does not seem to make sense to define "alternative"
mechanisms to provide
services, so I would strongly opt for using H.450.x when
possible and using
a simple stimulus protocol otherwise. The latter would allow service
providers to easily make services available and I see no
reason why this
should be standardised. In practice, today, we already see
that certain
digit sequences for service activation are identical in
several countries.
Frank

Frank Derks                    |Tel  +31 35 6893238 |
Advanced Development           |Fax  +31 35 6891030 |
Philip Business Communications |P.O. Box 32         |
                               |1200 JD  Hilversum  |
                               |The Netherlands     |
----------------------------------------------------|
E-mail: mailto:f.derks@pbc.be.philips.com           |
WWW: http://www.business-comms.be.philips.com       |

-----Original Message-----
From: Klaghofer Karl ICN IB NL IP 7
[mailto:Karl.Klaghofer@ICN.SIEMENS.DE]
Sent: 18 March 1999 22:36
To: ITU-SG16@MAILBAG.INTEL.COM
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)