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

[Paul E. Jones]

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 at ICN.SIEMENS.DE>
To: ITU-SG16 at MAILBAG.INTEL.COM <ITU-SG16 at 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 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