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

Klaghofer Karl ICN IB NL IP 7 Karl.Klaghofer at ICN.SIEMENS.DE
Wed Mar 17 15:15:42 EST 1999


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