- sg16-avd - lists.packetizer.com

FW: Protocol Action: Telephony Routing over IP (TRIP) to Proposed Standard
by Tom-PT Taylor 13 Sep '01

13 Sep '01

FYI: TRIP formally approved. -----Original Message----- From: The IESG [mailto:iesg-secretary@ietf.org] Sent: Thursday, September 13, 2001 1:11 PM To: IETF-Announce Cc: RFC Editor; Internet Architecture Board; iptel(a)lists.bell-labs.com Subject: Protocol Action: Telephony Routing over IP (TRIP) to Proposed Standard The IESG has approved the Internet-Draft 'Telephony Routing over IP (TRIP)' <draft-ietf-iptel-trip-09.txt> as a Proposed Standard. This document is the product of the IP Telephony Working Group. The IESG contact persons are Allison Mankin and Scott Bradner. Technical Summary This document presents the Telephony Routing over IP (TRIP). TRIP is a policy driven inter-administrative domain protocol for advertising the reachability of telephony destinations between location servers, and for advertising attributes of the routes to those destinations. TRIP's operation is independent of any signaling protocol, hence TRIP can serve as the telephony routing protocol for any signaling protocol. TRIP is modeled after the Border Gateway Protocol 4 (BGP-4) and enhanced with some link state features as in the Open Shortest Path First (OSPF) protocol, IS-IS, and the Server Cache Synchronization Protocol (SCSP). TRIP uses BGP's inter-domain transport mechanism, BGP's peer communication, BGP's finite state machine, and similar formats and attributes as BGP. Unlike BGP however, TRIP permits generic intra-domain LS topologies, which simplifies configuration and increases scalability in contrast to BGP's full mesh requirement of internal BGP speakers. TRIP uses an intra-domain flooding mechanism similar to that used in OSPF, IS-IS, and SCSP. Working Group Summary The working group supports this protocol, no significant issues were raised during IETF Last-Call. Protocol Quality This document was reviewed for the IESG by Scott Bradner ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

Re: H323 Annex E over UDP and TPKT header
by Sasha Ruditsky 13 Sep '01

13 Sep '01

Hi Vivek The only function of TPKT is to define message boundaries. Annex E has own mechanisms to do this. So basically I think that should be no TPKT header in the Q.931 messages when used with Annex E. Sasha -----Original Message----- From: Vivek Kakkar [mailto:vkakkar@CISCO.COM] Sent: Thursday, September 13, 2001 11:19 AM To: ITU-SG16(a)MAILBAG.INTEL.COM Subject: H323 Annex E over UDP and TPKT header Hello, I wanted to poll the H323 community regarding the use of TPKT header with H225 message while using AnnexE transport capability. AnnexE makes the UDP a reliable signaling channel. H.323 spec talks of using TPKT header with reliable signaling channel. What is your interpretation of H323/AnnexE regarding the TPKT header? Does the TPKT header have a function in this case? thanks, -- vivek ============================================================= Vivek Kakkar Cisco Systems, Inc. vkakkar(a)cisco.com Research Triangle Park, NC 919-392-6975:o USA

1 0

H323 Annex E over UDP and TPKT header
by Vivek Kakkar 13 Sep '01

13 Sep '01

Hello, I wanted to poll the H323 community regarding the use of TPKT header with H225 message while using AnnexE transport capability. AnnexE makes the UDP a reliable signaling channel. H.323 spec talks of using TPKT header with reliable signaling channel. What is your interpretation of H323/AnnexE regarding the TPKT header? Does the TPKT header have a function in this case? thanks, -- vivek ============================================================= Vivek Kakkar Cisco Systems, Inc. vkakkar(a)cisco.com Research Triangle Park, NC 919-392-6975:o USA

1 0

Re: Documents for Santa Barbara SG16 meeting
by Sebestyen Istvan ICN M SR 3 13 Sep '01

13 Sep '01

Dear all, first of all I would like to join Christian in his condolances especially to the victims' families, but also to all American colleagues for this terrible act. Though physically a US location was hit, but that is an essential part of our global village, so we have been equally hit. At the same time, I think we have to work out some sort of emergency plans. In addition to restrictions imposed by companies such as reported by Ericsson, I personally do not expect, but it might be that flights to the US remain impossible for some time as the airspace and airports might remain closed, plus stranded people have to be brought home first, so by what time do we have to make a final decision to go ahead with the meeting, or to postpone, or to cancel it entirely? Next Wednesday, or so? Regards, Istvan Sebestyen -------------------------------------------------------------------------- Dr. Istvan Sebestyen Siemens AG, ICN M SR 3, Hofmannstr. 51, D-81359 Munich, Germany Tel:+49-89-722-47230 Fax:+49-89-722-47713 E-Mail office: istvan.sebestyen(a)icn.siemens.de; istvan(a)sebestyen.de E-mail private: istvan_sebestyen(a)yahoo.com; Siemens Intranet:http://intranet.icn.siemens.de/marketing/cs27/ Siemens FTP: ftp://mchhpn006a.mch.pn.siemens.de/ ---------------------------------------------------------------------------- ---------------- > ---------- > From: Christian Groves[SMTP:Christian.Groves@ERICSSON.COM.AU] > Reply To: Christian Groves > Sent: Thursday, September 13, 2001 3:35 AM > To: ITU-SG16(a)mailbag.cps.INTEL.COM > Subject: Documents for Santa Barbara SG16 meeting > > 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 > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

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

12 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 12 Sep '01

12 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