- sg16-avd - lists.packetizer.com

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