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

Re: [H.323 Mobility:] A cleaned up H.323 Annex H draft uploaded
by Roy, Radhika R, ALCOO 17 Sep '00

17 Sep '00

Hi, Paul: I am glad that you have asked this question. HLF and VLF are value-added functions, and these server functions are necessary for any mobile users. IMT-2000 is working to develop these protocols. SG16 and SG11 had one joint meeting in the last Feb'00 in Geneva. These protocols are VLF <-> HLF and others. All we (Q.13/16) need to do: An interface with the VLF by the H.323 GK. (An analogy can also given: H.245 is a common set of control protocol that is being used by H.323, H.324, and other applications.) If there are one or more functions are needed for any reasons that are specific to H.323, people can always augment that particular protocol. This is a fact of life. The same is also true for QoS, authentication, accounting, billing, and others. More importantly, IMT-2000 is dedicated for mobility. Our (Q.13/16) primary task is to extend the H.323 protocol for supporting mobility (as explained many times) is as follows: Part 1: Within the scope of Q.13/16: Extension of H.323 (e.g., H.225.0 [RAS, Q.931, Annex G] and H.245 messages): Terminals, GKs/BEs, GWs. (Contributions are there: D.354 of SG16 Feb'00/TD-31 of Portland'00.) If we do NOT this part 1, we are NOT doing our primary job because the solution will NOT fly. We are rather "building a castle in the air." Best regards, Radhika R. Roy AT&T -----Original Message----- From: Paul E. Jones [mailto:paulej@PACKETIZER.COM] Sent: Saturday, September 16, 2000 2:45 PM To: ITU-SG16(a)MAILBAG.INTEL.COM Subject: Re: [H.323 Mobility:] A cleaned up H.323 Annex H draft uploaded Radhika, et al, I have to confess that I have had no time to really follow the Annex H work, but I do have a question to toss out here: Why do you consider the VLF or HLF functions outside the scope of Q13/16? I assume that these functions are IP-based (or at least used with the same call signaling transport as the H.323 system) and integrate with the H.323 functions. You stated below that these functions are common for all mobile systems. I will not argue that point, but will a common solution be the most appropriate for H.323 systems? I would guess that trying to introduce a generic mechanism may or may not be the best solution for H.323. I'd like to hear counter arguments to yours. Apparently others felt that these functions were necessary for H.323 systems and should be defined within the H.323 framework. Paul ----- Original Message ----- From: "Roy, Radhika R, ALCOO" <rrroy(a)ATT.COM> To: <ITU-SG16(a)mailbag.cps.intel.com> Sent: Friday, September 15, 2000 10:25 AM Subject: Re: [H.323 Mobility:] A cleaned up H.323 Annex H draft uploaded > Hi, Everyone: > > The document MD-106 (H.323 Annex H) submitted by the editor remains > basically same from the fundamentally point of view. So, the comments > provided on the September 8 email (copy enclosed) remains the same as stated > earlier. The comments can be summarized as follows: > > The Annex should be divided into two parts: > > Part 1: Within the scope of Q.13/16: Extension of H.323 (e.g., H.225.0 [RAS, > Q.931, Annex G] and H.245 messages): Terminals, GKs/BEs, GWs. (Contributions > are there: D.354 of SG16 Feb'00/TD-31 of Portland'00.) > > Part 2: Outside the scope of Q.13/16: Back-end services related to Mobility > (or value-added services related mobility) containing VLF and HLF. > > So, it can be seen clearly that MD-106 (H.323 Annex H) submitted by the > editor does not contain the basic part 1 which is within the scope of > Q.13/16 (it rather contains part 2 which is outside the scope of Q.13/16). > > Best regards, > Radhika R. Roy > AT&T > +1 732 420 1580 > > > -----Original Message----- > From: Roy, Radhika R, ALCOO > Sent: Friday, September 08, 2000 10:23 AM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: Re: [H.323 Mobility:] H.323 Annex H status check > > 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: Thursday, September 14, 2000 7:28 AM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: [H.323 Mobility:] A cleaned up H.323 Annex H draft uploaded > > > 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 > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > 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

1 0

Re: [H.323 Mobility:] A cleaned up H.323 Annex H draft uploaded
by Roy, Radhika R, ALCOO 16 Sep '00

16 Sep '00

Hi, Everyone: The document MD-106 (H.323 Annex H) submitted by the editor remains basically same from the fundamentally point of view. So, the comments provided on the September 8 email (copy enclosed) remains the same as stated earlier. The comments can be summarized as follows: The Annex should be divided into two parts: Part 1: Within the scope of Q.13/16: Extension of H.323 (e.g., H.225.0 [RAS, Q.931, Annex G] and H.245 messages): Terminals, GKs/BEs, GWs. (Contributions are there: D.354 of SG16 Feb'00/TD-31 of Portland'00.) Part 2: Outside the scope of Q.13/16: Back-end services related to Mobility (or value-added services related mobility) containing VLF and HLF. So, it can be seen clearly that MD-106 (H.323 Annex H) submitted by the editor does not contain the basic part 1 which is within the scope of Q.13/16 (it rather contains part 2 which is outside the scope of Q.13/16). Best regards, Radhika R. Roy AT&T +1 732 420 1580 -----Original Message----- From: Roy, Radhika R, ALCOO Sent: Friday, September 08, 2000 10:23 AM To: ITU-SG16(a)MAILBAG.INTEL.COM Subject: Re: [H.323 Mobility:] H.323 Annex H status check 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: Thursday, September 14, 2000 7:28 AM To: ITU-SG16(a)MAILBAG.INTEL.COM Subject: [H.323 Mobility:] A cleaned up H.323 Annex H draft uploaded 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 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

2 1

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

16 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