- sg16-avd - lists.packetizer.com

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

Re: Conflicting text in H.323 concerning the requirement for esta blishing a H.245 control channel??
by Agboh, Charles 20 Mar '01

20 Mar '01

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

3 2

Re: Conflicting text in H.323 concerning the requirement for esta blishing a H.245 control channel??
by Francois Audet 20 Mar '01

20 Mar '01

Fast start sole purpose is to get you talking as fast as possible. It is not to get you inputing digits as fast as possible. > -----Original Message----- > From: Agboh, Charles [mailto:charles.agboh@EBONE.COM] > Sent: Tuesday, March 20, 2001 7:49 AM > 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?? > > > 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 >

1 0

Re: Conflicting text in H.323 concerning the requirement for esta blishing a H.245 control channel??
by Agboh, Charles 20 Mar '01

20 Mar '01

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

2 1

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

20 Mar '01

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

2 1

Conflicting text in H.323 concerning the requirement for establishing a H.245 control channel??
by Frank Derks 20 Mar '01

20 Mar '01

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 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

2 1

Rapporteurs/Editors Manual - 1 Feb 2001 version
by OKUBO Sakae 20 Mar '01

20 Mar '01

Dear Fellow Rapporteurs, Editors and all, I have received from ITU-TSB the subject manual and placed it at the ftp site: http://standard.pictel.com/ftp/avc-site/manual21-02-01.zip Please carefully read it. I can say from the past experiences that the manual will help us when we face difficulty. Best regards, OKUBO Sakae *************************************************** Global Information and Telecommunication Institute Waseda University 29-7 Waseda University Bldg. 1-3-10 Nishi-Waseda, Shinjuku-ku, Tokyo 169-0051 Japan e-mail: sokubo(a)mn.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: A problem involving sending fast-start element in a facility message.
by Paul, Manoj 19 Mar '01

19 Mar '01

Praneeth, Refer to section 8.2.2 of H.323 Version 4. The last paragraph states that the reason should be set to "forwardedElements" as you indicated in your mail. -Manoj -----Original Message----- From: pmreddy(a)HSS.HNS.COM [mailto:pmreddy@HSS.HNS.COM] Sent: Wednesday, March 14, 2001 9:42 PM To: ITU-SG16(a)mailbag.cps.INTEL.COM Subject: A problem involving sending fast-start element in a facility message. Hi, I'm stuck with a particular problem, in the implementation of fast-start in the h323v2 implementation. The following are the details. If anybody is certain about the solution please do respond. Consider the scenario in which both calling end-point(A) and called end-point(B) support and prefer fast-start. Calls are gk-routed. A sends Setup message containing a fast-start element, to the Gatekeeper, which fowards it to B. Gatekeeper sends Call-Proceeding to A. B responds to the Setup sent by A, with a Call-Proceeding containing a fast-start element. Now, the Gatekeeper maps the fast-start element to a faststart element in the facility message. NOW, WHAT REASON SHOULD THE FACILITY MESSAGE HAVE?? I feel it should be "forwarded elements". But I am not very sure. If anybody knows about this, please respond immediately. Thanks Praneeth ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 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: FW: [VoIP-list] FW: [Fwd: AVT WG last call on RTP spec and pr ofil e]
by Roni Even 19 Mar '01

19 Mar '01

Glen, Were do I have to plea, Roni Even Acccord Networks -----Original Message----- From: Glen Freundlich [mailto:ggf@AVAYA.COM] Sent: Thursday, March 15, 2001 8:54 PM To: ITU-SG16(a)MAILBAG.INTEL.COM Subject: Re: FW: [VoIP-list] FW: [Fwd: AVT WG last call on RTP spec and profil e] I've made my plea to retain the G.723.1 payload format and codepoint, and would suggest that other vendors do the same. We may have some data collected from the IMTC H.323 interop test events that would reflect the number of vendors that have successfully interoperated using G.723.1 (and probably H.263, possibly the GSM coders), and might be able to provide those numbers. But, it's better for vendors to identify themselves. Glen Tom-PT Taylor wrote: It's simply a matter of implementors reporting. The key point is that the Working Group Chair has to know exactly which features of the RFC were tested and which not. In the case of the G723 payload type, there are no options to worry about: it's simply a matter of different implementations agreeing on RTP payload type 4 and subsequently transmitting RTP-encapsulated packets in accordance with G.723.1, using one frame (30 ms) per packet or such other value as specified by the A:ptime attribute. -----Original Message----- From: Rex Coldren [ mailto:coldrenr@AGCS.COM <mailto:coldrenr@AGCS.COM> ] Sent: Wednesday, March 14, 2001 2:37 PM To: ITU-SG16(a)MAILBAG.INTEL.COM Subject: Re: FW: [VoIP-list] FW: [Fwd: AVT WG last call on RTP spec and profil e] Francois, I believe you are correct. However, I am not familiar with how the IETF determines "interoperable implementations". Is is simply a matter of vendors reporting with whom they interoperate or is there some IETF-sponsored interop event that needs to be attended? Rex Francois Audet wrote: Guys,This payload type = 4 for G.723.1 has been in H.225.0 for many years. Don't we have many interoperable H.323 products using PT=4 for G.723?Won't it be a major interoperability problem if this payload type is removed from the A/V specification?????> -----Original Message----- > From: Simao Campos-Neto [ mailto:simao.campos@LABS.COMSAT.COM <mailto:simao.campos@LABS.COMSAT.COM> > < mailto:simao.campos@LABS.COMSAT.COM <mailto:simao.campos@LABS.COMSAT.COM> > ] > Sent: Friday, March 09, 2001 8:27 AM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: [Fwd: AVT WG last call on RTP spec and profile] > > > Dear colleagues, > > please see in the attached that audio payload formats for G.723.1, > called there "G723", has been removed from the latest RTP A/V profile > because of the lack on information that interoperable implementations of > them exist. Other audio payload formats have also been removed, e.g. > H263 (this is not the same as H263-2000), GSM-HR, GSM-EFR, If you know > of such implementations, there is still some VERY short time (less than > 2 weeks) before the IETF issues the repeat WG last call. Please provide > any such information directly to Stephen Casner <casner(a)acm.org>. > > Best regards, > Simao.

2 1

Report of the Launceston meeting AVD-2100
by OKUBO Sakae 19 Mar '01

19 Mar '01

Dear SG16 experts, The subject document has been uploaded to the /Incoming directory of the ftp site. It is an integration of Question reports and other administrative materials with editorial refinements. http://standard.pictel.com/ftp/avc-site/Incoming/AVD-2100.zip Please review it and return your advice if anything is wrong by the end of this week. Then it will be placed at /0103_Lau directory with status of "confirmed be the participants." Best regards, OKUBO Sakae *************************************************** Global Information and Telecommunication Institute Waseda University Waseda University Bldg. 29-7 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

I know it's been a while, but... 16921
by Kristie_S＠TEAMZEZZ.COM 19 Mar '01

19 Mar '01

1 0

Call for Participation: Internet Telephony Workshop 2001 April 2/3
by Henning Schulzrinne 18 Mar '01

18 Mar '01

Call for Participation 2nd IP Telephony Workshop April 2-3, 2001 - Columbia University, New York City http://www.fokus.gmd.de/events/iptel2001/ Objectives ---------- Internet telephony is rapidly evolving from research to design and deployment. The IP Telephony Workshop aims at bringing together researchers, developers, vendors and service providers active in this area and stimulate discussion on innovation, research, implementation, deployment experiences and future directions. Scope & Topics -------------- Original technical articles related to IP telephony will be presented, on topics ranging from quality of service, voice measurements, deployment experiences, accounting, security, service and feature interaction. The keynote address will be given by Prof. Dave Farber from the University of Pennsylvania. Important Dates --------------- Registration deadline March 23rd, 2001 Workshop April 2nd-3rd, 2001 iptel2001 Organizing Committee ------------------------------ Program Chair H. Schulzrinne Columbia University Program Committee M. Arango Sun Microsystems F. Baker Cisco W. Bauerfeld T-Nova G. Bond AT&T Research S. Bradner Harvard University G. Carle GMD FOKUS J. Crowcroft UCL C. Huitema Microsoft G. S. Kuo National Central University, Taiwan J. Kuthan GMD Fokus T. Magedanz IKV++ GmbH W. Marshall AT&T Research D. Medhi University of Missouri-Kansas City D. Oran Cisco J. Ott University of Bremen T. La Porta Bell Labs B. Rosen Marconi J. Rosenberg dynamicsoft H. Sinnreich MCI WorldCom R. Steinmetz Technical University of Darmstadt H. Stüttgen NEC CCRLE W. Wimmreuter Siemens L. Wolf University of Karlsruhe A. Wolisz Technical University of Berlin Contact Address --------------- Please send all your inquiries regarding iptel2001 to iptel2001(a)egroups.com. Registration ------------ The registration is now open. Participants are asked to register in advance at http://www.fokus.gmd.de/iptel2001/iptel2001/reg/ The registration deadline is March 23rd, 2001. See our registration website for more details. Accommodation ------------- New York city offers many hotels in different price ranges. Our accommodation web page contains pointers to some nearby hotels, however, attendees are responsible for booking their own accommodation. http://www.fokus.gmd.de/events/iptel2001/accommodation/ Exhibition ---------- To demonstrate how research and development become reality there will be an exhibition co-located with the workshop. A limited number of teams from industry as well as from academia and research will be given space to present their software and hardware, both products and prototypes. If you are interested in presenting your products or prototypes at iptel2001, please send an e-mail to iptel2001(a)egroups.com. Please include a short description of what you plan to display and special requirements if you have any. We will provide tables, power strips, Ethernet/802.11b wireless Internet connectivity (no firewall/NAT) and space for your booth if needed. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

IEEE/ACM Workshop on Mobile Software Agents- MATA 2001- Deadline-April 1.
by Ahmed Karmouch 18 Mar '01

18 Mar '01

[My apologies if you receive this more than once] ====================================================== MATA'2001 Third International Workshop on Mobile Agents for Telecommunication Applications August 14-16, 2001, Montréal, CANADA Co-sponsored by IEEE and ACM http://www.congresbcu.com/mata01/ CALL FOR PAPERS ================ Technical papers (4500 words maximum) describing previously unpublished, completed research or work in progress, not currently under review by another journal or conference, are solicited on the following topics: Mobile Agent Architecture and Models Agent Identification, Tracking and Persistence Agent-based Mobility Management in Mobile Networks Web Agent Systems Agent Integration with CORBA and TINA Active Networks and Mobile Agents Feature Interaction and Agents Mobile Agents Communication Language Security in Mobile Agent Systems Interactive Multimedia Presentation Agents Agent-based Electronic Commerce Agent-based Access to Legacy Services Managing QoS with agents Information Discovery and Gathering using agents Data Mining Agents Network Management Agents Policy-based Management using Mobile Agents Education and Applications of Mobile Agents Prototypes and Experience with Mobile Agents Seamless Messaging and Mobile Agents Accepted papers will be published in the conference proceedings. Papers of particular merit will be proposed for publication in IEEE Network Magazine. All paper submissions should have a cover page containing the title, names, email address and complete postal addresses (including telephone and fax numbers) for all authors. Please indicate the main author for the purpose of correspondence. The cover page should also provide an abstract (150 words maximum), and a list of keywords. Please include a statement stating that "when accepted, one of the authors will attend the Workshop to present the paper". Submissions should be sent by email to the program chair: Roch Glitho Ericcson Research Canada 8400, boul. Décarie Ville Mont-Royal, Québec, Canada, H4P 2N2 email: roch.glitho(a)lmc.ericsson.se Tel.: (514) 345-7000 ext. 2266 IMPORTANT DATES FOR PAPER SUBMISSION Full paper submission due April 1, 2001 Notification of acceptance May 15, 2001 Final paper due June 15, 2001 ======================================= ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

H.323 UUIE PDU
by Nehru, Archana 16 Mar '01

16 Mar '01

hi all, I have a question about the encoding of the UUIE PDU that is sent by an endpoint to its GateKeeper through an IRR message. Suppose we have the following scenario: EP1 (v3)-----------------------------GK(v3/v2)---------------------------------- ----EP2(v2) Here Ep1 is a version 3 client, Gk could either be v3 or V2. Ep2 is version 2. Now if EP1 sends out a UUIE PDU to the GK for all incoming messages from EP2, is it supposed to encode them as version 3 messages or version 2 messages? . The issue here is that the messages from EP2 will not contain V3 fields, so EP1 can forward the message coming from EP2 to the GK in one of the following ways: 1) EP1 forwards the EXACT copy of message coming from EP2. This obviously means that EP1 will forward a "version 2" message as a UUIE to the GK. Note that this means the GK gets an incoming version 2 message inspite of knowing that EP1 is a version 3 endpoint. 2) EP1 does not send an EXACT COPY of messages coming from EP2 as part of UUIEs. This means that EP1 decodes the v2 message from EP2, re-encodes it as a version 3 message and then sends this out to the GK. So the "information content" of the message sent to the Gk is the same as in the incoming PDU from EP2, but the message sent is version3. E.g: let us say EP2 sent a SETUP message to EP1, so its ASN part does not contain version 3 fields like "maintain connection" or "multipleCalls". So EP1 can do the following as indicated above: For choice 1(mentioned above): --------------------------------- It will forward the same SETP UUIE to Gk For Choice 2 (mentioned above): ------------------------------------- It will encode the incoming version 2 message as a version 3 message , i.e it will encode "maintain connection" and "multiple calls" BUT set their values to FALSE. This means that the information delivered to the Gk is the same( maintain connection or multiple calls not supported). The point to clarify here is whether : 1) it is acceptable that a GK sees a version 3 endpoint (EP1) sending out a version 2 message? 2) it is acceptable to GK that the EP1 has actually converted a version 2 message in to a version 3 message (choice no 2)? Pros and Cons of choice 1 and Choice 2: ----------------------------------------------------------- With choice 1, EP1 has to have logic for generating all backward compatible messages (e.g: if EP1 is a V4 endpoint, it should be capable of "encoding a v1, v2 and v3 message also. As the versions increase, this may become cumbersome to implement. With choice 2, EP1 can have the logic of encoding messages only for version 3. But the disadvantage here is that EP1 has to fill in values corresponding to all the fields added for version 3 in order to convert a version2 into a version 3 message. Also it is possible to fill corresponding values for fields that are "BOOLEANs" , but it may not be possible to fill "dummy values" for all "non-BOOLEAN" fields. E.g:what if the new fields added in version 3 is an integer? what dummy values will the GW fill in the version 3 message ? So the question here is , which one of the above choices is correct? My guess is choice 1) works better. Is that right? Any answers are greatly appreciated. -Archana ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

2 1

Re: FW: [VoIP-list] FW: [Fwd: AVT WG last call on RTP spec and pr ofil e]
by Tom-PT Taylor 15 Mar '01

15 Mar '01

It's simply a matter of implementors reporting. The key point is that the Working Group Chair has to know exactly which features of the RFC were tested and which not. In the case of the G723 payload type, there are no options to worry about: it's simply a matter of different implementations agreeing on RTP payload type 4 and subsequently transmitting RTP-encapsulated packets in accordance with G.723.1, using one frame (30 ms) per packet or such other value as specified by the A:ptime attribute. -----Original Message----- From: Rex Coldren [mailto:coldrenr@AGCS.COM] Sent: Wednesday, March 14, 2001 2:37 PM To: ITU-SG16(a)MAILBAG.INTEL.COM Subject: Re: FW: [VoIP-list] FW: [Fwd: AVT WG last call on RTP spec and profil e] Francois, I believe you are correct. However, I am not familiar with how the IETF determines "interoperable implementations". Is is simply a matter of vendors reporting with whom they interoperate or is there some IETF-sponsored interop event that needs to be attended? Rex Francois Audet wrote: Guys,This payload type = 4 for G.723.1 has been in H.225.0 for many years. Don't we have many interoperable H.323 products using PT=4 for G.723?Won't it be a major interoperability problem if this payload type is removed from the A/V specification?????> -----Original Message----- > From: Simao Campos-Neto [ mailto:simao.campos@LABS.COMSAT.COM <mailto:simao.campos@LABS.COMSAT.COM> > < mailto:simao.campos@LABS.COMSAT.COM <mailto:simao.campos@LABS.COMSAT.COM> > ] > Sent: Friday, March 09, 2001 8:27 AM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: [Fwd: AVT WG last call on RTP spec and profile] > > > Dear colleagues, > > please see in the attached that audio payload formats for G.723.1, > called there "G723", has been removed from the latest RTP A/V profile > because of the lack on information that interoperable implementations of > them exist. Other audio payload formats have also been removed, e.g. > H263 (this is not the same as H263-2000), GSM-HR, GSM-EFR, If you know > of such implementations, there is still some VERY short time (less than > 2 weeks) before the IETF issues the repeat WG last call. Please provide > any such information directly to Stephen Casner <casner(a)acm.org>. > > Best regards, > Simao.

2 1

A problem involving sending fast-start element in a facility message.
by pmreddy＠HSS.HNS.COM 15 Mar '01

15 Mar '01

Hi, I'm stuck with a particular problem, in the implementation of fast-start in the h323v2 implementation. The following are the details. If anybody is certain about the solution please do respond. Consider the scenario in which both calling end-point(A) and called end-point(B) support and prefer fast-start. Calls are gk-routed. A sends Setup message containing a fast-start element, to the Gatekeeper, which fowards it to B. Gatekeeper sends Call-Proceeding to A. B responds to the Setup sent by A, with a Call-Proceeding containing a fast-start element. Now, the Gatekeeper maps the fast-start element to a faststart element in the facility message. NOW, WHAT REASON SHOULD THE FACILITY MESSAGE HAVE?? I feel it should be "forwarded elements". But I am not very sure. If anybody knows about this, please respond immediately. Thanks Praneeth ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

Subscription Request
by pmreddy＠HSS.HNS.COM 15 Mar '01

15 Mar '01

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

1 0

Re: FW: [VoIP-list] FW: [Fwd: AVT WG last call on RTP spec and pr ofil e]
by Francois Audet 14 Mar '01

14 Mar '01

Guys, This payload type = 4 for G.723.1 has been in H.225.0 for many years. Don't we have many interoperable H.323 products using PT=4 for G.723? Won't it be a major interoperability problem if this payload type is removed from the A/V specification????? > -----Original Message----- > From: Simao Campos-Neto [ mailto:simao.campos@LABS.COMSAT.COM <mailto:simao.campos@LABS.COMSAT.COM> > < mailto:simao.campos@LABS.COMSAT.COM <mailto:simao.campos@LABS.COMSAT.COM> > ] > Sent: Friday, March 09, 2001 8:27 AM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: [Fwd: AVT WG last call on RTP spec and profile] > > > Dear colleagues, > > please see in the attached that audio payload formats for G.723.1, > called there "G723", has been removed from the latest RTP A/V profile > because of the lack on information that interoperable implementations of > them exist. Other audio payload formats have also been removed, e.g. > H263 (this is not the same as H263-2000), GSM-HR, GSM-EFR, If you know > of such implementations, there is still some VERY short time (less than > 2 weeks) before the IETF issues the repeat WG last call. Please provide > any such information directly to Stephen Casner <casner(a)acm.org>. > > Best regards, > Simao.

3 2

Re: FW: [VoIP-list] FW: [Fwd: AVT WG last call on RTP spec and pr ofil e]
by Francois Audet 14 Mar '01

14 Mar '01

I think that they just need people sending them emails saying "Company X demonstrated G.723.1 interoperability with Company Y". Some people have started to send those to Stephen Casner [casner(a)acm.org] He's looking for people who implemented the early version of H.263-1996 and GSM-HR and GSM-EFR. If you do, respond, because they will remove the payload type... -----Original Message----- From: Rex Coldren [mailto:coldrenr@agcs.com] Sent: Wednesday, March 14, 2001 11:37 AM To: Audet, Francois [SC2:4K02:EXCH] Cc: ITU-SG16(a)mailbag.cps.INTEL.COM Subject: Re: FW: [VoIP-list] FW: [Fwd: AVT WG last call on RTP spec and profil e] Francois, I believe you are correct. However, I am not familiar with how the IETF determines "interoperable implementations". Is is simply a matter of vendors reporting with whom they interoperate or is there some IETF-sponsored interop event that needs to be attended? Rex Francois Audet wrote: Guys,This payload type = 4 for G.723.1 has been in H.225.0 for many years. Don't we have many interoperable H.323 products using PT=4 for G.723?Won't it be a major interoperability problem if this payload type is removed from the A/V specification?????> -----Original Message----- > From: Simao Campos-Neto [ mailto:simao.campos@LABS.COMSAT.COM <mailto:simao.campos@LABS.COMSAT.COM> > < mailto:simao.campos@LABS.COMSAT.COM <mailto:simao.campos@LABS.COMSAT.COM> > ] > Sent: Friday, March 09, 2001 8:27 AM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: [Fwd: AVT WG last call on RTP spec and profile] > > > Dear colleagues, > > please see in the attached that audio payload formats for G.723.1, > called there "G723", has been removed from the latest RTP A/V profile > because of the lack on information that interoperable implementations of > them exist. Other audio payload formats have also been removed, e.g. > H263 (this is not the same as H263-2000), GSM-HR, GSM-EFR, If you know > of such implementations, there is still some VERY short time (less than > 2 weeks) before the IETF issues the repeat WG last call. Please provide > any such information directly to Stephen Casner <casner(a)acm.org>. > > Best regards, > Simao.

1 0

Re: Last Call for the SIP-H.323 Interworking Requirements draft
by Chip Sharp 13 Mar '01

13 Mar '01

Thanks. I assume since the actual work group mail list is the one given below, that the safest place to send comments (so they will be taken into account in the last call) is to this mail list. :-) Chip At 12:30 PM 3/13/2001 -0500, Roy, Radhika R, ALCOO wrote: >Hi, Chip and All: > >The comments can also be sent to the following email listing: > >sip-h323(a)yahoogroups.com > >This is the actual work group mailing list where most of the discussion is >being taken place for the SIP-H.323 Interworking. > >Best regards, >Radhika R. Roy > >-----Original Message----- >From: Roy, Radhika R, ALCOO >Sent: Tuesday, March 13, 2001 12:26 PM >To: 'Chip Sharp' >Cc: ITU-SG16(a)mailbag.cps.INTEL.COM >Subject: RE: Last Call for the SIP-H.323 Interworking Requirements draft > > >Hi, Chip and All: > >Any mailing list will be fine. > >However, I would prefer to send the comments in the SG16 mailing list >because although the respective WG Chairs in the IETF are planning to send >the notice in their mailing lists to receive comments soon (I am yet to know >exactly when they will notify it). > >Best regards, >Radhika R. Roy > >-----Original Message----- >From: Chip Sharp [mailto:chsharp@cisco.com] >Sent: Tuesday, March 13, 2001 11:47 AM >To: Roy, Radhika R, ALCOO >Cc: ITU-SG16(a)mailbag.cps.INTEL.COM >Subject: Re: Last Call for the SIP-H.323 Interworking Requirements draft > > >Roy, >Thanks for the notice. > >To which mail list should comments be sent (SG16, sip, iptel, megaco or >spirit)? > >Thanks, >Chip > >At 10:57 AM 3/13/2001 -0500, Roy, Radhika R, ALCOO wrote: > >Hi, Everyone: > > > >We are pleased to let you know that the last call for the following draft > >has been requested in the SIP, IPTEL, MEGACO and SPIRIT WG: > > > >http://search.ietf.org/internet-drafts/draft-agrawal-sip-h323-interworking- >r > >eqs-02.txt > > > >Authors: Hemant Agrawal, Radhika R. Roy, Vipin Palawat, Alan Johnston, > >Charles Agboh, David Wang, Kundan Singh, and Henning Schulzrinne > > > >Abstract: This document describes the requirements for the logical entity > >known as the SIP-H.323 Interworking Function (SIP-H.323 IWF) that will >allow > >the interworking between the SIP (Session Initiation Protocol) and H.323 > >protocols. > > > >Our objective is to obtain an informational RFC number for this draft. > > > >So, it is, therefore, requested to provide your comments by March 27, 2001. > > > >Best regards, > > > >Radhika R. Roy > > > >AT&T > >Room 3D-2C09 > >200 S. Laurel Avenue > >Middletown, NJ 07748, USA > >Tel: +1 732 420 1580 > >Email: rrroy(a)att.com > > > >~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > >For help on this mail list, send "HELP ITU-SG16" in a message to > >listserv(a)mailbag.intel.com > > >------------------------------------------------------------------- >Chip Sharp Consulting Engineering >Cisco Systems >------------------------------------------------------------------- ------------------------------------------------------------------- Chip Sharp Consulting Engineering Cisco Systems ------------------------------------------------------------------- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

Re: Last Call for the SIP-H.323 Interworking Requirements draft
by Roy, Radhika R, ALCOO 13 Mar '01

13 Mar '01

Hi, Chip and All: The comments can also be sent to the following email listing: sip-h323(a)yahoogroups.com This is the actual work group mailing list where most of the discussion is being taken place for the SIP-H.323 Interworking. Best regards, Radhika R. Roy -----Original Message----- From: Roy, Radhika R, ALCOO Sent: Tuesday, March 13, 2001 12:26 PM To: 'Chip Sharp' Cc: ITU-SG16(a)mailbag.cps.INTEL.COM Subject: RE: Last Call for the SIP-H.323 Interworking Requirements draft Hi, Chip and All: Any mailing list will be fine. However, I would prefer to send the comments in the SG16 mailing list because although the respective WG Chairs in the IETF are planning to send the notice in their mailing lists to receive comments soon (I am yet to know exactly when they will notify it). Best regards, Radhika R. Roy -----Original Message----- From: Chip Sharp [mailto:chsharp@cisco.com] Sent: Tuesday, March 13, 2001 11:47 AM To: Roy, Radhika R, ALCOO Cc: ITU-SG16(a)mailbag.cps.INTEL.COM Subject: Re: Last Call for the SIP-H.323 Interworking Requirements draft Roy, Thanks for the notice. To which mail list should comments be sent (SG16, sip, iptel, megaco or spirit)? Thanks, Chip At 10:57 AM 3/13/2001 -0500, Roy, Radhika R, ALCOO wrote: >Hi, Everyone: > >We are pleased to let you know that the last call for the following draft >has been requested in the SIP, IPTEL, MEGACO and SPIRIT WG: > >http://search.ietf.org/internet-drafts/draft-agrawal-sip-h323-interworking- r >eqs-02.txt > >Authors: Hemant Agrawal, Radhika R. Roy, Vipin Palawat, Alan Johnston, >Charles Agboh, David Wang, Kundan Singh, and Henning Schulzrinne > >Abstract: This document describes the requirements for the logical entity >known as the SIP-H.323 Interworking Function (SIP-H.323 IWF) that will allow >the interworking between the SIP (Session Initiation Protocol) and H.323 >protocols. > >Our objective is to obtain an informational RFC number for this draft. > >So, it is, therefore, requested to provide your comments by March 27, 2001. > >Best regards, > >Radhika R. Roy > >AT&T >Room 3D-2C09 >200 S. Laurel Avenue >Middletown, NJ 07748, USA >Tel: +1 732 420 1580 >Email: rrroy(a)att.com > >~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >For help on this mail list, send "HELP ITU-SG16" in a message to >listserv(a)mailbag.intel.com ------------------------------------------------------------------- Chip Sharp Consulting Engineering Cisco Systems ------------------------------------------------------------------- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0