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

Espen Skjæran Espen.Skjaeran at ericsson.com
Fri Mar 26 13:42:18 EST 1999


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 at TIES.ITU.INT]
> Sent: 22 March 1999 19:11
> To: ITU-SG16 at 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 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