November 2000 - sg16-avd - lists.packetizer.com

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