- sg16-avd - lists.packetizer.com

Re: AW: Call hold and transfer in H.323 AnnexF. Too limited??
by Derks, Frank 26 Mar '99

26 Mar '99

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(a)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(a)PBC.BE.PHILIPS.COM> To: ITU-SG16(a)MAILBAG.INTEL.COM <ITU-SG16(a)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(a)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(a)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(a)ICN.SIEMENS.DE> >> To: ITU-SG16(a)MAILBAG.INTEL.COM <ITU-SG16(a)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(a)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(a)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(a)omnitor.se >> >> Tel +46 751 100 501 >> >> fax +46 8 556 002 06

2 1

Re: Call Transfer
by Wuerfel, Randy P 26 Mar '99

26 Mar '99

See the modifications proposed below to Karl's Implementor's Guide text for Endpoint B exceptional procedures. ========================================================== Randy Wuerfel Enterprise Network Systems Development Unisphere Solutions, Inc. E-mail: Randy.P.Wuerfel(a)icn.siemens.com 4900 Old Ironsides Drive Fax: (408) 492-4666 M/S 200 Tel: (408) 492-4375 P.O. Box 58075 Santa Clara, CA 95052-8075 -----Original Message----- From: Klaghofer Karl ICN IB NL IP 7 [mailto:Karl.Klaghofer@ICN.SIEMENS.DE] Sent: Friday, March 26, 1999 2:33 AM To: ITU-SG16(a)mailbag.cps.intel.com Subject: AW: Call Transfer Transfer with Consultation: As Ernst pointed out, we need the ctSetup Invoke as it is defined in case of Transfer with Consultation. Transfer without Consultation (i.e. no secondary call exists): Some history: H.450.2 has chosen to use the same operation (ctSetup Invoke) in both cases. Transfer with and Transfer without Consultation in order to avoid having different procedures / state events within endpoint B for those two cases (with and without Consult). However, the point Espen raised is a valid question. We should put some exceptional procedure handling to the implementors guide (based on the suggestions made by Ernst) that clarify the usage of Transfer without Consultation in conjunction with an endpoint C that does not support Transfer. If endpoint C does not support H.450 at all, a basic call ALERTING, CONNECT would be received in endpoint B. This would lead to a FACILITY with ctInitiate Return error being sent to A (since ctSetup operation needs explicit confirmation). Endpoint B would end up with two calls A and C. To avoid this, the implementors guide should state some exceptional procedure handling that would apply to Transfer without Consultation (i.e. no secondary call exists). " Endpoint B exceptional procedures: a) When receiving an ALERTING or CONNECT message from endpoint C (that does not include a response to the ctSetup Invoke) while being in state CT-Await-Setup-Response, the transferred endpoint B shall (or may ?) continue as if a ctSetup Return Result had been received. This allows endpoint B to successfully continue with the Call Transfer procedures (i.e. appropriate internal call transfer state handling and clearing of the primary call to the transferring endpoint A). This exceptional procedure enables successful Call Transfer when the transferred-to endpoint C does not support H.450. b) When a RELEASE COMPLETE message is received (possibly containing a ctSetup return error APDU) in response to a SETUP message that contained a ctSetup Invoke sent by endpoint B (which happens if endpoint C supports H.450.1, but not H.450.2), then endpoint B may retry call establishment to endpoint C using a normal basic call (i.e. by sending a SETUP message without a ctSetup invoke APDU). Upon receiving an ALERTING or CONNECT message from endpoint C on this new call, the procedures as described above in a) shall apply. " Remark: If endpoint C supports H.450.1 but no H.450.2, I would NOT start ignoring the i-apdu "clear call". I-apdu always shall be honoured (if H.450.1 is supported), since C does not know that this is about call transfer (so it can not really be an exceptional procedure as part of a Call Transfer standard). This would cause problems when further supplementary services are inroduced that also use i-apdu "clear call". Any comments ? Regards, Karl Klaghofer Siemens AG ------------------------------------------------------ The simplest option is to just relax the 'clearCall' requirement in case of single-step transfer. The effect would be that a ctInitiate error is returned to user A and the primary call is not cleared. User B would have two calls to handle. Another alternative is the simple option plus adding the clearing of the primary call to the exceptional procedures for the transferred endpoint. This leaves a clean situation for all users, with B and C having an active call. For the consultation case H.450.2 should stay as it is. > -----Ursprüngliche Nachricht----- > Von: Ernst Horvath [SMTP:ernst.horvath@SIEMENS.AT] <mailto:[SMTP:ernst.horvath@SIEMENS.AT]> > Gesendet am: Mittwoch, 24. März 1999 10:58 > An: ITU-SG16(a)mailbag.cps.intel.com <mailto:ITU-SG16@mailbag.cps.intel.com> > Betreff: AW: Call Transfer > > We must consider two cases: > > First case: a secondary call exists. Here the new call from the > transferred endpoint is to replace an existing call which is identified > by the callIdentity value in the callTransferSetup invoke APDU. It is > essential that the transferred-to endpoint matches the new call and the > existing call, accepts the ne and releases the old call. Otherwise, if > the new call is treated just as another basic call, the called user may > be considered busy (with the old call). > > > Second case: No secondary call exists ("single step transfer"). Here > the requirement could be relaxed, the new call could be treated as just > a basic call if callTransferSetup is not understood. This would be the > case anyway if H.450.1 is also not supported. > The main consequence would be that the additional information about the > call having been transferred is lost. > Of course, also with the existing H.450.2, the transferred endpoint can > always repeat the SETUP without a callTransferSetup APDU when the first > SETUP fails. > > Ernst Horvath > Siemens AG > maito: ernst.horvath(a)siemens.at <mailto:ernst.horvath@siemens.at> > > > > -----Ursprüngliche Nachricht----- > Von: Espen.Skjaeran [SMTP:Espen.Skjaeran@ERICSSON.COM] <mailto:[SMTP:Espen.Skjaeran@ERICSSON.COM]> > Gesendet am: Dienstag, 23. März 1999 20:44 > An: ITU-SG16 > Cc: Espen.Skjaeran > Betreff: Call Transfer > > Hi, > > I have a specific question to H.450.2 Call Transfer. > -Why do the transferred-to endpoint have to support the service? > > Section 6 of H.450.2 states > "When conveying the invoke APDU of operation callTransferSetup, the > Interpretation APDU shall contain value > clearCallIfAnyInvokePduNotRecognized" > which I find to mean "if you don't support the service, forget it" > > The session between the transferred and the transferred-to endpoint > follows a basic call, and no useful information is returned > in the ctSetup. result operation. Why can't it be "dumb" and only > believe it is doing a basic call? > Isn't the receipt of ALERTING/CONNECT instead of RELEASE COMPLETE > acknowledgement enough that the transfer was successfull? > > Anyone to clear up this? > > Thanks, > Espen

1 0

Re: Draft Megaco Protocol proposal from the design team
by Nancy-M Greene 26 Mar '99

26 Mar '99

The email system broke my URL into two lines. So here is a shorter URL that gets you to the directory the draft is in: ftp://standards.nortelnetworks.com/megaco/docs/oslo99 Nancy -------------------------------------------------------------------------- Nancy M. Greene Internet & Service Provider Networks, Nortel Networks T:514-271-7221 (internal:ESN853-1077) E:ngreene@nortelnetworks.com > ---------- > From: Greene, Nancy-M [CAR:5N10:EXCH] > Sent: Friday, March 26, 1999 4:18 AM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: Draft Megaco Protocol proposal from the design team > > draft-ietf-megaco-protocol-00.txt has been submitted to the > IETF Internet Drafts editor, and should be announced shortly. > You can find the draft at: > > ftp://standards.nortelnetworks.com/megaco/docs/oslo99/draft-ietf-megaco-pr > ot > ocol-00.txt > (NOTE that the url starts with ftp) > > This draft is the result of a large amount of effort by the > design team over the past two weeks. On the other hand, the > document is what it's title says, a draft proposed protocol > definition. It is not a "take it or leave it" affair, but > we do hope you will find it suitable as a baseline text. > > We welcome your comments and suggestions to the list on the > draft. > > If you are participating on the conference call next Monday, > PLEASE READ THE DRAFT BEFORE YOU CALL IN. > > > > > -------------------------------------------------------------------------- > Nancy M. Greene > Internet & Service Provider Networks, Nortel Networks > T:514-271-7221 (internal:ESN853-1077) E:ngreene@nortelnetworks.com >

1 0

AW: Call Transfer
by Klaghofer Karl ICN IB NL IP 7 26 Mar '99

26 Mar '99

Transfer with Consultation: As Ernst pointed out, we need the ctSetup Invoke as it is defined in case of Transfer with Consultation. Transfer without Consultation (i.e. no secondary call exists): Some history: H.450.2 has choosen to use the same operation (ctSetup Invoke) in both cases Transfer with and Transfer without Consultation in order to avoid having different procedures / state events within endpoint B for those two cases (with and without Consult). However, the point Espen raised is a valid question. We should put some exceptional procedure handling to the implementors guide (based on the suggestions made by Ernst) that clarify the usage of Transfer without Consultation in conjunction with an endpoint C that does not support Transfer. If endpoint C does not support H.450 at all, a basic call ALERTING, CONNECT would be received in endpoint B. This would lead to a FACILITY with ctInitiate Return error being sent to A (since ctSetup operation needs explicit confirmation). Endpoint B would end up with two calls A and C. To avoid this, the implementors guide should state some exceptional procedure handling that would apply to Transfer without Consultation (i.e. no secondary call exists). " Endpoint B exceptional procedures: a) When receiving a CONNECT from endpoint C (that does not include a response to the ctSetup Invoke) while being in state CT-Await-Setup-Response, the transferred endpoint B shall (or may ?) continue as if a ctSetup Return Result would have been received. This allows endpoint B to successfully continue with the Call Transfer procedures (i.e. appropriate internal call transfer state handling and clearing of the primary call to the transferring endpoint A). This exceptional procedure enables successful Call Transfer even if the transferred-to endpoint C does not support H.450 at all. b) When a RELEASE COMPLETE as a response to ctSetup Invoke is received in endpoint B on the new call (which happens if the endpoint C supports H.450.1 but not H.450.2), then the endpoint B may retry call establishmet to endpoint C using a normal basic call. Upon receiving CONNECT from endpoint C, the procedures as described above in a) shall apply. " Remark: If endpoint C supports H.450.1 but no H.450.2, I would NOT start ignoring the i-apdu "clear call". I-apdu always shall be honoured (if H.450.1 is supported), since C does not know that this is about call transfer (so it can not really be an exceptional procedure as part of a Call Transfer standard). This would cause problems when further supplementary services are inroduced that also use i-apdu "clear call". Any comments ? Regards, Karl Klaghofer Siemens AG ------------------------------------------------------ The simplest option is to just relax the 'clearCall' requirement in case of single-step transfer. The effect would be that a ctInitiate error is returned to user A and the primary call is not cleared. User B would have two calls to handle. Another alternative is the simple option plus adding the clearing of the primary call to the exceptional procedures for the transferred endpoint. This leaves a clean situation for all users, with B and C having an active call. For the consultation case H.450.2 should stay as it is. > -----Ursprüngliche Nachricht----- > Von: Ernst Horvath [SMTP:ernst.horvath@SIEMENS.AT] > Gesendet am: Mittwoch, 24. März 1999 10:58 > An: ITU-SG16(a)mailbag.cps.intel.com > Betreff: AW: Call Transfer > > We must consider two cases: > > First case: a secondary call exists. Here the new call from the > transferred endpoint is to replace an existing call which is identified > by the callIdentity value in the callTransferSetup invoke APDU. It is > essential that the transferred-to endpoint matches the new call and the > existing call, accepts the ne and releases the old call. Otherwise, if > the new call is treated just as another basic call, the called user may > be considered busy (with the old call). > > > Second case: No secondary call exists ("single step transfer"). Here > the requirement could be relaxed, the new call could be treated as just > a basic call if callTransferSetup is not understood. This would be the > case anyway if H.450.1 is also not supported. > The main consequence would be that the additional information about the > call having been transferred is lost. > Of course, also with the existing H.450.2, the transferred endpoint can > always repeat the SETUP without a callTransferSetup APDU when the first > SETUP fails. > > Ernst Horvath > Siemens AG > maito: ernst.horvath(a)siemens.at > > > > -----Ursprüngliche Nachricht----- > Von: Espen.Skjaeran [SMTP:Espen.Skjaeran@ERICSSON.COM] > Gesendet am: Dienstag, 23. März 1999 20:44 > An: ITU-SG16 > Cc: Espen.Skjaeran > Betreff: Call Transfer > > Hi, > > I have a specific question to H.450.2 Call Transfer. > -Why do the transferred-to endpoint have to support the service? > > Section 6 of H.450.2 states > "When conveying the invoke APDU of operation callTransferSetup, the > Interpretation APDU shall contain value > clearCallIfAnyInvokePduNotRecognized" > which I find to mean "if you don't support the service, forget it" > > The session between the transferred and the transferred-to endpoint > follows a basic call, and no useful information is returned > in the ctSetup. result operation. Why can't it be "dumb" and only > believe it is doing a basic call? > Isn't the receipt of ALERTING/CONNECT instead of RELEASE COMPLETE > acknowledgement enough that the transfer was successfull? > > Anyone to clear up this? > > Thanks, > Espen

1 0

Draft Megaco Protocol proposal from the design team
by Nancy-M Greene 26 Mar '99

26 Mar '99

draft-ietf-megaco-protocol-00.txt has been submitted to the IETF Internet Drafts editor, and should be announced shortly. You can find the draft at: ftp://standards.nortelnetworks.com/megaco/docs/oslo99/draft-ietf-megaco-prot ocol-00.txt (NOTE that the url starts with ftp) This draft is the result of a large amount of effort by the design team over the past two weeks. On the other hand, the document is what it's title says, a draft proposed protocol definition. It is not a "take it or leave it" affair, but we do hope you will find it suitable as a baseline text. We welcome your comments and suggestions to the list on the draft. If you are participating on the conference call next Monday, PLEASE READ THE DRAFT BEFORE YOU CALL IN. -------------------------------------------------------------------------- Nancy M. Greene Internet & Service Provider Networks, Nortel Networks T:514-271-7221 (internal:ESN853-1077) E:ngreene@nortelnetworks.com

1 0

Re: masterSlaveDetermination procedure
by Bose 26 Mar '99

26 Mar '99

> > > >I've understood masterSlaveDetermination procedure goes as follows: > >1. EP1 sends mSD message with a value specific to it and also the random > >number. > >2. EP2 sends back an mSDAck with slave/master info (after comparing its own > >and EP1's related info). > >3. EP1 yet sends mSDAck to EP2 with slave/master info. > > > >Question: Could someone try to explain the reasoning behind the "third > >message", that is, what is it needed for? > >Manoj wrote > Step 3 is needed because EP2 needs to know if the result of the > present instance of MSD procedure is known to EP1. EP2 can not > initiate those procedures which rely on the knowledge of the MSD > result, until it has received confirmation that EP1 terminal > also has knwoledge of the result of the current MSD Preocedure. > That's why Step 3 is required. If the MSDAck doesn't reach EP1, EP1 will send MSDRelease to EP2. In Terminal Capability exchange also we can not initiate those procedures which rely on Terminal Capability. We don't have step 3 there. Then Why a special 3rd step in MSD? regards Bose

1 0

RE: ITU/IETF audio call announcement
by Bryan Hill 25 Mar '99

25 Mar '99

Note change in passcode!!! The new passcode: 131313# Sorry for any confusion. . . . -----Original Message----- From: Bryan Hill Sent: Thursday, March 25, 1999 9:22 AM To: ITU-SG16 (E-mail) Subject: ITU/IETF audio call announcement To IETF Megaco participants, and ITU-T SG16 participants, As most of you know, both the IETF and the ITU have working groups defining a device control protocol to be used between a media gateway controller and a media gateway. In ETSI-Tiphon, this is called the N-interface. Since November, there have been two different proposals on the table in both Megaco and in the SG16 group (MGCP and MDCP). There has also been a compromise proposal - MGCP-modified. MGCP and MDCP differ in many areas, the main one being the connection model. A goal shared by many, is to coordinate the Megaco work with the SG16 H.gcp work, and even to end up with ONE protocol, not two. At the Monterey ITU meeting, the MGCP/MDCP debate was directed at the connection model, and at the IETF meeting in Minneapolis last week, these debates continued. A design team was formed of authors of MGCP, MDCP, and MGCP-modified. Brian Hill, the H.GCP editor and Glen Freundlich were also present from SG16. The different connection models were presented, discussed, dissected... and we ended up inventing brand new terminology to allow us to explain a new connection model. While the terms context and termination may not seem clear at first, they do allow us to look at the problem anew, without the baggage of other proposals getting in the way. Brian Rosen presented the new connection model to the Megaco WG last Tuesday (3/16), and to the ITU during the H.gcp audio call this past Tuesday (3/23). Since then, a group of us has been fleshing out the model, defining commands, .... People from BOTH SG16 and the IETF have been involved. The result is the megaco protocol internet-draft that will be out this week, and sent to both the megaco(a)baynetworks.com <mailto:megaco@baynetworks.com> and the itu-sg16(a)mailbag.intel.com <mailto:itu-sg16@mailbag.intel.com> mailing lists. This internet-draft should be seen as a **working draft** - it has a good introduction to the new connection model, and provides descriptions of the commands, but certain sections contain editor notes that document unresolved issues. And some sections may be left blank. Anyone who would propose a different way to do something just needs to write it up and send it to the mailing lists for discussion. To foster collaboration, we are holding an audio call Monday March 29th at 10am EST, to which all participants in megaco and SG16 are invited. It will be a chance to air concerns and criticisms of the internet-draft, so that working group chairs and document editors can get a feel for the degree of agreement between the two groups. IMPORTANT: *****The audio call cannot make any decisions. There will certainly be people that won't be available for the call. *****Comments sent to the mailing lists carry equal weight to any discussions held in the audio call. *****The minutes of the audio call will be published to the mailing lists. Ideally, the SG16 group would agree to as much of the internet-draft as they can, and turn it into the current version of H.GCP. The more we agree on between the two groups the better. CALL DETAILS: DATE: Monday, March 29/99 TIME: 10amEST till 12pmEST NUMBER: 613-763-6338 PASSCODE: 131313# CHAIR: Nancy Greene problems joining? Call 613-765-CONF (613-765-2663) 90 ports have been booked. NOTES: * because of the potentially large # of people, no tones will be used to mark people joining or leaving * to improve the voice quality, it is important to mute your phone when you are not speaking - press 63 to mute, and 66 to unmute. Nancy Greene Bryan Hill ngreene(a)nortelnetworks.com <mailto:ngreene@nortelnetworks.com> bhill(a)videoserver.com <mailto:bhill@videoserver.com>

1 0

Re: masterSlaveDetermination procedure
by Manoj Paul 25 Mar '99

25 Mar '99

> > > >I've understood masterSlaveDetermination procedure goes as follows: > >1. EP1 sends mSD message with a value specific to it and also the random > >number. > >2. EP2 sends back an mSDAck with slave/master info (after comparing its own > >and EP1's related info). > >3. EP1 yet sends mSDAck to EP2 with slave/master info. > > > >Question: Could someone try to explain the reasoning behind the "third > >message", that is, what is it needed for? > Step 3 is needed because EP2 needs to know if the result of the present instance of MSD procedure is known to EP1. EP2 can not initiate those procedures which rely on the knowledge of the MSD result, until it has received confirmation that EP1 terminal also has knwoledge of the result of the current MSD Preocedure. That's why Step 3 is required. regards Manoj.

1 0

ITU/IETF audio call announcement
by Bryan Hill 25 Mar '99

25 Mar '99

To IETF Megaco participants, and ITU-T SG16 participants, As most of you know, both the IETF and the ITU have working groups defining a device control protocol to be used between a media gateway controller and a media gateway. In ETSI-Tiphon, this is called the N-interface. Since November, there have been two different proposals on the table in both Megaco and in the SG16 group (MGCP and MDCP). There has also been a compromise proposal - MGCP-modified. MGCP and MDCP differ in many areas, the main one being the connection model. A goal shared by many, is to coordinate the Megaco work with the SG16 H.gcp work, and even to end up with ONE protocol, not two. At the Monterey ITU meeting, the MGCP/MDCP debate was directed at the connection model, and at the IETF meeting in Minneapolis last week, these debates continued. A design team was formed of authors of MGCP, MDCP, and MGCP-modified. Brian Hill, the H.GCP editor and Glen Freundlich were also present from SG16. The different connection models were presented, discussed, dissected... and we ended up inventing brand new terminology to allow us to explain a new connection model. While the terms context and termination may not seem clear at first, they do allow us to look at the problem anew, without the baggage of other proposals getting in the way. Brian Rosen presented the new connection model to the Megaco WG last Tuesday (3/16), and to the ITU during the H.gcp audio call this past Tuesday (3/23). Since then, a group of us has been fleshing out the model, defining commands, .... People from BOTH SG16 and the IETF have been involved. The result is the megaco protocol internet-draft that will be out this week, and sent to both the megaco(a)baynetworks.com <mailto:megaco@baynetworks.com> and the itu-sg16(a)mailbag.intel.com <mailto:itu-sg16@mailbag.intel.com> mailing lists. This internet-draft should be seen as a **working draft** - it has a good introduction to the new connection model, and provides descriptions of the commands, but certain sections contain editor notes that document unresolved issues. And some sections may be left blank. Anyone who would propose a different way to do something just needs to write it up and send it to the mailing lists for discussion. To foster collaboration, we are holding an audio call Monday March 29th at 10am EST, to which all participants in megaco and SG16 are invited. It will be a chance to air concerns and criticisms of the internet-draft, so that working group chairs and document editors can get a feel for the degree of agreement between the two groups. IMPORTANT: *****The audio call cannot make any decisions. There will certainly be people that won't be available for the call. *****Comments sent to the mailing lists carry equal weight to any discussions held in the audio call. *****The minutes of the audio call will be published to the mailing lists. Ideally, the SG16 group would agree to as much of the internet-draft as they can, and turn it into the current version of H.GCP. The more we agree on between the two groups the better. CALL DETAILS: DATE: Monday, March 29/99 TIME: 10amEST till 12pmEST NUMBER: 613-763-6338 PASSCODE: 121212# CHAIR: Nancy Greene problems joining? Call 613-765-CONF (613-765-2663) 90 ports have been booked. NOTES: * because of the potentially large # of people, no tones will be used to mark people joining or leaving * to improve the voice quality, it is important to mute your phone when you are not speaking - press 63 to mute, and 66 to unmute. Nancy Greene Bryan Hill ngreene(a)nortelnetworks.com <mailto:ngreene@nortelnetworks.com> bhill(a)videoserver.com <mailto:bhill@videoserver.com>

1 0

masterSlaveDetermination procedure
by henri.maenpaa＠NOKIA.COM 24 Mar '99

24 Mar '99

Hi, I've understood masterSlaveDetermination procedure goes as follows: 1. EP1 sends mSD message with a value specific to it and also the random number. 2. EP2 sends back an mSDAck with slave/master info (after comparing its own and EP1's related info). 3. EP1 yet sends mSDAck to EP2 with slave/master info. Question: Could someone try to explain the reasoning behind the "third message", that is, what is it needed for? Thank you, Henri Mäenpää

2 1

Re: Call Forward too!... RE: AW: Call hold and transfer in H.323 Anne xF. Too limited??
by Derks, Frank 24 Mar '99

24 Mar '99

Karl, the limitation is not necessarily in H.450.3, but more general in the fact that H.450.x itself is a fairly complex mechanism for supplementary services, which call hold and transfer also are! If supplementary services are to be supported, then it would be preferable for this to be through one single mechanism. Furthermore, if this mechanism is going to be H.450.x then it would probably be extremely useful to standardise an (terminal) architecture that would allow addition of services on a per service basis, rather than having to upgrade the complete terminal software. This would enable service providers to provide their customers with specific services, rather than have the customers and the service providers wait for a bunch of manufacturers to implement these in their own (proprietary) ways. Using something like UserInputIndications would make life a lot easier. Frank -----Original Message----- From: Klaghofer Karl ICN IB NL IP 7 [mailto:Karl.Klaghofer@ICN.SIEMENS.DE] Sent: 23 March 1999 13:24 To: ITU-SG16(a)MAILBAG.INTEL.COM Subject: AW: Call Forward too!... RE: AW: Call hold and transfer in H.323 Anne xF. Too limited?? I do not see a limitation in H.450.3. If a called endpoint B is out of service (which is very likely for a PC based H.323 endpoint but which may be more an exceptional case for other endpoint types like "black phones"), a proxy function has to act on behalf of the endpoint B, provided you want to successfully establish the call. This is not specific to H.450.3 call diversion but applies to H.323 Basic call functions as well. This proxy function may e.g. be co-located with the gatekeeper or may be located within an other endpoint (with the gk just performing routing to the proxy). The latter one may allow more flexibility and scalability. Anyway, this is an issue of your architecture and does not need to be standardized. As an example, FIGURE 5/H.450.3 shows the forwarding function (i.e. the "served signalling entity") possibly being provided by a proxy function (e.g. for cases where the endpoint is out of service). Of course the proxy function needs knowledge about the activated supplementary services for a given user for which the proxy is acting, which again is an implementation issue. Regards, Karl > -----Ursprüngliche Nachricht----- > Von: Chris Purvis [SMTP:Chris.Purvis@MADGE.COM] > Gesendet am: Montag, 22. März 1999 12:07 > An: ITU-SG16(a)mailbag.cps.intel.com > Betreff: Call Forward too!... RE: AW: Call hold and transfer in H.323 > Anne xF. Too limited?? > > Frank, Karl, Anyone else who's interested, > > A limitation in H.450.3 (Call Forward) recently became clear to me, and > the > solution may arrive through the sorts of things Frank's suggesting. > > Background: > What I see as a problem arises from the endpoint-centric nature of CFU > (Call > Forward Unconditional), especially in the case where the endpoint being > forwarded is PC-based (probably NOT a SET). > > The specific problem: > I would regard as a prime use for CFU to be the ability to set up > forwarding > and then switch off my PC, so that all my calls would then go (for > example) > to a colleague. Everything seems to be there in H.450.3 to allow this to > happen in the gatekeeper-routed model (obviously the GK-routed model is > likely to be required, because the GK appears to be the only "live" entity > that can do the forwarding), with the exception of the transaction between > my PC and its gatekeeper. > > The solution: > I don't know. Maybe an H.450.3 extension (which has dangers because a GK > is > not normally a callable entity), maybe a new RAS transaction type (but we > don't want proliferation of RAS messages)? > > The plea: > I'd like to see some serious suggestions on this, and really drive some > solution towards standardisation, either as an Annex to H.450.3 or > elsewhere. It seems to me that this is possibly the most important > application of Call Forwarding, so it seems a shame that it is missing. > > If consensus works towards a RAS-based solution, we may be able to do this > in a way that will also suit Frank's ideas? > > Regards, > Chris > > > -----Original Message----- > > From: Derks, Frank [mailto:F.Derks@PBC.BE.PHILIPS.COM] > > Sent: 22 March 1999 10:43 > > To: ITU-SG16(a)MAILBAG.INTEL.COM > > 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(a)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(a)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(a)ICN.SIEMENS.DE> > > > To: ITU-SG16(a)MAILBAG.INTEL.COM <ITU-SG16(a)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(a)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(a)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(a)omnitor.se > > > >> Tel +46 751 100 501 > > > >> fax +46 8 556 002 06 > >

1 0

Re: Call Forward too!... RE: AW: Call hold and transfer in H.323 Anne xF. Too limited??
by Chris Purvis 24 Mar '99

24 Mar '99

Karl, > I do not see a limitation in H.450.3. > > If a called endpoint B is out of service (which is very > likely for a PC based H.323 endpoint but which may be more an > exceptional case for other endpoint types like "black > phones"), a proxy function has to act on behalf of the > endpoint B, provided you want to successfully establish the > call. > This is not specific to H.450.3 call diversion but applies to > H.323 Basic call functions as well. I disagree. As far as basic call functions are concerned (ie no forwarding is set up) B's gatekeeper will reject any ARQ trying to reach B, and if it is routing H.225.0 and receives a setup message without having had an ARQ, fail the call by some suitable means. The point IS specific to call forwarding. Without any forwarding set up, I don't see what a "proxy function" is going to do. > This proxy function may e.g. be co-located with the > gatekeeper or may be located within an other endpoint (with > the gk just performing routing to the proxy). The latter one > may allow more flexibility and scalability. Anyway, this is > an issue of your architecture and does not need to be > standardized. Agreed. The salient point here is that we agree the gatekeeper needs knowledge of what's going on (either to provide the service or to perform the routing to an external proxy). > As an example, FIGURE 5/H.450.3 shows the forwarding function > (i.e. the "served signalling entity") possibly being provided > by a proxy function (e.g. for cases where the endpoint is out > of service). Of course the proxy function needs knowledge > about the activated supplementary services for a given user > for which the proxy is acting, which again is an > implementation issue. I disagree with your last sentence here. The way the endpoint communicates "all my calls need to be forwarded to Joe in my absence" to its gatekeeper is certainly NOT just an implementation issue. An endpoint implementor ought to be able to implement a dialogue box on his endpoint, which will set up call forwarding whatever gatekeeper it uses (as long as the gatekeeper has this functionality). (S)he will not be able to do this if that particular communication is not standardised in some way - which seems to me to be a pretty good measure to indicate that it is a standardisation, rather than implementation, issue. As for whether communications between the gatekeeper and the "proxy function" need to be standardised, this is less clear (in my opinion) as it seems a significantly less restrictive requirement for people to need to buy "proxy function" and gatekeeper from the same vendor than to need to buy endpoint, "proxy function" and gatekeeper from the same vendor. However, given all the activity on gateway decomposition, I can imagine that there will be people who disagree. Regards, Chris > > -----Ursprüngliche Nachricht----- > > Von: Chris Purvis [SMTP:Chris.Purvis@MADGE.COM] > > Gesendet am: Montag, 22. März 1999 12:07 > > An: ITU-SG16(a)mailbag.cps.intel.com > > Betreff: Call Forward too!... RE: AW: Call hold and > transfer in H.323 > > Anne xF. Too limited?? > > > > Frank, Karl, Anyone else who's interested, > > > > A limitation in H.450.3 (Call Forward) recently became > clear to me, and > > the > > solution may arrive through the sorts of things Frank's suggesting. > > > > Background: > > What I see as a problem arises from the endpoint-centric > nature of CFU > > (Call > > Forward Unconditional), especially in the case where the > endpoint being > > forwarded is PC-based (probably NOT a SET). > > > > The specific problem: > > I would regard as a prime use for CFU to be the ability to set up > > forwarding > > and then switch off my PC, so that all my calls would then go (for > > example) > > to a colleague. Everything seems to be there in H.450.3 to > allow this to > > happen in the gatekeeper-routed model (obviously the > GK-routed model is > > likely to be required, because the GK appears to be the > only "live" entity > > that can do the forwarding), with the exception of the > transaction between > > my PC and its gatekeeper. > > > > The solution: > > I don't know. Maybe an H.450.3 extension (which has > dangers because a GK > > is > > not normally a callable entity), maybe a new RAS > transaction type (but we > > don't want proliferation of RAS messages)? > > > > The plea: > > I'd like to see some serious suggestions on this, and > really drive some > > solution towards standardisation, either as an Annex to H.450.3 or > > elsewhere. It seems to me that this is possibly the most important > > application of Call Forwarding, so it seems a shame that it > is missing. > > > > If consensus works towards a RAS-based solution, we may be > able to do this > > in a way that will also suit Frank's ideas? > > > > Regards, > > Chris > > > > > -----Original Message----- > > > From: Derks, Frank [mailto:F.Derks@PBC.BE.PHILIPS.COM] > > > Sent: 22 March 1999 10:43 > > > To: ITU-SG16(a)MAILBAG.INTEL.COM > > > 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(a)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(a)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(a)ICN.SIEMENS.DE> > > > > To: ITU-SG16(a)MAILBAG.INTEL.COM <ITU-SG16(a)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(a)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(a)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(a)omnitor.se > > > > >> Tel +46 751 100 501 > > > > >> fax +46 8 556 002 06 > > > >

1 0

AW: Call Transfer
by Ernst Horvath 24 Mar '99

24 Mar '99

We must consider two cases: First case: a secondary call exists. Here the new call from the transferred endpoint is to replace an existing call which is identified by the callIdentity value in the callTransferSetup invoke APDU. It is essential that the transferred-to endpoint matches the new call and the existing call, accepts the ne and releases the old call. Otherwise, if the new call is treated just as another basic call, the called user may be considered busy (with the old call). Second case: No secondary call exists ("single step transfer"). Here the requirement could be relaxed, the new call could be treated as just a basic call if callTransferSetup is not understood. This would be the case anyway if H.450.1 is also not supported. The main consequence would be that the additional information about the call having been transferred is lost. Of course, also with the existing H.450.2, the transferred endpoint can always repeat the SETUP without a callTransferSetup APDU when the first SETUP fails. Ernst Horvath Siemens AG maito: ernst.horvath(a)siemens.at -----Ursprüngliche Nachricht----- Von: Espen.Skjaeran [SMTP:Espen.Skjaeran@ERICSSON.COM] Gesendet am: Dienstag, 23. März 1999 20:44 An: ITU-SG16 Cc: Espen.Skjaeran Betreff: Call Transfer Hi, I have a specific question to H.450.2 Call Transfer. -Why do the transferred-to endpoint have to support the service? Section 6 of H.450.2 states "When conveying the invoke APDU of operation callTransferSetup, the Interpretation APDU shall contain value clearCallIfAnyInvokePduNotRecognized" which I find to mean "if you don't support the service, forget it" The session between the transferred and the transferred-to endpoint follows a basic call, and no useful information is returned in the ctSetup. result operation. Why can't it be "dumb" and only believe it is doing a basic call? Isn't the receipt of ALERTING/CONNECT instead of RELEASE COMPLETE acknowledgement enough that the transfer was successfull? Anyone to clear up this? Thanks, Espen

1 0

Call Transfer
by Espen Skjæran 23 Mar '99

23 Mar '99

Hi, I have a specific question to H.450.2 Call Transfer. -Why do the transferred-to endpoint have to support the service? Section 6 of H.450.2 states "When conveying the invoke APDU of operation callTransferSetup, the Interpretation APDU shall contain value clearCallIfAnyInvokePduNotRecognized" which I find to mean "if you don't support the service, forget it" The session between the transferred and the transferred-to endpoint follows a basic call, and no useful information is returned in the ctSetup. result operation. Why can't it be "dumb" and only believe it is doing a basic call? Isn't the receipt of ALERTING/CONNECT instead of RELEASE COMPLETE acknowledgement enough that the transfer was successfull? Anyone to clear up this? Thanks, Espen

1 0

H.GCP Conference Call
by Tom-PT Taylor 23 Mar '99

23 Mar '99

My apologies for missing this call. I got calls mixed up and thought this was another one on which I was not needed. Tom Taylor E-mail: taylor(a)nortelnetworks.com (internally Tom-PT Taylor) Tel.: +1 613 765 4167 (internally 395-4167) This is frequently forwarded to my residence.

1 0

AW: Call Forward too!... RE: AW: Call hold and transfer in H.323 Anne xF. Too limited??
by Klaghofer Karl ICN IB NL IP 7 23 Mar '99

23 Mar '99

I do not see a limitation in H.450.3. If a called endpoint B is out of service (which is very likely for a PC based H.323 endpoint but which may be more an exceptional case for other endpoint types like "black phones"), a proxy function has to act on behalf of the endpoint B, provided you want to successfully establish the call. This is not specific to H.450.3 call diversion but applies to H.323 Basic call functions as well. This proxy function may e.g. be co-located with the gatekeeper or may be located within an other endpoint (with the gk just performing routing to the proxy). The latter one may allow more flexibility and scalability. Anyway, this is an issue of your architecture and does not need to be standardized. As an example, FIGURE 5/H.450.3 shows the forwarding function (i.e. the "served signalling entity") possibly being provided by a proxy function (e.g. for cases where the endpoint is out of service). Of course the proxy function needs knowledge about the activated supplementary services for a given user for which the proxy is acting, which again is an implementation issue. Regards, Karl > -----Ursprüngliche Nachricht----- > Von: Chris Purvis [SMTP:Chris.Purvis@MADGE.COM] > Gesendet am: Montag, 22. März 1999 12:07 > An: ITU-SG16(a)mailbag.cps.intel.com > Betreff: Call Forward too!... RE: AW: Call hold and transfer in H.323 > Anne xF. Too limited?? > > Frank, Karl, Anyone else who's interested, > > A limitation in H.450.3 (Call Forward) recently became clear to me, and > the > solution may arrive through the sorts of things Frank's suggesting. > > Background: > What I see as a problem arises from the endpoint-centric nature of CFU > (Call > Forward Unconditional), especially in the case where the endpoint being > forwarded is PC-based (probably NOT a SET). > > The specific problem: > I would regard as a prime use for CFU to be the ability to set up > forwarding > and then switch off my PC, so that all my calls would then go (for > example) > to a colleague. Everything seems to be there in H.450.3 to allow this to > happen in the gatekeeper-routed model (obviously the GK-routed model is > likely to be required, because the GK appears to be the only "live" entity > that can do the forwarding), with the exception of the transaction between > my PC and its gatekeeper. > > The solution: > I don't know. Maybe an H.450.3 extension (which has dangers because a GK > is > not normally a callable entity), maybe a new RAS transaction type (but we > don't want proliferation of RAS messages)? > > The plea: > I'd like to see some serious suggestions on this, and really drive some > solution towards standardisation, either as an Annex to H.450.3 or > elsewhere. It seems to me that this is possibly the most important > application of Call Forwarding, so it seems a shame that it is missing. > > If consensus works towards a RAS-based solution, we may be able to do this > in a way that will also suit Frank's ideas? > > Regards, > Chris > > > -----Original Message----- > > From: Derks, Frank [mailto:F.Derks@PBC.BE.PHILIPS.COM] > > Sent: 22 March 1999 10:43 > > To: ITU-SG16(a)MAILBAG.INTEL.COM > > 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(a)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(a)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(a)ICN.SIEMENS.DE> > > > To: ITU-SG16(a)MAILBAG.INTEL.COM <ITU-SG16(a)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(a)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(a)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(a)omnitor.se > > > >> Tel +46 751 100 501 > > > >> fax +46 8 556 002 06 > >

1 0

AW: AW: AW: Call hold and transfer in H.323 AnnexF. Too limited??
by Klaghofer Karl ICN IB NL IP 7 23 Mar '99

23 Mar '99

Paul, Agreed. Karl > -----Ursprüngliche Nachricht----- > Von: Paul E. Jones [SMTP:paul.jones@ties.itu.int] > Gesendet am: Montag, 22. März 1999 18:42 > An: Klaghofer Karl ICN IB NL IP 7; ITU-SG16(a)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(a)ICN.SIEMENS.DE> > To: ITU-SG16(a)MAILBAG.INTEL.COM <ITU-SG16(a)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@TIES.ITU.INT] > >> Gesendet am: Donnerstag, 18. März 1999 18:57 > >> An: ITU-SG16(a)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(a)ICN.SIEMENS.DE> > >> To: ITU-SG16(a)MAILBAG.INTEL.COM <ITU-SG16(a)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(a)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(a)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(a)omnitor.se > >> >> Tel +46 751 100 501 > >> >> fax +46 8 556 002 06

1 0

Re: AW: Call hold and transfer in H.323 AnnexF. Too limited??
by Prasad Kallur 22 Mar '99

22 Mar '99

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(a)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(a)PBC.BE.PHILIPS.COM> To: ITU-SG16(a)MAILBAG.INTEL.COM <ITU-SG16(a)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(a)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(a)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(a)ICN.SIEMENS.DE> >> To: ITU-SG16(a)MAILBAG.INTEL.COM <ITU-SG16(a)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(a)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(a)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(a)omnitor.se >> >> Tel +46 751 100 501 >> >> fax +46 8 556 002 06

2 1

Re: AW: Call hold and transfer in H.323 AnnexF. Too limited??
by Paul E. Jones 22 Mar '99

22 Mar '99

Prasad, While I agree that it would be ideal to have the telephony equipment upgraded, I claim that it would be a nearly impossible task. First of all, you may have one of 1000 telephones on the market-- what firmware revision would you need and for your brand and model? How do we upgrade it? Send somebody to your house, mail it in, or "flash" the box over the Internet (keep in mind that many of these devices may not be connected to the Internet)? Who should perform the upgrade-- the manufacturer of the phone or the telephony service provider? Preferably, the phone would be updated by the manufacturer. That will most likely preclude one from taking advantage of particular special ("non-standard") services offered by a service provider-- the manufacturer's supplementary service support may or may not match your service provider's offerings. Most importantly, service providers will want to roll out new services that 1) do not require going through the ITU standardization process and 2) are rolled out more quickly than the ITU standardization process. To accomplish that, we need a generic service mechanism that does not live in the endpoint, but rather lives in the service provider's equipment. As Chris Purvis pointed out, the limitations with call forwarding as prescribed in H.450.3 demonstrate the need to have some services performed by the service provider's equipment. Paul -----Original Message----- From: Prasad Kallur <prasad(a)TRILLIUM.COM> To: ITU-SG16(a)MAILBAG.INTEL.COM <ITU-SG16(a)MAILBAG.INTEL.COM> Date: Monday, March 22, 1999 3:30 PM Subject: 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(a)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(a)PBC.BE.PHILIPS.COM> >To: ITU-SG16(a)MAILBAG.INTEL.COM <ITU-SG16(a)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(a)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(a)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(a)ICN.SIEMENS.DE> >>> To: ITU-SG16(a)MAILBAG.INTEL.COM <ITU-SG16(a)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(a)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(a)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(a)omnitor.se >>> >> Tel +46 751 100 501 >>> >> fax +46 8 556 002 06

1 0

Re: basic ASN.1 coding question
by Paul Long 22 Mar '99

22 Mar '99

Henri, To answer you question and to add to what Frank said, there is no semantic difference. The extension marker is just a syntactic mechanism for augmenting an ASN.1 tree. Paul Long Smith Micro Software, Inc. -----Original Message----- From: henri.maenpaa(a)NOKIA.COM [SMTP:henri.maenpaa@NOKIA.COM] Sent: Monday, March 22, 1999 1:49 AM To: ITU-SG16(a)MAILBAG.INTEL.COM Subject: basic ASN.1 coding question Hi everyone, I have a pretty basic/specific question about ASN.1 coding: what's the semantic difference if a particular information element is located above/below the "three dots"-line in an ASN.1 structure? -Henri Mäenpää

1 0

Re: AW: Call hold and transfer in H.323 AnnexF. Too limited??
by Paul E. Jones 22 Mar '99

22 Mar '99

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(a)PBC.BE.PHILIPS.COM> To: ITU-SG16(a)MAILBAG.INTEL.COM <ITU-SG16(a)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(a)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(a)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(a)ICN.SIEMENS.DE> >> To: ITU-SG16(a)MAILBAG.INTEL.COM <ITU-SG16(a)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(a)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(a)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(a)omnitor.se >> >> Tel +46 751 100 501 >> >> fax +46 8 556 002 06

1 0

Re: AW: AW: Call hold and transfer in H.323 AnnexF. Too limited??
by Paul E. Jones 22 Mar '99

22 Mar '99

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(a)ICN.SIEMENS.DE> To: ITU-SG16(a)MAILBAG.INTEL.COM <ITU-SG16(a)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@TIES.ITU.INT] >> Gesendet am: Donnerstag, 18. März 1999 18:57 >> An: ITU-SG16(a)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(a)ICN.SIEMENS.DE> >> To: ITU-SG16(a)MAILBAG.INTEL.COM <ITU-SG16(a)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(a)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(a)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(a)omnitor.se >> >> Tel +46 751 100 501 >> >> fax +46 8 556 002 06

1 0

Status of Annex G??
by William Pimentel 22 Mar '99

22 Mar '99

Hello all. I would like to know what's the actual status of Annex G (communication between administrative domains). Where can I get a copy of it?. I need it for my thesis. Thank you. -- William Pimentel w-piment(a)uniandes.edu.co

1 0

Re: basic ASN.1 coding question
by Derks, Frank 22 Mar '99

22 Mar '99

Hi Henri, the "three dots" that you are referring to are specified in X.681 Amendment 1: "Rules of extensibility". The dots are called an "extension marker" and they are used (in the case of the H.323 series) to demarcate the parts of the ASN.1 elements that were added for a particular version of the specification. So below a marker you will find newer additions to the specification. 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: henri.maenpaa(a)NOKIA.COM [mailto:henri.maenpaa@NOKIA.COM] > Sent: 22 March 1999 10:49 > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: basic ASN.1 coding question > > Hi everyone, > > I have a pretty basic/specific question about ASN.1 coding: > what's the semantic difference if a particular information element is > located above/below the "three dots"-line in an ASN.1 structure? > > -Henri Mäenpää

1 0

Call Forward too!... RE: AW: Call hold and transfer in H.323 Anne xF. Too limited??
by Chris Purvis 22 Mar '99

22 Mar '99

Frank, Karl, Anyone else who's interested, A limitation in H.450.3 (Call Forward) recently became clear to me, and the solution may arrive through the sorts of things Frank's suggesting. Background: What I see as a problem arises from the endpoint-centric nature of CFU (Call Forward Unconditional), especially in the case where the endpoint being forwarded is PC-based (probably NOT a SET). The specific problem: I would regard as a prime use for CFU to be the ability to set up forwarding and then switch off my PC, so that all my calls would then go (for example) to a colleague. Everything seems to be there in H.450.3 to allow this to happen in the gatekeeper-routed model (obviously the GK-routed model is likely to be required, because the GK appears to be the only "live" entity that can do the forwarding), with the exception of the transaction between my PC and its gatekeeper. The solution: I don't know. Maybe an H.450.3 extension (which has dangers because a GK is not normally a callable entity), maybe a new RAS transaction type (but we don't want proliferation of RAS messages)? The plea: I'd like to see some serious suggestions on this, and really drive some solution towards standardisation, either as an Annex to H.450.3 or elsewhere. It seems to me that this is possibly the most important application of Call Forwarding, so it seems a shame that it is missing. If consensus works towards a RAS-based solution, we may be able to do this in a way that will also suit Frank's ideas? Regards, Chris > -----Original Message----- > From: Derks, Frank [mailto:F.Derks@PBC.BE.PHILIPS.COM] > Sent: 22 March 1999 10:43 > To: ITU-SG16(a)MAILBAG.INTEL.COM > 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(a)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(a)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(a)ICN.SIEMENS.DE> > > To: ITU-SG16(a)MAILBAG.INTEL.COM <ITU-SG16(a)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(a)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(a)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(a)omnitor.se > > >> Tel +46 751 100 501 > > >> fax +46 8 556 002 06 >

1 0