April 2000 - sg16-avd - lists.packetizer.com

H.248 Package Coordination
by Tom-PT Taylor 12 Apr '00

12 Apr '00

We have a number of proposed new packages in Megaco, and I'm looking for thoughts on the process for agreeing amongst the various interested parties about which should become Megaco work items and which should be worked elsewhere. I should say that this should be a two-way street -- work introduced elsewhere may be something Megaco wants to get into. Currently, I suggest that interested parties take a look at the following drafts, all available at http://www.ietf.org/internet-drafts/<draft-name> draft-bouwen-megaco-isdn-00.txt Issues for Megaco - Sigtran Interworking in ISDN Access Gateways draft-brown-supplpkgs-00.txt Supplemental Packages for Megaco/H.248 Very shortly these will be joined by packages having to do with R1 and R2 signalling. I can pass the file names along if there is interest. Tom Taylor

1 0

Re: Mob ad hoc contribution numbers
by Roy, Radhika R, ALARC 12 Apr '00

12 Apr '00

Hi, Everyone: We are getting 3 to 4 messages when we send one message to the reflector. Is that a problem with the reflector itself? Best regards, Radhika R. Roy > -----Original Message----- > From: Jaakko Sundquist [SMTP:jaakko.sundquist@nokia.com] > Sent: Wednesday, April 12, 2000 7:30 AM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: Re: Mob ad hoc contribution numbers > > As Paul asked, I have uploaded MDs 16-19 to the ftp site, I will do the > same > for Radhika's contribution MD-020 when it arrives. > > -Jaakko > > > -----Original Message----- > > From: EXT Guram Paul-LPG019 [mailto:lpg019@email.mot.com] > > Sent: 11. April 2000 15:09 > > To: ITU-SG16(a)mailbag.cps.intel.com > > Subject: Mob ad hoc contribution numbers > > > > > > Hi mob group > > > > Nicholas Tran's contribution is to be MD-019, Radhika's new > > contribution to > > be MD-020. > > > > Please can Jaakko load these contributions (Nicolas' and all > > of Radhika's > > contributions),and Stephen Terrill's (MD-016) on to the ftp > > site, I also > > seem to have problems in loading onto the site. Thanks Jaakko. > > > > So the latest MDs for discussion are 11b, 16, 17, 18, 19 and 20. > > > > Paul > >

1 0

AW: H.450.x
by Horvath Ernst 12 Apr '00

12 Apr '00

Hi Wolfgang, H.450.x use H.225.0 call control messages for transport and the usual aliasAddress types in address fields. So there is no restriction imposed by H.450.x - what is possible for H.323 basic calls is also possible for H.450 supplementary services. Ernst Horvath Siemens AG > -----Ursprüngliche Nachricht----- > Von: Wolfgang Bandow [mailto:wolfgang.bandow@DETEWE.DE] > Gesendet am: Mittwoch, 12. April 2000 13:41 > An: ITU-SG16(a)mailbag.cps.intel.com > Betreff: H.450.x > > Hello H.450-Experts, > > H.450.1 says "The generic functional protocol defined in this > Recommendation provides the means to exchange signalling > information for > the control of supplementary services over a LAN" (cf. chapter 5). > > Is my assumption right, that the terminals and Gatekeepers > being part of > a H.450-connection do not necessarily have to be connected to the same > LAN, but may be connected via several routers? > > Whould the following configuration be possible? > > terminal 1 gatekeeper > 1 terminal 2 > gatekeeper 2 terminal 3 > | > | > | | | > ----------------------------------LAN 1 LAN 2 > ----------------------------------------- > > | | > router > 1 router 2 > |------------- ip link > ------------| > > E.G. > terminal 3 calls terminal 1 which has activated a call diversion to > terminal 2. > The gatekeeper routed call model is used. > > Is this allowed? > What will happen? > > Thanks a lot in advance for your reply. > > Regards, > Wolfgang Bandow CT-B, Berlin >

1 0

H.450.x
by Wolfgang Bandow 12 Apr '00

12 Apr '00

Hello H.450-Experts, H.450.1 says "The generic functional protocol defined in this Recommendation provides the means to exchange signalling information for the control of supplementary services over a LAN" (cf. chapter 5). Is my assumption right, that the terminals and Gatekeepers being part of a H.450-connection do not necessarily have to be connected to the same LAN, but may be connected via several routers? Whould the following configuration be possible? terminal 1 gatekeeper 1 terminal 2 gatekeeper 2 terminal 3 | | | | | ----------------------------------LAN 1 LAN 2 ----------------------------------------- | | router 1 router 2 |------------- ip link ------------| E.G. terminal 3 calls terminal 1 which has activated a call diversion to terminal 2. The gatekeeper routed call model is used. Is this allowed? What will happen? Thanks a lot in advance for your reply. Regards, Wolfgang Bandow CT-B, Berlin

1 0

Re: Mob ad hoc contribution numbers
by Jaakko Sundquist 12 Apr '00

12 Apr '00

As Paul asked, I have uploaded MDs 16-19 to the ftp site, I will do the same for Radhika's contribution MD-020 when it arrives. -Jaakko > -----Original Message----- > From: EXT Guram Paul-LPG019 [mailto:lpg019@email.mot.com] > Sent: 11. April 2000 15:09 > To: ITU-SG16(a)mailbag.cps.intel.com > Subject: Mob ad hoc contribution numbers > > > Hi mob group > > Nicholas Tran's contribution is to be MD-019, Radhika's new > contribution to > be MD-020. > > Please can Jaakko load these contributions (Nicolas' and all > of Radhika's > contributions),and Stephen Terrill's (MD-016) on to the ftp > site, I also > seem to have problems in loading onto the site. Thanks Jaakko. > > So the latest MDs for discussion are 11b, 16, 17, 18, 19 and 20. > > Paul >

1 0

Contribution for Uploading: MD-018
by Roy, Radhika R, ALARC 11 Apr '00

11 Apr '00

Hi, Paul: I am sending the contribution for uploading to the ITU-T SG16 Ad Hoc Mobility Web site: MD-018 - "H.323 Inter-Zone Mobility Management" Best regards, Radhika R. Roy AT&T +1 732 420 1580 rrroy(a)att.com <<MD-018_H.323_Inter_Zone_Mobility.zip>>

1 0

Mob ad hoc contribution numbers
by Guram Paul-LPG019 11 Apr '00

11 Apr '00

Hi mob group Nicholas Tran's contribution is to be MD-019, Radhika's new contribution to be MD-020. Please can Jaakko load these contributions (Nicolas' and all of Radhika's contributions),and Stephen Terrill's (MD-016) on to the ftp site, I also seem to have problems in loading onto the site. Thanks Jaakko. So the latest MDs for discussion are 11b, 16, 17, 18, 19 and 20. Paul

1 0

[apc] Re: Request for 2 APC numbers for the Osaka Rapporteurs meeting
by Sakae OKUBO 11 Apr '00

11 Apr '00

Dear Mr. Euchner, In response to your request, the following APC numbers have been allocated to your two contributions: APC-1753 >"White Paper H.235 VERSION 2 - SECURITY AND ENCRYPTION FOR H-SERIES >(H.323 AND OTHER H.245-BASED) MULTIMEDIA TERMINALS" APC-1754 >"White Paper H.323 Annex J - Security for H.323 Annex F" Best regards, Sakae OKUBO *********************************************************** 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 (to be transferred) +81 3 3204 8194 (direct) Fax: +81 3 5287 7287 e-mail: okubo(a)giti.or.jp ***********************************************************

1 0

Contribution for Uploading
by Roy, Radhika R, ALARC 10 Apr '00

10 Apr '00

Hi, Paul: I am enclosing one of the contributions for uploading in the ITU-T SG16 Ad Hoc Mobility Web server: MD-017: "H.323 Mobile Communications Environments and Intra-Zone Mobility Management." I plan to send MD-18 tomorrow. Best regards, Radhika R. Roy AT&T +1 732 420 1580 rrroy(a)att.com

1 0

[Robustness] Modifying Annex E to support Robustness?
by Tim Chen 10 Apr '00

10 Apr '00

Hi, There are a couple of thoughts we have regarding H.323 robustness: 1) As specified in TD87 from the Geneva meeting, "status inquiry" and "status" messages are used to resync call states. This may lead to a tremendous amount of load at the gatekeeper. A gatekeeper routed call requires 2 status inquiries and 2 status messages, plus the messages needed to re-establish the TCP connections. For a gatekeeper handling several thousand calls, this is a lot of messages. 2) Besides considering SCTP, have we considered modifying Annex E procedures to achieve robustness at network interface? If a NIC on a gatekeeper fails, endpoints trying to contact the gatekeeper could use a recovery address on another NIC to resend their messages. Is there any reason why this cannot be done or is undesirable? Such approach avoids invoking the procedures mentioned in TD87 to re-synchronize call states and to re-establish TCP connections. Since we are proposing a new set of procedures for a 323 entity to support robustness, backward compatibility doesn't seem like a problem. Thanks. Regards, Tim ------------------------------------------------------------ Tim Chen Trillium Digital Systems, Inc. Phone: +1 310 442 9222 Fax: +1 310 442 1162 email: tim(a)trillium.com http://www.trillium.com

3 2