September 2001 - sg16-avd - lists.packetizer.com

H.341 RAS MIB issues
by Vivek Bhargava 13 Sep '01

13 Sep '01

Dear experts, I would like to resolve a problem we have discovered with indexing in the H.341 MIB. The rasRegistrationTableEntry in the rasRegistrationTable of the RAS MIB is indexed by: ifIndex, rasRegistrationCallSignalingAddressTag, rasRegistrationCallSignalingAddress, rasRegistrationSrcRasAddressTag, rasRegistrationSrcRasAddress which indicates that an endpoint is uniquely identified by its CSA and RAS addresses together. However the rasRegistrationAliasTableEntry in the rasRegistrationAliasTable in the same MIB, aliases are indexed only by a call signal address. This would mean that the MIB would merge the aliases of otherwise distinct endpoints that differ only by their RAS addresses. The same holds for other tables in the MIB, for example, rasRegistrationRasAddressTable, and the rasRegistrationCallSignallingAddressTable. Would the right thing to do would be remove the RAS address from the index of an endpoint or add it to the index of the alias and other tables? Thanks. Vivek.

1 0

Documents for Santa Barbara SG16 meeting
by Christian Groves 13 Sep '01

13 Sep '01

Hello Glen, I have placed documents AVD-2120 to AVD-2127 in the Incoming directory of the pictel site, ftp://standard.pictel.com/avc-site/0109_San/. Could you please place these in the 0109_San directory? Due to recent events in the US, Ericsson's policy is that travel to the US is restricted until further notice. So at this stage I will not be attending the SG16 meeting. My sympathy goes to colleagues who may have been involved or affected by these events. Regards, Christian ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

None
by Gary A. Thom 12 Sep '01

12 Sep '01

Glen, Please assign 3 document numbers from Delta. 1) Proposal for changes to H.246 to support service classes 2) Draft H.GEF.4 Service Class designations for H.323 Calls 3) Comments on H.QOS Service Priority Gary Gary A. Thom Delta Information Systems, Inc. 300 Welsh Road, Bldg 3 Horsham, PA 19044 USA Phone: 215-657-5270 x123 Fax: 215-657-5273 Email: gthom(a)delta-info.com www.delta-info.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

Proposed additions/modifications to H.450.6
by Frank Derks 11 Sep '01

11 Sep '01

The current version of H.450.6 is such that in a GK-routed environment, it becomes impossible for a GK to remain in control of the Call Waiting service and still be able to notify the served endpoint about the fact that there are calls waiting. The reason for this is that the Recommendation only specifies a means for the served endpoint to notify the calling users/endpoints about the fact that there call "is waiting". The served endpoint uses incoming call setups to implement the service. As a result, a GK has no choice but to propagate call setups to the served endpoint to let it know about incoming calls. This means that both the GK and the served endpoint implement Call Waiting, there will most likely be some unwanted service interaction. For this purpose I propose to make the following modifications to H.450.6: - 7.3 is split up into two parts (7.3.1 and 7.3.2). - The text that is now in 7.3 goes into 7.3.1. - The new section (7.3.2) will contain the following text: --start of new text --- "7.3.2 Call waiting notification to served user A GK/Proxy may implement the Call Waiting service. In this case, the GK/Proxy may send a cwNotification Invoke APDU to the served endpoint. The GK/Proxy shall send the cwNotification Invoke APDU in either a FACILITY message of an existing call or in a SETUP message for a new call- independent signalling connection. If a new call-independent signalling connection is initiated, it shall be established in accordance with the procedures specified in 6.2/H.450.1." --end of text--- The ASN.1 to be added is the following: ---Start of ASN.1----- cwNotification OPERATION ::= { -- Sent from GK to served endpoint ARGUMENT cwNotificationArg RETURN RESULT FALSE ALWAYS RESPONDS FALSE CODE local:xxx } cwNotificationArg ::= SEQUENCE { nbOfCalls NbOfCalls OPTIONAL, waitingCalls SEQUENCE SIZE (0..65535) OF WaitingCall, extensionArg SEQUENCE SIZE (0..255) OF MixedExtension OPTIONAL ... } WaitingCall ::= SEQUENCE { waitingNumber EndpointAddress OPTIONAL, -- if not present, waitingPosition must be present callId CallIdentifier OPTIONAL, -- to be used if waitingNumber is not present ... } NbOfCalls ::= INTEGER (0..65535) ---End of ASN.1--- Some carifications for the above ASN.1: - Since the operation defines a notification, no (return) result is required. - Because the GK/Proxy may have more than one calls waiting, a "nbOfParties" field is added. This field, when present, will contain the number of parties that the GK/Proxy has currently waiting for the served endpoint. - Since it may be possible that presentation restrictions or screening apply to a call, it is possible to only convey the callId and not the calling party's "number" to the served endpoint. - The "waitingParties" element contains a list of parties that are currently waiting. The number of calls that can be waiting is set at the same number as the maximum number of calls that can be parked according to the H.450.5 Recommendation. Regards, Frank ----------------------------------------------------- Frank Derks |Tel +31 35 6893238 | ServWare |Fax +31 35 6891030 | Philips Business Communications|P.O. Box 32 | |1200 JD Hilversum | |The Netherlands | ----------------------------------------------------| E-mail: mailto:frank.derks@philips.com | WWW: http://www.sopho.philips.com | ----------------------------------------------------- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

W.House's Hubbard says consumers "optimistic"
by union_products＠NETZERO.NET 11 Sep '01

11 Sep '01

News... Union Members Save American Jobs - Christmas domestic American made, union made products could save thousands of unionized Americans jobs... read on please! Tuesday September 11, 11:20 am Eastern Time http://altavista.com/sites/search/web?q=union+products&kl=XX W.House's Hubbard says consumers "optimistic" NEW YORK, Sept 10 (Reuters) - While consumers remained optimistic, given the sharp U.S. economic slowdown, further declines in a weak stock market could impair consumer confidence, White House economic adviser Glenn Hubbard said on Monday. ``Further declines in the stock market might impair consumer confidence,'' Hubbard said. Hubbard said a lot of consumer wealth is in real estate, which has held up well in the current downturn. ``Consumers seem very optimistic, given the current state of the economy,'' Hubbard said. Hubbard said, despite the shrinking budget surpluses due to slowing revenue from the economic slowdown and the $1.35 trillion tax cut, it was unlikely spending would have to dip into the Social Security portion of the surplus. ``I don't think we view it likely that there's going to be an on-budget deficit in (fiscal year) 2002,'' Hubbard said. The government's 2002 fiscal year begins in October. (--U.S. Financial Markets Desk, 646-223-6300) ____________________________________________________________ Save your job and buy American and support unionized American manufactures - buy union products today - http://altavista.com/sites/search/web?q=union+products&kl=XX Your itu-sg16(a)mailbag.intel.com from http://standard.pictel.com/email.htm has been chosen to receive union relevant news. Reply with 'remove' in the subject line to stop receiving monthly union friendly news wires. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

AW: Security in Inter Gatekeeper Communication
by Euchner Martin 11 Sep '01

11 Sep '01

Ivan, it is my understanding that LRQ/LCF for inter GK communication does not scale very well. Thus, H.225.0 Annex G is the more appropriate approach that should be taken. However, it is also true, that H.225.0 Annex G does not run between GKs but rather only between border elements. To be precise, an external protocol between an GK and a BE is currently undefined; better think of a co-located GK/BE entity without any in-between protocol. Regarding security, H.235 Annex G for securing H.MMS.1 mobility is being worked on and will describe also security protection of inter-BE messages similar to H.235 Annex D. To my knowledge, this is currently the only security profile that is of interest between BEs, thus there is no trial and error to be expected. As the shared secret between both BEs has to be administered anyway, so can the security profile be configured as well. Nevertheless, the security profile itself is identified through a set of OIDs. I hope this answers your questions. Kind Regards, Martin Euchner. ----------------------------------------------------------------------- | Dipl.-Inf. Phone: +49 89 722 55790 | Martin Euchner Fax : +49 89 722 46841 | Siemens AG | ICN M SR 3 mailto:Martin.Euchner@icn.siemens.de | mailto:martin.euchner@ties.itu.int | Hofmannstr. 51 Intranet: http://intranet.icn.siemens.de/marketing/sr/pages/122/122_euchner.htm | D-81359 Muenchen Internet: http://www.siemens.de | __________________ | Germany ----------------------------------------------------------------------- > -----Urspr> üngliche Nachricht----- > Von: Ivan Varghis [SMTP:ivancse@YAHOO.COM] > Gesendet am: Samstag, 8. September 2001 14:09 > An: ITU-SG16(a)mailbag.cps.INTEL.COM > Betreff: Security in Inter Gatekeeper Communication > > Hi > > For security in inter Gatekeeper conmmunication, > currently there is no authentication capabltiy > exchange for selection of a common security profile. > This facility is provided in the case of communication > between the Endpoint and Gatekeeper using the GRQ GCF > exchange. > > The field used for this are > AuthenticationCapabilty and AlgorithmOIDs in GRQ > ( Capabilities of the EP) > and > AuthenticationMode and AlgorithmOID in GCF > ( The capabiltiy selected by Gatekeeper) > > Wouldnt it be good to add the " same fields in the LRQ > and LCF" as his would help in selection of a common > profile between Gatekeepers. > > Though the profile which is used can be determined > from the TokenIOD and AlgorithmOID in the message, as > the number of security profiles increases the > Gatekeepers will have to use a trial and error method > to arrive at a common security Profile. Wouldnt this > be a overhead which can be avoided ? > > Cheers H.323 > Ivan > > > __________________________________________________ > Do You Yahoo!? > Get email alerts & NEW webcam video instant messaging with Yahoo! Messenger > http://im.yahoo.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

2 1

Security in Inter Gatekeeper Communication
by Ivan Varghis 08 Sep '01

08 Sep '01

Hi For security in inter Gatekeeper conmmunication, currently there is no authentication capabltiy exchange for selection of a common security profile. This facility is provided in the case of communication between the Endpoint and Gatekeeper using the GRQ GCF exchange. The field used for this are AuthenticationCapabilty and AlgorithmOIDs in GRQ ( Capabilities of the EP) and AuthenticationMode and AlgorithmOID in GCF ( The capabiltiy selected by Gatekeeper) Wouldnt it be good to add the " same fields in the LRQ and LCF" as his would help in selection of a common profile between Gatekeepers. Though the profile which is used can be determined from the TokenIOD and AlgorithmOID in the message, as the number of security profiles increases the Gatekeepers will have to use a trial and error method to arrive at a common security Profile. Wouldnt this be a overhead which can be avoided ? Cheers H.323 Ivan __________________________________________________ Do You Yahoo!? Get email alerts & NEW webcam video instant messaging with Yahoo! Messenger http://im.yahoo.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

subscribe
by Haotian zhang 07 Sep '01

07 Sep '01

__________________________________________________ Do You Yahoo!? Get email alerts & NEW webcam video instant messaging with Yahoo! Messenger http://im.yahoo.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

subscribe
by Henkel, Friedhelm 07 Sep '01

07 Sep '01

======================================================== Dipl.-Ing. Friedhelm Henkel, E23g Junior Research and Development Expert Next Generation Service Platforms and Architectures Business Unit Technologiezentrum Am Kavalleriesand 3 64295 Darmstadt, Germany P.O.Box: 64307 Darmstadt Phone: +49 6151/ 83 - 4089 Fax: +49 6151/ 83 - 4590 Internet: http://www.t-nova.de, http://www.t-systems.de ======================================================== ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

FW: [sip-h323]
by Tom-PT Taylor 06 Sep '01

06 Sep '01

I expect this should really go to the H.323 Implementors list, but maybe some people out there want to answer James. -----Original Message----- From: Yu, James [mailto:james.yu@neustar.com] Sent: Thursday, September 06, 2001 2:29 PM To: 'sip-h323(a)yahoogroups.com' Subject: RE: [sip-h323] Charles, Cisco has a proposal to support number portability for H.323. My question on H.323 is "who, the GK or GW, will do the NP queries? I guess that either one can do it but just want to know in the real world who will be doing that. James -----Original Message----- From: Agboh, Charles [mailto:charles.agboh@ebone.com] Sent: Tuesday, July 31, 2001 6:17 PM To: 'sip-h323(a)yahoogroups.com' Subject: RE: [sip-h323] Hi Ranjit, I believe TRIP will close that gap (contact details and thier expiration/keepalive). Regards, Charles -----Original Message----- From: Ranjit Kumar Avasarala [mailto:ranjitka@email.masconit.com] Sent: Wednesday, August 01, 2001 12:02 AM To: sip-h323(a)yahoogroups.com Subject: RE: [sip-h323] Hi Charles, But RFC 2543 does not mandate processing of Expires header. What is says is time duration mentioned in Expire header field can be used as upper limit For the user to respond. So since it is optional it depends on the SIP Proxy / Registrar implementation. I was thinking of the case Where it is not implemented. Regards Ranjit Mascon Communication Technologies http://www.masconit.com Ph: 847-240-2444 -----Original Message----- From: Agboh, Charles [mailto:charles.agboh@ebone.com] Sent: Tuesday, July 31, 2001 4:42 PM To: 'sip-h323(a)yahoogroups.com' Subject: RE: [sip-h323] Hi, Ranjit; You may have looked at this but, the Expires header and optional "expires" Contact parameter is just for that (Expires t; where t is time in seconds (i.e. 0)). See Section 4.2.6 of http://www.cs.columbia.edu/sip/drafts/draft-ietf-sip-rfc2543bis-02.pdf for details. Also see section 7.4 of http://www.cs.columbia.edu/sip/drafts/draft-ietf-sip-rfc2543bis-03.pdf. I hope this helps. Regards, Charles > -----Original Message----- > From: Roy, Radhika R, ALCTA [mailto:rrroy@att.com] > Sent: Tuesday, July 31, 2001 11:19 PM > To: sip-h323(a)yahoogroups.com > Subject: RE: [sip-h323] > > > Hi, Ranjit: > > Yes, it is an issue (especially for the IWF where it will be > working on > behalf of many users). > > Our work is to limit ourselves within the context of RFC 2543. > > However, if there are any good proposals, we can make > suggestion to the SIP > WG for the future improvement. > > Alternatively, we can also work for some best current practices or > experimental documents separately based on our collectives experiences > (e.g., your suggestions for solving some of the problems for the IWF). > > Let us collect all the issues and, please provide more > comments like this. > > Best regards, > Radhika > > -----Original Message----- > From: Ranjit Kumar Avasarala [mailto:ranjitka@email.masconit.com] > Sent: Tuesday, July 31, 2001 5:15 PM > To: sip-h323(a)yahoogroups.com > Subject: RE: [sip-h323] > > > > Hi Radhika, > > Ya I am talking of SIP side. > > In SIP there is no mechanism for the registrar to indicate to > user agents > that their registration has expired. > So it should be either responsibility of UA to periodically > monitor its > registration status or registrar should > Notify the UA about its registration status. > > I feel this could be a problem if IWF behaving like SIP UA > and registers > with SIP registrar using > REGISTER method > > Thanks > > Ranjit > -----Original Message----- > From: Roy, Radhika R, ALCTA [ mailto:rrroy@att.com > <mailto:rrroy@att.com> > ] > Sent: Tuesday, July 31, 2001 3:48 PM > To: sip-h323(a)yahoogroups.com > Subject: RE: [sip-h323] > > Hi, Ranjit: > > IWF will have its two sides: SIP (UA) and H.323. > > Now for the SIP side, it will behave like a SIP UA and, its > relationship > with the SIP REGISTER will be in accordance to RFC 2543. So, > some of the > behaviors that you are describing may be applicable in this context. > > Best regards, > Radhika > > -----Original Message----- > From: Ranjit Kumar Avasarala [ mailto:ranjitka@email.masconit.com > <mailto:ranjitka@email.masconit.com> ] > Sent: Tuesday, July 31, 2001 4:43 PM > To: sip-h323(a)yahoogroups.com > Subject: [sip-h323] > > > > Hi > > Say IWF is registered with Sip registrar in SIP network > and with GK in > the H323 zone. > > > > Say the registration has expired after some time. Now > registrar has no means > > of notifying IWF that its registration has expired. > > So I feel IWF should periodically monitor if its registration > is active or > the Registrar should send CANCEL message SIP > > Messages from IWF. Then IWF will come to know that its > registration has > expired and will re register. > > > > Regards > > Ranjit > > > > > > Yahoo! Groups Sponsor > > < > http://rd.yahoo.com/M=210948.1523299.3088501.1269402/D=egroupw > eb/S=17050047 > <http://rd.yahoo.com/M=210948.1523299.3088501.1269402/D=egroup > web/S=17050047 > > > 26:HM/A=733441/R=0/* > http://altfarm.mediaplex.com/ad/ck/1177-3936-1039-2?mpt= > <http://altfarm.mediaplex.com/ad/ck/1177-3936-1039-2?mpt=> > 996611651> > > < > http://us.adserver.yahoo.com/l?M=210948.1523299.3088501.126940 2/D=egroupmai > <http://us.adserver.yahoo.com/l?M=210948.1523299.3088501.12694 02/D=egroupmai > > > l/S=1705004726:HM/A=733441/rand=317565678> > > To Post a message, send it to: sip-h323(a)eGroups.com > > To Unsubscribe, send a blank message to: > sip-h323-unsubscribe(a)eGroups.com > > Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service > < http://docs.yahoo.com/info/terms/ <http://docs.yahoo.com/info/terms/> > . ------------------------ Yahoo! Groups Sponsor ---------------------~--> Small business owners... Tell us what you think! http://us.click.yahoo.com/vO1FAB/txzCAA/ySSFAA/26EolB/TM <http://us.click.yahoo.com/vO1FAB/txzCAA/ySSFAA/26EolB/TM> ---------------------------------------------------------------------~-> To Post a message, send it to: sip-h323(a)eGroups.com To Unsubscribe, send a blank message to: sip-h323-unsubscribe(a)eGroups.com Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/ <http://docs.yahoo.com/info/terms/> Yahoo! Groups Sponsor <http://rd.yahoo.com/M=210948.1523299.3088501.1269402/D=egroupweb/S=17050047 26:HM/A=733441/R=0/*http://altfarm.mediaplex.com/ad/ck/1177-3936-1039-2?mpt= 996613626> <http://us.adserver.yahoo.com/l?M=210948.1523299.3088501.1269402/D=egroupmai l/S=1705004726:HM/A=733441/rand=622034757> To Post a message, send it to: sip-h323(a)eGroups.com To Unsubscribe, send a blank message to: sip-h323-unsubscribe(a)eGroups.com Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service <http://docs.yahoo.com/info/terms/> . To Post a message, send it to: sip-h323(a)eGroups.com To Unsubscribe, send a blank message to: sip-h323-unsubscribe(a)eGroups.com Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/ ------------------------ Yahoo! Groups Sponsor ---------------------~--> Small business owners... Tell us what you think! http://us.click.yahoo.com/vO1FAB/txzCAA/ySSFAA/26EolB/TM ---------------------------------------------------------------------~-> To Post a message, send it to: sip-h323(a)eGroups.com To Unsubscribe, send a blank message to: sip-h323-unsubscribe(a)eGroups.com Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/ To Post a message, send it to: sip-h323(a)eGroups.com To Unsubscribe, send a blank message to: sip-h323-unsubscribe(a)eGroups.com Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service. To Post a message, send it to: sip-h323(a)eGroups.com To Unsubscribe, send a blank message to: sip-h323-unsubscribe(a)eGroups.com Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service. Yahoo! Groups Sponsor ADVERTISEMENT You can, too! Start here... Height: 345678 ft 01234567891011in Weight: lbs. kg. To Post a message, send it to: sip-h323(a)eGroups.com To Unsubscribe, send a blank message to: sip-h323-unsubscribe(a)eGroups.com Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

2 1