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:

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,

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@ICN.SIEMENS.DE> To: ITU-SG16@MAILBAG.INTEL.COM <ITU-SG16@MAILBAG.INTEL.COM> Date: Thursday, March 18, 1999 5:09 PM Subject: AW: AW: Call hold and transfer in H.323 AnnexF. Too limited?? 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