- sg16-avd - lists.packetizer.com

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

TCP or RTP for text conversation in H.323
by Gunnar Hellstrom 18 Mar '99

18 Mar '99

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

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

18 Mar '99

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. 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

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

18 Mar '99

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: H.GCP Audio Call postponed
by Nancy-M Greene 17 Mar '99

17 Mar '99

As some of you know, at the IETF meeting in Minneapolis this week, a group of us have reached agreement on a proposal for new connection model for the device control protocol. We have been fortunate to have had, here in Minneapolis, almost all the authors of existing internet-draft and ITU contributions that address device control between a media gateway controller and a media gateway (draft-huitema-megaco-mgcp-v0r1-05.txt, draft-sijben-megaco-mdcp-01.txt, and draft-cuervo-megaco-mgcp-compromise-00.txt). Bryan Hill and Glen Freundlich were also here for part of the time. The slides attached will give you a flavour for the work we are currently documenting in a new internet-draft. We have presented the new connection model to the megaco WG, and will be sending out the new internet-draft to the megaco WG by the end of next week for comments. I hope to be able to present this work at the next H.gcp conference call. I think we have made a huge step forward by coming to an agreement on the connection model, and am looking forward to having input from other SG16 members on the work we have begun. Nancy -------------------------------------------------------------------------- Nancy M. Greene Internet & Service Provider Networks, Nortel Networks T:514-271-7221 (internal:ESN853-1077) E:ngreene@nortelnetworks.com <<Megaco-forSG16confcall.zip>> > ---------- > From: Santo Wiryaman[SMTP:swiryaman@VIDEOSERVER.COM] > Sent: Wednesday, March 17, 1999 11:27 AM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: H.GCP Audio Call postponed > > Collegues, > > Bryan Hill is out-of-the office this week. He would like to postpone the > audio call that was tentatively scheduled for Thursday to a later date. > Please stay tuned. Thank you. > > Regards, > Santo Wiryaman > VideoServer Inc. > (781) 505-2159 > swiryaman(a)videoserver.com > > > > -----Original Message----- > > From: Bryan Hill [SMTP:bhill@VIDEOSERVER.COM] > > Sent: Friday, March 05, 1999 11:38 AM > > To: ITU-SG16(a)mailbag.cps.intel.com > > Subject: H.GCP Audio Call minutes > > > > Colleagues, > > > > The H.GCP audio call was held Thursday March 4th , 18 ports called in > > including a group from the TIPHON meeting. Companies represented were > > ATT, > > Lucent, ACGS, RadVision, Cisco, Nortel, Delta Information Systems, > > NetSpeak, > > Bellcore and others. . . > > The meeting opened by reviewing a proposed working model and fleshing > out > > the work items that need to be addressed. A number of individuals > > committed to fleshing some of the work items prior to the next call, I > > would > > like to thank these individuals in advance. There was some news from > > TIPHON > > regarding changes to the reference model and some adjustments to the > > requirements they have contributed to H.GCP. These changes will be > > reflected once TDs from the Philadelphia meeting are released. The last > > hour or so was focussed on reviewing the H.GCP requirements I sent > around > > prior to the meeting. > > The next call is tentatively planned for Thursday March 18 at 10AM EST. > > > > The working model > > Individuals will be working up submissions to be reviewed by the entire > > group at the next audio call. The objective is that the principals > > involved > > will collaborate off line initially, post the results to the SG16 > > reflector > > for comments and a final version will be posted for discussion in an > audio > > call. The result of that final review will be added into the H.GCP by > > the > > editor. Every effort will be made to resolve issues in this forum but > if > > issues remain they will be logged and discussed in Santiago > > > > Work items > > T > > > > > > he following work items were identified and individuals who expressed an > > interest in working on them are noted. > > Control Model Tom Taylor > > Connection Model Rex Coldren, Hong Liu, Nortel rep > > Command related issues Chip Sharp > > Resource Management Paul Sijben > > > > Other work items > > Messages (i.e.-command packaging) > > Message Encoding > > Scripting/Packages > > Interface C protocol (Q.931/Q.764) > > Interface B protocol (Q.931 ) > > > > > > > > -----Original Message----- > > From: Bryan Hill [SMTP:bhill@VIDEOSERVER.COM] > > Sent: Monday, March 01, 1999 2:37 PM > > To: ITU-SG16(a)mailbag.cps.intel.com > > Subject: H.GCP Audio Call > > > > Colleagues, > > > > I would like to invite you to participate in audio call on > > Thursday > > March > > 4th from 11AM until 1PM EST to discuss H.GCP. The call details > > are > > as > > follows: > > > > Calls from outside the US: 312-470-7273 > > Calls from within the US: 888-847-7598 > > Passcode: BryanHill > > Confirmation number: 5193957 > > > > Please respond to me directly to reserve a port for this call > > (where > > ever > > possible please try to minimize port requirements by sharing a > > port > > with a > > colleague). > > > > The main purpose of this initial call will be to review > > requirements > > and > > terminology for H.GCP which were discussed in Monterey. I have > > been > > editing > > these sections and will make them available on the ptel SG16 ftp > > site no > > later than tomorrow 3/2. The second purpose of the call is to > > identify > > other areas that need to be discussed in subsequent audio calls. > > An > > initial > > pass of topics is listed below. I would like to solicit > > volunteers > > to > > submit written contribution in each of the areas identified and > > use > > these > > submissions as a basis for discussing topics in future audio > > calls. > > In this > > manner I hope to scope our discussion to specific technical > topics > > and > > combine the benefits from MDCP and MGCP approaches into H.GCP. > > > > > > 1) Control model > > a) Controller to gateway associations > > b) Controller to internal gateway entity > associations > > c) Failover > > d) Security > > 2) Connection model > > a) Controllable entities > > b) Controllable entity properties > > 3) Commands > > a) Types > > b) Parameters > > c) Acknowledgement styles/sequencing > > 4) Messages (i.e.-command packaging) > > 5) Message Encoding > > 6) Resource management > > 7) Scripting/Packages > > 8) Interface C protocol (Q.931/Q.764) > > 9) Interface B protocol (Q.931 ) > > > > > > Best Regards, > > Bryan > > _________________________________________________________ > > Bryan Hill > > VideoServer Inc. > > (781) 505-2159 > > <mailto:bhill@videoserver.com> >

2 1

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

17 Mar '99

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

H.GCP Audio Call postponed
by Santo Wiryaman 17 Mar '99

17 Mar '99

Collegues, Bryan Hill is out-of-the office this week. He would like to postpone the audio call that was tentatively scheduled for Thursday to a later date. Please stay tuned. Thank you. Regards, Santo Wiryaman VideoServer Inc. (781) 505-2159 swiryaman(a)videoserver.com > -----Original Message----- > From: Bryan Hill [SMTP:bhill@VIDEOSERVER.COM] > Sent: Friday, March 05, 1999 11:38 AM > To: ITU-SG16(a)mailbag.cps.intel.com > Subject: H.GCP Audio Call minutes > > Colleagues, > > The H.GCP audio call was held Thursday March 4th , 18 ports called in > including a group from the TIPHON meeting. Companies represented were > ATT, > Lucent, ACGS, RadVision, Cisco, Nortel, Delta Information Systems, > NetSpeak, > Bellcore and others. . . > The meeting opened by reviewing a proposed working model and fleshing out > the work items that need to be addressed. A number of individuals > committed to fleshing some of the work items prior to the next call, I > would > like to thank these individuals in advance. There was some news from > TIPHON > regarding changes to the reference model and some adjustments to the > requirements they have contributed to H.GCP. These changes will be > reflected once TDs from the Philadelphia meeting are released. The last > hour or so was focussed on reviewing the H.GCP requirements I sent around > prior to the meeting. > The next call is tentatively planned for Thursday March 18 at 10AM EST. > > The working model > Individuals will be working up submissions to be reviewed by the entire > group at the next audio call. The objective is that the principals > involved > will collaborate off line initially, post the results to the SG16 > reflector > for comments and a final version will be posted for discussion in an audio > call. The result of that final review will be added into the H.GCP by > the > editor. Every effort will be made to resolve issues in this forum but if > issues remain they will be logged and discussed in Santiago > > Work items > T > > > he following work items were identified and individuals who expressed an > interest in working on them are noted. > Control Model Tom Taylor > Connection Model Rex Coldren, Hong Liu, Nortel rep > Command related issues Chip Sharp > Resource Management Paul Sijben > > Other work items > Messages (i.e.-command packaging) > Message Encoding > Scripting/Packages > Interface C protocol (Q.931/Q.764) > Interface B protocol (Q.931 ) > > > > -----Original Message----- > From: Bryan Hill [SMTP:bhill@VIDEOSERVER.COM] > Sent: Monday, March 01, 1999 2:37 PM > To: ITU-SG16(a)mailbag.cps.intel.com > Subject: H.GCP Audio Call > > Colleagues, > > I would like to invite you to participate in audio call on > Thursday > March > 4th from 11AM until 1PM EST to discuss H.GCP. The call details > are > as > follows: > > Calls from outside the US: 312-470-7273 > Calls from within the US: 888-847-7598 > Passcode: BryanHill > Confirmation number: 5193957 > > Please respond to me directly to reserve a port for this call > (where > ever > possible please try to minimize port requirements by sharing a > port > with a > colleague). > > The main purpose of this initial call will be to review > requirements > and > terminology for H.GCP which were discussed in Monterey. I have > been > editing > these sections and will make them available on the ptel SG16 ftp > site no > later than tomorrow 3/2. The second purpose of the call is to > identify > other areas that need to be discussed in subsequent audio calls. > An > initial > pass of topics is listed below. I would like to solicit > volunteers > to > submit written contribution in each of the areas identified and > use > these > submissions as a basis for discussing topics in future audio > calls. > In this > manner I hope to scope our discussion to specific technical topics > and > combine the benefits from MDCP and MGCP approaches into H.GCP. > > > 1) Control model > a) Controller to gateway associations > b) Controller to internal gateway entity associations > c) Failover > d) Security > 2) Connection model > a) Controllable entities > b) Controllable entity properties > 3) Commands > a) Types > b) Parameters > c) Acknowledgement styles/sequencing > 4) Messages (i.e.-command packaging) > 5) Message Encoding > 6) Resource management > 7) Scripting/Packages > 8) Interface C protocol (Q.931/Q.764) > 9) Interface B protocol (Q.931 ) > > > Best Regards, > Bryan > _________________________________________________________ > Bryan Hill > VideoServer Inc. > (781) 505-2159 > <mailto:bhill@videoserver.com>

1 0

Re: Handling of channel failures (H.323v2 clause 8.6)
by Chris Purvis 17 Mar '99

17 Mar '99

Karl, The paragraph to which you refer seems to me to say "the endpoint may choose to terminate the call as described in Phase E, or it may attempt to re-establish the Call Signalling Channel as described above.". This is a lot more explicit than "the procedures described above shall be used" - it says, in fact that an endpoint may follow either of the courses of action you describe. A gatekeeper, however, would appear to be obliged to do the first: I wonder how many do! Regards, Chris > -----Original Message----- > From: Klaghofer Karl ICN IB NL IP 7 > [mailto:Karl.Klaghofer@ICN.SIEMENS.DE] > Sent: 16 March 1999 6:25 > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: Handling of channel failures (H.323v2 clause 8.6) > > > > H.225.0 channel failure: > > Section 8.6 of H323 V2 second para states that in the case > of a protocol > > failure of the > > H225 channel it is possible for an endpoint to attempt to > reestablish the > > H225 channel and continue the call. > > > > H.245 channel failure: > > At the end of section 8.6 (second last para) it states that > > in the case of a failure of the H245 channel the > "procedures described > > above" shall be used. Which procedures are referred here ? > > > > a) the procedures described for the signalling channel > failure case in the > > second para, allowing a channel re-establishment. This > would mean that in > > case of a H.245 channel failure the H.245 channel may be > re-established. > > If re-establishment is successful, the call may continue. Only if > > re-establishment fails, the call would have to be > terminated according to > > what is sayd in para 1. > > > > b) the procedures described for H.245 channel failure in the first > > paragraph; which would mean that the call would have to be > terminated. No > > H.245 channel re-establishment attempt is allowed. > > > > Thanks, > > 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 > > >

1 0

question about MCU cascade
by pjh 16 Mar '99

16 Mar '99

Dear All I'd like to ask about MCU cascading. for example, if MCU A is calling MCU B with conference goal(create) and MCU A becomes an active MC according to the master/slave procedures, which MCU is the masterMCU? I think active MC(MCU A) should become the master MC. but according to 8.4.5 of H.323, inactive MC(MCU B) becomes the master MC. Please , Let me know why. Best Regards Jihye Park(Miss) Nada Research Co., Ltd. Seoul 137-070 , Korea Tel: 82-2-525-3941 Fax: 82-2-525-3945 pjh(a)deskview.nada.co.kr <mailto:pjh@deskview.nada.co.kr> < mailto:pjh@deskview.nada.co.kr <mailto:pjh@deskview.nada.co.kr> >

1 0

Call hold and transfer in H.323 AnnexF. Too limited??
by Gunnar Hellstrom 16 Mar '99

16 Mar '99

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

Handling of channel failures (H.323v2 clause 8.6)
by Klaghofer Karl ICN IB NL IP 7 16 Mar '99

16 Mar '99

> H.225.0 channel failure: > Section 8.6 of H323 V2 second para states that in the case of a protocol > failure of the > H225 channel it is possible for an endpoint to attempt to reestablish the > H225 channel and continue the call. > > H.245 channel failure: > At the end of section 8.6 (second last para) it states that > in the case of a failure of the H245 channel the "procedures described > above" shall be used. Which procedures are referred here ? > > a) the procedures described for the signalling channel failure case in the > second para, allowing a channel re-establishment. This would mean that in > case of a H.245 channel failure the H.245 channel may be re-established. > If re-establishment is successful, the call may continue. Only if > re-establishment fails, the call would have to be terminated according to > what is sayd in para 1. > > b) the procedures described for H.245 channel failure in the first > paragraph; which would mean that the call would have to be terminated. No > H.245 channel re-establishment attempt is allowed. > > Thanks, > 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 >

1 0

Mailing List
by Simon Brewer 11 Mar '99

11 Mar '99

Dear Sir, could you please send me a list of mailing list resources, and how i may subscribe, Best Regards, Simon Brewer -- Simon Brewer Signal Processing Associates P/L Ph +61 3 9800 2000 3/97 Lewis Rd, Wantirna, 3152 Fx +61 3 9800 2111 Australia. simon(a)spa.com.au This communication is proprietary and confidential.

1 0

Fast Start
by Francois Audet 11 Mar '99

11 Mar '99

Hi, Question on fastStart. When presenting different alternatives in the OpenLogicalChannel, the sessionID is the same for all, in order to distinguish between alternatives for the same session, instead of a proposal to open multiple media channels. Is the same valid for the RTP/RTCP port numbers, and the logical channel numbers? Do they have to be the same for alternative proposals, or can they be different? Any views? ----- François Audet Tel:+1 408 565 5675 mailto:audet@NortelNetworks.com Nortel Networks Fax:+1 408 565 2375 http://www.NortelNetworks.com

2 1

Re: FW: Where H.245 goes - MG or MGC (Skran's comments)
by Ami Amir 11 Mar '99

11 Mar '99

Hi Well - it seems we are getting pretty religious about this issue. My take: For a simple toll by-pass application - it makes sense to route H.245 to the MGC. The MG is "dumb" - all decisions are centralized - and life is simple :) However, if we believe that the real future of VoIP is in adding functionality and services, that there will be instances when H.323 end points also are involved, and multimedia is important, a case can be made for that the MG should support H.245. I believe that in reaching a sensible conclusion we should also look at enterprise connections that utilize Q.931 or Q.SIG for signaling. My question - can't we allow for both? Ami -----Original Message----- From: Flemming Andreasen [SMTP:fandreas@telcordia.com] Sent: Wednesday, March 10, 1999 4:58 PM To: ITU-SG16(a)mailbag.cps.intel.com Subject: Re: FW: Where H.245 goes - MG or MGC (Skran's comments) I will agree with that. Let's not forget that we are addressing "decomposed gateways". As Dave pointed, out GW = MGC + MG + SG so there's no argument there. Also, the idea with the decompostion is precisely that; to decompose the GW into its logical components that each address different aspects of the combined GW. The MGC is the one with the intelligence/control/complexity, or whatever we want to call it, and as Brian pointed out earlier the bearer part is in the MG. Thus Dave's arguments still stand, and H.245 should be in the MGC, not the MG. Regards Flemming Andreasen "David R. Oran" <oran(a)cisco.com> on 03/10/99 09:33:05 AM To: "Taylor, Tom-PT [SKY:B318-I:EXCH]" <taylor(a)americasm01.nt.com>, "Mailing list for parties associated with ITU-T Study Group 16" <ITU-SG16(a)mailbag.cps.intel.com> cc: megaco(a)BayNetworks.COM (bcc: Flemming Andreasen/Bellcore) Subject: RE: FW: Where H.245 goes - MG or MGC (Skran's comments) Dale's arguments are impeccable if one believes that MGCs are gatekeepers, which they're not. MGCs and MGs are a single H.323 endpoint, ripped apart and put in different boxes. The Megaco protocol glues the boxes together. If you put all of H.323 in the MG then you have no need of an MGC in the first place. QED. I don't think anyone proposes declaring that monolithic H.323 endpoints (i.e. MGC+MG+SG) must be split up. Heavens, many of us sell hundreds of these every day and they work just fine, thank you. So, I think I agree with Tom that this response is interesting but not terribly relevant to the engineering tradeoffs in marrying Megaco to H.323. > -----Original Message----- > From: owner-megaco(a)BayNetworks.COM > [mailto:owner-megaco@BayNetworks.COM]On Behalf Of Taylor, Tom-PT > [SKY:B318-I:EXCH] > Sent: Wednesday, March 10, 1999 8:54 AM > To: Mailing list for parties associated with ITU-T Study Group 16 > Cc: megaco(a)BayNetworks.COM > Subject: RE: FW: Where H.245 goes - MG or MGC (Skran's comments) > > > I'll forward this to the Megaco list. One point, though. > Just because call > signalling is in the MGC doesn't mean we have a GK-routed > model: the MGC is > part of the Gateway in the SG 16 architecture and TIPHON's. (Its > relationship to the H.323 architecture is unstated in Megaco, > except that we > cite the TIPHON architecture as an example.) > > > > -----Original Message----- > > From: Dale L. Skran [SMTP:dskran@ASCEND.COM] > > Sent: Tuesday, March 09, 1999 12:22 PM > > To: ITU-SG16(a)MAILBAG.INTEL.COM > > Subject: Re: FW: Where H.245 goes - MG or MGC (Skran's comments) > > > > See detailed comments below. > > > > Dale Skran > > Q13 rapporteur > > > > At 12:07 PM 3/8/99 -0600, Tom-PT Taylor wrote: > > >> -----Original Message----- > > >> From: David R. Oran [SMTP:oran@cisco.com] > > >> Sent: Monday, March 08, 1999 10:25 AM > > >> To: megaco > > >> Subject: Where H.245 goes - MG or MGC > > >> > > >> Here are some random thoughts on one of the questions of marrying > > Megaco > > >> with H.323 - where H.245 goes. Some prior messages have > indicated that > > >> there are tradeoffs involved here, and I agree. Some > food for thought: > > >> > > >> - If we terminate H.245 on the MG, this blows away V2 > fast start, and > > >> looking at likely call flows may introduce 1/2 RTT extra over a > > monolothic > > >> H.323 gateway. > > > > If GW A sends a setup with an OLC to GW B, > > H.225.0 and H.245 both go between the GWs and fast start > works fine. The > > penalty of not using fast start only occurs if you want the > call signaling > > going > > to the controller and the H.245 to the GWs. > > > > In any case, the key word here is OPTIONAL. All three > alternatives need to > > be > > supported, not just the imposition of the GK-routed call > model on all > > vendors and > > customers. > > > > a)full GK-routed > > b)GK routed signaling; H.245 between GWs > > c)direct call model with H.323 RAS in MGC and H.225.0/H.245 > > between GWs > > > > >> > > >> - The MGC may wish to participate in CAPs exchange for > policy reasons. > > > > Of course, and this should be the MGC's choice to force the > GK-routed call > > model > > just as is currently the case. > > > > >> > > >> - The H.245 open logical channel operation is analogous > to doing VC > > >> establishment on the MG in the ATM case, and for > parallelism might be > > best > > >> done MG-MG. It is also where certain resource allocation > operations get > > > > This is part of the case for doing H.245 between GWs rather > than through > > the > > controller. > > > > >> done and hence synchronizes well with the H.323 model of error > > reporting. > > >> Unfortunately, putting CAPs excahnge in one association > and logical > > >> channel control in a different association would be a > pretty major > > tweak > > >> to H.323. > > > > There is a mental leap here that is not clear; why would > this be done? > > > > >> > > >> - Putting H.245 completely on the MG factors the problem > of translating > > >> among different media description syntaxes (e.g. > H245/ASN1 vs SDP) - > > the > > >> MGC-MG protocol then might not need to have a full-blown media > > description > > >> in it when using H.323 for global signaling. > > > > Indeed, another good reason for H.245 between the GWs. > > > > >> > > >> - Putting H.245 on the MG gives the MG a lot of autonomy. This is > > arguably > > >> more autonomy than the Megaco model should assign to the MG. > > > > Different strokes for different folks. Different customers > will take each > > approach. > > > > >> > > >> - Splitting up H.323 with H.225 signaling in one place and H.245 > > signaling > > >> in another place may uncover some state coordination > issues which would > > >> (unneccesarily?) complicate the MGC-MG protocol and > possibly introduce > > >> direct H.323 dependencies. > > > > Certainly this is possible, although there are vendors who > do this right > > now > > (how about a posting?). It is difficult to not have H.323 > dependencies in > > a > > protocol to decompose an H.323 GW. > > > > >> > > >> My intuition says that the tradeoffs favor keeping H.245 > in the MGC. > > What > > >> do others think? > > > > The arguements presented here indicate the opposite; that > H.245 should > > optionally > > go between the GWs, as well as H.225.0 call signaling. > > > > Beware the black/white view. Different customers will use > the products in > > different > > ways. > > > > > > > >

4 3

Re: Handling of nonreceipt of IRRs by gatekeeper
by rtgupta＠HSS.HNS.COM 11 Mar '99

11 Mar '99

Hi, Specifications have not included all the glare and error conditions. So I assume in these cases, decision making is at gatekeeper's discretion. Even in 'IRR not received' case, it is at gatekeeper's disposal how to deal with it. But in my opinion, best solution is 3rd one as suggested by you. If gatekeeper does not receive IRR from an endpoint within irrFrequency period, it should send IRQ. Gatekeeper should try atleast twice. In case no response is received, gatekeeper should clear the call. Thanks, Ritu. srini(a)trillium.com (Srinivasa Beereddy) on 03/11/99 05:54:10 AM Please respond to srini(a)trillium.com (Srinivasa Beereddy) To: h323implementors(a)imtc.org, ITU-SG16(a)mailbag.cps.intel.com cc: Subject: Handling of nonreceipt of IRRs by gatekeeper Handling of nonreceipt of IRRs by gatekeeper. If irrFrequency is specified in ACF message and the endpoint doesnot respond with an IRR in the specified interval, what should the GK do? (H2250V2 Section 7.11.2 says endpoint shall send IRRs if the irrFrequency is specified, but doesn't say about nonreceipt of IRRs) Following are the list of possible actions by GK, and I would like hear your opinion. 1. Just ignore 2. Clear the call by sending DRQ 3. Send a IRQ and release the call if no response. thanks, Srini Trillium Digital Systems, Inc. ------------------------------------------------------------------------- for list subscription instructions, send email to h323implementors-request(a)imtc.org with text "info"

1 0

Date of SG16 meeting in February 2000 has been fixed
by Sakae OKUBO 10 Mar '99

10 Mar '99

Dear Q12-14/16 experts, Mr. Tosco has advised Rapporteurs of the subject matter as follows: 7 to 18 February 2000 inclusive, at ITU premises in Geneva Please note that this is the final meeting of the current study period 1997 - 2000. I will update the Monterey meeting report accordingly. Best regards, Sakae OKUBO (Mr.) *********************************************************** Waseda Research Center Telecommunications Advancement Organization of Japan (TAO) 5th Floor, Nishi-Waseda Bldg. 1-21-1 Nishi-Waseda, Shinjuku-ku, Tokyo 169-0051 Japan Tel: +81 3 5286 3830 Fax: +81 3 5287 7287 e-mail: okubo(a)giti.or.jp ***********************************************************

1 0

Handling of nonreceipt of IRRs by gatekeeper
by Srinivasa Beereddy 10 Mar '99

10 Mar '99

Handling of nonreceipt of IRRs by gatekeeper. If irrFrequency is specified in ACF message and the endpoint doesnot respond with an IRR in the specified interval, what should the GK do? (H2250V2 Section 7.11.2 says endpoint shall send IRRs if the irrFrequency is specified, but doesn't say about nonreceipt of IRRs) Following are the list of possible actions by GK, and I would like hear your opinion. 1. Just ignore 2. Clear the call by sending DRQ 3. Send a IRQ and release the call if no response. thanks, Srini Trillium Digital Systems, Inc.

1 0

Re: FW: Where H.245 goes - MG or MGC (Skran's comments)
by Tom-PT Taylor 10 Mar '99

10 Mar '99

I think this sums things up. There was absolutely no intention that we mandate that H.245 be co-located with the MG. The only question was whether we would even consider it as an option. I think the answer is yes, but SG 16 has some issues to work out before it becomes a real priority for Megaco. These relate to definition of SG 16's interfaces B (occurs if H.225.0 call signalling is co-located with the MG) and E (occurs if H.245 is co-located with the MG). These interfaces are additional to the device control interface A, but will share the transport and do need to be coordinated with it. It is not our job to define what goes across those interfaces; the content will be tightly coupled to H.323. Until the definition of the messaging across those interfaces is well-begun, I'd say our main concern is what I stated in the first place: to make sure that our protocol is modular enough that parts of it can be left unused if the MG is designed to respond autonomously to H.245 messaging. The second possible requirement is to think about how to coordinate device control messaging with other messaging happening between the same boxes (e.g. back-hauled SCN signalling). Beyond that, I can't see any need to add anything to our protocol to support this option beyond the ability to negotiate its use. > -----Original Message----- > From: Christian Huitema [SMTP:huitema@research.telcordia.com] > Sent: Wednesday, March 10, 1999 12:42 PM > To: Rex Coldren; David R. Oran > Cc: Taylor, Tom-PT [SKY:B318-I:EXCH]; Mailing list for parties > associated with ITU-T Study Group 16; megaco(a)BayNetworks.COM > Subject: Re: FW: Where H.245 goes - MG or MGC (Skran's comments) > > On Mar 10, 8:57am, Rex Coldren wrote: > > Subject: Re: FW: Where H.245 goes - MG or MGC (Skran's comments) > > Just to get this argument back on track... > > > > Are we going to allow for the option of H.245 channels being opened > > on the MG? > > Hey, we are not the protocol police... The answer to your "are we going to > allow" is an unquivocal yes. You could in fact easily extend even our > simplest MG-MGC protocol (SGCP) to support H.245 in the gateway, for > example by declaring an "m=h245" media type in SDP. As Dave pointed out, > it would be difficult then to support the fast start option, but this > would definitely result in H.245 in the MG. It would also become very > difficult for the MGC to keep track of the resources used by the MG. > > The real question is whether the base protocol defined by Megaco should > mandate autonoumous support of H.245 in each and every MG. I think that at > this point, the consensus is "no." There is no need for a full support in > simple telephone-only gateways, the protocol is quite heavy and also > subject to rapid evolution with the definition of new media and new > algorithm, and the resulting resource control is very murky. > > On the other hand, there may be value in an H.245 "option", so that we > don't get three vendors implementing the H.245-in-the-gateway extensions > in three different ways. > > -- > Christian Huitema

1 0

Re: FW: Where H.245 goes - MG or MGC (Skran's comments)
by Peter Blatherwick 10 Mar '99

10 Mar '99

Makes sense to me to allow for the OPTION of carrying H.245 messaging within Megaco protocol. This should be defined as an optional package. Not sure how it would be used in a product context, but that's ok, its optional. (I repeat myself, but don't want it to get lost on the twists and turns of the thread.) -- Peter Blatherwick > -----Original Message----- > From: Rex Coldren [SMTP:coldrenr@agcs.com] > Sent: 10 Mar, 1999 10:57 > To: David R. Oran > Cc: Taylor, Tom-PT [SKY:B318-I:EXCH]; Mailing list for parties > associated with ITU-T Study Group 16; megaco(a)BayNetworks.COM > Subject: Re: FW: Where H.245 goes - MG or MGC (Skran's comments) > > Just to get this argument back on track... > > Are we going to allow for the option of H.245 channels being opened > on the MG? > > David R. Oran wrote: > > > Dale's arguments are impeccable if one believes that MGCs are > > gatekeepers, which they're not. MGCs and MGs are a single H.323 > > endpoint, ripped apart and put in different boxes. The Megaco protocol > > glues the boxes together. If you put all of H.323 in the MG then you > > have no need of an MGC in the first place. QED. > > > > I don't think anyone proposes declaring that monolithic H.323 endpoints > > (i.e. MGC+MG+SG) must be split up. Heavens, many of us sell hundreds of > > these every day and they work just fine, thank you. > > > > So, I think I agree with Tom that this response is interesting but not > > terribly relevant to the engineering tradeoffs in marrying Megaco to > > H.323. > > > >

1 0

Re: FW: Where H.245 goes - MG or MGC (Skran's comments)
by Christian Huitema 10 Mar '99

10 Mar '99

On Mar 10, 8:57am, Rex Coldren wrote: > Subject: Re: FW: Where H.245 goes - MG or MGC (Skran's comments) > Just to get this argument back on track... > > Are we going to allow for the option of H.245 channels being opened > on the MG? Hey, we are not the protocol police... The answer to your "are we going to allow" is an unquivocal yes. You could in fact easily extend even our simplest MG-MGC protocol (SGCP) to support H.245 in the gateway, for example by declaring an "m=h245" media type in SDP. As Dave pointed out, it would be difficult then to support the fast start option, but this would definitely result in H.245 in the MG. It would also become very difficult for the MGC to keep track of the resources used by the MG. The real question is whether the base protocol defined by Megaco should mandate autonoumous support of H.245 in each and every MG. I think that at this point, the consensus is "no." There is no need for a full support in simple telephone-only gateways, the protocol is quite heavy and also subject to rapid evolution with the definition of new media and new algorithm, and the resulting resource control is very murky. On the other hand, there may be value in an H.245 "option", so that we don't get three vendors implementing the H.245-in-the-gateway extensions in three different ways. -- Christian Huitema

1 0