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

6 Apr 1999

      All,
I find it hard to believe that we can't do better (from the user's point of
view) than the old black-phone view of the world whereby people have to type
in various combinations of *s and digits to mean various different things to
the local exchange.  Most endpoints, after all, have pretty UIs.
Now at the messaging level it may well make sense to have things APPEAR as
if that (ie the typing of arcane sequences of digits) is what is happening -
and it's possible that all we need to do to make that work in an
interoperable way is to define what sequences of characters in the
destination address in a setup message mean what sort of service.  Do we
start from a point such as "Setup with a single destination address which is
e164 starting with '*' means arcane supplementary service", or define
another alias type for "arcane supplementary service" or what?
My aim is simply that an endpoint vendor should be ABLE to write things that
do not require the user to understand bizarre control sequences, and will be
able to access supplementary services wherever, and by whatever vendor, they
are provided.
Regards,
Chris
--
Dr Chris Purvis - Senior Development Engineer, WAVE CC Software
Madge Networks Ltd, Wexham Springs, Framewood Road, Wexham, Berks.  ENGLAND
Phone: +44 1753 661 359  email: cpurvis@madge.com
...
-----Original Message-----
From: Espen Skjæran [mailto:Espen.Skjaeran@ERICSSON.COM]
Sent: 26 March 1999 6:42
To: ITU-SG16@MAILBAG.INTEL.COM
Subject: Re: AW: Call hold and transfer in H.323 AnnexF. Too limited??
Hei,
I do not think it is a bad thing if ISPs choose to control service
profiles/configuration outside of H.450. There are a lot
more flexible ways to transport data. Proven technologies
exist today which are
very flexible and extendible (HTTP, WAP, IVRs, etc). User
oriented services
might also include non-H.323 equipment (mobile, email, even a
SIP terminal!), so
confining it to H.450 and H.323 would limit the possibillity
for "fancy"
services significantly, thereby also limiting the
distribution of H.323.
If a Call Forward service is put in the network, it turns
more into a user
oriented than an endpoint oriented service, and the
possibilities for extensions are huge. As soon as the "Call
Forward Unreachable"
is standardized, I might come up with a proposal for call
forward based on
week/time, and this will hardly ever stop. We need a flexible
mechanism for
controlling these services, not new detailed service specifications.
As the mechanisms for a call forward done in the network does
not require the
same level of interactions as a terminal
oriented (or in-call) service, we do not need to follow the
same approach as
H.450, where services are specified in detail.
The H.450 approach makes the creation (and extension) of a
service a very
lenghty process, and is actually a great
obstacle to creativity and development of new user oriented
services. (Though
for in-call services I don't see any way around it...)
Espen
"Derks, Frank" wrote:
...
Paul,
you got my points exactly right. The reason that I weakened
by arguments by
...
hinting at the ease of upgrade in an IP environment was to
avoid people
...
coming back with this line of argument. Although using
"DTMF digits" as the
...
means to access services may not be the most elegant one,
it is probably the
...
simplest and it maps well onto a simple "blackphone" type
of terminal. If we
...
do not provide for something fairly simple (both for the
users and the
...
service providers) then the chances are that service
providers will come up
...
with "(IP) Telephony unrelated" means to access services.
E.g. they could
...
provide  Web pages that allow customers to specify their
service behaviour.
...
Frank
-----Original Message-----
From: Paul E. Jones [mailto:paul.jones@TIES.ITU.INT]
Sent: 22 March 1999 19:11
To: ITU-SG16@MAILBAG.INTEL.COM
Subject: Re: AW: Call hold and transfer in H.323 AnnexF.
Too limited??
...
Frank,
I do agree that two mechanisms for accomplishing the same
task is a bad
...
idea.  I, too, would rather see one mechanism employed-- we
do want to
...
create interoperable equipment, after all.  Unfortunately,
we already have
...
two ways of doing "call hold"-- H.450.4 and "empty
capability sets" (see
...
7.6.2 of Annex F).
The issues you raise with supplementary services echoes the
concerns of
...
those also participating in the TIPHON work.  Essentially,
service providers
...
would like to be able to add new services without upgrading
software in the
...
endpoints.  Although it may be possible to upgrade IP phone
devices, I can
...
assure you that the average person would never do that--
once the phone is
...
plugged in, it will stay there until it stops working.
More importantly,
...
why would one want to require somebody who purchased a
hardware phone device
...
to upgrade periodically?
We need to engineer a solution so that the telephony
service providers can
...
introduce new services without requiring software upgrades
in the endpoints.
...
I would like to see SET device to take advantage of those
newly introduced
...
services without software or hardware upgrades.
Paul
-----Original Message-----
From: Derks, Frank F.Derks@PBC.BE.PHILIPS.COM
To: ITU-SG16@MAILBAG.INTEL.COM ITU-SG16@MAILBAG.INTEL.COM
Date: Monday, March 22, 1999 5:45 AM
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
**********************************************************************
This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they
are addressed. If you have received this email in error please notify
the system manager.
This footnote also confirms that this email message has been swept by
MIMEsweeper for the presence of computer viruses.
www.mimesweeper.com
**********************************************************************

Chris Purvis

Gunnar Hellström

tags (0)

participants (1)