- sg16-avd - lists.packetizer.com

Re: [sip-h323] SIP-H.323 interworking Requirements Draft
by Roy, Radhika R, ALCOO 29 Aug '00

29 Aug '00

Hi, Paul: I understand your points, and we also believe that we should work for version 3, but it would be nice if we could finish for version 2 first. Presently, my company (AT&T), like many other companies, has also difficulties to get version 3 implemented because of problems as stated earlier. However, we all realize that version 3 is needed and will be working for version 3 immediately as soon as we finish our work for version 2. I also like to point out that we are working for the informational RFCs and hope that we can produce the interworking spec for version 3 very quickly once we finish the same for version 2. My guess is that version 3 needs some incremental changes from those of version 2. So, I think that the work for version 3 can be completed quickly. Hope that this will answer your questions. Best regards, Radhika R. Roy AT&T -----Original Message----- From: Paul E. Jones [mailto:paulej@packetizer.com] Sent: Monday, August 28, 2000 11:53 PM To: Roy, Radhika R, ALCOO; sip-h323(a)egroups.com; ITU-SG16(a)mailbag.cps.intel.com Subject: Re: [sip-h323] SIP-H.323 interworking Requirements Draft Radhika, A few months ago, I published the final set of ASN.1 corrections for H.323v3 to the ITU-T SG16 mailing list and to the IMTC H.323 mailing list. I also contact 11 companies that have H.323v3 products or products in development that I was aware of. There are certainly plenty of v3 implementations in progress and it's important to be prepared for those implementations. H.323v4 will be approved in November and I expect even quicker adoption of that Recommendation, because it introduces a lot of new functionality. I think what the group should try to strive for is a specification that will work with the most recent version of H.323-- H.323v4. Of course there will be few implementations, but there are not a large number of new mandatory features. (I don't have a list handy.) For a "bigger picture" view of what's new in the various versions of H.323, see: http://www.packetizer.com/iptel/h323/ Best Regards, Paul ----- Original Message ----- From: "Roy, Radhika R, ALCOO" <rrroy(a)att.com> To: "Roy, Radhika R, ALCOO" <rrroy(a)att.com>; <sip-h323(a)egroups.com> Sent: Monday, August 28, 2000 10:32 PM Subject: RE: [sip-h323] SIP-H.323 interworking Requirements Draft > Hi, Everyone: > > Here is my view as stated below: > > It is very difficult to find any vendor to support H.323 version 3. Many > companies are now testing vendor implementations of H.323 version 2, and it > is also reported that multivendor interoperability at the version 2 level is > still problematic. In many cases, no promise has been obtained from the > major vendors when they will support version 3. It may be very nice to have > SIP/H.323 v3 interworking, but we think SIP/H.323 v2 interworking should > come first. > > Considering all factors, I think that we should keep our first interworking > requirements to support H.323 version 2 as defined in the present draft > (while we may consider for H.323 version 3 in the future). > > So, I recommend that we should make any changes in the present draft. > > Best regards, > Radhika R. Roy > AT&T > +11 732 420 1580 > > -----Original Message----- > From: Roy, Radhika R, ALCOO [mailto:rrroy@att.com] > Sent: Sunday, August 27, 2000 10:32 PM > To: sip-h323(a)egroups.com > Subject: [sip-h323] SIP-H.323 interworking Requirements Draft > > > Hi, Everyone: > > I have just returned from the ITU-T SG16 Q.13 (H.323) meeting where our > SIP-H.323 Interworking requirement draft was also discussed. > > The Q.13 members have strongly recommended that we should consider H.323 > version 3 (instead of version 2) for our SIP-H.323 interworking work. > > We would appreciate if you would kindly provide your comments on the point. > > Best regards, > Radhika R. Roy > AT&T > +1 732 420 1580 > rrroy(a)att.com > > > 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 > > > 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 > > -------------------------- eGroups Sponsor -------------------------~-~> > GET A NEXTCARD VISA, in 30 seconds! Get rates > of 2.9% Intro or 9.9% Ongoing APR* and no annual fee! > Apply NOW! > http://click.egroups.com/1/7872/7/_/302437/_/967516325/ > ---------------------------------------------------------------------_-> > > 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 > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

Re: [sip-h323] SIP-H.323 interworking Requirements Draft
by Paul E. Jones 28 Aug '00

28 Aug '00

Radhika, A few months ago, I published the final set of ASN.1 corrections for H.323v3 to the ITU-T SG16 mailing list and to the IMTC H.323 mailing list. I also contact 11 companies that have H.323v3 products or products in development that I was aware of. There are certainly plenty of v3 implementations in progress and it's important to be prepared for those implementations. H.323v4 will be approved in November and I expect even quicker adoption of that Recommendation, because it introduces a lot of new functionality. I think what the group should try to strive for is a specification that will work with the most recent version of H.323-- H.323v4. Of course there will be few implementations, but there are not a large number of new mandatory features. (I don't have a list handy.) For a "bigger picture" view of what's new in the various versions of H.323, see: http://www.packetizer.com/iptel/h323/ Best Regards, Paul ----- Original Message ----- From: "Roy, Radhika R, ALCOO" <rrroy(a)att.com> To: "Roy, Radhika R, ALCOO" <rrroy(a)att.com>; <sip-h323(a)egroups.com> Sent: Monday, August 28, 2000 10:32 PM Subject: RE: [sip-h323] SIP-H.323 interworking Requirements Draft > Hi, Everyone: > > Here is my view as stated below: > > It is very difficult to find any vendor to support H.323 version 3. Many > companies are now testing vendor implementations of H.323 version 2, and it > is also reported that multivendor interoperability at the version 2 level is > still problematic. In many cases, no promise has been obtained from the > major vendors when they will support version 3. It may be very nice to have > SIP/H.323 v3 interworking, but we think SIP/H.323 v2 interworking should > come first. > > Considering all factors, I think that we should keep our first interworking > requirements to support H.323 version 2 as defined in the present draft > (while we may consider for H.323 version 3 in the future). > > So, I recommend that we should make any changes in the present draft. > > Best regards, > Radhika R. Roy > AT&T > +11 732 420 1580 > > -----Original Message----- > From: Roy, Radhika R, ALCOO [mailto:rrroy@att.com] > Sent: Sunday, August 27, 2000 10:32 PM > To: sip-h323(a)egroups.com > Subject: [sip-h323] SIP-H.323 interworking Requirements Draft > > > Hi, Everyone: > > I have just returned from the ITU-T SG16 Q.13 (H.323) meeting where our > SIP-H.323 Interworking requirement draft was also discussed. > > The Q.13 members have strongly recommended that we should consider H.323 > version 3 (instead of version 2) for our SIP-H.323 interworking work. > > We would appreciate if you would kindly provide your comments on the point. > > Best regards, > Radhika R. Roy > AT&T > +1 732 420 1580 > rrroy(a)att.com > > > 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 > > > 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 > > -------------------------- eGroups Sponsor -------------------------~-~> > GET A NEXTCARD VISA, in 30 seconds! Get rates > of 2.9% Intro or 9.9% Ongoing APR* and no annual fee! > Apply NOW! > http://click.egroups.com/1/7872/7/_/302437/_/967516325/ > ---------------------------------------------------------------------_-> > > 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 > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

FW: [sip-h323] SIP-H.323 interworking Requirements Draft
by Roy, Radhika R, ALCOO 28 Aug '00

28 Aug '00

FYI -----Original Message----- From: Roy, Radhika R, ALCOO Sent: Monday, August 28, 2000 10:41 PM To: 'sip-h323(a)egroups.com'; sip-h323(a)egroups.com Subject: RE: [sip-h323] SIP-H.323 interworking Requirements Draft Hi, Henning: I agree with you (please also see my response provided below). Best regards, Radhika R. Roy -----Original Message----- From: Henning Schulzrinne [mailto:schulzrinne@cs.columbia.edu] Sent: Monday, August 28, 2000 12:12 PM To: sip-h323(a)egroups.com Subject: Re: [sip-h323] SIP-H.323 interworking Requirements Draft "Roy, Radhika R, ALCOO" wrote: > > Hi, Everyone: > > I have just returned from the ITU-T SG16 Q.13 (H.323) meeting where our > SIP-H.323 Interworking requirement draft was also discussed. > > The Q.13 members have strongly recommended that we should consider H.323 > version 3 (instead of version 2) for our SIP-H.323 interworking work. What practical difference does it make? Could you summarize the relevant differences? Presumably, a v3 terminal is going to interoperate with v2 terminals. For the next year, at the very least, the only real implementation to worry about is NetMeeting (v2, I assume). -----Original Message----- From: Roy, Radhika R, ALCOO Sent: Monday, August 28, 2000 10:32 PM To: Roy, Radhika R, ALCOO; sip-h323(a)egroups.com Subject: RE: [sip-h323] SIP-H.323 interworking Requirements Draft Hi, Everyone: Here is my view as stated below: It is very difficult to find any vendor to support H.323 version 3. Many companies are now testing vendor implementations of H.323 version 2, and it is also reported that multivendor interoperability at the version 2 level is still problematic. In many cases, no promise has been obtained from the major vendors when they will support version 3. It may be very nice to have SIP/H.323 v3 interworking, but we think SIP/H.323 v2 interworking should come first. Considering all factors, I think that we should keep our first interworking requirements to support H.323 version 2 as defined in the present draft (while we may consider for H.323 version 3 in the future). So, I recommend that we should make any changes in the present draft. Best regards, Radhika R. Roy AT&T +11 732 420 1580 -----Original Message----- From: Roy, Radhika R, ALCOO [mailto:rrroy@att.com] Sent: Sunday, August 27, 2000 10:32 PM To: sip-h323(a)egroups.com Subject: [sip-h323] SIP-H.323 interworking Requirements Draft Hi, Everyone: I have just returned from the ITU-T SG16 Q.13 (H.323) meeting where our SIP-H.323 Interworking requirement draft was also discussed. The Q.13 members have strongly recommended that we should consider H.323 version 3 (instead of version 2) for our SIP-H.323 interworking work. We would appreciate if you would kindly provide your comments on the point. Best regards, Radhika R. Roy AT&T +1 732 420 1580 rrroy(a)att.com 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 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

IP Telecom Services Workshop 2000: Final Call for Participation
by Gregory W. Bond 28 Aug '00

28 Aug '00

[Please accept our apologies for multiple copies of this call.] ------------- FINAL CALL FOR PARTICIPATION --------------- IP TELECOM SERVICES WORKSHOP 2000 (IPTS 2000) co-located with Fall 2000 Voice on the Net (VON) organized by AT&T Labs Research pulver.com Cobb Galleria, Atlanta, Georgia, U.S.A September 11, 2000 http://www.research.att.com/conf/ipts2000/ ----------------------------------------------------------- IPTS 2000 is a new workshop dedicated to the important, emerging field of IP Telecom Services research. In contrast to the services available on the PSTN, a new world of telecom services is possible on an IP-based infrastructure. This world presents new challenges for service development, deployment and management. This one-day workshop will serve as a forum for the dissemination of research relating to these challenges. We have put together an excellent technical program that includes 7 original research papers, two distinguished invited speakers, and a round table discussion. We look forward to the participation from you and your colleagues in the telecom industry and the research community. Registration is now open at http://pulver.com/ipts2000/register.html. TECHNICAL PROGRAM Keynote Speaker - Eric Sumner President and CEO of dynamicsoft "The End of Telephony" Invited Speaker - Joe Rinde AT&T Labs "Why Service? What Services?" DFC as the basis for ECLIPSE, an IP communications software platform Greg Bond, Eric Cheung, Andrew Forrest, Michael Jackson, Hal Purdy, Chris Ramming, and Pamela Zave AT&T Labs Research Experimenting with PARLAY in a SIP Environment: Early Results Stephane Desrochers, Roch H. Glitho, Kindy Sylla Ericsson Research Canada Approach For Services in Converged Networks Sanjiv Kapur, Rakesh Vij Hughes Software Systems Unified Messaging using SIP and RTSP Kundan Singh and Henning Schulzrinne Columbia University SPHINX: A Study in Convergent Telephony and Advanced Scenarios for H.323-SIP Interoperation Kumar V. Vemuri Lucent Technologies Where Should Services Reside in Internet Telephony Systems? Xiaotao Wu and Henning Schulzrinne Columbia University A Transformation Approach for Service Creation in a Hybrid IP-IN Network Cyril Carrez, Elie Najm, Alexandre Tauveron Ecole Nationale Superieure des Telecom Roundtable Discussion - topic to be announced REGISTRATION IPTS 2000 will be held on September 11, 2000 in Atlanta, Georgia. The workshop will be co-located with Fall 2000 Voice on the Net (VON). Registration details for IPTS 2000 can be found at http://www.research.att.com/conf/ipts2000. Hotel information can be found at http://www.pulver.com/von/hotel.html. Registration for IPTS 2000 does not include registration for Fall 2000 VON. Registration details for Fall 2000 VON can be found at http://pulver.com/von. IPTS 2000 is organized by AT&T Labs Research (http://www.research.att.com) and pulver.com (http://pulver.com). WORKSHOP CO-CHAIRS Greg Bond, AT&T Labs Research Eric Cheung, AT&T Labs Research PROGRAM COMMITTEE Mauricio Arango, Sun Microsystems Labs Joanne Atlee, University of Waterloo Ralph Blumenthal, Daewoo Telecom Scott Hoffpauir, BroadSoft Evan Magill, University of Strathclyde Peter Mataga, dynamicsoft Bernie Pagurek, Carleton University Jonathan Rosenberg, dynamicsoft Henning Schulzrinne, Columbia University Greg Utas, Nortel Networks Pamela Zave, AT&T Labs Research FURTHER GENERAL INFORMATION http://www.research.att.com/conf/ipts2000 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

Open Letter To Dale Skran
by Tom-PT Taylor 26 Aug '00

26 Aug '00

At the meeting just concluded, you described and criticized a contribution to 3GPP2, naming Nortel Networks as the contributor. In the process, you managed to imply that Nortel was less than competent, that 3GPP2 was gullible, and that no other company provided a contribution favouring the eventual 3GPP2 decision. I have to assume that in doing so you felt it your duty as Q.13/16 Rapporteur to publicly admonish a major company that supports the use of H.323 only in the enterprise environment. Any other interpretation of your motives would imply immediately that you had abused your position as Rapporteur on behalf of your employer or for personal reasons. However, I would argue that even with the stated motive, your actions were improper within the context of an ITU-T meeting. The ITU-T (unlike many private fora) is neither a marketing organization nor a religious exercise. In our respective domains, both Francois Audet and I have made significant contributions to the work of Study Group 16 on behalf of our employer. You have performed your work as Rapporteur with great skill, and we all appreciate it. This does not give you the right to use your position as a pulpit to denounce sinners. I would hope that on reflection you agree and are prepared to say so publicly. Tom Taylor Nortel Networks

1 0

Quick report of the Portland meeting
by Sakae OKUBO 26 Aug '00

26 Aug '00

<x-html><!x-stuff-for-pete id="0"> <!doctype html public "-//W3C//DTD W3 HTML//EN"> <html><head><style type="text/css"></style><title>Quick report of the Portland meeting</title></head><body> <div>Dear Q12-14/16 experts,</div> <div><br></div> <div>A quick report of the Portland meeting is uploaded at the following place:</div> <div><br></div> <div><font size="+1" color="#000000">  http://standard.pictel.com/ftp/avc-site/Incoming/Portland_quick<span ></span>_report.zip</font></div> <div><font size="+1" color="#000000"><br></font></div> <div>It contains TD-34b (general), TD-36a (Q13) and TD-37b (Q14) and will be integrated into APC-1949 with other materials.</div> <div><br></div> <div>Best regards,<br> <br> Sakae OKUBO<br> *****************************************<span ></span>******************<br> Waseda Research Center<br> Telecommunications Advancement Organization of Japan (TAO)<br> 5th Floor, Nishi-Waseda Bldg.<br> 1-21-1 Nishi-Waseda, Shinjuku-ku, Tokyo<br> 169-0051 Japan<br>       Tel: +81 3 5286 3830 (to be transferred)<br>            +81 3 3204 8194 (direct)<br>       Fax: +81 3 5287 7287<br>       e-mail: okubo(a)giti.or.jp<br> *****************************************<span ></span>******************</div> </body> </html> </x-html> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

draft-ietf-megaco-ipphone-03.txt
by Tom-PT Taylor 25 Aug '00

25 Aug '00

As indicated in the quotation below, the latest version of the IPPhone profile has been sent to the IETF. If you can't wait for it to be posted, please send an E-mail to Peter Blatherwick asking for a copy. When it appears, I offer it for WG Last Call, with a view to publishing it as an Informational RFC. Tom Taylor -----Original Message----- From: Blatherwick, Peter [CAR:AT14:EXCH] Sent: Friday, August 25, 2000 12:29 To: 'internet-drafts(a)ietf.org' Cc: 'Bob Bell (Cisco)'; 'Phil Holland (Circa)' Subject: I-D Submission: Megaco IP Phone MG 03 Greetings: Please find I-D submission, "draft-ietf-megaco-ipphone-03.txt", for Megaco WG, attached. This replaces the previous submission of the same name (draft-ietf-megaco-ipphone-02.txt). Please copy announcement to Megaco mailing list (megaco(a)standards.nortelnetworks.com) when posted. Thanks, and have a great day, Peter Blatherwick 613-763-7539 blather(a)nortelnetworks.com << File: draft-ietf-megaco-ipphone-03.txt >>

1 0

Support of Values in Packages
by Christian Groves 24 Aug '00

24 Aug '00

G'Day all, There has been some confusion at the SG16 on what is supported in Packages. The understanding that I had was that: If you support a package you must support all the signals, properties, events and statistics. However you do not have to support all the values associated with the properties and parameters. Tom mentioned that a thread discussed on the list contravened this. The reasoning that I have for not having to support all the values is the following: o Proliferation of packages. Eg: if a package has a list of tones, and I must support all the values, if I only want to support a subset of these values then I need a new package. Therefore you may get the case of a package "Package Call Progress Tones E.7" where an MG doesn't support Payphone Recognition Tone because it doesn't have payphones connected to it. To be compliant with H.248 I can't extend the package because I want to remove the payphone tone. So a new Package needs to be defined containing exactly the same information but without the payphone tone. Now my MG won't support the standard Call Progress Tone package but will support the XXX_companies_Call_Progress_Tone package. This would lead to a proliferation of packages. o Multiple GW support - One MG may not implement all the values of a property. For something like a list of codecs, a group of resources associated with the value may be placed in different MG GWs. ie. GSM codecs in MG1, PCM codecs in MG2. So whilst the MGs support the same package properties, they can't support a subset of values then you'd need to define a different package for each MG configuration. Again leading to a proliferation of packages. o The MGC knows the PackageID, that all Properties, Signals, Events, Statistics are supported. In H.248 we have the AuditCapability and AuditValue commands to find out what actual values of properties are supported. So if people agree that not all values in a package need to be supported I propose to add some text to the implementor's guide: Section 12.1 after 2nd Paragraph "A MG SHALL support all Property, Signals & parameters, Events & parameters and Statistics. A MG MAY support a subset of property and parameter values defined in the package unless specified in a package." Cheers, Christian ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

APC-1926: Intra-Zone and Intra-Domain Communications
by Roy, Radhika R, ALCOO 24 Aug '00

24 Aug '00

Hi, Everyone: Yesterday, we had a brief discussion with the above contribution. Please note the following: 1. MGA has been proposed as another alternative mechanism to take care-of the problems of GRQ/GCF/GRJ messages. The Bandwidth problems have been taken care-of because it can be unicast as well, if needed. If anyone has any more comments, please let us know. (GRQ/GCF/GRJ messages have serious limitations in many mobile communications environments. For example, sending of GRQs to discover GKs while the mobile is moving from place to place. In addition, we have just discovered how authentication messages are causing problems when the multicast GRQs are sent to many GKs, and every GKs start processing these messages while the mobile has to choose an unique GK that will be its GK in that particular place given the fact it is changing its network point of attachment. How does a mobile can decide a unique GK in a dynamic environment when the multiple GKs respond back? Does the load (bandwidth) not increase lineally by 2*N [where N = # of users] for all GKs of all zones around the whole domain?) 2. GK needs to be allowed to communicate with HLF directly while service provisioning is done to populate the HLF to store the profile of the mobile users. 3. RRQ messages are NOT sent to the HLF. It is a "new" message that will be used between the GK and HLF, however, the mobility related information provided in RRQ will be communicated to the HLF via the "new" message. In addition, the decision has been made that, like Annex G messages, LRQ messages should also be augmented to support mobility. We already know (as explained in Annex H) that there can be many HLFs, VLFs, etc. in a given domain, and no architectural restriction will be provided in the protocol whether HLFs are centralized or distributed. If you have any questions, please let me know. Best regards, Radhika R. Roy AT&T ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

AW: Comments on H.225.0 v4 Whitedraft (sourceAddress)
by Klaghofer Karl ICN EN HC SE 81 24 Aug '00

24 Aug '00

Rich wrote: "...Note that we allow the E.164 number to be included in both the sourceAddress field and the Calling Party Number IE. If we're saying that it "shall" be in the IE, should we at least say that it "should not" be included in the sourceAddress field? ..." YES, we should state that the real E.164 number of the calling user shall be in Calling Party Number IE and should not be in SourceAddress field. Regards, Karl ----------------------------------------------------------- Karl Klaghofer / ICN EN HC SE 81 HiPath VoIP Enterprise Architecture & Standardization Hofmannstr. 51, 81359 Munich, Germany Tel.: +49 89 722 31488 Fax.: +49 89 722 37629 E-Mail: karl.klaghofer(a)icn.siemens.de -----Ursprüngliche Nachricht----- Von: Rich Bowen [mailto:rkbowen@CISCO.COM] Gesendet am: Freitag, 21. Juli 2000 02:06 An: ITU-SG16(a)mailbag.cps.intel.com Betreff: Re: Comments on H.225.0 v4 Whitedraft (sourceAddress) Karl, Glad you noticed this. How about the following slight modification of the wording that you proposed: "sourceAddress - Contains the alias addresses of the source. The primary address shall be first. Note that the E.164 Number of the source, if any, shall be contained within the Calling Party Number Information Element." Note that we allow the E.164 number to be included in both the sourceAddress field and the Calling Party Number IE. If we're saying that it "shall" be in the IE, should we at least say that it "should not" be included in the sourceAddress field? Regards, Rich Klaghofer Karl ICN EN HC SE 81 wrote: > > One more try, since it seems that my previous mail I sent out yesterday did > not arrive. > Regards, > Karl Klaghofer > > > -----Ursprüngliche Nachricht----- > > Von: Klaghofer Karl ICN EN HC SE 81 > > Gesendet am: Tuesday, July 18, 2000 12:02 > > An: 'ITU-SG16(a)mailbag.cps.intel.com' > > Betreff: Comments on H.225.0 v4 Whitedraft (sourceAddress) > > > > Rich and others, > > > > H.225.0v4 White draft, section 7.3.10 Setup reads: > > "... > > sourceAddress - Contains the alias addresses for the source; the dialed > > digit string of the source is in the Q.931 Calling Party Number IE. The > > primary address shall be first. > > ..." > > > > PROPOSED TO BE CORRECTED TO: > > "... > > sourceAddress - Contains the alias addresses of the source. Note that the > > E.164 Number of the source is contained within Calling Party Number > > Information Element. The primary address shall be first. > > ..." > > > > Background: > > As part of the global v4 change to replace the term "e164" by the term > > "dialedDigits" in the whole H.225.0 document, the sentense in current v4 > > Whitedraft does not make sense anymore and should be corrected in v4 in > > Portland. I think what we wanted to say is that the E.164 number is > > contained within the Calling Party Number IE and not the dialed digit > > string ! Dialed digit string (unstructured number which maybe may include > > prefixes, etc would be put into sourceAddress.dialedDigits). > > Note: There might be further sections where the simple replacement of the > > term e164 by term dialed digits may have caused vagueness, since term e164 > > in v2 was actually used for both - real E.164 but also unstructured digit > > strings. > > > > Regards, > > Karl Klaghofer > > ------------------------------------------------------- > > Karl Klaghofer, Siemens AG > > Dpmt ICN EN HC D81, VoIP Architecture & Standardization > > Hofmannstr. 51, 81359 Munich, Germany > > Tel.: +49 89 722 31488; Fax.: +49 89 722 37629 > > Mail: karl.klaghofer(a)icn.siemens.de > > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > 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 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

2 1