- sg16-avd - lists.packetizer.com

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

27 Nov '00

Hi, All: Let me add a little more. The term "third party" indicates that it is doing something on behalf of the "first" party and is NOT involved at all for anything. However, in the case of IWF, the transport address of the IWF is being used for all aliases that are being registered. In true sense, IWF becomes a party "indirectly" for all aliases. As Chris mentioned, the term "third party" has not been used by the H.323 GW (H.323v2) for the registration although it is registering many alias addresses to the H.323 GK. However, in SIP, the "third party" registration has been clearly defined, and third party does not get involved once the registration is over. I believe that H.323v2 does not define the third party registration as it is supposed to be. Hope this will clarify blending the views of both Chris and Charles. Best regards, Radhika -----Original Message----- From: Agboh, Charles [mailto:Charles.Agboh@GTS.COM] Sent: Monday, November 27, 2000 11:56 AM To: ITU-SG16(a)MAILBAG.INTEL.COM Subject: Re: Third party registration/group registration sorry,... Hi Chris, 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. 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 } regards, charles -----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 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 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 27 Nov '00

27 Nov '00

sorry,... Hi Chris, 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. 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 } regards, charles -----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 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 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 27 Nov '00

27 Nov '00

Hi Chris, 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. H.323v4 provides this feature (a way to bypass the UDP packet size limitation) for this same reason. What I would like is -----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 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

clarification needed
by mvikram 27 Nov '00

27 Nov '00

Hi All, I need clarifications on following : 1. In H.245 conferencing, whenever an MCU receives dropTerminalRequest from a chair token owner, MCU responds with terminalLeftConference Indication(as per H.243). But as per the H.245 recommendation, every request shall have a corresponding response. This creates a sort of ambiguity. Is it a valid response to the dropTerminalRequest? 2. According to H.243 an MCU sends CCR( same as withdrawChairToken Indication/makeMeChairResponse in H.245) in response to cancelMakeMeChair request.Which one of these is a valid response? regards vikram ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 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 27 Nov '00

27 Nov '00

Hi, Chris and Charles: I agree with Chris that we may avoid the term "Third Party" for registration in H.323. Best regards, Radhika -----Original Message----- From: Chris Wayman Purvis [mailto:cwp@ISDN-COMMS.CO.UK] Sent: Monday, November 27, 2000 4:41 AM To: ITU-SG16(a)MAILBAG.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 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 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.323 Mobility:] MD-112 (H.323 Annex H Draft) uploaded
by Jaakko Sundquist 27 Nov '00

27 Nov '00

Hi all, I have uploaded MD-112 to the pictel ftp site (URL: ftp://standard.pictel.com/avc-site/Incoming/Mobility-AHG/) The document includes the last draft version of the H.323 Annex H that I will produce as the editor of the annex and it includes additions due to the APC-2017 (comparison with 3GPP All IP architecture) that were presented in the Rapporteurs' meeting in Geneva. I would like to thank all the people that have been involved in the work on H.323 Annex H during the time of my editorship and I wish all the best for the next editor, whoever he/she might be. I will also offer my help concerning questions about the current draft of the annex. ------------------------------------------------ Jaakko Sundquist * +358 50 3598281 * Audere est Facere! jaakko.sundquist(a)nokia.com * ------------------------------------------------ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

Re: Request of uploading : H.323 Annex K
by Espen Skj�ran 27 Nov '00

27 Nov '00

Hi All, I've uploaded the edited documents for H.323 Annex K, which was decided in Geneva Nov 17th. It's on ftp://standard.pictel.com/avc-site/Incoming/h323-annexk-decision.zip It contains two files, where the _wcm.doc has changemarks, and _ncm.doc has none. Regards, Espen Skjæran -----Original Message----- From: Sakae OKUBO [mailto:sakae.okubo@ties.itu.ch] Sent: 18. november 2000 02:00 To: ITU-SG16(a)mailbag.cps.intel.com Subject: Request of uploading Dear Editors, Could you please upload the final edited documents for decision, approval, "consent", "previously intended determination" to the PictureTel site and announce through the reflector? Best regards, Sakae OKUBO *********************************************************** Waseda Research Center Telecommunications Advancement Organization of Japan (TAO) 5th Floor, Nishi-Waseda Bldg. 1-21-1 Nishi-Waseda, Shinjuku-ku, Tokyo 169-0051 Japan Tel: +81 3 5286 3830 (to be transferred) +81 3 3204 8194 (direct) Fax: +81 3 5287 7287 e-mail: okubo(a)giti.or.jp *********************************************************** ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 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 27 Nov '00

27 Nov '00

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 -----Original Message----- From: Chris Wayman Purvis [mailto:cwp@isdn-comms.co.uk] Sent: Friday, November 24, 2000 6:44 PM To: Agboh, Charles Cc: ITU-SG16(a)mailbag.cps.intel.com Subject: Re: Third party registration/group registration Charles, If your application is a gateway, this is NOT third-party registration. It is simply registration of a potentially large number of aliases. The gateway is not registering on behalf of several H.323 endpoints - it is the edge of the H.323 network as far as signalling is concerned. This appears to be possible in version 4 (although probably not before) of H.225.0 using the "additiveRegistration" field in RRQ. Regards, Chris "Agboh, Charles" wrote: > > Chris, > > Q1: How can I support third party registration in H.323 v2? > > A:1 alternateEndpoint structure but I have the UDP packet size > limitation so if I want to do third party registration on behalf of > thousands of EPs what can I do? > > Q2: Is there a clean way to circumvent this limit? > > The application is an H.323-X gateway. X may be SIP. > > regards, > > charles > > -----Original Message----- > From: Chris Wayman Purvis [mailto:cwp@isdn-comms.co.uk] > Sent: Friday, November 24, 2000 5:48 PM > To: Agboh, Charles > Cc: ITU-SG16(a)mailbag.cps.intel.com > Subject: Re: Third party registration/group registration > > Charles, > > The way you describe this I don't understand how it is "third-party". > > It is possible to register lots of aliases simultaneously to the same > endpoint. This is not third-party as I understand the term. The size of a > single RRQ is limited by your transport network, but if you're using UDP > that > gives you about 64 kilobytes - is that really not enough for your purposes? > > Maybe you should describe your application, so we can think about how to > achieve the desired result. > > Regards, > Chris > > "Agboh, Charles" wrote: > > > > Chris, all; > > > > Thanks for the response. The scenario I am thinking off is this. > > > > -(a) for a single endpointIdentifier > > -(b) for a single callSignalingAddress/rasAddress > > -(c) potentially thousands of terminalAlias's. > > > > In version 2, (a) and (b) are not supported together because of the > > following text in H.225.0 V2: > > > > (d) Section 7.2.2 > > ----------------- > > > > "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." > > > > My question is, how can I have (a), (b), (c) or third party registration > > with (c). > > > > I was thinking that the alternateEndpoint Structure may be usful for (c) > but > > there is the limitation of the size of the UDP packet. An alternative > could > > be to use the lightweight RRQ but from section 7.9.1 of H.225.0: > > > > "An endpoint can send a lightweight RRQ consisting of only keepAlive, > > endpointIdentifier, gatekeeperIdentifier, tokens, and timeToLive." > > > > The last resort for (a), (b) and (c). > > --------------------------------------- > > > > -H.323v4 addtitive registration > > -Group registration (i.e. e164 prefix registration). This is supported in > > v2->v4. > > -Is there another method I can use with an H.323 complaint GK without > > creating backward compatibility problems. > > > > Best regards, > > > > charles > > > > -----Original Message----- > > From: Chris Wayman Purvis [mailto:cwp@ISDN-COMMS.CO.UK] > > Sent: Friday, November 24, 2000 2:41 PM > > To: ITU-SG16(a)MAILBAG.INTEL.COM > > Subject: Re: Third party registration > > > > Charles, All, > > > > > Is third party registration supported in H.323 V2, V3, V4? > > What's your application? > > > > According to "original intent", the answer is "yes". However this will > > surprise a lot of people and I doubt you'll find many gatekeepers to > support > > it. It all comes down to a couple of strange-looking "sequence of"s in > RRQ. > > I > > was reliably informed some time ago that the original intent was that IF > RRQ > > gives more than one callSignalAddresses, it should give the same number of > > rasAddresses and either none or the same number of terminalAliases. > > Similarly > > if giving more than one rasAddress there should be the same number of > > callSignalAddresses Then the first element in each list maps to the first > > element of the others, the second to the second etc. My assumption is > that > > RCF > > or RRJ ought to be sent only to the first rasAddress in the list. > > However, as I said before, this is an undocumented "original intent", and > > the > > ASN.1 that came out of it is far from the best way to achieve it. I don't > > know > > if anybody actually handles multiple entries in these fields (apart from > > terminalAlias) or, if they do, HOW they handle them. > > > > Does anyone out there with a gatekeeper have any input on whether or how > > they > > handle this? > > > > Charles, > > > > I'm cross-posting this to the H.323 implementors list - you may get more > > idea > > of what's actually implemented from there. > > > > Regards, > > Chris > > -- > > Dr Chris Purvis -- Development Manager > > ISDN Communications Ltd, The Stable Block, Ronans, Chavey Down Road > > Winkfield Row, Berkshire. RG42 6LY ENGLAND > > Phone: +44 1344 899 007 > > Fax: +44 1344 899 001 > > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > For help on this mail list, send "HELP ITU-SG16" in a message to > > listserv(a)mailbag.intel.com > > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > For help on this mail list, send "HELP ITU-SG16" in a message to > > listserv(a)mailbag.intel.com > > -- > Dr Chris Purvis -- Development Manager > ISDN Communications Ltd, The Stable Block, Ronans, Chavey Down Road > Winkfield Row, Berkshire. RG42 6LY ENGLAND > Phone: +44 1344 899 007 > Fax: +44 1344 899 001 > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > For help on this mail list, send "HELP ITU-SG16" in a message to > listserv(a)mailbag.intel.com -- Dr Chris Purvis -- Development Manager ISDN Communications Ltd, The Stable Block, Ronans, Chavey Down Road Winkfield Row, Berkshire. RG42 6LY ENGLAND Phone: +44 1344 899 007 Fax: +44 1344 899 001 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

2 1

H225 Annex G v2 document uploaded to Incoming directory
by Michael Fortinsky 27 Nov '00

27 Nov '00

I have uploaded the following document to the Incoming directory of the PictureTel site: H225-AnnexG-v2-intended-determined.zip This file contains pl-057.doc, the plenary TD from the recent Geneva SG16 meeting that contains the latest H.225.0 Annex G v2. This is the clean document (no change marks) that was intended to be determined in Geneva. I have not yet had the time to prepare the document containing change marks. Michael Fortinsky ----------------------------------------------------------------- Senior Program Manager, IP Telephony Group, VocalTec Communications Ltd. Email: mike(a)vocaltec.com Tel: 972 9 9707768 Fax: 972 9 9561867

1 0

Output documents from the SG16 meeting in Geneva
by Sakae OKUBO 27 Nov '00

27 Nov '00

Dear SG16 colleagues, All the subject files uploaded so far, including H.225.0 v4, have been moved to http://standard.pictel.com/ftp/avc-site/0011_Gen/. As part of producing its index, I am trying to complete the attached table. Editors are encouraged to upload his/her works. Best regards, Sakae OKUBO *********************************************************** Waseda Research Center Telecommunications Advancement Organization of Japan (TAO) 5th Floor, Nishi-Waseda Bldg. 1-21-1 Nishi-Waseda, Shinjuku-ku, Tokyo 169-0051 Japan Tel: +81 3 5286 3830 (to be transferred) +81 3 3204 8194 (direct) Fax: +81 3 5287 7287 e-mail: okubo(a)giti.or.jp ***********************************************************

1 0

Virus is found in E-MAIL you send us.
by Shmuel Attiya (SA) 26 Nov '00

26 Nov '00

Sorry to tell you but our mailing system detect that you have send us an Virus infected E-MAIL. Please detect your viruses by your self before sending it to us. no other notice will be send. but in case of other virus detection from you your mail will be block Shmuel attiya System Administrator Accord Networks shmuel(a)accord.co.il Tel:+972-3-9251 431 Fax:+972-3-9211571 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

Packetizer updated
by Paul E. Jones 25 Nov '00

25 Nov '00

Folks, I have updated Packetizer with information about H.323v4 and H.248 annexes. Please review the information on these pages for errors (especially the document status of current draft and recently approved documents): http://www.packetizer.com/iptel/h248/ http://www.packetizer.com/iptel/h248/doc_status.html http://www.packetizer.com/iptel/h323/ http://www.packetizer.com/iptel/h323/doc_status.html Many people use these pages and I want to keep them as accurate as possible. Thanks! Paul ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 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 24 Nov '00

24 Nov '00

Chris, Q1: How can I support third party registration in H.323 v2? A:1 alternateEndpoint structure but I have the UDP packet size limitation so if I want to do third party registration on behalf of thousands of EPs what can I do? Q2: Is there a clean way to circumvent this limit? The application is an H.323-X gateway. X may be SIP. regards, charles -----Original Message----- From: Chris Wayman Purvis [mailto:cwp@isdn-comms.co.uk] Sent: Friday, November 24, 2000 5:48 PM To: Agboh, Charles Cc: ITU-SG16(a)mailbag.cps.intel.com Subject: Re: Third party registration/group registration Charles, The way you describe this I don't understand how it is "third-party". It is possible to register lots of aliases simultaneously to the same endpoint. This is not third-party as I understand the term. The size of a single RRQ is limited by your transport network, but if you're using UDP that gives you about 64 kilobytes - is that really not enough for your purposes? Maybe you should describe your application, so we can think about how to achieve the desired result. Regards, Chris "Agboh, Charles" wrote: > > Chris, all; > > Thanks for the response. The scenario I am thinking off is this. > > -(a) for a single endpointIdentifier > -(b) for a single callSignalingAddress/rasAddress > -(c) potentially thousands of terminalAlias's. > > In version 2, (a) and (b) are not supported together because of the > following text in H.225.0 V2: > > (d) Section 7.2.2 > ----------------- > > "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." > > My question is, how can I have (a), (b), (c) or third party registration > with (c). > > I was thinking that the alternateEndpoint Structure may be usful for (c) but > there is the limitation of the size of the UDP packet. An alternative could > be to use the lightweight RRQ but from section 7.9.1 of H.225.0: > > "An endpoint can send a lightweight RRQ consisting of only keepAlive, > endpointIdentifier, gatekeeperIdentifier, tokens, and timeToLive." > > The last resort for (a), (b) and (c). > --------------------------------------- > > -H.323v4 addtitive registration > -Group registration (i.e. e164 prefix registration). This is supported in > v2->v4. > -Is there another method I can use with an H.323 complaint GK without > creating backward compatibility problems. > > Best regards, > > charles > > -----Original Message----- > From: Chris Wayman Purvis [mailto:cwp@ISDN-COMMS.CO.UK] > Sent: Friday, November 24, 2000 2:41 PM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: Re: Third party registration > > Charles, All, > > > Is third party registration supported in H.323 V2, V3, V4? > What's your application? > > According to "original intent", the answer is "yes". However this will > surprise a lot of people and I doubt you'll find many gatekeepers to support > it. It all comes down to a couple of strange-looking "sequence of"s in RRQ. > I > was reliably informed some time ago that the original intent was that IF RRQ > gives more than one callSignalAddresses, it should give the same number of > rasAddresses and either none or the same number of terminalAliases. > Similarly > if giving more than one rasAddress there should be the same number of > callSignalAddresses Then the first element in each list maps to the first > element of the others, the second to the second etc. My assumption is that > RCF > or RRJ ought to be sent only to the first rasAddress in the list. > However, as I said before, this is an undocumented "original intent", and > the > ASN.1 that came out of it is far from the best way to achieve it. I don't > know > if anybody actually handles multiple entries in these fields (apart from > terminalAlias) or, if they do, HOW they handle them. > > Does anyone out there with a gatekeeper have any input on whether or how > they > handle this? > > Charles, > > I'm cross-posting this to the H.323 implementors list - you may get more > idea > of what's actually implemented from there. > > Regards, > Chris > -- > 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

2 1

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

24 Nov '00

Chris, all; Thanks for the response. The scenario I am thinking off is this. -(a) for a single endpointIdentifier -(b) for a single callSignalingAddress/rasAddress -(c) potentially thousands of terminalAlias's. In version 2, (a) and (b) are not supported together because of the following text in H.225.0 V2: (d) Section 7.2.2 ----------------- "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." My question is, how can I have (a), (b), (c) or third party registration with (c). I was thinking that the alternateEndpoint Structure may be usful for (c) but there is the limitation of the size of the UDP packet. An alternative could be to use the lightweight RRQ but from section 7.9.1 of H.225.0: "An endpoint can send a lightweight RRQ consisting of only keepAlive, endpointIdentifier, gatekeeperIdentifier, tokens, and timeToLive." The last resort for (a), (b) and (c). --------------------------------------- -H.323v4 addtitive registration -Group registration (i.e. e164 prefix registration). This is supported in v2->v4. -Is there another method I can use with an H.323 complaint GK without creating backward compatibility problems. Best regards, charles -----Original Message----- From: Chris Wayman Purvis [mailto:cwp@ISDN-COMMS.CO.UK] Sent: Friday, November 24, 2000 2:41 PM To: ITU-SG16(a)MAILBAG.INTEL.COM Subject: Re: Third party registration Charles, All, > Is third party registration supported in H.323 V2, V3, V4? What's your application? According to "original intent", the answer is "yes". However this will surprise a lot of people and I doubt you'll find many gatekeepers to support it. It all comes down to a couple of strange-looking "sequence of"s in RRQ. I was reliably informed some time ago that the original intent was that IF RRQ gives more than one callSignalAddresses, it should give the same number of rasAddresses and either none or the same number of terminalAliases. Similarly if giving more than one rasAddress there should be the same number of callSignalAddresses Then the first element in each list maps to the first element of the others, the second to the second etc. My assumption is that RCF or RRJ ought to be sent only to the first rasAddress in the list. However, as I said before, this is an undocumented "original intent", and the ASN.1 that came out of it is far from the best way to achieve it. I don't know if anybody actually handles multiple entries in these fields (apart from terminalAlias) or, if they do, HOW they handle them. Does anyone out there with a gatekeeper have any input on whether or how they handle this? Charles, I'm cross-posting this to the H.323 implementors list - you may get more idea of what's actually implemented from there. Regards, Chris -- 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

Third party registration
by Agboh, Charles 24 Nov '00

24 Nov '00

Hi, Is third party registration supported in H.323 V2, V3, V4? If not, how could we have this feature without introducing backward compatibility problems. I know about the Additive Registration feature of H.323 V4. regards, charles ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

2 1

(no subject)
by David Mary 24 Nov '00

24 Nov '00

1 0

error in H.245
by Wu Yongming 24 Nov '00

24 Nov '00

hi,experts h245 says all request need a repsonse,but i find ConferenceRequest.dropTerminal has no corresponding respone message? any comments? thanks ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

Further update of WP2/16 report
by Sakae OKUBO 24 Nov '00

24 Nov '00

Dear SG16 experts, I have received another material from Mr. Tosco, which lists all the Recommendations WP2/16 is working on. Now the WP2/16 report is as follows: WP2_Report_001117b.zip Report of WP2/16 * WP2_Report_Part_I.doc General, Q1, Q11, Q12, Q13, Q14 * WP2_Report_Part_II.doc Recs for "consent" and texts for approval * WP2_Report_Annex_1.doc Status of Recommendations * WP2_Report_Meetings.doc Planned Rapporteurs meetings * WP2_Report_Liaisons.doc Liaison statements and communications * WP2_Recs_status.doc Recommendations of which WP2/16 is in charge Best regards, Sakae OKUBO *********************************************************** Waseda Research Center Telecommunications Advancement Organization of Japan (TAO) 5th Floor, Nishi-Waseda Bldg. 1-21-1 Nishi-Waseda, Shinjuku-ku, Tokyo 169-0051 Japan Tel: +81 3 5286 3830 (to be transferred) +81 3 3204 8194 (direct) Fax: +81 3 5287 7287 e-mail: okubo(a)giti.or.jp *********************************************************** ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

Decided H.248 Annex F, Fax, text Conversation and Call Discrimination packages uploaded
by Gunnar Hellstrom 23 Nov '00

23 Nov '00

Hi all, The decided H.248 Annex F, Fax, Text Conversation and Call discrimination packages, is uploaded to the Pictel/ AVC site, Incoming directory. Two files are uploaded: H248AnnexFdecided-clean.zip clean H248AnnexFdecided-wcm.zip with change marks Regards Gunnar Hellström **************************************** Gunnar Hellström Ericsson Radio Systems AB tel´+46 708 204 288 ***************************************** ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

AW: Request of uploading
by Euchner Martin 23 Nov '00

23 Nov '00

Mr. Sakae Okubo, due to network problems, my first attempt failed to upload the file H235v2_approved.zip. Would you please remove this file from Incoming, as the zip is not a valid archive. Instead I upload the file once again as H235v2_approved1.zip which was successful. 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: Euchner Martin Gesendet am: Donnerstag, 23. November 2000 10:53 An: 'okubo(a)mxz.mesh.ne.jp'; ITU-SG16(a)mailbag.cps.intel.com Betreff: AW: Request of uploading H.235 Version 2 as approved by the Plenary meeting has been uploaded to the Incoming directory. 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: Sakae OKUBO [SMTP:sakae.okubo@ties.itu.ch] Gesendet am: Samstag, 18. November 2000 02:00 An: ITU-SG16(a)mailbag.cps.intel.com Betreff: Request of uploading Dear Editors, Could you please upload the final edited documents for decision, approval, "consent", "previously intended determination" to the PictureTel site and announce through the reflector? Best regards, Sakae OKUBO *********************************************************** Waseda Research Center Telecommunications Advancement Organization of Japan (TAO) 5th Floor, Nishi-Waseda Bldg. 1-21-1 Nishi-Waseda, Shinjuku-ku, Tokyo 169-0051 Japan Tel: +81 3 5286 3830 (to be transferred) +81 3 3204 8194 (direct) Fax: +81 3 5287 7287 e-mail: okubo(a)giti.or.jp *********************************************************** ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 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: Request of uploading
by Euchner Martin 23 Nov '00

23 Nov '00

H.235 Version 2 as approved by the Plenary meeting has been uploaded to the Incoming directory. 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: Sakae OKUBO [SMTP:sakae.okubo@ties.itu.ch] Gesendet am: Samstag, 18. November 2000 02:00 An: ITU-SG16(a)mailbag.cps.intel.com Betreff: Request of uploading Dear Editors, Could you please upload the final edited documents for decision, approval, "consent", "previously intended determination" to the PictureTel site and announce through the reflector? Best regards, Sakae OKUBO *********************************************************** Waseda Research Center Telecommunications Advancement Organization of Japan (TAO) 5th Floor, Nishi-Waseda Bldg. 1-21-1 Nishi-Waseda, Shinjuku-ku, Tokyo 169-0051 Japan Tel: +81 3 5286 3830 (to be transferred) +81 3 3204 8194 (direct) Fax: +81 3 5287 7287 e-mail: okubo(a)giti.or.jp *********************************************************** ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 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.450.9Final001117 uploaded
by Klaghofer Karl ICN EN HC SE 81 23 Nov '00

23 Nov '00

H.450.9Final001117 has been uploaded to the picturetel Incoming site. It is a compound document of the two documents COM16-117 and TD22(PLEN), both approved on Nov. 17, 2000 in Geneva. It is a clean copy since the changes in TD22(PLEN) were so minor. Regards, Karl Klaghofer Siemens ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

H.248 Annex G
by Tom-PT Taylor 22 Nov '00

22 Nov '00

H.248 Annex G as decided has been uploaded to the AVC Incoming directory. I inadvertently uploaded the unzipped file H.248AnnexGDecidedwcm.doc when I meant to upload H.248AnnexGDecided.zip, which contains the document with (wcm) and without (ncm) correction marks. The latter has now also been uploaded. Tom Taylor +1 613 736 0961 taylor(a)nortelnetworks.com

1 0

H.323 Annex M.1
by Francois Audet 22 Nov '00

22 Nov '00

H.323 Annex M.1 "Q.SIG Tunnelling" has been uploaded to the APC web site as h323M1ncm.doc (no change marks) and h323M1wcm.doc (with change marks). ---- François AUDET, Nortel Networks mailto:audet@nortelnetworks.com <mailto:audet@nortelnetworks.com> , tel:+1 408 495 3756

1 0

H323 Annex R uploaded
by Terry L Anderson 22 Nov '00

22 Nov '00

I have uploaded to the incoming directory the draft of H.323 Annex R that was approved by Q.13 for determination, but due to the new ITU rules that we will no longer determine recommendations, no action was taken by SG16 plenary. This document is the same as TD-069(Plen). The plan is that Annex R will be considered for the Alternate Approval Procedures at the next SG16 meeting. The document is named: ftp://standard.pictel.com/avc-site/Incoming/h323_annex_R_intend_determined.… -- ------------------------------------------------------------ Terry L Anderson mailto:tla@lucent.com Tel:908.582.7013 Fax:908.582.6729 Pager:800.759.8352 pin 1704572 1704572(a)skytel.com Lucent Technologies/ Voice Over IP Access Networks/ Applications Grp Rm 2B-121, 600 Mountain Av, Murray Hill, NJ 07974 http://its.lucent.com/~tla (Lucent internal) http://www.gti.net/tla

1 0