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

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