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

Documents for the SG16 meeting in Porto Seguro
by OKUBO Sakae 16 Apr '01

16 Apr '01

Dear SG16 experts, The next Study Group 16 meeting will be held during 28 May - 8 June in Porto Seguro, Brazil (see <http://www.itu.int/itudoc/itu-t/com16/coll/01-04/001_ww9.doc>). Since this is an official SG16 meeting, all the documents are managed by ITU-TSB. There are three types of document: White Contributions from the members, Delayed Contributions from the members and Temporary Documents from Rapporteurs. To facilitate the advance review of experts, please upload your document to ftp://standard.pictel.com/avc-site/Incoming or e-mail it to me when you have submitted your document to ITU-TSB. These documents will not be AVD-numbered as in our autonomous Rapporteur meetings, but placed at http://standard.pictel.com/ftp/avc-site/0105_Por/ without changing the file name. Best regards, OKUBO Sakae ********************************************************* Global Information and Telecommunication Institute (GITI) Waseda University 29-7 Waseda University Bldg. 1-3-10 Nishi-Waseda, Shinjuku-ku, Tokyo 169-0051 Japan e-mail: okubo(a)giti.waseda.ac.jp Tel: +81 3 3204 8194 Fax: +81 3 5286 3832 ********************************************************* My contract with TAO finished on 31 March. Please change my e-mail address as above, though okubo(a)giti.or.jp will continue to work for some time. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

Re: Question on presence
by Paul, Manoj 13 Apr '01

13 Apr '01

Dear Mr. Okubo, As you pointed out, the item (3) still needs to be worked on and the intention is what you mentioned during the end of your mail. In addition, the Presence signalling shall be carried out using the genericData field in RAS messages (using H.323 Generic Extensibility Framework), instead of adding new IEs to RAS messages. The ASN.1 synatx of CommunicationState may be further enhanced/modified to be more generic and reflect the necessary information that Presence is required to support (e.g user information in a standard presence format). The work on this is to be carried out further and presented as AVDs in subsequent SG16 meetings. best regards Manoj Paul. -----Original Message----- From: OKUBO Sakae [mailto:okubo@GITI.WASEDA.AC.JP] Sent: Thursday, April 12, 2001 8:10 PM To: ITU-SG16(a)mailbag.cps.INTEL.COM Subject: Question on presence Dear Mr. Manoj Paul, I am trying to understand the concept of H.323 presence. In AVD-2087, communication states to be exchanged are listed as: 1) status of the user, 2) its reachable address, 3) user's means of communication, including the preferred mode. The ASN.1 syntax CommunicationState in AVD-2087 includes newAliasAddress (corresponding to 2) above, I understand) and availableForCall, busy (both corresponding to 1) above). I wonder how 3) is handled. Is it going to be added in the course of work? Or as H.323 has the H.245 capability exchange procedure, H.323 presence needs only 1) and 2) above? Or still we would like to indicate e.g. being ready to communicate with fixed H.323 terminal at office, mobile phone like H.323 or H.323 on PDA on the road before the actual communication? Best regards, OKUBO Sakae ********************************************************* Global Information and Telecommunication Institute (GITI) Waseda University 29-7 Waseda University Bldg. 1-3-10 Nishi-Waseda, Shinjuku-ku, Tokyo 169-0051 Japan e-mail: okubo(a)giti.waseda.ac.jp Tel: +81 3 3204 8194 Fax: +81 3 5286 3832 ********************************************************* ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

Re: ras address in RRQ/GRQ
by Francois Audet 13 Apr '01

13 Apr '01

The reason I was thinking about this is that if it was NOT included in the RRQ/GRQ, and the gatekeeper would be force to use the source IP address for any other messages (from GK to GW), the same as if it had been explicitly indicated in the GRQ/RRQ, then it would be possible to use a gatekeeper on one side of a NAT while both endpoints are on the other side. I guess not. Thanks Terry. > -----Original Message----- > From: Terry L Anderson [mailto:tla@LUCENT.COM] > Sent: Friday, April 13, 2001 6:31 AM > To: ITU-SG16(a)mailbag.cps.INTEL.COM > Subject: Re: ras address in RRQ/GRQ > > > This is of course the opposite of H.248 where replies must go > to source > address. But remember that there are requests (as opposed to confirms > and rejects) that are sent from GK to GW and the GK must know what > address to use. If no rasaddress were registered and ARQs > (for example) > came from various port numbers, the GK would have no idea > where to send > a DRQ, URQ, IRQ, etc. > > rasaddress is not optional in GRQ and so cannot be omitted. It is > probably not intended to be optional in RRQ although since it > is defined > as SEQUENCE OF TransportAddress and SEQUENCES can be of zero > length, it > is in effect optional. A comment probably should be added to make it > required for the above reason. > > "Paul E. Jones" wrote: > > > Francois, There is no requirement that RAS messages sent to a > > Gatekeeper have to be sent from the same port that it will > receive RAS > > messages. If it is not included, I would expect that the > results will > > be unpredictable. Some devices will probably assume an address and > > others will probably just reject the request. Paul > > > > ----- Original Message ----- > > From: Francois Audet > > To: ITU-SG16(a)mailbag.cps.INTEL.COM > > Sent: Thursday, April 12, 2001 8:17 PM > > Subject: ras address in RRQ/GRQ > > Guys,What is the purpose of the rasAddress in GRQ and > > RRQ?Shouldn't it just be the originating IP address? Is the > > gatekeeper supposed to send the GCF and RCF to IP address > > indicated in the GRQ/RRQ, or is it supposed to send it to > > the source IP address (at the IP layer)?What if the RAS > > address is not included in the RRQ/GRQ?----François AUDET, > > Nortel Networksmailto:audet@nortelnetworks.com, tel:+1 408 > > 495 3756 > > > -- > ------------------------------------------------------------ > Terry L Anderson mailto:tla@lucent.com > Tel:908.582.7013 Fax:908.582.6729 > Pager:800.759.8352 pin 1704572 1704572(a)skytel.com > Lucent Technologies/ Voice Over IP Access Networks/ Applications Grp > Rm 2B-121, 600 Mountain Av, Murray Hill, NJ 07974 > http://its.lucent.com/~tla (Lucent internal) http://www.gti.net/tla > >

1 0

ras address in RRQ/GRQ
by Francois Audet 13 Apr '01

13 Apr '01

Guys, What is the purpose of the rasAddress in GRQ and RRQ? Shouldn't it just be the originating IP address? Is the gatekeeper supposed to send the GCF and RCF to IP address indicated in the GRQ/RRQ, or is it supposed to send it to the source IP address (at the IP layer)? What if the RAS address is not included in the RRQ/GRQ? ---- François AUDET, Nortel Networks mailto:audet@nortelnetworks.com <mailto:audet@nortelnetworks.com> , tel:+1 408 495 3756

3 2

Is the capability set also a delta for MultiplexCapability?
by Frank Derks 13 Apr '01

13 Apr '01

There is general consensus that received capability sets should be treated as deltas (unfortunately H.323 is not really explicit about this). This certainly applies to the capabilityTable and CapabilityDescriptors elements in the TerminalCapabilitySet message, but does this also apply to the multiplexCapability? If I first send a TCS with a nonStandard element and then a TCS with a h225Capability element should this be treated as a delta or a replacement? If I send two TCSs, both with a h225Capability element, should anything that is present in the second, but not in the first TCS be "added" and anything that was present in the first but not present in the second be removed? Regards, Frank ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

Merchant Status Account #6DA0
by Victor Simmons 13 Apr '01

13 Apr '01

***** This is an HTML Message ! *****

1 0

All VIP'S
by Earnie Preston 13 Apr '01

13 Apr '01

Dear Candidate, You have been selected as a potential candidate for a free listing in the 2001 Edition of the International Executive Guild Registry. Please accept our congratulations for this coveted honor. As this edition is so important in view of the new millennium, the International Executive Guild Registry will be published in two different formats; the searchable CD-ROM and the Online Registry. Since inclusion can be considered recognition of your career position and professionalism, each candidate is evaluated in keeping with high standards of individual achievement. In light of this, the International Executive Guild thinks that you may make an interesting biographical subject. We look forward to your inclusion and appearance in the International Executive Guild's Registry. Best wishes for your continued success. International Executive Guild Listing Dept.  If you wish to be removed from our list, please submit your request at the bottom of this email.   0); // returns false if empty } // --> International Executive Guild Registration Form (US and Canada Only) Please fill out this form if you would like to be included in The International Executive Guild's Registry. For accuracy and publication purposes, please complete and send this form at the earliest opportunity. There is no charge or obligation to be listed in The International Executive Guild's Registry. Your Name Your Company Title Address City State or Province Country USACanada ZIP/Postal Code Day Time Telephone Home Phone (Not To Be Published) Email TO HELP US IN CONSIDERING YOUR APPLICATION, PLEASE TELL US A LITTLE ABOUT YOURSELF... Your Business (Financial Svcs, Banking, Computer Hardware, Software, Professional Svcs, Chemicals, Apparel, Aerospace, Food, Government, Utility, etc.) Type of Organization (Mfg, Dist/Wholesaler, Retailer, Law Firm, Investment Bank, Commercial Bank, University, Financial Consultants, Ad Agency, Contractor, Broker, etc.) Your Business Expertise (Corp.Mgmt, Marketing, Civil Engineering, Tax Law, Nuclear Physics, Database Development, Operations, Pathologist, Mortgage Banking, etc.) Major Product Line (Integrated Circuits, Commercial Aircraft, Adhesives, Cosmetics, Plastic Components, Snack Foods, etc.) Note: Submitting this form will be made by email, not by use of  www.  Confirmation of its delivery is made by browsing your outgoing mail. Thank you for filling in this form, we will contact you with more information. List Removal Click Here

1 0

EndSessionCommand?
by Paul, Manoj 13 Apr '01

13 Apr '01

Hi, Does an endpoint using Tunnelling to exchange H.245 messages with peer, need to send EndSessionCommand message during call termination? There are two different texts relating to this: H.245 Specification(V7), Section B.13.4: "This command indicates the end of the h245 session. After tx EndSessionCommand, the terminal shallnot send any more of the messages defined in this Recommendation". H.323 Specification (V4), Section 8.5: Phase E-Call Termination "..It shall transmit H.245 endSessionCommand message in the H.245 Control Channel..." First statement seems to indicate that notwithstanding how H.245 messages are exchanged, an EndSessionCOmmand should be sent to stop any further exchange. Second statement seems to mean that EndSessionCommand is sent only when H.245 Control Channel exists (tunnelling not used). Could someone clarify? thanks Manoj Paul. Trillium Digital Systems. -----Original Message----- From: Nehru, Archana [mailto:archie@TRILLIUM.COM] Sent: Thursday, April 12, 2001 5:34 PM To: ITU-SG16(a)mailbag.cps.INTEL.COM Subject: H.323 v1 problem hi all, I have a doubt about ARQ message in H.323 -V1. The H.323 specs for V1 say that "srcCallSignalAddress" and "destCallSignalAddress" are optional. But there were some mails exchanged somtime back on the mailing list which said that these two fields are MANDATORY for v1, since without these fields it is not possible to identify a call in H.323 V1. E.g: Let us say we have an endpoint EP1, and EP2 and a GK and a call is Gk-routed. When EP1 wants to make a connection to EP2, it finishes RAS with GK and then sends a SETUP to GK. When EP2 receives the incoming SETUP from the GK, it send an ARQ to the GK. At this point the Gk needs to identify the "call " associated with the incoming ARQ. As there was no "callId" in V1, the only parameters that can give the GK a clue are the "srcCallSignalAddress" and "destCallSignalAddress" tuple. But if these are treated optional, then what parameters can the GK use to find the "associated call"? I believe for this reason it was suggested that "srcCallSignalAddress" and "destCallSignalAddress" would always be present in ARQ from a V1. Can someone please confirm this?. Many thanks, -Archana Archana Nehru, Engineering Project Manager, Trillium Digital Systems Inc., an Intel Company. http://www.trillium.com Ph:310-481-5525 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

2 1

H.323 v1 problem
by Nehru, Archana 13 Apr '01

13 Apr '01

hi all, I have a doubt about ARQ message in H.323 -V1. The H.323 specs for V1 say that "srcCallSignalAddress" and "destCallSignalAddress" are optional. But there were some mails exchanged somtime back on the mailing list which said that these two fields are MANDATORY for v1, since without these fields it is not possible to identify a call in H.323 V1. E.g: Let us say we have an endpoint EP1, and EP2 and a GK and a call is Gk-routed. When EP1 wants to make a connection to EP2, it finishes RAS with GK and then sends a SETUP to GK. When EP2 receives the incoming SETUP from the GK, it send an ARQ to the GK. At this point the Gk needs to identify the "call " associated with the incoming ARQ. As there was no "callId" in V1, the only parameters that can give the GK a clue are the "srcCallSignalAddress" and "destCallSignalAddress" tuple. But if these are treated optional, then what parameters can the GK use to find the "associated call"? I believe for this reason it was suggested that "srcCallSignalAddress" and "destCallSignalAddress" would always be present in ARQ from a V1. Can someone please confirm this?. Many thanks, -Archana Archana Nehru, Engineering Project Manager, Trillium Digital Systems Inc., an Intel Company. http://www.trillium.com Ph:310-481-5525 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

2 1

All VIP'S
by Perry Thomas 13 Apr '01

13 Apr '01

Dear Candidate, You have been selected as a potential candidate for a free listing in the 2001 Edition of the International Executive Guild Registry. Please accept our congratulations for this coveted honor. As this edition is so important in view of the new millennium, the International Executive Guild Registry will be published in two different formats; the searchable CD-ROM and the Online Registry. Since inclusion can be considered recognition of your career position and professionalism, each candidate is evaluated in keeping with high standards of individual achievement. In light of this, the International Executive Guild thinks that you may make an interesting biographical subject. We look forward to your inclusion and appearance in the International Executive Guild's Registry. Best wishes for your continued success. International Executive Guild Listing Dept. _____ If you wish to be removed from our list, please submit your request at the bottom of this email. _____ International Executive Guild Registration Form (US and Canada Only) _____ Please fill out this form if you would like to be included in The International Executive Guild's Registry. For accuracy and publication purposes, please complete and send this form at the earliest opportunity. There is no charge or obligation to be listed in The International Executive Guild's Registry. _____ Your Name Your Company Title Address City State or Province Country USACanada ZIP/Postal Code Day Time Telephone Home Phone (Not To Be Published) Email _____ TO HELP US IN CONSIDERING YOUR APPLICATION, PLEASE TELL US A LITTLE ABOUT YOURSELF... _____ Your Business (Financial Svcs, Banking, Computer Hardware, Software, Professional Svcs, Chemicals, Apparel, Aerospace, Food, Government, Utility, etc.) Type of Organization (Mfg, Dist/Wholesaler, Retailer, Law Firm, Investment Bank, Commercial Bank, University, Financial Consultants, Ad Agency, Contractor, Broker, etc.) Your Business Expertise (Corp.Mgmt, Marketing, Civil Engineering, Tax Law, Nuclear Physics, Database Development, Operations, Pathologist, Mortgage Banking, etc.) Major Product Line (Integrated Circuits, Commercial Aircraft, Adhesives, Cosmetics, Plastic Components, Snack Foods, etc.) Note: Submitting this form will be made by email, not by use of www. Confirmation of its delivery is made by browsing your outgoing mail. _____ Thank you for filling in this form, we will contact you with more information. _____ List Removal Click <mailto:nvbobr@netscape.net?subject=remove> Here

1 0