- sg16-avd - lists.packetizer.com

New Editor of H.225.0 and the H.323-Series Implementers Guide
by Paul E. Jones 22 Mar '01

22 Mar '01

Folks, As many of you know, Rich Bowen has changed roles within the company and now has little time to continue as editor of H.225.0. I would like to thank Rich for his hard work on version 4-- I know he spent a few nights without sleep to finish that document! (Perhaps that's the *real* reason he chose to step down.) Vivek Bhargava (Cisco), who has been working on H.323 for a number of years, expressed an interest to assume responsibility for H.225.0v5. In discussing the work with him, he also expressed interest in taking the Implementers Guide forward. As many of you know, it is very hard to find an editor for the Implementers Guide, so he was quickly awarded the job before he changed his mind :-) Seriously, Vivek is very thorough and pays close attention to detail. I believe he will serve well as editor of these two documents. His e-mail address is vbhargava(a)packetizer.com. Feel free to call out his name as new Implementers Guide issues arise. Best Regards, Paul E. Jones Rapporteur Q.2/16 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

AW: Conflicting text in H.323 concerning the requirement for esta blishing a H.245 control channel??
by Horvath Ernst 22 Mar '01

22 Mar '01

Frank, Roni et al., I like Roni's summary. In my opinion the procedures (in section 8) are clear enough. But section 6.2 talks about terminal functionality, and this got out of line with new options added over time. How about the following guidelines for improving on the text in 6.2.8: 1. All terminals shall support H.245 control, as far as required by the terminal type (e.g. annex-F-SETs need only a subset for fastStart). 2. Except for SETs, a terminal shall be "able" to open an H.245 control channel at any time during a call. 3. Encapsulation/tunneling may be used instead of the H.245 control channel if supported at both ends. 4. The terminal shall associate exactly one H.245 "session" with each call, but the transport method for the H.245 control information can be chosen as desired and also changed during a call (fastStart / tunnel / H.245 control channel - the rules for switching from one method to another are given in section 8). Regards, Ernst Horvath Siemens AG > -----Ursprüngliche Nachricht----- > Von: Frank Derks [mailto:frank.derks@PHILIPS.COM] > Gesendet am: Donnerstag, 22. März 2001 15:03 > An: ITU-SG16(a)mailbag.cps.INTEL.COM > Betreff: Re: Conflicting text in H.323 concerning the requirement for > esta blishing a H.245 control channel?? > > Roni (et al.), > > I would say that what you are saying is pretty much how I > initially thought > things were supposed to work (before I started this > discussion;-0). The > downside is that this brings us back to square one, and I do > not want to > restart the discussion. > > I would like to ask Paul and Chris to come up with how we're > going to avoid > future confusion. Would it be a good idea to change the > wording in 6.2.8 to: > > "The endpoint shall establish at most one H.245 Control > Channel for each call > that the endpoint is participating in." > > Regards, > > Frank > > > > > > Roni_e@ACCORD.CO.IL@SMTP@MAILBAG.INTEL.COM on 22-03-2001 13:55:44 > Please respond to Roni_e@ACCORD.CO.IL@SMTP > Sent by: ITU-SG16(a)MAILBAG.INTEL.COM > To: ITU-SG16@MAILBAG.INTEL.COM@SMTP > cc: > Subject: Re: Conflicting text in H.323 concerning the > requirement for esta blishing a H.245 control channel?? > Classification: > > all, > > I will try to give my view and history of the H.245. > Before fast connect the issue of H.245 was simple. It is > mandatory and after > call setup the H.245 process with Master-slave and caps > exchange was the > only way. Annex F gave an option for a simple terminal with no h.245 > mandatory support. This is the text in 6.2.8. When we added > fast connect we > opened the door for simple calls that finished the connection and > establishment of media channels and did not need any more > control to delay > or skip H.245 and described in 8.1.7.2. Any side can initiate > the opening of > H.245 during the call. I have to agree that 6.2.8 is very > strong about H.245 > channel establishment. The reason for having it this way is to prevent > implementers from understanding that an H.323 compliant > endpoint can be > implemented without support of H.245 if they are doing fast > connect!!!. > > Call termination, before fast connect, was done through > H.245. The call > signaling channel can be closed before but H.245 must stay > open during the > call. 8.1.7.2 explain what to do if H.245 was not open (call > signaling must > stay open until call finish or opening of a separate H.245 channel) ( > 8.1.7.2 2nd paragraph "When a call is established using the > Fast Connect > procedure, both endpoints shall keep the Q.931 Call Signaling > Channel open > until either the call is terminated or, for compatibility with older > endpoints, until a separate H.245 connection is established.") > > I think that is what H.323 says. If you feel that this is not > clear from the > text give me a suggestion how to change it. It can be > submitted to the next > meeting (I am the new editor for H.323 V5). > Regards > Roni Even > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

Re: Conflicting text in H.323 concerning the requirement for esta blishing a H.245 control channel??
by Roni Even 22 Mar '01

22 Mar '01

Chris, About your comments 1. B can make A start H.245 by using facility message with reason startH.245. See H.323 8.2.3 Switching to a separate H.245 connection. 2. About 6.2.8 I agree that it states the H.245 shall be established, it does not say when. The when is mentioned in 8.1.7.2. Roni Even -----Original Message----- From: Chris Wayman Purvis [mailto:cwp@ISDN-COMMS.CO.UK] Sent: Wednesday, March 21, 2001 3:31 PM To: ITU-SG16(a)MAILBAG.INTEL.COM Subject: Re: Conflicting text in H.323 concerning the requirement for esta blishing a H.245 control channel?? Roni, > H.323 mandates the support of H.245 for end points that comply with the > standard. It does not mean, when using fast connect that it must be open > immediately but can be opened at a later stage by any side. Except that it states exactly the opposite in the section under discussion. Also, consider the following scenario: Two endpoints, A and B. B does not support tunnelled H.245. A calls B, without giving any H.245 address in its Setup message. B accepts the call on the basis of fastStart. No H.245 channel is set up, as you suggest. Suppose now B wishes to send a UII (or any H.245 message) to A. It can't. It can't set up the H.245 channel. A could set it up, but doesn't see the need. > The reason for > mandating H.245 is to supply a control channel and is important for gateways > and MCUs as well as for control functions in point to point calls such as > Video fast updates. H.323 annex F defines a simple end point that has H.245 > support as optional. > I do not see the conflict between 6.2.8 and 8.1.7 if 6.2.8 means that you > have to support it but not to actually open it as in simple fast connect > calls. But 6.2.8 does not mean that. It clearly states that an H.245 channel SHALL be opened. > As for DTMF you can use the DTMF RTP payload to have it in band instead of > H.245. If the person you're talking to happens to support this. Of course you don't know whether or not it does if you haven't exchanged TCS. Please let's not break this! Regards, Chris > -----Original Message----- > From: Agboh, Charles [mailto:charles.agboh@EBONE.COM] > Sent: Tuesday, March 20, 2001 6:59 PM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: Re: Conflicting text in H.323 concerning the requirement for > esta blishing a H.245 control channel?? > > > Chris, > > Part of establishing a "point-to-point" call involves opening 2 TCP > connnections using the Fast Connect procedure as you described it. If that > is the case, then the extract from H.323v2 below is misleading(I believe). > > H.323v2: 8.1.7 Fast Connect Procedure > > "..... The Fast Connect procedure allows the endpoints to establish a basic > point-to-point call with as few as one round-trip message exchange, enabling > immediate media stream delivery upon call connection." > > BR, > Charles > >> -----Original Message----- >> From: Chris Wayman Purvis [mailto:cwp@ISDN-COMMS.CO.UK] >> Sent: Tuesday, March 20, 2001 5:47 PM >> To: ITU-SG16(a)MAILBAG.INTEL.COM >> Subject: Re: Conflicting text in H.323 concerning the requirement for >> esta blishing a H.245 control channel?? >> >> >> Charles, >> >> It does NOT defeat ANY of the stated aims of FastConnect. >> These aims were to get agreed media channels in both >> directions open as >> quickly as possible. Doing FastStart AND H.245 gives you your media >> quickly, and means you have the power of H.245 thereon. >> >> In-band DTMF transfer may be used. If you happen to be using >> a codec that >> supports it. If you assume it when you're using an >> unsuitable codec you'll >> have a problem. Which is a reason for using H.245 capability >> negotiation. >> >> Regards, >> Chris >> >> Agboh, Charles wrote: >> >> >>> which defeats the whole point of having a Fast Connect >> >> procedure (FS + >> >>> H.245). Why isn't in-band- DTMF transfer used instead (in FS)? >>> >>> -Charles >>> >>> >>> >>>> -----Original Message----- >>>> From: Frank Derks [mailto:frank.derks@PHILIPS.COM] >>>> Sent: Tuesday, March 20, 2001 4:40 PM >>>> To: ITU-SG16(a)MAILBAG.INTEL.COM >>>> Subject: Re: Conflicting text in H.323 concerning the >>> >> requirement for >> >>>> establishing a H.245 control channel?? >>>> >>>> >>>> Chris, >>>> >>>> I thought I was being clear enough, so let me try again. >>>> 6.2.8/H.323 states >>>> that an enpoint must open one (and exactly one) H.245 control >>>> channel. When >>>> Fast Connect is being used, I assume that the intention is >>>> that no such control >>>> channel is opened. >>>> >>>> To be compliant with 6.2.8/H,323 I would have to open a H.245 >>>> control channel >>>> irrespective of which type of H.245 procedures I will be >>>> using. So if I intend >>>> to use Fast Start (and assuming that the other party also >>>> supports this), I >>>> still have to open a H.245 control channel. >>>> >>>> Frank >>>> >>>> >>>> >>>> >>>> >>>> >>>> cwp(a)isdn-comms.co.uk on 20-03-2001 15:17:14 >>>> To: Frank Derks/HVS/BE/PHILIPS@EMEA2 >>>> cc: ITU-SG16@mailbag.cps.INTEL.COM@SMTP >>>> Subject: Re: Conflicting text in H.323 concerning the >>>> requirement for establishing a H.245 control channel?? >>>> Classification: >>>> >>>> Frank, >>>> >>>> Why do you consider this text to be "conflicting"? >>>> Specifically, with what does it conflict? >>>> >>>> Regards, >>>> Chris >>>> >>>> >>>> >>>>> 6.2.8/H.323 states: "The endpoint shall establish exactly >>>> >> one H.245 >> >>>>> Control Channel for each call that the endpoint is >>>> >>>> participating in." >>>> >>>> >>>>> 8.1.7/H.323 never states that when Fast Connect is being >>>> >> used such a >> >>>>> control channel should be established. As far as I understand the >>>>> mechanism this is only required to switch to "normal" H.245 >>>> >>>> procedures. >>>> >>>> >>>>> It would seem that section 6.2.8 should be rephrased to >>>> >>>> make clear that >>>> >>>> >>>>> the H.245 control channel shall only be established when >>>> >>>> "normal" H.245 >>>> >>>> >>>>> procedures are being followed and not in the fast connect case. >>>>> >>>>> Frank >>>> >>>> -- >>>> 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 >> >> >> -- >> 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 > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > For help on this mail list, send "HELP ITU-SG16" in a message to > listserv(a)mailbag.intel.com -- 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

3 2

Re: Conflicting text in H.323 concerning the requirement for esta blishing a H.245 control channel??
by Roni Even 22 Mar '01

22 Mar '01

All, H.323 mandates the support of H.245 for end points that comply with the standard. It does not mean, when using fast connect that it must be open immediately but can be opened at a later stage by any side. The reason for mandating H.245 is to supply a control channel and is important for gateways and MCUs as well as for control functions in point to point calls such as Video fast updates. H.323 annex F defines a simple end point that has H.245 support as optional. I do not see the conflict between 6.2.8 and 8.1.7 if 6.2.8 means that you have to support it but not to actually open it as in simple fast connect calls. As for DTMF you can use the DTMF RTP payload to have it in band instead of H.245. Regards Roni Even -----Original Message----- From: Agboh, Charles [mailto:charles.agboh@EBONE.COM] Sent: Tuesday, March 20, 2001 6:59 PM To: ITU-SG16(a)MAILBAG.INTEL.COM Subject: Re: Conflicting text in H.323 concerning the requirement for esta blishing a H.245 control channel?? Chris, Part of establishing a "point-to-point" call involves opening 2 TCP connnections using the Fast Connect procedure as you described it. If that is the case, then the extract from H.323v2 below is misleading(I believe). H.323v2: 8.1.7 Fast Connect Procedure "..... The Fast Connect procedure allows the endpoints to establish a basic point-to-point call with as few as one round-trip message exchange, enabling immediate media stream delivery upon call connection." BR, Charles > -----Original Message----- > From: Chris Wayman Purvis [mailto:cwp@ISDN-COMMS.CO.UK] > Sent: Tuesday, March 20, 2001 5:47 PM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: Re: Conflicting text in H.323 concerning the requirement for > esta blishing a H.245 control channel?? > > > Charles, > > It does NOT defeat ANY of the stated aims of FastConnect. > These aims were to get agreed media channels in both > directions open as > quickly as possible. Doing FastStart AND H.245 gives you your media > quickly, and means you have the power of H.245 thereon. > > In-band DTMF transfer may be used. If you happen to be using > a codec that > supports it. If you assume it when you're using an > unsuitable codec you'll > have a problem. Which is a reason for using H.245 capability > negotiation. > > Regards, > Chris > > Agboh, Charles wrote: > > > which defeats the whole point of having a Fast Connect > procedure (FS + > > H.245). Why isn't in-band- DTMF transfer used instead (in FS)? > > > > -Charles > > > > > >> -----Original Message----- > >> From: Frank Derks [mailto:frank.derks@PHILIPS.COM] > >> Sent: Tuesday, March 20, 2001 4:40 PM > >> To: ITU-SG16(a)MAILBAG.INTEL.COM > >> Subject: Re: Conflicting text in H.323 concerning the > requirement for > >> establishing a H.245 control channel?? > >> > >> > >> Chris, > >> > >> I thought I was being clear enough, so let me try again. > >> 6.2.8/H.323 states > >> that an enpoint must open one (and exactly one) H.245 control > >> channel. When > >> Fast Connect is being used, I assume that the intention is > >> that no such control > >> channel is opened. > >> > >> To be compliant with 6.2.8/H,323 I would have to open a H.245 > >> control channel > >> irrespective of which type of H.245 procedures I will be > >> using. So if I intend > >> to use Fast Start (and assuming that the other party also > >> supports this), I > >> still have to open a H.245 control channel. > >> > >> Frank > >> > >> > >> > >> > >> > >> > >> cwp(a)isdn-comms.co.uk on 20-03-2001 15:17:14 > >> To: Frank Derks/HVS/BE/PHILIPS@EMEA2 > >> cc: ITU-SG16@mailbag.cps.INTEL.COM@SMTP > >> Subject: Re: Conflicting text in H.323 concerning the > >> requirement for establishing a H.245 control channel?? > >> Classification: > >> > >> Frank, > >> > >> Why do you consider this text to be "conflicting"? > >> Specifically, with what does it conflict? > >> > >> Regards, > >> Chris > >> > >> > >>> 6.2.8/H.323 states: "The endpoint shall establish exactly > one H.245 > >>> Control Channel for each call that the endpoint is > >> > >> participating in." > >> > >>> 8.1.7/H.323 never states that when Fast Connect is being > used such a > >>> control channel should be established. As far as I understand the > >>> mechanism this is only required to switch to "normal" H.245 > >> > >> procedures. > >> > >>> It would seem that section 6.2.8 should be rephrased to > >> > >> make clear that > >> > >>> the H.245 control channel shall only be established when > >> > >> "normal" H.245 > >> > >>> procedures are being followed and not in the fast connect case. > >>> > >>> Frank > >> > >> -- > >> 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 > > > -- > 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 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

4 3

Re: Conflicting text in H.323 concerning the requirement for esta blishing a H.245 control channel??
by Frank Derks 22 Mar '01

22 Mar '01

Roni (et al.), I would say that what you are saying is pretty much how I initially thought things were supposed to work (before I started this discussion;-0). The downside is that this brings us back to square one, and I do not want to restart the discussion. I would like to ask Paul and Chris to come up with how we're going to avoid future confusion. Would it be a good idea to change the wording in 6.2.8 to: "The endpoint shall establish at most one H.245 Control Channel for each call that the endpoint is participating in." Regards, Frank Roni_e@ACCORD.CO.IL@SMTP@MAILBAG.INTEL.COM on 22-03-2001 13:55:44 Please respond to Roni_e@ACCORD.CO.IL@SMTP Sent by: ITU-SG16(a)MAILBAG.INTEL.COM To: ITU-SG16@MAILBAG.INTEL.COM@SMTP cc: Subject: Re: Conflicting text in H.323 concerning the requirement for esta blishing a H.245 control channel?? Classification: all, I will try to give my view and history of the H.245. Before fast connect the issue of H.245 was simple. It is mandatory and after call setup the H.245 process with Master-slave and caps exchange was the only way. Annex F gave an option for a simple terminal with no h.245 mandatory support. This is the text in 6.2.8. When we added fast connect we opened the door for simple calls that finished the connection and establishment of media channels and did not need any more control to delay or skip H.245 and described in 8.1.7.2. Any side can initiate the opening of H.245 during the call. I have to agree that 6.2.8 is very strong about H.245 channel establishment. The reason for having it this way is to prevent implementers from understanding that an H.323 compliant endpoint can be implemented without support of H.245 if they are doing fast connect!!!. Call termination, before fast connect, was done through H.245. The call signaling channel can be closed before but H.245 must stay open during the call. 8.1.7.2 explain what to do if H.245 was not open (call signaling must stay open until call finish or opening of a separate H.245 channel) ( 8.1.7.2 2nd paragraph "When a call is established using the Fast Connect procedure, both endpoints shall keep the Q.931 Call Signaling Channel open until either the call is terminated or, for compatibility with older endpoints, until a separate H.245 connection is established.") I think that is what H.323 says. If you feel that this is not clear from the text give me a suggestion how to change it. It can be submitted to the next meeting (I am the new editor for H.323 V5). Regards Roni Even -----Original Message----- From: Chris Wayman Purvis [mailto:cwp@isdn-comms.co.uk] Sent: Thursday, March 22, 2001 1:27 PM To: Roni Even; Paul Jones Cc: ITU-SG16(a)mailbag.cps.INTEL.COM Subject: Re: Conflicting text in H.323 concerning the requirement for esta blishing a H.245 control channel?? Roni, Frank, Paul Jones et al, Having reread 8.1.7.2 (as referenced by Roni) I believe that Frank was right all along in saying there is a conflict. 8.1.7.2 saying that a device "may" establish an H.245 session at any point during a call is, I would argue, clearly at odds with 6.2.8 stating that such a session "shall" be established. After all, having not bothered to bring one up until an instant before the end of the call (clearly permitted by 8.1.7.2), why create one at that stage (except because 6.2.8 tells you to...)? There is an alternative reading: the implication of 6.2.8 is that some sort of H.245 session should start immediately (the start and end are the only "special" times in an ordinary call, so if you must start one it's pretty well a requirement to do it immediately). What I don't recall is whether it's permitted to drop an H.245 session during a call. I think it is. So is there an alternative reading, saying "start the H.245 channel at the beginning of the call, but you may drop and restart it as you like during the call"? I don't like this reading, though, it's probably the worst of all worlds. However I don't like the delay of setting up an H.245 session being added to the time taken to transmit the first DTMF tone in a call either... Paul, I think this really needs tidying up one way or another - I think it's a job for the implementors guide... Consensus currently seems to be against me, and to be that we should dump the relevant text in 6.2.8. Regards, Chris Roni Even wrote: > Chris, > About your comments > > 1. B can make A start H.245 by using facility message with reason > startH.245. See H.323 8.2.3 Switching to a separate H.245 connection. > 2. About 6.2.8 I agree that it states the H.245 shall be established, it > does not say when. The when is mentioned in 8.1.7.2. > Roni Even > > > -----Original Message----- > From: Chris Wayman Purvis [mailto:cwp@ISDN-COMMS.CO.UK] > Sent: Wednesday, March 21, 2001 3:31 PM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: Re: Conflicting text in H.323 concerning the requirement for > esta blishing a H.245 control channel?? > > > Roni, > > > >> H.323 mandates the support of H.245 for end points that comply with the >> standard. It does not mean, when using fast connect that it must be open >> immediately but can be opened at a later stage by any side. > > Except that it states exactly the opposite in the section under discussion. > > Also, consider the following scenario: > Two endpoints, A and B. B does not support tunnelled H.245. A calls B, > without giving any H.245 address in its Setup message. B accepts the call > on the basis of fastStart. No H.245 channel is set up, as you suggest. > Suppose now B wishes to send a UII (or any H.245 message) to A. It can't. > It can't set up the H.245 channel. A could set it up, but doesn't see the > need. > > >> The reason for >> mandating H.245 is to supply a control channel and is important for > > gateways > >> and MCUs as well as for control functions in point to point calls such as >> Video fast updates. H.323 annex F defines a simple end point that has > > H.245 > >> support as optional. >> I do not see the conflict between 6.2.8 and 8.1.7 if 6.2.8 means that you >> have to support it but not to actually open it as in simple fast connect >> calls. > > But 6.2.8 does not mean that. It clearly states that an H.245 channel SHALL > be opened. > > >> As for DTMF you can use the DTMF RTP payload to have it in band instead of >> H.245. > > If the person you're talking to happens to support this. Of course you > don't know whether or not it does if you haven't exchanged TCS. > > Please let's not break this! > > Regards, > Chris > > > >> -----Original Message----- >> From: Agboh, Charles [mailto:charles.agboh@EBONE.COM] >> Sent: Tuesday, March 20, 2001 6:59 PM >> To: ITU-SG16(a)MAILBAG.INTEL.COM >> Subject: Re: Conflicting text in H.323 concerning the requirement for >> esta blishing a H.245 control channel?? >> >> >> Chris, >> >> Part of establishing a "point-to-point" call involves opening 2 TCP >> connnections using the Fast Connect procedure as you described it. If > > that > >> is the case, then the extract from H.323v2 below is misleading(I believe). >> >> H.323v2: 8.1.7 Fast Connect Procedure >> >> "..... The Fast Connect procedure allows the endpoints to establish a > > basic > >> point-to-point call with as few as one round-trip message exchange, > > enabling > >> immediate media stream delivery upon call connection." >> >> BR, >> Charles >> >> >>> -----Original Message----- >>> From: Chris Wayman Purvis [mailto:cwp@ISDN-COMMS.CO.UK] >>> Sent: Tuesday, March 20, 2001 5:47 PM >>> To: ITU-SG16(a)MAILBAG.INTEL.COM >>> Subject: Re: Conflicting text in H.323 concerning the requirement for >>> esta blishing a H.245 control channel?? >>> >>> >>> Charles, >>> >>> It does NOT defeat ANY of the stated aims of FastConnect. >>> These aims were to get agreed media channels in both >>> directions open as >>> quickly as possible. Doing FastStart AND H.245 gives you your media >>> quickly, and means you have the power of H.245 thereon. >>> >>> In-band DTMF transfer may be used. If you happen to be using >>> a codec that >>> supports it. If you assume it when you're using an >>> unsuitable codec you'll >>> have a problem. Which is a reason for using H.245 capability >>> negotiation. >>> >>> Regards, >>> Chris >>> >>> Agboh, Charles wrote: >>> >>> >>> >>>> which defeats the whole point of having a Fast Connect >>> >>> procedure (FS + >>> >>> >>>> H.245). Why isn't in-band- DTMF transfer used instead (in FS)? >>>> >>>> -Charles >>>> >>>> >>>> >>>> >>>>> -----Original Message----- >>>>> From: Frank Derks [mailto:frank.derks@PHILIPS.COM] >>>>> Sent: Tuesday, March 20, 2001 4:40 PM >>>>> To: ITU-SG16(a)MAILBAG.INTEL.COM >>>>> Subject: Re: Conflicting text in H.323 concerning the >>>> >>> requirement for >>> >>> >>>>> establishing a H.245 control channel?? >>>>> >>>>> >>>>> Chris, >>>>> >>>>> I thought I was being clear enough, so let me try again. >>>>> 6.2.8/H.323 states >>>>> that an enpoint must open one (and exactly one) H.245 control >>>>> channel. When >>>>> Fast Connect is being used, I assume that the intention is >>>>> that no such control >>>>> channel is opened. >>>>> >>>>> To be compliant with 6.2.8/H,323 I would have to open a H.245 >>>>> control channel >>>>> irrespective of which type of H.245 procedures I will be >>>>> using. So if I intend >>>>> to use Fast Start (and assuming that the other party also >>>>> supports this), I >>>>> still have to open a H.245 control channel. >>>>> >>>>> Frank >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> cwp(a)isdn-comms.co.uk on 20-03-2001 15:17:14 >>>>> To: Frank Derks/HVS/BE/PHILIPS@EMEA2 >>>>> cc: ITU-SG16@mailbag.cps.INTEL.COM@SMTP >>>>> Subject: Re: Conflicting text in H.323 concerning the >>>>> requirement for establishing a H.245 control channel?? >>>>> Classification: >>>>> >>>>> Frank, >>>>> >>>>> Why do you consider this text to be "conflicting"? >>>>> Specifically, with what does it conflict? >>>>> >>>>> Regards, >>>>> Chris >>>>> >>>>> >>>>> >>>>> >>>>>> 6.2.8/H.323 states: "The endpoint shall establish exactly >>>>> >>> one H.245 >>> >>> >>>>>> Control Channel for each call that the endpoint is >>>>> >>>>> participating in." >>>>> >>>>> >>>>> >>>>>> 8.1.7/H.323 never states that when Fast Connect is being >>>>> >>> used such a >>> >>> >>>>>> control channel should be established. As far as I understand the >>>>>> mechanism this is only required to switch to "normal" H.245 >>>>> >>>>> procedures. >>>>> >>>>> >>>>> >>>>>> It would seem that section 6.2.8 should be rephrased to >>>>> >>>>> make clear that >>>>> >>>>> >>>>> >>>>>> the H.245 control channel shall only be established when >>>>> >>>>> "normal" H.245 >>>>> >>>>> >>>>> >>>>>> procedures are being followed and not in the fast connect case. >>>>>> >>>>>> Frank >>>>> >>>>> -- >>>>> 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 >>> >>> >>> -- >>> 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 >> >> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >> For help on this mail list, send "HELP ITU-SG16" in a message to >> listserv(a)mailbag.intel.com > > > > -- > 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 -- 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: Firewall/NAT Crossing by H.323/H.248
by Steve Davies 22 Mar '01

22 Mar '01

Radhika & SG-16, I am in Minneapolis at the IETF and then in Bethesda at TIPHON22. If anyone would like to meet to discuss presenting this within SG16, then I can be contatced via email or my US cell. regards Steve Steve Davies Chief Technical Officer Ridgeway Systems and Software Email: mailto:sdavies@ridgeway-sys.com Web: www.ridgeway-sys.com Tel B: +44 (0) 118 938 1114 Tel H: +44 (0) 1285 770979 US cell: +1 512 771 7160 -----Original Message----- From: Roy, Radhika R, ALCOO [mailto:rrroy@att.com] Sent: 22 March 2001 04:18 To: ITU-SG16(a)mailbag.cps.INTEL.COM Cc: SDavies(a)Ridgeway-Sys.com Subject: Firewall/NAT Crossing by H.323/H.248 Folks: The following Internet draft (draft-davies-fw-nat-traversal-00.txt) deals with the proposal how H.323, H.248, and other applications (e.g., SIP) can cross the firewalls and NATs that do not require any changes in NATs and firewalls. I would request the members that it may be worthwhile to look into the proposal. (I would also propose the authors to see whether this can be presented in the ITU-T SG16 for possible examination. If attendance is a problem by the authors, whether Rapporteurs, as they did in the past, can help in collaboration with the authors in the presenting the proposal.) Best regards, Radhika R. Roy AT&T -----Original Message----- From: Steve Davies [mailto:SDavies@Ridgeway-Sys.com] Sent: Tuesday, March 20, 2001 8:45 PM To: mshore(a)cisco.com Cc: sob(a)harvard.edu; Steve Davies; midcom(a)ietf.com; sip(a)lists.bell-labs.com Subject: [SIP] Contribution to Midcom WG Melinda, Please excuse this email at the 11th hour. I've taking the liberty of copying it to the SIP and Midcom WGs in order to maximise the opportunity for discussion. Ridgeway Systems & Software have just completed an Internet draft for the traversal of non-protocol aware firewalls and NATs by session-oriented protocols such as H.323, SIP and H.248/Megaco. The draft is the culmination of the last 2 years of research and development within Ridgeway. The methods outlined in the draft have been implemented and proven to work. The main benefit to the Internet and Telecommunications community of the method outlined in this draft is that it is protocol agnostic - a single method can carry multiple protocols. Until it is available through the system it is available from http://www.vxserver.com/standards/ - username is 'standards' password is 'stevedavies'. The method outlined in the draft is probably ahead of where Midcom is at this point. I bring it to your attention now because I see similar initiatives within the SIP WG and because I would like to suggest to the Midcom WG that there are at least 2 classes of problem with potentially multiple solutions to address and capture. My basic premise is that it is not just a FW/NAT problem to address, but a FW/NAT + deployment set of problems. Class A: This class of problem is characterised by the fact that it is not possible or it is undesirable to upgrade the firewalls and NAT devices. Typically, NAPT is being used and Internet data and voice/video packets are transported on the same network (at some point, e.g. the LAN). Security must not be compromised. Examples deployments include residential and enterprise access to the Converged Network via an ISP. The Traversal method Ridgeway has developed addresses this class of problem. Class B: This class of problem is characterised by the fact that it is possible to upgrade existing or deploy new equipment to transport voice/video over IP. ALGs in firewalls and NATs is one solution to this class of problem. It seems that the approach within Midcom is to formalise and abstract ALGs such that one method suits all protocols. However, this doesn't address deployments in Class A. My colleague, Pete Cordell, and I will be in Minneapolis from Wednesday thru Friday and shall be attending the Midcom WG where we hope such requirements and issues will be raised and captured. Please feel free to contact me should you want to discuss this offline. Kindest regards Steve Steve Davies Chief Technical Officer Ridgeway Systems and Software Email: mailto:sdavies@ridgeway-sys.com Web: www.ridgeway-sys.com Tel B: +44 (0) 118 938 1114 Tel H: +44 (0) 1285 770979 US cell: +1 512 771 7160 _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementor's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to sip-implementors-request(a)cs.columbia.edu with "subscribe" in the body. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

Re: Conflicting text in H.323 concerning the requirement for esta blishing a H.245 control channel??
by Roni Even 22 Mar '01

22 Mar '01

all, I will try to give my view and history of the H.245. Before fast connect the issue of H.245 was simple. It is mandatory and after call setup the H.245 process with Master-slave and caps exchange was the only way. Annex F gave an option for a simple terminal with no h.245 mandatory support. This is the text in 6.2.8. When we added fast connect we opened the door for simple calls that finished the connection and establishment of media channels and did not need any more control to delay or skip H.245 and described in 8.1.7.2. Any side can initiate the opening of H.245 during the call. I have to agree that 6.2.8 is very strong about H.245 channel establishment. The reason for having it this way is to prevent implementers from understanding that an H.323 compliant endpoint can be implemented without support of H.245 if they are doing fast connect!!!. Call termination, before fast connect, was done through H.245. The call signaling channel can be closed before but H.245 must stay open during the call. 8.1.7.2 explain what to do if H.245 was not open (call signaling must stay open until call finish or opening of a separate H.245 channel) ( 8.1.7.2 2nd paragraph "When a call is established using the Fast Connect procedure, both endpoints shall keep the Q.931 Call Signaling Channel open until either the call is terminated or, for compatibility with older endpoints, until a separate H.245 connection is established.") I think that is what H.323 says. If you feel that this is not clear from the text give me a suggestion how to change it. It can be submitted to the next meeting (I am the new editor for H.323 V5). Regards Roni Even -----Original Message----- From: Chris Wayman Purvis [mailto:cwp@isdn-comms.co.uk] Sent: Thursday, March 22, 2001 1:27 PM To: Roni Even; Paul Jones Cc: ITU-SG16(a)mailbag.cps.INTEL.COM Subject: Re: Conflicting text in H.323 concerning the requirement for esta blishing a H.245 control channel?? Roni, Frank, Paul Jones et al, Having reread 8.1.7.2 (as referenced by Roni) I believe that Frank was right all along in saying there is a conflict. 8.1.7.2 saying that a device "may" establish an H.245 session at any point during a call is, I would argue, clearly at odds with 6.2.8 stating that such a session "shall" be established. After all, having not bothered to bring one up until an instant before the end of the call (clearly permitted by 8.1.7.2), why create one at that stage (except because 6.2.8 tells you to...)? There is an alternative reading: the implication of 6.2.8 is that some sort of H.245 session should start immediately (the start and end are the only "special" times in an ordinary call, so if you must start one it's pretty well a requirement to do it immediately). What I don't recall is whether it's permitted to drop an H.245 session during a call. I think it is. So is there an alternative reading, saying "start the H.245 channel at the beginning of the call, but you may drop and restart it as you like during the call"? I don't like this reading, though, it's probably the worst of all worlds. However I don't like the delay of setting up an H.245 session being added to the time taken to transmit the first DTMF tone in a call either... Paul, I think this really needs tidying up one way or another - I think it's a job for the implementors guide... Consensus currently seems to be against me, and to be that we should dump the relevant text in 6.2.8. Regards, Chris Roni Even wrote: > Chris, > About your comments > > 1. B can make A start H.245 by using facility message with reason > startH.245. See H.323 8.2.3 Switching to a separate H.245 connection. > 2. About 6.2.8 I agree that it states the H.245 shall be established, it > does not say when. The when is mentioned in 8.1.7.2. > Roni Even > > > -----Original Message----- > From: Chris Wayman Purvis [mailto:cwp@ISDN-COMMS.CO.UK] > Sent: Wednesday, March 21, 2001 3:31 PM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: Re: Conflicting text in H.323 concerning the requirement for > esta blishing a H.245 control channel?? > > > Roni, > > > >> H.323 mandates the support of H.245 for end points that comply with the >> standard. It does not mean, when using fast connect that it must be open >> immediately but can be opened at a later stage by any side. > > Except that it states exactly the opposite in the section under discussion. > > Also, consider the following scenario: > Two endpoints, A and B. B does not support tunnelled H.245. A calls B, > without giving any H.245 address in its Setup message. B accepts the call > on the basis of fastStart. No H.245 channel is set up, as you suggest. > Suppose now B wishes to send a UII (or any H.245 message) to A. It can't. > It can't set up the H.245 channel. A could set it up, but doesn't see the > need. > > >> The reason for >> mandating H.245 is to supply a control channel and is important for > > gateways > >> and MCUs as well as for control functions in point to point calls such as >> Video fast updates. H.323 annex F defines a simple end point that has > > H.245 > >> support as optional. >> I do not see the conflict between 6.2.8 and 8.1.7 if 6.2.8 means that you >> have to support it but not to actually open it as in simple fast connect >> calls. > > But 6.2.8 does not mean that. It clearly states that an H.245 channel SHALL > be opened. > > >> As for DTMF you can use the DTMF RTP payload to have it in band instead of >> H.245. > > If the person you're talking to happens to support this. Of course you > don't know whether or not it does if you haven't exchanged TCS. > > Please let's not break this! > > Regards, > Chris > > > >> -----Original Message----- >> From: Agboh, Charles [mailto:charles.agboh@EBONE.COM] >> Sent: Tuesday, March 20, 2001 6:59 PM >> To: ITU-SG16(a)MAILBAG.INTEL.COM >> Subject: Re: Conflicting text in H.323 concerning the requirement for >> esta blishing a H.245 control channel?? >> >> >> Chris, >> >> Part of establishing a "point-to-point" call involves opening 2 TCP >> connnections using the Fast Connect procedure as you described it. If > > that > >> is the case, then the extract from H.323v2 below is misleading(I believe). >> >> H.323v2: 8.1.7 Fast Connect Procedure >> >> "..... The Fast Connect procedure allows the endpoints to establish a > > basic > >> point-to-point call with as few as one round-trip message exchange, > > enabling > >> immediate media stream delivery upon call connection." >> >> BR, >> Charles >> >> >>> -----Original Message----- >>> From: Chris Wayman Purvis [mailto:cwp@ISDN-COMMS.CO.UK] >>> Sent: Tuesday, March 20, 2001 5:47 PM >>> To: ITU-SG16(a)MAILBAG.INTEL.COM >>> Subject: Re: Conflicting text in H.323 concerning the requirement for >>> esta blishing a H.245 control channel?? >>> >>> >>> Charles, >>> >>> It does NOT defeat ANY of the stated aims of FastConnect. >>> These aims were to get agreed media channels in both >>> directions open as >>> quickly as possible. Doing FastStart AND H.245 gives you your media >>> quickly, and means you have the power of H.245 thereon. >>> >>> In-band DTMF transfer may be used. If you happen to be using >>> a codec that >>> supports it. If you assume it when you're using an >>> unsuitable codec you'll >>> have a problem. Which is a reason for using H.245 capability >>> negotiation. >>> >>> Regards, >>> Chris >>> >>> Agboh, Charles wrote: >>> >>> >>> >>>> which defeats the whole point of having a Fast Connect >>> >>> procedure (FS + >>> >>> >>>> H.245). Why isn't in-band- DTMF transfer used instead (in FS)? >>>> >>>> -Charles >>>> >>>> >>>> >>>> >>>>> -----Original Message----- >>>>> From: Frank Derks [mailto:frank.derks@PHILIPS.COM] >>>>> Sent: Tuesday, March 20, 2001 4:40 PM >>>>> To: ITU-SG16(a)MAILBAG.INTEL.COM >>>>> Subject: Re: Conflicting text in H.323 concerning the >>>> >>> requirement for >>> >>> >>>>> establishing a H.245 control channel?? >>>>> >>>>> >>>>> Chris, >>>>> >>>>> I thought I was being clear enough, so let me try again. >>>>> 6.2.8/H.323 states >>>>> that an enpoint must open one (and exactly one) H.245 control >>>>> channel. When >>>>> Fast Connect is being used, I assume that the intention is >>>>> that no such control >>>>> channel is opened. >>>>> >>>>> To be compliant with 6.2.8/H,323 I would have to open a H.245 >>>>> control channel >>>>> irrespective of which type of H.245 procedures I will be >>>>> using. So if I intend >>>>> to use Fast Start (and assuming that the other party also >>>>> supports this), I >>>>> still have to open a H.245 control channel. >>>>> >>>>> Frank >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> cwp(a)isdn-comms.co.uk on 20-03-2001 15:17:14 >>>>> To: Frank Derks/HVS/BE/PHILIPS@EMEA2 >>>>> cc: ITU-SG16@mailbag.cps.INTEL.COM@SMTP >>>>> Subject: Re: Conflicting text in H.323 concerning the >>>>> requirement for establishing a H.245 control channel?? >>>>> Classification: >>>>> >>>>> Frank, >>>>> >>>>> Why do you consider this text to be "conflicting"? >>>>> Specifically, with what does it conflict? >>>>> >>>>> Regards, >>>>> Chris >>>>> >>>>> >>>>> >>>>> >>>>>> 6.2.8/H.323 states: "The endpoint shall establish exactly >>>>> >>> one H.245 >>> >>> >>>>>> Control Channel for each call that the endpoint is >>>>> >>>>> participating in." >>>>> >>>>> >>>>> >>>>>> 8.1.7/H.323 never states that when Fast Connect is being >>>>> >>> used such a >>> >>> >>>>>> control channel should be established. As far as I understand the >>>>>> mechanism this is only required to switch to "normal" H.245 >>>>> >>>>> procedures. >>>>> >>>>> >>>>> >>>>>> It would seem that section 6.2.8 should be rephrased to >>>>> >>>>> make clear that >>>>> >>>>> >>>>> >>>>>> the H.245 control channel shall only be established when >>>>> >>>>> "normal" H.245 >>>>> >>>>> >>>>> >>>>>> procedures are being followed and not in the fast connect case. >>>>>> >>>>>> Frank >>>>> >>>>> -- >>>>> 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 >>> >>> >>> -- >>> 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 >> >> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >> For help on this mail list, send "HELP ITU-SG16" in a message to >> listserv(a)mailbag.intel.com > > > > -- > 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 -- 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

1 0

Moving some text from H.323/8.2.3 to H.323/8.2?
by Frank Derks 22 Mar '01

22 Mar '01

Folks, the last paragraph in H.323/8.2.3 describes the actions to be taken in the case that both endpoints, simultaneously initiate the establishment of the H.245 Control Channel. However, this section is about _switching_ to a separate H.245 connection. Obviously, the actions apply to this situation, but they also apply to the situation when a separate H.245 Control Channel is "normally" set up. Wouldn't it, therefore, be better to move this paragraph to H.323/8.2? Frank ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

Re: Conflicting text in H.323 concerning the requirement for esta blishing a H.245 control channel??
by Frank Derks 22 Mar '01

22 Mar '01

Roni, I agree that 6.2.8 may be "somewhat vague" in stating exactly when the H.245 Control Channel must be established. Nevertheless, it states that it shall be established and this is considered to be irrespective of the channel actually being used! I.e. it does not matter whether fast connect, H.245 tunnelling or "normal H.245" is going to be used. 8.1.7.2 is no great help in answering the "when" question either, because it is left up to the Endpoint's discretion ("...at the time an endpoint deems it necessary...") to decide. I would consider this text to be misleading, because according to 6,2,8 the Endpoint must establish this connection. Frank Roni_e@ACCORD.CO.IL@SMTP@MAILBAG.INTEL.COM on 22-03-2001 10:37:35 Please respond to Roni_e@ACCORD.CO.IL@SMTP Sent by: ITU-SG16(a)MAILBAG.INTEL.COM To: ITU-SG16@MAILBAG.INTEL.COM@SMTP cc: Subject: Re: Conflicting text in H.323 concerning the requirement for esta blishing a H.245 control channel?? Classification: Chris, About your comments 1. B can make A start H.245 by using facility message with reason startH.245. See H.323 8.2.3 Switching to a separate H.245 connection. 2. About 6.2.8 I agree that it states the H.245 shall be established, it does not say when. The when is mentioned in 8.1.7.2. Roni Even -----Original Message----- From: Chris Wayman Purvis [mailto:cwp@ISDN-COMMS.CO.UK] Sent: Wednesday, March 21, 2001 3:31 PM To: ITU-SG16(a)MAILBAG.INTEL.COM Subject: Re: Conflicting text in H.323 concerning the requirement for esta blishing a H.245 control channel?? Roni, > H.323 mandates the support of H.245 for end points that comply with the > standard. It does not mean, when using fast connect that it must be open > immediately but can be opened at a later stage by any side. Except that it states exactly the opposite in the section under discussion. Also, consider the following scenario: Two endpoints, A and B. B does not support tunnelled H.245. A calls B, without giving any H.245 address in its Setup message. B accepts the call on the basis of fastStart. No H.245 channel is set up, as you suggest. Suppose now B wishes to send a UII (or any H.245 message) to A. It can't. It can't set up the H.245 channel. A could set it up, but doesn't see the need. > The reason for > mandating H.245 is to supply a control channel and is important for gateways > and MCUs as well as for control functions in point to point calls such as > Video fast updates. H.323 annex F defines a simple end point that has H.245 > support as optional. > I do not see the conflict between 6.2.8 and 8.1.7 if 6.2.8 means that you > have to support it but not to actually open it as in simple fast connect > calls. But 6.2.8 does not mean that. It clearly states that an H.245 channel SHALL be opened. > As for DTMF you can use the DTMF RTP payload to have it in band instead of > H.245. If the person you're talking to happens to support this. Of course you don't know whether or not it does if you haven't exchanged TCS. Please let's not break this! Regards, Chris > -----Original Message----- > From: Agboh, Charles [mailto:charles.agboh@EBONE.COM] > Sent: Tuesday, March 20, 2001 6:59 PM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: Re: Conflicting text in H.323 concerning the requirement for > esta blishing a H.245 control channel?? > > > Chris, > > Part of establishing a "point-to-point" call involves opening 2 TCP > connnections using the Fast Connect procedure as you described it. If that > is the case, then the extract from H.323v2 below is misleading(I believe). > > H.323v2: 8.1.7 Fast Connect Procedure > > "..... The Fast Connect procedure allows the endpoints to establish a basic > point-to-point call with as few as one round-trip message exchange, enabling > immediate media stream delivery upon call connection." > > BR, > Charles > >> -----Original Message----- >> From: Chris Wayman Purvis [mailto:cwp@ISDN-COMMS.CO.UK] >> Sent: Tuesday, March 20, 2001 5:47 PM >> To: ITU-SG16(a)MAILBAG.INTEL.COM >> Subject: Re: Conflicting text in H.323 concerning the requirement for >> esta blishing a H.245 control channel?? >> >> >> Charles, >> >> It does NOT defeat ANY of the stated aims of FastConnect. >> These aims were to get agreed media channels in both >> directions open as >> quickly as possible. Doing FastStart AND H.245 gives you your media >> quickly, and means you have the power of H.245 thereon. >> >> In-band DTMF transfer may be used. If you happen to be using >> a codec that >> supports it. If you assume it when you're using an >> unsuitable codec you'll >> have a problem. Which is a reason for using H.245 capability >> negotiation. >> >> Regards, >> Chris >> >> Agboh, Charles wrote: >> >> >>> which defeats the whole point of having a Fast Connect >> >> procedure (FS + >> >>> H.245). Why isn't in-band- DTMF transfer used instead (in FS)? >>> >>> -Charles >>> >>> >>> >>>> -----Original Message----- >>>> From: Frank Derks [mailto:frank.derks@PHILIPS.COM] >>>> Sent: Tuesday, March 20, 2001 4:40 PM >>>> To: ITU-SG16(a)MAILBAG.INTEL.COM >>>> Subject: Re: Conflicting text in H.323 concerning the >>> >> requirement for >> >>>> establishing a H.245 control channel?? >>>> >>>> >>>> Chris, >>>> >>>> I thought I was being clear enough, so let me try again. >>>> 6.2.8/H.323 states >>>> that an enpoint must open one (and exactly one) H.245 control >>>> channel. When >>>> Fast Connect is being used, I assume that the intention is >>>> that no such control >>>> channel is opened. >>>> >>>> To be compliant with 6.2.8/H,323 I would have to open a H.245 >>>> control channel >>>> irrespective of which type of H.245 procedures I will be >>>> using. So if I intend >>>> to use Fast Start (and assuming that the other party also >>>> supports this), I >>>> still have to open a H.245 control channel. >>>> >>>> Frank >>>> >>>> >>>> >>>> >>>> >>>> >>>> cwp(a)isdn-comms.co.uk on 20-03-2001 15:17:14 >>>> To: Frank Derks/HVS/BE/PHILIPS@EMEA2 >>>> cc: ITU-SG16@mailbag.cps.INTEL.COM@SMTP >>>> Subject: Re: Conflicting text in H.323 concerning the >>>> requirement for establishing a H.245 control channel?? >>>> Classification: >>>> >>>> Frank, >>>> >>>> Why do you consider this text to be "conflicting"? >>>> Specifically, with what does it conflict? >>>> >>>> Regards, >>>> Chris >>>> >>>> >>>> >>>>> 6.2.8/H.323 states: "The endpoint shall establish exactly >>>> >> one H.245 >> >>>>> Control Channel for each call that the endpoint is >>>> >>>> participating in." >>>> >>>> >>>>> 8.1.7/H.323 never states that when Fast Connect is being >>>> >> used such a >> >>>>> control channel should be established. As far as I understand the >>>>> mechanism this is only required to switch to "normal" H.245 >>>> >>>> procedures. >>>> >>>> >>>>> It would seem that section 6.2.8 should be rephrased to >>>> >>>> make clear that >>>> >>>> >>>>> the H.245 control channel shall only be established when >>>> >>>> "normal" H.245 >>>> >>>> >>>>> procedures are being followed and not in the fast connect case. >>>>> >>>>> Frank >>>> >>>> -- >>>> 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 >> >> >> -- >> 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 > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > For help on this mail list, send "HELP ITU-SG16" in a message to > listserv(a)mailbag.intel.com -- 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 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

Firewall/NAT Crossing by H.323/H.248
by Roy, Radhika R, ALCOO 21 Mar '01

21 Mar '01

Folks: The following Internet draft (draft-davies-fw-nat-traversal-00.txt) deals with the proposal how H.323, H.248, and other applications (e.g., SIP) can cross the firewalls and NATs that do not require any changes in NATs and firewalls. I would request the members that it may be worthwhile to look into the proposal. (I would also propose the authors to see whether this can be presented in the ITU-T SG16 for possible examination. If attendance is a problem by the authors, whether Rapporteurs, as they did in the past, can help in collaboration with the authors in the presenting the proposal.) Best regards, Radhika R. Roy AT&T -----Original Message----- From: Steve Davies [mailto:SDavies@Ridgeway-Sys.com] Sent: Tuesday, March 20, 2001 8:45 PM To: mshore(a)cisco.com Cc: sob(a)harvard.edu; Steve Davies; midcom(a)ietf.com; sip(a)lists.bell-labs.com Subject: [SIP] Contribution to Midcom WG Melinda, Please excuse this email at the 11th hour. I've taking the liberty of copying it to the SIP and Midcom WGs in order to maximise the opportunity for discussion. Ridgeway Systems & Software have just completed an Internet draft for the traversal of non-protocol aware firewalls and NATs by session-oriented protocols such as H.323, SIP and H.248/Megaco. The draft is the culmination of the last 2 years of research and development within Ridgeway. The methods outlined in the draft have been implemented and proven to work. The main benefit to the Internet and Telecommunications community of the method outlined in this draft is that it is protocol agnostic - a single method can carry multiple protocols. Until it is available through the system it is available from http://www.vxserver.com/standards/ - username is 'standards' password is 'stevedavies'. The method outlined in the draft is probably ahead of where Midcom is at this point. I bring it to your attention now because I see similar initiatives within the SIP WG and because I would like to suggest to the Midcom WG that there are at least 2 classes of problem with potentially multiple solutions to address and capture. My basic premise is that it is not just a FW/NAT problem to address, but a FW/NAT + deployment set of problems. Class A: This class of problem is characterised by the fact that it is not possible or it is undesirable to upgrade the firewalls and NAT devices. Typically, NAPT is being used and Internet data and voice/video packets are transported on the same network (at some point, e.g. the LAN). Security must not be compromised. Examples deployments include residential and enterprise access to the Converged Network via an ISP. The Traversal method Ridgeway has developed addresses this class of problem. Class B: This class of problem is characterised by the fact that it is possible to upgrade existing or deploy new equipment to transport voice/video over IP. ALGs in firewalls and NATs is one solution to this class of problem. It seems that the approach within Midcom is to formalise and abstract ALGs such that one method suits all protocols. However, this doesn't address deployments in Class A. My colleague, Pete Cordell, and I will be in Minneapolis from Wednesday thru Friday and shall be attending the Midcom WG where we hope such requirements and issues will be raised and captured. Please feel free to contact me should you want to discuss this offline. Kindest regards Steve Steve Davies Chief Technical Officer Ridgeway Systems and Software Email: mailto:sdavies@ridgeway-sys.com Web: www.ridgeway-sys.com Tel B: +44 (0) 118 938 1114 Tel H: +44 (0) 1285 770979 US cell: +1 512 771 7160 _______________________________________________ This list is for continuing development of the SIP protocol. The sip-implementor's list is the place to discuss implementation, and to receive advice on understanding existing sip. To subscribe to it, send mail to sip-implementors-request(a)cs.columbia.edu with "subscribe" in the body. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0