February 2003 - sg16-avd - lists.packetizer.com

FW: [HvS] H323 for Instant Message and Presence information suppo rt?
by Anatoli Levine 11 Feb '03

11 Feb '03

Interesting question - anyone wants to take a stub at it? Thanks, Anatoli -----Original Message----- From: Xiaotao Wu [mailto:xiaotaow@hotmail.com] Sent: Tuesday, February 11, 2003 11:41 AM To: Hvs(a)packetizer.com Subject: [HvS] H323 for Instant Message and Presence information support? In the article "H.323 versus SIP: A Comparison", seems a very important aspect of Internet Telephony prodcut (NOTE: not Telephony product) is missed -- how easily to integrate the H323 or SIP products with the other Internet services? Is there any effort in H323 on supporting Instant Message and presence information -- an important and convinient service over the Internet? Or we have to say that any H323 terminal has to have a separate messenger with it for IM and presence information, and any H323 proxy has to have a separate presence agent with it. For SIP, with the effort in SIMPLE working group, this can be easily solved, and it's easy to add a presence agent to a SIP proxy server. Thanks! _________________________________________________________________ The new MSN 8: smart spam protection and 2 months FREE* http://join.msn.com/?page=features/junkmail _______________________________________________ H.323-versus-SIP mailing list (hvs(a)packetizer.com) http://host4.imagelinkusa.net/mailman/listinfo/hvs_packetizer.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)lists.intel.com

1 0

Re: Tunneling ISDN - semi-permanent scenario
by Peter Price 10 Feb '03

10 Feb '03

Frank, I've added the subject line that I forgot on the original posting. thanks for your reply but I still don't see how it all works. I'm either missing something fundamental or there really is a need for this to be covered in H.323. > I assume that you are referring to 9.3.2/ECMA-333 and 11.2/ECMA-333. > In 9.3.2/ECMA-333, it is stated that the Uq-channel number is used > as the session identifier and not the other way around, but this is > a only a trivial matter. You have the correct references, but I think a minor mis-interpretation. 9.3.2/ECMA-333 says the pair of logical channels shall be established and then it says that the session numnber shall be used as the Uq-channel number. In other words the session number is determined before the Uq-channel number. This means that when a QSIG SETUP is received by a gateway that is going to tunnel using the semi-permanent scenario an exchange of H.323 messages must occur to establish the RTP streams and hence the session number before it is possible to forward the QSIG SETUP with the correct Uq-channel number through the H323 tunnel. The gateway that received the SETUP can only establish the RTP stream in one direction. The RTP stream in the other direction must be initiated by the destination gateway. If that destination gateway is the H.323 slave how does it ensure that it achieves the same session number for the return channel (consider the possibility of multiple QSIG calls arriving at the gateway simultaneously). 11.2/ECMA-333 Note 2 is a reminder that each gateway/PINX must open its own tx channel. The only way I can think of to ensure both RTP streams have matching session numbers is for the original OLC to be initiated from the slave so that the master can assign the session number and immediately open a return channel with the same session number. So now the question becomes - what if the QSIG SETUP is originally received at the master gateway. What message does it send to the remote gateway? Hence my original questions. Or alternatively - what am I missing? Regards Peter > -----Original Message----- > From: frank.derks(a)philips.com [mailto:frank.derks@philips.com] > Sent: 10 February 2003 18:10 > To: Peter Price > Cc: ITU-SG16(a)echo.jf.INTEL.COM > Subject: Re: > > > Peter, > > I assume that you are referring to 9.3.2/ECMA-333 and 11.2/ECMA-333. > In 9.3.2/ECMA-333, it is stated that the Uq-channel number is used > as the session identifier and not the other way around, but this is > a only a trivial matter. > > Your concern seems to be the fact that the "H.245 slave" can > establish a QSIG call and therefore tunnel a QSIG SETUP message, but > it is not in control over the H.245 session identifier: H.245 states > that the session identifier can only be created by the master. > > When the slave opens its logical channel towards the master it will > specify a session identifier with the value 0. In the > OpenLogicalChannelAck message, the master will provide the session > identifier that is to be used for this session. If the master > overruled the Uq-channel number, it will return this number as the > session identifier. If the master accepted the Uq-channel number > that was proposed by the slave, it will return this number as the > session identifier. > > So, unless I don't quite understood you concerns, I do not see any > real problems. > > > Regards, > > Frank > > ----------------------------------------------------- > Frank Derks |Tel +31 35 6893238 | > APPlications |Fax +31 35 6891290 | > Philips Business Communications|P.O. Box 32 | > |1200 JD Hilversum | > |The Netherlands | > ----------------------------------------------------| > E-mail: mailto:frank.derks@philips.com | > WWW: http://www.sopho.philips.com | > ----------------------------------------------------- > > > > > > > > > > Peter Price <PeterP(a)VEGASTREAM.COM> > Sent by: > Mailing list for parties associated with ITU-T Study Group 16 > <ITU-SG16(a)echo.jf.INTEL.COM> > 2003-02-06 11:53 > Please respond to Peter Price > > > To: ITU-SG16(a)echo.jf.INTEL.COM > cc: (bcc: Frank Derks/HVS/BE/PHILIPS) > Subject: > Classification: > > > > All, > > ECMA 333 defines the mapping functions for tunneling QSIG over H.323 > networks. > It describes two scenarios, on-demand and semi-permanent. > In on-demand each new ISDN call is tunneled through a > separate H.323 call. > In semi-permanent multiple ISDN calls can be tunneled through > a single > H323 > call. > > 10.2.4/H323 V4 describes the mechanism for tunneling ISDN > protocols within > H323 calls. > However, this only ssems to cover the on-demand scenario. It does not > include any procedures for the establisment of the additional > RTP streams > that will be required to support multiple calls. > > Obviously the existing logical channel procedures can be used > to actually > open the channels - thats not the problem. > > ECMA 333 states that the Channel ID IE in the tunneled messages should > contain the H.323 session id of the logical channel to be > used for the > audio > stream. This isn't a problem for on-demand, there is only one voice > channel > and it uses the well-known session id 1. > > However there are multiple active channels whenn using > semi-permanent and > the problem is that the session ID is allocated by the H.323 > master - what > happens if you want to originate a call from the H.323 slave > - what do you > put in the tunneled ISDN SETUP message? > > Is this actually covered anywhere or does it need something in H.323? > Is there any work in progress within the standards community > to cover this > issue? > Any other commnents? > > Thanks > > > Peter Price > Principal Software Engineer > Vegastream, a division of Pace Micro Technology plc > > Enabling Digital. > Our Vision is to be the biggest supplier worldwide of digital gateway > technology. > > Tel: +44 1344 784914 > Fax: +44 1344 784901 > Berkshire Court, Western Road, Bracknell, Berkshire. RG12 1RE > www.pace.co.uk > www.vegastream.co.uk > > This E-mail and any attachments hereto are strictly confidential and > intended solely for the addressee. If you are not the > intended addressee > please notify the sender by return and delete the message. > You must not > disclose, forward or copy this E-mail or attachments to any > third party > without the prior consent of the sender. > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > For help on this mail list, send "HELP ITU-SG16" in a message to > listserv(a)lists.intel.com > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)lists.intel.com

1 0

None
by frank.derks＠PHILIPS.COM 10 Feb '03

10 Feb '03

Peter, I assume that you are referring to 9.3.2/ECMA-333 and 11.2/ECMA-333. In 9.3.2/ECMA-333, it is stated that the Uq-channel number is used as the session identifier and not the other way around, but this is a only a trivial matter. Your concern seems to be the fact that the "H.245 slave" can establish a QSIG call and therefore tunnel a QSIG SETUP message, but it is not in control over the H.245 session identifier: H.245 states that the session identifier can only be created by the master. When the slave opens its logical channel towards the master it will specify a session identifier with the value 0. In the OpenLogicalChannelAck message, the master will provide the session identifier that is to be used for this session. If the master overruled the Uq-channel number, it will return this number as the session identifier. If the master accepted the Uq-channel number that was proposed by the slave, it will return this number as the session identifier. So, unless I don't quite understood you concerns, I do not see any real problems. Regards, Frank ----------------------------------------------------- Frank Derks |Tel +31 35 6893238 | APPlications |Fax +31 35 6891290 | Philips Business Communications|P.O. Box 32 | |1200 JD Hilversum | |The Netherlands | ----------------------------------------------------| E-mail: mailto:frank.derks@philips.com | WWW: http://www.sopho.philips.com | ----------------------------------------------------- Peter Price <PeterP(a)VEGASTREAM.COM> Sent by: Mailing list for parties associated with ITU-T Study Group 16 <ITU-SG16(a)echo.jf.INTEL.COM> 2003-02-06 11:53 Please respond to Peter Price To: ITU-SG16(a)echo.jf.INTEL.COM cc: (bcc: Frank Derks/HVS/BE/PHILIPS) Subject: Classification: All, ECMA 333 defines the mapping functions for tunneling QSIG over H.323 networks. It describes two scenarios, on-demand and semi-permanent. In on-demand each new ISDN call is tunneled through a separate H.323 call. In semi-permanent multiple ISDN calls can be tunneled through a single H323 call. 10.2.4/H323 V4 describes the mechanism for tunneling ISDN protocols within H323 calls. However, this only ssems to cover the on-demand scenario. It does not include any procedures for the establisment of the additional RTP streams that will be required to support multiple calls. Obviously the existing logical channel procedures can be used to actually open the channels - thats not the problem. ECMA 333 states that the Channel ID IE in the tunneled messages should contain the H.323 session id of the logical channel to be used for the audio stream. This isn't a problem for on-demand, there is only one voice channel and it uses the well-known session id 1. However there are multiple active channels whenn using semi-permanent and the problem is that the session ID is allocated by the H.323 master - what happens if you want to originate a call from the H.323 slave - what do you put in the tunneled ISDN SETUP message? Is this actually covered anywhere or does it need something in H.323? Is there any work in progress within the standards community to cover this issue? Any other commnents? Thanks Peter Price Principal Software Engineer Vegastream, a division of Pace Micro Technology plc Enabling Digital. Our Vision is to be the biggest supplier worldwide of digital gateway technology. Tel: +44 1344 784914 Fax: +44 1344 784901 Berkshire Court, Western Road, Bracknell, Berkshire. RG12 1RE www.pace.co.uk www.vegastream.co.uk This E-mail and any attachments hereto are strictly confidential and intended solely for the addressee. If you are not the intended addressee please notify the sender by return and delete the message. You must not disclose, forward or copy this E-mail or attachments to any third party without the prior consent of the sender. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)lists.intel.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)lists.intel.com

1 0

Re: Errors in TD-02
by OKUBO Sakae 10 Feb '03

10 Feb '03

Dear Paul, Thank you for your advice. An updated version is issued as: http://standard.pictel.com/ftp/avc-site/0302_San/TD-02a.xls At 23:50 -0500 03/02/09, Paul E. Jones wrote: >Mr. Okubo, > >In TD-02, I noted a few errors: > >AVD-2268 is marked as being to "I, 2", but the document is actually >to "I, 3". Even so, I have put this on the Q.2 agenda, it seems >relevant, considering the H.460.4 work (referenced in that liaison). > >AVD-2299 should be addressed only to Q.2. > >AVD-2308 should be to 2 and 3. > >AVD-2318 is addressed to "3, I". I think you are saying "G, I." >AVD-2321 and AVD-2322 are reversed. I will assume that the >documents will remain the same and that the TD-02 will be updated to >reflect the real document titles. Yes, I have swapped the titles in TD-02a. -- Best regards, OKUBO Sakae e-mail: okubo(a)giti.waseda.ac.jp ******************************************************************* YRP Office Global Information and Telecommunication Institute (GITI) Waseda University YRP Ichibankan 312 Tel: +81 46 847 5406 3-4 Hikarinooka, Yokosuka-shi, Kanagawa-ken Fax: +81 46 847 5413 239-0847 Japan GITI Headquarter 29-7 Waseda University Bldg. Tel: +81 3 5286 3831 1-3-10 Nishi-Waseda, Shinjuku-ku, Tokyo Fax: +81 3 5286 3832 169-0051 Japan ******************************************************************* ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)lists.intel.com

1 0

San Jose meeting information
by OKUBO Sakae 07 Feb '03

07 Feb '03

Dear San Jose meeting participants, This is information from the meeting host. >From: "Paul E. Jones" <paulej(a)packetizer.com> >To: "Sakae Okubo" <okubo(a)giti.waseda.ac.jp> >Subject: Updated attendee list >Date: Wed, 5 Feb 2003 23:52:51 -0500 > >Mr. Okubo, > >We have an additional attendee registered, for a total of 29 now. I >would expect that not all Cisco folks will be present at all times. >The room holds about 40 people, so I would expect that we should >have plenty of work space. > >I have requested a projector for the laptop and microphones for the >rapporteurs and floor stand or mobile microphones.. whatever they >have available. > >I did not make arrangement for catering, but there is a cafeteria in >that building, so getting stacks and drinks is easy to do. > >We will have power at each seat and Ethernet connections at each >seat. My understanding is that hubs will be placed throughout the >room. Cisco employees can access the wireless network, but no >wireless access is available for non-Cisco employees. Further, >Cisco policy does not allow non-Cisco IT managed wireless devices to >be installed by employees, so I can't install an access point myself. > >I actually get there late Monday night, so I can only hope things >are in good order when I arrive. I will follow-up with the folks in >SJ to make sure things are going OK. > >[...] > >Paul -- Best regards, OKUBO Sakae e-mail: okubo(a)giti.waseda.ac.jp ******************************************************************* YRP Office Global Information and Telecommunication Institute (GITI) Waseda University YRP Ichibankan 312 Tel: +81 46 847 5406 3-4 Hikarinooka, Yokosuka-shi, Kanagawa-ken Fax: +81 46 847 5413 239-0847 Japan GITI Headquarter 29-7 Waseda University Bldg. Tel: +81 3 5286 3831 1-3-10 Nishi-Waseda, Shinjuku-ku, Tokyo Fax: +81 3 5286 3832 169-0051 Japan ******************************************************************* ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)lists.intel.com

1 0

None
by Peter Price 06 Feb '03

06 Feb '03

All, ECMA 333 defines the mapping functions for tunneling QSIG over H.323 networks. It describes two scenarios, on-demand and semi-permanent. In on-demand each new ISDN call is tunneled through a separate H.323 call. In semi-permanent multiple ISDN calls can be tunneled through a single H323 call. 10.2.4/H323 V4 describes the mechanism for tunneling ISDN protocols within H323 calls. However, this only ssems to cover the on-demand scenario. It does not include any procedures for the establisment of the additional RTP streams that will be required to support multiple calls. Obviously the existing logical channel procedures can be used to actually open the channels - thats not the problem. ECMA 333 states that the Channel ID IE in the tunneled messages should contain the H.323 session id of the logical channel to be used for the audio stream. This isn't a problem for on-demand, there is only one voice channel and it uses the well-known session id 1. However there are multiple active channels whenn using semi-permanent and the problem is that the session ID is allocated by the H.323 master - what happens if you want to originate a call from the H.323 slave - what do you put in the tunneled ISDN SETUP message? Is this actually covered anywhere or does it need something in H.323? Is there any work in progress within the standards community to cover this issue? Any other commnents? Thanks Peter Price Principal Software Engineer Vegastream, a division of Pace Micro Technology plc Enabling Digital. Our Vision is to be the biggest supplier worldwide of digital gateway technology. Tel: +44 1344 784914 Fax: +44 1344 784901 Berkshire Court, Western Road, Bracknell, Berkshire. RG12 1RE www.pace.co.uk www.vegastream.co.uk This E-mail and any attachments hereto are strictly confidential and intended solely for the addressee. If you are not the intended addressee please notify the sender by return and delete the message. You must not disclose, forward or copy this E-mail or attachments to any third party without the prior consent of the sender. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)lists.intel.com

1 0

San Jose meeting documents
by OKUBO Sakae 05 Feb '03

05 Feb '03

Dear SG16 experts, This reflector itu-sg16(a)lists.intel.com has resumed its operation thanks to the Intel efforts. Please note that the San Jose meeting documents are available at: http://standard.pictel.com/ftp/avc-site/0302_San/ where the current list of documents is contained as: http://standard.pictel.com/ftp/avc-site/0302_San/TD-02.xls If you are using a ftp tool, URL is ftp://standard.pictel.com/avc-site/0302_San/ -- Best regards, OKUBO Sakae e-mail: okubo(a)giti.waseda.ac.jp ******************************************************************* YRP Office Global Information and Telecommunication Institute (GITI) Waseda University YRP Ichibankan 312 Tel: +81 46 847 5406 3-4 Hikarinooka, Yokosuka-shi, Kanagawa-ken Fax: +81 46 847 5413 239-0847 Japan GITI Headquarter 29-7 Waseda University Bldg. Tel: +81 3 5286 3831 1-3-10 Nishi-Waseda, Shinjuku-ku, Tokyo Fax: +81 3 5286 3832 169-0051 Japan ******************************************************************* ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)lists.intel.com

1 0

Re: document in incoming
by Euchner Martin ICN M SR 3 04 Feb '03

04 Feb '03

I've uploaded the following contributions to the Incoming directory AVD-2284 Editor H.235 Draft H.235 VERSION 3 AVD-2285 Siemens AG H.235 Annex G: H.323-SIP Security Interworking considerations With kind regards Martin Euchner. ----------------------------------------------------------------------- | Dipl.-Inf. Rapporteur Q.G/SG16 | Martin Euchner Phone: +49 89 722 55790 | Siemens AG.....................Fax : +49 89 722 62366 | ICN M SR 3 mailto:Martin.Euchner@siemens.com | mailto:martin.euchner@ties.itu.int | Hofmannstr. 51 Intranet: http://intranet.icn.siemens.de/marketing/cs27/topics/security/ | D-81359 Muenchen Internet: http://www.siemens.de/ | __________________ | Germany ----------------------------------------------------------------------- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)lists.intel.com

1 0

testing - please disregard
by OKUBO Sakae 31 Jan '03

31 Jan '03

This is a test message to check if the reflector is working - Sakae OKUBO ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)lists.intel.com

1 0