masterSlaveDetermination procedure

[henri.maenpaa at NOKIA.COM]

Paul,
Agreed.
Karl

> -----Ursprüngliche Nachricht-----
> Von:  Paul E. Jones [SMTP:paul.jones at ties.itu.int]
> Gesendet am:  Montag, 22. März 1999 18:42
> An:   Klaghofer Karl ICN IB NL IP 7; ITU-SG16 at mailbag.cps.intel.com
> Betreff:      Re:      AW: AW: Call hold and transfer in H.323 AnnexF. Too
> limited??
>
> 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