March 1999 - sg16-avd - lists.packetizer.com

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

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

22 Mar '99

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

basic ASN.1 coding question
by henri.maenpaa＠NOKIA.COM 22 Mar '99

22 Mar '99

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: H.GCP Audio Call postponed
by Scott Bradner 19 Mar '99

19 Mar '99

Rex mentions: > the upper level people > in the IETF and ITU will have no choice but to support us. I would not have put it quite that way - since its not a quiestion of force here > I believe they want one solution too. I, and everyone from the ITU that I've talked to, would like one solution Scott

1 0

H.GCP Call Tuesday 3/23
by Bryan Hill 19 Mar '99

19 Mar '99

Colleagues, I have scheduled an H.GCP audio call for Tuesday March 23rd at 10 AM EST for two hours. The call-in details are listed below. Calls from outside the US: 773 756-4715 Call from within the US: 888 847-9708 Passcode: Brian The first agenda item will be to discuss the progress made on the connection model since our last H.GCP audio call. For those who may not have kept up with the events that transpired at the IETF in Minneapolis, a new connection model has been agreed to by a core group of interested parties that included the authors of MGCP and MDCP. This was reached after review of the work Rex Coldren, Hong Liu and Fernando Cuervo took on during our last H.GCP call and it included the document Nancy Green and others submitted for IETF meeting in Minneapolis that compared MGCP and MDCP. This is an exciting development and text that describes this work will soon be available for review on the IETF and ITU reflectors. I have attached a brief slide presentation that was presented during the Megaco meeting in Minneapolis. Nancy Green has kindly volunteered to present this material on Tuesday. The remainder of the call will be used to address how the control model, commands, resources and message acknowledgement strategies for H.GCP protocol. These are topics that various individuals agreed to research during the last call. In closing we will discuss additional items to work on in preparation for the next H.GCP call. I will proposed the next call be held a week later, on March 30th, as time is growing short to reach consensus on H.GCP. Regards, Bryan

1 0

Re: TCP or RTP for text conversation in H.323
by Scott Bradner 19 Mar '99

19 Mar '99

note that any transport protocol will need to be able to react to congestion in the network - a good reason to use TCP where one can Scott From: Gunnar Hellstrom <gunnar.hellstrom(a)OMNITOR.SE> Subject: TCP or RTP for text conversation in H.323 I have one furter area of discussion: When selecting the transport protocol for the text conversation, the current draft (APC 1504) specifies TCP or UDP. It would be good to be able to specify only one of them. 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 dropped or destroyed text in the text stream for T.140 to display. If we have less than 3 % dropped frames, and these occations are clearly marked, I think the users could accept it. Questions 1. Do you agree that there are situations when TCP should be avoided, and a UDP based protocol preferred? (H.332, conferencing, connecting through many chained networks, connections including sattellite links...) 2. Do you agree that RTP is a good alternative, with a thin transport protocol for error indications to the user? 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? Gunnar ------------------------------------------------ Gunnar Hellström Omnitor AB Alsnögatan 7, 4tr S-116 41 Stockholm SWEDEN Tel +46 751 100 501 Fax +46 8 556 002 06 E-mail: gunnar.hellstrom(a)omnitor.se WWW: www.omnitor.se ------------------------------------------------

1 0

Add to mailing list
by Robert Abrams 18 Mar '99

18 Mar '99

Please add me to the email reflector for SG-16. Robert Abrams abramsrj(a)lucent.com

1 0