- sg16-avd - lists.packetizer.com

Re: liaison from SG11
by Sakae OKUBO 15 Sep '00

15 Sep '00

At 10:13 -0600 00/09/13, Glen Freundlich wrote: >I have received a liaison from SG11 (Q.BICC/11) titled "Liaison To SG >12, SG 13 And SG 16 Asking For Guidance On Quality Of Services to be >Supported with the BICC Protocol" that I believe we should review during >our rapporteurs meeting of 9-10 November. Could you please provide an APC >number? APC-1950 has been allocated to this liaison and will eventually be placed at /0011_Gen directory. 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 *********************************************************** ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

Re: RTP port for sending media
by Nadathur, Srivathsan G (Srivathsan) 14 Sep '00

14 Sep '00

Thanks Paul. I got confused by the following line from the H.245 section 7.3.2 However I think what is said in H.323 has more precedence over what is said in H.245. "mediaControlChannel indicates the media control channel in which the sender of the openLogicalChannelAck will be listening for media control messages for this session. This field is present only when a media control channel is required." Thanks Srivathsan -----Original Message----- From: Paul E. Jones [mailto:paulej@PACKETIZER.COM] Sent: Thursday, September 14, 2000 2:52 PM To: ITU-SG16(a)MAILBAG.INTEL.COM Subject: Re: RTP port for sending media Srivathsan, 6.2.8.2 states this: ``The initiating terminal shall send an openLogicalChannel message as described in Recommendation H.245. If the logical channel is to carry a media type using RTP (audio or video), the openLogicalChannel message shall include the mediaControlChannel parameter containing the Transport Address for the reverse RTCP channel.'' Note the part "shall include the mediaControlChannel parameter" Paul ----- Original Message ----- From: "Nadathur, Srivathsan G (Srivathsan)" <snadathur(a)LUCENT.COM> To: <ITU-SG16(a)mailbag.cps.intel.com> Sent: Thursday, September 14, 2000 12:56 PM Subject: Re: RTP port for sending media > Also, I remember H.245 spec implying that RTCP is not a mandatory > requirement. Could someone clarify. > > Thanks > Srivathsan. > > -----Original Message----- > From: Paul E. Jones [mailto:paulej@packetizer.com] > Sent: Tuesday, September 12, 2000 12:20 PM > To: Anatoli Levine > Cc: h323implementors(a)imtc.org; ITU-SG16(a)mailbag.cps.intel.com > Subject: Re: RTP port for sending media > > > Anatoli, et al, > > I agree that it would be very helpful for NAT devices or other equipment to > be able to safely rely on receiving media from the specified RTP port that > is one lower than the RTCP port advertised in the original OLC message. I > thought that was the expected behavior when using RTP/RTCP, but recent > discussions with folks working on SIP is that "no, that's not necessarily > true." Apparently, it is believed that a SIP device may send RTP from any > port. > > So, if you have a line like this in the INVITE message: > m= > to indicate a bi-directional media flow, the RTP address is interpreted only > as the "receive" address. But then I questioned, "what about the fact that > the associated RTCP port (next odd port) is used for receiving RR packets.. > would that not suggest that the RTP port for sending is also the same port > specified in this 'm=' line?" > > The answer was 'no'. So this made me curious about H.323 implementations. > > Do we need to clarify that the RTP port used to send data associated with > the RTCP address in an OLC is the next lower port (even) number, or do we > have implementations out there that send RTP traffic from and random port, > irrespective of the RTCP port put in the forwardLogicalChannelParameters of > the OLC message? If the latter is the case, I think we need to state this > clearly, too. > > Thanks, > Paul > > > ----- Original Message ----- > From: Anatoli Levine <mailto:alevine@radvision.com> > To: Paul E. <mailto:paulej@packetizer.com> Jones > Cc: h323implementors(a)imtc.org <mailto:h323implementors@imtc.org> > Sent: Tuesday, September 12, 2000 9:37 AM > Subject: Re: RTP port for sending media > > Paul, > > when you are transmitting, you can probably can use any port, but the > problem is that usually it make sense to use the same RTP port for both > receive and transmit - in this case if you will use a random RTP port you > will violate the rules. Another dangerous thing is that we don 't know what > assumptions can firewall vendors make, so we can run into trouble with this > also ( if assumption will be made from the 2501 port number). I would > suggest that we will make it clear in the standard that two consequent port > numbers would be used for RTP/RTCP in any case. > > > Anatoli > > > "Paul E. Jones" wrote: > > > Folks, I have a question... I thought this was clear, but perhaps it is not. > Suppose I send an OLC proposing a channel to be opened and I provide my RTCP > port in the mediaControlChannel field. Say, 2501. H.245 states in B.3.1: > > The mediaChannel indicates a transportAddress to be used for the logical > channel. When the transport is unicast, mediaChannel is not present in the > OpenLogicalChannel forwardLogicalChannelParameters, but may be present in > the reverseLogicChannelParameters. > > Is it safe to assume, then, that I will send my media to you from the port > 2500, or am I at liberty to send my RTP data to you using any port I choose? > My understanding was that I was obligated to transmit media from port 2500, > since I indicated that the RTCP port was 2501. Thanks,Paul > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > 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 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

2 1

Re: RTP port for sending media
by Nadathur, Srivathsan G (Srivathsan) 14 Sep '00

14 Sep '00

Also, I remember H.245 spec implying that RTCP is not a mandatory requirement. Could someone clarify. Thanks Srivathsan. -----Original Message----- From: Paul E. Jones [mailto:paulej@packetizer.com] Sent: Tuesday, September 12, 2000 12:20 PM To: Anatoli Levine Cc: h323implementors(a)imtc.org; ITU-SG16(a)mailbag.cps.intel.com Subject: Re: RTP port for sending media Anatoli, et al, I agree that it would be very helpful for NAT devices or other equipment to be able to safely rely on receiving media from the specified RTP port that is one lower than the RTCP port advertised in the original OLC message. I thought that was the expected behavior when using RTP/RTCP, but recent discussions with folks working on SIP is that "no, that's not necessarily true." Apparently, it is believed that a SIP device may send RTP from any port. So, if you have a line like this in the INVITE message: m= to indicate a bi-directional media flow, the RTP address is interpreted only as the "receive" address. But then I questioned, "what about the fact that the associated RTCP port (next odd port) is used for receiving RR packets.. would that not suggest that the RTP port for sending is also the same port specified in this 'm=' line?" The answer was 'no'. So this made me curious about H.323 implementations. Do we need to clarify that the RTP port used to send data associated with the RTCP address in an OLC is the next lower port (even) number, or do we have implementations out there that send RTP traffic from and random port, irrespective of the RTCP port put in the forwardLogicalChannelParameters of the OLC message? If the latter is the case, I think we need to state this clearly, too. Thanks, Paul ----- Original Message ----- From: Anatoli Levine <mailto:alevine@radvision.com> To: Paul E. <mailto:paulej@packetizer.com> Jones Cc: h323implementors(a)imtc.org <mailto:h323implementors@imtc.org> Sent: Tuesday, September 12, 2000 9:37 AM Subject: Re: RTP port for sending media Paul, when you are transmitting, you can probably can use any port, but the problem is that usually it make sense to use the same RTP port for both receive and transmit - in this case if you will use a random RTP port you will violate the rules. Another dangerous thing is that we don 't know what assumptions can firewall vendors make, so we can run into trouble with this also ( if assumption will be made from the 2501 port number). I would suggest that we will make it clear in the standard that two consequent port numbers would be used for RTP/RTCP in any case. Anatoli "Paul E. Jones" wrote: Folks, I have a question... I thought this was clear, but perhaps it is not. Suppose I send an OLC proposing a channel to be opened and I provide my RTCP port in the mediaControlChannel field. Say, 2501. H.245 states in B.3.1: The mediaChannel indicates a transportAddress to be used for the logical channel. When the transport is unicast, mediaChannel is not present in the OpenLogicalChannel forwardLogicalChannelParameters, but may be present in the reverseLogicChannelParameters. Is it safe to assume, then, that I will send my media to you from the port 2500, or am I at liberty to send my RTP data to you using any port I choose? My understanding was that I was obligated to transmit media from port 2500, since I indicated that the RTCP port was 2501. Thanks,Paul ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

2 1

SIP and H.323 Interworking question
by Paul E. Jones 14 Sep '00

14 Sep '00

Folks, I was recently pondering issues related to H.323/SIP interworking-- particularly the handling of media streams. If I understand things correctly, the 'm=' line in the SDP used by SIP indicates only the media address to which RTP packets will be sent. It says nothing about the RTP/RTCP port used for sending media. Those can be another pair of ports, apparently. How, then, can an H.323 IWF send an OLC to an H.323 endpoint? (Let's assume that the IWF does not want to proxy the media-- only handle signaling.) Assume that the IWF has received the INVITE message, containing the RTP address of the reverse channel. It then goes ahead and establishes the call with the H.323 endpoint, starts H.245 and exchanges capability information. Suppose the IWF now wishes to open a channel. Part of the forwardLogicalChannel parameters of the OLC is a required field called "mediaControlChannel". However, this information is not passed in the SDP. Are people assuming, as I had done, that the 'm=' line contained the RTP address for both sending and receiving media? Am I misreading something or is there a real interworking issue here? Thanks, Paul ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

2 2

Re: RTP port for sending media
by Francois Audet 14 Sep '00

14 Sep '00

I am not sure it would help NAT devices. Couldn't a sender "fake" the RTP sender port by inserting another value? More commonly, I would believe that the port would typically be set to "0"? RFC 768 (UDP) says: Source Port is an optional field, when meaningful, it indicates the port of the sending process, and may be assumed to be the port to which a reply should be addressed in the absence of any other information. If not used, a value of zero is inserted. -----Original Message----- From: Paul E. Jones [mailto:paulej@PACKETIZER.COM] Sent: Tuesday, September 12, 2000 9:20 AM To: ITU-SG16(a)MAILBAG.INTEL.COM Subject: Re: RTP port for sending media Anatoli, et al, I agree that it would be very helpful for NAT devices or other equipment to be able to safely rely on receiving media from the specified RTP port that is one lower than the RTCP port advertised in the original OLC message. I thought that was the expected behavior when using RTP/RTCP, but recent discussions with folks working on SIP is that "no, that's not necessarily true." Apparently, it is believed that a SIP device may send RTP from any port. So, if you have a line like this in the INVITE message: m= to indicate a bi-directional media flow, the RTP address is interpreted only as the "receive" address. But then I questioned, "what about the fact that the associated RTCP port (next odd port) is used for receiving RR packets.. would that not suggest that the RTP port for sending is also the same port specified in this 'm=' line?" The answer was 'no'. So this made me curious about H.323 implementations. Do we need to clarify that the RTP port used to send data associated with the RTCP address in an OLC is the next lower port (even) number, or do we have implementations out there that send RTP traffic from and random port, irrespective of the RTCP port put in the forwardLogicalChannelParameters of the OLC message? If the latter is the case, I think we need to state this clearly, too. Thanks, Paul ----- Original Message ----- From: Anatoli <mailto:alevine@radvision.com> Levine To: Paul E. Jones <mailto:paulej@packetizer.com> Cc: h323implementors(a)imtc.org <mailto:h323implementors@imtc.org> Sent: Tuesday, September 12, 2000 9:37 AM Subject: Re: RTP port for sending media Paul, when you are transmitting, you can probably can use any port, but the problem is that usually it make sense to use the same RTP port for both receive and transmit - in this case if you will use a random RTP port you will violate the rules. Another dangerous thing is that we don 't know what assumptions can firewall vendors make, so we can run into trouble with this also ( if assumption will be made from the 2501 port number). I would suggest that we will make it clear in the standard that two consequent port numbers would be used for RTP/RTCP in any case. Anatoli "Paul E. Jones" wrote: Folks, I have a question... I thought this was clear, but perhaps it is not. Suppose I send an OLC proposing a channel to be opened and I provide my RTCP port in the mediaControlChannel field. Say, 2501. H.245 states in B.3.1: The mediaChannel indicates a transportAddress to be used for the logical channel. When the transport is unicast, mediaChannel is not present in the OpenLogicalChannel forwardLogicalChannelParameters, but may be present in the reverseLogicChannelParameters. Is it safe to assume, then, that I will send my media to you from the port 2500, or am I at liberty to send my RTP data to you using any port I choose? My understanding was that I was obligated to transmit media from port 2500, since I indicated that the RTCP port was 2501. Thanks,Paul

1 0

Re: RTP port for sending media
by Paul E. Jones 14 Sep '00

14 Sep '00

Anatoli, et al, I agree that it would be very helpful for NAT devices or other equipment to be able to safely rely on receiving media from the specified RTP port that is one lower than the RTCP port advertised in the original OLC message. I thought that was the expected behavior when using RTP/RTCP, but recent discussions with folks working on SIP is that "no, that's not necessarily true." Apparently, it is believed that a SIP device may send RTP from any port. So, if you have a line like this in the INVITE message: m= to indicate a bi-directional media flow, the RTP address is interpreted only as the "receive" address. But then I questioned, "what about the fact that the associated RTCP port (next odd port) is used for receiving RR packets.. would that not suggest that the RTP port for sending is also the same port specified in this 'm=' line?" The answer was 'no'. So this made me curious about H.323 implementations. Do we need to clarify that the RTP port used to send data associated with the RTCP address in an OLC is the next lower port (even) number, or do we have implementations out there that send RTP traffic from and random port, irrespective of the RTCP port put in the forwardLogicalChannelParameters of the OLC message? If the latter is the case, I think we need to state this clearly, too. Thanks, Paul ----- Original Message ----- From: Anatoli Levine To: Paul E. Jones Cc: h323implementors(a)imtc.org Sent: Tuesday, September 12, 2000 9:37 AM Subject: Re: RTP port for sending media Paul, when you are transmitting, you can probably can use any port, but the problem is that usually it make sense to use the same RTP port for both receive and transmit - in this case if you will use a random RTP port you will violate the rules. Another dangerous thing is that we don 't know what assumptions can firewall vendors make, so we can run into trouble with this also ( if assumption will be made from the 2501 port number). I would suggest that we will make it clear in the standard that two consequent port numbers would be used for RTP/RTCP in any case. Anatoli "Paul E. Jones" wrote: Folks, I have a question... I thought this was clear, but perhaps it is not. Suppose I send an OLC proposing a channel to be opened and I provide my RTCP port in the mediaControlChannel field. Say, 2501. H.245 states in B.3.1: The mediaChannel indicates a transportAddress to be used for the logical channel. When the transport is unicast, mediaChannel is not present in the OpenLogicalChannel forwardLogicalChannelParameters, but may be present in the reverseLogicChannelParameters. Is it safe to assume, then, that I will send my media to you from the port 2500, or am I at liberty to send my RTP data to you using any port I choose? My understanding was that I was obligated to transmit media from port 2500, since I indicated that the RTCP port was 2501. Thanks,Paul

2 2

[H.323 Mobility:] A cleaned up H.323 Annex H draft uploaded
by Jaakko Sundquist 14 Sep '00

14 Sep '00

Hi all, I have uploaded MD-106 to URL: ftp://standard.pictel.com/avc-site/Incoming/Mobility-AHG/Md-106_H323AnnexHDr aft.zip . The document is a cleaned up version of TD-42 of the Portland meeting and contains only editorial changes(as the template used in the draft document so far was, for some reason, a total mess). The only "exeption" to this is the following correction. Section 8.1 of TD-42 included the text: "Reference points A and B are out of the scope of this Annex.", which has been removed and instead section 8.3 now includes the text: "Reference points B, C and D are out of the scope of this Annex (Hinter is included but only as an option in case that utilization of reference point A is not practical).". The reason for this change is that the text in TD-42 is, as I understand from Mr. Rissanen's comments, a typo and should have mentioned reference points B and C instead of A and B. ------------------------------------------------ Jaakko Sundquist * +358 50 3598281 * Audere est Facere! jaakko.sundquist(a)nokia.com * ------------------------------------------------ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

Report of the Portland meeting APC-1949
by Sakae OKUBO 14 Sep '00

14 Sep '00

Dear Q12-14/16 experts, I have belatedly compiled the Portland meeting report APC-1949 and placed it at the /Incoming of the ftp site. http://standard.pictel.com/ftp/avc-site/Incoming/APC-1949.zip This has been edited using TD-34 (general), TD-35 (Q12), TD-35 (Q13) and TD-36 (Q14) and correcting obvious editorial errors. Please review it and return your findings in a week time. Then I will move it to /0008_Por directory with confirmed status. Please provide missing information in the list of participants with respect to yourself or your colleagues. 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 *********************************************************** ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

subscribe
by Baese Gero 13 Sep '00

13 Sep '00

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

Possibilities of URL
by Chip Sharp 13 Sep '00

13 Sep '00

In relation to the current discussion of the H.323 URL. Here is an interesting example of the possibilities of a currently defined fairly simple URL type. http://$urlcalc(about).x42.com/ Sorry for the interruption. Back to the H.323 URL discussion. :-) Chip ------------------------------------------------------------------- Chip Sharp Consulting Engineering Cisco Systems Reality - Love it or Change it. http://www.netaid.org ------------------------------------------------------------------- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

Re: Revised H.323 URL document
by Orit Levin 12 Sep '00

12 Sep '00

Bob! Below is my take on the current situation. The three of us have the following different views on the possible use of the H.323 URL. If I try to map them into the H.323 "classic" picture of EP1---GK1-------GK2---EP2 . The GKs are optional. If exist, they may contain BE as well. I understand the following: Bob:: indirect: EP1---GK1; direct: EP1 --------Zone2 Paul:: indirect: Zone1-------GK2; direct: Zone1------EP2 Orit:: Zone1-------Zone2 (with H.225.0 Q.931, LRQ or Annex G) possible between them for a specific call. We "agree" that all of the scenarios should be allowed. "It seems like" we disagree about the priority/emergency of each of the applications above. Saying that, I don't like very much to define a solution based on the "perceived priority" of the applications. My proposed approach is, above all, guided by the fact, that the DESTINATION is the one to design its URL scheme, implement and, eventually, publish its URL(s). The URL - has a key (I.e. the DNS domain) for IP resolution only - says what is the first H.323 protocol to contact this IP address, all the scenarios above are addressed. If the DNS portion (I.e. "host") is not present, it automatically means, that the local (pre-configured or RAS discovered) gatekeeper will resolve the "user" name (using RAS, Annex G, another DNS lookup, other means). It is an exception, but it is still consistent with the approach above (The local zone is responsible for the URL scheme, it published.) The bottom line: I agree with the last proposal for H.323v4: No parameters at all. The default: H.225.0/Q.931/Setup with its default TCP port. Paul? Best Regards, Orit Levin RADVision Inc. 575 Corporate Drive Suite 420 Mahwah, NJ 07430 Tel: 1 201 529 4300 (230) Fax: 1 201 529 3516 www.radvision.com orit(a)radvision.com -----Original Message----- From: Callaghan, Robert <Robert.Callaghan(a)icn.siemens.com> To: 'Orit Levin' <orit(a)radvision.com> Cc: ITU-SG16(a)mailbag.cps.intel.com <ITU-SG16(a)mailbag.cps.intel.com> Date: Monday, September 11, 2000 1:53 PM Subject: RE: Revised H.323 URL document Orit, Let us try to focus on a few points first: (These are snippets from the thread.) OL: Are you interested in efficiently running H.323 over the Internet? RC: Yes! For clarification, this is the H.323 as defined in H.323v4 and H.225.0v4. For the November decision, there should not be any extensions, implicit or explicit. OL: The picture, in my mind, is different from yours and fits the "traditional" H.323. For every H.323 call, logically there are (at least) two GKs: source and destination. (Physically, both of them are optional, based on the "mode" policy inside the corresponding H.323 zones.) RC: I agree with your model of two endpoint each with an optional GKs based on zone policies. The source and destination policies are independent from each other. I dont know how this is different, as you state. OL: By specifying in H323-URL the "mode" of operation between the source EP and a GK, you propose to use the URL for "publishing" the relations between the EP and "ITS" GK PER DESTINATION! It is, indeed, very different from the H.323 today. Moreover, you implicitly introduce a concept of a "source" GK, being re-defined each time BY THE DESTINATION. (This case may be considered as an additional application for the H.323 URL) RC: I make so such assumption. In the Direct model, I assume that the given address is directly callable. The routing model is not specified nor assumed. If the term Direct is a problem in that the term overlaps with the routing model then the use of Callable would be fine. The use of the DNS service to convert the DNS domain to an IP address is assumed. This is also the only use of the DNS server. No DNS records beyond the A record will be used. If the initial use of the H.323 URL could be limited to this service. RC: The use of the Indirect or non callable form has bothered me in that its use is not clearly defined. My view is that this was a means to access an H.323 repository to obtain the true address. Apparently there are other views. Therefore I suggest that a solution would be to drop this form for now. OL: The natural use of URLs is between the zones/domain. For H.323, it is an OPTION, what kind of address resolution to propose and use. The beauty of the URL approach is that the DESTINATION provides an option to be reached using the DNS lookup, if it chooses so and populates properly the DNS. RC: The may be beautify for some; but it is definitely new. I know of nothing in H.323v4 that describes the procedures and rules for this type of address resolution. This can be discussed as part of Annex O, after the decision on H.323v4. OL: We don't have to agree on the mailing list. We can spend more then one meeting in order to reach "the consensus". In that case, I would support the inclusion of the minimal H323-URL only (without any parameters and without the PORT number) towards the H.323v4. RC: I agree that it is not possible to agree to a complex solution on the mailing list. However, I hope that we can agree to a simple URL without any parameters or port (ouch! J) where this URL is the actual address to be used in a SETUP message. This should not change anything in H.323 including the use of the GK. I hope that this helps. Bob ------------------------------------------------------------------ Robert Callaghan Siemens Enterprise Networks Tel: +1.561.923.1756 Fax: +1.561.923.1403 Email: Robert.Callaghan(a)ICN.Siemens.com ------------------------------------------------------------------

2 1

Re: Revised H.323 URL document
by Callaghan, Robert 11 Sep '00

11 Sep '00

Paul, In my mind, Direct meant callable and Indirect meant not callable. In either case the DNS portion of the URL identified the target entity for the initial contact. I have no problem with the use of a DNS server providing the IP address of this entity through the use of the A record. However, this is the limit to the use of DNS records, at this time. Until the procedures are resolve, there can be no use of service records etc. As to a domain being "administrative" or "DNS" - the DNS portion of the URL has to relate to the DNS domain in that this is the definition of DNS. However, it may be possible to have resolution of the URL addresses be an extension of Annex G so that the information exchange between administrative domains may be used to resolve the address. However, this is future. Bob ------------------------------------------------------------------ Robert Callaghan Siemens Enterprise Networks Tel: +1.561.923.1756 Fax: +1.561.923.1403 Email: Robert.Callaghan(a)ICN.Siemens.com ------------------------------------------------------------------ -----Original Message----- From: Paul E. Jones [mailto:paulej@PACKETIZER.COM] Sent: Sunday, September 10, 2000 12:12 AM To: ITU-SG16(a)mailbag.cps.intel.com Subject: Re: Revised H.323 URL document Bob and Orit, Indeed, it would appear that this "proto" or "mode" parameter is still a bit contentious. Let me make a few comments.. my immediate goal is to see H.323v4 brought to Decision. We can haggle over Annex O (which will contain all of the specific procedural text) later on. I agree with Bob-- we will have a few of these meetings, I am sure. There is nothing in the URL scheme itself that would prevent a Gatekeeper or an endpoint from utilizing DNS. When the mode is specified as "direct", we specified that the hostname resolves has an associated 'A' record in DNS. However, if I give you h323: paulej(a)packetizer.com <mailto:paulej@packetizer.com> , you can't assume that 'packetizer.com' will have an 'A' record-- and if it does, it may not contain H.323 entity (endpoint, GK, or BE). So, in the "indirect" mode (the default), the endpoint must somehow turn this URL into a callable address. Now, the procedure for this may involve DNS or it may not. The text I last sent out suggested that this is the "domain name", but I did not say DNS or "administrative domain name". I can imagine that either may be utilized, but I also prefer that the "domain name" refer to a DNS domain name and would also like to propose that the "domain name" mentioned in this section be qualified with "DNS domain name": that might not sit well-- Bob? How about this: what if I remove the text that says that "indirect" means that "an endpoint shall use a Gatekeeper to resolve the address". Instead, I will say "the mode value indirect indicates that the address does not refer to a callable H.323 entity. The procedure for resolving such an address is for further study." Making this change does not prevent a Gatekeeper from being involved and it also does not prevent an endpoint from doing some type of direct resolution. Perhaps this will get us past this-- we'll debate this when we get to Annex O. Orit, one thing you say over and over again is "direct" and "routed". I never used the word "routed"-- do not mistake "indirect" for "routed". The word "direct" versus "indirect" merely indicated that the entity is callable or not. Perhaps this: in addition to making the above change, we change "mode" to "callable". The URL will then take this form: h323:paulej@packetizer.com;callable=no or h323:paulej@paris.packetizer.com;callable=yes The default would be "callable=no". This equates to the same thing as "mode=direct" and "mode=indirect", but perhaps it's clearer? (Or perhaps not... I personally prefer "mode=[in]direct"). Paul ----- Original Message ----- From: Callaghan, Robert <mailto:Robert.Callaghan@icn.siemens.com> To: 'Orit Levin' <mailto:orit@radvision.com> ; Paul E. <mailto:paul.jones@ties.itu.ch> Jones Cc: Mailing list for parties associated with <mailto:ITU-SG16@mailbag.cps.intel.com> ITU-T Study Group 16 (E-mail) Sent: Friday, September 08, 2000 4:45 PM Subject: RE: Re: Revised H.323 URL document Orit, Based on this email, we have not agreement at all. 1) I am not interest at all in developing an addressing scheme for the sole reason that it mimics the addressing schemes used by SIP. SIP is very oriented towards the concept of domains defined by DNS and a user in that domain. H.323 is oriented towards administration domains defined by one or more gatekeepers and users attached to those gatekeepers. The only commonality is that a gatekeeper can be a server with a name defined by DNS. These distinctions must remain. 2) It is unacceptable to force the implementation of annex G on any endpoint, gatekeeper or administrative domain. Therefore the differentiation between the use of Annex G or the use of LRQ should not known to the originating endpoint. The differentiation should be that this address defines the destination endpoint (direct relationship) or it defines a source for resolving the destination endpoint address (indirect). In my view, in the direct relation a SETUP message is routed towards the entity defined by the DNS where the user portion is resolved. This may be direct routed or gatekeeper routed, it does not matter. The endpoint defined by the DNS may be a gatekeeper or the endpoint itself where the user portion defines one of multiple users on that endpoint. For the indirect relationship, the endpoint must resolve the address of the destination address before sending the SETUP message. Based on H.323 procedures, the endpoint sends ARQ to its GK. How the GK resolves the address is within the capabilities of the GK. It may use Annex G, it this is possible. Or, it may fall back to LRQ to the entity specified by the DNS name. 3) The definition of an H.323 URL cannot be the vehicle to implicitly define new procedures for address resolution. If a new procedure for address resolution is to be defined, it must be explicit, and it must be clear. These requirements have not been realized. I have seen no procedural text that has full agreement. I have seen Annex O as a working document, but this is a year from closure. I expect to have many discussions on this subject in future meetings (note the plural). The H.323 URL we have for November must support the existing H.323 procedures without any implicit extension or modification. I think that Paul's proposal meets the requirements that I have stated. Where does this leave us now? Bob ------------------------------------------------------------------ Robert Callaghan Siemens Enterprise Networks Tel: +1.561.923.1756 Fax: +1.561.923.1403 Email: Robert.Callaghan(a)ICN.Siemens.com ------------------------------------------------------------------ -----Original Message----- From: Orit Levin [mailto:orit@radvision.com] Sent: Friday, September 08, 2000 3:57 PM To: Paul E. Jones; Robert (Bob) Callaghan Subject: Re: Re: Revised H.323 URL document Hello Paul and Bob! I prepared the following "speech" for the mailing list, but it is definitely better to try to understand each other first... --------------------------------------- I hate to disappoint you, but I would strongly disagree with the proposed "mode" terminology. I will try to explain below, why it does not fit the URL concept. 1. The MAIN purpose of URL is to use the Internet DNS Infrastructure for SERVICE+ADDRESS resolution ACROSS the DOMAINS. (The use of the "user-only" URL is [just] a possible additional feature.) 2. The H.323 "direct vs. routed" concept specifies the relations between an End Point and ITS Gatekeeper. It is an local policy issue WITHIN their zone. Today, according to H.323 specification, the real flavor of the operational mode in the DESTINATION zone is UNKNOWN (and irrelevant) to the originator of the call. Not mentioning the future possible GK decomposition!... 3. Following the proposed "mode" terminology, I guess, "routed" would mean "LRQ" or "Access Request" and "direct" would mean "Setup". In reality, the LRQ would lead to the "direct call" and the Setup would lead to the "routed call". And how to distinguish between the all three? 4. The INTER-ZONE communication haven't been solidly defined so far. (LRQ ? Annex G?) The INTER-DOMAIN communication is the subject of H.225.0 Annex G. The URL approach is an OPTION for all of the "intra" and "inter" H.323 Zone and H.323 Domain cases. It may be used as a first lookup, before the LRQ or Annex G are performed. It may also have an overlapping functionality with LRQ and with very specific PARTS of Annex G. The relations between the H.323 URL and H.225.0 "Annex G" are very close to those of the SIP-URL and TRIP in a "SIP system". Both have their uses and complement each other. 5. The proposal is to have a possibility to "publish", using the URL, the first procedure, to be issued towards the destination "domain". By its nature, it is not an issue for standardization. It is a policy of the destination domain, which also is responsible for the URL itself. The first procedure (i.e. the "method") required for establishing of a specific call across domains/zones can be either of the following: - H.225.0 Annex G/AccessRequest - H.225.0/LRQ - H.225.0/CALL SETUP Once, the first message is issued towards the destination (which is a result of DNS lookup using the URL), the rest of the procedures are, indeed, very well defined by H.323 and H.225.0 Annex G all together. Best Regards, Orit Levin RADVision Inc. 575 Corporate Drive Suite 420 Mahwah, NJ 07430 Tel: 1 201 529 4300 (230) Fax: 1 201 529 3516 www.radvision.com <http://www.radvision.com> orit(a)radvision.com <mailto:orit@radvision.com> -----Original Message----- From: Callaghan, Robert < Robert.Callaghan(a)ICN.SIEMENS.COM <mailto:Robert.Callaghan@ICN.SIEMENS.COM> > To: ITU-SG16(a)MAILBAG.INTEL.COM <mailto:ITU-SG16@MAILBAG.INTEL.COM> < ITU-SG16(a)MAILBAG.INTEL.COM <mailto:ITU-SG16@MAILBAG.INTEL.COM> > Date: Thursday, September 07, 2000 8:17 AM Subject: Re: Revised H.323 URL document Paul, I definitely like "mode" as a replacement for "protocol." It clearly represents the required procedure without over doing details. I think that we got it. Bob ------------------------------------------------------------------ Robert Callaghan Siemens Enterprise Networks Tel: +1.561.923.1756 Fax: +1.561.923.1403 Email: Robert.Callaghan(a)ICN.Siemens.com ------------------------------------------------------------------ -----Original Message----- From: Paul E. Jones [mailto:paulej@acm.org] Sent: Wednesday, September 06, 2000 11:20 PM To: Robert Callaghan; Orit Levin; ITU-SG16(a)mailbag.cps.intel.com Subject: Revised H.323 URL document Orit, Bob, et al, Attached is the revised section covering the syntax of the H.323 URL. This (I hope) includes all of the changes we have discussed so far. I am not sure that we settled on the "mode" parameter, but I made the change here in this document-- feedback is welcome. Best Regards, Paul

2 1

Re: Revised H.323 URL document
by Callaghan, Robert 11 Sep '00

11 Sep '00

Orit, You still do not hear what I am saying. So I repeat, in order to have something for November; * The H.323 URL is used as an H.323 alias. The means that it has all of the properties of an H.323 alias, and nothing beyond these properties. To expand this, this alias is used in ARQs LRQs, SETUP, etc. messages exactly the same as any other alias. It is not used for any purpose beyond that for which all other aliases are used in H.323. * There are no new functions, features, or capabilities added to H.323v4 based on the addition of the H.323 URL as a new alias type. * Any other uses for the H.323 URL are for future study. Can we agree to these statements for the H.323 URL in H.323v4? If we agree on this, can the URL format be formulated to support these statements? If the URL can be formulated, can it be submitted and approved by IETF before November? Bob ------------------------------------------------------------------ Robert Callaghan Siemens Enterprise Networks Tel: +1.561.923.1756 Fax: +1.561.923.1403 Email: Robert.Callaghan(a)ICN.Siemens.com ------------------------------------------------------------------ -----Original Message----- From: Orit Levin [mailto:orit@radvision.com] Sent: Monday, September 11, 2000 3:01 PM To: Callaghan, Robert Cc: ITU-SG16(a)mailbag.cps.intel.com Subject: Re: Revised H.323 URL document Bob! Below is my take on the current situation. The three of us have the following different views on the possible use of the H.323 URL. If I try to map them into the H.323 "classic" picture of EP1---GK1-------GK2---EP2 . The GKs are optional. If exist, they may contain BE as well. I understand the following: Bob:: indirect: EP1---GK1; direct: EP1 --------Zone2 Paul:: indirect: Zone1-------GK2; direct: Zone1------EP2 Orit:: Zone1-------Zone2 (with H.225.0 Q.931, LRQ or Annex G) possible between them for a specific call. We "agree" that all of the scenarios should be allowed. "It seems like" we disagree about the priority/emergency of each of the applications above. Saying that, I don't like very much to define a solution based on the "perceived priority" of the applications. My proposed approach is, above all, guided by the fact, that the DESTINATION is the one to design its URL scheme, implement and, eventually, publish its URL(s). The URL - has a key (I.e. the DNS domain) for IP resolution only - says what is the first H.323 protocol to contact this IP address, all the scenarios above are addressed. If the DNS portion (I.e. "host") is not present, it automatically means, that the local (pre-configured or RAS discovered) gatekeeper will resolve the "user" name (using RAS, Annex G, another DNS lookup, other means). It is an exception, but it is still consistent with the approach above (The local zone is responsible for the URL scheme, it published.) The bottom line: I agree with the last proposal for H.323v4: No parameters at all. The default: H.225.0/Q.931/Setup with its default TCP port. Paul? Best Regards, Orit Levin RADVision Inc. 575 Corporate Drive Suite 420 Mahwah, NJ 07430 Tel: 1 201 529 4300 (230) Fax: 1 201 529 3516 www.radvision.com <http://www.radvision.com> orit(a)radvision.com <mailto:orit@radvision.com> -----Original Message----- From: Callaghan, Robert < Robert.Callaghan(a)icn.siemens.com <mailto:Robert.Callaghan@icn.siemens.com> > To: 'Orit Levin' < orit(a)radvision.com <mailto:orit@radvision.com> > Cc: ITU-SG16(a)mailbag.cps.intel.com <mailto:ITU-SG16@mailbag.cps.intel.com> < ITU-SG16(a)mailbag.cps.intel.com <mailto:ITU-SG16@mailbag.cps.intel.com> > Date: Monday, September 11, 2000 1:53 PM Subject: RE: Revised H.323 URL document Orit, Let us try to focus on a few points first: (These are snippets from the thread.) OL: Are you interested in efficiently running H.323 over the Internet? RC: Yes! For clarification, this is the H.323 as defined in H.323v4 and H.225.0v4. For the November decision, there should not be any extensions, implicit or explicit. OL: The picture, in my mind, is different from yours and fits the "traditional" H.323. For every H.323 call, logically there are (at least) two GKs: source and destination. (Physically, both of them are optional, based on the "mode" policy inside the corresponding H.323 zones.) RC: I agree with your model of two endpoint each with an optional GKs based on zone policies. The source and destination policies are independent from each other. I don't know how this is different, as you state. OL: By specifying in H323-URL the "mode" of operation between the source EP and a GK, you propose to use the URL for "publishing" the relations between the EP and "ITS" GK PER DESTINATION! It is, indeed, very different from the H.323 today. Moreover, you implicitly introduce a concept of a "source" GK, being re-defined each time BY THE DESTINATION. (This case may be considered as an additional application for the H.323 URL) RC: I make so such assumption. In the "Direct" model, I assume that the given address is directly callable. The routing model is not specified nor assumed. If the term "Direct" is a problem in that the term overlaps with the routing model then the use of "Callable" would be fine. The use of the DNS service to convert the DNS domain to an IP address is assumed. This is also the only use of the DNS server. No DNS records beyond the "A" record will be used. If the initial use of the H.323 URL could be limited to this service. RC: The use of the "Indirect" or "non callable" form has bothered me in that its use is not clearly defined. My view is that this was a means to access an H.323 repository to obtain the true address. Apparently there are other views. Therefore I suggest that a solution would be to drop this form for now. OL: The natural use of URLs is between the zones/domain. For H.323, it is an OPTION, what kind of address resolution to propose and use. The beauty of the URL approach is that the DESTINATION provides an option to be reached using the DNS lookup, if it chooses so and populates properly the DNS. RC: The may be beautify for some; but it is definitely new. I know of nothing in H.323v4 that describes the procedures and rules for this type of address resolution. This can be discussed as part of Annex O, after the decision on H.323v4. OL: We don't have to agree on the mailing list. We can spend more then one meeting in order to reach "the consensus". In that case, I would support the inclusion of the minimal H323-URL only (without any parameters and without the PORT number) towards the H.323v4. RC: I agree that it is not possible to agree to a complex solution on the mailing list. However, I hope that we can agree to a simple URL without any parameters or port (ouch! :-)) where this URL is the actual address to be used in a SETUP message. This should not change anything in H.323 including the use of the GK. I hope that this helps. Bob ------------------------------------------------------------------ Robert Callaghan Siemens Enterprise Networks Tel: +1.561.923.1756 Fax: +1.561.923.1403 Email: Robert.Callaghan(a)ICN.Siemens.com ------------------------------------------------------------------

2 1

Re: Revised H.323 URL document
by Callaghan, Robert 11 Sep '00

11 Sep '00

Orit, Let us try to focus on a few points first: (These are snippets from the thread.) OL: Are you interested in efficiently running H.323 over the Internet? RC: Yes! For clarification, this is the H.323 as defined in H.323v4 and H.225.0v4. For the November decision, there should not be any extensions, implicit or explicit. OL: The picture, in my mind, is different from yours and fits the "traditional" H.323. For every H.323 call, logically there are (at least) two GKs: source and destination. (Physically, both of them are optional, based on the "mode" policy inside the corresponding H.323 zones.) RC: I agree with your model of two endpoint each with an optional GKs based on zone policies. The source and destination policies are independent from each other. I don't know how this is different, as you state. OL: By specifying in H323-URL the "mode" of operation between the source EP and a GK, you propose to use the URL for "publishing" the relations between the EP and "ITS" GK PER DESTINATION! It is, indeed, very different from the H.323 today. Moreover, you implicitly introduce a concept of a "source" GK, being re-defined each time BY THE DESTINATION. (This case may be considered as an additional application for the H.323 URL) RC: I make so such assumption. In the "Direct" model, I assume that the given address is directly callable. The routing model is not specified nor assumed. If the term "Direct" is a problem in that the term overlaps with the routing model then the use of "Callable" would be fine. The use of the DNS service to convert the DNS domain to an IP address is assumed. This is also the only use of the DNS server. No DNS records beyond the "A" record will be used. If the initial use of the H.323 URL could be limited to this service. RC: The use of the "Indirect" or "non callable" form has bothered me in that its use is not clearly defined. My view is that this was a means to access an H.323 repository to obtain the true address. Apparently there are other views. Therefore I suggest that a solution would be to drop this form for now. OL: The natural use of URLs is between the zones/domain. For H.323, it is an OPTION, what kind of address resolution to propose and use. The beauty of the URL approach is that the DESTINATION provides an option to be reached using the DNS lookup, if it chooses so and populates properly the DNS. RC: The may be beautify for some; but it is definitely new. I know of nothing in H.323v4 that describes the procedures and rules for this type of address resolution. This can be discussed as part of Annex O, after the decision on H.323v4. OL: We don't have to agree on the mailing list. We can spend more then one meeting in order to reach "the consensus". In that case, I would support the inclusion of the minimal H323-URL only (without any parameters and without the PORT number) towards the H.323v4. RC: I agree that it is not possible to agree to a complex solution on the mailing list. However, I hope that we can agree to a simple URL without any parameters or port (ouch! :-)) where this URL is the actual address to be used in a SETUP message. This should not change anything in H.323 including the use of the GK. I hope that this helps. Bob ------------------------------------------------------------------ Robert Callaghan Siemens Enterprise Networks Tel: +1.561.923.1756 Fax: +1.561.923.1403 Email: Robert.Callaghan(a)ICN.Siemens.com ------------------------------------------------------------------

1 0

RE: Re: Revised H.323 URL document
by Callaghan, Robert 10 Sep '00

10 Sep '00

Orit, Based on this email, we have not agreement at all. 1) I am not interest at all in developing an addressing scheme for the sole reason that it mimics the addressing schemes used by SIP. SIP is very oriented towards the concept of domains defined by DNS and a user in that domain. H.323 is oriented towards administration domains defined by one or more gatekeepers and users attached to those gatekeepers. The only commonality is that a gatekeeper can be a server with a name defined by DNS. These distinctions must remain. 2) It is unacceptable to force the implementation of annex G on any endpoint, gatekeeper or administrative domain. Therefore the differentiation between the use of Annex G or the use of LRQ should not known to the originating endpoint. The differentiation should be that this address defines the destination endpoint (direct relationship) or it defines a source for resolving the destination endpoint address (indirect). In my view, in the direct relation a SETUP message is routed towards the entity defined by the DNS where the user portion is resolved. This may be direct routed or gatekeeper routed, it does not matter. The endpoint defined by the DNS may be a gatekeeper or the endpoint itself where the user portion defines one of multiple users on that endpoint. For the indirect relationship, the endpoint must resolve the address of the destination address before sending the SETUP message. Based on H.323 procedures, the endpoint sends ARQ to its GK. How the GK resolves the address is within the capabilities of the GK. It may use Annex G, it this is possible. Or, it may fall back to LRQ to the entity specified by the DNS name. 3) The definition of an H.323 URL cannot be the vehicle to implicitly define new procedures for address resolution. If a new procedure for address resolution is to be defined, it must be explicit, and it must be clear. These requirements have not been realized. I have seen no procedural text that has full agreement. I have seen Annex O as a working document, but this is a year from closure. I expect to have many discussions on this subject in future meetings (note the plural). The H.323 URL we have for November must support the existing H.323 procedures without any implicit extension or modification. I think that Paul's proposal meets the requirements that I have stated. Where does this leave us now? Bob ------------------------------------------------------------------ Robert Callaghan Siemens Enterprise Networks Tel: +1.561.923.1756 Fax: +1.561.923.1403 Email: Robert.Callaghan(a)ICN.Siemens.com ------------------------------------------------------------------ -----Original Message----- From: Orit Levin [mailto:orit@radvision.com] Sent: Friday, September 08, 2000 3:57 PM To: Paul E. Jones; Robert (Bob) Callaghan Subject: Re: Re: Revised H.323 URL document Hello Paul and Bob! I prepared the following "speech" for the mailing list, but it is definitely better to try to understand each other first... --------------------------------------- I hate to disappoint you, but I would strongly disagree with the proposed "mode" terminology. I will try to explain below, why it does not fit the URL concept. 1. The MAIN purpose of URL is to use the Internet DNS Infrastructure for SERVICE+ADDRESS resolution ACROSS the DOMAINS. (The use of the "user-only" URL is [just] a possible additional feature.) 2. The H.323 "direct vs. routed" concept specifies the relations between an End Point and ITS Gatekeeper. It is an local policy issue WITHIN their zone. Today, according to H.323 specification, the real flavor of the operational mode in the DESTINATION zone is UNKNOWN (and irrelevant) to the originator of the call. Not mentioning the future possible GK decomposition!... 3. Following the proposed "mode" terminology, I guess, "routed" would mean "LRQ" or "Access Request" and "direct" would mean "Setup". In reality, the LRQ would lead to the "direct call" and the Setup would lead to the "routed call". And how to distinguish between the all three? 4. The INTER-ZONE communication haven't been solidly defined so far. (LRQ ? Annex G?) The INTER-DOMAIN communication is the subject of H.225.0 Annex G. The URL approach is an OPTION for all of the "intra" and "inter" H.323 Zone and H.323 Domain cases. It may be used as a first lookup, before the LRQ or Annex G are performed. It may also have an overlapping functionality with LRQ and with very specific PARTS of Annex G. The relations between the H.323 URL and H.225.0 "Annex G" are very close to those of the SIP-URL and TRIP in a "SIP system". Both have their uses and complement each other. 5. The proposal is to have a possibility to "publish", using the URL, the first procedure, to be issued towards the destination "domain". By its nature, it is not an issue for standardization. It is a policy of the destination domain, which also is responsible for the URL itself. The first procedure (i.e. the "method") required for establishing of a specific call across domains/zones can be either of the following: - H.225.0 Annex G/AccessRequest - H.225.0/LRQ - H.225.0/CALL SETUP Once, the first message is issued towards the destination (which is a result of DNS lookup using the URL), the rest of the procedures are, indeed, very well defined by H.323 and H.225.0 Annex G all together. Best Regards, Orit Levin RADVision Inc. 575 Corporate Drive Suite 420 Mahwah, NJ 07430 Tel: 1 201 529 4300 (230) Fax: 1 201 529 3516 www.radvision.com <http://www.radvision.com> orit(a)radvision.com <mailto:orit@radvision.com> -----Original Message----- From: Callaghan, Robert < Robert.Callaghan(a)ICN.SIEMENS.COM <mailto:Robert.Callaghan@ICN.SIEMENS.COM> > To: ITU-SG16(a)MAILBAG.INTEL.COM <mailto:ITU-SG16@MAILBAG.INTEL.COM> < ITU-SG16(a)MAILBAG.INTEL.COM <mailto:ITU-SG16@MAILBAG.INTEL.COM> > Date: Thursday, September 07, 2000 8:17 AM Subject: Re: Revised H.323 URL document Paul, I definitely like "mode" as a replacement for "protocol." It clearly represents the required procedure without over doing details. I think that we got it. Bob ------------------------------------------------------------------ Robert Callaghan Siemens Enterprise Networks Tel: +1.561.923.1756 Fax: +1.561.923.1403 Email: Robert.Callaghan(a)ICN.Siemens.com ------------------------------------------------------------------ -----Original Message----- From: Paul E. Jones [mailto:paulej@acm.org] Sent: Wednesday, September 06, 2000 11:20 PM To: Robert Callaghan; Orit Levin; ITU-SG16(a)mailbag.cps.intel.com Subject: Revised H.323 URL document Orit, Bob, et al, Attached is the revised section covering the syntax of the H.323 URL. This (I hope) includes all of the changes we have discussed so far. I am not sure that we settled on the "mode" parameter, but I made the change here in this document-- feedback is welcome. Best Regards, Paul

2 1

Re: Enforcing symmetric operation in the context of slow start fo r H. 323v4
by Roni Even 08 Sep '00

08 Sep '00

Hi, I think the issue is very important, there is no clear way to achieve symmetric operation today. In H.323 it states that if a terminal supports H.263 CIF it implies that it support H.261 CIF. On the other hand it states that a terminal can use the receive capabilities to signal which codec it supports, it is not clear if for example a terminal signal that it can receive H.263 CIF, if the transmitter can send H.261 CIF since it is implied but is less preferable, or does it mean that it can only receive H.263 CIF. I think that we can use this change also to make the text correct at least for the symmetric mode. It should state that these are the modes that the terminal can do in symmetric mode and not the implied ones. Roni Even -----Original Message----- From: Mike Nilsson [mailto:mike.nilsson@BT.COM] Sent: Thursday, September 07, 2000 11:47 AM To: ITU-SG16(a)MAILBAG.INTEL.COM Subject: Enforcing symmetric operation in the context of slow start for H. 323v4 At the Portland rapporteur's meeting of Q12-14, document APC-1881, 'Enforcing symmetric operation in the context of slow start for H.323v4', was discussed. The outcome of the discussion, as described in the meeting report, is: This was accepted for the H.323 IG and also H.323 V4. It was agreed that this was meritorius, but that some further discussion was needed. See TD-47. The agreement is that APC-1881 is adopted for changes to H.323 V4, and TD-47 for H.245 V7, with the redefinition of the receiveAndTransmitt capability being the preferred approach. It was noted that the rejectReason needs to be mentioned in TD-47. Text will also be added to note that the procedures of TD-47 only apply if the slave has detected a conflict. All are urged to look very closely at this, and to consider if there are any issues with this. If any are found, we will make changes in November. The editor will post this discussion on the mailing list to ensure broad discussion. The purpose of this mail is simply to do as the meeting report stated, and highlight the issue and to try to get broad agreement on the proposed solution. As far as H.245 is concerned the proposed solution is to include text from TD-47a that is labelled as 'Proposal for immediate action' and the first option (redefinition of the receiveAndTransmitt capability) from the section labelled 'Longer term options'. The documents are available at: ftp://standard.pictel.com/avc-site/0008_Por/APC-1881.zip ftp://standard.pictel.com/avc-site/0008_Por/TD-47a.zip Best regards Mike Nilsson -------------------- Mike Nilsson Multimedia Applications B81 Room 102 pp14 BT Advanced Communications Technology Centre Adastral Park, Martlesham Heath, Ipswich, IP5 3RE, UK Tel: +44 1473 645413 Mobile: +44 7808 635412 Fax: +44 1473 646589 Email: mike.nilsson(a)bt.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 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

4 3

Re: Re: Revised H.323 URL document
by Orit Levin 08 Sep '00

08 Sep '00

Hello Paul and Bob! I prepared the following "speech" for the mailing list, but it is definitely better to try to understand each other first... --------------------------------------- I hate to disappoint you, but I would strongly disagree with the proposed "mode" terminology. I will try to explain below, why it does not fit the URL concept. 1. The MAIN purpose of URL is to use the Internet DNS Infrastructure for SERVICE+ADDRESS resolution ACROSS the DOMAINS. (The use of the "user-only" URL is [just] a possible additional feature.) 2. The H.323 "direct vs. routed" concept specifies the relations between an End Point and ITS Gatekeeper. It is an local policy issue WITHIN their zone. Today, according to H.323 specification, the real flavor of the operational mode in the DESTINATION zone is UNKNOWN (and irrelevant) to the originator of the call. Not mentioning the future possible GK decomposition!... 3. Following the proposed "mode" terminology, I guess, "routed" would mean "LRQ" or "Access Request" and "direct" would mean "Setup". In reality, the LRQ would lead to the "direct call" and the Setup would lead to the "routed call". And how to distinguish between the all three? 4. The INTER-ZONE communication haven't been solidly defined so far. (LRQ ? Annex G?) The INTER-DOMAIN communication is the subject of H.225.0 Annex G. The URL approach is an OPTION for all of the "intra" and "inter" H.323 Zone and H.323 Domain cases. It may be used as a first lookup, before the LRQ or Annex G are performed. It may also have an overlapping functionality with LRQ and with very specific PARTS of Annex G. The relations between the H.323 URL and H.225.0 "Annex G" are very close to those of the SIP-URL and TRIP in a "SIP system". Both have their uses and complement each other. 5. The proposal is to have a possibility to "publish", using the URL, the first procedure, to be issued towards the destination "domain". By its nature, it is not an issue for standardization. It is a policy of the destination domain, which also is responsible for the URL itself. The first procedure (i.e. the "method") required for establishing of a specific call across domains/zones can be either of the following: - H.225.0 Annex G/AccessRequest - H.225.0/LRQ - H.225.0/CALL SETUP Once, the first message is issued towards the destination (which is a result of DNS lookup using the URL), the rest of the procedures are, indeed, very well defined by H.323 and H.225.0 Annex G all together. Best Regards, Orit Levin RADVision Inc. 575 Corporate Drive Suite 420 Mahwah, NJ 07430 Tel: 1 201 529 4300 (230) Fax: 1 201 529 3516 www.radvision.com orit(a)radvision.com -----Original Message----- From: Callaghan, Robert <Robert.Callaghan(a)ICN.SIEMENS.COM> To: ITU-SG16(a)MAILBAG.INTEL.COM <ITU-SG16(a)MAILBAG.INTEL.COM> Date: Thursday, September 07, 2000 8:17 AM Subject: Re: Revised H.323 URL document Paul, I definitely like mode as a replacement for protocol. It clearly represents the required procedure without over doing details. I think that we got it. Bob ------------------------------------------------------------------ Robert Callaghan Siemens Enterprise Networks Tel: +1.561.923.1756 Fax: +1.561.923.1403 Email: Robert.Callaghan(a)ICN.Siemens.com ------------------------------------------------------------------ -----Original Message----- From: Paul E. Jones [mailto:paulej@acm.org] Sent: Wednesday, September 06, 2000 11:20 PM To: Robert Callaghan; Orit Levin; ITU-SG16(a)mailbag.cps.intel.com Subject: Revised H.323 URL document Orit, Bob, et al, Attached is the revised section covering the syntax of the H.323 URL. This (I hope) includes all of the changes we have discussed so far. I am not sure that we settled on the "mode" parameter, but I made the change here in this document-- feedback is welcome. Best Regards, Paul

1 0

Re: Enforcing symmetric operation in the context of slow start fo r H. 323v4
by Danail Kirov 08 Sep '00

08 Sep '00

Since the proposed procedure simply defines implementation details at application level and redifines the meaning of caps which already exist in H.323v2, there is nothing that would prevent an H.323v2 compliant endpoint to make use of this procedure for enforcing symmetric operation. Is it safe to recommend this procedure as the prefered approach for H.323v2 endpoints as well? Danail Kirov Vertical Networks -----Original Message----- From: mike.nilsson(a)bt.com [mailto:mike.nilsson@bt.com] Sent: Thursday, September 07, 2000 2:47 AM To: itu-sg16(a)mailbag.cps.intel.com; h323implementors(a)imtc.org Subject: Enforcing symmetric operation in the context of slow start for H. 323v4 At the Portland rapporteur's meeting of Q12-14, document APC-1881, 'Enforcing symmetric operation in the context of slow start for H.323v4', was discussed. The outcome of the discussion, as described in the meeting report, is: This was accepted for the H.323 IG and also H.323 V4. It was agreed that this was meritorius, but that some further discussion was needed. See TD-47. The agreement is that APC-1881 is adopted for changes to H.323 V4, and TD-47 for H.245 V7, with the redefinition of the receiveAndTransmitt capability being the preferred approach. It was noted that the rejectReason needs to be mentioned in TD-47. Text will also be added to note that the procedures of TD-47 only apply if the slave has detected a conflict. All are urged to look very closely at this, and to consider if there are any issues with this. If any are found, we will make changes in November. The editor will post this discussion on the mailing list to ensure broad discussion. The purpose of this mail is simply to do as the meeting report stated, and highlight the issue and to try to get broad agreement on the proposed solution. As far as H.245 is concerned the proposed solution is to include text from TD-47a that is labelled as 'Proposal for immediate action' and the first option (redefinition of the receiveAndTransmitt capability) from the section labelled 'Longer term options'. The documents are available at: ftp://standard.pictel.com/avc-site/0008_Por/APC-1881.zip ftp://standard.pictel.com/avc-site/0008_Por/TD-47a.zip Best regards Mike Nilsson -------------------- Mike Nilsson Multimedia Applications B81 Room 102 pp14 BT Advanced Communications Technology Centre Adastral Park, Martlesham Heath, Ipswich, IP5 3RE, UK Tel: +44 1473 645413 Mobile: +44 7808 635412 Fax: +44 1473 646589 Email: mike.nilsson(a)bt.com --------------------------------------------------------------------------- ------------------------------ Please send E-mail to contact(a)imtc.org <mailto:contact@imtc.org> to subscribe or unsubscribe from this list ------------------------------ --------------------------------------------------------------------------- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

2 1

Re: [H.323 Mobility:] H.323 Annex H status check
by Roy, Radhika R, ALCOO 08 Sep '00

08 Sep '00

Hi, Everyone: The draft does not contain the basic part: Extensions of H.323 (e.g., H.225.0 messages). Contributions are there (e.g., D.354 of SG16 Feb'00, Geneva - reproduced as TD-31 in Portland [August 21-15, 2000]). GRQ messages need to be removed to the base spec of H.323 because there is nothing specific to be done with mobility. If it is used in the context of mobility, the issues related to mobile need to be pointed out so that contributions can be brought to address those issues. Contributions are there to note the issues. The another suggestion is to make two parts of the Annex: 1. Basic extension of H.323 (H.225.0, H.245: Terminals, GKs/BEs, GWs) and 2. Back-end services related to Mobility (or value-added services related mobility)containing VLF and HLF. Part 2 clearly does not have to be specific to H.323. It is a general service related to mobility. Every application that needs mobility may like to use these services. This will be addressed in the light of the all mobile applications of all questions of all SGs of the ITU-T. So, it is out-of-scope of Q.13/16 because Q.13/16 alone cannot makes this decision. Please note that Security (AuF) is also needed for the fixed users. So, this is a generic service that needs to be developed for both fixed and mobile users. So, it also belongs to the base H.323 spec. That is, any specification related to AuF should be moved to the base H.323 spec as well because it belong to both and the standard should be developed accordingly. For rapid determination, I would suggest to address part 1 only in the first phase. More specific technical comments will be given for each point once the primary objectives are clarified. Best regards, Radhika R. Roy AT&T -----Original Message----- From: Jaakko Sundquist [mailto:jaakko.sundquist@NOKIA.COM] Sent: Friday, September 08, 2000 7:54 AM To: ITU-SG16(a)MAILBAG.INTEL.COM Subject: [H.323 Mobility:] H.323 Annex H status check Hi all, I'll try to gather my thoughts of the situation of the H.323 Annex H work after the Portland meeting in this mail. This mail will not handle the issues about the "mandate" of the annex raised by Mr. Roy, but I will take part in that discussion in separate postings. The draft annex produced as the result of the discussions you had in Portland is TD-42 (not TD-42a as I may have stated earlier). I will produce a cleaned up version of that draft early next week (this new version will only have editorial changes compared to TD-42). In the following I list issues that need to be addressed in the future work and discussions. The list is based on the ad hoc group meeting minutes that I received from Mr. Rissanen (I assume that these are made by Mr. Korpi) and on the discussions I have had with Mr. Rissanen. The list is not in any particular order. - Chapter 2, especially concerning Figure 1, should be clarified. I understand that Mr. Aronson will contribute a clarified version of the figure and accompanying text. - Terms, abbreviations and definitions should be re-examined. This work shall be done by the editor with the help of other representatives. Especially the following issues should be kept in mind: - Definition of the H.323 Mobile User should be expanded. - Definition of the Service Provider should be rewritten. - Some representatives were not happy about the current definitions for the Administrative Domains (Home, Visited, etc.). - The terminology of the annex should be aligned with the terminology used in 3G. - Chapter 7 -> Normative text should be produced out of the current text. Editor's note: Currently this chapter is meant to handle the functional REQUIREMENTS for the annex, not normative specifications. Normative text will be produced when these issues are discussed and worked on. Furthermore, I think this chapter could evolve as being the normative text defining e.g. the formats of the identifiers. - New sub-section 7.1.2: "Procedures Required for Provisioning Mobile H.323 Service". If this section is to be added, contributions from the representatives are required (quite fast), otherwise I'm on the opinion that this sub-section should be dropped from the document intended for determination in November. Also, the editor does not have a very clear picture of what issues this sub-section is going to handle, so some clarifications would be nice. - Current draft assumes the GK-routed call model -> Contributions for direct call model are invited. - BEs will be utilized with information flows between different administrative domains. - Some of the information flows in some interfaces should be marked as optional. Also related to this, I think it would be important to decide on which interfaces do we concentrate in the first version of the annex. E.g. reference points K, L and J do not seem to be of the greatest importance, but we could assume that the AuF is always co-located with some other entity and thus leave the interfaces unspecified. I will make a proposal about the this issue in the following week. - The security issues of this annex will be handled in H.235 Annex G. The contents of APC-1930 will be the first "draft" of this annex. The work on H.235 Annex G will, of course, require the help of the mobility group in the form of contributions. I.e., you should still consider the security issues, when making a contribution for the H.323 Annex H, these issues will then be reflected in H.235 Annex G. The editor of H.235 (Mr. Euchner) has kindly offered his help on the security issues. - The cases of a non-mobile User/Terminal calling a mobile User/Terminal (or vice versa) should be addressed in the annex (some of the needed changes are incorporated already in TD-42). - The work on the information flows should continue as fast as possible. Also other protocols than the H.225 Annex G should be examined (e.g. IETF's Mobile IP, etc.). Contributions are invited. As I said this mail tries to capture my understanding of the H.323 Annex H situation after the Portland meeting. If you think I have missed something important or am deadly wrong about something or you have some other comments/questions, please send a response to this mail to the list. Have a nice, relaxing weekend, everyone! ------------------------------------------------ Jaakko Sundquist * +358 50 3598281 * Audere est Facere! jaakko.sundquist(a)nokia.com * ------------------------------------------------ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 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

need help:some questions about SessionID
by Wu Yongming 08 Sep '00

08 Sep '00

hi,all experts i am new to H323.i have difficulty in understanding SessionID,i have refered to many readings. here are some questions: 1,according to H245,SessionID is a unique RTP or T120 session identifier in the conference. does it mean each sessionID is unique in the conference. 2,i assume seesionID is unique,H245 also says audio session number is 1,video session number is 2, so in a multipoint conference,are all of audio session numbers equal to 1? if so,the conclusion 1 is not right. 3,are the session number 1,2,3 implied assigned by Master? 4,if i leave the sessionID blank,will it be a serious error? thank you advanced! ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

[H.323 Mobility:] H.323 Annex H status check
by Jaakko Sundquist 08 Sep '00

08 Sep '00

Hi all, I'll try to gather my thoughts of the situation of the H.323 Annex H work after the Portland meeting in this mail. This mail will not handle the issues about the "mandate" of the annex raised by Mr. Roy, but I will take part in that discussion in separate postings. The draft annex produced as the result of the discussions you had in Portland is TD-42 (not TD-42a as I may have stated earlier). I will produce a cleaned up version of that draft early next week (this new version will only have editorial changes compared to TD-42). In the following I list issues that need to be addressed in the future work and discussions. The list is based on the ad hoc group meeting minutes that I received from Mr. Rissanen (I assume that these are made by Mr. Korpi) and on the discussions I have had with Mr. Rissanen. The list is not in any particular order. - Chapter 2, especially concerning Figure 1, should be clarified. I understand that Mr. Aronson will contribute a clarified version of the figure and accompanying text. - Terms, abbreviations and definitions should be re-examined. This work shall be done by the editor with the help of other representatives. Especially the following issues should be kept in mind: - Definition of the H.323 Mobile User should be expanded. - Definition of the Service Provider should be rewritten. - Some representatives were not happy about the current definitions for the Administrative Domains (Home, Visited, etc.). - The terminology of the annex should be aligned with the terminology used in 3G. - Chapter 7 -> Normative text should be produced out of the current text. Editor's note: Currently this chapter is meant to handle the functional REQUIREMENTS for the annex, not normative specifications. Normative text will be produced when these issues are discussed and worked on. Furthermore, I think this chapter could evolve as being the normative text defining e.g. the formats of the identifiers. - New sub-section 7.1.2: "Procedures Required for Provisioning Mobile H.323 Service". If this section is to be added, contributions from the representatives are required (quite fast), otherwise I'm on the opinion that this sub-section should be dropped from the document intended for determination in November. Also, the editor does not have a very clear picture of what issues this sub-section is going to handle, so some clarifications would be nice. - Current draft assumes the GK-routed call model -> Contributions for direct call model are invited. - BEs will be utilized with information flows between different administrative domains. - Some of the information flows in some interfaces should be marked as optional. Also related to this, I think it would be important to decide on which interfaces do we concentrate in the first version of the annex. E.g. reference points K, L and J do not seem to be of the greatest importance, but we could assume that the AuF is always co-located with some other entity and thus leave the interfaces unspecified. I will make a proposal about the this issue in the following week. - The security issues of this annex will be handled in H.235 Annex G. The contents of APC-1930 will be the first "draft" of this annex. The work on H.235 Annex G will, of course, require the help of the mobility group in the form of contributions. I.e., you should still consider the security issues, when making a contribution for the H.323 Annex H, these issues will then be reflected in H.235 Annex G. The editor of H.235 (Mr. Euchner) has kindly offered his help on the security issues. - The cases of a non-mobile User/Terminal calling a mobile User/Terminal (or vice versa) should be addressed in the annex (some of the needed changes are incorporated already in TD-42). - The work on the information flows should continue as fast as possible. Also other protocols than the H.225 Annex G should be examined (e.g. IETF's Mobile IP, etc.). Contributions are invited. As I said this mail tries to capture my understanding of the H.323 Annex H situation after the Portland meeting. If you think I have missed something important or am deadly wrong about something or you have some other comments/questions, please send a response to this mail to the list. Have a nice, relaxing weekend, everyone! ------------------------------------------------ Jaakko Sundquist * +358 50 3598281 * Audere est Facere! jaakko.sundquist(a)nokia.com * ------------------------------------------------ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

Draft H.245 Rapporteur's TD for H.245V7
by Mike Nilsson 08 Sep '00

08 Sep '00

Please find attached a draft, for review, of the Rapporteur's TD for changes to H.245 relative to the white paper COM-16-120, due for approval in November. <<H245-TD-DraftA.zip>> Best regards Mike Nilsson -------------------- Mike Nilsson Multimedia Applications B81 Room 102 pp14 BT Advanced Communications Technology Centre Adastral Park, Martlesham Heath, Ipswich, IP5 3RE, UK Tel: +44 1473 645413 Mobile: +44 7808 635412 Fax: +44 1473 646589 Email: mike.nilsson(a)bt.com

1 0

Re: Support bi-directional channels in annex C fast start
by Roni Even 08 Sep '00

08 Sep '00

Paul, I think that the original text was due to APC-1516 from 9902-Mon submitted by Francois Audet. Any how the current text explains that the originating side is responsible to open the bi-directional VC and signal it in the OLC of the fast connect. The procedure is there in annex C and I do not see what extra text is needed. I think that we only need to allow this mode in the fast connect section. Bellow is the text from annex C - C.3.8.2 If the bidirectional usage is indicated, the receiving endpoint shall send an openLogicalChannelAck (or the openLogicalChannel in the case of Fast Connect) and then it must watch for an ATM VC to be opened by the other endpoint. When ATM VC is completed, it may then use the reverse direction for the media type indicated in the openLogicalChannel command. The endpoint that initiates the openLogicalChannel command is the endpoint that shall open the ATM VC. Thanks Roni Even -----Original Message----- From: Roni Even [mailto:Roni_e@ACCORD.CO.IL] Sent: Tuesday, September 05, 2000 10:33 AM To: ITU-SG16(a)MAILBAG.INTEL.COM Subject: Re: Support bi-directional channels in annex C fast start Paul, TD14 from 9902-MON clearly states that the change was done to support fast start. This is the implementer guide for version 2. I am including the text as well as attaching the TD. I would think that the problem was not putting the extra text in the fast start procedure. IF it is not clear I can add some text to annex C Thanks Roni H.323 Annex C - Indication of ATM capabilities in TransportCapability Description: Annex C requires that the indication of ATM be indicated in the Terminal Capability Set, but it implies that it is done in the capability exchange procedures. While this is valid when fast start is not used, it is not when fast start procedures are used since they do not use the capability exchange procedures before setting up the channels. The current wording unfortunately prohibits the use of fast start with Annex C. This contribution proposes that the wording be amended to allow for this indication to be provided in fast start as well. More specifically, the current Annex mandates that the Terminal Capability set be used to indicate the ATM capabilities. If fast start is used, the TransportCapability (where the ATM information is included) is not included. It is however included in the OpenLogicalChannel. Annex C shall be amended the text to reflect this. It shall also be clarified that OpenLogicalChannel is used instead of OpenLogicalChannelAck when fast start is used..This change will be reflected in H.323 v3. C.3.6 Transport Capabilities added to TerminalCapabilityTransportCapability Set For operation of H.323 on AAL5, an addition to the TerminalCapabilityTransportCapability set is made in H.245. This includes transport level capabilities such as support for ATM Transfer Capability (DBR, SBR1, SBR2, SBR3, ABT/DT, ABT/IT, ABR) as defined in Recommendation I.371. Terminals that do not send this new capability parameter shall not make use of the new methods described in this Annex. The TransportCapability information can be sent as part of the Terminal Capability set exchange in the capability exchange phase. It is also included in the OpenLogicalChannel. ... C.3.7.1 ATM address The ATM address for an RTP stream shall be given in the mediaChannel subfield of H2250LogicalChannelParameters of the H.245 OpenLogicalChannelAck message (or the OpenLogicalChannel in the case of fast start). The mediaChannel subfield UnicastAddress or MulticastAddress shall be filled with the 20-octet NSAP-style ATM End System Address. ... C.3.8.2 Bidirectional logical channels If the bidirectional usage is indicated, the receiving endpoint shall send an OpenLogicalChannelAck (or the OpenLogicalChannel in the case of fast start) and then it must watch for an ATM VC to be opened by the other endpoint. When ATM VC is completed, it may then use the reverse direction for the media type indicated in the OpenLogicalChannel command. The endpoint that initiates the OpenLogicalChannel command is the endpoint that shall open the ATM VC. ... -----Original Message----- From: Paul E. Jones [mailto:paulej@packetizer.com] Sent: Tuesday, September 05, 2000 9:13 AM To: Mailing list for parties associated with ITU-T Study Group 16; Roni_e(a)ACCORD.CO.IL Subject: Re: Support bi-directional channels in annex C fast start Ron, Here are the facts that led to this: 1) In H.323v3 (which is what the Implementers Guide is correcting), it is illegal to use a bi-directional channel with Fast Connect. 2) Section C.3.8.2 and it's parent section C.3.8 were written with H.245 signaling in mind-- there was no thought of Fast Connect here. The procedure is not defined. With H.323v4, Fast Connect was extended to include bi-directional TCP channels, but nothing has been contributed for bi-directional ATM VCs. To simply say it is allowed opens a very large hole. I will quote the authors of the e-mail sent to me that prompted my proposed correction. Since it was sent privately, I will withhold their names. It states: [[ begin quote ]] We believe that there is a conflict between Annex C and H.323 version 3 WRT the Faststart and the method used to open logical channels. Annex C talks about using B-directional OLCs and H.323 V3 claims that only uni- directional OLCs are used during Faststart. ... Annex C in H.323v3 (C.3.8.2) still allows for bidirectional channels in FastStart. It doesn't go into any details, but I can think of two possibilities: - It either opens an exception and allows for the reverse channel to be specified, or - It takes advantage of the fact that the *two* unidirectional channels (forward and reverse) are sent in the same message and somehow associates them as being the same SVC (using the SessionID and/or the mediaChannel value). [[ end quote ]] The author of that e-mail definitely pointed out a whole in the specification. Annex C references bi-directional channels used with Fast Connect, but that is explicitly illegal in V3. I am not at all opposed to re-inserting this text into H.323v4, but we definitely need some clarifying text that explains how this shall be used in Annex C. We cannot assume that the readers understand how it works. Would you be willing to draft text for Annex C to be included in the decided document in November? Best Regards, Paul ----- Original Message ----- From: "Roni Even" <Roni_e(a)ACCORD.CO.IL> To: <ITU-SG16(a)mailbag.cps.intel.com> Sent: Sunday, September 03, 2000 6:03 AM Subject: Support bi-directional channels in annex C fast start > Hi, > During the Portland meeting I had a concern about the change in H.323 V4 and > Implementers guide described in APC 1875a item 17 that was added by the > editor. This change was also added by the editor to the white draft of H.323 > V4. The editor pointed out that there is a contradiction between the text in > Annex C in paragraph C.3.8.2 and fast start in 8.1.71. concerning the use of > bi-directional channels. > I looked at the subject and my suggestion is to keep the text in annex C and > add to the end of the first paragraph of 8.1.7.1 "or one bi-directional > channel logical channel as described in annex C" > Thanks > Roni Even > > ******************************** > Roni Even > VP Product Planning > Accord Networks > Phone: +972-3-9251200 > Fax: +972-3-9211571 > email: roni_e(a)accord.co.il > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > 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

3 2

Re: H.323 Mobility: Enterprise vs. Mobile Carrier - The teleconfe rence
by Jaakko Sundquist 08 Sep '00

08 Sep '00

Hi Paul, Radhika, Markku & al, Personally I think that having the teleconference already on next Monday is too early. I think we should discuss and especially get other people's opinions on this matter on the list before having the teleconference. -Jaakko ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

tML - telecommunication Markup Language
by Sakae OKUBO 08 Sep '00

08 Sep '00

Dear SG16 colleagues, Does anyone know about the subject tML which seems to be studied somewhere in ITU? I have received this question only referring to the word "tML - telecommunication Markup Language." Any advice is appreciated. 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 *********************************************************** ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

2 2