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

Klaghofer Karl ICN IB NL IP 7 Karl.Klaghofer at ICN.SIEMENS.DE
Thu Mar 18 16:36:26 EST 1999


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