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

Hi Paul, I would like to jump in and add my 2 cents. IMHO, I do not agree that you can introduce completely new services without software or hardware upgrades. Actually, I see that as an advantage if my IP phone supplier can add features into my phone with just a software upgrade - ideally of course without a fee -)) and doing it using my IP phone would be definitely simpler than with my PSTN black phone. Also, today for modems or PC applications I have the ability to upgrade my software. Of course, we should try to define our current specifications such that they meet at least all the service deployment requirements for existing services. Thanks, Prasad -----Original Message----- From: Paul E. Jones [mailto:paul.jones@TIES.ITU.INT] Sent: Monday, March 22, 1999 10:11 AM To: ITU-SG16@mailbag.cps.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?? provide the

Hi all, I am glad I spawned this discussion with my question on the intended capabilities and procedures of the text SET. By having the text SET as an example of what you might want to transfer a call to, it becomes clear that the transfer is wanted in a SET, and that the re-negotiation should take place after re-routing. It would not be good tactics to skip such functionality, because that is what is done often in PSTN telephony, and the users tend to want to keep old functionality. It does not mean that it has to be mandatory, but users will expect it to be there. Without looking deeper, I think it seems very strange to start describing a new procedure for call transfer, when one is just finished in standardisation in H.450. One of my goals is to make you realise that there are a lot of users who will regard a standardised text chatting facility very valuable in their black IP-phone as well as in the full H.323 video phone. And to settle the protocols needed for that facility. Regarding the choice between RTP or TCP for the text channel, I have got one reminder about the need to discover network congestions, indicating that TCP would be to prefer. Are there any other strong views on this part of the problem. Regards Gunnar At 12:29 1999-03-22 -0800, Prasad Kallur wrote:
----------------------------------------------- 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)
-
Gunnar Hellstrom
-
Prasad Kallur