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

[Gunnar Hellstrom]

Paul and all,
How about the other conclusions from earlier comments?

The re-negotiating of coding standard for the medium, and the addition of
one more medium ( in this case text)
is that also more than you would expect from a SET?

Gunnar

At 12:56 1999-03-18 -0500, Paul E. Jones wrote:
>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.
>
>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
>
>