- 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

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

Santa Barbara meeting: document list and reminder
by Glen Freundlich 06 Sep '01

06 Sep '01

Greetings Colleagues, We currently have 19 contributions registered for the upcoming Santa Barbara meeting (see the list below). Please remember to register your contribution by close of business on 14 September (earlier is certainly welcome and encouraged), and post the contribution to ftp://standard.pictel.com/avc-site/Incoming by close of business on 17 September. If you have not already done so, please send a note to Paul Jones (paulej(a)packetizer.com) if you plan to attend the meeting. Best Regards, Glen -------------------- This information will be available on the avc-site soon. AVD- Q Title Source 2101 2 Draft H.GEF.1 Tech-Know-Ware 2102 3 MCU Decomposition Polycom 2103 2 Circuit Information Signalling for Alternate Endpoints Cisco 2104 2 Corrections to the H.323 URL Syntax Pagoo 2105 3 Rec. H.248 package definitions ATM Forum 2106 All Concepts of Emergency Communications Service NCS 2107 F Allowable QoS Degradation NCS 2108 G Security for Emergency Communications Service NCS 2109 2, 5 H.GEF.3 (Presence in H.323 Systems) RadVision 2110 G Draft H.235 V3 Editor 2111 G Draft H.235 Annex F Editor 2112 G, 5 Draft H.235 Annex G Editor 2113 G, 2, 5 Extended H.235 error codes Siemens 2114 G Harmonization of media security Q.G Rapporteur 2115 3 Topology enhancement in H.248 Version 2 RadVision 2116 G Liaison Statement to ITU-T SG 16 regarding Mediacom 2004 and MPEG-2 ISO/IEC JTC1/SC29/WG11 2117 G Security for Emergency Communications Service Siemens AG 2118 2 Draft H.323 Annex O Editor 2119 3 H.248 Annex M.1, Advanced Audio Server Packages Editor

1 0

AVD-2116: uploaded liaison from ISO towards Q.G
by Euchner Martin 06 Sep '01

06 Sep '01

Please find contribution AVD-2116 conveying a "Liaison Statement to ITU-T SG 16 regarding Mediacom 2004 and MPEG-21" from ISO/IEC JTC1/SC29/WG11 in the Incoming directory ftp://standard.pictel.com/avc-site/Incoming/AVD-2116LSfromSC29onMedi2004.zip <ftp://standard.pictel.com/avc-site/Incoming/AVD-2116LSfromSC29onMedi2004.zip> The file will be moved to the ftp://standard.pictel.com/avc-site/0109_San/ <ftp://standard.pictel.com/avc-site/0109_San/> directory. 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@icn.siemens.de> | mailto:martin.euchner@ties.itu.int <mailto:martin.euchner@ties.itu.int> | Hofmannstr. 51 Intranet: http://intranet.icn.siemens.de/marketing/sr/pages/122/122_euchner.htm <http://intranet.icn.siemens.de/marketing/cs27/> | D-81359 Muenchen Internet: http://www.siemens.de <http://www.siemens.de> | __________________ | Germany ----------------------------------------------------------------------- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

Re: H.450.6 and Gatekeeper actions
by Callaghan, Robert 06 Sep '01

06 Sep '01

Frank, The basic model for determining busy in H.450.x features is User Determined User-Busy. That is, only the endpoint can truly determine if it is not able to handle additional calls. It is easy for an endpoint to be equipped to handle multiple call instances in a manner similar to keyset operation. In the case of H.450.6 (Call Waiting), this is a destination endpoint controlled feature. The destination endpoint is indicating that it can handle an additional call. However there will be a short delay. If the endpoint cannot handle the call, then it should indicate busy. I fail to see the logic of having the destination GK process Call Waiting. This denies the endpoint the ability to place the existing call on hold and to process the new call. >From an operational viewpoint, I fail to see how a FACILITY message can be sent from the GK to the endpoint when there is no signaling path. In that each call is independent, it is invalid to send signaling for a call on the signaling path for another call. This signaling independence is key to the handling of feature interaction between different calls. Bob -------------------------------------------------------------- Robert Callaghan Siemens Enterprise Networks 5500 Broken Sound Blvd, Boca Raton, Fl 33487 Tel: +1 561 923-1756 Fax: +1 561 923-1403 Email: Robert.Callaghan(a)ICN.Siemens.com ----------------------------------------------------------------- -----Original Message----- From: Frank Derks [mailto:frank.derks@PHILIPS.COM] Sent: Thursday, September 06, 2001 5:33 AM To: ITU-SG16(a)mailbag.cps.INTEL.COM Subject: H.450.6 and Gatekeeper actions In many of the H.450 Recommendations, the Gatekeeper (in a GK-routed model) can take on the role of one or more of the parties involved in a call and/or supplementary service. In H.450.6, however, this role is limited to the extent that the GK can only act on behalf of the served endpoint towards the calling user. What this means, is that the call to the served user must always be propagated towards the served ednpoint, to be able to _notify_ the served user about an incoming call. Since the GK (in the GK-routed) model knows that the served user is busy, it may not want to propagate the new call to the served user, but it may also want to be able to notify the served user the call. This does not seem to be possible. As a consequence of the reception of the call setup, the served endpoint may invoke some supplementary service (e.g. CFB). This may create a situation of undesired supplementary service interaction, in which both the served endpoint and the GK act on the situation. One possible way out of this situation is to allow for the served endpoint to receive the callWaiting.Invoke in a FACILITY message from the GK. This allows the GK to notify the served user about the fact that there is a call waiting and how many calls are waiting. It, however, does not provide the served endpoint with sufficient information to be able to, e.g., pickup a specific call! Maybe it would be better to introduce a new operation callWaitingNotification, that can be used towards the served user and that will include information (e.g. a list of the Calling Party number(s) and/or Alias(es)) of the calling party(s)) that the served endpoint can use to refer to such a call. Any views? Regards, Frank ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 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: Rules for sending H.450.1 APDUs
by Horvath Ernst 06 Sep '01

06 Sep '01

Frank, H.450.1 is the framework for individual supplementary service specifications. Which messages will be used for supplementary service APDUs is specified in these individual specifications, subject to the rules of H.450.1. In particular: - In the context of H.450, a Facility message needs a valid, agreed-upon call reference. - Therefore the sender of Setup shall not send a Facility message before having received a positive response message (e.g. Call Proceeding, but obviously not Release Complete since the call reference would be no longer valid). - The recipient of Setup shall not use Facility as first response message - note that supplementary service APDUs can be included in almost all other possible response messages. The last bullet applies only to H.450 standards. It does not mean that Facility could not be the first response message for other purposes! Ernst Horvath Siemens AG > -----Ursprüngliche Nachricht----- > Von: Frank Derks [mailto:frank.derks@PHILIPS.COM] > Gesendet am: Dienstag, 04. September 2001 14:28 > An: ITU-SG16(a)mailbag.cps.INTEL.COM > Betreff: Rules for sending H.450.1 APDUs > > 6.3/H.450.1 states (the third bullet item): > > "a FACILITY message shall not be sent if a SETUP message previously > sent or received has not been answered" > > It is not clear what constitutes an answer to a SETUP message. Does > this refer to any response that is the effect effect of sending or > receiving a SETUP message? E.g. a SETUP ACKNOWLEDGE or a CALL > PROCEEDING as "response" to having received a SETUP? > > Regards, > > Frank > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > 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

MSCs in H.450.5
by Frank Derks 06 Sep '01

06 Sep '01

All the MSCs in H.450.5 are identical and are copied (and unmodified) from H.450.2 (Figure 2)!!! Regards, Frank ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

H.450.6 and Gatekeeper actions
by Frank Derks 06 Sep '01

06 Sep '01

In many of the H.450 Recommendations, the Gatekeeper (in a GK-routed model) can take on the role of one or more of the parties involved in a call and/or supplementary service. In H.450.6, however, this role is limited to the extent that the GK can only act on behalf of the served endpoint towards the calling user. What this means, is that the call to the served user must always be propagated towards the served ednpoint, to be able to _notify_ the served user about an incoming call. Since the GK (in the GK-routed) model knows that the served user is busy, it may not want to propagate the new call to the served user, but it may also want to be able to notify the served user the call. This does not seem to be possible. As a consequence of the reception of the call setup, the served endpoint may invoke some supplementary service (e.g. CFB). This may create a situation of undesired supplementary service interaction, in which both the served endpoint and the GK act on the situation. One possible way out of this situation is to allow for the served endpoint to receive the callWaiting.Invoke in a FACILITY message from the GK. This allows the GK to notify the served user about the fact that there is a call waiting and how many calls are waiting. It, however, does not provide the served endpoint with sufficient information to be able to, e.g., pickup a specific call! Maybe it would be better to introduce a new operation callWaitingNotification, that can be used towards the served user and that will include information (e.g. a list of the Calling Party number(s) and/or Alias(es)) of the calling party(s)) that the served endpoint can use to refer to such a call. Any views? Regards, Frank ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

Limited Openings #2608
by Lenny Resorte 05 Sep '01

05 Sep '01

*Earn $2000 - $5000 weekly-starting within 3-12 weeks. Make what you deserve! *Own your own business. Control your destiny! *Money Freedom=Time Freedom *54% + Gross Profit Margins *No Selling *Work from home, No overhead, or employees. *Fabulous Training & Support *Not traditional MLM, many times more profitable *Multibillion Dollar Travel & Internet Industry The most incredible part of our business is that ALL MY CLIENTS ASK ME TO CALL THEM! DO YOU QUALIFY FOR OUR MENTOR PROGRAM? ACCEPTING ONLY A FEW NEW ASSOCIATES This is not a hobby! Serious Inquires Only!! Please reply with the following information NOW! FULL NAME: COMPLETE ADDRESS: EMAIL ADDRESS: PHONE: (Required; area code & number) BEST 2 TIMES TO CALL YOU: TO: mailto:55btr@verizonmail.com?subject=tell_me_more This message is sent in compliance of the new email bill section 301. Per Section 301, Paragraph (a)(2)(C) of S. 1618, further transmissions to you by the sender of this email will be stopped at no cost to you. This message is not intended for residents in the State of WA, NV, CA & VA. Screening of addresses has been done to the best of our technical ability. If you are a Washington, Virginia, or California resident please remove yourself. We respect all removal requests. //////////////////////////////////////////////////// Please remove at: mailto:rxxpp9@netscape.net?subject=remove //////////////////////////////////////////////////// ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

incomplete SDL in H.450.3 continued
by Frank Derks 05 Sep '01

05 Sep '01

There is only one SDL diagram in H.450.3 that uses divertingLegInformation4.Invoke and then only as something that is received, without specifying the message(s) in which it could be received (see a previous E-mail message). I would certainly expect at least one situation in which it is sent in the diagrams, but I can't find it. Regards, Frank ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

incomplete SDL in H.450.3
by Frank Derks 05 Sep '01

05 Sep '01

Figure 24/H,450.3 (sheet 4) does not specify in which message the divertingLegInformation4.Invoke may be received from the network. The text does not seem to be conclusive, in that it mentions that this operation may be carried in a FACILITY message or "using the call independent procedures as specified in 6.2/H.450.1". Figure 25/H.450.3 (sheet 2) does not specify in which message the divertingLegInformation3.Invoke may be received from the network. According to the text it would seem that a comment should be added, stating that the message may be FACILITY, ALERTING or CONNECT. 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

H.GEF.1 - GEF Usage
by Pete Cordell 04 Sep '01

04 Sep '01

Dear All, I've uploaded new text for H.GEF.1 - Usage guidelines for GEF - to my local server so that people have a chance to comment on it before I formally post it on the PictureTel server. The main changes are removal of the syntax method of specification and making it clear that the examples section is informative only. There have also been a number of editorial changes which should not affect the original direction of the document. It can be accessed at: http://www.tech-know-ware.com/HGEF1-Santa-Barbara.zip If you have any comments, let me know and I can sort them out before formal posting to the PictureTel site. All the best, Pete. ============================================= Pete Cordell Tech-Know-Ware pete(a)tech-know-ware.com +44 1473 635863 ============================================= ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 1

Rules for sending H.450.1 APDUs
by Frank Derks 04 Sep '01

04 Sep '01

6.3/H.450.1 states (the third bullet item): "a FACILITY message shall not be sent if a SETUP message previously sent or received has not been answered" It is not clear what constitutes an answer to a SETUP message. Does this refer to any response that is the effect effect of sending or receiving a SETUP message? E.g. a SETUP ACKNOWLEDGE or a CALL PROCEEDING as "response" to having received a SETUP? Regards, Frank ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0