Re: AW: Call hold and transfer in H.323 AnnexF. Too limited??
Paul,
you got my points exactly right. The reason that I weakened by arguments by hinting at the ease of upgrade in an IP environment was to avoid people coming back with this line of argument. Although using "DTMF digits" as the means to access services may not be the most elegant one, it is probably the simplest and it maps well onto a simple "blackphone" type of terminal. If we do not provide for something fairly simple (both for the users and the service providers) then the chances are that service providers will come up with "(IP) Telephony unrelated" means to access services. E.g. they could provide Web pages that allow customers to specify their service behaviour.
Frank
-----Original Message----- From: Paul E. Jones [mailto:paul.jones@TIES.ITU.INT] Sent: 22 March 1999 19:11 To: ITU-SG16@MAILBAG.INTEL.COM Subject: Re: AW: Call hold and transfer in H.323 AnnexF. Too limited??
Frank,
I do agree that two mechanisms for accomplishing the same task is a bad idea. I, too, would rather see one mechanism employed-- we do want to create interoperable equipment, after all. Unfortunately, we already have two ways of doing "call hold"-- H.450.4 and "empty capability sets" (see 7.6.2 of Annex F).
The issues you raise with supplementary services echoes the concerns of those also participating in the TIPHON work. Essentially, service providers would like to be able to add new services without upgrading software in the endpoints. Although it may be possible to upgrade IP phone devices, I can assure you that the average person would never do that-- once the phone is plugged in, it will stay there until it stops working. More importantly, why would one want to require somebody who purchased a hardware phone device to upgrade periodically?
We need to engineer a solution so that the telephony service providers can introduce new services without requiring software upgrades in the endpoints. I would like to see SET device to take advantage of those newly introduced services without software or hardware upgrades.
Paul
-----Original Message----- From: Derks, Frank F.Derks@PBC.BE.PHILIPS.COM To: ITU-SG16@MAILBAG.INTEL.COM ITU-SG16@MAILBAG.INTEL.COM Date: Monday, March 22, 1999 5:45 AM Subject: Re: AW: Call hold and transfer in H.323 AnnexF. Too limited??
Folks,
when talking about a Simple Endpoint Type, I think we should aim for it to be something that closely resembles a black phone. This way it becomes a
lot
easier to define what its capabilities are and it makes life easy on the users and on those companies that will actually make (physical) IP-phones. These phones should probably look and act like the normal phones that are currently being used. Looking at how most supplementary services are accessed in both the public and the private (PBX) networks, I think it is safe to say that in most cases we are talking about "stimulus protocols". I.e. DTMF digits are sent to an exchange and the exchange interprets
certain
digit sequences as being the invocation of some service rather than a
number
to be dialled. The big advantage over functional protocols (like H.450.x) being that services can be added from the exchange side, without the terminal having to be modified as well.
Functional protocols never became a success in the ISDN world and this may end up to be the same in the IP world. However, having said this, there is
a
lot more potential for easy upgrading of e.g. terminal software in this domain, which reduces the side effects of functional protocols.
It does not seem to make sense to define "alternative" mechanisms to
provide
services, so I would strongly opt for using H.450.x when possible and using a simple stimulus protocol otherwise. The latter would allow service providers to easily make services available and I see no reason why this should be standardised. In practice, today, we already see that certain digit sequences for service activation are identical in several countries.
Frank
Frank Derks |Tel +31 35 6893238 | Advanced Development |Fax +31 35 6891030 | Philip Business Communications |P.O. Box 32 | |1200 JD Hilversum | |The Netherlands | ----------------------------------------------------| E-mail: mailto:f.derks@pbc.be.philips.com | WWW: http://www.business-comms.be.philips.com |
-----Original Message----- From: Klaghofer Karl ICN IB NL IP 7 [mailto:Karl.Klaghofer@ICN.SIEMENS.DE] Sent: 18 March 1999 22:36 To: ITU-SG16@MAILBAG.INTEL.COM 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@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:
- Is that kind of call transfer that is handled by the mechanisms in
7.61
and 7.6.2?
Are my conclusion right about the limitations?
Is this limitation a consequence of using Fast Connect?
Do you see any possibility to avoid the negative effects of it - to
make re-negotiation possible?
- 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:
- 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@omnitor.se Tel +46 751 100 501 fax +46 8 556 002 06
Hei,
I do not think it is a bad thing if ISPs choose to control service profiles/configuration outside of H.450. There are a lot more flexible ways to transport data. Proven technologies exist today which are very flexible and extendible (HTTP, WAP, IVRs, etc). User oriented services might also include non-H.323 equipment (mobile, email, even a SIP terminal!), so confining it to H.450 and H.323 would limit the possibillity for "fancy" services significantly, thereby also limiting the distribution of H.323.
If a Call Forward service is put in the network, it turns more into a user oriented than an endpoint oriented service, and the possibilities for extensions are huge. As soon as the "Call Forward Unreachable" is standardized, I might come up with a proposal for call forward based on week/time, and this will hardly ever stop. We need a flexible mechanism for controlling these services, not new detailed service specifications.
As the mechanisms for a call forward done in the network does not require the same level of interactions as a terminal oriented (or in-call) service, we do not need to follow the same approach as H.450, where services are specified in detail. The H.450 approach makes the creation (and extension) of a service a very lenghty process, and is actually a great obstacle to creativity and development of new user oriented services. (Though for in-call services I don't see any way around it...)
Espen
"Derks, Frank" wrote:
Paul,
you got my points exactly right. The reason that I weakened by arguments by hinting at the ease of upgrade in an IP environment was to avoid people coming back with this line of argument. Although using "DTMF digits" as the means to access services may not be the most elegant one, it is probably the simplest and it maps well onto a simple "blackphone" type of terminal. If we do not provide for something fairly simple (both for the users and the service providers) then the chances are that service providers will come up with "(IP) Telephony unrelated" means to access services. E.g. they could provide Web pages that allow customers to specify their service behaviour.
Frank
-----Original Message----- From: Paul E. Jones [mailto:paul.jones@TIES.ITU.INT] Sent: 22 March 1999 19:11 To: ITU-SG16@MAILBAG.INTEL.COM Subject: Re: AW: Call hold and transfer in H.323 AnnexF. Too limited??
Frank,
I do agree that two mechanisms for accomplishing the same task is a bad idea. I, too, would rather see one mechanism employed-- we do want to create interoperable equipment, after all. Unfortunately, we already have two ways of doing "call hold"-- H.450.4 and "empty capability sets" (see 7.6.2 of Annex F).
The issues you raise with supplementary services echoes the concerns of those also participating in the TIPHON work. Essentially, service providers would like to be able to add new services without upgrading software in the endpoints. Although it may be possible to upgrade IP phone devices, I can assure you that the average person would never do that-- once the phone is plugged in, it will stay there until it stops working. More importantly, why would one want to require somebody who purchased a hardware phone device to upgrade periodically?
We need to engineer a solution so that the telephony service providers can introduce new services without requiring software upgrades in the endpoints. I would like to see SET device to take advantage of those newly introduced services without software or hardware upgrades.
Paul
-----Original Message----- From: Derks, Frank F.Derks@PBC.BE.PHILIPS.COM To: ITU-SG16@MAILBAG.INTEL.COM ITU-SG16@MAILBAG.INTEL.COM Date: Monday, March 22, 1999 5:45 AM Subject: Re: AW: Call hold and transfer in H.323 AnnexF. Too limited??
Folks,
when talking about a Simple Endpoint Type, I think we should aim for it to be something that closely resembles a black phone. This way it becomes a
lot
easier to define what its capabilities are and it makes life easy on the users and on those companies that will actually make (physical) IP-phones. These phones should probably look and act like the normal phones that are currently being used. Looking at how most supplementary services are accessed in both the public and the private (PBX) networks, I think it is safe to say that in most cases we are talking about "stimulus protocols". I.e. DTMF digits are sent to an exchange and the exchange interprets
certain
digit sequences as being the invocation of some service rather than a
number
to be dialled. The big advantage over functional protocols (like H.450.x) being that services can be added from the exchange side, without the terminal having to be modified as well.
Functional protocols never became a success in the ISDN world and this may end up to be the same in the IP world. However, having said this, there is
a
lot more potential for easy upgrading of e.g. terminal software in this domain, which reduces the side effects of functional protocols.
It does not seem to make sense to define "alternative" mechanisms to
provide
services, so I would strongly opt for using H.450.x when possible and using a simple stimulus protocol otherwise. The latter would allow service providers to easily make services available and I see no reason why this should be standardised. In practice, today, we already see that certain digit sequences for service activation are identical in several countries.
Frank
Frank Derks |Tel +31 35 6893238 | Advanced Development |Fax +31 35 6891030 | Philip Business Communications |P.O. Box 32 | |1200 JD Hilversum | |The Netherlands | ----------------------------------------------------| E-mail: mailto:f.derks@pbc.be.philips.com | WWW: http://www.business-comms.be.philips.com |
-----Original Message----- From: Klaghofer Karl ICN IB NL IP 7 [mailto:Karl.Klaghofer@ICN.SIEMENS.DE] Sent: 18 March 1999 22:36 To: ITU-SG16@MAILBAG.INTEL.COM 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@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:
- Is that kind of call transfer that is handled by the mechanisms in
7.61
and 7.6.2?
Are my conclusion right about the limitations?
Is this limitation a consequence of using Fast Connect?
Do you see any possibility to avoid the negative effects of it - to
make re-negotiation possible?
- 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:
- 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@omnitor.se Tel +46 751 100 501 fax +46 8 556 002 06
participants (2)
-
Derks, Frank -
Espen Skjæran