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

Contribution for Porto Seguro Q.5/16 (Mobility)
by Horvath Ernst 21 May '01

21 May '01

Dear Mr. Okubo, I uploaded contribution "TD-xxx H_MMS_comments" to the Picturetel Incoming directory. This is for discussion in Q.5/16. Kind Regards, Ernst Horvath Siemens AG ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

2 1

The Info You Requested 30273
by sabrina_B＠HWMCPLUS.COM 21 May '01

21 May '01

Long Distance Conference Calls 18 Cents Per Minute! -Connect up to 100 participants -No set up fees or contractual fees -Call anytime, from anywhere, to anywhere -Web, Data, and Video Conferencing Available Why pay more for something you don't have to. Learn More About Conference Calls For Less Here http://marketing201.net/ccfl/ This is not SPAM. You have been emailed this message because you have opted to receive information regarding business opportunities. If you feel that your email address has been used without your consent and wish to be removed, click the following link. We will gladly remove you from our distribution list and apologize for any inconvenience. rem0ve992(a)excite.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

Annex Gv2
by Paul E. Jones 21 May '01

21 May '01

Folks, The editor of Annex G has recommended that we not approve Annex G at this meeting, citing that there is insufficient material to warrant approval. I have also heard comments from some that additional work should be done in the area of defining reference point D. Of course, we also have the open question of where (if anywhere) Annex G fits into the H.MMS.x work. For the benefit of those not planning to attend the meeting, please tell me if you would have objections to *not* approving Annex Gv2 at this meeting. Thanks, Paul ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

Re: Annex M.4 for H248
by OKUBO Sakae 19 May '01

19 May '01

Dear Mr. Sayre, >I have emailed to Mr. Bigi the Temporary Document (editor's draft ) for >Annex M.4 of H.248. I have also uploaded this file, AnnexM4H248.zip, to the >Incoming folder on the Pictel site. Can you please move this file to the >Porto Seguro folder? I have done so. Best regards, OKUBO Sakae ********************************************************* Global Information and Telecommunication Institute (GITI) Waseda University 29-7 Waseda University Bldg. 1-3-10 Nishi-Waseda, Shinjuku-ku, Tokyo 169-0051 Japan e-mail: okubo(a)giti.waseda.ac.jp Tel: +81 3 3204 8194 Fax: +81 3 5286 3832 ********************************************************* ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

Re: Switching to H.245
by Francois Audet 18 May '01

18 May '01

Or something like "H.323 entities shall only process the first fastStart element it receives for a call". Thanks guys. > -----Original Message----- > From: Sasha Ruditsky [mailto:sasha@RADVISION.COM] > Sent: Friday, May 18, 2001 12:16 PM > To: ITU-SG16(a)mailbag.cps.intel.com > Subject: Re: Switching to H.245 > > > Hi François > > Probably I'll try to state you question in more generic way. > > We know that it is possible to perform OLC operations after fast start > completed > and before another Q.931 message (like ALERTING or CONNECT) > with fast start > is sent. > (the simplest probably is to close channel opened using fast start) > (3rd party pause and redirection is of course procedure of this kind) > > What is the meaning of the fast start in such CONNECT message? > > And here I agree with Chris that such fast start elements > should be ignored. > > So probably the text that may solve this and should be added > should state > something like: > "H.323 entity shall process fast start elements only once > during the call." > > BTW Probably the same statement should be done about > h245Address. I just > know one H.323 endpoint that established 3 H.245 connections > when got the > h245Address in CALL PROCEEDING, ALERTING and CONNECT. > > Sasha > > > > -----Original Message----- > From: Chris Wayman Purvis [mailto:cwp@ISDN-COMMS.CO.UK] > Sent: Friday, May 18, 2001 6:56 AM > To: ITU-SG16(a)mailbag.cps.INTEL.COM > Subject: Re: Switching to H.245 > > > Francois, > > Good catch! My suggestion would be to add some text saying > that anything > exchanged via H.245 overrides anything done by fastStart, even if the > fastStart happens to arrive later. > > Now what happens if there's a possible scenario someone can > devise where you > manage to get tunnelled and "separate connection" H.245 > contradicting each > other is a thornier problem - can anyone see that happening? > > Regards, > Chris > > Francois Audet wrote: > > > Hum, interesting. > > > > > > > > My follow up question is then: > > > > * A sends SETUP to B with fast start with h245Address and > > tunnelling. ALERTING responds to FS, and the whole TCS and M/S > > process takes place. Then A wants to forward the call > (internally) > > before answer (i.e., in the ALERTING phase). It thus > sends TCS=0, > > TCS=full, OLCs and all that. Then B answers and sends > the CONNECT > > (with the same fastStart as the ALERTING as per earlier > > discussions we had ;^) Wouldn't the content of the fastStart > > contradict what the actual forwarded connections is > really? Would > > it be a problem? > > > > Seems pretty tricky... > > > > -----Original Message----- > > From: Paul Long [mailto:plong@IPDIALOG.COM] > > Sent: Thursday, May 17, 2001 11:52 AM > > To: ITU-SG16(a)MAILBAG.INTEL.COM > > Subject: Re: Switching to H.245 > > > > Francois, > > > > > > > > I realize how this could be confusing, but I don't > necessarily see a > > conflict since they all say, "may." For example, if I > say, "X may do > > A or B," and, "X may do B," that does not preclude "X may do A." > > Conversely, if I said "shall" instead of "may," I think > there would > > be real conflicts. I've worked on EPs that are very aggressive > > during call establishment. For example, Setup contains an > > h245Address and indicates support for Fast Connect and H.245 > > Tunneling. Other than all the non-compliant EPs out > there, it worked > > just fine. The EPs also support third-party pause, but I don't > > remember ever testing that particular scenario. As long > as an EP is > > implemented correctly, I don't see anything in the > Recommendation > > that would prevent this from working. > > > > > > > > Paul Long > > > > ipDialog, Inc. > > > > -----Original Message----- > > From: Mailing list for parties associated with > ITU-T Study Group > > 16 [mailto:ITU-SG16@mailbag.cps.INTEL.COM]On Behalf > Of Francois > > Audet > > Sent: Thursday, May 17, 2001 1:07 PM > > To: ITU-SG16(a)mailbag.cps.INTEL.COM > > Subject: Switching to H.245 > > > > Guys, > > > > > > > > H.323/8.1.7.2 says : > > > > After establishment of a call using the Fast Connect > > procedure, either endpoint may determine that it is > > necessary to invoke call features that require > the use of > > H.245 procedures. Either endpoint may initiate > the use of > > H.245 procedures at any point during the call, using > > tunnelling as described in 8.2..1 (if > h245Tunnelling remains > > enabled) or a separate H.245 connection. The process for > > switching to a separate H.245 connection is described in > 8.2.3. > > > > 8.2..3 says: > > > > When H.245 encapsulation or Fast Connect is being used, > > either endpoint may choose to switch to using > the separate > > H.245 connection at any time. > > > > There seem to be some contradiction in there: is it "after > > establishment" or "at any time"? > > > > > > > > Do you have to wait for after CONNECT to establish > a separate > > H.245 channel or not? > > > > > > > > The case I'm interested in would be to send SETUP with > > fastStart, then receive ALERTING with fastStart. > Then can either > > end initiate H.245 before CONNECT? If so, what if > third party > > pause and redirection is initiated before CONNECT? > > > > > > > > ---- > > > > François AUDET, Nortel Networks > > > > mailto:audet@nortelnetworks.com, tel:+1 408 495 3756 > > > > > > > > > -- > Dr Chris Purvis -- Development Manager > ISDN Communications Ltd, The Stable Block, Ronans, Chavey Down Road > Winkfield Row, Berkshire. RG42 6LY ENGLAND > Phone: +44 1344 899 007 > Fax: +44 1344 899 001 > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > 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: Switching to H.245
by Sasha Ruditsky 18 May '01

18 May '01

Hi François Probably I'll try to state you question in more generic way. We know that it is possible to perform OLC operations after fast start completed and before another Q.931 message (like ALERTING or CONNECT) with fast start is sent. (the simplest probably is to close channel opened using fast start) (3rd party pause and redirection is of course procedure of this kind) What is the meaning of the fast start in such CONNECT message? And here I agree with Chris that such fast start elements should be ignored. So probably the text that may solve this and should be added should state something like: "H.323 entity shall process fast start elements only once during the call." BTW Probably the same statement should be done about h245Address. I just know one H.323 endpoint that established 3 H.245 connections when got the h245Address in CALL PROCEEDING, ALERTING and CONNECT. Sasha -----Original Message----- From: Chris Wayman Purvis [mailto:cwp@ISDN-COMMS.CO.UK] Sent: Friday, May 18, 2001 6:56 AM To: ITU-SG16(a)mailbag.cps.INTEL.COM Subject: Re: Switching to H.245 Francois, Good catch! My suggestion would be to add some text saying that anything exchanged via H.245 overrides anything done by fastStart, even if the fastStart happens to arrive later. Now what happens if there's a possible scenario someone can devise where you manage to get tunnelled and "separate connection" H.245 contradicting each other is a thornier problem - can anyone see that happening? Regards, Chris Francois Audet wrote: > Hum, interesting. > > > > My follow up question is then: > > * A sends SETUP to B with fast start with h245Address and > tunnelling. ALERTING responds to FS, and the whole TCS and M/S > process takes place. Then A wants to forward the call (internally) > before answer (i.e., in the ALERTING phase). It thus sends TCS=0, > TCS=full, OLCs and all that. Then B answers and sends the CONNECT > (with the same fastStart as the ALERTING as per earlier > discussions we had ;^) Wouldn't the content of the fastStart > contradict what the actual forwarded connections is really? Would > it be a problem? > > Seems pretty tricky... > > -----Original Message----- > From: Paul Long [mailto:plong@IPDIALOG.COM] > Sent: Thursday, May 17, 2001 11:52 AM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: Re: Switching to H.245 > > Francois, > > > > I realize how this could be confusing, but I don't necessarily see a > conflict since they all say, "may." For example, if I say, "X may do > A or B," and, "X may do B," that does not preclude "X may do A." > Conversely, if I said "shall" instead of "may," I think there would > be real conflicts. I've worked on EPs that are very aggressive > during call establishment. For example, Setup contains an > h245Address and indicates support for Fast Connect and H.245 > Tunneling. Other than all the non-compliant EPs out there, it worked > just fine. The EPs also support third-party pause, but I don't > remember ever testing that particular scenario. As long as an EP is > implemented correctly, I don't see anything in the Recommendation > that would prevent this from working. > > > > Paul Long > > ipDialog, Inc. > > -----Original Message----- > From: Mailing list for parties associated with ITU-T Study Group > 16 [mailto:ITU-SG16@mailbag.cps.INTEL.COM]On Behalf Of Francois > Audet > Sent: Thursday, May 17, 2001 1:07 PM > To: ITU-SG16(a)mailbag.cps.INTEL.COM > Subject: Switching to H.245 > > Guys, > > > > H.323/8.1.7.2 says : > > After establishment of a call using the Fast Connect > procedure, either endpoint may determine that it is > necessary to invoke call features that require the use of > H.245 procedures. Either endpoint may initiate the use of > H.245 procedures at any point during the call, using > tunnelling as described in 8.2..1 (if h245Tunnelling remains > enabled) or a separate H.245 connection. The process for > switching to a separate H.245 connection is described in 8.2.3. > > 8.2..3 says: > > When H.245 encapsulation or Fast Connect is being used, > either endpoint may choose to switch to using the separate > H.245 connection at any time. > > There seem to be some contradiction in there: is it "after > establishment" or "at any time"? > > > > Do you have to wait for after CONNECT to establish a separate > H.245 channel or not? > > > > The case I'm interested in would be to send SETUP with > fastStart, then receive ALERTING with fastStart. Then can either > end initiate H.245 before CONNECT? If so, what if third party > pause and redirection is initiated before CONNECT? > > > > ---- > > François AUDET, Nortel Networks > > mailto:audet@nortelnetworks.com, tel:+1 408 495 3756 > > > -- Dr Chris Purvis -- Development Manager ISDN Communications Ltd, The Stable Block, Ronans, Chavey Down Road Winkfield Row, Berkshire. RG42 6LY ENGLAND Phone: +44 1344 899 007 Fax: +44 1344 899 001 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 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

AW: Gatekeeper behavior question
by Guntram Diehl 18 May '01

18 May '01

Hi Hans, yes, you have to map IP address + port to an alias. The H.323 standard only talks about "transport addresses" which have to be mapped. And a transport address in the IP case consists of addr+port. Guntram > -----Ursprüngliche Nachricht----- > Von: Hans Viens [mailto:hviens@MEDIATRIX.COM] > Gesendet: Freitag, 18. Mai 2001 14:48 > An: ITU-SG16(a)MAILBAG.INTEL.COM > Betreff: Gatekeeper behavior question > > > Hi folks! > > I just want to pin point a place on the H.323 standard that > talk about the > behavior of a gatekeeper on a specific scenario. My question is: Is it > mandatory for a gatekeeper to accept the registration of a > unit using 1 IP > address and supporting mutiple H.323 endpoint (multiple > ports) (i.e EP1: > 192.168.0.1:2000; EP2: 192.168.0.1:2001 ... ) ? Also, is it > mandatory for a > gatekeeper to translate the alias of an endpoint with both > its IP address & > port number ? > > If you could help me to point me to a section in the H.323 > standard, I would > appreciate it! > > Regards, > > Hans > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > 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: AW: Gatekeeper behavior question
by Frank Derks 18 May '01

18 May '01

Hans, H.323 describes this situation in section 7.2.2. If the aliases _and_ the transport addresses (i.e. IP address + TCP port) are distinct, then the Gatekeeper is able to distinguish the two as really being different. If _either_ the aliases _or_ the transport addresses are identical then it is up to the Gatekeeper implementation to decide what to do. If the alias is the same (and the transport address is not), it is up to the Gatekeeper to decide to accept or reject the registration. If the transport address is the same (and the alias is not), it is advisable to replace the previous registration with the new one. Regards, Frank gdiehl@INNOVAPHONE.COM@SMTP@MAILBAG.INTEL.COM on 18-05-2001 15:39:11 Please respond to gdiehl@INNOVAPHONE.COM@SMTP Sent by: ITU-SG16(a)MAILBAG.INTEL.COM To: ITU-SG16@MAILBAG.INTEL.COM@SMTP cc: Subject: AW: Gatekeeper behavior question Classification: Hi Hans, yes, you have to map IP address + port to an alias. The H.323 standard only talks about "transport addresses" which have to be mapped. And a transport address in the IP case consists of addr+port. Guntram > -----Ursprüngliche Nachricht----- > Von: Hans Viens [mailto:hviens@MEDIATRIX.COM] > Gesendet: Freitag, 18. Mai 2001 14:48 > An: ITU-SG16(a)MAILBAG.INTEL.COM > Betreff: Gatekeeper behavior question > > > Hi folks! > > I just want to pin point a place on the H.323 standard that > talk about the > behavior of a gatekeeper on a specific scenario. My question is: Is it > mandatory for a gatekeeper to accept the registration of a > unit using 1 IP > address and supporting mutiple H.323 endpoint (multiple > ports) (i.e EP1: > 192.168.0.1:2000; EP2: 192.168.0.1:2001 ... ) ? Also, is it > mandatory for a > gatekeeper to translate the alias of an endpoint with both > its IP address & > port number ? > > If you could help me to point me to a section in the H.323 > standard, I would > appreciate it! > > Regards, > > Hans > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > 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

Gatekeeper behavior question
by Hans Viens 18 May '01

18 May '01

Hi folks! I just want to pin point a place on the H.323 standard that talk about the behavior of a gatekeeper on a specific scenario. My question is: Is it mandatory for a gatekeeper to accept the registration of a unit using 1 IP address and supporting mutiple H.323 endpoint (multiple ports) (i.e EP1: 192.168.0.1:2000; EP2: 192.168.0.1:2001 ... ) ? Also, is it mandatory for a gatekeeper to translate the alias of an endpoint with both its IP address & port number ? If you could help me to point me to a section in the H.323 standard, I would appreciate it! Regards, Hans ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

Re: Switching to H.245
by Francois Audet 18 May '01

18 May '01

Hum, interesting. My follow up question is then: * A sends SETUP to B with fast start with h245Address and tunnelling. ALERTING responds to FS, and the whole TCS and M/S process takes place. Then A wants to forward the call (internally) before answer (i.e., in the ALERTING phase). It thus sends TCS=0, TCS=full, OLCs and all that. Then B answers and sends the CONNECT (with the same fastStart as the ALERTING as per earlier discussions we had ;^) Wouldn't the content of the fastStart contradict what the actual forwarded connections is really? Would it be a problem? Seems pretty tricky... -----Original Message----- From: Paul Long [mailto:plong@IPDIALOG.COM] Sent: Thursday, May 17, 2001 11:52 AM To: ITU-SG16(a)MAILBAG.INTEL.COM Subject: Re: Switching to H.245 Francois, I realize how this could be confusing, but I don't necessarily see a conflict since they all say, "may." For example, if I say, "X may do A or B," and, "X may do B," that does not preclude "X may do A." Conversely, if I said "shall" instead of "may," I think there would be real conflicts. I've worked on EPs that are very aggressive during call establishment. For example, Setup contains an h245Address and indicates support for Fast Connect and H.245 Tunneling. Other than all the non-compliant EPs out there, it worked just fine. The EPs also support third-party pause, but I don't remember ever testing that particular scenario. As long as an EP is implemented correctly, I don't see anything in the Recommendation that would prevent this from working. Paul Long ipDialog, Inc. -----Original Message----- From: Mailing list for parties associated with ITU-T Study Group 16 [mailto:ITU-SG16@mailbag.cps.INTEL.COM]On Behalf Of Francois Audet Sent: Thursday, May 17, 2001 1:07 PM To: ITU-SG16(a)mailbag.cps.INTEL.COM Subject: Switching to H.245 Guys, H.323/8.1.7.2 says : After establishment of a call using the Fast Connect procedure, either endpoint may determine that it is necessary to invoke call features that require the use of H.245 procedures. Either endpoint may initiate the use of H.245 procedures at any point during the call, using tunnelling as described in 8.2.1 (if h245Tunnelling remains enabled) or a separate H.245 connection. The process for switching to a separate H.245 connection is described in 8.2.3. 8.2.3 says: When H.245 encapsulation or Fast Connect is being used, either endpoint may choose to switch to using the separate H.245 connection at any time. There seem to be some contradiction in there: is it "after establishment" or "at any time"? Do you have to wait for after CONNECT to establish a separate H.245 channel or not? The case I'm interested in would be to send SETUP with fastStart, then receive ALERTING with fastStart. Then can either end initiate H.245 before CONNECT? If so, what if third party pause and redirection is initiated before CONNECT? ---- François AUDET, Nortel Networks mailto:audet@nortelnetworks.com <mailto:audet@nortelnetworks.com> , tel:+1 408 495 3756

2 1