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

Paul E. Jones paul.jones at ties.itu.int
Mon Mar 22 16:47:47 EST 1999


Prasad,

While I agree that it would be ideal to have the telephony equipment
upgraded, I claim that it would be a nearly impossible task.

First of all, you may have one of 1000 telephones on the market-- what
firmware revision would you need and for your brand and model?  How do we
upgrade it?  Send somebody to your house, mail it in, or "flash" the box
over the Internet (keep in mind that many of these devices may not be
connected to the Internet)?  Who should perform the upgrade-- the
manufacturer of the phone or the telephony service provider?

Preferably, the phone would be updated by the manufacturer.  That will most
likely preclude one from taking advantage of particular special
("non-standard") services offered by a service provider-- the manufacturer's
supplementary service support may or may not match your service provider's
offerings.

Most importantly, service providers will want to roll out new services that
1) do not require going through the ITU standardization process and 2) are
rolled out more quickly than the ITU standardization process.  To accomplish
that, we need a generic service mechanism that does not live in the
endpoint, but rather lives in the service provider's equipment.

As Chris Purvis pointed out, the limitations with call forwarding as
prescribed in H.450.3 demonstrate the need to have some services performed
by the service provider's equipment.

Paul

-----Original Message-----
From: Prasad Kallur <prasad at TRILLIUM.COM>
To: ITU-SG16 at MAILBAG.INTEL.COM <ITU-SG16 at MAILBAG.INTEL.COM>
Date: Monday, March 22, 1999 3:30 PM
Subject: Re: AW: Call hold and transfer in H.323 AnnexF. Too limited??


>Hi Paul,
>I would like to jump in and add my 2 cents.  IMHO, I do not agree that you
>can introduce completely new services without software or hardware
upgrades.
>Actually, I see that as an advantage if my IP phone supplier can add
>features into my phone with just a software upgrade - ideally of course
>without a fee -)) and doing it using my IP phone would be definitely
simpler
>than with my PSTN black phone.  Also, today for modems or PC applications I
>have the ability to upgrade my software. Of course, we should try to define
>our current specifications such that they meet at least all the service
>deployment requirements for existing services.
>Thanks,
>Prasad
>
>
>-----Original Message-----
>From: Paul E. Jones [mailto:paul.jones at TIES.ITU.INT]
>Sent: Monday, March 22, 1999 10:11 AM
>To: ITU-SG16 at mailbag.cps.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 at PBC.BE.PHILIPS.COM>
>To: ITU-SG16 at MAILBAG.INTEL.COM <ITU-SG16 at 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 at 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 at ICN.SIEMENS.DE]
>>Sent: 18 March 1999 22:36
>>To: ITU-SG16 at 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 at TIES.ITU.INT]
>>> Gesendet am:  Donnerstag, 18. März 1999 18:57
>>> An:   ITU-SG16 at 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 at ICN.SIEMENS.DE>
>>> To: ITU-SG16 at MAILBAG.INTEL.COM <ITU-SG16 at 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 at icn.siemens.de
>>> >
>>> >
>>> >
>>> >> -----Ursprüngliche Nachricht-----
>>> >> Von:  Gunnar Hellstrom [SMTP:gunnar.hellstrom at OMNITOR.SE]
>>> >> Gesendet am:  Dienstag, 16. März 1999 23:01
>>> >> An:   ITU-SG16 at 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,
>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



More information about the sg16-avd mailing list