July 1999 - sg16-avd - lists.packetizer.com

H283 decided document is available
by Mark Duckworth 25 Sep '99

25 Sep '99

I uploaded it to the ftp site. ftp://standard.pictel.com/avc-site/Incoming/H283_decided.zip Mark

2 1

Re: Article on H.323 Supplementary Services
by Paul Long 04 Aug '99

04 Aug '99

IEEE members (only) can access the article online at http://207.127.135.8/ci1/private/1999/jul/Korpi.html Paul Long Smith Micro Software, inc. -----Original Message----- From: Kaynam Hedayat [SMTP:Kaynam_Hedayat@PICTEL.COM] Sent: Wednesday, July 21, 1999 6:52 PM To: ITU-SG16(a)mailbag.cps.intel.com; h323implementors(a)imtc.org Subject: Article on H.323 Supplementary Services Hello everyone, I would like to bring your attention to a very good article by Vineet Kumar and Markku Korpi on H.323 Supplementary Services. The article appears in the July issue of the IEEE Communications Magazine with the title "Supplementary Services in the H.323 IP Telephony Network". Regards, Kaynam Hedayat ------------------------------------------------------------------------- for list subscription instructions, send email to h323implementors-request(a)imtc.org with text "info"

5 4

apc1641 has been uploaded to incoming
by Dale L. Skran 31 Jul '99

31 Jul '99

This document concerns interoperability between H.323 systems using G.711 and SD/CNG. It is also applicable to any other system such as H.248/MEGACOP that uses G.711 and RTP. Dale Skran

1 0

Re: H.323 Annex E optional?
by Paul Long 31 Jul '99

31 Jul '99

Paul, Let me phrase it another way. Are you saying that a v3 EP _must_ support Annex E? Even though an EP indicates that it does not support it in its RRQ, can a GK force it to use Annex E? Paul Long Smith Micro Software, Inc. -----Original Message----- From: Paul E. Jones [mailto:paul.jones@TIES.ITU.INT] Sent: Thursday, July 29, 1999 10:59 PM To: ITU-SG16(a)MAILBAG.INTEL.COM Subject: Re: H.323 Annex E optional? Paul, The endpoint does not indicate a preference-- it is to indicate capability. The gatekeeper may force an endpoint to use Annex E by setting the flag in the RCF. Paul

2 1

Re: H.323 Annex E optional?
by Manoj Paul 31 Jul '99

31 Jul '99

> Paul, > > Okay, but what if the EP does not indicate that it has this capability? > 7.9.2/H.225.0v3 currently says that the EP _shall_ use an unreliable channel > if in receipt of an RCF with useAnnexECallSignalling set to TRUE. Period. > Regardless of whether the endpoint indicated the capability in its RRQ. The > following would eliminate the ambiguity and possible misunderstanding: > > 7.9.2/H.225.0v3: "useAnnexECallSignalling - If TRUE and > supportsAnnexECallSignalling was set to TRUE in the RRQ to which this > message is in response, the endpoint receiving this message shall use call > signaling exclusively on an unreliable transport channel as described in > H.323 Annex E when placing calls." Doesn't it mean that Gk can not adopt direct call routed model between endpoints. Consider when the remote endpoint is not Annex E Compliant. Now Ep1 sends call signalling messages *only* over UDP (after receiving useAnnexECallSignalling = TRUE in RCF). This direct routed call will not go through as Ep2 is not Annex E compliant. Should Ep1 look into the callModel in ACF to figure out if it is Gk/direct routed call. If Gk routed and useAnnexECallSig = TRUE, do only UDP call signalling, and if direct routed, use Annex E Mixed TCP and UDP procedures ? -M.Paul.

2 1

FW: MegacoHGCP9 is posted
by Nancy-M Greene 30 Jul '99

30 Jul '99

fyi. -------------------------------------------------------------------------- Nancy M. Greene Internet & Service Provider Networks, Nortel Networks T:514-271-7221 (internal:ESN853-1077) E:ngreene@nortelnetworks.com > ---------- > From: Brian Rosen[SMTP:brosen@ENG.FORE.COM] > Sent: Friday, July 30, 1999 10:21 PM > To: megaco(a)standards.nortelnetworks.com > Subject: MegacoHGCP9 is posted > > I have received very few comments on Wednesday evening's > draft. MegacoHGCP9.pdf is available at: > ftp://standards.nortelnetworks.com/megaco/docs/Oslo99/MegacoHGCP9.pdf > It has the following changes: > > 1. Abdallah Rayhan and his colleagues at Nortel Networks > have been furiously putting together a real parser while I'm > merrily changing the syntax. They have provided some updates > that make the grammar consistent, error free and presumably > more regular. While the changes do in fact modify the syntax, > they should not introduce any semantic changes except as noted. > > A summary of changes are: > some spelling errors were corrected > several places where I had made commas optional were > put back to requiring commas > several places where parameters should have been optional > were fixed so that they were optional > several ABNF rule construction errors were fixed > a change was made in eventParameter to fix a syntax > ambiguity > an error where SignalsDescriptor had a RequestID was fixed > an option to return an error from Transaction was added > > 2. Time Notation is changed per Chris Ross' suggestion > > 3. Nancy Greene from Nortel Networks has updated the examples > They are believed to be reasonably consistent with the current grammar. > > 4. I have clarified wording to expressly state that a Termination can > only exist in one Context at a time. > > 5. I have clarified wording in termination Mode to state that > send/receive is with respect to the Termination. A Termination in Send > mode can only talk, it cannot listen. > > 6. Text on the local, tx and rx descriptor was replaced/reworded, and > Mode text was restored/relocated to the Local descriptor section. > > A new Internet Draft referencing this pdf has been submitted, > and will be announced in a few days. > > For those attending the SG16 Berlin meeting, there will be a hard copy > of this draft, with change bars from APC-1610 available. A zipped > version of the pdf and doc files is also on the ftp site for your > use. Please note that files with "itu" in the file name have the ITU > headers and some extra text not in the IETF version (the macros were > invoked to show ITU text). > > I thank all of the people who have contributed to this editing process. > Other than the missing text on defining packages that should be > available very soon, and the separate document with the default > packages, I feel that the document is getting very close to > last call quality. > > Any further review you would care to do would be most welcome. > Feature requests will probably be discouraged. > > Brian Rosen, Editor > ------------ > Brian Rosen, Principal Engineer > FORE Systems, 1000 FORE Drive, Warrendale, PA 15086 > (724) 742-6826 mailto:brosen@eng.fore.com >

1 0

IMTC Mobility, CoIP, iNOW! - joint session
by senthil.sengodan＠nokia.com 30 Jul '99

30 Jul '99

Folks: My apologies if you've received multiple copies of this email. Due to the synergy that the IMTC CoIP, iNOW! and Mobility groups have in the H.323 space, it is intended to have a joint session between these groups (in addition to any individual sessions) during SuperOP in September. If anyone is interested in making a presentation during this joint meeting, please let me know. In the mobility area, it is foreseen that the agenda would cover: 1) An overview of mobility efforts in other standards bodies - specifically ETSI TIPHON & ITU-T SG16. 2) A possible contribution/discussion on a mobility model based on H.323. 3) A possible discussion on the security aspects involved in mobility. If anyone would like to see any other specific area being addressed or would like to contribute to any of these areas, please let me know. - Senthil Sengodan Co-chair, IMTC Mobility AG

1 0

Address Change Assistance Required
by Matthew Sickles 30 Jul '99

30 Jul '99

Why are you getting this message? Recently Nortel Networks changed the domain name to nortelnetworks.com. As a result of this change, mailing lists are consistently sending mail to some of our older domain addresses. In an attempt to reduce the mail volume to these legacy domains, we are trying to contact the administrators for list-servers for assistance. What can you do? If you could please review your address databases and change the addresses that have the following domain names to nortelnetworks.com: nt.com nortel.com nortel.ca bnr.ca bnr.co.uk nortel.ie northern.co.uk nortel.co.uk Why should you assist us? Beginning in October we will start sending an NDR (non-delivery report) for all messages sent to older domains. In preparing ahead of time, we can prevent hundreds and thousands of messages from being sent to an incorrect address. What if you do not find any addresses in your database? Please disregard this message. If in future mailings you keep getting messages from me and you are annoyed, please contact me and we can work out these issues one-on-one. What if you find older Nortel Networks domains in your database? Thank you so much for your assistance, send me an e-mail with the list of addresses and I will forward you a Thank You Gift from Nortel Networks for your assistance. We appreciate your help and always appreciate the co-operation of postmasters, mailing-list and list-server administrators. Sincerely, Matthew W. Sickles Sr. Project Manager Nortel Networks Messaging Service _____ Matthew W. Sickles Nortel Networks 919.303.6656 [ESN] 455.6656 [voice] 919.303.8850 [ESN] 455.8850 [fax]

1 0

Re: H.323 Annex E optional?
by Paul Long 30 Jul '99

30 Jul '99

Paul, Okay, but what if the EP does not indicate that it has this capability? 7.9.2/H.225.0v3 currently says that the EP _shall_ use an unreliable channel if in receipt of an RCF with useAnnexECallSignalling set to TRUE. Period. Regardless of whether the endpoint indicated the capability in its RRQ. The following would eliminate the ambiguity and possible misunderstanding: 7.9.2/H.225.0v3: "useAnnexECallSignalling - If TRUE and supportsAnnexECallSignalling was set to TRUE in the RRQ to which this message is in response, the endpoint receiving this message shall use call signaling exclusively on an unreliable transport channel as described in H.323 Annex E when placing calls." Paul Long Smith Micro Software, Inc. -----Original Message----- From: Paul E. Jones To: ITU-SG16(a)MAILBAG.INTEL.COM Sent: 7/29/99 8:58 PM Subject: Re: H.323 Annex E optional? Paul, The endpoint does not indicate a preference-- it is to indicate capability. The gatekeeper may force an endpoint to use Annex E by setting the flag in the RCF. Paul ----- Original Message ----- From: Paul Long <Plong(a)SMITHMICRO.COM> To: <ITU-SG16(a)mailbag.cps.intel.com> Sent: Tuesday, July 27, 1999 7:53 PM Subject: H.323 Annex E optional? > Is H.323 Annex E optional? H.225.0 says that an EP can indicate in an RRQ > (and a GK, in an LCF) whether it supports H.323 Annex E (call-signaling over > an unreliable channel), so Annex E is apparently optional. For example, > > 7.9.1/H.225.0v3: "supportsAnnexECallSignalling - If TRUE, this indicates > that the sender of this message is capable of call signalling [sic] on an > unreliable transport channel as described in H.323 Annex E." > > However, H.225.0 also says that via an RCF or ACF a GK can force an EP to > use Annex E. For example, > > 7.9.2/H.225.0v3: "useAnnexECallSignalling - If TRUE, this parameter > indicates that the endpoint receiving this message shal [sic] use call > signalling [sic] exclusively on an unreliable transport channel as described > in H.323 Annex E when placing calls." > > There is nothing in the Recommendations that requires a GK to abide by the > EP's capabilities. Is this an oversight, or does the EP merely indicate in > its RRQ a preference for supporting Annex E, and it must therefore support > this Annex? >

2 1

H.323 Annex E optional?
by Paul Long 29 Jul '99

29 Jul '99

Is H.323 Annex E optional? H.225.0 says that an EP can indicate in an RRQ (and a GK, in an LCF) whether it supports H.323 Annex E (call-signaling over an unreliable channel), so Annex E is apparently optional. For example, 7.9.1/H.225.0v3: "supportsAnnexECallSignalling - If TRUE, this indicates that the sender of this message is capable of call signalling [sic] on an unreliable transport channel as described in H.323 Annex E." However, H.225.0 also says that via an RCF or ACF a GK can force an EP to use Annex E. For example, 7.9.2/H.225.0v3: "useAnnexECallSignalling - If TRUE, this parameter indicates that the endpoint receiving this message shal [sic] use call signalling [sic] exclusively on an unreliable transport channel as described in H.323 Annex E when placing calls." There is nothing in the Recommendations that requires a GK to abide by the EP's capabilities. Is this an oversight, or does the EP merely indicate in its RRQ a preference for supporting Annex E, and it must therefore support this Annex?

2 1