- sg16-avd - lists.packetizer.com

Re: Third party registration/group registration
by Roy, Radhika R, ALCOO 30 Nov '00

30 Nov '00

Hi, Chris: Yes, I do. Regards, Radhika -----Original Message----- From: Chris Wayman Purvis [mailto:cwp@isdn-comms.co.uk] Sent: Thursday, November 30, 2000 12:01 PM To: ITU-SG16(a)mailbag.cps.intel.com Cc: Roy, Radhika R, ALCOO Subject: Re: Third party registration/group registration All, A clarification: I am sure Radhika will agree that when he refers to call setup this includes the case of incoming call setup as well as that of outgoing call setup! Regards, Chris "Roy, Radhika R, ALCOO" wrote: > > Hi, All: > > Let me add a little. > > An H.323 entity needs to have the capability to support RAS messages. > However, whether the RAS messages will be used or not before the call setup > is up to that entity. > > Best regards, > Radhika > > -----Original Message----- > From: Chris Wayman Purvis [mailto:cwp@ISDN-COMMS.CO.UK] > Sent: Thursday, November 30, 2000 8:56 AM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: Re: Third party registration/group registration > > Charles, > > This comes up on this list every now and again, and the answer doesn't > change. > The gatekeeper is an optional entity: TRUE. > RAS is optional: FALSE. > Endpoints (including gateways, IWFs, whatever you want to call them) have a > responsibility of trying to find one, registering with one if it can and > SHUTTING ITSELF DOWN if it manages to find one or more gatekeepers but fails > to > register. Only if all reasonable attempts to find a gatekeeper fail should > an > H.323 endpoint operate without an active registration. > > Let me give you the first couple of quotations from H.323 (I'm looking at v4 > determined, but I don't believe this has ever changed) I find on the > subject. > They're in section 7.2.2: > "As part of their configuration process, all endpoints shall register..." > "Registration shall occur before any calls are attempted and may occur > periodically as necessary (for example, at endpoint power-up)." > > Oh, and I suggest reading H.225.0 section 7.7 "Required Support of RAS > messages" as well. > > How else could things work? Consider the case where an endpoint (A) is > trying > to make a call to another endpoint (B). A issues an ARQ to its gatekeeper, > asking permission to try a call; the gatekeeper rejects the call (ARJ) on > some > reasonable grounds (possibly a conceptual "do not disturb" notice B has set > up > with its gatekeeper). A thinks "stuff this", unregisters from its > gatekeeper > ("we don't want to worry about all that boring RAS stuff if it's going to be > inconvenient to us") and sends the Setup message to B anyway - resulting (at > best) in an disgruntled B. > In other words, as soon as you allow endpoints to operate in the presence of > a > gatekeeper without registering with it and abiding by its decisions, you > might > as well write all xRJ messages out of the protocol entirely! > > If an endpoint is going to ignore RAS (and hence the standard) then why > should > it bother having anyone else register on its behalf? I refer you to > "Besides,..." in my last mail (which point you still haven't addressed). > > Regards, > Chris > > "Agboh, Charles" wrote: > > > > Chris, > > > > RAS IS OPTIONAL!!!! The GK is an OPTIONAL H.323 entity. > > > > charles > > > > -----Original Message----- > > From: Chris Wayman Purvis [mailto:cwp@ISDN-COMMS.CO.UK] > > Sent: Thursday, November 30, 2000 12:49 PM > > To: ITU-SG16(a)MAILBAG.INTEL.COM > > Subject: Re: Third party registration/group registration > > > > Charles, > > > > > The answer to your first question depends on the capabilities of D. > > > RAS is OPTIONAL so I could have a D device that does not implement RAS. > > > In my last email, the "third-party" would be a C device and > "first-party" > > > would be a D device (second-party is the A device) . > > RUBBISH! > > RAS is NOT optional. See Table 18/H.225.0. > > Besides, how would your crippled H.323 endpoint tell its RAS handler to > send > > the various RAS messages (like for instance ARQ to ask permission to make > a > > call...)? > > > > Regards, > > Chris > > > > > > > > Regards, > > > > > > charles > > > > > > -----Original Message----- > > > From: Chris Wayman Purvis [mailto:cwp@ISDN-COMMS.CO.UK] > > > Sent: Thursday, November 30, 2000 10:43 AM > > > To: ITU-SG16(a)MAILBAG.INTEL.COM > > > Subject: Re: Third party registration/group registration > > > > > > Charles, > > > > > > In your definition of "third-party" registration, consider a scenario > > > involving > > > four entities: an H.323 endpoint (A), an H.323 gatekeeper (B), a > > > gateway/IWF/registering-entity (C) and an entity of some sort on whose > > > behalf C > > > is registering (which we'll call D). Assuming that B is not routing > > > call-signalling, to which entity would A send its "Setup" message in > order > > > to > > > contact D? > > > > > > If the answer to this question is "C", this is well-covered in the > > standard > > > - > > > it is simply that the term "third-party registration" is not used for > it. > > > It > > > is simply viewed as C registering (potentially) lots of aliases. This > > > parallels Tom's second case. > > > If the answer is "D" (parallelling Tom's first case), then D is a very > odd > > > device (it can't be a full H.323 implementation or it would register for > > > itself). Why have a device implementing all of H.323 except gatekeeper > > > registration? After all, D would have to handle all the rest of RAS for > > > itself > > > - what would it be gaining by not registering on its own behalf? > > > > > > In the same scenario, to what entities are you referring, respectively, > as > > > the > > > "third-party" in your latest contribution? > > > > > > PLEASE clarify your definitions of "first-party" and "third-party" in > > cases > > > where you use these terms. I am certain that the ends you are trying to > > > achieve are perfectly possible - and not even that hard. Either will > > > result, I > > > believe, in a brief discussion with early consensus emerging. I believe > > the > > > problems, and the large amount of mail this is generating on this list, > > come > > > about entirely from the use of these terms without anyone understanding > > > exactly > > > what is meant by them. > > > > > > I agree with Tom that once we can agree on terminology we can move on > > quite > > > easily, and thank him for his usual high-quality clear-sighted input. > > > > > > Regards, > > > Chris > > > > > > ------------------------------------ > > > > > > The registration feature allows endpoints to bind their identities to > > > transport > > > address(es) at the GK. This is well described in H.323. When an > > endpoint > > > delegates another endpoint to perform this fearture on its behalf the > > > definition in H.323 is not there. The signaling that follows the > > > registration > > > whether, its > > > first or third-party may interrogate this binding. The third-party > > > registration feature can enhance the user experience much more than a > > normal > > > first-party > > > registration. I don't believe that the third-party has to be in the > > > signaling > > > flow that may follow the third-registration. I agree with Tom-PTs > view. > > > > > > Best regards, > > > > > > charles > > > > > > -----Original Message----- > > > From: Tom-PT Taylor [mailto:taylor@NORTELNETWORKS.COM] > > > Sent: Wednesday, November 29, 2000 7:39 PM > > > To: ITU-SG16(a)MAILBAG.INTEL.COM > > > Subject: Re: Third party registration/group registration > > > > > > Accurate terminology is obviously useful, but in this case, at > least, > > it > > > looks like something people can agree on and then move on. The more > > > important point seems to be the underlying distinction in > > requirements: > > > > > > -- register on behalf of H.323 endpoints > > > -- register on behalf of other endpoints > > > where I use "other" in the sense that the contact address is > > associated > > > with a non-H.323 signalling protocol. Purity is beside the point here > -- > > > it's the intention of the contact address that matters. Stating the > > > requirement in this way makes it obvious that the second requirement > > > includes > > > the need to state which protocol the endpoints expects to receive. > > > > > > There is another possibility, of course: use the same mechanism to > > > satisfy > > > all requirements, and allow for the possibility that the endpoint > > > supports multiple protocols. I think the design would be cleaner if > > we > > > took the approach: one contact point, one protocol -- even if it meant > > > repeating the contact information for each protocol a multiprotocol > > > endpoint supports. > > > > > > -- > > > 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 > > -- > 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

1 0

RE: Draft Status Update
by Callaghan, Robert 30 Nov '00

30 Nov '00

Paul, Based on the rule that the SIP-H.323 gateway appears to the endpoints as an H.323 firewall, then this will work. If there ever is any difference, then there is a problem I prefer to keep the "h323" designation. Bob -----Original Message----- From: Paul E. Jones [mailto:paulej@packetizer.com] Sent: Wednesday, November 29, 2000 8:33 PM To: Callaghan, Robert; ITU-SG16(a)mailbag.cps.intel.com Subject: Re: Draft Status Update Bob, I was not suggesting that we use the h323-ID field any differently-- it was the "h323" field inside the supportedProtocols choice. It is used to indicate a gateway that gateways to H.323 devices. However, it could serve just as well to say it gateways to any IP telephony protocol. That's why I suggested we call it "ipgw". Whether we do that or add a "sip" field makes no difference to me, but the latter option may take 2 years. Paul ----- Original Message ----- From: "Callaghan, Robert" <Robert.Callaghan(a)icn.siemens.com> To: "'Paul E. Jones'" <paulej(a)PACKETIZER.COM>; <ITU-SG16(a)mailbag.cps.intel.com> Sent: Wednesday, November 29, 2000 4:18 AM Subject: RE: Draft Status Update > Paul, > > I thought that the object of the IWF is to make the mixing of H.323 > terminals and SIP terminals transparent. > > However, I could see supporting SIP: URLs in the H.323 URL field along with > the H.323 URL. This would be possible under the URL rules for H.323v4. I > would also expect SIP terminals to support the H.323 URL. > > The does not solve the problem of true E.164 Ids or the TEL: URL. A true > E.164 Id does not allow for a service prefix. In that this is the normal Id > for voice calls, it must have a solution. An added problem is "Number > Portability" which tends to kill number grouping. > > I do not accept the concept of hidden usages of any field. Therefor I do > not support the use of the H.323ID field having a special format that > indicates a SIP connection. The H.323ID field should remain a free format > string. > > As it was stated, the gateway identifieds as having H.323 protocol is used > by firewalls doing H.323-H.323. Also voice indicates any gateway support > voice only connections. These should be mis-used. Adding a new protocol > type for a gateway would have to wait. > > Bob > > -----Original Message----- > From: Paul E. Jones [mailto:paulej@PACKETIZER.COM] > Sent: Tuesday, November 28, 2000 12:08 AM > To: ITU-SG16(a)mailbag.cps.intel.com > Subject: Re: Draft Status Update > > > Charles, > > I have discussed that idea with people before. > > I'm certainly open to the idea of adding a "sip" codepoint. However, since > H.323v4 was just approved, we'd have to wait for 2 years to get it in there. > We might be able to persuade folks to use the "h323" field for IP GWs and > document that in the H.323 Implementers Guide-- perhaps even changing the > name in v5 to "ipgw". > > Paul

2 1

ACIVS'2001
by d.d.giusto 30 Nov '00

30 Nov '00

************************************************ First Call For Papers --------------------- ACIVS'2001 3rd International Conference on ADVANCED CONCEPTS FOR INTELLIGENT VISION SYSTEMS Theory and Applications Baden-Baden (Germany) July 30 - August 3, 2001 (in conjunction with the 13th Int. Conf. on Systems Research, Informatics and Cybernetics) ************************************************ * CONFERENCE SCOPE ACIVS'2001 is the third of a series of conferences focusing on techniques for building adaptive, intelligent, safe and secure imaging systems. Papers are sollicited in the areas of image processing, pattern recognition, compression and algorithm assessment. Topics include (but are not limited to): - Image Processing (adaptive filtering and image restoration, adaptive segmentation, model-based algorithms, learning and nonlinear optimization, recurrent networks, multiresolution and scale-space theory, fractals and multifractals). - Pattern Recognition (statistical and structural pattern recognition, robust matching and parsing algorithms, application of automata and grammars). - Image and Video Compression Algorithms (wavelets, vector quantization, fractals, hybrid techniques, semantic image compression, watermarking). - Image Quality and Algorithmic Performance Evaluation (empirical evaluation techniques, image and video quality metrics [objective and perceptually based metrics], methods [ROC curves, etc.] and professional applications [medical, military, etc.]). * PROGRAM COMMITTEE Scott Acton, University of Virginia, Charlottesville, USA. Sos S. Agaian, University of Texas, San Antonio, USA. Mauro Barni, Universita' di Siena, Italy. Jacques Blanc-Talon, CTA, Arcueil, France. Philippe Bolon, LAMII, University of Savoie, Annecy, France. Don Bone, Mediaware Solutions, Canberra, Australia. Adam Borkowski, IFTP, Warsaw, Poland. Nikolaos Bourbakis, SUNY, Binghamton, USA. Horst Bunke, IAM, Bern, Switzerland. Jennifer Davidson, Iowa State University, Ames, USA. Edward J. Delp, Purdue University, USA. Georgy Gimel'Farb, University of Auckland, New Zealand. Daniele Giusto, University of Cagliari, Italy. Haomin Jin, University of Tokyo, Japan. Itsuo Kumazawa, Tokyo Institute of Technology, Japan. Hideo Kuroda, Nagasaki University, Japan. Bruce Litow, James Cook University, Townsville, Australia. Hitoshi Maekawa, Saitama University, Japan. Anamitra Makur, Indian Institute of Science, India. Masoud Mohammadian, University of Canberra, Australia. Wojciech S. Mokrzycki, IPIPAN, Warsaw, Poland. Annick Montanvert, UPMF, Grenoble, France. Naoya Ohta, Gunma University, Kiryu, Japan. Andrew P. Paplinski, Monash University, Melbourne, Australia. Marcin Paprzycki, University of Southern Mississippi, USA. Fernando Pereira, Instituto Superior Técnico, Lisboa, Portugal. Sylvie Philip, ENSEA, Cergy, France. Wilfried Philips, Vakgroep TELIN, Gent, Belgium. Moshe Porat, Dept. of Electrical Eng., Technion, Israel. Dan Popescu, CSIRO, Canberra, Australia. Georges Stamon, IARFA, Paris VI University, France. Wojciech Szpankowski, Purdue University, USA. Frederic Truchetet, Le2i, Le Creusot, France. Juan Jose Villanueva, CVC Univ. Autonoma de Barcelona, Spain. * IMPORTANT DATES Expression of interest: December 22, 2000 Tutorials proposal: December 22, 2000 Notification of tutorials acceptance: January 26, 2001 Deadline for paper submission: March 16, 2001 Notification of paper acceptance: May 4, 2001 Camera-ready manuscripts: June 1, 2001 Conference date: July 30/August 4, 2001 * EXPRESSION OF INTEREST Any person who intends to participate is invited to fill and send a reply card available at: http://www.etca.fr/CTA/ACIVS01 * CONFERENCE WEB SERVER Information about the conference can be found at: http://www.etca.fr/CTA/ACIVS01 * TUTORIAL SUBMISSION Tutorials are sollicited on the following topics: - adaptive segmentation - pattern recognition - video compression - watermarking - algorithmic performance evaluation * PAPER SUBMISSION AND REVIEW PROCESS All submissions will be reviewed by at least 2 members of the International Programme Committee; additional reviewers may be consulted if needed. The papers have to provide sufficient information about the background to the problem, clearly indicate the original contribution, evaluate the results, draw conclusions and provide adequate references. Full regular papers are 5 pages long (including figures) in times 11pt, A4. There will be an extra cost for any additional page. We strongly recommend the use of LaTex format; the style macros will be available soon at the conference web server (see above). Word documents or other formats are also accepted, but only accompanied by the corresponding PostScript files. Make sure that PS files are kept within reasonable limits. The papers can be sent by e-mail to either member of the steering committee. * PROCEEDINGS All accepted papers will be published in the Conference Proceedings. Selected papers will be considered for publication in a book series. * STEERING COMMITTEE Dr Jacques Blanc-Talon Dr Dan Popescu Geographie-Imagerie-Perception Mathematical and Information Science CTA/GIP CMIS/CSIRO 16 bis, Av. Prieur de la cote d'or, GPO Box 664 94114, Arcueil, FRANCE Canberra, ACT 2601, AUSTRALIA Jacques.Blanc-Talon(a)etca.fr Dan.Popescu(a)cmis.csiro.au ------------------------------------------------------------ Prof. Dr. D.D.Giusto ------------------------------------------------------------ e-mail: ddgiusto(a)unica.it - ddgiusto(a)ieee.org url: http://www.diee.unica.it/~pytheas ph: +39-070-675-5896/5866 - fax: +39-070-675-5900 mobile: +39-348-8757022 (RAM_CNIT: 302) mail: Department of Electrical and Electronic Engineering University of Cagliari, Piazza d'Armi, Cagliari 09123 Italy ------------------------------------------------------------ Die Strassen teilen sich auf, wie die Spitzen eines Sternes, Und jede ist der Heimweg. (H.Hesse) ------------------------------------------------------------

1 0

Re: Third party registration/group registration
by Roy, Radhika R, ALCOO 30 Nov '00

30 Nov '00

Hi, All: Let me add a little. An H.323 entity needs to have the capability to support RAS messages. However, whether the RAS messages will be used or not before the call setup is up to that entity. Best regards, Radhika -----Original Message----- From: Chris Wayman Purvis [mailto:cwp@ISDN-COMMS.CO.UK] Sent: Thursday, November 30, 2000 8:56 AM To: ITU-SG16(a)MAILBAG.INTEL.COM Subject: Re: Third party registration/group registration Charles, This comes up on this list every now and again, and the answer doesn't change. The gatekeeper is an optional entity: TRUE. RAS is optional: FALSE. Endpoints (including gateways, IWFs, whatever you want to call them) have a responsibility of trying to find one, registering with one if it can and SHUTTING ITSELF DOWN if it manages to find one or more gatekeepers but fails to register. Only if all reasonable attempts to find a gatekeeper fail should an H.323 endpoint operate without an active registration. Let me give you the first couple of quotations from H.323 (I'm looking at v4 determined, but I don't believe this has ever changed) I find on the subject. They're in section 7.2.2: "As part of their configuration process, all endpoints shall register..." "Registration shall occur before any calls are attempted and may occur periodically as necessary (for example, at endpoint power-up)." Oh, and I suggest reading H.225.0 section 7.7 "Required Support of RAS messages" as well. How else could things work? Consider the case where an endpoint (A) is trying to make a call to another endpoint (B). A issues an ARQ to its gatekeeper, asking permission to try a call; the gatekeeper rejects the call (ARJ) on some reasonable grounds (possibly a conceptual "do not disturb" notice B has set up with its gatekeeper). A thinks "stuff this", unregisters from its gatekeeper ("we don't want to worry about all that boring RAS stuff if it's going to be inconvenient to us") and sends the Setup message to B anyway - resulting (at best) in an disgruntled B. In other words, as soon as you allow endpoints to operate in the presence of a gatekeeper without registering with it and abiding by its decisions, you might as well write all xRJ messages out of the protocol entirely! If an endpoint is going to ignore RAS (and hence the standard) then why should it bother having anyone else register on its behalf? I refer you to "Besides,..." in my last mail (which point you still haven't addressed). Regards, Chris "Agboh, Charles" wrote: > > Chris, > > RAS IS OPTIONAL!!!! The GK is an OPTIONAL H.323 entity. > > charles > > -----Original Message----- > From: Chris Wayman Purvis [mailto:cwp@ISDN-COMMS.CO.UK] > Sent: Thursday, November 30, 2000 12:49 PM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: Re: Third party registration/group registration > > Charles, > > > The answer to your first question depends on the capabilities of D. > > RAS is OPTIONAL so I could have a D device that does not implement RAS. > > In my last email, the "third-party" would be a C device and "first-party" > > would be a D device (second-party is the A device) . > RUBBISH! > RAS is NOT optional. See Table 18/H.225.0. > Besides, how would your crippled H.323 endpoint tell its RAS handler to send > the various RAS messages (like for instance ARQ to ask permission to make a > call...)? > > Regards, > Chris > > > > > Regards, > > > > charles > > > > -----Original Message----- > > From: Chris Wayman Purvis [mailto:cwp@ISDN-COMMS.CO.UK] > > Sent: Thursday, November 30, 2000 10:43 AM > > To: ITU-SG16(a)MAILBAG.INTEL.COM > > Subject: Re: Third party registration/group registration > > > > Charles, > > > > In your definition of "third-party" registration, consider a scenario > > involving > > four entities: an H.323 endpoint (A), an H.323 gatekeeper (B), a > > gateway/IWF/registering-entity (C) and an entity of some sort on whose > > behalf C > > is registering (which we'll call D). Assuming that B is not routing > > call-signalling, to which entity would A send its "Setup" message in order > > to > > contact D? > > > > If the answer to this question is "C", this is well-covered in the > standard > > - > > it is simply that the term "third-party registration" is not used for it. > > It > > is simply viewed as C registering (potentially) lots of aliases. This > > parallels Tom's second case. > > If the answer is "D" (parallelling Tom's first case), then D is a very odd > > device (it can't be a full H.323 implementation or it would register for > > itself). Why have a device implementing all of H.323 except gatekeeper > > registration? After all, D would have to handle all the rest of RAS for > > itself > > - what would it be gaining by not registering on its own behalf? > > > > In the same scenario, to what entities are you referring, respectively, as > > the > > "third-party" in your latest contribution? > > > > PLEASE clarify your definitions of "first-party" and "third-party" in > cases > > where you use these terms. I am certain that the ends you are trying to > > achieve are perfectly possible - and not even that hard. Either will > > result, I > > believe, in a brief discussion with early consensus emerging. I believe > the > > problems, and the large amount of mail this is generating on this list, > come > > about entirely from the use of these terms without anyone understanding > > exactly > > what is meant by them. > > > > I agree with Tom that once we can agree on terminology we can move on > quite > > easily, and thank him for his usual high-quality clear-sighted input. > > > > Regards, > > Chris > > > > ------------------------------------ > > > > The registration feature allows endpoints to bind their identities to > > transport > > address(es) at the GK. This is well described in H.323. When an > endpoint > > delegates another endpoint to perform this fearture on its behalf the > > definition in H.323 is not there. The signaling that follows the > > registration > > whether, its > > first or third-party may interrogate this binding. The third-party > > registration feature can enhance the user experience much more than a > normal > > first-party > > registration. I don't believe that the third-party has to be in the > > signaling > > flow that may follow the third-registration. I agree with Tom-PTs view. > > > > Best regards, > > > > charles > > > > -----Original Message----- > > From: Tom-PT Taylor [mailto:taylor@NORTELNETWORKS.COM] > > Sent: Wednesday, November 29, 2000 7:39 PM > > To: ITU-SG16(a)MAILBAG.INTEL.COM > > Subject: Re: Third party registration/group registration > > > > Accurate terminology is obviously useful, but in this case, at least, > it > > looks like something people can agree on and then move on. The more > > important point seems to be the underlying distinction in > requirements: > > > > -- register on behalf of H.323 endpoints > > -- register on behalf of other endpoints > > where I use "other" in the sense that the contact address is > associated > > with a non-H.323 signalling protocol. Purity is beside the point here -- > > it's the intention of the contact address that matters. Stating the > > requirement in this way makes it obvious that the second requirement > > includes > > the need to state which protocol the endpoints expects to receive. > > > > There is another possibility, of course: use the same mechanism to > > satisfy > > all requirements, and allow for the possibility that the endpoint > > supports multiple protocols. I think the design would be cleaner if > we > > took the approach: one contact point, one protocol -- even if it meant > > repeating the contact information for each protocol a multiprotocol > > endpoint supports. > > > > -- > > 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 -- 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: Third party registration/group registration
by van Schelven, Richard 30 Nov '00

30 Nov '00

Charles, Only if a there is no Gateway! Ries > -----Original Message----- > From: Agboh, Charles [mailto:Charles.Agboh@GTS.COM] > Sent: Thursday, November 30, 2000 1:10 PM > To: ITU-SG16(a)mailbag.cps.intel.com > Subject: Re: Third party registration/group registration > > > Chris, > > RAS IS OPTIONAL!!!! The GK is an OPTIONAL H.323 entity. > > charles > > -----Original Message----- > From: Chris Wayman Purvis [mailto:cwp@ISDN-COMMS.CO.UK] > Sent: Thursday, November 30, 2000 12:49 PM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: Re: Third party registration/group registration > > > Charles, > > > The answer to your first question depends on the capabilities of D. > > RAS is OPTIONAL so I could have a D device that does not > implement RAS. > > In my last email, the "third-party" would be a C device and > "first-party" > > would be a D device (second-party is the A device) . > RUBBISH! > RAS is NOT optional. See Table 18/H.225.0. > Besides, how would your crippled H.323 endpoint tell its RAS > handler to send > the various RAS messages (like for instance ARQ to ask > permission to make a > call...)? > > Regards, > Chris > > > > > Regards, > > > > charles > > > > -----Original Message----- > > From: Chris Wayman Purvis [mailto:cwp@ISDN-COMMS.CO.UK] > > Sent: Thursday, November 30, 2000 10:43 AM > > To: ITU-SG16(a)MAILBAG.INTEL.COM > > Subject: Re: Third party registration/group registration > > > > Charles, > > > > In your definition of "third-party" registration, consider > a scenario > > involving > > four entities: an H.323 endpoint (A), an H.323 gatekeeper (B), a > > gateway/IWF/registering-entity (C) and an entity of some > sort on whose > > behalf C > > is registering (which we'll call D). Assuming that B is not routing > > call-signalling, to which entity would A send its "Setup" > message in order > > to > > contact D? > > > > If the answer to this question is "C", this is well-covered in the > standard > > - > > it is simply that the term "third-party registration" is > not used for it. > > It > > is simply viewed as C registering (potentially) lots of > aliases. This > > parallels Tom's second case. > > If the answer is "D" (parallelling Tom's first case), then > D is a very odd > > device (it can't be a full H.323 implementation or it would > register for > > itself). Why have a device implementing all of H.323 > except gatekeeper > > registration? After all, D would have to handle all the > rest of RAS for > > itself > > - what would it be gaining by not registering on its own behalf? > > > > In the same scenario, to what entities are you referring, > respectively, as > > the > > "third-party" in your latest contribution? > > > > PLEASE clarify your definitions of "first-party" and > "third-party" in > cases > > where you use these terms. I am certain that the ends you > are trying to > > achieve are perfectly possible - and not even that hard. > Either will > > result, I > > believe, in a brief discussion with early consensus > emerging. I believe > the > > problems, and the large amount of mail this is generating > on this list, > come > > about entirely from the use of these terms without anyone > understanding > > exactly > > what is meant by them. > > > > I agree with Tom that once we can agree on terminology we > can move on > quite > > easily, and thank him for his usual high-quality > clear-sighted input. > > > > Regards, > > Chris > > > > ------------------------------------ > > > > The registration feature allows endpoints to bind their > identities to > > transport > > address(es) at the GK. This is well described in H.323. When an > endpoint > > delegates another endpoint to perform this fearture on its > behalf the > > definition in H.323 is not there. The signaling that follows the > > registration > > whether, its > > first or third-party may interrogate this binding. The third-party > > registration feature can enhance the user experience much > more than a > normal > > first-party > > registration. I don't believe that the third-party has to > be in the > > signaling > > flow that may follow the third-registration. I agree with > Tom-PTs view. > > > > Best regards, > > > > charles > > > > -----Original Message----- > > From: Tom-PT Taylor [mailto:taylor@NORTELNETWORKS.COM] > > Sent: Wednesday, November 29, 2000 7:39 PM > > To: ITU-SG16(a)MAILBAG.INTEL.COM > > Subject: Re: Third party registration/group registration > > > > Accurate terminology is obviously useful, but in this > case, at least, > it > > looks like something people can agree on and then move on. The more > > important point seems to be the underlying distinction in > requirements: > > > > -- register on behalf of H.323 endpoints > > -- register on behalf of other endpoints > > where I use "other" in the sense that the contact address is > associated > > with a non-H.323 signalling protocol. Purity is beside the > point here -- > > it's the intention of the contact address that matters. > Stating the > > requirement in this way makes it obvious that the second requirement > > includes > > the need to state which protocol the endpoints expects > to receive. > > > > There is another possibility, of course: use the same > mechanism to > > satisfy > > all requirements, and allow for the possibility that the endpoint > > supports multiple protocols. I think the design would > be cleaner if > we > > took the approach: one contact point, one protocol -- even > if it meant > > repeating the contact information for each protocol a > multiprotocol > > endpoint supports. > > > > -- > > 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

1 0

Re: Draft Status Update
by Agboh, Charles 30 Nov '00

30 Nov '00

Bob, what sort of problem are you talking about? charles -----Original Message----- From: Callaghan, Robert [mailto:Robert.Callaghan@ICN.SIEMENS.COM] Sent: Thursday, November 30, 2000 1:38 PM To: ITU-SG16(a)MAILBAG.INTEL.COM Subject: Re: Draft Status Update Paul, Based on the rule that the SIP-H.323 gateway appears to the endpoints as an H.323 firewall, then this will work. If there ever is any difference, then there is a problem I prefer to keep the "h323" designation. Bob -----Original Message----- From: Paul E. Jones [mailto:paulej@packetizer.com] Sent: Wednesday, November 29, 2000 8:33 PM To: Callaghan, Robert; ITU-SG16(a)mailbag.cps.intel.com Subject: Re: Draft Status Update Bob, I was not suggesting that we use the h323-ID field any differently-- it was the "h323" field inside the supportedProtocols choice. It is used to indicate a gateway that gateways to H.323 devices. However, it could serve just as well to say it gateways to any IP telephony protocol. That's why I suggested we call it "ipgw". Whether we do that or add a "sip" field makes no difference to me, but the latter option may take 2 years. Paul ----- Original Message ----- From: "Callaghan, Robert" <Robert.Callaghan(a)icn.siemens.com> To: "'Paul E. Jones'" <paulej(a)PACKETIZER.COM>; <ITU-SG16(a)mailbag.cps.intel.com> Sent: Wednesday, November 29, 2000 4:18 AM Subject: RE: Draft Status Update > Paul, > > I thought that the object of the IWF is to make the mixing of H.323 > terminals and SIP terminals transparent. > > However, I could see supporting SIP: URLs in the H.323 URL field along with > the H.323 URL. This would be possible under the URL rules for H.323v4. I > would also expect SIP terminals to support the H.323 URL. > > The does not solve the problem of true E.164 Ids or the TEL: URL. A true > E.164 Id does not allow for a service prefix. In that this is the normal Id > for voice calls, it must have a solution. An added problem is "Number > Portability" which tends to kill number grouping. > > I do not accept the concept of hidden usages of any field. Therefor I do > not support the use of the H.323ID field having a special format that > indicates a SIP connection. The H.323ID field should remain a free format > string. > > As it was stated, the gateway identifieds as having H.323 protocol is used > by firewalls doing H.323-H.323. Also voice indicates any gateway support > voice only connections. These should be mis-used. Adding a new protocol > type for a gateway would have to wait. > > Bob > > -----Original Message----- > From: Paul E. Jones [mailto:paulej@PACKETIZER.COM] > Sent: Tuesday, November 28, 2000 12:08 AM > To: ITU-SG16(a)mailbag.cps.intel.com > Subject: Re: Draft Status Update > > > Charles, > > I have discussed that idea with people before. > > I'm certainly open to the idea of adding a "sip" codepoint. However, since > H.323v4 was just approved, we'd have to wait for 2 years to get it in there. > We might be able to persuade folks to use the "h323" field for IP GWs and > document that in the H.323 Implementers Guide-- perhaps even changing the > name in v5 to "ipgw". > > Paul ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

Re: Third party registration/group registration
by Agboh, Charles 30 Nov '00

30 Nov '00

Chris, The answer to your first question depends on the capabilities of D. RAS is OPTIONAL so I could have a D device that does not implement RAS. In my last email, the "third-party" would be a C device and "first-party" would be a D device (second-party is the A device) . Regards, charles -----Original Message----- From: Chris Wayman Purvis [mailto:cwp@ISDN-COMMS.CO.UK] Sent: Thursday, November 30, 2000 10:43 AM To: ITU-SG16(a)MAILBAG.INTEL.COM Subject: Re: Third party registration/group registration Charles, In your definition of "third-party" registration, consider a scenario involving four entities: an H.323 endpoint (A), an H.323 gatekeeper (B), a gateway/IWF/registering-entity (C) and an entity of some sort on whose behalf C is registering (which we'll call D). Assuming that B is not routing call-signalling, to which entity would A send its "Setup" message in order to contact D? If the answer to this question is "C", this is well-covered in the standard - it is simply that the term "third-party registration" is not used for it. It is simply viewed as C registering (potentially) lots of aliases. This parallels Tom's second case. If the answer is "D" (parallelling Tom's first case), then D is a very odd device (it can't be a full H.323 implementation or it would register for itself). Why have a device implementing all of H.323 except gatekeeper registration? After all, D would have to handle all the rest of RAS for itself - what would it be gaining by not registering on its own behalf? In the same scenario, to what entities are you referring, respectively, as the "third-party" in your latest contribution? PLEASE clarify your definitions of "first-party" and "third-party" in cases where you use these terms. I am certain that the ends you are trying to achieve are perfectly possible - and not even that hard. Either will result, I believe, in a brief discussion with early consensus emerging. I believe the problems, and the large amount of mail this is generating on this list, come about entirely from the use of these terms without anyone understanding exactly what is meant by them. I agree with Tom that once we can agree on terminology we can move on quite easily, and thank him for his usual high-quality clear-sighted input. Regards, Chris ------------------------------------ The registration feature allows endpoints to bind their identities to transport address(es) at the GK. This is well described in H.323. When an endpoint delegates another endpoint to perform this fearture on its behalf the definition in H.323 is not there. The signaling that follows the registration whether, its first or third-party may interrogate this binding. The third-party registration feature can enhance the user experience much more than a normal first-party registration. I don't believe that the third-party has to be in the signaling flow that may follow the third-registration. I agree with Tom-PTs view. Best regards, charles -----Original Message----- From: Tom-PT Taylor [mailto:taylor@NORTELNETWORKS.COM] Sent: Wednesday, November 29, 2000 7:39 PM To: ITU-SG16(a)MAILBAG.INTEL.COM Subject: Re: Third party registration/group registration Accurate terminology is obviously useful, but in this case, at least, it looks like something people can agree on and then move on. The more important point seems to be the underlying distinction in requirements: -- register on behalf of H.323 endpoints -- register on behalf of other endpoints where I use "other" in the sense that the contact address is associated with a non-H.323 signalling protocol. Purity is beside the point here -- it's the intention of the contact address that matters. Stating the requirement in this way makes it obvious that the second requirement includes the need to state which protocol the endpoints expects to receive. There is another possibility, of course: use the same mechanism to satisfy all requirements, and allow for the possibility that the endpoint supports multiple protocols. I think the design would be cleaner if we took the approach: one contact point, one protocol -- even if it meant repeating the contact information for each protocol a multiprotocol endpoint supports. -- 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: Third party registration/group registration
by Agboh, Charles 30 Nov '00

30 Nov '00

The registration feature allows endpoints to bind their identities to transport address(es) at the GK. This is well described in H.323. When an endpoint delegates another endpoint to perform this fearture on its behalf the definition in H.323 is not there. The signaling that follows the registration whether, its first or third-party may interrogate this binding. The third-party registration feature can enhance the user experience much more than a normal first-party registration. I don't believe that the third-party has to be in the signaling flow that may follow the third-registration. I agree with Tom-PTs view. Best regards, charles -----Original Message----- From: Tom-PT Taylor [mailto:taylor@NORTELNETWORKS.COM] Sent: Wednesday, November 29, 2000 7:39 PM To: ITU-SG16(a)MAILBAG.INTEL.COM Subject: Re: Third party registration/group registration Accurate terminology is obviously useful, but in this case, at least, it looks like something people can agree on and then move on. The more important point seems to be the underlying distinction in requirements: -- register on behalf of H.323 endpoints -- register on behalf of other endpoints where I use "other" in the sense that the contact address is associated with a non-H.323 signalling protocol. Purity is beside the point here -- it's the intention of the contact address that matters. Stating the requirement in this way makes it obvious that the second requirement includes the need to state which protocol the endpoints expects to receive. There is another possibility, of course: use the same mechanism to satisfy all requirements, and allow for the possibility that the endpoint supports multiple protocols. I think the design would be cleaner if we took the approach: one contact point, one protocol -- even if it meant repeating the contact information for each protocol a multiprotocol endpoint supports. > -----Original Message----- > From: Chris Wayman Purvis [ mailto:cwp@ISDN-COMMS.CO.UK <mailto:cwp@ISDN-COMMS.CO.UK> ] > Sent: Wednesday, November 29, 2000 4:45 AM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: Re: Third party registration/group registration > > > Charles, > > > The IWF (SIP-H.323 gateway) may terminate data (voice, > video, data) if it > > determines that the call cannot go from end-to-end. An > entity outside of > > the IWF may perform this function on behalf of the IWF. In > this case, this > > entity would be under the influence of the IWF. > Right. But my point is that for a registration is to be > called "third-party", > the IWF would have NO part in the proceedings other than the > registration > stage. You appear to be ignoring my point about what entity > is handling > H.225.0/Q.931 and/or H.245 signalling, which I feel is the > crucial part of what > would make a registration "third-party". > > > By *true* H.323 entities, I meant an entity that *speaks* > ONLY H.323. The > > IWF represents non-H.323 entities on the H.323 network. > Your "*true*" H.323 entity is an unusual beast indeed, given > that the majority > of H.323 devices around are either gateways (speaking another > protocol) or > PC-based (in which they generally "*speak*" large varieties > of protocols for > different purposes. In fact you restrict your definition of > "*true*" H.323 > entities to standalone IP phones. The fact that a device > supports protocols > other than H.323 does NOT make it any the less a "*true*" > H.323 device in any > reasonable definition of the word "true". > > > You are right, additive registration is NOT third-party > registration. Can > > it be used as a means to achieve scalable third-party registration? > Additive registrations can, I believe, be used to achieve > what you are trying > to achieve. I don't believe it can be used to achieve what > _I_ understand as > third-party registration. Our disagreement is around the > definition of the > term "third-party registration", the difference in our > definitions causing > confusion. > > I'll stick my neck out here and say that so far I believe > consensus is with my > definition (third-party registration as one H.323 entity > registering on behalf > of other entities which are H.323 except in their inability > or unwillingness to > register themselves with a gatekeeper) rather than yours (a > gateway registering > any device using any protocol with an H.323 gatekeeper). I > will then promptly > duck as I wait for the flack to fly! > > Regards, > Chris > > -----Original Message----- > > From: Chris Wayman Purvis [ mailto:cwp@isdn-comms.co.uk <mailto:cwp@isdn-comms.co.uk> ] > > Sent: Tuesday, November 28, 2000 10:36 AM > > To: Agboh, Charles; 'ITU-SG16(a)mailbag.cps.intel.com' > > Subject: Re: Third party registration/group registration > > > > All, > > > > Please please PLEASE can we have some more opinions on this > important > > definition, though. Charles and I simply disagree, and a > wider pool of > > opinion > > is needed in order for consensus to be reached. Although I > disagree with > > Charles's view I am willing to espouse it if that's the way > the majority of > > experts see things. Without further input we'll simply go > round in circles. > > > > Charles, All, > > > > I believe the fundamental question about "third-partyness" > in this context > > is > > what entity or entities will handle the H.225.0/Q.931 and or H.245 > > signalling. > > My understanding of the type of IWF you are talking about > (at least, the way > > I > > would implement such a thing!) is that the IWF terminates > all signalling, > > with > > RTP data going direct end to end. So it is the entity that > is performing > > the > > registration that will handle all signalling (namely what > you in your > > SIP-centred way call and IWF and I in my H.323-centred way > call a gateway!). > > > > To me this is a fair definition of first-party. The only > thing the IWF is > > not > > terminating is (voice, video and application) data. This > does not make the > > registration third-party in my opinion. There is no > assumption (as far as I > > can remember, anyway) that H.323 entities have to handle > their own RTP > > sessions > > - they are required only to exchange addresses to terminate > these sessions. > > > > Simple question: What is your definition of a "*true* H.323 > entity"? In > > what > > sense is your gateway/IWF not a "*true* H.323 entity"? > > > > Additive registration is NOT third-party registration by my > definition. > > > > Regards, > > Chris > > > > "Agboh, Charles" wrote: > > > > > > Hi Chris, > > > > > > I see what you mean. I think you are working under the > assumption that > > the > > > "..other H.323 entities" are *true* H.323 entites. The > IWF may give the > > > impression that they are H.323 entities but it doesn't > mean they are. > > > > > > In this model, I am assuming that the "third-party" is > receving all > > > signalling from the GK whether it (the GK) is in DRC or GRC mode. > > > > > > Q: Do I really care if the "..other H.323 entities" are > *true* H.323 > > > entities or not? A GK probably couldn't say if the > "first-party" > > being > > > registered (the entitry being registered as apposed to > the entity > > > receiving the registration) is a *true* H.323 entity or not. > > > A: It may be usefull. A GK can invoke a special feature > if it can > > > differentiate. > > > > > > H.323v4 defines the additive registration feature, which by your > > definition > > > is a third-party registration, right? So how does the GK > know that the > > > "first-party" is a *true* H.323 entitry? > > > > > > Best Regards, > > > charles > > > > > > -----Original Message----- > > > From: Chris Wayman Purvis [ mailto:cwp@isdn-comms.co.uk <mailto:cwp@isdn-comms.co.uk> ] > > > Sent: Monday, November 27, 2000 6:19 PM > > > To: Agboh, Charles > > > Cc: 'ITU-SG16(a)mailbag.cps.intel.com' > > > Subject: Re: Third party registration/group registration > > > > > > Charles, > > > > > > > My undstanding of "third-party" registration is the > same as yours. > > But, > > > in > > > > some applications a registration by the IWF may not be > on its own > > behalf. > > > These two sentences contradict each other. Please reread > my explanation > > of > > > my > > > understanding, as it is impossible for you to agree with > it and believe > > what > > > you have written in the second sentence above. > > > Unless I misunderstand your definition of an "IWF", which > I take to be > > > synonymous with a "gateway" as defined in the H.323 > series of standards. > > > > > > > H.323v4 provides this feature (a way to bypass the UDP > packet size > > > > limitation) for this same reason. > > > > > > > > Does it make sense to have this?, If no, then why not? > > > > > > > > SupportedProtocols ::= CHOICE > > > > { > > > > nonStandardData NonStandardParameter, > > > > h310 H310Caps, > > > > h320 H320Caps, > > > > h321 H321Caps, > > > > h322 H322Caps, > > > > h323 H323Caps, > > > > h324 H324Caps, > > > > voice > > > > ......., > > > > SIP SIPCaps > > > > } > > > This may make sense (and is what I meant when I referred to > > > "supportedPrefixes"). If this is a way forward that you > believe would be > > > useful for SIP gateways I would encourage you to write a > formal proposal > > to > > > an > > > ITU SG16 experts meeting on this basis. > > > > > > Regards, > > > Chris > > > > > > > -----Original Message----- > > > > From: Chris Wayman Purvis [ mailto:cwp@isdn-comms.co.uk <mailto:cwp@isdn-comms.co.uk> ] > > > > Sent: Monday, November 27, 2000 10:41 AM > > > > To: Agboh, Charles > > > > Cc: ITU-SG16(a)mailbag.cps.intel.com > > > > Subject: Re: Third party registration/group registration > > > > > > > > Charles, > > > > > > > > Wrong in my opinion, but I would hope other experts > would express their > > > > opinions too! The problem is I'm not sure whether this > is a question of > > > > understanding or of detailed definition of the phrase > "third party" in > > > this > > > > context. > > > > My understanding of the phrase "third party > registration" would be one > > > H.323 > > > > entity registering at a gatekeeper on behalf of other > H.323 entities. > > My > > > > understanding of the word "registration" of this > context is that it can > > > only > > > > apply to H.323 entities. In this context the IWF can > be considered to > > be > > > at > > > > the extreme edge of the H.323 network, so any > "registration" it does is > > on > > > > its > > > > own behalf. > > > > Maybe what you actually want is some equivalent to the > supportedPrefixes > > > > that > > > > arrived in version 2, for SIP gateways. > > > > Whatever we agree you want, though, I think it is worth > trying to reach > > > some > > > > consensus among experts in this group as to what the > phrase "third > > party" > > > > means > > > > in this context - as your understanding and mine are clearly in > > > > disagreement. > > > > > > > > Regards, > > > > Chris > > > > > > > > "Agboh, Charles" wrote: > > > > > > > > > > Chris, > > > > > > > > > > There are applications where an IWF can register an > EP from one domain > > > > into > > > > > another. This allows automatic visibility of EP > from one domain from > > > > > another. In this case the IWF is registering not > only itself but > > other > > > > EPs. > > > > > For this scenario, the third-party entity is the IWF, right? > > > > > > > > > > regards, > > > > > > > > > > charles > > > > -- > > > > 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 > > > > > > -- > > > 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 > > > > -- > > 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 >

2 1

RE: Draft Status Update
by Callaghan, Robert 29 Nov '00

29 Nov '00

Paul, I thought that the object of the IWF is to make the mixing of H.323 terminals and SIP terminals transparent. However, I could see supporting SIP: URLs in the H.323 URL field along with the H.323 URL. This would be possible under the URL rules for H.323v4. I would also expect SIP terminals to support the H.323 URL. The does not solve the problem of true E.164 Ids or the TEL: URL. A true E.164 Id does not allow for a service prefix. In that this is the normal Id for voice calls, it must have a solution. An added problem is "Number Portability" which tends to kill number grouping. I do not accept the concept of hidden usages of any field. Therefor I do not support the use of the H.323ID field having a special format that indicates a SIP connection. The H.323ID field should remain a free format string. As it was stated, the gateway identifieds as having H.323 protocol is used by firewalls doing H.323-H.323. Also voice indicates any gateway support voice only connections. These should be mis-used. Adding a new protocol type for a gateway would have to wait. Bob -----Original Message----- From: Paul E. Jones [mailto:paulej@PACKETIZER.COM] Sent: Tuesday, November 28, 2000 12:08 AM To: ITU-SG16(a)mailbag.cps.intel.com Subject: Re: Draft Status Update Charles, I have discussed that idea with people before. I'm certainly open to the idea of adding a "sip" codepoint. However, since H.323v4 was just approved, we'd have to wait for 2 years to get it in there. We might be able to persuade folks to use the "h323" field for IP GWs and document that in the H.323 Implementers Guide-- perhaps even changing the name in v5 to "ipgw". Paul ----- Original Message ----- From: "Agboh, Charles" <Charles.Agboh(a)gts.com> To: "'Paul E. Jones'" <paulej(a)packetizer.com>; "'Wong, Walter'" <wwong(a)nuera.com>; "'Roy, Radhika R, ALCOO'" <rrroy(a)att.com>; "Wang, Dave" <dwang(a)nuera.com>; <VPalawat(a)opuswave.com>; <kns10(a)cs.columbia.edu> Cc: <joon_maeng(a)vtel.com>; <hemantag(a)globespan.net>; <schulzrinne(a)cs.columbia.edu>; <alan.johnston(a)wcom.com>; "David Daiker" <ddaiker(a)cisco.com>; <ITU-SG16(a)mailbag.cps.intel.com> Sent: Monday, November 27, 2000 2:09 PM Subject: RE: Draft Status Update > Paul, > > The "sip" option shouild be used by an H.323-SIP gateway if such a > code-point was available ( following the example you gave, the "h323"option > would not be *correct* for an H.323-SIP gw ). In light of this, should > there be a code-point ("sip") for SIP (it is no longer a nonStandard > protocol)in H.323v5? > > charles > > -----Original Message----- > From: Paul E. Jones [mailto:paulej@packetizer.com] > Sent: Monday, November 27, 2000 7:56 PM > To: Agboh, Charles; 'Wong, Walter'; 'Roy, Radhika R, ALCOO'; Wang, Dave; > VPalawat(a)opuswave.com; kns10(a)cs.columbia.edu > Cc: joon_maeng(a)vtel.com; hemantag(a)globespan.net; > schulzrinne(a)cs.columbia.edu; alan.johnston(a)wcom.com; David Daiker > Subject: Re: Draft Status Update > > > Charles, > > "voice" is supposed to be used by voice gateways. > "h323" is supposed to be used by H.323-H.323 GWs (proxies). > > BTW, it should be noted that "supportedPrefixes" does *not* indicate what > E.164 prefixes a gateway can reach. some implementers have interpreted it > that way and others have interpreted it to indicate "service prefixes", such > as dialing "9" to reach an outside line. The latter definition is the > correct interpretation. > > H.323v4 now has fields that are there specifically for registering E.164 > address ranges. > > Paul > > ----- Original Message ----- > From: "Agboh, Charles" <Charles.Agboh(a)gts.com> > To: "'Wong, Walter'" <wwong(a)nuera.com>; "'Roy, Radhika R, ALCOO'" > <rrroy(a)att.com>; "Wang, Dave" <dwang(a)nuera.com>; <VPalawat(a)opuswave.com>; > <kns10(a)cs.columbia.edu> > Cc: <joon_maeng(a)vtel.com>; <hemantag(a)globespan.net>; > <schulzrinne(a)cs.columbia.edu>; <alan.johnston(a)wcom.com>; "David Daiker" > <ddaiker(a)cisco.com>; <paulej(a)cisco.com> > Sent: Friday, November 24, 2000 12:10 PM > Subject: RE: Draft Status Update > > > > Hi, > > > > > > A comment about > > RegistrationRequest.terminalType.gateway.protocol.h323.supportPrefixes IE. > > I saw an H.323-ISDN/voice gateway from Cisco (AS5300) that uses the > > RegistrationRequest.terminalType.gateway.protocol.voice.supportPrefixes IE > > instead of > > RegistrationRequest.terminalType.gateway.protocol.h323.supportPrefixes IE > to > > define the supported prefixes. > > > > Dave, can you comment on this? > > regards, > > > > charles > > > > > > > > -----Original Message----- > > From: Wong, Walter [mailto:wwong@nuera.com] > > Sent: Wednesday, November 22, 2000 3:13 AM > > To: 'Roy, Radhika R, ALCOO'; Agboh, Charles; Wong, Walter; Wong, Walter; > > Wang, Dave; VPalawat(a)opuswave.com; kns10(a)cs.columbia.edu > > Cc: joon_maeng(a)vtel.com; hemantag(a)globespan.net; > > schulzrinne(a)cs.columbia.edu; alan.johnston(a)wcom.com; David Daiker > > Subject: RE: Draft Status Update > > > > > > Hi Roy, Charles, and all, > > > > Thanks Charles for pointing out the use of supportedPrefix field. I think > > the IWF can use > > > RegistrationRequest.terminalType.gateway.protocol.h323.supportPrefixes.prefi > > x.e164 field of the RRQ to register an e164 prefix. This way, it's not > > non-standard any more. Using "SIP" as the non-standard supportedProtocol > > has some concerns. a) It's non-standard, b) The H.323 side will know the > > IWF is not a usual or "genuine" H.323 GW. This may violate the > requirement > > that the IWF should make both side unaware of the protocol difference. > > > > Charles, do you know if a prefix works for other type of aliases besides > > e.164? For example, what if we put ...supportedPrefix.prefix.url-id in > the > > RRQ? > > > > As far as standard is concerned, we should leave room for vendors to come > up > > with their own implementation of how this problem is solved. My proposed > > solution is just one of the possible ways to get around the registration > > issues. We shouldn't put that as a hard requirement for an IWF to have > > table lookup function. My suggestion is to put this as a recommendation > and > > use the word "MAY", not "MUST". > > > > -Walter > > > > -----Original Message----- > > From: Roy, Radhika R, ALCOO [mailto:rrroy@att.com] > > Sent: Tuesday, November 21, 2000 9:23 AM > > To: Agboh, Charles; Wong, Walter; Wong, Walter; Wang, Dave; > > VPalawat(a)opuswave.com; kns10(a)cs.columbia.edu > > Cc: joon_maeng(a)vtel.com; hemantag(a)globespan.net; > > schulzrinne(a)cs.columbia.edu; alan.johnston(a)wcom.com; David Daiker > > Subject: RE: Draft Status Update > > > > > > Hi, Charles, Walter and All: > > > > The non-standard protocol field may provide to do this. The puzzle is that > > it is still a "non-standard" and each vendor may implement differently. > > > > It appears that our SIP-H.323 Interworking standard likes to make this > > "non-standard" scheme as the standard one. > > > > Is that acceptable? Comments? > > > > Best regards, > > Radhika > > > > -----Original Message----- > > From: Agboh, Charles [mailto:Charles.Agboh@gts.com] > > Sent: Monday, November 20, 2000 4:54 AM > > To: Roy, Radhika R, ALCOO; Wong, Walter; Wong, Walter; Wang, Dave; > > VPalawat(a)opuswave.com; kns10(a)cs.columbia.edu > > Cc: joon_maeng(a)vtel.com; hemantag(a)globespan.net; > > schulzrinne(a)cs.columbia.edu; alan.johnston(a)wcom.com; David Daiker > > Subject: RE: Draft Status Update > > > > > > Hi Roy, Walter and all: > > > > Walter's proposed solution is sound for H.323 v2 compatibility. In the > > RegistrationRequest.terminalType.gateway.protocol.h323 | > > [nonstandardprotocol].supportPrefixes.prefix.e164 field of the RRQ the IWF > > can register an e164 prefix. H.323 gateways register their prefixes using > > this field. The supported protocols in this example should not be h323 > > (?), instead, it should be "sip" for the IWF. The nonstandardprotocol > > field will allow the IWF to register "sip" has the supported protocol. > > The "prefix" that the IWF registers should be well-known. > > > > regards, > > > > charles > > > > > > -----Original Message----- > > From: Roy, Radhika R, ALCOO [mailto:rrroy@att.com] > > Sent: Saturday, November 18, 2000 8:52 AM > > To: Wong, Walter; Agboh, Charles; Wong, Walter; Wang, Dave; > > VPalawat(a)opuswave.com; kns10(a)cs.columbia.edu > > Cc: joon_maeng(a)vtel.com; hemantag(a)globespan.net; > > schulzrinne(a)cs.columbia.edu; alan.johnston(a)wcom.com; David Daiker > > Subject: RE: Draft Status Update > > > > > > Hi, Walter: > > > > Yes, your proposal is a good one considering all the options that we have. > > In fact, the grouping of the addresses shall be the main aspect of the > > registration by the IWF in any situation. > > > > For E.164, it is clear. Let all members provide comments for grouping of > the > > SIP addresses as proposed by you. In fact, we are assuming that the IWF > will > > have the capabilities for the local address translation using the table > > look-up, and grouping of the SIP-side address may be another feature. The > > question is: How far we can make this acceptable from the standard point > of > > view? > > > > Best regards, > > Radhika > > > > -----Original Message----- > > From: Wong, Walter [mailto:wwong@nuera.com] > > Sent: Friday, November 17, 2000 2:48 PM > > To: Roy, Radhika R, ALCOO; Agboh, Charles; Wong, Walter; Wang, Dave; > > VPalawat(a)opuswave.com; kns10(a)cs.columbia.edu > > Cc: joon_maeng(a)vtel.com; hemantag(a)globespan.net; > > schulzrinne(a)cs.columbia.edu; alan.johnston(a)wcom.com; David Daiker > > Subject: RE: Draft Status Update > > > > > > Hi Radhika, Charles and all, > > > > Regarding the 2 solutions we have discussed, both have backward > compatility > > problems. H.323 v4 case is obvious. The lightweight RRQ with KeepAlive > > solution also require modification of current GK behavior by implementing > > the new recommendation. So the IWF would still have problem when working > > with existing GK's out there that did not implement the new > recommendation. > > > > So as far as backward compatibility is concerned, each of the 2 solutions > > don't have advantage over the other. Because of the tricky nature of the > > lightweight RRQ approach, I tend to agree working towards H.323 V4 may be > a > > better way to go. > > > > But we still need to address the issue when we integrate the IWF into an > > existing H.323 v2 GK domain. One possible way is to pre-register all SIP > > endpoints to the GK by static GK configuration. This is not a good > solution > > because of the static nature of the approach. It loses the dynamic power > of > > reqister and unregister. It also require reconfiguring the GK whenever > > there is a change on the SIP side. > > > > Another thinking that I have is to put some address mapping intellegence > in > > the IWF. The IWF maps a SIP url to a specific e.164 number. The good > thing > > about e.164 number is we can group the numbers with a prefix. For > example, > > in the GK domain, we can assign a number prefix for the SIP network that's > > on the other side of the IWF. Then pre-register all numbers with this > > prefix (i.e. any number with area code 123) by static GK configuration. > > This way, any destination number with the prefix 123 will get routed by > the > > GK to the IWF. The IWF then maps the number to a SIP url when connecting > > the call to the SIP side. From the SIP side, the IWF assigns a number > with > > prefix 123 for each SIP endpoint that registers with the IWF and keeps the > > assignment in a local map. When a SIP call is going through the IWF to > the > > H323 side, the IWF uses this number from the local map with prefix 123 as > > the source alias when connecting the call with the GK. > > > > The advantage of this approach is it doesn't require registering of all > the > > SIP endpoints individually. Instead, register them as a group. > > > > This approach would work the best if we can find a way to do registration > > with a group of numbers using some range or wildcard notion in the RRQ. > It > > would solve the problem of statically configuring the GK and allow for > > dynamic registeration. Unfortunately I wasn't able to find such a way > from > > the current H.323 documentation. Does anyone aware of any such way to do > > group registration without specifying individual aliases in the RRQ? > > > > Thanks, > > > > -Walter > > > > -----Original Message----- > > From: Roy, Radhika R, ALCOO [mailto:rrroy@att.com] > > Sent: Thursday, November 16, 2000 11:29 PM > > To: Agboh, Charles; 'Wong, Walter'; Wang, Dave; VPalawat(a)opuswave.com; > > kns10(a)cs.columbia.edu > > Cc: joon_maeng(a)vtel.com; hemantag(a)globespan.net; > > schulzrinne(a)cs.columbia.edu; alan.johnston(a)wcom.com; David Daiker > > Subject: RE: Draft Status Update > > > > > > Hi, Charles and Walter: > > > > The solution is in sight to proceed with standardization form H.323 > version > > 2 to H.323 Version 4 as quickly as possible keeping in mind that we have > > problems now. > > > > Radhika > > > > -----Original Message----- > > From: Agboh, Charles [mailto:Charles.Agboh@gts.com] > > Sent: Thursday, November 16, 2000 6:06 AM > > To: 'Wong, Walter'; Roy, Radhika R, ALCOO; Wang, Dave; > > VPalawat(a)opuswave.com; kns10(a)cs.columbia.edu > > Cc: joon_maeng(a)vtel.com; hemantag(a)globespan.net; > > schulzrinne(a)cs.columbia.edu; alan.johnston(a)wcom.com; David Daiker > > Subject: RE: Draft Status Update > > > > > > Hi Walter, > > > > > > You are right, use of lightweight RRQ for additive registration is tricky. > > The keyword is "SHOULD". The recommeded behaivior for a GK is to ignore > the > > terminalAlias field in the lightweight RRQ. So what can we do to allow > the > > SIP EP to register its aliase via the IWF without using non-standard "tips > > and tricks". > > > > - Base the I-D on H.323 v4: Backward compatibility problem (not > really > > an option) > > - Recommend that the GK SHOULD NOT replace new alias address (for the > > same transport address) and SHOULD NOT ignore the terminalAlias fields in > a > > lightweight RRQ for a given endpointIdentifier when communicating with > the > > IWF or any other type of gateway. This will be backward compatible with > > H.323v2 (as you can see below: ".....should...." ). > > > > *Section 7.2.2/H.323v2 > > ------------------------------- > > " If the Gatekeeper receives an RRQ having the same > > Transport Address as a previous RRQ and a different alias address, it > should > > replace the translation table entries." > > > > *Section 7.9.1/H.225v2 > > ------------------------------- > > > > "A gatekeeper in receipt of RRQ with a keepAlive field set to TRUE > > should ignore fields other than endpointIdentifier, gatekeeperIdentifier, > > tokens, and timeToLive." > > > > comments or suggestions? > > regards, > > > > charles > > > > > > -----Original Message----- > > From: Wong, Walter [mailto:wwong@nuera.com] > > Sent: Wednesday, November 15, 2000 7:48 PM > > To: Agboh, Charles; 'Roy, Radhika R, ALCOO'; Wang, Dave; > > VPalawat(a)opuswave.com; kns10(a)cs.columbia.edu > > Cc: joon_maeng(a)vtel.com; hemantag(a)globespan.net; > > schulzrinne(a)cs.columbia.edu; alan.johnston(a)wcom.com; Wong, Walter > > Subject: RE: Draft Status Update > > > > > > Hi Charles, > > > > You right, one RRQ may not be able to carry all aliases because of the > size > > limitation of the packet. So we have to find a way for the IWF to > register > > all the SIP endpoints in seperate RRQs. > > > > The use of lightweight RRQ is tricky and need more thought. When TTL > > expires, an RRQ should contain the "KeepAlive" field set to TRUE. Here is > > the description of KeepAlive from section 7.9.1 of H225v3: > > > > " > > keepAlive - If set to TRUE indicates that the endpoint has sent this RRQ > as > > a "keep alive". An endpoint can send a lightweight RRQ consisting of only > > rasAddress, keepAlive, endpointIdentifier, gatekeeperIdentifier, tokens, > and > > timeToLive. A gatekeeper in receipt of RRQ with a keepAlive field set to > > TRUE should ignore fields other than endpointIdentifier, > > gatekeeperIdentifier, tokens, and timeToLive. The rasAddress in a > > lightweight RRQ shall only be used by a gatekeeper as the destination for > an > > RRJ when the endpoint is not registered. > > " > > > > The tricky part about this is: when KeepAlive is TRUE, the GK should > ignore > > the Terminal Alias field (3rd sentense above). However, if we set the > > KeepAlive to FALSE, the GK may treat it as a new RRQ and thus, overwrites > > the previously registerred aliases. This GK behavior may be vendor > > implementation dependent. Apparently, the GK I did the experiment with > was > > doing it this way. > > > > The additive registration feature in H323 V4 seems to be a promissing > > solution. However, it brings up a backward compatibility issue when the > IWF > > is talking to a H323 V2 GK. > > > > -Walter > > > > -----Original Message----- > > From: Agboh, Charles [mailto:Charles.Agboh@gts.com] > > Sent: Wednesday, November 15, 2000 7:48 AM > > To: 'Roy, Radhika R, ALCOO'; Wang, Dave; VPalawat(a)opuswave.com; > > kns10(a)cs.columbia.edu > > Cc: joon_maeng(a)vtel.com; hemantag(a)globespan.net; > > schulzrinne(a)cs.columbia.edu; alan.johnston(a)wcom.com; Wong, Walter > > Subject: RE: Draft Status Update > > > > > > Hi, > > > > The problem with registering multiple alias addresses with a GK was this: > > the size limitation of a UDP packet just prevented that from happening. > A > > solution around this limitation is to use the additive registration > feature > > in H.323 v4. Unfortunately our current I-D is based on H.323V2. An > > interim solution may be the use of the lighweight RRQ. With this > > approache, each time an RRQ TTL expires the IWF may send more aliases to > the > > GK (should fill the terminal alias field). The problem with this > > solution is that the RRQ is no longer *lightweight*. The second problem > > which walter mentioned is that the GK overwrites previous terminalAlias > (It > > shoudn't since the terminal alias's are different while the transport > > address remains the same). > > > > Best regards, > > > > charles > > > > -----Original Message----- > > From: Roy, Radhika R, ALCOO [mailto:rrroy@att.com] > > Sent: Wednesday, November 15, 2000 7:38 AM > > To: Wang, Dave; VPalawat(a)opuswave.com; Agboh, Charles; > > kns10(a)cs.columbia.edu > > Cc: joon_maeng(a)vtel.com; hemantag(a)globespan.net; > > schulzrinne(a)cs.columbia.edu; alan.johnston(a)wcom.com; Wong, Walter > > Subject: RE: Draft Status Update > > > > > > Hi, Walter and All: > > > > I guess that you may be right. > > > > Can we change the behavior like this: Can we not say that the IWF sends > all > > aliases together each time it sends the RRQ? > > > > It may be a crude method. What else could we do? The other solution may be > > to make GK and IWF collocated. We may not like to do this as well. > > > > All members are requested to provide their comments as well. > > > > Best regards, > > Radhika > > > > -----Original Message----- > > From: Wang, Dave [mailto:dwang@nuera.com] > > Sent: Tuesday, November 14, 2000 3:33 AM > > To: VPalawat(a)opuswave.com; Roy, Radhika R, ALCOO; Charles.Agboh(a)gts.com; > > kns10(a)cs.columbia.edu > > Cc: joon_maeng(a)vtel.com; hemantag(a)globespan.net; > > schulzrinne(a)cs.columbia.edu; alan.johnston(a)wcom.com; dwang(a)nuera.com; > > Wong, Walter > > Subject: RE: Draft Status Update > > > > > > Hi All, > > > > Here is some comments from my colleague Walter Wong, who is our expert on > > SIP/H.323 IWF. You may want to replace me by Walter in the e-mail list, > and > > consider recruiting him in this work and drop me off it. > > > > David Wang > > > > > -----Original Message----- > > > From: Wong, Walter > > > Sent: Monday, November 13, 2000 7:29 PM > > > To: Wang, Dave > > > Subject: RE: Draft Status Update > > > > > > > > > Hi Dave, > > > > > > The registration scheme specified here for registering with > > > GK my not work. The IWF may not be able to send seperate RRQ > > > for each SIP end point. Here is the description from > > > H.225v3, section 7.9.1 on RRQ: > > > > > > "terminalAlias -This optional value is a list of alias > > > addresses, by which other terminals may identify this > > > terminal. If the terminalAlias is null, or an E.164 address > > > is not present, an E.164 address may be assigned by the > > > gatekeeper, and included in the RCF. If an email-ID is > > > available for the endpoint, it should be registered. Note > > > that multiple alias addresses may refer to the same transport > > > addresses. All of the endpoint's aliases shall be included in > > > each RRQ." > > > > > > The scheme seems to be violating the last sentense. > > > > > > I've also done some experiment with the Cisco 3600 GK. If I > > > send RRQ with 8000001 then another RRQ with 8000002 from the > > > same GW, the GK loses the 8000001 as soon as the RRQ for > > > 8000002 is received. > > > > > > We have to find another way to get around this unless we can > > > change the GK behavior. Packing all individual endpoint > > > aliases in 1 RRQ is not a good solution because it's limited > > > by the size of the RRQ. I have not been successful in > > > finding a way to specify a range of aliases or use wildcard > > > in the RRQ. Although not flexible, statically configuring > > > the GK may be a workable solution. > > > > > > -Walter > > > > > -----Original Message----- > > > From: VPalawat(a)opuswave.com [mailto:VPalawat@opuswave.com] > > > Sent: Monday, November 13, 2000 1:33 PM > > > To: rrroy(a)att.com; VPalawat(a)opuswave.com; Charles.Agboh(a)gts.com; > > > kns10(a)cs.columbia.edu > > > Cc: joon_maeng(a)vtel.com; hemantag(a)globespan.net; > > > schulzrinne(a)cs.columbia.edu; alan.johnston(a)wcom.com; dwang(a)nuera.com > > > Subject: RE: Draft Status Update > > > > > > > > > Hi All, > > > > > > A quick update on the draft status: > > > > > > * Last minute changes and some error corrections to Call Flow > > > diagrams. > > > > > > * More additions to other sections are under progress. > > > * Draft formatting is under progress. > > > > > > Please let me know if you have any comments/suggestions on my > > > approach/opinion. > > > > > > Best Regards > > > Vipin > > > > > > > > > > > > > > > -----Original Message----- > > > From: Roy, Radhika R, ALCOO [mailto:rrroy@att.com] > > > Sent: Sunday, November 12, 2000 10:53 AM > > > To: VPalawat(a)opuswave.com; Charles.Agboh(a)gts.com; > > > kns10(a)cs.columbia.edu > > > Cc: joon_maeng(a)vtel.com; hemantag(a)globespan.net; > > > schulzrinne(a)cs.columbia.edu; alan.johnston(a)wcom.com; dwang(a)nuera.com > > > Subject: RE: Draft Status Update > > > > > > << File: Registration_v3.txt >> << File: > > > Requirements.txt > > > >> Hi, Vipin and All: > > > > > > I am enclosing two files for the following two sections: > > > > > > 1. Registration and Address Resolution (Version 3) > > > 2. SIP-H.323 Interworking Requirements > > > > > > For address resolution, I have an issue as follows: > > > > > > Does the IWF will send the response (200 OK) to > > > the SIP EP > > > after receiving > > > the REGISTER message because we do not assume > > > that IWF may > > > act as the > > > register server? > > > > > > Based on comments provided earlier, I have > > > modified the last > > > flow diagram > > > assuming that the IWF and the H.323 GK are NOT > > > co-located. > > > Still, I have > > > been able to use the OPTIONS message to resolve the > > > H.323-side addresses. > > > However, I have not been able to use the > > > OPTIONS message for > > > resolving the > > > SIP-side addresses if the ARQ/LRQ messages come from the > > > H.323-side unless > > > IWF and GK are co-located. > > > > > > Can anyone help to find examples for this > > > scenario using the > > > OPTIONS > > > message? > > > > > > The OPTIONS message is an extremely useful one and H.323 > > > does NOT have any > > > equivalent one. (It silently provides all the > > > capabilities > > > of the SIP > > > entities without going through needless > > > negotiations like > > > H.245 messages.) > > > > > > I am yet to show all fields of all messages in > > > the message > > > flows. Hope to > > > refine those later. > > > > > > For the SIP-H.323 Interworking Requirements > > > section, I also > > > like to have > > > your comments. > > > > > > Best regards, > > > Radhika > > > > > > PS: I have apprised the ITU-T SG16 Q.13/16 > > > meeting delegates > > > about the > > > progress of our SIP-H.323 Interworking works in > > > the IETF. > > > > > > > > > > > > -----Original Message----- > > > From: VPalawat(a)opuswave.com > > > [mailto:VPalawat@opuswave.com] > > > Sent: Friday, November 10, 2000 2:45 PM > > > To: VPalawat(a)opuswave.com; Charles.Agboh(a)gts.com; > > > kns10(a)cs.columbia.edu > > > Cc: joon_maeng(a)vtel.com; hemantag(a)globespan.net; > > > schulzrinne(a)cs.columbia.edu; alan.johnston(a)wcom.com; > > > dwang(a)nuera.com; > > > Roy, Radhika R, ALCOO > > > Subject: RE: Draft Status Update > > > > > > > > > Hi All, > > > > > > Here is a quick update on the status of the draft. > > > > > > * Detailed description of calls along > > > with message > > > details in call > > > flow diagrams is complete. > > > > > > * Basic message handling Section is > > > nearly complete. > > > > > > Following sections are still under progress: > > > > > > * State m/c diagram. Lot of work is there. > > > > > > > > > I would like to have your opinion on the state > > > of the draft. > > > I also want to know that if in case we were unable to > > > complete the state m/c > > > on time, then > > > Can we include it in the "TO DO" list and later > > > we will add > > > it into the next > > > release of the same draft. > > > This is because I don't want to put everything > > > in a rush. > > > This will impact > > > the quality of the document. > > > We have already written the draft in a short > > > time, so I feel > > > if we were > > > unable to complete that section, > > > Then it is better to put it in the "TO DO" list > > > and better > > > concentrate on > > > the review of the existing stuff. > > > > > > I would like to have your opinions on this. > > > > > > Please let me know if you have any > > > comments/suggestions on > > > my > > > approach/opinion. > > > > > > Best Regards > > > Vipin > > > > > > > > > > > > -----Original Message----- > > > From: Palawat, Vipin > > > Sent: Thursday, November 09, > > > 2000 10:02 AM > > > To: 'Agboh, Charles'; 'Kundan Singh' > > > Cc: Palawat, Vipin; > > > joon_maeng(a)vtel.com; > > > hemantag(a)globespan.net; schulzrinne(a)cs.columbia.edu; > > > alan.johnston(a)wcom.com; > > > dwang(a)nuera.com; rrroy(a)att.com > > > Subject: Draft Status Update > > > > > > Hi All, > > > > > > Here is a quick update on the > > > status of the > > > draft. > > > > > > Following section were almost complete: > > > * Detailed description and call message details in > > > call flow diagrams. > > > > > > Following sections are > > > still under > > > progress: > > > * Basic Call Handling. > > > * State m/c > > > > > > Please let me know if you have any > > > comments/suggestions on > > > my approach/opinion. > > > > > > Best Regards > > > Vipin > > > > > > > > > > > > -----Original > > > Message----- > > > From: Agboh, Charles > > > [mailto:Charles.Agboh@gts.com] > > > Sent: > > > Wednesday, November > > > 08, 2000 3:05 PM > > > To: 'Kundan Singh' > > > Cc: > > > 'VPalawat(a)opuswave.com'; > > > ddaiker(a)cisco.com; joon_maeng(a)vtel.com; > > > hemantag(a)globespan.net; > > > schulzrinne(a)cs.columbia.edu; alan.johnston(a)wcom.com; > > > dwang(a)nuera.com; > > > rrroy(a)att.com > > > Subject: > > > RE: Message > > > Mapping: > > > SIP-H.323 interworking > > > > > > Hi, > > > > > > Can we keep Dave > > > (ddaiker(a)cisco.com) in the > > > discussion. > > > > > > > > > regards > > > charles > > > -----Original > > > Message----- > > > From: Kundan Singh > > > [mailto:kns10@cs.columbia.edu] > > > Sent: > > > Wednesday, November > > > 08, 2000 6:57 PM > > > To: Agboh, Charles > > > Cc: > > > 'VPalawat(a)opuswave.com'; > > > ddaiker(a)cisco.com; joon_maeng(a)vtel.com; > > > hemantag(a)globespan.net; > > > schulzrinne(a)cs.columbia.edu; > > > alan.johnston(a)wcom.com; > > > dwang(a)nuera.com; > > > rrroy(a)att.com > > > Subject: RE: Message > > > Mapping: SIP-H.323 > > > interworking > > > > > > > > > > > > > > > > Are we going > > > to constrain > > > an > > > implementation to an algorithm for matching > > > SDP > > > > capability > > > description ang > > > H.245? I think > > > we should leave it open and say > > > > that there must be at > > > least an > > > intersection and that intersection must > > > > include G.711. > > > > > > I agree that it > > > should be > > > open, however, we > > > can provide a > > > guideline for > > > finding such > > > intersection with > > > examples. > > > Secondly, > > > "intersection must > > > include G.711" > > > is not > > > acceptable, I think, > > > especially if the SIP > > > side > > > does not > > > support G.711 and > > > the IWF provider > > > is capable of doing > > > conversion between > > > G.711 (from > > > H.323 EP) and > > > some other codec > > > (from SIP UA). > > > Having G.711 always > > > mandatory will > > > eventually cause the > > > SIP calls > > > (without G.711) to > > > be always > > > rejected. > > > > > > > H.225.0/Q.931 > > > part (not > > > UUIE): > > > > > > I think, we can > > > ignore the > > > unnecessary > > > fields in > > > this phase and > > > can look at > > > it in the next > > > phase, if needed. > > > Some of the fields (like > > > Caller Number) can > > > be used > > > in IWF. > > > > > > Will send more comments > > > soon. > > > > > > Thanks and regards > > > > > > Kundan > > > > > > > Can we get perspective > > > from vendors on > > > this (ie. bearer cap..) > > > > > > > > vipin, how do > > > you want to > > > proceed? > > > > regards, > > > > > > > > charles > > > > -----Original > > > Message----- > > > > From: > > > VPalawat(a)opuswave.com > > > [mailto:VPalawat@opuswave.com] > > > > Sent: > > > Wednesday, November > > > 08, 2000 5:45 PM > > > > To: Agboh, Charles; > > > ddaiker(a)cisco.com > > > > Cc: > > > joon_maeng(a)vtel.com; > > > hemantag(a)globespan.net; > > > > > > > schulzrinne(a)cs.columbia.edu; > > > alan.johnston(a)wcom.com; dwang(a)nuera.com; > > > > rrroy(a)att.com; > > > VPalawat(a)opuswave.com; > > > kns10(a)cs.columbia.edu > > > > Subject: RE: Message > > > Mapping: SIP-H.323 > > > interworking > > > > > > > > > > > > Hi All, > > > > > > > > A quick update on the > > > status of the > > > current draft. > > > > > > > > * Work in > > > still going > > > on in the > > > following sections. > > > > * > > > Description of Call > > > Flow diagrams. > > > > * State m/c > > > > * Basic Message > > > Handling. > > > > > > > > As soon as > > > the draft comes > > > to a complete > > > and good shape, I will forward it > > > > to all the editors. > > > > > > > > I will keep > > > on updating > > > the status twice a > > > day. > > > > > > > > Please let me > > > know if you > > > have any > > > comments/suggestions on my > > > > approach/opinion. > > > > > > > > Best Regards > > > > Vipin > > > > > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > From: > > > Agboh, Charles > > > [mailto:Charles.Agboh@gts.com] > > > > Sent: > > > Tuesday, November > > > 07, 2000 11:19 AM > > > > To: > > > 'David Daiker' > > > > Cc: > > > Agboh, Charles; > > > joon_maeng(a)vtel.com; > > > > > > > hemantag(a)globespan.net; > > > schulzrinne(a)cs.columbia.edu; > > > alan.johnston(a)wcom.com; > > > > dwang(a)nuera.com; > > > rrroy(a)att.com; > > > VPalawat(a)opuswave.com; > > > kns10(a)cs.columbia.edu > > > > Subject: > > > RE: Message > > > Mapping: SIP-H.323 interworking > > > > > > > > > > > Hi David, > > > > > > > > > > > I will open > > > the discussion > > > tomorrow with my contribution > > > > which is mostly > > > > > > > derived from > > > Kundan Singh's > > > work (Its going to be a long > > > > night). I think > > > > > > > it will be > > > difficult to come > > > up with something consistent > > > > before the 16th > > > > > > > but, we will > > > try. > > > > > > > > > > > We welcome > > > your > > > participation in this discussion. > > > > > > > > Best > > > regards, > > > > > > > > charles, > > > > > > > > > > > -----Original Message----- > > > > > > > From: David > > > Daiker > > > [mailto:ddaiker@cisco.com] > > > > Sent: > > > Tuesday, November 07, > > > 2000 4:50 PM > > > > > > > To: Agboh, > > > Charles > > > > > > > Cc: David > > > Daiker > > > > > > > Subject: Re: > > > Message > > > Mapping: SIP-H.323 interworking > > > > > > > > > > > > > > > > > > > Hi Charles, > > > > > > > > > > > Sorry for > > > the late response, > > > I am just starting to look at > > > > mapping > > > headers/parms/ies > > > between sip/isup/h323. > > > > > > > > > > > And quite > > > honestly, other > > > than the obvious (calling, called, > > > > bearer cap, > > > > > > > timestamps) > > > I don't have > > > anything specific in mind. > > > > > > > > Though I > > > will certainly > > > provide Cisco's perspective and > > > > participate > > > > in any > > > discussions. > > > > > > > > thanks, > > > > > > > > david > > > > > > > > > > > > > > > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

2 1

Re: Third party registration/group registration
by Francois Audet 29 Nov '00

29 Nov '00

As far as H.323 is concerned, all endpoints are H.323 endpoints. They are further sub-qualified as either "terminals" or "gateways". The line becomes a little blurr when the physical device we are thinking of is a telephone set behind some sort of IP PBX or Gateway. That telephone can even be an H.248-controlled device. You could view the "proxy" as either a Gateway, an MCU or a terminal, or even a combination of 2 or 3 of them depending on your personnal preferences. Then there are glitches in the actual H.245 capabilities to negotiate what these entities can support (I think we sorted that out for v4). In any case, in H.323 terminology, the "endpoint" is the entity that will register aliases with the gatekeeper. This alias can be completely abstract (in which case the numbering plan and mapping to phone numbers themselves would be provisionned in the gatekeeper), or it can be actual phone numbers. H.323v4 even allows for registering large ranges of numbers without explicitly enumerating them (this is useful when you prefer to have the numbering plan managed in each gateways as opposed to a cental gatekeeper). In the H.323 world, this is not really "third-party" registration since the H.323 proxy is viewed as the first party (the fact that the media will be on different devices is irrelevant). That being said, I would imagine that the same mechanism could be used to register 3rd parties (real H.323 endpoints). In my opinion, I think all possible angles are covered in H.323v4... I wouldn't like to have even more ways to do registration. If anything, we should probably look into describing a little better how this is supposed to work to facilitate interworking with gatekeepers. We did a little bit in v4 (for example on the use of so-called prefixes, E.164 numbers, and private ISO/IEC 11571 addresses). My 2 cents... ---- François AUDET, Nortel Networks mailto:audet@nortelnetworks.com <mailto:audet@nortelnetworks.com> , tel:+1 408 495 3756 -----Original Message----- From: Taylor, Tom-PT [NORSE:B901:EXCH] Sent: Wednesday, November 29, 2000 10:39 AM To: ITU-SG16(a)MAILBAG.INTEL.COM Subject: Re: Third party registration/group registration Accurate terminology is obviously useful, but in this case, at least, it looks like something people can agree on and then move on. The more important point seems to be the underlying distinction in requirements: -- register on behalf of H.323 endpoints -- register on behalf of other endpoints where I use "other" in the sense that the contact address is associated with a non-H.323 signalling protocol. Purity is beside the point here -- it's the intention of the contact address that matters. Stating the requirement in this way makes it obvious that the second requirement includes the need to state which protocol the endpoints expects to receive. There is another possibility, of course: use the same mechanism to satisfy all requirements, and allow for the possibility that the endpoint supports multiple protocols. I think the design would be cleaner if we took the approach: one contact point, one protocol -- even if it meant repeating the contact information for each protocol a multiprotocol endpoint supports.

1 0

Re: Third party registration/group registration
by Tom-PT Taylor 29 Nov '00

29 Nov '00

Accurate terminology is obviously useful, but in this case, at least, it looks like something people can agree on and then move on. The more important point seems to be the underlying distinction in requirements: -- register on behalf of H.323 endpoints -- register on behalf of other endpoints where I use "other" in the sense that the contact address is associated with a non-H.323 signalling protocol. Purity is beside the point here -- it's the intention of the contact address that matters. Stating the requirement in this way makes it obvious that the second requirement includes the need to state which protocol the endpoints expects to receive. There is another possibility, of course: use the same mechanism to satisfy all requirements, and allow for the possibility that the endpoint supports multiple protocols. I think the design would be cleaner if we took the approach: one contact point, one protocol -- even if it meant repeating the contact information for each protocol a multiprotocol endpoint supports. > -----Original Message----- > From: Chris Wayman Purvis [mailto:cwp@ISDN-COMMS.CO.UK] > Sent: Wednesday, November 29, 2000 4:45 AM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: Re: Third party registration/group registration > > > Charles, > > > The IWF (SIP-H.323 gateway) may terminate data (voice, > video, data) if it > > determines that the call cannot go from end-to-end. An > entity outside of > > the IWF may perform this function on behalf of the IWF. In > this case, this > > entity would be under the influence of the IWF. > Right. But my point is that for a registration is to be > called "third-party", > the IWF would have NO part in the proceedings other than the > registration > stage. You appear to be ignoring my point about what entity > is handling > H.225.0/Q.931 and/or H.245 signalling, which I feel is the > crucial part of what > would make a registration "third-party". > > > By *true* H.323 entities, I meant an entity that *speaks* > ONLY H.323. The > > IWF represents non-H.323 entities on the H.323 network. > Your "*true*" H.323 entity is an unusual beast indeed, given > that the majority > of H.323 devices around are either gateways (speaking another > protocol) or > PC-based (in which they generally "*speak*" large varieties > of protocols for > different purposes. In fact you restrict your definition of > "*true*" H.323 > entities to standalone IP phones. The fact that a device > supports protocols > other than H.323 does NOT make it any the less a "*true*" > H.323 device in any > reasonable definition of the word "true". > > > You are right, additive registration is NOT third-party > registration. Can > > it be used as a means to achieve scalable third-party registration? > Additive registrations can, I believe, be used to achieve > what you are trying > to achieve. I don't believe it can be used to achieve what > _I_ understand as > third-party registration. Our disagreement is around the > definition of the > term "third-party registration", the difference in our > definitions causing > confusion. > > I'll stick my neck out here and say that so far I believe > consensus is with my > definition (third-party registration as one H.323 entity > registering on behalf > of other entities which are H.323 except in their inability > or unwillingness to > register themselves with a gatekeeper) rather than yours (a > gateway registering > any device using any protocol with an H.323 gatekeeper). I > will then promptly > duck as I wait for the flack to fly! > > Regards, > Chris > > -----Original Message----- > > From: Chris Wayman Purvis [mailto:cwp@isdn-comms.co.uk] > > Sent: Tuesday, November 28, 2000 10:36 AM > > To: Agboh, Charles; 'ITU-SG16(a)mailbag.cps.intel.com' > > Subject: Re: Third party registration/group registration > > > > All, > > > > Please please PLEASE can we have some more opinions on this > important > > definition, though. Charles and I simply disagree, and a > wider pool of > > opinion > > is needed in order for consensus to be reached. Although I > disagree with > > Charles's view I am willing to espouse it if that's the way > the majority of > > experts see things. Without further input we'll simply go > round in circles. > > > > Charles, All, > > > > I believe the fundamental question about "third-partyness" > in this context > > is > > what entity or entities will handle the H.225.0/Q.931 and or H.245 > > signalling. > > My understanding of the type of IWF you are talking about > (at least, the way > > I > > would implement such a thing!) is that the IWF terminates > all signalling, > > with > > RTP data going direct end to end. So it is the entity that > is performing > > the > > registration that will handle all signalling (namely what > you in your > > SIP-centred way call and IWF and I in my H.323-centred way > call a gateway!). > > > > To me this is a fair definition of first-party. The only > thing the IWF is > > not > > terminating is (voice, video and application) data. This > does not make the > > registration third-party in my opinion. There is no > assumption (as far as I > > can remember, anyway) that H.323 entities have to handle > their own RTP > > sessions > > - they are required only to exchange addresses to terminate > these sessions. > > > > Simple question: What is your definition of a "*true* H.323 > entity"? In > > what > > sense is your gateway/IWF not a "*true* H.323 entity"? > > > > Additive registration is NOT third-party registration by my > definition. > > > > Regards, > > Chris > > > > "Agboh, Charles" wrote: > > > > > > Hi Chris, > > > > > > I see what you mean. I think you are working under the > assumption that > > the > > > "..other H.323 entities" are *true* H.323 entites. The > IWF may give the > > > impression that they are H.323 entities but it doesn't > mean they are. > > > > > > In this model, I am assuming that the "third-party" is > receving all > > > signalling from the GK whether it (the GK) is in DRC or GRC mode. > > > > > > Q: Do I really care if the "..other H.323 entities" are > *true* H.323 > > > entities or not? A GK probably couldn't say if the > "first-party" > > being > > > registered (the entitry being registered as apposed to > the entity > > > receiving the registration) is a *true* H.323 entity or not. > > > A: It may be usefull. A GK can invoke a special feature > if it can > > > differentiate. > > > > > > H.323v4 defines the additive registration feature, which by your > > definition > > > is a third-party registration, right? So how does the GK > know that the > > > "first-party" is a *true* H.323 entitry? > > > > > > Best Regards, > > > charles > > > > > > -----Original Message----- > > > From: Chris Wayman Purvis [mailto:cwp@isdn-comms.co.uk] > > > Sent: Monday, November 27, 2000 6:19 PM > > > To: Agboh, Charles > > > Cc: 'ITU-SG16(a)mailbag.cps.intel.com' > > > Subject: Re: Third party registration/group registration > > > > > > Charles, > > > > > > > My undstanding of "third-party" registration is the > same as yours. > > But, > > > in > > > > some applications a registration by the IWF may not be > on its own > > behalf. > > > These two sentences contradict each other. Please reread > my explanation > > of > > > my > > > understanding, as it is impossible for you to agree with > it and believe > > what > > > you have written in the second sentence above. > > > Unless I misunderstand your definition of an "IWF", which > I take to be > > > synonymous with a "gateway" as defined in the H.323 > series of standards. > > > > > > > H.323v4 provides this feature (a way to bypass the UDP > packet size > > > > limitation) for this same reason. > > > > > > > > Does it make sense to have this?, If no, then why not? > > > > > > > > SupportedProtocols ::= CHOICE > > > > { > > > > nonStandardData NonStandardParameter, > > > > h310 H310Caps, > > > > h320 H320Caps, > > > > h321 H321Caps, > > > > h322 H322Caps, > > > > h323 H323Caps, > > > > h324 H324Caps, > > > > voice > > > > ......., > > > > SIP SIPCaps > > > > } > > > This may make sense (and is what I meant when I referred to > > > "supportedPrefixes"). If this is a way forward that you > believe would be > > > useful for SIP gateways I would encourage you to write a > formal proposal > > to > > > an > > > ITU SG16 experts meeting on this basis. > > > > > > Regards, > > > Chris > > > > > > > -----Original Message----- > > > > From: Chris Wayman Purvis [mailto:cwp@isdn-comms.co.uk] > > > > Sent: Monday, November 27, 2000 10:41 AM > > > > To: Agboh, Charles > > > > Cc: ITU-SG16(a)mailbag.cps.intel.com > > > > Subject: Re: Third party registration/group registration > > > > > > > > Charles, > > > > > > > > Wrong in my opinion, but I would hope other experts > would express their > > > > opinions too! The problem is I'm not sure whether this > is a question of > > > > understanding or of detailed definition of the phrase > "third party" in > > > this > > > > context. > > > > My understanding of the phrase "third party > registration" would be one > > > H.323 > > > > entity registering at a gatekeeper on behalf of other > H.323 entities. > > My > > > > understanding of the word "registration" of this > context is that it can > > > only > > > > apply to H.323 entities. In this context the IWF can > be considered to > > be > > > at > > > > the extreme edge of the H.323 network, so any > "registration" it does is > > on > > > > its > > > > own behalf. > > > > Maybe what you actually want is some equivalent to the > supportedPrefixes > > > > that > > > > arrived in version 2, for SIP gateways. > > > > Whatever we agree you want, though, I think it is worth > trying to reach > > > some > > > > consensus among experts in this group as to what the > phrase "third > > party" > > > > means > > > > in this context - as your understanding and mine are clearly in > > > > disagreement. > > > > > > > > Regards, > > > > Chris > > > > > > > > "Agboh, Charles" wrote: > > > > > > > > > > Chris, > > > > > > > > > > There are applications where an IWF can register an > EP from one domain > > > > into > > > > > another. This allows automatic visibility of EP > from one domain from > > > > > another. In this case the IWF is registering not > only itself but > > other > > > > EPs. > > > > > For this scenario, the third-party entity is the IWF, right? > > > > > > > > > > regards, > > > > > > > > > > charles > > > > -- > > > > 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 > > > > > > -- > > > 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 > > > > -- > > 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

Re: H.323 MIB definition
by Francois Audet 29 Nov '00

29 Nov '00

H.341. http://www.itu.int/itudoc/itu-t/rec/h/h-341.html -----Original Message----- From: Hans Viens [mailto:hviens@MEDIATRIX.COM] Sent: Wednesday, November 29, 2000 08:34 To: ITU-SG16(a)MAILBAG.INTEL.COM Subject: H.323 MIB definition Hi all, I would like to know if there is a proposal existing of a MIB definition for a H.323 endpoint ? If anyone could send me informations or link or documents it would be very appreciated. Best Regards, Hans ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

H.323 MIB definition
by Hans Viens 29 Nov '00

29 Nov '00

Hi all, I would like to know if there is a proposal existing of a MIB definition for a H.323 endpoint ? If anyone could send me informations or link or documents it would be very appreciated. Best Regards, Hans ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

RE: Annex H Editorship
by Roy, Radhika R, ALCOO 29 Nov '00

29 Nov '00

Hi, Everyone: Let us extend our thanks to Ernst Horvath for taking the lead of the editorship and Paul for his quick decision to fill that post. Jaakko Sundquist has done a wonderful job to make the progress despite competing proposals. Now it is the time to revisit the fundamental issues to make a genuine progress keeping in mind that we need to satisfy all requirements that have been laid down so that we do not face the same situation what happened last time. As a first step, I would request the editor to go through all contributions that had been submitted over the last two years (Q.13 Rap and SG16 meetings). From my side, I would provide all copies of AT&T contributions if the editor does not have copies of those contributions. I strongly feel that none of those contributions were taken into account in the present Annex H. I do not like to bring the same issues over and again with new contributions. Issues will not go away unless we address all those issues properly. If the editor wants to know what are all those issues, I would be glad to help, if already not known. Let us make a quick resolution for sake of making progress quickly. One more point, we have now got a complete new Question in SG16 related to mobility. Our objectives should always be to see the BIG picture. Best regards, Radhika R. Roy AT&T -----Original Message----- From: Paul E. Jones [mailto:paulej@PACKETIZER.COM] Sent: Tuesday, November 28, 2000 3:16 PM To: ITU-SG16(a)MAILBAG.INTEL.COM Subject: Annex H Editorship Folks, I am pleased to announce that Ernst Horvath (Siemens) has agreed to assume the role of Editor of Annex H/H.323. This is an important work that we hope to bring to completion in 2001. I also want to thank Jaakko Sundquist for his hard work as Editor up to this point. Best Regards, Paul E. Jones ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

Re: Third party registration/group registration
by Agboh, Charles 29 Nov '00

29 Nov '00

Chris, The IWF (SIP-H.323 gateway) may terminate data (voice, video, data) if it determines that the call cannot go from end-to-end. An entity outside of the IWF may perform this function on behalf of the IWF. In this case, this entity would be under the influence of the IWF. By *true* H.323 entities, I meant an entity that *speaks* ONLY H.323. The IWF represents non-H.323 entities on the H.323 network. You are right, additive registration is NOT third-party registration. Can it be used as a means to achieve scalable third-party registration? Regards, Charles -----Original Message----- From: Chris Wayman Purvis [mailto:cwp@isdn-comms.co.uk] Sent: Tuesday, November 28, 2000 10:36 AM To: Agboh, Charles; 'ITU-SG16(a)mailbag.cps.intel.com' Subject: Re: Third party registration/group registration All, Please please PLEASE can we have some more opinions on this important definition, though. Charles and I simply disagree, and a wider pool of opinion is needed in order for consensus to be reached. Although I disagree with Charles's view I am willing to espouse it if that's the way the majority of experts see things. Without further input we'll simply go round in circles. Charles, All, I believe the fundamental question about "third-partyness" in this context is what entity or entities will handle the H.225.0/Q.931 and or H.245 signalling. My understanding of the type of IWF you are talking about (at least, the way I would implement such a thing!) is that the IWF terminates all signalling, with RTP data going direct end to end. So it is the entity that is performing the registration that will handle all signalling (namely what you in your SIP-centred way call and IWF and I in my H.323-centred way call a gateway!). To me this is a fair definition of first-party. The only thing the IWF is not terminating is (voice, video and application) data. This does not make the registration third-party in my opinion. There is no assumption (as far as I can remember, anyway) that H.323 entities have to handle their own RTP sessions - they are required only to exchange addresses to terminate these sessions. Simple question: What is your definition of a "*true* H.323 entity"? In what sense is your gateway/IWF not a "*true* H.323 entity"? Additive registration is NOT third-party registration by my definition. Regards, Chris "Agboh, Charles" wrote: > > Hi Chris, > > I see what you mean. I think you are working under the assumption that the > "..other H.323 entities" are *true* H.323 entites. The IWF may give the > impression that they are H.323 entities but it doesn't mean they are. > > In this model, I am assuming that the "third-party" is receving all > signalling from the GK whether it (the GK) is in DRC or GRC mode. > > Q: Do I really care if the "..other H.323 entities" are *true* H.323 > entities or not? A GK probably couldn't say if the "first-party" being > registered (the entitry being registered as apposed to the entity > receiving the registration) is a *true* H.323 entity or not. > A: It may be usefull. A GK can invoke a special feature if it can > differentiate. > > H.323v4 defines the additive registration feature, which by your definition > is a third-party registration, right? So how does the GK know that the > "first-party" is a *true* H.323 entitry? > > Best Regards, > charles > > -----Original Message----- > From: Chris Wayman Purvis [mailto:cwp@isdn-comms.co.uk] > Sent: Monday, November 27, 2000 6:19 PM > To: Agboh, Charles > Cc: 'ITU-SG16(a)mailbag.cps.intel.com' > Subject: Re: Third party registration/group registration > > Charles, > > > My undstanding of "third-party" registration is the same as yours. But, > in > > some applications a registration by the IWF may not be on its own behalf. > These two sentences contradict each other. Please reread my explanation of > my > understanding, as it is impossible for you to agree with it and believe what > you have written in the second sentence above. > Unless I misunderstand your definition of an "IWF", which I take to be > synonymous with a "gateway" as defined in the H.323 series of standards. > > > H.323v4 provides this feature (a way to bypass the UDP packet size > > limitation) for this same reason. > > > > Does it make sense to have this?, If no, then why not? > > > > SupportedProtocols ::= CHOICE > > { > > nonStandardData NonStandardParameter, > > h310 H310Caps, > > h320 H320Caps, > > h321 H321Caps, > > h322 H322Caps, > > h323 H323Caps, > > h324 H324Caps, > > voice > > ......., > > SIP SIPCaps > > } > This may make sense (and is what I meant when I referred to > "supportedPrefixes"). If this is a way forward that you believe would be > useful for SIP gateways I would encourage you to write a formal proposal to > an > ITU SG16 experts meeting on this basis. > > Regards, > Chris > > > -----Original Message----- > > From: Chris Wayman Purvis [mailto:cwp@isdn-comms.co.uk] > > Sent: Monday, November 27, 2000 10:41 AM > > To: Agboh, Charles > > Cc: ITU-SG16(a)mailbag.cps.intel.com > > Subject: Re: Third party registration/group registration > > > > Charles, > > > > Wrong in my opinion, but I would hope other experts would express their > > opinions too! The problem is I'm not sure whether this is a question of > > understanding or of detailed definition of the phrase "third party" in > this > > context. > > My understanding of the phrase "third party registration" would be one > H.323 > > entity registering at a gatekeeper on behalf of other H.323 entities. My > > understanding of the word "registration" of this context is that it can > only > > apply to H.323 entities. In this context the IWF can be considered to be > at > > the extreme edge of the H.323 network, so any "registration" it does is on > > its > > own behalf. > > Maybe what you actually want is some equivalent to the supportedPrefixes > > that > > arrived in version 2, for SIP gateways. > > Whatever we agree you want, though, I think it is worth trying to reach > some > > consensus among experts in this group as to what the phrase "third party" > > means > > in this context - as your understanding and mine are clearly in > > disagreement. > > > > Regards, > > Chris > > > > "Agboh, Charles" wrote: > > > > > > Chris, > > > > > > There are applications where an IWF can register an EP from one domain > > into > > > another. This allows automatic visibility of EP from one domain from > > > another. In this case the IWF is registering not only itself but other > > EPs. > > > For this scenario, the third-party entity is the IWF, right? > > > > > > regards, > > > > > > charles > > -- > > 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 > > -- > 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 -- 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

Annex H Editorship
by Paul E. Jones 28 Nov '00

28 Nov '00

Folks, I am pleased to announce that Ernst Horvath (Siemens) has agreed to assume the role of Editor of Annex H/H.323. This is an important work that we hope to bring to completion in 2001. I also want to thank Jaakko Sundquist for his hard work as Editor up to this point. Best Regards, Paul E. Jones ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

Re: Third party registration/group registration
by Agboh, Charles 28 Nov '00

28 Nov '00

Hi Chris, I see what you mean. I think you are working under the assumption that the "..other H.323 entities" are *true* H.323 entites. The IWF may give the impression that they are H.323 entities but it doesn't mean they are. In this model, I am assuming that the "third-party" is receving all signalling from the GK whether it (the GK) is in DRC or GRC mode. Q: Do I really care if the "..other H.323 entities" are *true* H.323 entities or not? A GK probably couldn't say if the "first-party" being registered (the entitry being registered as apposed to the entity receiving the registration) is a *true* H.323 entity or not. A: It may be usefull. A GK can invoke a special feature if it can differentiate. H.323v4 defines the additive registration feature, which by your definition is a third-party registration, right? So how does the GK know that the "first-party" is a *true* H.323 entitry? Best Regards, charles -----Original Message----- From: Chris Wayman Purvis [mailto:cwp@isdn-comms.co.uk] Sent: Monday, November 27, 2000 6:19 PM To: Agboh, Charles Cc: 'ITU-SG16(a)mailbag.cps.intel.com' Subject: Re: Third party registration/group registration Charles, > My undstanding of "third-party" registration is the same as yours. But, in > some applications a registration by the IWF may not be on its own behalf. These two sentences contradict each other. Please reread my explanation of my understanding, as it is impossible for you to agree with it and believe what you have written in the second sentence above. Unless I misunderstand your definition of an "IWF", which I take to be synonymous with a "gateway" as defined in the H.323 series of standards. > H.323v4 provides this feature (a way to bypass the UDP packet size > limitation) for this same reason. > > Does it make sense to have this?, If no, then why not? > > SupportedProtocols ::= CHOICE > { > nonStandardData NonStandardParameter, > h310 H310Caps, > h320 H320Caps, > h321 H321Caps, > h322 H322Caps, > h323 H323Caps, > h324 H324Caps, > voice > ......., > SIP SIPCaps > } This may make sense (and is what I meant when I referred to "supportedPrefixes"). If this is a way forward that you believe would be useful for SIP gateways I would encourage you to write a formal proposal to an ITU SG16 experts meeting on this basis. Regards, Chris > -----Original Message----- > From: Chris Wayman Purvis [mailto:cwp@isdn-comms.co.uk] > Sent: Monday, November 27, 2000 10:41 AM > To: Agboh, Charles > Cc: ITU-SG16(a)mailbag.cps.intel.com > Subject: Re: Third party registration/group registration > > Charles, > > Wrong in my opinion, but I would hope other experts would express their > opinions too! The problem is I'm not sure whether this is a question of > understanding or of detailed definition of the phrase "third party" in this > context. > My understanding of the phrase "third party registration" would be one H.323 > entity registering at a gatekeeper on behalf of other H.323 entities. My > understanding of the word "registration" of this context is that it can only > apply to H.323 entities. In this context the IWF can be considered to be at > the extreme edge of the H.323 network, so any "registration" it does is on > its > own behalf. > Maybe what you actually want is some equivalent to the supportedPrefixes > that > arrived in version 2, for SIP gateways. > Whatever we agree you want, though, I think it is worth trying to reach some > consensus among experts in this group as to what the phrase "third party" > means > in this context - as your understanding and mine are clearly in > disagreement. > > Regards, > Chris > > "Agboh, Charles" wrote: > > > > Chris, > > > > There are applications where an IWF can register an EP from one domain > into > > another. This allows automatic visibility of EP from one domain from > > another. In this case the IWF is registering not only itself but other > EPs. > > For this scenario, the third-party entity is the IWF, right? > > > > regards, > > > > charles > -- > 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 -- 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

3 2

Re: Third party registration/group registration
by Roy, Radhika R, ALCOO 28 Nov '00

28 Nov '00

Hi, Euchner: Let me add a little more to clarify the definition of the "Third Party:" "what I'm understanding as "3rd party registration" is something where an arbitrary "H.323 entity" performs some kind of one-step bulk registration of many endpoints at the GK." I agree with this part of the definition of yours. The next thing is the "role" of the "entity" that performs the "third party" registration: The said entity (that performs the "role" of the third party) should be completely OFF (or it should not have any more "role") once the registration is done. For example, my secretary does a registration on behalf of me, but the secretary does not have any more role once the registration of mine is performed. (Please also see how SIP allows the third party registration.) If we agree with this definition of the "Third Party," we may then examine what is being done by the H.323 GW or IWF. It can be clearly seen that both H.323 GK and IWF remain an inherent part of the whole process even after the registration is completed (as I explained earlier). For example, both signaling and media MUST go through the GW, and the signaling information must go via the IWF on behalf of those endpoints/aliases. So, the basic question is: Why do we call this as the "Third Party" registration to start with? [For security, we need help from you and others when we will start the work for "SIP-H.323 Interworking" phase 2 that will include other complex issues including security. Thanks for your ideas that will be useful for phase 2.] Best regards, Radhika -----Original Message----- From: Euchner Martin [mailto:Martin.Euchner@icn.siemens.de] Sent: Tuesday, November 28, 2000 11:26 AM To: Roy, Radhika R, ALCOO; Euchner Martin; ITU-SG16(a)mailbag.cps.INTEL.COM Subject: AW: Third party registration/group registration Radhika and others, what I'm understanding as "3rd party registration" is something where an arbitrary "H.323 entity" performs some kind of one-step bulk registration of many endpoints at the GK. But how should this exactly work? Would the "H.323 entity" send out the bulk request whereas the terminals receive the registration confirmation message each? Or would the "H.323 entity" act somehow transparently in between the endpoints and the GK? For Radhika's comment, please see my security bits below marked with meu:> 4. To make the matter more complicated as the security issue raised by Euchner, there are two components: 1. Authenticate the IWF for the signaling and meu:> This could be achieved without efforts using the available H.235 security techniques, I would say. Here, the idea could be that the IWF as an H.323 gateway performs machine authentication. 2. Authenticate the endpoints for the media streams. I do not how the security can be dealt on end-to-end basis for two different protocols (H.323, SIP). (Am I right, Euchner?) Meu:> hmm, how should this work during the GK registration phase when it is not yet clear which terminals and media streams will be in force? But the situation is probably not that hopeless as it looks like. Roughly speaking, PKI might help here such that a single proxy registration through the IWF authenticates not only the IWF itself but also each individual device on an end-to-end basis. Of course, procedural description is needed for this... In order to keep things simple for the time being, lets leave the SIP stuff away for some further time and let's first figure out how the H.323 case would work. However, following the discussion until now, it appears to me that we all are talking not quite about the same scenario and various terms such as gateways, IWFs, additive registration, proxys and other items have already been mentioned. Kind Regards Martin Euchner. ----------------------------------------------------------------------- | Dipl.-Inf. Phone: +49 89 722 55790 | Martin Euchner Fax : +49 89 722 46841 | Siemens AG | ICN M NT 5 mailto:Martin.Euchner@icn.siemens.de <mailto:Martin.Euchner@icn.siemens.de> | mailto:martin.euchner@ties.itu.int <mailto:martin.euchner@ties.itu.int> | Hofmannstr. 51 Intranet: http://intranet.icn.siemens.de/marketing/network_technology/security/pki.htm | D-81359 Muenchen Internet: http://www.siemens.de <http://www.siemens.de> | __________________ | Germany ----------------------------------------------------------------------- -----Ursprüngliche Nachricht----- Von: Roy, Radhika R, ALCOO [SMTP:rrroy@att.com] Gesendet am: Dienstag, 28. November 2000 16:40 An: Euchner Martin; ITU-SG16(a)mailbag.cps.INTEL.COM Betreff: RE: Third party registration/group registration Hi, All: Let me ask some basic questions: 1. Does H.323 define the "Third Party" in any context: Registration or Call Control. If it is NOT, let us define what we mean by third party. In this way, we can examine the basic definition and go from there. 2. H.323 GW does registration on behalf many endpoints. However, an H.323 GW is a monolithic one where RAS, Q.931, and H.245 are being dealt by the same entity. That is, both signaling and media are terminated in the H.323 GW. So, can we call the registration by the H.323 GW as a third party registration? 3. SIP-H.323 IWF is dealing only with the signaling part while the RTP media stream is going end-to-end. Can we call the registration of many aliases by the IWF as the third party registration because the transport address of the IWF is still being used for signaling in all situations? 4. To make the matter more complicated as the security issue raised by Euchner, there are two components: 1. Authenticate the IWF for the signaling and 2. Authenticate the endpoints for the media streams. I do not how the security can be dealt on end-to-end basis for two different protocols (H.323, SIP). (Am I right, Euchner?) The last question that I have: What do we loose, if we do not use the term "Third Party" registration for the IWF? Best regards, Radhika R. Roy AT&T -----Original Message----- From: Euchner Martin [mailto:Martin.Euchner@ICN.SIEMENS.DE] <mailto:[mailto:Martin.Euchner@ICN.SIEMENS.DE]> Sent: Tuesday, November 28, 2000 6:26 AM To: ITU-SG16(a)MAILBAG.INTEL.COM <mailto:ITU-SG16@MAILBAG.INTEL.COM> Subject: AW: Third party registration/group registration I'm not certain whether the term "3rd party registration" is really clearly defined and described; although technically, there might be some means to realize this. My understanding here is, that a third party which is probably not actually involved in the call, registers one or more H.323 endpoints in one step. An interesting question for security is: Who gets authenticated? How does the 3rd party registration interact with the usual user-based authentication? Thus, there is certainly some need for clarification and better description. Kind Regards Martin Euchner. ----------------------------------------------------------------------- | Dipl.-Inf. Phone: +49 89 722 55790 | Martin Euchner Fax : +49 89 722 46841 | Siemens AG | ICN M NT 5 mailto:Martin.Euchner@icn.siemens.de <mailto:Martin.Euchner@icn.siemens.de> <mailto:Martin.Euchner@icn.siemens.de <mailto:Martin.Euchner@icn.siemens.de> > | mailto:martin.euchner@ties.itu.int <mailto:martin.euchner@ties.itu.int> <mailto:martin.euchner@ties.itu.int <mailto:martin.euchner@ties.itu.int> > | Hofmannstr. 51 Intranet: http://intranet.icn.siemens.de/marketing/network_technology/security/pki.htm <http://intranet.icn.siemens.de/marketing/network_technology/security/pki.ht m> | D-81359 Muenchen Internet: http://www.siemens.de <http://www.siemens.de> <http://www.siemens.de <http://www.siemens.de> > | __________________ | Germany ----------------------------------------------------------------------- -----Ursprüngliche Nachricht----- Von: Chris Wayman Purvis [SMTP:cwp@ISDN-COMMS.CO.UK] <mailto:[SMTP:cwp@ISDN-COMMS.CO.UK]> Gesendet am: Dienstag, 28. November 2000 10:36 An: ITU-SG16(a)mailbag.cps.intel.com <mailto:ITU-SG16@mailbag.cps.intel.com> Betreff: Re: Third party registration/group registration All, Please please PLEASE can we have some more opinions on this important definition, though. Charles and I simply disagree, and a wider pool of opinion is needed in order for consensus to be reached. Although I disagree with Charles's view I am willing to espouse it if that's the way the majority of experts see things. Without further input we'll simply go round in circles. Charles, All, I believe the fundamental question about "third-partyness" in this context is what entity or entities will handle the H.225.0/Q.931 and or H.245 signalling. My understanding of the type of IWF you are talking about (at least, the way I would implement such a thing!) is that the IWF terminates all signalling, with RTP data going direct end to end. So it is the entity that is performing the registration that will handle all signalling (namely what you in your SIP-centred way call and IWF and I in my H.323-centred way call a gateway!). To me this is a fair definition of first-party. The only thing the IWF is not terminating is (voice, video and application) data. This does not make the registration third-party in my opinion. There is no assumption (as far as I can remember, anyway) that H.323 entities have to handle their own RTP sessions * they are required only to exchange addresses to terminate these sessions. Simple question: What is your definition of a "*true* H.323 entity"? In what sense is your gateway/IWF not a "*true* H.323 entity"? Additive registration is NOT third-party registration by my definition. Regards, Chris "Agboh, Charles" wrote: > > Hi Chris, > > I see what you mean. I think you are working under the assumption that the > "..other H.323 entities" are *true* H.323 entites. The IWF may give the > impression that they are H.323 entities but it doesn't mean they are. > > In this model, I am assuming that the "third-party" is receving all > signalling from the GK whether it (the GK) is in DRC or GRC mode. > > Q: Do I really care if the "..other H.323 entities" are *true* H.323 > entities or not? A GK probably couldn't say if the "first-party" being > registered (the entitry being registered as apposed to the entity > receiving the registration) is a *true* H.323 entity or not. > A: It may be usefull. A GK can invoke a special feature if it can > differentiate. > > H.323v4 defines the additive registration feature, which by your definition > is a third-party registration, right? So how does the GK know that the > "first-party" is a *true* H.323 entitry? > > Best Regards, > charles > > -----Original Message----- > From: Chris Wayman Purvis [mailto:cwp@isdn-comms.co.uk] <mailto:[mailto:cwp@isdn-comms.co.uk]> > Sent: Monday, November 27, 2000 6:19 PM > To: Agboh, Charles > Cc: 'ITU-SG16(a)mailbag.cps.intel.com' > Subject: Re: Third party registration/group registration > > Charles, > > > My undstanding of "third-party" registration is the same as yours. But, > in > > some applications a registration by the IWF may not be on its own behalf. > These two sentences contradict each other. Please reread my explanation of > my > understanding, as it is impossible for you to agree with it and believe what > you have written in the second sentence above. > Unless I misunderstand your definition of an "IWF", which I take to be > synonymous with a "gateway" as defined in the H.323 series of standards. > > > H.323v4 provides this feature (a way to bypass the UDP packet size > > limitation) for this same reason. > > > > Does it make sense to have this?, If no, then why not? > > > > SupportedProtocols ::= CHOICE > > { > > nonStandardData NonStandardParameter, > > h310 H310Caps, > > h320 H320Caps, > > h321 H321Caps, > > h322 H322Caps, > > h323 H323Caps, > > h324 H324Caps, > > voice > > ......., > > SIP SIPCaps > > } > This may make sense (and is what I meant when I referred to > "supportedPrefixes"). If this is a way forward that you believe would be > useful for SIP gateways I would encourage you to write a formal proposal to > an > ITU SG16 experts meeting on this basis. > > Regards, > Chris > > > -----Original Message----- > > From: Chris Wayman Purvis [mailto:cwp@isdn-comms.co.uk] <mailto:[mailto:cwp@isdn-comms.co.uk]> > > Sent: Monday, November 27, 2000 10:41 AM > > To: Agboh, Charles > > Cc: ITU-SG16(a)mailbag.cps.intel.com <mailto:ITU-SG16@mailbag.cps.intel.com> > > Subject: Re: Third party registration/group registration > > > > Charles, > > > > Wrong in my opinion, but I would hope other experts would express their > > opinions too! The problem is I'm not sure whether this is a question of > > understanding or of detailed definition of the phrase "third party" in > this > > context. > > My understanding of the phrase "third party registration" would be one > H.323 > > entity registering at a gatekeeper on behalf of other H.323 entities. My > > understanding of the word "registration" of this context is that it can > only > > apply to H.323 entities. In this context the IWF can be considered to be > at > > the extreme edge of the H.323 network, so any "registration" it does is on > > its > > own behalf. > > Maybe what you actually want is some equivalent to the supportedPrefixes > > that > > arrived in version 2, for SIP gateways. > > Whatever we agree you want, though, I think it is worth trying to reach > some > > consensus among experts in this group as to what the phrase "third party" > > means > > in this context - as your understanding and mine are clearly in > > disagreement. > > > > Regards, > > Chris > > > > "Agboh, Charles" wrote: > > > > > > Chris, > > > > > > There are applications where an IWF can register an EP from one domain > > into > > > another. This allows automatic visibility of EP from one domain from > > > another. In this case the IWF is registering not only itself but other > > EPs. > > > For this scenario, the third-party entity is the IWF, right? > > > > > > regards, > > > > > > charles > > -- > > 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 > > -- > 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 -- 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 <mailto:listserv@mailbag.intel.com> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com <mailto:listserv@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: Third party registration/group registration
by Roy, Radhika R, ALCOO 28 Nov '00

28 Nov '00

Hi, All: Let me ask some basic questions: 1. Does H.323 define the "Third Party" in any context: Registration or Call Control. If it is NOT, let us define what we mean by third party. In this way, we can examine the basic definition and go from there. 2. H.323 GW does registration on behalf many endpoints. However, an H.323 GW is a monolithic one where RAS, Q.931, and H.245 are being dealt by the same entity. That is, both signaling and media are terminated in the H.323 GW. So, can we call the registration by the H.323 GW as a third party registration? 3. SIP-H.323 IWF is dealing only with the signaling part while the RTP media stream is going end-to-end. Can we call the registration of many aliases by the IWF as the third party registration because the transport address of the IWF is still being used for signaling in all situations? 4. To make the matter more complicated as the security issue raised by Euchner, there are two components: 1. Authenticate the IWF for the signaling and 2. Authenticate the endpoints for the media streams. I do not how the security can be dealt on end-to-end basis for two different protocols (H.323, SIP). (Am I right, Euchner?) The last question that I have: What do we loose, if we do not use the term "Third Party" registration for the IWF? Best regards, Radhika R. Roy AT&T -----Original Message----- From: Euchner Martin [mailto:Martin.Euchner@ICN.SIEMENS.DE] Sent: Tuesday, November 28, 2000 6:26 AM To: ITU-SG16(a)MAILBAG.INTEL.COM Subject: AW: Third party registration/group registration I'm not certain whether the term "3rd party registration" is really clearly defined and described; although technically, there might be some means to realize this. My understanding here is, that a third party which is probably not actually involved in the call, registers one or more H.323 endpoints in one step. An interesting question for security is: Who gets authenticated? How does the 3rd party registration interact with the usual user-based authentication? Thus, there is certainly some need for clarification and better description. Kind Regards Martin Euchner. ----------------------------------------------------------------------- | Dipl.-Inf. Phone: +49 89 722 55790 | Martin Euchner Fax : +49 89 722 46841 | Siemens AG | ICN M NT 5 mailto:Martin.Euchner@icn.siemens.de <mailto:Martin.Euchner@icn.siemens.de> | mailto:martin.euchner@ties.itu.int <mailto:martin.euchner@ties.itu.int> | Hofmannstr. 51 Intranet: http://intranet.icn.siemens.de/marketing/network_technology/security/pki.htm | D-81359 Muenchen Internet: http://www.siemens.de <http://www.siemens.de> | __________________ | Germany ----------------------------------------------------------------------- -----Ursprüngliche Nachricht----- Von: Chris Wayman Purvis [SMTP:cwp@ISDN-COMMS.CO.UK] Gesendet am: Dienstag, 28. November 2000 10:36 An: ITU-SG16(a)mailbag.cps.intel.com Betreff: Re: Third party registration/group registration All, Please please PLEASE can we have some more opinions on this important definition, though. Charles and I simply disagree, and a wider pool of opinion is needed in order for consensus to be reached. Although I disagree with Charles's view I am willing to espouse it if that's the way the majority of experts see things. Without further input we'll simply go round in circles. Charles, All, I believe the fundamental question about "third-partyness" in this context is what entity or entities will handle the H.225.0/Q.931 and or H.245 signalling. My understanding of the type of IWF you are talking about (at least, the way I would implement such a thing!) is that the IWF terminates all signalling, with RTP data going direct end to end. So it is the entity that is performing the registration that will handle all signalling (namely what you in your SIP-centred way call and IWF and I in my H.323-centred way call a gateway!). To me this is a fair definition of first-party. The only thing the IWF is not terminating is (voice, video and application) data. This does not make the registration third-party in my opinion. There is no assumption (as far as I can remember, anyway) that H.323 entities have to handle their own RTP sessions - they are required only to exchange addresses to terminate these sessions. Simple question: What is your definition of a "*true* H.323 entity"? In what sense is your gateway/IWF not a "*true* H.323 entity"? Additive registration is NOT third-party registration by my definition. Regards, Chris "Agboh, Charles" wrote: > > Hi Chris, > > I see what you mean. I think you are working under the assumption that the > "..other H.323 entities" are *true* H.323 entites. The IWF may give the > impression that they are H.323 entities but it doesn't mean they are. > > In this model, I am assuming that the "third-party" is receving all > signalling from the GK whether it (the GK) is in DRC or GRC mode. > > Q: Do I really care if the "..other H.323 entities" are *true* H.323 > entities or not? A GK probably couldn't say if the "first-party" being > registered (the entitry being registered as apposed to the entity > receiving the registration) is a *true* H.323 entity or not. > A: It may be usefull. A GK can invoke a special feature if it can > differentiate. > > H.323v4 defines the additive registration feature, which by your definition > is a third-party registration, right? So how does the GK know that the > "first-party" is a *true* H.323 entitry? > > Best Regards, > charles > > -----Original Message----- > From: Chris Wayman Purvis [mailto:cwp@isdn-comms.co.uk] > Sent: Monday, November 27, 2000 6:19 PM > To: Agboh, Charles > Cc: 'ITU-SG16(a)mailbag.cps.intel.com' > Subject: Re: Third party registration/group registration > > Charles, > > > My undstanding of "third-party" registration is the same as yours. But, > in > > some applications a registration by the IWF may not be on its own behalf. > These two sentences contradict each other. Please reread my explanation of > my > understanding, as it is impossible for you to agree with it and believe what > you have written in the second sentence above. > Unless I misunderstand your definition of an "IWF", which I take to be > synonymous with a "gateway" as defined in the H.323 series of standards. > > > H.323v4 provides this feature (a way to bypass the UDP packet size > > limitation) for this same reason. > > > > Does it make sense to have this?, If no, then why not? > > > > SupportedProtocols ::= CHOICE > > { > > nonStandardData NonStandardParameter, > > h310 H310Caps, > > h320 H320Caps, > > h321 H321Caps, > > h322 H322Caps, > > h323 H323Caps, > > h324 H324Caps, > > voice > > ......., > > SIP SIPCaps > > } > This may make sense (and is what I meant when I referred to > "supportedPrefixes"). If this is a way forward that you believe would be > useful for SIP gateways I would encourage you to write a formal proposal to > an > ITU SG16 experts meeting on this basis. > > Regards, > Chris > > > -----Original Message----- > > From: Chris Wayman Purvis [mailto:cwp@isdn-comms.co.uk] > > Sent: Monday, November 27, 2000 10:41 AM > > To: Agboh, Charles > > Cc: ITU-SG16(a)mailbag.cps.intel.com > > Subject: Re: Third party registration/group registration > > > > Charles, > > > > Wrong in my opinion, but I would hope other experts would express their > > opinions too! The problem is I'm not sure whether this is a question of > > understanding or of detailed definition of the phrase "third party" in > this > > context. > > My understanding of the phrase "third party registration" would be one > H.323 > > entity registering at a gatekeeper on behalf of other H.323 entities. My > > understanding of the word "registration" of this context is that it can > only > > apply to H.323 entities. In this context the IWF can be considered to be > at > > the extreme edge of the H.323 network, so any "registration" it does is on > > its > > own behalf. > > Maybe what you actually want is some equivalent to the supportedPrefixes > > that > > arrived in version 2, for SIP gateways. > > Whatever we agree you want, though, I think it is worth trying to reach > some > > consensus among experts in this group as to what the phrase "third party" > > means > > in this context - as your understanding and mine are clearly in > > disagreement. > > > > Regards, > > Chris > > > > "Agboh, Charles" wrote: > > > > > > Chris, > > > > > > There are applications where an IWF can register an EP from one domain > > into > > > another. This allows automatic visibility of EP from one domain from > > > another. In this case the IWF is registering not only itself but other > > EPs. > > > For this scenario, the third-party entity is the IWF, right? > > > > > > regards, > > > > > > charles > > -- > > 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 > > -- > 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 -- 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

H.245v7: Editorial error in ASN.1
by Orit Levin 28 Nov '00

28 Nov '00

Hello, Mike! I would like to bring to your attention that during our work on H.323v4 an editorial error in ASN.1 of H.245v7 has been found. The "MultiplexFormat" definition is misspelled in one case as "MultipexFormat", which prevents the ASN.1 from compilation. Best Regards, Orit Levin RADVision Inc. TEL: 201.529.4300 x 230 FAX:201.529.3516 mailto:orit@radvision.com http://www.radvision.com 575 Corporate Drive Suite 420 Mahwah, NJ 07430 -----Original Message----- From: mike.nilsson(a)bt.com [mailto:mike.nilsson@bt.com] Sent: Friday, September 08, 2000 6:29 AM To: itu-sg16(a)mailbag.cps.intel.com; h323implementors(a)imtc.org; tsg16q11(a)itu.int; itu-adv-video(a)standard.pictel.com Subject: Draft H.245 Rapporteur's TD for H.245V7 Please find attached a draft, for review, of the Rapporteur's TD for changes to H.245 relative to the white paper COM-16-120, due for approval in November. <<H245-TD-DraftA.zip>> Best regards Mike Nilsson -------------------- Mike Nilsson Multimedia Applications B81 Room 102 pp14 BT Advanced Communications Technology Centre Adastral Park, Martlesham Heath, Ipswich, IP5 3RE, UK Tel: +44 1473 645413 Mobile: +44 7808 635412 Fax: +44 1473 646589 Email: mike.nilsson(a)bt.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

Re: Third party registration/group registration
by Roni Even 28 Nov '00

28 Nov '00

All, In H.323 section 7.2.3 is sort of third party register but the actual register process is a Gatekeeper application dependent. "A Gatekeeper may be aware of the alias address and connection information of endpoints on the SCN. This Gatekeeper could respond to an LRQ requesting information on the SCN endpoint with the connection information necessary to reach that endpoint. This would include the information necessary to address the Gateway as well as the SCN endpoint. Note that the SCN endpoint is not registered with the Gatekeeper in the sense that it exchanges RRQ/RCF messages with the Gatekeeper. The method by which a Gatekeeper becomes aware of the SCN endpoint information is outside the scope of this Recommendation." Roni Even -----Original Message----- From: Chris Wayman Purvis [mailto:cwp@ISDN-COMMS.CO.UK] Sent: Tuesday, November 28, 2000 11:36 AM To: ITU-SG16(a)MAILBAG.INTEL.COM Subject: Re: Third party registration/group registration All, Please please PLEASE can we have some more opinions on this important definition, though. Charles and I simply disagree, and a wider pool of opinion is needed in order for consensus to be reached. Although I disagree with Charles's view I am willing to espouse it if that's the way the majority of experts see things. Without further input we'll simply go round in circles. Charles, All, I believe the fundamental question about "third-partyness" in this context is what entity or entities will handle the H.225.0/Q.931 and or H.245 signalling. My understanding of the type of IWF you are talking about (at least, the way I would implement such a thing!) is that the IWF terminates all signalling, with RTP data going direct end to end. So it is the entity that is performing the registration that will handle all signalling (namely what you in your SIP-centred way call and IWF and I in my H.323-centred way call a gateway!). To me this is a fair definition of first-party. The only thing the IWF is not terminating is (voice, video and application) data. This does not make the registration third-party in my opinion. There is no assumption (as far as I can remember, anyway) that H.323 entities have to handle their own RTP sessions - they are required only to exchange addresses to terminate these sessions. Simple question: What is your definition of a "*true* H.323 entity"? In what sense is your gateway/IWF not a "*true* H.323 entity"? Additive registration is NOT third-party registration by my definition. Regards, Chris "Agboh, Charles" wrote: > > Hi Chris, > > I see what you mean. I think you are working under the assumption that the > "..other H.323 entities" are *true* H.323 entites. The IWF may give the > impression that they are H.323 entities but it doesn't mean they are. > > In this model, I am assuming that the "third-party" is receving all > signalling from the GK whether it (the GK) is in DRC or GRC mode. > > Q: Do I really care if the "..other H.323 entities" are *true* H.323 > entities or not? A GK probably couldn't say if the "first-party" being > registered (the entitry being registered as apposed to the entity > receiving the registration) is a *true* H.323 entity or not. > A: It may be usefull. A GK can invoke a special feature if it can > differentiate. > > H.323v4 defines the additive registration feature, which by your definition > is a third-party registration, right? So how does the GK know that the > "first-party" is a *true* H.323 entitry? > > Best Regards, > charles > > -----Original Message----- > From: Chris Wayman Purvis [mailto:cwp@isdn-comms.co.uk] > Sent: Monday, November 27, 2000 6:19 PM > To: Agboh, Charles > Cc: 'ITU-SG16(a)mailbag.cps.intel.com' > Subject: Re: Third party registration/group registration > > Charles, > > > My undstanding of "third-party" registration is the same as yours. But, > in > > some applications a registration by the IWF may not be on its own behalf. > These two sentences contradict each other. Please reread my explanation of > my > understanding, as it is impossible for you to agree with it and believe what > you have written in the second sentence above. > Unless I misunderstand your definition of an "IWF", which I take to be > synonymous with a "gateway" as defined in the H.323 series of standards. > > > H.323v4 provides this feature (a way to bypass the UDP packet size > > limitation) for this same reason. > > > > Does it make sense to have this?, If no, then why not? > > > > SupportedProtocols ::= CHOICE > > { > > nonStandardData NonStandardParameter, > > h310 H310Caps, > > h320 H320Caps, > > h321 H321Caps, > > h322 H322Caps, > > h323 H323Caps, > > h324 H324Caps, > > voice > > ......., > > SIP SIPCaps > > } > This may make sense (and is what I meant when I referred to > "supportedPrefixes"). If this is a way forward that you believe would be > useful for SIP gateways I would encourage you to write a formal proposal to > an > ITU SG16 experts meeting on this basis. > > Regards, > Chris > > > -----Original Message----- > > From: Chris Wayman Purvis [mailto:cwp@isdn-comms.co.uk] > > Sent: Monday, November 27, 2000 10:41 AM > > To: Agboh, Charles > > Cc: ITU-SG16(a)mailbag.cps.intel.com > > Subject: Re: Third party registration/group registration > > > > Charles, > > > > Wrong in my opinion, but I would hope other experts would express their > > opinions too! The problem is I'm not sure whether this is a question of > > understanding or of detailed definition of the phrase "third party" in > this > > context. > > My understanding of the phrase "third party registration" would be one > H.323 > > entity registering at a gatekeeper on behalf of other H.323 entities. My > > understanding of the word "registration" of this context is that it can > only > > apply to H.323 entities. In this context the IWF can be considered to be > at > > the extreme edge of the H.323 network, so any "registration" it does is on > > its > > own behalf. > > Maybe what you actually want is some equivalent to the supportedPrefixes > > that > > arrived in version 2, for SIP gateways. > > Whatever we agree you want, though, I think it is worth trying to reach > some > > consensus among experts in this group as to what the phrase "third party" > > means > > in this context - as your understanding and mine are clearly in > > disagreement. > > > > Regards, > > Chris > > > > "Agboh, Charles" wrote: > > > > > > Chris, > > > > > > There are applications where an IWF can register an EP from one domain > > into > > > another. This allows automatic visibility of EP from one domain from > > > another. In this case the IWF is registering not only itself but other > > EPs. > > > For this scenario, the third-party entity is the IWF, right? > > > > > > regards, > > > > > > charles > > -- > > 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 > > -- > 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 -- Dr Chris Purvis -- Development Manager ISDN Communications Ltd, The Stable Block, Ronans, Chavey Down Road Winkfield Row, Berkshire. RG42 6LY ENGLAND Phone: +44 1344 899 007 Fax: +44 1344 899 001 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

AW: Third party registration/group registration
by Euchner Martin 28 Nov '00

28 Nov '00

I'm not certain whether the term "3rd party registration" is really clearly defined and described; although technically, there might be some means to realize this. My understanding here is, that a third party which is probably not actually involved in the call, registers one or more H.323 endpoints in one step. An interesting question for security is: Who gets authenticated? How does the 3rd party registration interact with the usual user-based authentication? Thus, there is certainly some need for clarification and better description. Kind Regards Martin Euchner. ----------------------------------------------------------------------- | Dipl.-Inf. Phone: +49 89 722 55790 | Martin Euchner Fax : +49 89 722 46841 | Siemens AG | ICN M NT 5 mailto:Martin.Euchner@icn.siemens.de <mailto:Martin.Euchner@icn.siemens.de> | mailto:martin.euchner@ties.itu.int <mailto:martin.euchner@ties.itu.int> | Hofmannstr. 51 Intranet: http://intranet.icn.siemens.de/marketing/network_technology/security/pki.htm | D-81359 Muenchen Internet: http://www.siemens.de <http://www.siemens.de> | __________________ | Germany ----------------------------------------------------------------------- -----Ursprüngliche Nachricht----- Von: Chris Wayman Purvis [SMTP:cwp@ISDN-COMMS.CO.UK] Gesendet am: Dienstag, 28. November 2000 10:36 An: ITU-SG16(a)mailbag.cps.intel.com Betreff: Re: Third party registration/group registration All, Please please PLEASE can we have some more opinions on this important definition, though. Charles and I simply disagree, and a wider pool of opinion is needed in order for consensus to be reached. Although I disagree with Charles's view I am willing to espouse it if that's the way the majority of experts see things. Without further input we'll simply go round in circles. Charles, All, I believe the fundamental question about "third-partyness" in this context is what entity or entities will handle the H.225.0/Q.931 and or H.245 signalling. My understanding of the type of IWF you are talking about (at least, the way I would implement such a thing!) is that the IWF terminates all signalling, with RTP data going direct end to end. So it is the entity that is performing the registration that will handle all signalling (namely what you in your SIP-centred way call and IWF and I in my H.323-centred way call a gateway!). To me this is a fair definition of first-party. The only thing the IWF is not terminating is (voice, video and application) data. This does not make the registration third-party in my opinion. There is no assumption (as far as I can remember, anyway) that H.323 entities have to handle their own RTP sessions - they are required only to exchange addresses to terminate these sessions. Simple question: What is your definition of a "*true* H.323 entity"? In what sense is your gateway/IWF not a "*true* H.323 entity"? Additive registration is NOT third-party registration by my definition. Regards, Chris "Agboh, Charles" wrote: > > Hi Chris, > > I see what you mean. I think you are working under the assumption that the > "..other H.323 entities" are *true* H.323 entites. The IWF may give the > impression that they are H.323 entities but it doesn't mean they are. > > In this model, I am assuming that the "third-party" is receving all > signalling from the GK whether it (the GK) is in DRC or GRC mode. > > Q: Do I really care if the "..other H.323 entities" are *true* H.323 > entities or not? A GK probably couldn't say if the "first-party" being > registered (the entitry being registered as apposed to the entity > receiving the registration) is a *true* H.323 entity or not. > A: It may be usefull. A GK can invoke a special feature if it can > differentiate. > > H.323v4 defines the additive registration feature, which by your definition > is a third-party registration, right? So how does the GK know that the > "first-party" is a *true* H.323 entitry? > > Best Regards, > charles > > -----Original Message----- > From: Chris Wayman Purvis [mailto:cwp@isdn-comms.co.uk] > Sent: Monday, November 27, 2000 6:19 PM > To: Agboh, Charles > Cc: 'ITU-SG16(a)mailbag.cps.intel.com' > Subject: Re: Third party registration/group registration > > Charles, > > > My undstanding of "third-party" registration is the same as yours. But, > in > > some applications a registration by the IWF may not be on its own behalf. > These two sentences contradict each other. Please reread my explanation of > my > understanding, as it is impossible for you to agree with it and believe what > you have written in the second sentence above. > Unless I misunderstand your definition of an "IWF", which I take to be > synonymous with a "gateway" as defined in the H.323 series of standards. > > > H.323v4 provides this feature (a way to bypass the UDP packet size > > limitation) for this same reason. > > > > Does it make sense to have this?, If no, then why not? > > > > SupportedProtocols ::= CHOICE > > { > > nonStandardData NonStandardParameter, > > h310 H310Caps, > > h320 H320Caps, > > h321 H321Caps, > > h322 H322Caps, > > h323 H323Caps, > > h324 H324Caps, > > voice > > ......., > > SIP SIPCaps > > } > This may make sense (and is what I meant when I referred to > "supportedPrefixes"). If this is a way forward that you believe would be > useful for SIP gateways I would encourage you to write a formal proposal to > an > ITU SG16 experts meeting on this basis. > > Regards, > Chris > > > -----Original Message----- > > From: Chris Wayman Purvis [mailto:cwp@isdn-comms.co.uk] > > Sent: Monday, November 27, 2000 10:41 AM > > To: Agboh, Charles > > Cc: ITU-SG16(a)mailbag.cps.intel.com > > Subject: Re: Third party registration/group registration > > > > Charles, > > > > Wrong in my opinion, but I would hope other experts would express their > > opinions too! The problem is I'm not sure whether this is a question of > > understanding or of detailed definition of the phrase "third party" in > this > > context. > > My understanding of the phrase "third party registration" would be one > H.323 > > entity registering at a gatekeeper on behalf of other H.323 entities. My > > understanding of the word "registration" of this context is that it can > only > > apply to H.323 entities. In this context the IWF can be considered to be > at > > the extreme edge of the H.323 network, so any "registration" it does is on > > its > > own behalf. > > Maybe what you actually want is some equivalent to the supportedPrefixes > > that > > arrived in version 2, for SIP gateways. > > Whatever we agree you want, though, I think it is worth trying to reach > some > > consensus among experts in this group as to what the phrase "third party" > > means > > in this context - as your understanding and mine are clearly in > > disagreement. > > > > Regards, > > Chris > > > > "Agboh, Charles" wrote: > > > > > > Chris, > > > > > > There are applications where an IWF can register an EP from one domain > > into > > > another. This allows automatic visibility of EP from one domain from > > > another. In this case the IWF is registering not only itself but other > > EPs. > > > For this scenario, the third-party entity is the IWF, right? > > > > > > regards, > > > > > > charles > > -- > > 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 > > -- > 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 -- 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: Third party registration/group registration
by Roni Even 28 Nov '00

28 Nov '00

All, I read most of the discussion. I agree that an H.323 entity can register more then one alias for it self. It can use prefixes to define different services. As for third party registration it is not defined as such. The idea is that there is a gatekeeper per zone and if a gateway need to resolve addresses in two different zones he has to communicate with two gatekeepers. But I can see a gateway registering a service that let him identify a specific end point (call it EPA) that uses a signaling protocol that is not H.323, this will make sense if the gateway will access it using direct addressing. The problem with this solution is that each gateway or what you call the registering IWF that will need address resolution to EPA will need to register it and have some mechanism to know when to update EPA registration. Roni Even -----Original Message----- From: Chris Wayman Purvis [mailto:cwp@ISDN-COMMS.CO.UK] Sent: Tuesday, November 28, 2000 11:36 AM To: ITU-SG16(a)MAILBAG.INTEL.COM Subject: Re: Third party registration/group registration All, Please please PLEASE can we have some more opinions on this important definition, though. Charles and I simply disagree, and a wider pool of opinion is needed in order for consensus to be reached. Although I disagree with Charles's view I am willing to espouse it if that's the way the majority of experts see things. Without further input we'll simply go round in circles. Charles, All, I believe the fundamental question about "third-partyness" in this context is what entity or entities will handle the H.225.0/Q.931 and or H.245 signalling. My understanding of the type of IWF you are talking about (at least, the way I would implement such a thing!) is that the IWF terminates all signalling, with RTP data going direct end to end. So it is the entity that is performing the registration that will handle all signalling (namely what you in your SIP-centred way call and IWF and I in my H.323-centred way call a gateway!). To me this is a fair definition of first-party. The only thing the IWF is not terminating is (voice, video and application) data. This does not make the registration third-party in my opinion. There is no assumption (as far as I can remember, anyway) that H.323 entities have to handle their own RTP sessions - they are required only to exchange addresses to terminate these sessions. Simple question: What is your definition of a "*true* H.323 entity"? In what sense is your gateway/IWF not a "*true* H.323 entity"? Additive registration is NOT third-party registration by my definition. Regards, Chris "Agboh, Charles" wrote: > > Hi Chris, > > I see what you mean. I think you are working under the assumption that the > "..other H.323 entities" are *true* H.323 entites. The IWF may give the > impression that they are H.323 entities but it doesn't mean they are. > > In this model, I am assuming that the "third-party" is receving all > signalling from the GK whether it (the GK) is in DRC or GRC mode. > > Q: Do I really care if the "..other H.323 entities" are *true* H.323 > entities or not? A GK probably couldn't say if the "first-party" being > registered (the entitry being registered as apposed to the entity > receiving the registration) is a *true* H.323 entity or not. > A: It may be usefull. A GK can invoke a special feature if it can > differentiate. > > H.323v4 defines the additive registration feature, which by your definition > is a third-party registration, right? So how does the GK know that the > "first-party" is a *true* H.323 entitry? > > Best Regards, > charles > > -----Original Message----- > From: Chris Wayman Purvis [mailto:cwp@isdn-comms.co.uk] > Sent: Monday, November 27, 2000 6:19 PM > To: Agboh, Charles > Cc: 'ITU-SG16(a)mailbag.cps.intel.com' > Subject: Re: Third party registration/group registration > > Charles, > > > My undstanding of "third-party" registration is the same as yours. But, > in > > some applications a registration by the IWF may not be on its own behalf. > These two sentences contradict each other. Please reread my explanation of > my > understanding, as it is impossible for you to agree with it and believe what > you have written in the second sentence above. > Unless I misunderstand your definition of an "IWF", which I take to be > synonymous with a "gateway" as defined in the H.323 series of standards. > > > H.323v4 provides this feature (a way to bypass the UDP packet size > > limitation) for this same reason. > > > > Does it make sense to have this?, If no, then why not? > > > > SupportedProtocols ::= CHOICE > > { > > nonStandardData NonStandardParameter, > > h310 H310Caps, > > h320 H320Caps, > > h321 H321Caps, > > h322 H322Caps, > > h323 H323Caps, > > h324 H324Caps, > > voice > > ......., > > SIP SIPCaps > > } > This may make sense (and is what I meant when I referred to > "supportedPrefixes"). If this is a way forward that you believe would be > useful for SIP gateways I would encourage you to write a formal proposal to > an > ITU SG16 experts meeting on this basis. > > Regards, > Chris > > > -----Original Message----- > > From: Chris Wayman Purvis [mailto:cwp@isdn-comms.co.uk] > > Sent: Monday, November 27, 2000 10:41 AM > > To: Agboh, Charles > > Cc: ITU-SG16(a)mailbag.cps.intel.com > > Subject: Re: Third party registration/group registration > > > > Charles, > > > > Wrong in my opinion, but I would hope other experts would express their > > opinions too! The problem is I'm not sure whether this is a question of > > understanding or of detailed definition of the phrase "third party" in > this > > context. > > My understanding of the phrase "third party registration" would be one > H.323 > > entity registering at a gatekeeper on behalf of other H.323 entities. My > > understanding of the word "registration" of this context is that it can > only > > apply to H.323 entities. In this context the IWF can be considered to be > at > > the extreme edge of the H.323 network, so any "registration" it does is on > > its > > own behalf. > > Maybe what you actually want is some equivalent to the supportedPrefixes > > that > > arrived in version 2, for SIP gateways. > > Whatever we agree you want, though, I think it is worth trying to reach > some > > consensus among experts in this group as to what the phrase "third party" > > means > > in this context - as your understanding and mine are clearly in > > disagreement. > > > > Regards, > > Chris > > > > "Agboh, Charles" wrote: > > > > > > Chris, > > > > > > There are applications where an IWF can register an EP from one domain > > into > > > another. This allows automatic visibility of EP from one domain from > > > another. In this case the IWF is registering not only itself but other > > EPs. > > > For this scenario, the third-party entity is the IWF, right? > > > > > > regards, > > > > > > charles > > -- > > 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 > > -- > 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 -- 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: Draft Status Update
by Agboh, Charles 27 Nov '00

27 Nov '00

Paul, The "sip" option shouild be used by an H.323-SIP gateway if such a code-point was available ( following the example you gave, the "h323"option would not be *correct* for an H.323-SIP gw ). In light of this, should there be a code-point ("sip") for SIP (it is no longer a nonStandard protocol)in H.323v5? charles -----Original Message----- From: Paul E. Jones [mailto:paulej@packetizer.com] Sent: Monday, November 27, 2000 7:56 PM To: Agboh, Charles; 'Wong, Walter'; 'Roy, Radhika R, ALCOO'; Wang, Dave; VPalawat(a)opuswave.com; kns10(a)cs.columbia.edu Cc: joon_maeng(a)vtel.com; hemantag(a)globespan.net; schulzrinne(a)cs.columbia.edu; alan.johnston(a)wcom.com; David Daiker Subject: Re: Draft Status Update Charles, "voice" is supposed to be used by voice gateways. "h323" is supposed to be used by H.323-H.323 GWs (proxies). BTW, it should be noted that "supportedPrefixes" does *not* indicate what E.164 prefixes a gateway can reach. some implementers have interpreted it that way and others have interpreted it to indicate "service prefixes", such as dialing "9" to reach an outside line. The latter definition is the correct interpretation. H.323v4 now has fields that are there specifically for registering E.164 address ranges. Paul ----- Original Message ----- From: "Agboh, Charles" <Charles.Agboh(a)gts.com> To: "'Wong, Walter'" <wwong(a)nuera.com>; "'Roy, Radhika R, ALCOO'" <rrroy(a)att.com>; "Wang, Dave" <dwang(a)nuera.com>; <VPalawat(a)opuswave.com>; <kns10(a)cs.columbia.edu> Cc: <joon_maeng(a)vtel.com>; <hemantag(a)globespan.net>; <schulzrinne(a)cs.columbia.edu>; <alan.johnston(a)wcom.com>; "David Daiker" <ddaiker(a)cisco.com>; <paulej(a)cisco.com> Sent: Friday, November 24, 2000 12:10 PM Subject: RE: Draft Status Update > Hi, > > > A comment about > RegistrationRequest.terminalType.gateway.protocol.h323.supportPrefixes IE. > I saw an H.323-ISDN/voice gateway from Cisco (AS5300) that uses the > RegistrationRequest.terminalType.gateway.protocol.voice.supportPrefixes IE > instead of > RegistrationRequest.terminalType.gateway.protocol.h323.supportPrefixes IE to > define the supported prefixes. > > Dave, can you comment on this? > regards, > > charles > > > > -----Original Message----- > From: Wong, Walter [mailto:wwong@nuera.com] > Sent: Wednesday, November 22, 2000 3:13 AM > To: 'Roy, Radhika R, ALCOO'; Agboh, Charles; Wong, Walter; Wong, Walter; > Wang, Dave; VPalawat(a)opuswave.com; kns10(a)cs.columbia.edu > Cc: joon_maeng(a)vtel.com; hemantag(a)globespan.net; > schulzrinne(a)cs.columbia.edu; alan.johnston(a)wcom.com; David Daiker > Subject: RE: Draft Status Update > > > Hi Roy, Charles, and all, > > Thanks Charles for pointing out the use of supportedPrefix field. I think > the IWF can use > RegistrationRequest.terminalType.gateway.protocol.h323.supportPrefixes.prefi > x.e164 field of the RRQ to register an e164 prefix. This way, it's not > non-standard any more. Using "SIP" as the non-standard supportedProtocol > has some concerns. a) It's non-standard, b) The H.323 side will know the > IWF is not a usual or "genuine" H.323 GW. This may violate the requirement > that the IWF should make both side unaware of the protocol difference. > > Charles, do you know if a prefix works for other type of aliases besides > e.164? For example, what if we put ...supportedPrefix.prefix.url-id in the > RRQ? > > As far as standard is concerned, we should leave room for vendors to come up > with their own implementation of how this problem is solved. My proposed > solution is just one of the possible ways to get around the registration > issues. We shouldn't put that as a hard requirement for an IWF to have > table lookup function. My suggestion is to put this as a recommendation and > use the word "MAY", not "MUST". > > -Walter > > -----Original Message----- > From: Roy, Radhika R, ALCOO [mailto:rrroy@att.com] > Sent: Tuesday, November 21, 2000 9:23 AM > To: Agboh, Charles; Wong, Walter; Wong, Walter; Wang, Dave; > VPalawat(a)opuswave.com; kns10(a)cs.columbia.edu > Cc: joon_maeng(a)vtel.com; hemantag(a)globespan.net; > schulzrinne(a)cs.columbia.edu; alan.johnston(a)wcom.com; David Daiker > Subject: RE: Draft Status Update > > > Hi, Charles, Walter and All: > > The non-standard protocol field may provide to do this. The puzzle is that > it is still a "non-standard" and each vendor may implement differently. > > It appears that our SIP-H.323 Interworking standard likes to make this > "non-standard" scheme as the standard one. > > Is that acceptable? Comments? > > Best regards, > Radhika > > -----Original Message----- > From: Agboh, Charles [mailto:Charles.Agboh@gts.com] > Sent: Monday, November 20, 2000 4:54 AM > To: Roy, Radhika R, ALCOO; Wong, Walter; Wong, Walter; Wang, Dave; > VPalawat(a)opuswave.com; kns10(a)cs.columbia.edu > Cc: joon_maeng(a)vtel.com; hemantag(a)globespan.net; > schulzrinne(a)cs.columbia.edu; alan.johnston(a)wcom.com; David Daiker > Subject: RE: Draft Status Update > > > Hi Roy, Walter and all: > > Walter's proposed solution is sound for H.323 v2 compatibility. In the > RegistrationRequest.terminalType.gateway.protocol.h323 | > [nonstandardprotocol].supportPrefixes.prefix.e164 field of the RRQ the IWF > can register an e164 prefix. H.323 gateways register their prefixes using > this field. The supported protocols in this example should not be h323 > (?), instead, it should be "sip" for the IWF. The nonstandardprotocol > field will allow the IWF to register "sip" has the supported protocol. > The "prefix" that the IWF registers should be well-known. > > regards, > > charles > > > -----Original Message----- > From: Roy, Radhika R, ALCOO [mailto:rrroy@att.com] > Sent: Saturday, November 18, 2000 8:52 AM > To: Wong, Walter; Agboh, Charles; Wong, Walter; Wang, Dave; > VPalawat(a)opuswave.com; kns10(a)cs.columbia.edu > Cc: joon_maeng(a)vtel.com; hemantag(a)globespan.net; > schulzrinne(a)cs.columbia.edu; alan.johnston(a)wcom.com; David Daiker > Subject: RE: Draft Status Update > > > Hi, Walter: > > Yes, your proposal is a good one considering all the options that we have. > In fact, the grouping of the addresses shall be the main aspect of the > registration by the IWF in any situation. > > For E.164, it is clear. Let all members provide comments for grouping of the > SIP addresses as proposed by you. In fact, we are assuming that the IWF will > have the capabilities for the local address translation using the table > look-up, and grouping of the SIP-side address may be another feature. The > question is: How far we can make this acceptable from the standard point of > view? > > Best regards, > Radhika > > -----Original Message----- > From: Wong, Walter [mailto:wwong@nuera.com] > Sent: Friday, November 17, 2000 2:48 PM > To: Roy, Radhika R, ALCOO; Agboh, Charles; Wong, Walter; Wang, Dave; > VPalawat(a)opuswave.com; kns10(a)cs.columbia.edu > Cc: joon_maeng(a)vtel.com; hemantag(a)globespan.net; > schulzrinne(a)cs.columbia.edu; alan.johnston(a)wcom.com; David Daiker > Subject: RE: Draft Status Update > > > Hi Radhika, Charles and all, > > Regarding the 2 solutions we have discussed, both have backward compatility > problems. H.323 v4 case is obvious. The lightweight RRQ with KeepAlive > solution also require modification of current GK behavior by implementing > the new recommendation. So the IWF would still have problem when working > with existing GK's out there that did not implement the new recommendation. > > So as far as backward compatibility is concerned, each of the 2 solutions > don't have advantage over the other. Because of the tricky nature of the > lightweight RRQ approach, I tend to agree working towards H.323 V4 may be a > better way to go. > > But we still need to address the issue when we integrate the IWF into an > existing H.323 v2 GK domain. One possible way is to pre-register all SIP > endpoints to the GK by static GK configuration. This is not a good solution > because of the static nature of the approach. It loses the dynamic power of > reqister and unregister. It also require reconfiguring the GK whenever > there is a change on the SIP side. > > Another thinking that I have is to put some address mapping intellegence in > the IWF. The IWF maps a SIP url to a specific e.164 number. The good thing > about e.164 number is we can group the numbers with a prefix. For example, > in the GK domain, we can assign a number prefix for the SIP network that's > on the other side of the IWF. Then pre-register all numbers with this > prefix (i.e. any number with area code 123) by static GK configuration. > This way, any destination number with the prefix 123 will get routed by the > GK to the IWF. The IWF then maps the number to a SIP url when connecting > the call to the SIP side. From the SIP side, the IWF assigns a number with > prefix 123 for each SIP endpoint that registers with the IWF and keeps the > assignment in a local map. When a SIP call is going through the IWF to the > H323 side, the IWF uses this number from the local map with prefix 123 as > the source alias when connecting the call with the GK. > > The advantage of this approach is it doesn't require registering of all the > SIP endpoints individually. Instead, register them as a group. > > This approach would work the best if we can find a way to do registration > with a group of numbers using some range or wildcard notion in the RRQ. It > would solve the problem of statically configuring the GK and allow for > dynamic registeration. Unfortunately I wasn't able to find such a way from > the current H.323 documentation. Does anyone aware of any such way to do > group registration without specifying individual aliases in the RRQ? > > Thanks, > > -Walter > > -----Original Message----- > From: Roy, Radhika R, ALCOO [mailto:rrroy@att.com] > Sent: Thursday, November 16, 2000 11:29 PM > To: Agboh, Charles; 'Wong, Walter'; Wang, Dave; VPalawat(a)opuswave.com; > kns10(a)cs.columbia.edu > Cc: joon_maeng(a)vtel.com; hemantag(a)globespan.net; > schulzrinne(a)cs.columbia.edu; alan.johnston(a)wcom.com; David Daiker > Subject: RE: Draft Status Update > > > Hi, Charles and Walter: > > The solution is in sight to proceed with standardization form H.323 version > 2 to H.323 Version 4 as quickly as possible keeping in mind that we have > problems now. > > Radhika > > -----Original Message----- > From: Agboh, Charles [mailto:Charles.Agboh@gts.com] > Sent: Thursday, November 16, 2000 6:06 AM > To: 'Wong, Walter'; Roy, Radhika R, ALCOO; Wang, Dave; > VPalawat(a)opuswave.com; kns10(a)cs.columbia.edu > Cc: joon_maeng(a)vtel.com; hemantag(a)globespan.net; > schulzrinne(a)cs.columbia.edu; alan.johnston(a)wcom.com; David Daiker > Subject: RE: Draft Status Update > > > Hi Walter, > > > You are right, use of lightweight RRQ for additive registration is tricky. > The keyword is "SHOULD". The recommeded behaivior for a GK is to ignore the > terminalAlias field in the lightweight RRQ. So what can we do to allow the > SIP EP to register its aliase via the IWF without using non-standard "tips > and tricks". > > - Base the I-D on H.323 v4: Backward compatibility problem (not really > an option) > - Recommend that the GK SHOULD NOT replace new alias address (for the > same transport address) and SHOULD NOT ignore the terminalAlias fields in a > lightweight RRQ for a given endpointIdentifier when communicating with the > IWF or any other type of gateway. This will be backward compatible with > H.323v2 (as you can see below: ".....should...." ). > > *Section 7.2.2/H.323v2 > ------------------------------- > " If the Gatekeeper receives an RRQ having the same > Transport Address as a previous RRQ and a different alias address, it should > replace the translation table entries." > > *Section 7.9.1/H.225v2 > ------------------------------- > > "A gatekeeper in receipt of RRQ with a keepAlive field set to TRUE > should ignore fields other than endpointIdentifier, gatekeeperIdentifier, > tokens, and timeToLive." > > comments or suggestions? > regards, > > charles > > > -----Original Message----- > From: Wong, Walter [mailto:wwong@nuera.com] > Sent: Wednesday, November 15, 2000 7:48 PM > To: Agboh, Charles; 'Roy, Radhika R, ALCOO'; Wang, Dave; > VPalawat(a)opuswave.com; kns10(a)cs.columbia.edu > Cc: joon_maeng(a)vtel.com; hemantag(a)globespan.net; > schulzrinne(a)cs.columbia.edu; alan.johnston(a)wcom.com; Wong, Walter > Subject: RE: Draft Status Update > > > Hi Charles, > > You right, one RRQ may not be able to carry all aliases because of the size > limitation of the packet. So we have to find a way for the IWF to register > all the SIP endpoints in seperate RRQs. > > The use of lightweight RRQ is tricky and need more thought. When TTL > expires, an RRQ should contain the "KeepAlive" field set to TRUE. Here is > the description of KeepAlive from section 7.9.1 of H225v3: > > " > keepAlive - If set to TRUE indicates that the endpoint has sent this RRQ as > a "keep alive". An endpoint can send a lightweight RRQ consisting of only > rasAddress, keepAlive, endpointIdentifier, gatekeeperIdentifier, tokens, and > timeToLive. A gatekeeper in receipt of RRQ with a keepAlive field set to > TRUE should ignore fields other than endpointIdentifier, > gatekeeperIdentifier, tokens, and timeToLive. The rasAddress in a > lightweight RRQ shall only be used by a gatekeeper as the destination for an > RRJ when the endpoint is not registered. > " > > The tricky part about this is: when KeepAlive is TRUE, the GK should ignore > the Terminal Alias field (3rd sentense above). However, if we set the > KeepAlive to FALSE, the GK may treat it as a new RRQ and thus, overwrites > the previously registerred aliases. This GK behavior may be vendor > implementation dependent. Apparently, the GK I did the experiment with was > doing it this way. > > The additive registration feature in H323 V4 seems to be a promissing > solution. However, it brings up a backward compatibility issue when the IWF > is talking to a H323 V2 GK. > > -Walter > > -----Original Message----- > From: Agboh, Charles [mailto:Charles.Agboh@gts.com] > Sent: Wednesday, November 15, 2000 7:48 AM > To: 'Roy, Radhika R, ALCOO'; Wang, Dave; VPalawat(a)opuswave.com; > kns10(a)cs.columbia.edu > Cc: joon_maeng(a)vtel.com; hemantag(a)globespan.net; > schulzrinne(a)cs.columbia.edu; alan.johnston(a)wcom.com; Wong, Walter > Subject: RE: Draft Status Update > > > Hi, > > The problem with registering multiple alias addresses with a GK was this: > the size limitation of a UDP packet just prevented that from happening. A > solution around this limitation is to use the additive registration feature > in H.323 v4. Unfortunately our current I-D is based on H.323V2. An > interim solution may be the use of the lighweight RRQ. With this > approache, each time an RRQ TTL expires the IWF may send more aliases to the > GK (should fill the terminal alias field). The problem with this > solution is that the RRQ is no longer *lightweight*. The second problem > which walter mentioned is that the GK overwrites previous terminalAlias (It > shoudn't since the terminal alias's are different while the transport > address remains the same). > > Best regards, > > charles > > -----Original Message----- > From: Roy, Radhika R, ALCOO [mailto:rrroy@att.com] > Sent: Wednesday, November 15, 2000 7:38 AM > To: Wang, Dave; VPalawat(a)opuswave.com; Agboh, Charles; > kns10(a)cs.columbia.edu > Cc: joon_maeng(a)vtel.com; hemantag(a)globespan.net; > schulzrinne(a)cs.columbia.edu; alan.johnston(a)wcom.com; Wong, Walter > Subject: RE: Draft Status Update > > > Hi, Walter and All: > > I guess that you may be right. > > Can we change the behavior like this: Can we not say that the IWF sends all > aliases together each time it sends the RRQ? > > It may be a crude method. What else could we do? The other solution may be > to make GK and IWF collocated. We may not like to do this as well. > > All members are requested to provide their comments as well. > > Best regards, > Radhika > > -----Original Message----- > From: Wang, Dave [mailto:dwang@nuera.com] > Sent: Tuesday, November 14, 2000 3:33 AM > To: VPalawat(a)opuswave.com; Roy, Radhika R, ALCOO; Charles.Agboh(a)gts.com; > kns10(a)cs.columbia.edu > Cc: joon_maeng(a)vtel.com; hemantag(a)globespan.net; > schulzrinne(a)cs.columbia.edu; alan.johnston(a)wcom.com; dwang(a)nuera.com; > Wong, Walter > Subject: RE: Draft Status Update > > > Hi All, > > Here is some comments from my colleague Walter Wong, who is our expert on > SIP/H.323 IWF. You may want to replace me by Walter in the e-mail list, and > consider recruiting him in this work and drop me off it. > > David Wang > > > -----Original Message----- > > From: Wong, Walter > > Sent: Monday, November 13, 2000 7:29 PM > > To: Wang, Dave > > Subject: RE: Draft Status Update > > > > > > Hi Dave, > > > > The registration scheme specified here for registering with > > GK my not work. The IWF may not be able to send seperate RRQ > > for each SIP end point. Here is the description from > > H.225v3, section 7.9.1 on RRQ: > > > > "terminalAlias -This optional value is a list of alias > > addresses, by which other terminals may identify this > > terminal. If the terminalAlias is null, or an E.164 address > > is not present, an E.164 address may be assigned by the > > gatekeeper, and included in the RCF. If an email-ID is > > available for the endpoint, it should be registered. Note > > that multiple alias addresses may refer to the same transport > > addresses. All of the endpoint's aliases shall be included in > > each RRQ." > > > > The scheme seems to be violating the last sentense. > > > > I've also done some experiment with the Cisco 3600 GK. If I > > send RRQ with 8000001 then another RRQ with 8000002 from the > > same GW, the GK loses the 8000001 as soon as the RRQ for > > 8000002 is received. > > > > We have to find another way to get around this unless we can > > change the GK behavior. Packing all individual endpoint > > aliases in 1 RRQ is not a good solution because it's limited > > by the size of the RRQ. I have not been successful in > > finding a way to specify a range of aliases or use wildcard > > in the RRQ. Although not flexible, statically configuring > > the GK may be a workable solution. > > > > -Walter > > > -----Original Message----- > > From: VPalawat(a)opuswave.com [mailto:VPalawat@opuswave.com] > > Sent: Monday, November 13, 2000 1:33 PM > > To: rrroy(a)att.com; VPalawat(a)opuswave.com; Charles.Agboh(a)gts.com; > > kns10(a)cs.columbia.edu > > Cc: joon_maeng(a)vtel.com; hemantag(a)globespan.net; > > schulzrinne(a)cs.columbia.edu; alan.johnston(a)wcom.com; dwang(a)nuera.com > > Subject: RE: Draft Status Update > > > > > > Hi All, > > > > A quick update on the draft status: > > > > * Last minute changes and some error corrections to Call Flow > > diagrams. > > > > * More additions to other sections are under progress. > > * Draft formatting is under progress. > > > > Please let me know if you have any comments/suggestions on my > > approach/opinion. > > > > Best Regards > > Vipin > > > > > > > > > > -----Original Message----- > > From: Roy, Radhika R, ALCOO [mailto:rrroy@att.com] > > Sent: Sunday, November 12, 2000 10:53 AM > > To: VPalawat(a)opuswave.com; Charles.Agboh(a)gts.com; > > kns10(a)cs.columbia.edu > > Cc: joon_maeng(a)vtel.com; hemantag(a)globespan.net; > > schulzrinne(a)cs.columbia.edu; alan.johnston(a)wcom.com; dwang(a)nuera.com > > Subject: RE: Draft Status Update > > > > << File: Registration_v3.txt >> << File: > > Requirements.txt > > >> Hi, Vipin and All: > > > > I am enclosing two files for the following two sections: > > > > 1. Registration and Address Resolution (Version 3) > > 2. SIP-H.323 Interworking Requirements > > > > For address resolution, I have an issue as follows: > > > > Does the IWF will send the response (200 OK) to > > the SIP EP > > after receiving > > the REGISTER message because we do not assume > > that IWF may > > act as the > > register server? > > > > Based on comments provided earlier, I have > > modified the last > > flow diagram > > assuming that the IWF and the H.323 GK are NOT > > co-located. > > Still, I have > > been able to use the OPTIONS message to resolve the > > H.323-side addresses. > > However, I have not been able to use the > > OPTIONS message for > > resolving the > > SIP-side addresses if the ARQ/LRQ messages come from the > > H.323-side unless > > IWF and GK are co-located. > > > > Can anyone help to find examples for this > > scenario using the > > OPTIONS > > message? > > > > The OPTIONS message is an extremely useful one and H.323 > > does NOT have any > > equivalent one. (It silently provides all the > > capabilities > > of the SIP > > entities without going through needless > > negotiations like > > H.245 messages.) > > > > I am yet to show all fields of all messages in > > the message > > flows. Hope to > > refine those later. > > > > For the SIP-H.323 Interworking Requirements > > section, I also > > like to have > > your comments. > > > > Best regards, > > Radhika > > > > PS: I have apprised the ITU-T SG16 Q.13/16 > > meeting delegates > > about the > > progress of our SIP-H.323 Interworking works in > > the IETF. > > > > > > > > -----Original Message----- > > From: VPalawat(a)opuswave.com > > [mailto:VPalawat@opuswave.com] > > Sent: Friday, November 10, 2000 2:45 PM > > To: VPalawat(a)opuswave.com; Charles.Agboh(a)gts.com; > > kns10(a)cs.columbia.edu > > Cc: joon_maeng(a)vtel.com; hemantag(a)globespan.net; > > schulzrinne(a)cs.columbia.edu; alan.johnston(a)wcom.com; > > dwang(a)nuera.com; > > Roy, Radhika R, ALCOO > > Subject: RE: Draft Status Update > > > > > > Hi All, > > > > Here is a quick update on the status of the draft. > > > > * Detailed description of calls along > > with message > > details in call > > flow diagrams is complete. > > > > * Basic message handling Section is > > nearly complete. > > > > Following sections are still under progress: > > > > * State m/c diagram. Lot of work is there. > > > > > > I would like to have your opinion on the state > > of the draft. > > I also want to know that if in case we were unable to > > complete the state m/c > > on time, then > > Can we include it in the "TO DO" list and later > > we will add > > it into the next > > release of the same draft. > > This is because I don't want to put everything > > in a rush. > > This will impact > > the quality of the document. > > We have already written the draft in a short > > time, so I feel > > if we were > > unable to complete that section, > > Then it is better to put it in the "TO DO" list > > and better > > concentrate on > > the review of the existing stuff. > > > > I would like to have your opinions on this. > > > > Please let me know if you have any > > comments/suggestions on > > my > > approach/opinion. > > > > Best Regards > > Vipin > > > > > > > > -----Original Message----- > > From: Palawat, Vipin > > Sent: Thursday, November 09, > > 2000 10:02 AM > > To: 'Agboh, Charles'; 'Kundan Singh' > > Cc: Palawat, Vipin; > > joon_maeng(a)vtel.com; > > hemantag(a)globespan.net; schulzrinne(a)cs.columbia.edu; > > alan.johnston(a)wcom.com; > > dwang(a)nuera.com; rrroy(a)att.com > > Subject: Draft Status Update > > > > Hi All, > > > > Here is a quick update on the > > status of the > > draft. > > > > Following section were almost complete: > > * Detailed description and call message details in > > call flow diagrams. > > > > Following sections are > > still under > > progress: > > * Basic Call Handling. > > * State m/c > > > > Please let me know if you have any > > comments/suggestions on > > my approach/opinion. > > > > Best Regards > > Vipin > > > > > > > > -----Original > > Message----- > > From: Agboh, Charles > > [mailto:Charles.Agboh@gts.com] > > Sent: > > Wednesday, November > > 08, 2000 3:05 PM > > To: 'Kundan Singh' > > Cc: > > 'VPalawat(a)opuswave.com'; > > ddaiker(a)cisco.com; joon_maeng(a)vtel.com; > > hemantag(a)globespan.net; > > schulzrinne(a)cs.columbia.edu; alan.johnston(a)wcom.com; > > dwang(a)nuera.com; > > rrroy(a)att.com > > Subject: > > RE: Message > > Mapping: > > SIP-H.323 interworking > > > > Hi, > > > > Can we keep Dave > > (ddaiker(a)cisco.com) in the > > discussion. > > > > > > regards > > charles > > -----Original > > Message----- > > From: Kundan Singh > > [mailto:kns10@cs.columbia.edu] > > Sent: > > Wednesday, November > > 08, 2000 6:57 PM > > To: Agboh, Charles > > Cc: > > 'VPalawat(a)opuswave.com'; > > ddaiker(a)cisco.com; joon_maeng(a)vtel.com; > > hemantag(a)globespan.net; > > schulzrinne(a)cs.columbia.edu; > > alan.johnston(a)wcom.com; > > dwang(a)nuera.com; > > rrroy(a)att.com > > Subject: RE: Message > > Mapping: SIP-H.323 > > interworking > > > > > > > > > > > Are we going > > to constrain > > an > > implementation to an algorithm for matching > > SDP > > > capability > > description ang > > H.245? I think > > we should leave it open and say > > > that there must be at > > least an > > intersection and that intersection must > > > include G.711. > > > > I agree that it > > should be > > open, however, we > > can provide a > > guideline for > > finding such > > intersection with > > examples. > > Secondly, > > "intersection must > > include G.711" > > is not > > acceptable, I think, > > especially if the SIP > > side > > does not > > support G.711 and > > the IWF provider > > is capable of doing > > conversion between > > G.711 (from > > H.323 EP) and > > some other codec > > (from SIP UA). > > Having G.711 always > > mandatory will > > eventually cause the > > SIP calls > > (without G.711) to > > be always > > rejected. > > > > > H.225.0/Q.931 > > part (not > > UUIE): > > > > I think, we can > > ignore the > > unnecessary > > fields in > > this phase and > > can look at > > it in the next > > phase, if needed. > > Some of the fields (like > > Caller Number) can > > be used > > in IWF. > > > > Will send more comments > > soon. > > > > Thanks and regards > > > > Kundan > > > > > Can we get perspective > > from vendors on > > this (ie. bearer cap..) > > > > > > vipin, how do > > you want to > > proceed? > > > regards, > > > > > > charles > > > -----Original > > Message----- > > > From: > > VPalawat(a)opuswave.com > > [mailto:VPalawat@opuswave.com] > > > Sent: > > Wednesday, November > > 08, 2000 5:45 PM > > > To: Agboh, Charles; > > ddaiker(a)cisco.com > > > Cc: > > joon_maeng(a)vtel.com; > > hemantag(a)globespan.net; > > > > > schulzrinne(a)cs.columbia.edu; > > alan.johnston(a)wcom.com; dwang(a)nuera.com; > > > rrroy(a)att.com; > > VPalawat(a)opuswave.com; > > kns10(a)cs.columbia.edu > > > Subject: RE: Message > > Mapping: SIP-H.323 > > interworking > > > > > > > > > Hi All, > > > > > > A quick update on the > > status of the > > current draft. > > > > > > * Work in > > still going > > on in the > > following sections. > > > * > > Description of Call > > Flow diagrams. > > > * State m/c > > > * Basic Message > > Handling. > > > > > > As soon as > > the draft comes > > to a complete > > and good shape, I will forward it > > > to all the editors. > > > > > > I will keep > > on updating > > the status twice a > > day. > > > > > > Please let me > > know if you > > have any > > comments/suggestions on my > > > approach/opinion. > > > > > > Best Regards > > > Vipin > > > > > > > > > > > > > > > > > -----Original Message----- > > > From: > > Agboh, Charles > > [mailto:Charles.Agboh@gts.com] > > > Sent: > > Tuesday, November > > 07, 2000 11:19 AM > > > To: > > 'David Daiker' > > > Cc: > > Agboh, Charles; > > joon_maeng(a)vtel.com; > > > > > hemantag(a)globespan.net; > > schulzrinne(a)cs.columbia.edu; > > alan.johnston(a)wcom.com; > > > dwang(a)nuera.com; > > rrroy(a)att.com; > > VPalawat(a)opuswave.com; > > kns10(a)cs.columbia.edu > > > Subject: > > RE: Message > > Mapping: SIP-H.323 interworking > > > > > > > > Hi David, > > > > > > > > I will open > > the discussion > > tomorrow with my contribution > > > which is mostly > > > > > derived from > > Kundan Singh's > > work (Its going to be a long > > > night). I think > > > > > it will be > > difficult to come > > up with something consistent > > > before the 16th > > > > > but, we will > > try. > > > > > > > > We welcome > > your > > participation in this discussion. > > > > > > Best > > regards, > > > > > > charles, > > > > > > > > -----Original Message----- > > > > > From: David > > Daiker > > [mailto:ddaiker@cisco.com] > > > Sent: > > Tuesday, November 07, > > 2000 4:50 PM > > > > > To: Agboh, > > Charles > > > > > Cc: David > > Daiker > > > > > Subject: Re: > > Message > > Mapping: SIP-H.323 interworking > > > > > > > > > > > > > > Hi Charles, > > > > > > > > Sorry for > > the late response, > > I am just starting to look at > > > mapping > > headers/parms/ies > > between sip/isup/h323. > > > > > > > > And quite > > honestly, other > > than the obvious (calling, called, > > > bearer cap, > > > > > timestamps) > > I don't have > > anything specific in mind. > > > > > > Though I > > will certainly > > provide Cisco's perspective and > > > participate > > > in any > > discussions. > > > > > > thanks, > > > > > > david > > > > > > > > > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

2 1

Correction to the approved H.225.0 v4 ASN.1
by Rich Bowen 27 Nov '00

27 Nov '00

Folks, An error in the approved H.225.0 v4 ASN.1 has been brought to my attention. At the meeting 2 weeks ago, we agreed to change the syntax of the "group" fields from OCTET STRING to IA5String. Somehow during a 3:00 am editing session I managed to update one of the "group" fields but not the other. Unless there are any objections, the following editorial change will be submitted to Mr. Bigi for inclusion in the published ASN.1. CallsAvailable ::= SEQUENCE { calls INTEGER (0..4294967295), group OCTET STRING (SIZE (2..4)) OPTIONAL, ... } will be replaced with: CallsAvailable ::= SEQUENCE { calls INTEGER (0..4294967295), group IA5String (SIZE (1..128)) OPTIONAL, ... } This will be consistent with the other "group" field definition: GroupID ::= SEQUENCE { member SEQUENCE OF INTEGER (0..65535) OPTIONAL, group IA5String (SIZE (1..128)), ... } Regards, Rich ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0