- sg16-avd - lists.packetizer.com

Draft versions of H.323v4, H.225.0v4, H.323v4 Annex D, and the Implementers Guide ready for review
by Paul E. Jones 30 Jun '00

30 Jun '00

Folks, At long last, Rich Bowen and I have been able to complete the initial editing work for the H.323v4 and H.225.0v4 documents. I believe that most of the work is behind us, but I want everybody to review these documents before we finish the final edits and present them to the TSB. The only editing work that remains (at least in H.323v4 and Annex D) are minor editorial issues. Please post comments to the ITU-T SG16 mailing list with the subject prefix "[V4]". Also, I'd like to schedule a conference call for interested parties on Friday, July 7 at 11AM U.S. Eastern Time (GMT - 5). If you are interested in going through the documents, please contact me before that date and we'll set up a conference bridge for the right number of people and go through an issues. http://www.packetizer.com/iptel/h323/drafts/h225v4h_wp_draft.zip http://www.packetizer.com/iptel/h323/drafts/h323v4.zip http://www.packetizer.com/iptel/h323/drafts/H323_annex_d.zip I have one open issue that I definitely want to resolve before the white paper is produced, although we could wait if we absolutely had to-- it is an issue that affects H.323v3, too, and is detailed at the top of the H.323v4 document. I consider it significant as H.323v3 and H.323v2 interoperability is currently impaired. If you have any questions, please feel free to contact me. Once we get the initial review complete, we will complete the edits and send them to the TSB. I also have a complete up to date Implementers Guide for H.323v3: http://www.packetizer.com/iptel/h323/drafts/H.323v3_ig.zip Comments are certainly welcome, but it is not necessary to review that document immediately. Best Regards, Paul E. Jones ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

upload of H.235v2 white contribution
by Euchner Martin 30 Jun '00

30 Jun '00

The H.235v2 white paper has been uploaded to the incoming directory of the avc-site. After the document has been moved, you will find it in the 0011_Gen directory. Changes since the Osaka Meeting: * Figures added clarifying use of the challenge-response procedures. * Minor editorial cleanup. Kind regards Martin Euchner. ----------------------------------------------------------------------- | Dipl.-Inf. Phone: +49 89 636-46201 | Martin Euchner Fax : +49 89 636-48000 | Siemens AG | ZT IK 3 mailto:Martin.Euchner@mchp.siemens.de | mailto:martin.euchner@ties.itu.int | Otto-Hahn-Ring 6 Intranet: http://zt-security.mchp.siemens.de/de/Competence/Standardization/ITU-T_SG16/ index.html | D-81730 Muenchen Internet: 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

H.323 URL Text
by Paul E. Jones 30 Jun '00

30 Jun '00

Folks, I have attached the text that I propose adding to the H.323v4 document relating to the H.323 URL scheme. I think this text is weak, but I expect contributions to be brought to define the usage of this scheme-- presently, there really is no procedural text. I'd like to point out that I removed the telephone number portions of the URL, which should make both Orit and Bob happy :-) Please review the text and the ABNF grammar for errors. You will note one small bit of procedural text near the end where it discusses the fact that a Gatekeeper may modify the alias provided to the Gatekeeper. The substance of that existed in TD-50 (Osaka) and I thought that it was important to go ahead and include that at the very least. Please, give me feedback. Mr. Bowen and I plan to post H.323v4 and H.225.0v4 this week for review. A formal announcement will be made later today or tomorrow. Best Regards, Paul

2 1

PV 2001
by PV2001 Secretariat 29 Jun '00

29 Jun '00

<<APOLOGIES TO THOSE WHO RECEIVE THIS EMAIL MORE THAN ONCE.>> Invitation to PV(Packet Video Workshop) 2001 : 30 April - 1 May 2001, Kyongju, Korea The 11th International Packet Video Workshop (PV 2001) will be held on 30 April - 1 May 2001 in Kyongju, Korea, which was the capital city of ancient Korea (A.D 676 - A.D 935), located in 350-kilometer southeast of Seoul. The workshop is devoted to presenting technological advancements and innovations in video transmission over packet networks, in particular, the Internet. Packet Video Workshop has been unique in providing a common ground for people from video coding and networking fields. Presentations on theory and practice, standards activities, and business and consumer applications are encouraged. In 2001, the workshop is scheduled to take place in the week following Picture Coding Symposium (PCS 2001) which will be held in Seoul, Korea on 25-27 April 2001 (http://pcs.kaist.ac.kr) We cordially invite you take part in this workshop by submitting your work. Important due date: November 15, 2000: Paper submission January 31, 2001: Notice of acceptance March 15, 2001: Final paper delivery For more information about PV 2001 and the conference city, kyongju, please check the attached file as well as the web site of http://pv2001.kaist.ac.kr. Best regards, Jae-kyoon Kim, General Chair

1 0

Re: liaisons for August Q12-14 meeting
by Sakae OKUBO 23 Jun '00

23 Jun '00

Dear Mr. Freundlich, APC numbers have been allocated as follows: >We have received two liaisons from SG11 that we should cover during the >August meeting in Portland: APC-1872 >"Liaison to SG16 On Interaction Between Intelligent Network Systems and >H.248" from Q22/11 APC-1873 >"Liaison to SG16 On Interworking Between H.323 Systems and Intelligent >Network Systems" from Q22/11 Best regards, Sakae OKUBO *********************************************************** Waseda Research Center Telecommunications Advancement Organization of Japan (TAO) 5th Floor, Nishi-Waseda Bldg. 1-21-1 Nishi-Waseda, Shinjuku-ku, Tokyo 169-0051 Japan Tel: +81 3 5286 3830 (to be transferred) +81 3 3204 8194 (direct) Fax: +81 3 5287 7287 e-mail: okubo(a)giti.or.jp *********************************************************** ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

upload of white draft for Annex K
by Espen Skj�ran 23 Jun '00

23 Jun '00

Hi all, I've uploaded a draft of H.323 Annex K to ftp://standard.pictel.com/avc-site/Incoming/h323-annexK-white.zip Changes since Osaka: - Removed section K.3.3 (the callto: scheme) and inserted text that h323-urls should be handled locally by the h.323 endpoint. - Removed references to WAP, XML, and CPL. All CPL descriptions are made more generic with "call processing scripts". I saw Chip's mail about the less need for justification of informative references, but this seemed the most reasonable thing to do. I intend to submit this document by July 1st. Espen ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

H.323 URL - IANA registration
by Orit Levin 22 Jun '00

22 Jun '00

Chip, I agree and taking care of that. Before the decision where to register H323 url (and after the reading of BCP-35) this is my take on it: To register H323 url under a new ITU tree may be a quicker process and more flexible for later changes. The disadvantage is that we (ITU) need to define procedures for ITU tree maintenance/"change control". To register H323 url under IETF would require either RFC standard track document (I don't believe in such a thing for H.323) or Informational RFC carefully inspected by IESG for all possible implications. Your opinions, please! Orit Levin RADVision Inc. 575 Corporate Drive Suite 420 Mahwah, NJ 07430 Tel: 1 201 529 4300 (230) Fax: 1 201 529 3516 www.radvision.com orit(a)radvision.com -----Original Message----- From: Chip Sharp <chsharp(a)CISCO.COM> To: ITU-SG16(a)MAILBAG.INTEL.COM <ITU-SG16(a)MAILBAG.INTEL.COM> Date: Thursday, June 22, 2000 9:14 AM Subject: Re: H.323 URL >I don't disagree with your proposal; however... :-) > >If it is going to be called a URL, it needs to be registered as per >BCP35. Otherwise, use of the term URL will be confusing to the industry. > >Chip > > >At 01:46 AM 6/22/00 -0400, Paul E. Jones wrote: >>Bob, >> >>Perhaps the simplest solution is for the white paper to contain the agreed >>syntax thus far from TD-40, without any of the other content. I agree >>that it is probably illegal to say that the H.323 URL can be copied into >>the e-mail ID field. However, if the syntax following h323: suggested >>that what follows is some generic identifier and its attributes, an e-mail >>address, or telephone number based on the format, then I believe it would >>be valid to say we could copy the e-mail address into that alias >>field. However, I don't know how to interpret the octets following the h323:. >> >>Could we agree to have a section that defines the shows the URL syntax >>without procedure and agree that the procedural text will be added to >>Annex O? I would even suggest to put the URL definition in Annex O, too, >>but we have a timing problem with respect to Annex K-- it needs that >>definition now. >> >>Thoughts? >> >>Paul >> >>>----- Original Message ----- >>>From: <mailto:Robert.Callaghan@ICN.SIEMENS.COM>Callaghan, Robert >>>To: <mailto:ITU-SG16@mailbag.cps.intel.com>ITU-SG16(a)mailbag.cps.intel.com >>>Sent: Monday, June 19, 2000 2:46 PM >>>Subject: Re: H.323 URL >>> >>>Orit, >>> >>>I am not now sure what was agreed to, other that to let TD-40a to move >>>forward. >>> >>>I do agree with the three points in your note. >>> >>>I do not agree that the proposal was limited to Call Control Messages. I >>>see no difference between the use of H.323-URLs on a Web page and the use >>>of H.3233-URLs in Call Control. The one directly leads to the latter. >>> >>>I am not sure if you are implying that only H.323-URL can be used to >>>direct a call to an H.323 destination. If so, I disagree. All alias >>>formats work equally well. My understanding is that Paul Jones wanted >>>the E.164 format of the H.323-URL in order to access the gateway using >>>the H.323 client as a telephony client. This definitely does not point >>>to an H.323 URL. >>> >>>I am afraid that we may not know what we agreed to, other than to >>>proceed. That is why I objected that the URL be included in v4 instead >>>of and annex or appendix. Now our lack of understanding as to what we >>>understood will jeprodice v4 if it remains as is. But that was the >>>agreement, so we must proceed forward. >>> >>>Bob >>> >>> >>>-----Original Message----- >>>From: Orit Levin [mailto:orit@radvision.com] >>>Sent: Monday, June 19, 2000 10:06 AM >>>To: ITU-SG16(a)mailbag.cps.intel.com >>>Subject: Re: H.323 URL >>> >>>Dear all! >>>There are two faces to H323-URL. The first one is when H.323-URL is used >>>as an alias in H.323 Call Control messages. The second is when H.323-URL >>>is used in Web pages or other hyperlinks. (Although, when both are in >>>place, from procedural point of view their order is vice versa.) >>> >>>In my contribution in Osaka, I chose to address "the first case" first. >>>There are number reasons for this: >>>1. URL concept exists in H.323 since version 2. The procedures, how URLs >>>should be used, haven't been defined. This clearly invites >>>interoperability problems. >>>2. H323-URL hasn't been defined at all. This leads to interpretation of >>>other URLs, to be used INSTEAD, while reaching pure H.323 entities! This >>>clearly invites interoperability problems. >>>3. Standard H323-URL can greatly facilitate address translation >>>procedure, when H.323 runs on Internet. >>> >>>As it can be seen from TD-40a, it has been agreed, that H323-URL should >>>be used to POINT TO H.323 DESTINATION. Other URLs may/should be used in >>>H.323 messages to point to other destinations. Personally, I see this >>>approach as the best. Also Bob and Francoise supported this in their last >>>e-mails. Please, lets try not to open already agreed things before the >>>next meeting, jeopardizing by that H.323v4 decision. Specifically on >>>H323-URL topic, we have to clean things (such as the use of email ID >>>alias) and put the basic version onto H.323v4. Then we will have "Annex >>>O" to expand on additional "complimentary to H.323" procedures. >>> >>>One of these procedures is "the second face" of H323-URL: while used in >>>WEB pages. It is clear that H.323-URL should be expanded with additional >>>parameters to be used as such. It is also mentioned in TD-40a. >>>Contributions are mostly welcome. >>> >>>Best Regards, >>>Orit Levin >>>RADVision Inc. >>>575 Corporate Drive Suite 420 >>>Mahwah, NJ 07430 >>>Tel: 1 201 529 4300 (230) >>>Fax: 1 201 529 3516 >>><http://www.radvision.com>www.radvision.com >>><mailto:orit@radvision.com>orit(a)radvision.com >>>>-----Original Message----- >>>>From: Paul E. Jones <<mailto:paulej@PACKETIZER.COM>paulej(a)PACKETIZER.COM> >>>>To: <mailto:ITU-SG16@MAILBAG.INTEL.COM>ITU-SG16(a)MAILBAG.INTEL.COM >>>><<mailto:ITU-SG16@MAILBAG.INTEL.COM>ITU-SG16(a)MAILBAG.INTEL.COM> >>>>Date: Monday, June 19, 2000 3:27 AM >>>>Subject: Re: H.323 URL >>>> >>>>Francois, >>>> >>>>If I want to provide a means of allowing somebody to call me by placing >>>>a URL on a web page, I need to provide something that can be resolved >>>>universally by H.323 endpoints. Bob mentioned querying a database-- >>>>that's certainly a possibility, assuming that that database contains all >>>>of the information it needs to resolve an address. >>>> >>>>What I am afraid of here is that we are introducing syntax to reach a >>>>resource without defining any procedure. >>>> >>>>If I see this url: >>>><mailto:h323:paulej@packetizer.com>h323:paulej@packetizer.com >>>> >>>>What does that tell the H.323 entity? Is there a GK that is expecting a >>>>LRQ, AccessRequest, or is it something else entirely? Perhaps the right >>>>solution is to define (in normative text) the procedure for using SRV >>>>DNS records to query the packetizer.com domain. >>>> >>>>As Pete rightfully pointed out, an H.323 URL would be the perfect place >>>>to place conference identifiers for multipoint conferences: >>>> >>>><mailto:h323:conf-server1@packetizer.com;cid:XXXX-XXXX-XXXX-XXXX>h323:co nf-server1@packetizer.com;cid:XXXX-XXXX-XXXX-XXXX >>>> >>>> >>>>I think we need to work on the procedural part of this now. Who is >>>>working on that? >>>> >>>>Paul >>>> >>>>>----- Original Message ----- >>>>>From: <mailto:audet@NORTELNETWORKS.COM>Francois Audet >>>>>To: <mailto:ITU-SG16@mailbag.cps.intel.com>ITU-SG16(a)mailbag.cps.intel.com >>>>>Sent: Friday, June 16, 2000 11:48 AM >>>>>Subject: Re: H.323 URL >>>>> >>>>>I would agree with Bob here. >>>>>Using an H.323 URL for a telephone number would imply that you can only >>>>>be >>>>>reached using H.323. Is this you intention? >>>>> >>>>> > -----Original Message----- >>>>> > From: Callaghan, Robert >>>>> [<mailto:Robert.Callaghan@ICN.SIEMENS.COM>mailto:Robert.Callaghan@ICN.SIEMEN S.COM] >>>>> >>>>> > Sent: Friday, June 16, 2000 5:39 AM >>>>> > To: <mailto:ITU-SG16@MAILBAG.INTEL.COM>ITU-SG16(a)MAILBAG.INTEL.COM >>>>> > Subject: Re: H.323 URL >>>>> > >>>>> > >>>>> > Paul, >>>>> > >>>>> > I think that this is getting complicated. >>>>> > >>>>> > I did not envision the use of the H.323-URL to encompase a >>>>> > telephone number. >>>>> > I only conceede for the purpose of progress. >>>>> > >>>>> > I saw the H.323-URL to be an identifier that would be used to access a >>>>> > database. The DNS portion would identify the database, the >>>>> > userID would be >>>>> > the entry in the database. The database would then return >>>>> > the necessary >>>>> > information to complete the call. It is highly propable that this >>>>> > information would include an E.164 or PNP address. This is >>>>> > especially true >>>>> > when the call must be ompleted over the SCN. >>>>> > >>>>> > I saw telephone numbers being defined in the "Tel:" URL >>>>> > defined in RFC2806. >>>>> > This URL covers many of optional fields needed to make an SCN >>>>> > call which are >>>>> > not presently covered in H.323. >>>>> > >>>>> > If we are to have multiple forms of an H.323 URL, I would >>>>> > prefer to have >>>>> > multi-URL IDs. >>>>> > >>>>> > Bob >>>>> > >>>>> > P.S. (By the way, the complex, cover everything, is where the >>>>> > last try at an >>>>> > H.323 URL diaappeared.) >>>>> > >>>>> > ------------------------------------------------------------------ >>>>> > Robert Callaghan >>>>> > Siemens Enterprise Networks >>>>> > Tel: +1.561.923.1756 Fax: +1.561.923.1403 >>>>> > Email: Robert.Callaghan(a)ICN.Siemens.com >>>>> > ------------------------------------------------------------------ >>>>> > >>>>> > >>>>> > -----Original Message----- >>>>> > From: Paul E. Jones >>>>> [<mailto:paulej@packetizer.com>mailto:paulej@packetizer.com] >>>>> > Sent: Friday, June 16, 2000 3:11 AM >>>>> > To: Callaghan, Robert; 'Orit Levin' >>>>> > Cc: Mailing list for parties associated with ITU-T Study Group 16 >>>>> > (E-mail) >>>>> > Subject: Re: H.323 URL >>>>> > >>>>> > >>>>> > Bob, >>>>> > >>>>> > I'm still surprised that you don't want to see the URL expanded... >>>>> > especially to address party number types. Here is is currently: >>>>> > >>>>> > H323-URL = "H323:" user ["@" hostport] >>>>> > user = username | phone-number >>>>> > username = *( unreserved | escaped | "&" | "=" | "+" >>>>> > | "$" | "," ) >>>>> > hostport = host [ ":" port ] >>>>> > host = hostname | IPv4address >>>>> > hostname = *( domainlabel "." ) toplabel [ "." ] >>>>> > domainlabel = alphanum | alphanum *( alphanum | "-" ) alphanum >>>>> > toplabel = alpha | alpha *( alphanum | "-" ) alphanum >>>>> > IPv4address = 1*digit "." 1*digit "." 1*digit "." 1*digit >>>>> > port = *digit >>>>> > reserved = ";" | "/" | "?" | ":" | "@" | "&" | "=" | >>>>> > "+" |"$" | "," >>>>> > digits = 1*DIGIT >>>>> > >>>>> > However, to be useful, information that follows the "h323:" should be >>>>> > something in a form that an H.323 Gatekeeper can resolve. >>>>> > Those things >>>>> > include: >>>>> > dialedDigits >>>>> > h323-ID >>>>> > email-ID >>>>> > partyNumber >>>>> > or one of the transportAddress types. >>>>> > >>>>> > This seems to be a reasonable syntax: >>>>> > >>>>> > H323-URL = "H323:" Address >>>>> > Address = AliasAddress / TransportAddress >>>>> > AliasAddress = dialedDigits / h323-ID / email-ID / partyNumber >>>>> > dialedDigits = "dialedDigits=" 1*digit >>>>> > h323-ID = "h323-ID=" 1*OCTET ; UTF-8 string represting the >>>>> > BMPString >>>>> > email-ID = "email-ID=" email-ID-spec >>>>> > partyNumber = e164Number / dataPartyNumber / telexPartyNumber / >>>>> > privateNumber >>>>> > / nationalStandardPartyNumber >>>>> > email-ID-spec = mailbox / group >>>>> > group = phrase ":" [ mailbox ] ";" >>>>> > phrase = 1*word >>>>> > word = atom / quoted-string >>>>> > atom = 1*CHAR ; any CHAR except specials, SPACE and CTLs >>>>> > specials = "(" / ")" / "<" / ">" / "@" ; Must be in quoted- >>>>> > / "," / ";" / ":" / "\" / <"> ; string, to use >>>>> > / "." / "[" / "]" ; within a word. >>>>> > quoted-string = >>>>> > mailbox = addr-spec / phrase route-addr >>>>> > addr-spec = local-part "@" domain >>>>> > local-part = word *("." word) >>>>> > domain = sub-domain *("." sub-domain) >>>>> > sub-domain = domain-ref / domain-literal >>>>> > domain-ref = atom >>>>> > domain-literal = "[" *(dtext / quoted-pair) "]" >>>>> > dtext = 1*CHAR ; Any CHAR excluding "[", "]", "\" & CR, >>>>> > ; & including linear-white-space> >>>>> > linear-white-space = 1*([CRLF] LWSP-char) >>>>> > LWSP-char = SP / HTAB >>>>> > quoted-pair = "\" CHAR >>>>> > phrase = 1*word >>>>> > route-addr = "<" [route] addr-spec ">" >>>>> > route = "@" domain ":" >>>>> > e164Number = "e164Number=" publicTypeOfNumber "," digits >>>>> > digits = 1*(DIGIT / "#" / "*" / ",") >>>>> > publicTypeOfNumber = "unknown" / "internationalStandard" / >>>>> > "nationalNumber" >>>>> > / "networkSpecificNumber" / "subscriberNumber" / >>>>> > / "abbreviatedNumber" >>>>> > dataPartyNumber = "dataPartyNumber=" digits >>>>> > telexPartyNumber= "telexPartyNumber=" digits >>>>> > privatePartyNumber = "privatePartyNumber=" >>>>> > privateTypeOfNumber "," digits >>>>> > privateTypeOfNumber = "unknown" / "level2RegionalNumber" / >>>>> > "level1RegionalNumber" >>>>> > / "pISNSpecificNumber" / "localNumber" / >>>>> > "abbreviatedNumber" >>>>> > TransportAddress = ipAddress / ipSourceRoute / ipxAddress / ip6Address >>>>> > / netBios / nsap / nonStandardAddress >>>>> > ipAddress = ip ":" port >>>>> > ip = 1*DIGIT "." 1*DIGIT "." 1*DIGIT "." 1*DIGIT >>>>> > port = 1*DIGIT >>>>> > ipSourceRoute = ip ":" port "," ip *1("," ip) ";" ("strict" >>>>> > / "loose") >>>>> > ipxAddress = 1*DIGIT ":" 1*DIGIT ":" 1*DIGIT >>>>> > ip6Address = 1*HEXDIGIT 14*(":" [1*HEXDIGIT]) 1*HEXDIGIT >>>>> > HEXDIGIT = DIGIT / "A" / "B" / "C" / "D" / "E" / "F" >>>>> > netBios = ;; and so forth >>>>> > nsap = >>>>> > nonStandardAddress = >>>>> > >>>>> > Now, there may be an error or two in there, but at least it >>>>> > is more complete >>>>> > and an H.323 system knows how to work with these. (Note I >>>>> > did not address >>>>> > the new V4 alias "mobileIUM") >>>>> > >>>>> > If we used this grammar, I don't think we would need a lot of >>>>> > strange rules >>>>> > about what you do with the URL. Basically, you take it apart >>>>> > according to >>>>> > its internal parts to form an alias address that a Gatekeeper >>>>> > can resolve. >>>>> > >>>>> > Paul >>>>> > >>>>> > ----- Original Message ----- >>>>> > From: "Callaghan, Robert" <Robert.Callaghan(a)icn.siemens.com> >>>>> > To: "'Orit Levin'" <orit(a)radvision.com>; "'Paul E. Jones'" >>>>> > <paulej(a)PACKETIZER.COM> >>>>> > Cc: "Mailing list for parties associated with ITU-T Study >>>>> > Group 16 (E-mail)" >>>>> > <ITU-SG16(a)mailbag.cps.intel.com> >>>>> > Sent: Wednesday, June 14, 2000 3:50 PM >>>>> > Subject: RE: H.323 URL >>>>> > >>>>> > >>>>> > > Orit, >>>>> > > >>>>> > > In my opinion, an email-ID alias conforms to RFC-822 and is >>>>> > interpreted >>>>> > > according the rules stated in H.225.0. An H.323-URL-ID conforms to >>>>> > > TD-40a/Osaka and is interpreted according to the rules >>>>> > stated in TD-40a. >>>>> > An >>>>> > > H.323-ID is a character string without any rules of >>>>> > interpretation. I see >>>>> > > no need to blend these contexts. All three addressing >>>>> > modes can be use; >>>>> > > each in its own context. >>>>> > > >>>>> > > However, these are my opinion. Maybe more work is needed >>>>> > in Portland. >>>>> > > >>>>> > > Bob >>>>> > > >>>>> > > ------------------------------------------------------------------ >>>>> > > Robert Callaghan >>>>> > > Siemens Enterprise Networks >>>>> > > Tel: +1.561.923.1756 Fax: +1.561.923.1403 >>>>> > > Email: Robert.Callaghan(a)ICN.Siemens.com >>>>> > > ------------------------------------------------------------------ >>>>> > > >>>>> > > >>>>> > > -----Original Message----- >>>>> > > From: Orit Levin >>>>> [<mailto:orit@radvision.com>mailto:orit@radvision.com] >>>>> > > Sent: Wednesday, June 14, 2000 11:45 AM >>>>> > > To: Callaghan, Robert; 'Paul E. Jones' >>>>> > > Cc: Mailing list for parties associated with ITU-T Study Group 16 >>>>> > > (E-mail) >>>>> > > Subject: Re: H.323 URL >>>>> > > >>>>> > > >>>>> > > Hello Bob and Paul! >>>>> > > I don't see backwards compatibility problem, when the URL >>>>> > says explicitly >>>>> > > H323-URL. An appropriate change may be to state, that the >>>>> > default meaning >>>>> > of >>>>> > > url, encoded into email-ID alias, is according to RFC-822. >>>>> > > Now, I feel a need to put a chapter explaining what is the >>>>> > meaning of >>>>> > email >>>>> > > URL (apart from its syntax) when used in H.323 Network. >>>>> > There is some >>>>> > > explanation in H.225.0 Appendix IV. Do you find it clear >>>>> > and sufficient? >>>>> > > Orit Levin >>>>> > > RADVision Inc. >>>>> > > 575 Corporate Drive Suite 420 >>>>> > > Mahwah, NJ 07430 >>>>> > > Tel: 1 201 529 4300 (230) >>>>> > > Fax: 1 201 529 3516 >>>>> > > www.radvision.com >>>>> > > orit(a)radvision.com >>>>> > > -----Original Message----- >>>>> > > From: Callaghan, Robert <Robert.Callaghan(a)icn.siemens.com> >>>>> > > To: 'Paul E. Jones' <paulej(a)PACKETIZER.COM>; 'Orit Levin' >>>>> > > <orit(a)radvision.com> >>>>> > > Cc: Mailing list for parties associated with ITU-T Study >>>>> > Group 16 (E-mail) >>>>> > > <ITU-SG16(a)mailbag.cps.intel.com> >>>>> > > Date: Wednesday, June 14, 2000 9:56 AM >>>>> > > Subject: H.323 URL >>>>> > > >>>>> > > >>>>> > > >Paul, >>>>> > > > >>>>> > > >I have a backward compatibility item for you to think about. >>>>> > > > >>>>> > > >TD-40/Osaka states that the H323-URL may be coded into the >>>>> > email-ID for >>>>> > > >alias address. However, H.225.0 states that the email-ID >>>>> > shall conform >>>>> > to >>>>> > > >RFC822. This is an exclusionary requirement in that other >>>>> > standards may >>>>> > > not >>>>> > > >be used. Also, Note 4 of the BNF definition of the >>>>> > H323-URL clearly >>>>> > states >>>>> > > >that that the H323-URL is *not* compatible with RFC822. >>>>> > > > >>>>> > > >Therefor, I propose that the H323-URL cannot be coded into >>>>> > the email-ID >>>>> > for >>>>> > > >alias address because of compatibility problems. >>>>> > > > >>>>> > > >Bob >>>>> > > > >>>>> > > >------------------------------------------------------------------ >>>>> > > >Robert Callaghan >>>>> > > >Siemens Enterprise Networks >>>>> > > >Tel: +1.561.923.1756 Fax: +1.561.923.1403 >>>>> > > >Email: Robert.Callaghan(a)ICN.Siemens.com >>>>> > > >------------------------------------------------------------------ >>>>> > > > >>>>> > > >>>>> > >>>>> > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >>>>> > For help on this mail list, send "HELP ITU-SG16" in a message to >>>>> > listserv(a)mailbag.intel.com >>>>> > > > >------------------------------------------------------------------- >Chip Sharp CTO Consulting Engineering >Cisco Systems >Reality - Love it or Change it. >http://www.netaid.org >------------------------------------------------------------------- > >~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >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

Re: H.323 URL
by Callaghan, Robert 22 Jun '00

22 Jun '00

Orit, I am not now sure what was agreed to, other that to let TD-40a to move forward. I do agree with the three points in your note. I do not agree that the proposal was limited to Call Control Messages. I see no difference between the use of H.323-URLs on a Web page and the use of H.3233-URLs in Call Control. The one directly leads to the latter. I am not sure if you are implying that only H.323-URL can be used to direct a call to an H.323 destination. If so, I disagree. All alias formats work equally well. My understanding is that Paul Jones wanted the E.164 format of the H.323-URL in order to access the gateway using the H.323 client as a telephony client. This definitely does not point to an H.323 URL. I am afraid that we may not know what we agreed to, other than to proceed. That is why I objected that the URL be included in v4 instead of and annex or appendix. Now our lack of understanding as to what we understood will jeprodice v4 if it remains as is. But that was the agreement, so we must proceed forward. Bob -----Original Message----- From: Orit Levin [mailto:orit@radvision.com] Sent: Monday, June 19, 2000 10:06 AM To: ITU-SG16(a)mailbag.cps.intel.com Subject: Re: H.323 URL Dear all! There are two faces to H323-URL. The first one is when H.323-URL is used as an alias in H.323 Call Control messages. The second is when H.323-URL is used in Web pages or other hyperlinks. (Although, when both are in place, from procedural point of view their order is vice versa.) In my contribution in Osaka, I chose to address "the first case" first. There are number reasons for this: 1. URL concept exists in H.323 since version 2. The procedures, how URLs should be used, haven't been defined. This clearly invites interoperability problems. 2. H323-URL hasn't been defined at all. This leads to interpretation of other URLs, to be used INSTEAD, while reaching pure H.323 entities! This clearly invites interoperability problems. 3. Standard H323-URL can greatly facilitate address translation procedure, when H.323 runs on Internet. As it can be seen from TD-40a, it has been agreed, that H323-URL should be used to POINT TO H.323 DESTINATION. Other URLs may/should be used in H.323 messages to point to other destinations. Personally, I see this approach as the best. Also Bob and Francoise supported this in their last e-mails. Please, lets try not to open already agreed things before the next meeting, jeopardizing by that H.323v4 decision. Specifically on H323-URL topic, we have to clean things (such as the use of email ID alias) and put the basic version onto H.323v4. Then we will have "Annex O" to expand on additional "complimentary to H.323" procedures. One of these procedures is "the second face" of H323-URL: while used in WEB pages. It is clear that H.323-URL should be expanded with additional parameters to be used as such. It is also mentioned in TD-40a. Contributions are mostly welcome. Best Regards, Orit Levin RADVision Inc. 575 Corporate Drive Suite 420 Mahwah, NJ 07430 Tel: 1 201 529 4300 (230) Fax: 1 201 529 3516 www.radvision.com <http://www.radvision.com> orit(a)radvision.com <mailto:orit@radvision.com> -----Original Message----- From: Paul E. Jones < paulej(a)PACKETIZER.COM <mailto:paulej@PACKETIZER.COM> > To: ITU-SG16(a)MAILBAG.INTEL.COM <mailto:ITU-SG16@MAILBAG.INTEL.COM> < ITU-SG16(a)MAILBAG.INTEL.COM <mailto:ITU-SG16@MAILBAG.INTEL.COM> > Date: Monday, June 19, 2000 3:27 AM Subject: Re: H.323 URL Francois, If I want to provide a means of allowing somebody to call me by placing a URL on a web page, I need to provide something that can be resolved universally by H.323 endpoints. Bob mentioned querying a database-- that's certainly a possibility, assuming that that database contains all of the information it needs to resolve an address. What I am afraid of here is that we are introducing syntax to reach a resource without defining any procedure. If I see this url: h323:paulej@packetizer.com <mailto:h323:paulej@packetizer.com> What does that tell the H.323 entity? Is there a GK that is expecting a LRQ, AccessRequest, or is it something else entirely? Perhaps the right solution is to define (in normative text) the procedure for using SRV DNS records to query the packetizer.com domain. As Pete rightfully pointed out, an H.323 URL would be the perfect place to place conference identifiers for multipoint conferences: h323:conf-server1@packetizer.com;cid:XXXX-XXXX-XXXX-XXXX <mailto:h323:conf-server1@packetizer.com;cid:XXXX-XXXX-XXXX-XXXX> I think we need to work on the procedural part of this now. Who is working on that? Paul ----- Original Message ----- From: Francois Audet <mailto:audet@NORTELNETWORKS.COM> To: ITU-SG16(a)mailbag.cps.intel.com <mailto:ITU-SG16@mailbag.cps.intel.com> Sent: Friday, June 16, 2000 11:48 AM Subject: Re: H.323 URL I would agree with Bob here. Using an H.323 URL for a telephone number would imply that you can only be reached using H.323. Is this you intention? > -----Original Message----- > From: Callaghan, Robert [ mailto:Robert.Callaghan@ICN.SIEMENS.COM <mailto:Robert.Callaghan@ICN.SIEMENS.COM> ] > Sent: Friday, June 16, 2000 5:39 AM > To: ITU-SG16(a)MAILBAG.INTEL.COM <mailto:ITU-SG16@MAILBAG.INTEL.COM> > Subject: Re: H.323 URL > > > Paul, > > I think that this is getting complicated. > > I did not envision the use of the H.323-URL to encompase a > telephone number. > I only conceede for the purpose of progress. > > I saw the H.323-URL to be an identifier that would be used to access a > database. The DNS portion would identify the database, the > userID would be > the entry in the database. The database would then return > the necessary > information to complete the call. It is highly propable that this > information would include an E.164 or PNP address. This is > especially true > when the call must be ompleted over the SCN. > > I saw telephone numbers being defined in the "Tel:" URL > defined in RFC2806. > This URL covers many of optional fields needed to make an SCN > call which are > not presently covered in H.323. > > If we are to have multiple forms of an H.323 URL, I would > prefer to have > multi-URL IDs. > > Bob > > P.S. (By the way, the complex, cover everything, is where the > last try at an > H.323 URL diaappeared.) > > ------------------------------------------------------------------ > Robert Callaghan > Siemens Enterprise Networks > Tel: +1.561.923.1756 Fax: +1.561.923.1403 > Email: Robert.Callaghan(a)ICN.Siemens.com > ------------------------------------------------------------------ > > > -----Original Message----- > From: Paul E. Jones [ mailto:paulej@packetizer.com <mailto:paulej@packetizer.com> ] > Sent: Friday, June 16, 2000 3:11 AM > To: Callaghan, Robert; 'Orit Levin' > Cc: Mailing list for parties associated with ITU-T Study Group 16 > (E-mail) > Subject: Re: H.323 URL > > > Bob, > > I'm still surprised that you don't want to see the URL expanded... > especially to address party number types. Here is is currently: > > H323-URL = "H323:" user ["@" hostport] > user = username | phone-number > username = *( unreserved | escaped | "&" | "=" | "+" > | "$" | "," ) > hostport = host [ ":" port ] > host = hostname | IPv4address > hostname = *( domainlabel "." ) toplabel [ "." ] > domainlabel = alphanum | alphanum *( alphanum | "-" ) alphanum > toplabel = alpha | alpha *( alphanum | "-" ) alphanum > IPv4address = 1*digit "." 1*digit "." 1*digit "." 1*digit > port = *digit > reserved = ";" | "/" | "?" | ":" | "@" | "&" | "=" | > "+" |"$" | "," > digits = 1*DIGIT > > However, to be useful, information that follows the "h323:" should be > something in a form that an H.323 Gatekeeper can resolve. > Those things > include: > dialedDigits > h323-ID > email-ID > partyNumber > or one of the transportAddress types. > > This seems to be a reasonable syntax: > > H323-URL = "H323:" Address > Address = AliasAddress / TransportAddress > AliasAddress = dialedDigits / h323-ID / email-ID / partyNumber > dialedDigits = "dialedDigits=" 1*digit > h323-ID = "h323-ID=" 1*OCTET ; UTF-8 string represting the > BMPString > email-ID = "email-ID=" email-ID-spec > partyNumber = e164Number / dataPartyNumber / telexPartyNumber / > privateNumber > / nationalStandardPartyNumber > email-ID-spec = mailbox / group > group = phrase ":" [ mailbox ] ";" > phrase = 1*word > word = atom / quoted-string > atom = 1*CHAR ; any CHAR except specials, SPACE and CTLs > specials = "(" / ")" / "<" / ">" / "@" ; Must be in quoted- > / "," / ";" / ":" / "\" / <"> ; string, to use > / "." / "[" / "]" ; within a word. > quoted-string = > mailbox = addr-spec / phrase route-addr > addr-spec = local-part "@" domain > local-part = word *("." word) > domain = sub-domain *("." sub-domain) > sub-domain = domain-ref / domain-literal > domain-ref = atom > domain-literal = "[" *(dtext / quoted-pair) "]" > dtext = 1*CHAR ; Any CHAR excluding "[", "]", "\" & CR, > ; & including linear-white-space> > linear-white-space = 1*([CRLF] LWSP-char) > LWSP-char = SP / HTAB > quoted-pair = "\" CHAR > phrase = 1*word > route-addr = "<" [route] addr-spec ">" > route = "@" domain ":" > e164Number = "e164Number=" publicTypeOfNumber "," digits > digits = 1*(DIGIT / "#" / "*" / ",") > publicTypeOfNumber = "unknown" / "internationalStandard" / > "nationalNumber" > / "networkSpecificNumber" / "subscriberNumber" / > / "abbreviatedNumber" > dataPartyNumber = "dataPartyNumber=" digits > telexPartyNumber= "telexPartyNumber=" digits > privatePartyNumber = "privatePartyNumber=" > privateTypeOfNumber "," digits > privateTypeOfNumber = "unknown" / "level2RegionalNumber" / > "level1RegionalNumber" > / "pISNSpecificNumber" / "localNumber" / > "abbreviatedNumber" > TransportAddress = ipAddress / ipSourceRoute / ipxAddress / ip6Address > / netBios / nsap / nonStandardAddress > ipAddress = ip ":" port > ip = 1*DIGIT "." 1*DIGIT "." 1*DIGIT "." 1*DIGIT > port = 1*DIGIT > ipSourceRoute = ip ":" port "," ip *1("," ip) ";" ("strict" > / "loose") > ipxAddress = 1*DIGIT ":" 1*DIGIT ":" 1*DIGIT > ip6Address = 1*HEXDIGIT 14*(":" [1*HEXDIGIT]) 1*HEXDIGIT > HEXDIGIT = DIGIT / "A" / "B" / "C" / "D" / "E" / "F" > netBios = ;; and so forth > nsap = > nonStandardAddress = > > Now, there may be an error or two in there, but at least it > is more complete > and an H.323 system knows how to work with these. (Note I > did not address > the new V4 alias "mobileIUM") > > If we used this grammar, I don't think we would need a lot of > strange rules > about what you do with the URL. Basically, you take it apart > according to > its internal parts to form an alias address that a Gatekeeper > can resolve. > > Paul > > ----- Original Message ----- > From: "Callaghan, Robert" <Robert.Callaghan(a)icn.siemens.com> > To: "'Orit Levin'" <orit(a)radvision.com>; "'Paul E. Jones'" > <paulej(a)PACKETIZER.COM> > Cc: "Mailing list for parties associated with ITU-T Study > Group 16 (E-mail)" > <ITU-SG16(a)mailbag.cps.intel.com> > Sent: Wednesday, June 14, 2000 3:50 PM > Subject: RE: H.323 URL > > > > Orit, > > > > In my opinion, an email-ID alias conforms to RFC-822 and is > interpreted > > according the rules stated in H.225.0. An H.323-URL-ID conforms to > > TD-40a/Osaka and is interpreted according to the rules > stated in TD-40a. > An > > H.323-ID is a character string without any rules of > interpretation. I see > > no need to blend these contexts. All three addressing > modes can be use; > > each in its own context. > > > > However, these are my opinion. Maybe more work is needed > in Portland. > > > > Bob > > > > ------------------------------------------------------------------ > > Robert Callaghan > > Siemens Enterprise Networks > > Tel: +1.561.923.1756 Fax: +1.561.923.1403 > > Email: Robert.Callaghan(a)ICN.Siemens.com > > ------------------------------------------------------------------ > > > > > > -----Original Message----- > > From: Orit Levin [ mailto:orit@radvision.com <mailto:orit@radvision.com> ] > > Sent: Wednesday, June 14, 2000 11:45 AM > > To: Callaghan, Robert; 'Paul E. Jones' > > Cc: Mailing list for parties associated with ITU-T Study Group 16 > > (E-mail) > > Subject: Re: H.323 URL > > > > > > Hello Bob and Paul! > > I don't see backwards compatibility problem, when the URL > says explicitly > > H323-URL. An appropriate change may be to state, that the > default meaning > of > > url, encoded into email-ID alias, is according to RFC-822. > > Now, I feel a need to put a chapter explaining what is the > meaning of > email > > URL (apart from its syntax) when used in H.323 Network. > There is some > > explanation in H.225.0 Appendix IV. Do you find it clear > and sufficient? > > Orit Levin > > RADVision Inc. > > 575 Corporate Drive Suite 420 > > Mahwah, NJ 07430 > > Tel: 1 201 529 4300 (230) > > Fax: 1 201 529 3516 > > www.radvision.com > > orit(a)radvision.com > > -----Original Message----- > > From: Callaghan, Robert <Robert.Callaghan(a)icn.siemens.com> > > To: 'Paul E. Jones' <paulej(a)PACKETIZER.COM>; 'Orit Levin' > > <orit(a)radvision.com> > > Cc: Mailing list for parties associated with ITU-T Study > Group 16 (E-mail) > > <ITU-SG16(a)mailbag.cps.intel.com> > > Date: Wednesday, June 14, 2000 9:56 AM > > Subject: H.323 URL > > > > > > >Paul, > > > > > >I have a backward compatibility item for you to think about. > > > > > >TD-40/Osaka states that the H323-URL may be coded into the > email-ID for > > >alias address. However, H.225.0 states that the email-ID > shall conform > to > > >RFC822. This is an exclusionary requirement in that other > standards may > > not > > >be used. Also, Note 4 of the BNF definition of the > H323-URL clearly > states > > >that that the H323-URL is *not* compatible with RFC822. > > > > > >Therefor, I propose that the H323-URL cannot be coded into > the email-ID > for > > >alias address because of compatibility problems. > > > > > >Bob > > > > > >------------------------------------------------------------------ > > >Robert Callaghan > > >Siemens Enterprise Networks > > >Tel: +1.561.923.1756 Fax: +1.561.923.1403 > > >Email: Robert.Callaghan(a)ICN.Siemens.com > > >------------------------------------------------------------------ > > > > > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > For help on this mail list, send "HELP ITU-SG16" in a message to > listserv(a)mailbag.intel.com >

3 2

Re: TD-50/Osaka - Changes to the conferenceGoal field
by Callaghan, Robert 22 Jun '00

22 Jun '00

Pete, As you well know, for H.323 mandatory is in the eyes of the implementors. If an implementor does not think that they are useful for him then it won't be implemented. I think that Packages can be a useful service, but not mandatory. (I have yet to see a specific service to use Packages; but theoretically they are useful.) The problem is service that are mandatory, but have optional coding. Annex L has two coding formats in order to use v2 clients. I can seen some Packages services using the same technique - v4 uses Packages, v2 uses nonStandardControl. I would prefer a negotiation process like that for RAS negotiation - the originators asks for what is wanted, the response is what is available. Then the originators chooses what to do. If this is done, there is no need to mess with conferenceGoals. Bob ------------------------------------------------------------------ Robert Callaghan Siemens Enterprise Networks Tel: +1.561.923.1756 Fax: +1.561.923.1403 Email: Robert.Callaghan(a)ICN.Siemens.com ------------------------------------------------------------------ -----Original Message----- From: Pete Cordell [mailto:pete@TECH-KNOW-WARE.COM] Sent: Tuesday, June 20, 2000 2:01 PM To: ITU-SG16(a)mailbag.cps.intel.com Subject: Re: TD-50/Osaka - Changes to the conferenceGoal field Bob, You have made the perfect argument for leaving neededFeatures in the conferenceGoal! Previously we could say that support for packages was optional because we were relying on the conferenceGoal backwards compatibility method to work for V4 endpoints. This is because all the support packages need is to reject a call if neededFeatures is signalled. If we have to move neededFeatures to some other position, then packages MUST become MANDATORY, at least in terms of recognising that neededFeatures are present. I would imagine that you wouldn't like this. Pete. P.S. I believe you have expressed some concern that calls should be able to continue even if certain features are not supported which may be causing you to be worried about packages. This can be easily achieved with packages. Simply DON'T signal the features that you desire as neededFeatures, signal them as desiredFeatures. You then have the behaviour that you are looking for. The important thing here is that it gives the network architect the choice of the behaviour that should happen. Or should Siemens customers take what they're given and lump it :) ============================================= Pete Cordell Tech-Know-Ware pete(a)tech-know-ware.com +44 1473 635863 ============================================= ----- Original Message ----- From: Callaghan, Robert <Robert.Callaghan(a)ICN.SIEMENS.COM> To: <ITU-SG16(a)mailbag.cps.intel.com> Sent: 20 June 2000 14:53 Subject: Re: TD-50/Osaka - Changes to the conferenceGoal field > Rich, > > I agree that a v4 client that supports packages and further supports a > specific feature will respond. My comment is in regard to the generation of > a negative message indicating that the feature is not support. If a v4 > client supports packages but not a feature, it will resond with a negative > message. However if the v4 client does not support packages, it will not > respond at all. This is worse that the v2 or v3 clients if the change in > conferceGoals is made. Therefor, my idea is that the change in > conferenceGoal is not needed because than the v2, v3, and some v4 clients > will work the same. This allows the addition of coding of package > information to be anywhere other than conferenceGoal. > > Bob > > -----Original Message----- > From: Rich Bowen [mailto:rkbowen@cisco.com] > Sent: Tuesday, June 20, 2000 3:20 AM > To: Callaghan, Robert > Cc: 'Mailing list for parties associated with ITU-T Study Group 16' > Subject: Re: TD-50/Osaka - Changes to the conferenceGoal field > > > > Bob, > > If the v4 client supports the features listed in the needFeatures field, > then it will respond with those same features listed in a > supportedFeatures field, as an acknowledgement. Presumably if it > acknowledges features in this way, then it will not ignore packages > related to those features. > > Rich > > "Callaghan, Robert" wrote: > > > > Rich, > > > > I question that the concept for forcing conferenceGoal to fail will even > > work. > > > > The use of conferenceGoal will detect a v2 or v3 client through a failure. > > But the version number will also detect the older versions. A v4 client > can > > properly detect and decode the new structure. However, support of > packages > > is optional, so the client can ignore the requirement to evaluate the > > packages. > > > > Then what? > > > > Bob > > > > -----Original Message----- > > From: Rich Bowen [mailto:rkbowen@CISCO.COM] > > Sent: Sunday, June 18, 2000 5:14 PM > > To: ITU-SG16(a)mailbag.cps.intel.com > > Subject: TD-50/Osaka - Changes to the conferenceGoal field > > > > All, > > > > In Osaka we agreed to add support for packages to H.225.0 along the > > lines of TD-50 (ftp://standard.pictel.com/avc-site/0005_Osa/TD-50.zip) > > There was some concern raised about the proposed modifications to the > > conferenceGoal field in the Setup message. The meeting report states: > > > > "Some issues were raised about conflicts in the usage of the conference > > goal field between this new method and H.450.x. A possible solution is > > to create a new field in the ASN.1 to avoid conflicts. The editors are > > empowered to work with interested parties to resolve these conflicts in > > the ASN.1 before the white paper is issued." > > > > The modification proposed in TD-50 was the addition of the > > "neededFeatures" field to the confereceGoal field of the Setup-UUIE: > > > > conferenceGoal CHOICE > > { > > create NULL, > > join NULL, > > invite NULL, > > ..., > > capability-negotiation NULL, > > callIndependentSupplementaryService NULL, > > --> neededFeatures NeededFeatureGoal > > }, > > > > where the NeededFeatureGoal structure is defined as: > > > > NeededFeatureGoal ::= SEQUENCE > > { > > basicGoal CHOICE > > { > > create NULL, > > join NULL, > > invite NULL, > > capability-negotiation NULL, > > callIndependentSupplementaryService NULL, > > ... > > } OPTIONAL, > > features SEQUENCE OF SupportedFeatures, > > ... > > } > > > > An alternative approach would be to add a neededFeatures field at the > > highest level of the Setup-UUIE ASN.1 instead of inside the > > conferenceGoal structure, similar to the way the desirededFeatures and > > supportedFeatures fields will be added (see TD-50), like this: > > > > Setup-UUIE ::= SEQUENCE > > { > > [snip] > > --> neededFeatures SEQUENCE OF SupportedFeatures OPTIONAL, > > desiredFeatures SEQUENCE OF SupportedFeatures OPTIONAL, > > supportedFeatures SEQUENCE OF SupportedFeatures OPTIONAL > > } > > > > The motivation for adding neededFeatures to the conferenceGoal field was > > to force a call failure when trying to setup a call to pre-v4 endpoint > > and there is some v4 or later feature that is *required* for the call. > > The mechanism is intended to work like this: > > > > o The v4 EP sends Setup to the pre-v4 endpoint, and specifies some > > required feature in the neededFeatures field of the conferenceGoal. > > o The pre-v4 EP doesn't recognize the neededFeatures field as a > > supported CHOICE for a conferenceGoal, so it sends Release Complete. > > > > There would not be any conflicts with H.450, as suggested in the meeting > > report, because if the callIndependentSupplementaryService was needed, > > it would still be specified. The difference is that, if a neededFeature > > was also required, the H.450 goals would be specified inside the > > NeededFeatureGoal structure, which v4 and later endpoints would be aware > > of. > > > > These are the pros and cons of adding neededFeatures to the > > conferenceGoal vs. adding it to Setup-UUIE, IMO: > > o Advantages: > > - *May* force an early call release if a required feature is > > not supported by a pre-v4 endpoint. > > o Disadvantages: > > - ASN.1 and thus implementation would be more complex. > > Potentially have to check the conferenceGoal in two structures > > instead of one. > > - If pre-v4 EP sends Release Complete, there is no way to > > know whether it was sent because of an unrecognized > > conferenceGoal, because there is no ReleaseCompleteReason > > defined for that purpose. > > - H.323 does not require failing a call if the conferenceGoal > > is unrecognized, so the mechanism may not work at all. > > > > Although I think this mechanism is a good idea (and I supported it in > > Osaka), at this point I don't think it would work reliably enough to > > justify the added complexity. So I would prefer the alternative > > approach described above, adding the neededFeatures field directly to > > the Setup-UUIE. > > > > Okay, fire away. :-) > > > > Regards, > > Rich > > -------------------------------------------------------------------- > > Richard K. Bowen Cisco Systems, Inc. > > VoIP Session Protocols Research Triangle Park, NC, USA > > -------------------------------------------------------------------- > > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > For help on this mail list, send "HELP ITU-SG16" in a message to > > listserv(a)mailbag.intel.com > > -- > -------------------------------------------------------------------- > Richard K. Bowen Cisco Systems, Inc. > VoIP Session Protocols Research Triangle Park, NC, USA > -------------------------------------------------------------------- > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > 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

3 6

next revision of H.323 Annex H ?
by Kumar, Vineet 21 Jun '00

21 Jun '00

Jaakko, When is the next revision of H.323 Annex H draft scheduled to be out ? Regards, vineet ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

[robustness]Comments on TD-42/Osaka
by Rich Bowen 20 Jun '00

20 Jun '00

Robustness folks, A couple of comments on TD-42/Osaka - 1) While adding the ASN.1 from TD-42 to the draft H.225.0 v4, I noticed the following paragraph about using StatusInquiry as a keepalive mechanism: "The element closer to the called party shall send StatusInquiry periodically (this is the direction of least traffic during established calls). The period should be configurable. Two seconds is the recommended default, in order to allow detection of failure before other messages timeout. The selected value must be added to StatusInquiry so that the recipient can also monitor failure without an additional StatusInquiry/Status exchange in the opposite direction. The recipient system needs only to maintain a timer using the indicated value as a timeout." This clause indicates that the period at which StatusInquiry is sent is also the amount of time that the receiving system should use as a timeToLive timer. This arrangement would result in a race condition since the next StatusInquiry would be expected at the exact moment that the timeToLive timer was due to expire. IMHO, the StatusInquiry period and the timeToLive should be separately configurable, both having default values defined in Annex R, with the obvious restriction that timeToLive shall be greater than the StatusInquiry period. 2) Has consideration been given to adding the ability for the endpoint to indicate to the GK via the ARQ that a particular call requires robustness, or to allowing the GK to indicate to the EP that the EP must use the robustness procedure for a particular call? Several other features added in v4 use this model and it seems to be a useful framework. - Rich ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

2 4

[Fwd: Final Corrections to H.225.0v3]
by Rich Bowen 20 Jun '00

20 Jun '00

All, Paul Jones is having trouble with email access from home, where he does his standards work, and asked me if I could resend the attached email that he sent earlier. A couple of people have told him they did not see this on the itu-sg16 list. Rich -------------------------------------------------------------------- Richard K. Bowen Cisco Systems, Inc. VoIP Session Protocols Research Triangle Park, NC, USA --------------------------------------------------------------------

1 0

Re: TD-50/Osaka - Changes to the conferenceGoal field
by Callaghan, Robert 20 Jun '00

20 Jun '00

Rich, I agree that a v4 client that supports packages and further supports a specific feature will respond. My comment is in regard to the generation of a negative message indicating that the feature is not support. If a v4 client supports packages but not a feature, it will resond with a negative message. However if the v4 client does not support packages, it will not respond at all. This is worse that the v2 or v3 clients if the change in conferceGoals is made. Therefor, my idea is that the change in conferenceGoal is not needed because than the v2, v3, and some v4 clients will work the same. This allows the addition of coding of package information to be anywhere other than conferenceGoal. Bob -----Original Message----- From: Rich Bowen [mailto:rkbowen@cisco.com] Sent: Tuesday, June 20, 2000 3:20 AM To: Callaghan, Robert Cc: 'Mailing list for parties associated with ITU-T Study Group 16' Subject: Re: TD-50/Osaka - Changes to the conferenceGoal field Bob, If the v4 client supports the features listed in the needFeatures field, then it will respond with those same features listed in a supportedFeatures field, as an acknowledgement. Presumably if it acknowledges features in this way, then it will not ignore packages related to those features. Rich "Callaghan, Robert" wrote: > > Rich, > > I question that the concept for forcing conferenceGoal to fail will even > work. > > The use of conferenceGoal will detect a v2 or v3 client through a failure. > But the version number will also detect the older versions. A v4 client can > properly detect and decode the new structure. However, support of packages > is optional, so the client can ignore the requirement to evaluate the > packages. > > Then what? > > Bob > > -----Original Message----- > From: Rich Bowen [mailto:rkbowen@CISCO.COM] > Sent: Sunday, June 18, 2000 5:14 PM > To: ITU-SG16(a)mailbag.cps.intel.com > Subject: TD-50/Osaka - Changes to the conferenceGoal field > > All, > > In Osaka we agreed to add support for packages to H.225.0 along the > lines of TD-50 (ftp://standard.pictel.com/avc-site/0005_Osa/TD-50.zip) > There was some concern raised about the proposed modifications to the > conferenceGoal field in the Setup message. The meeting report states: > > "Some issues were raised about conflicts in the usage of the conference > goal field between this new method and H.450.x. A possible solution is > to create a new field in the ASN.1 to avoid conflicts. The editors are > empowered to work with interested parties to resolve these conflicts in > the ASN.1 before the white paper is issued." > > The modification proposed in TD-50 was the addition of the > "neededFeatures" field to the confereceGoal field of the Setup-UUIE: > > conferenceGoal CHOICE > { > create NULL, > join NULL, > invite NULL, > ..., > capability-negotiation NULL, > callIndependentSupplementaryService NULL, > --> neededFeatures NeededFeatureGoal > }, > > where the NeededFeatureGoal structure is defined as: > > NeededFeatureGoal ::= SEQUENCE > { > basicGoal CHOICE > { > create NULL, > join NULL, > invite NULL, > capability-negotiation NULL, > callIndependentSupplementaryService NULL, > ... > } OPTIONAL, > features SEQUENCE OF SupportedFeatures, > ... > } > > An alternative approach would be to add a neededFeatures field at the > highest level of the Setup-UUIE ASN.1 instead of inside the > conferenceGoal structure, similar to the way the desirededFeatures and > supportedFeatures fields will be added (see TD-50), like this: > > Setup-UUIE ::= SEQUENCE > { > [snip] > --> neededFeatures SEQUENCE OF SupportedFeatures OPTIONAL, > desiredFeatures SEQUENCE OF SupportedFeatures OPTIONAL, > supportedFeatures SEQUENCE OF SupportedFeatures OPTIONAL > } > > The motivation for adding neededFeatures to the conferenceGoal field was > to force a call failure when trying to setup a call to pre-v4 endpoint > and there is some v4 or later feature that is *required* for the call. > The mechanism is intended to work like this: > > o The v4 EP sends Setup to the pre-v4 endpoint, and specifies some > required feature in the neededFeatures field of the conferenceGoal. > o The pre-v4 EP doesn't recognize the neededFeatures field as a > supported CHOICE for a conferenceGoal, so it sends Release Complete. > > There would not be any conflicts with H.450, as suggested in the meeting > report, because if the callIndependentSupplementaryService was needed, > it would still be specified. The difference is that, if a neededFeature > was also required, the H.450 goals would be specified inside the > NeededFeatureGoal structure, which v4 and later endpoints would be aware > of. > > These are the pros and cons of adding neededFeatures to the > conferenceGoal vs. adding it to Setup-UUIE, IMO: > o Advantages: > - *May* force an early call release if a required feature is > not supported by a pre-v4 endpoint. > o Disadvantages: > - ASN.1 and thus implementation would be more complex. > Potentially have to check the conferenceGoal in two structures > instead of one. > - If pre-v4 EP sends Release Complete, there is no way to > know whether it was sent because of an unrecognized > conferenceGoal, because there is no ReleaseCompleteReason > defined for that purpose. > - H.323 does not require failing a call if the conferenceGoal > is unrecognized, so the mechanism may not work at all. > > Although I think this mechanism is a good idea (and I supported it in > Osaka), at this point I don't think it would work reliably enough to > justify the added complexity. So I would prefer the alternative > approach described above, adding the neededFeatures field directly to > the Setup-UUIE. > > Okay, fire away. :-) > > Regards, > Rich > -------------------------------------------------------------------- > Richard K. Bowen Cisco Systems, Inc. > VoIP Session Protocols Research Triangle Park, NC, USA > -------------------------------------------------------------------- > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > For help on this mail list, send "HELP ITU-SG16" in a message to > listserv(a)mailbag.intel.com -- -------------------------------------------------------------------- Richard K. Bowen Cisco Systems, Inc. VoIP Session Protocols Research Triangle Park, NC, USA -------------------------------------------------------------------- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

2 1

Re: H.323 URL
by Orit Levin 20 Jun '00

20 Jun '00

RE: H.323 URLBob, sorry for being unclear. This is why face-to-face discussions are, after all, more efficient. I agree with all (?) your points. What I wanted to say is, that H323-URL, in its current format, provides sufficient means for - originator's local application to activate H.323 application, while configured consistently within its zone policies - zone's server (most probably a GK.) to invoke DNS based address resolution procedure, based on the received H323-URL The current H323-URL definition and the proposed text are NOT sufficient (but BOTH are expandable) to provide more functionality to that, we have today, such as: - meaning of non-H323 URLs in H.323 messages and the corresponding procedures - H323-URL used in WEB pages when extensive configuration means are not available and/or not sufficient Now, to Chip's remarks. It seems to me helpful to add this kind of "url tutorial" to Annex O. After all, what may be seen obvious to the authors, is not necessarily obvious to the readers/implementers of H.323. Chip, I have a question to you. I send a request to IANA, as to the procedures to add the new H323-URL identifier. No answer so far. Any help/guidance would be appreciated. Regards, Orit Levin RADVision Inc. 575 Corporate Drive Suite 420 Mahwah, NJ 07430 Tel: 1 201 529 4300 (230) Fax: 1 201 529 3516 www.radvision.com orit(a)radvision.com -----Original Message----- From: Callaghan, Robert <Robert.Callaghan(a)ICN.SIEMENS.COM> To: ITU-SG16(a)MAILBAG.INTEL.COM <ITU-SG16(a)MAILBAG.INTEL.COM> Date: Monday, June 19, 2000 2:51 PM Subject: Re: H.323 URL Orit, I am not now sure what was agreed to, other that to let TD-40a to move forward. I do agree with the three points in your note. I do not agree that the proposal was limited to Call Control Messages. I see no difference between the use of H.323-URLs on a Web page and the use of H.3233-URLs in Call Control. The one directly leads to the latter. I am not sure if you are implying that only H.323-URL can be used to direct a call to an H.323 destination. If so, I disagree. All alias formats work equally well. My understanding is that Paul Jones wanted the E.164 format of the H.323-URL in order to access the gateway using the H.323 client as a telephony client. This definitely does not point to an H.323 URL. I am afraid that we may not know what we agreed to, other than to proceed. That is why I objected that the URL be included in v4 instead of and annex or appendix. Now our lack of understanding as to what we understood will jeprodice v4 if it remains as is. But that was the agreement, so we must proceed forward. Bob -----Original Message----- From: Orit Levin [mailto:orit@radvision.com] Sent: Monday, June 19, 2000 10:06 AM To: ITU-SG16(a)mailbag.cps.intel.com Subject: Re: H.323 URL Dear all! There are two faces to H323-URL. The first one is when H.323-URL is used as an alias in H.323 Call Control messages. The second is when H.323-URL is used in Web pages or other hyperlinks. (Although, when both are in place, from procedural point of view their order is vice versa.) In my contribution in Osaka, I chose to address "the first case" first. There are number reasons for this: 1. URL concept exists in H.323 since version 2. The procedures, how URLs should be used, haven't been defined. This clearly invites interoperability problems. 2. H323-URL hasn't been defined at all. This leads to interpretation of other URLs, to be used INSTEAD, while reaching pure H.323 entities! This clearly invites interoperability problems. 3. Standard H323-URL can greatly facilitate address translation procedure, when H.323 runs on Internet. As it can be seen from TD-40a, it has been agreed, that H323-URL should be used to POINT TO H.323 DESTINATION. Other URLs may/should be used in H.323 messages to point to other destinations. Personally, I see this approach as the best. Also Bob and Francoise supported this in their last e-mails. Please, lets try not to open already agreed things before the next meeting, jeopardizing by that H.323v4 decision. Specifically on H323-URL topic, we have to clean things (such as the use of email ID alias) and put the basic version onto H.323v4. Then we will have "Annex O" to expand on additional "complimentary to H.323" procedures. One of these procedures is "the second face" of H323-URL: while used in WEB pages. It is clear that H.323-URL should be expanded with additional parameters to be used as such. It is also mentioned in TD-40a. Contributions are mostly welcome. Best Regards, Orit Levin RADVision Inc. 575 Corporate Drive Suite 420 Mahwah, NJ 07430 Tel: 1 201 529 4300 (230) Fax: 1 201 529 3516 www.radvision.com orit(a)radvision.com -----Original Message----- From: Paul E. Jones <paulej(a)PACKETIZER.COM> To: ITU-SG16(a)MAILBAG.INTEL.COM <ITU-SG16(a)MAILBAG.INTEL.COM> Date: Monday, June 19, 2000 3:27 AM Subject: Re: H.323 URL Francois, If I want to provide a means of allowing somebody to call me by placing a URL on a web page, I need to provide something that can be resolved universally by H.323 endpoints. Bob mentioned querying a database-- that's certainly a possibility, assuming that that database contains all of the information it needs to resolve an address. What I am afraid of here is that we are introducing syntax to reach a resource without defining any procedure. If I see this url: h323:paulej@packetizer.com What does that tell the H.323 entity? Is there a GK that is expecting a LRQ, AccessRequest, or is it something else entirely? Perhaps the right solution is to define (in normative text) the procedure for using SRV DNS records to query the packetizer.com domain. As Pete rightfully pointed out, an H.323 URL would be the perfect place to place conference identifiers for multipoint conferences: h323:conf-server1@packetizer.com;cid:XXXX-XXXX-XXXX-XXXX I think we need to work on the procedural part of this now. Who is working on that? Paul ----- Original Message ----- From: Francois Audet To: ITU-SG16(a)mailbag.cps.intel.com Sent: Friday, June 16, 2000 11:48 AM Subject: Re: H.323 URL I would agree with Bob here. Using an H.323 URL for a telephone number would imply that you can only be reached using H.323. Is this you intention? > -----Original Message----- > From: Callaghan, Robert [mailto:Robert.Callaghan@ICN.SIEMENS.COM] > Sent: Friday, June 16, 2000 5:39 AM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: Re: H.323 URL > > > Paul, > > I think that this is getting complicated. > > I did not envision the use of the H.323-URL to encompase a > telephone number. > I only conceede for the purpose of progress. > > I saw the H.323-URL to be an identifier that would be used to access a > database. The DNS portion would identify the database, the > userID would be > the entry in the database. The database would then return > the necessary > information to complete the call. It is highly propable that this > information would include an E.164 or PNP address. This is > especially true > when the call must be ompleted over the SCN. > > I saw telephone numbers being defined in the "Tel:" URL > defined in RFC2806. > This URL covers many of optional fields needed to make an SCN > call which are > not presently covered in H.323. > > If we are to have multiple forms of an H.323 URL, I would > prefer to have > multi-URL IDs. > > Bob > > P.S. (By the way, the complex, cover everything, is where the > last try at an > H.323 URL diaappeared.) > > ------------------------------------------------------------------ > Robert Callaghan > Siemens Enterprise Networks > Tel: +1.561.923.1756 Fax: +1.561.923.1403 > Email: Robert.Callaghan(a)ICN.Siemens.com > ------------------------------------------------------------------ > > > -----Original Message----- > From: Paul E. Jones [mailto:paulej@packetizer.com] > Sent: Friday, June 16, 2000 3:11 AM > To: Callaghan, Robert; 'Orit Levin' > Cc: Mailing list for parties associated with ITU-T Study Group 16 > (E-mail) > Subject: Re: H.323 URL > > > Bob, > > I'm still surprised that you don't want to see the URL expanded... > especially to address party number types. Here is is currently: > > H323-URL = "H323:" user ["@" hostport] > user = username | phone-number > username = *( unreserved | escaped | "&" | "=" | "+" > | "$" | "," ) > hostport = host [ ":" port ] > host = hostname | IPv4address > hostname = *( domainlabel "." ) toplabel [ "." ] > domainlabel = alphanum | alphanum *( alphanum | "-" ) alphanum > toplabel = alpha | alpha *( alphanum | "-" ) alphanum > IPv4address = 1*digit "." 1*digit "." 1*digit "." 1*digit > port = *digit > reserved = ";" | "/" | "?" | ":" | "@" | "&" | "=" | > "+" |"$" | "," > digits = 1*DIGIT > > However, to be useful, information that follows the "h323:" should be > something in a form that an H.323 Gatekeeper can resolve. > Those things > include: > dialedDigits > h323-ID > email-ID > partyNumber > or one of the transportAddress types. > > This seems to be a reasonable syntax: > > H323-URL = "H323:" Address > Address = AliasAddress / TransportAddress > AliasAddress = dialedDigits / h323-ID / email-ID / partyNumber > dialedDigits = "dialedDigits=" 1*digit > h323-ID = "h323-ID=" 1*OCTET ; UTF-8 string represting the > BMPString > email-ID = "email-ID=" email-ID-spec > partyNumber = e164Number / dataPartyNumber / telexPartyNumber / > privateNumber > / nationalStandardPartyNumber > email-ID-spec = mailbox / group > group = phrase ":" [ mailbox ] ";" > phrase = 1*word > word = atom / quoted-string > atom = 1*CHAR ; any CHAR except specials, SPACE and CTLs > specials = "(" / ")" / "<" / ">" / "@" ; Must be in quoted- > / "," / ";" / ":" / "\" / <"> ; string, to use > / "." / "[" / "]" ; within a word. > quoted-string = > mailbox = addr-spec / phrase route-addr > addr-spec = local-part "@" domain > local-part = word *("." word) > domain = sub-domain *("." sub-domain) > sub-domain = domain-ref / domain-literal > domain-ref = atom > domain-literal = "[" *(dtext / quoted-pair) "]" > dtext = 1*CHAR ; Any CHAR excluding "[", "]", "\" & CR, > ; & including linear-white-space> > linear-white-space = 1*([CRLF] LWSP-char) > LWSP-char = SP / HTAB > quoted-pair = "\" CHAR > phrase = 1*word > route-addr = "<" [route] addr-spec ">" > route = "@" domain ":" > e164Number = "e164Number=" publicTypeOfNumber "," digits > digits = 1*(DIGIT / "#" / "*" / ",") > publicTypeOfNumber = "unknown" / "internationalStandard" / > "nationalNumber" > / "networkSpecificNumber" / "subscriberNumber" / > / "abbreviatedNumber" > dataPartyNumber = "dataPartyNumber=" digits > telexPartyNumber= "telexPartyNumber=" digits > privatePartyNumber = "privatePartyNumber=" > privateTypeOfNumber "," digits > privateTypeOfNumber = "unknown" / "level2RegionalNumber" / > "level1RegionalNumber" > / "pISNSpecificNumber" / "localNumber" / > "abbreviatedNumber" > TransportAddress = ipAddress / ipSourceRoute / ipxAddress / ip6Address > / netBios / nsap / nonStandardAddress > ipAddress = ip ":" port > ip = 1*DIGIT "." 1*DIGIT "." 1*DIGIT "." 1*DIGIT > port = 1*DIGIT > ipSourceRoute = ip ":" port "," ip *1("," ip) ";" ("strict" > / "loose") > ipxAddress = 1*DIGIT ":" 1*DIGIT ":" 1*DIGIT > ip6Address = 1*HEXDIGIT 14*(":" [1*HEXDIGIT]) 1*HEXDIGIT > HEXDIGIT = DIGIT / "A" / "B" / "C" / "D" / "E" / "F" > netBios = ;; and so forth > nsap = > nonStandardAddress = > > Now, there may be an error or two in there, but at least it > is more complete > and an H.323 system knows how to work with these. (Note I > did not address > the new V4 alias "mobileIUM") > > If we used this grammar, I don't think we would need a lot of > strange rules > about what you do with the URL. Basically, you take it apart > according to > its internal parts to form an alias address that a Gatekeeper > can resolve. > > Paul > > ----- Original Message ----- > From: "Callaghan, Robert" <Robert.Callaghan(a)icn.siemens.com> > To: "'Orit Levin'" <orit(a)radvision.com>; "'Paul E. Jones'" > <paulej(a)PACKETIZER.COM> > Cc: "Mailing list for parties associated with ITU-T Study > Group 16 (E-mail)" > <ITU-SG16(a)mailbag.cps.intel.com> > Sent: Wednesday, June 14, 2000 3:50 PM > Subject: RE: H.323 URL > > > > Orit, > > > > In my opinion, an email-ID alias conforms to RFC-822 and is > interpreted > > according the rules stated in H.225.0. An H.323-URL-ID conforms to > > TD-40a/Osaka and is interpreted according to the rules > stated in TD-40a. > An > > H.323-ID is a character string without any rules of > interpretation. I see > > no need to blend these contexts. All three addressing > modes can be use; > > each in its own context. > > > > However, these are my opinion. Maybe more work is needed > in Portland. > > > > Bob > > > > ------------------------------------------------------------------ > > Robert Callaghan > > Siemens Enterprise Networks > > Tel: +1.561.923.1756 Fax: +1.561.923.1403 > > Email: Robert.Callaghan(a)ICN.Siemens.com > > ------------------------------------------------------------------ > > > > > > -----Original Message----- > > From: Orit Levin [mailto:orit@radvision.com] > > Sent: Wednesday, June 14, 2000 11:45 AM > > To: Callaghan, Robert; 'Paul E. Jones' > > Cc: Mailing list for parties associated with ITU-T Study Group 16 > > (E-mail) > > Subject: Re: H.323 URL > > > > > > Hello Bob and Paul! > > I don't see backwards compatibility problem, when the URL > says explicitly > > H323-URL. An appropriate change may be to state, that the > default meaning > of > > url, encoded into email-ID alias, is according to RFC-822. > > Now, I feel a need to put a chapter explaining what is the > meaning of > email > > URL (apart from its syntax) when used in H.323 Network. > There is some > > explanation in H.225.0 Appendix IV. Do you find it clear > and sufficient? > > Orit Levin > > RADVision Inc. > > 575 Corporate Drive Suite 420 > > Mahwah, NJ 07430 > > Tel: 1 201 529 4300 (230) > > Fax: 1 201 529 3516 > > www.radvision.com > > orit(a)radvision.com > > -----Original Message----- > > From: Callaghan, Robert <Robert.Callaghan(a)icn.siemens.com> > > To: 'Paul E. Jones' <paulej(a)PACKETIZER.COM>; 'Orit Levin' > > <orit(a)radvision.com> > > Cc: Mailing list for parties associated with ITU-T Study > Group 16 (E-mail) > > <ITU-SG16(a)mailbag.cps.intel.com> > > Date: Wednesday, June 14, 2000 9:56 AM > > Subject: H.323 URL > > > > > > >Paul, > > > > > >I have a backward compatibility item for you to think about. > > > > > >TD-40/Osaka states that the H323-URL may be coded into the > email-ID for > > >alias address. However, H.225.0 states that the email-ID > shall conform > to > > >RFC822. This is an exclusionary requirement in that other > standards may > > not > > >be used. Also, Note 4 of the BNF definition of the > H323-URL clearly > states > > >that that the H323-URL is *not* compatible with RFC822. > > > > > >Therefor, I propose that the H323-URL cannot be coded into > the email-ID > for > > >alias address because of compatibility problems. > > > > > >Bob > > > > > >------------------------------------------------------------------ > > >Robert Callaghan > > >Siemens Enterprise Networks > > >Tel: +1.561.923.1756 Fax: +1.561.923.1403 > > >Email: Robert.Callaghan(a)ICN.Siemens.com > > >------------------------------------------------------------------ > > > > > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > For help on this mail list, send "HELP ITU-SG16" in a message to > listserv(a)mailbag.intel.com >

2 1

static vs dynamic configuration
by Agboh, Charles 20 Jun '00

20 Jun '00

I am not sure if this is the place to ask this question but I would like some comments on the following. in a static configuration I have H.323 gateways deployed with no gatekeeper in a dynamic configuration I have the static configuation with a gatekeeper. What are the advantages of the dynamic configuration over the static configuration. regards, charles ---------------------------- Charles Keli Agboh Data and Access R&D - GTS Network Services Terhulpsesteenweg 6A 1560 Hoeilaart (Brussels) Belgium Direct: +32 2 658 4243 Mobile: +32 479 28 97 35 Fax: +32 2 700 43 66 Email: charles.agboh(a)gtsgroup.com http://www.gtsgroup.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

2 1

AW: TD-50/Osaka - Changes to the conferenceGoal field
by Klaghofer Karl ICN EN HC SE 81 20 Jun '00

20 Jun '00

H.323 procedures and H.450.1 procedures reference H.225.0 on how to set the conferenceGoal for certain cases (e.g. for conference invitations, 450 call independent signalling connections, ...). So far there is exactly one field to be used for setting the appropriate value. With the original BT proposal, we would suddenly in v4 have two ways on how to set the conferenceGoal (depending on whether I send the new v4 optional neededFeatures package or not). Again, we should go with the alternative proposal provided by Rich keeping the optional neededFeatures package out of the conferenceGoal construct. It does not belong there. The guideline has always been that new optional features shall not impact existing behaviour. Karl Klaghofer Siemens karl.klaghofer(a)icn.siemens.de > -----Ursprüngliche Nachricht----- > Von: Rich Bowen [SMTP:rkbowen@CISCO.COM] > Gesendet am: Tuesday, June 20, 2000 09:20 > An: ITU-SG16(a)mailbag.cps.intel.com > Betreff: Re: TD-50/Osaka - Changes to the conferenceGoal field > > Bob, > > If the v4 client supports the features listed in the needFeatures field, > then it will respond with those same features listed in a > supportedFeatures field, as an acknowledgement. Presumably if it > acknowledges features in this way, then it will not ignore packages > related to those features. > > Rich > > "Callaghan, Robert" wrote: > > > > Rich, > > > > I question that the concept for forcing conferenceGoal to fail will even > > work. > > > > The use of conferenceGoal will detect a v2 or v3 client through a > failure. > > But the version number will also detect the older versions. A v4 client > can > > properly detect and decode the new structure. However, support of > packages > > is optional, so the client can ignore the requirement to evaluate the > > packages. > > > > Then what? > > > > Bob > > > > -----Original Message----- > > From: Rich Bowen [mailto:rkbowen@CISCO.COM] > > Sent: Sunday, June 18, 2000 5:14 PM > > To: ITU-SG16(a)mailbag.cps.intel.com > > Subject: TD-50/Osaka - Changes to the conferenceGoal field > > > > All, > > > > In Osaka we agreed to add support for packages to H.225.0 along the > > lines of TD-50 (ftp://standard.pictel.com/avc-site/0005_Osa/TD-50.zip) > > There was some concern raised about the proposed modifications to the > > conferenceGoal field in the Setup message. The meeting report states: > > > > "Some issues were raised about conflicts in the usage of the conference > > goal field between this new method and H.450.x. A possible solution is > > to create a new field in the ASN.1 to avoid conflicts. The editors are > > empowered to work with interested parties to resolve these conflicts in > > the ASN.1 before the white paper is issued." > > > > The modification proposed in TD-50 was the addition of the > > "neededFeatures" field to the confereceGoal field of the Setup-UUIE: > > > > conferenceGoal CHOICE > > { > > create NULL, > > join NULL, > > invite NULL, > > ..., > > capability-negotiation NULL, > > callIndependentSupplementaryService NULL, > > --> neededFeatures NeededFeatureGoal > > }, > > > > where the NeededFeatureGoal structure is defined as: > > > > NeededFeatureGoal ::= SEQUENCE > > { > > basicGoal CHOICE > > { > > create NULL, > > join NULL, > > invite NULL, > > capability-negotiation NULL, > > callIndependentSupplementaryService NULL, > > ... > > } OPTIONAL, > > features SEQUENCE OF SupportedFeatures, > > ... > > } > > > > An alternative approach would be to add a neededFeatures field at the > > highest level of the Setup-UUIE ASN.1 instead of inside the > > conferenceGoal structure, similar to the way the desirededFeatures and > > supportedFeatures fields will be added (see TD-50), like this: > > > > Setup-UUIE ::= SEQUENCE > > { > > [snip] > > --> neededFeatures SEQUENCE OF SupportedFeatures OPTIONAL, > > desiredFeatures SEQUENCE OF SupportedFeatures OPTIONAL, > > supportedFeatures SEQUENCE OF SupportedFeatures OPTIONAL > > } > > > > The motivation for adding neededFeatures to the conferenceGoal field was > > to force a call failure when trying to setup a call to pre-v4 endpoint > > and there is some v4 or later feature that is *required* for the call. > > The mechanism is intended to work like this: > > > > o The v4 EP sends Setup to the pre-v4 endpoint, and specifies some > > required feature in the neededFeatures field of the conferenceGoal. > > o The pre-v4 EP doesn't recognize the neededFeatures field as a > > supported CHOICE for a conferenceGoal, so it sends Release Complete. > > > > There would not be any conflicts with H.450, as suggested in the meeting > > report, because if the callIndependentSupplementaryService was needed, > > it would still be specified. The difference is that, if a neededFeature > > was also required, the H.450 goals would be specified inside the > > NeededFeatureGoal structure, which v4 and later endpoints would be aware > > of. > > > > These are the pros and cons of adding neededFeatures to the > > conferenceGoal vs. adding it to Setup-UUIE, IMO: > > o Advantages: > > - *May* force an early call release if a required feature is > > not supported by a pre-v4 endpoint. > > o Disadvantages: > > - ASN.1 and thus implementation would be more complex. > > Potentially have to check the conferenceGoal in two structures > > instead of one. > > - If pre-v4 EP sends Release Complete, there is no way to > > know whether it was sent because of an unrecognized > > conferenceGoal, because there is no ReleaseCompleteReason > > defined for that purpose. > > - H.323 does not require failing a call if the conferenceGoal > > is unrecognized, so the mechanism may not work at all. > > > > Although I think this mechanism is a good idea (and I supported it in > > Osaka), at this point I don't think it would work reliably enough to > > justify the added complexity. So I would prefer the alternative > > approach described above, adding the neededFeatures field directly to > > the Setup-UUIE. > > > > Okay, fire away. :-) > > > > Regards, > > Rich > > -------------------------------------------------------------------- > > Richard K. Bowen Cisco Systems, Inc. > > VoIP Session Protocols Research Triangle Park, NC, USA > > -------------------------------------------------------------------- > > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > For help on this mail list, send "HELP ITU-SG16" in a message to > > listserv(a)mailbag.intel.com > > -- > -------------------------------------------------------------------- > Richard K. Bowen Cisco Systems, Inc. > VoIP Session Protocols Research Triangle Park, NC, USA > -------------------------------------------------------------------- > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > 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

Re: TD-54a/Osaka: New ReleaseCompleteReason for Annex M?
by Rich Bowen 20 Jun '00

20 Jun '00

I was thinking that Table 5 was an exhaustive mapping of all ReleaseCompleteReasons to Q.931 causes, but I see now that there are a couple of exceptions. So unless there are other suggestions, perhaps I can leave this mapping as an exercise for the Annex M.3 (DSS1 tunnelling) editor :-) - Rich Pete Cordell wrote: > > Shouldn't the releaseCompleteReason be mapped to a cause in defined for the > protocol that is being tunnelled rather than Q.931. i.e. for M.1 it should > map to an ISUP cause. If that's the case, changes to Table 5 are not > needed. > > Pete. > > ============================================= > Pete Cordell > Tech-Know-Ware > pete(a)tech-know-ware.com > +44 1473 635863 > ============================================= > > ----- Original Message ----- > From: Klaghofer Karl ICN SIB NL D1 <Karl.Klaghofer(a)ICN.SIEMENS.DE> > To: <ITU-SG16(a)mailbag.cps.intel.com> > Sent: 19 June 2000 10:48 > Subject: AW: TD-54a/Osaka: New ReleaseCompleteReason for Annex M? > > Rich, > > A new tunneling specific H.225.0 ReleaseCompleteReason would be valuable to > be received at an ingress GWY from the egress GWY. > > However, regarding SCN mapping rules of such a new ReleaseCompleteReason to > Cause IE, I do not like any of the proposed values: > > * Cause 88 "incompatible destination" is not suitable. > * Cause 111 "Interworking, unspecified" would sound good. However, in > case of Annex M1, a QSIG PINX would interpret Cause 111 as "Protocol error, > unspecified" (this is what Cause 111 is defined in QSIG). > * Cause 63 is not really suitable since tunneling is not a service or > option requested by the SCN (e.g. QSIG side). > > Regards, > Karl > > -----Ursprüngliche Nachricht----- > > Von: Rich Bowen [SMTP:rkbowen@CISCO.COM] > > Gesendet am: Monday, June 19, 2000 00:22 > > An: ITU-SG16(a)mailbag.cps.intel.com > > Betreff: TD-54a/Osaka: New ReleaseCompleteReason for Annex M? > > > > Mr. Holm and others, > > > > In Osaka it was suggested during the discussion of TD-54a (Draft Annex > > M.2, ISUP tunneling) that a new ReleaseCompleteReason is needed to > > support tunnelling. The reason would indicate that the called endpoint > > is dropping the call because it rejects tunnelling and the > > tunnellingRequired flag was set in the Setup message. > > > > My notes indicate that I was to look into whether this was needed in > > H.225.0 v4. The existing reasons are: > > > > ReleaseCompleteReason ::= CHOICE > > { > > noBandwidth NULL, -- bandwidth taken > > away or ARQ denied > > gatekeeperResources NULL, -- exhausted > > unreachableDestination NULL, -- no transport path > > to the destination > > destinationRejection NULL, -- rejected at > > destination > > invalidRevision NULL, > > noPermission NULL, -- called party's > > gatekeeper rejects > > unreachableGatekeeper NULL, -- terminal cannot > > reach gatekeeper > > for ARQ > > gatewayResources NULL, > > badFormatAddress NULL, > > adaptiveBusy NULL, -- call is dropping > > due to LAN crowding > > inConf NULL, -- no address in > > AlternativeAddress > > undefinedReason NULL, > > ..., > > facilityCallDeflection NULL, -- call was deflected > > using a Facility > > message > > securityDenied NULL, -- incompatible > > security settings > > calledPartyNotRegistered NULL, -- used by gatekeeper > > when endpoint has > > -- preGrantedARQ to > > bypass ARQ/ACF > > callerNotRegistered NULL, -- used by gatekeeper > > when endpoint has > > -- preGrantedARQ to > > bypass ARQ/ACF > > newConnectionNeeded NULL, -- indicates that > > the Setup was not > > accepted on this > > -- connection, but > > that the Setup may > > be accepted on > > -- a new connection > > nonStandardReason NonStandardParameter, > > replaceWithConferenceInvite ConferenceIdentifier > > -- call dropped due > > to subsequent > > -- invitation to a > > conference > > -- (see H.323 8.4.3.8) > > } > > > > So I'll ask ... is a new reason needed? > > > > If so, Mr. Holm's draft contains an editor's note that suggests a reason > > code of "tunnelRejected". Should I incorporate that value as a > > ReleaseCompleteReason? > > > > If so, what Q.931/Q.850 mapping should I add to Table 5/H.225.0 for this > > reason? Some suggestions: > > > > 63 - Service or option not available, unspecified > > 88 - Incompatible destination > > 111 - Interworking, unspecified > > > > Thanks, > > Rich > > -------------------------------------------------------------------- > > Richard K. Bowen Cisco Systems, Inc. > > VoIP Session Protocols Research Triangle Park, NC, USA > > -------------------------------------------------------------------- > > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > 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 -- -------------------------------------------------------------------- Richard K. Bowen Cisco Systems, Inc. VoIP Session Protocols Research Triangle Park, NC, USA -------------------------------------------------------------------- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

Re: TD-50/Osaka - Changes to the conferenceGoal field
by Callaghan, Robert 20 Jun '00

20 Jun '00

Rich, I question that the concept for forcing conferenceGoal to fail will even work. The use of conferenceGoal will detect a v2 or v3 client through a failure. But the version number will also detect the older versions. A v4 client can properly detect and decode the new structure. However, support of packages is optional, so the client can ignore the requirement to evaluate the packages. Then what? Bob -----Original Message----- From: Rich Bowen [mailto:rkbowen@CISCO.COM] Sent: Sunday, June 18, 2000 5:14 PM To: ITU-SG16(a)mailbag.cps.intel.com Subject: TD-50/Osaka - Changes to the conferenceGoal field All, In Osaka we agreed to add support for packages to H.225.0 along the lines of TD-50 (ftp://standard.pictel.com/avc-site/0005_Osa/TD-50.zip) There was some concern raised about the proposed modifications to the conferenceGoal field in the Setup message. The meeting report states: "Some issues were raised about conflicts in the usage of the conference goal field between this new method and H.450.x. A possible solution is to create a new field in the ASN.1 to avoid conflicts. The editors are empowered to work with interested parties to resolve these conflicts in the ASN.1 before the white paper is issued." The modification proposed in TD-50 was the addition of the "neededFeatures" field to the confereceGoal field of the Setup-UUIE: conferenceGoal CHOICE { create NULL, join NULL, invite NULL, ..., capability-negotiation NULL, callIndependentSupplementaryService NULL, --> neededFeatures NeededFeatureGoal }, where the NeededFeatureGoal structure is defined as: NeededFeatureGoal ::= SEQUENCE { basicGoal CHOICE { create NULL, join NULL, invite NULL, capability-negotiation NULL, callIndependentSupplementaryService NULL, ... } OPTIONAL, features SEQUENCE OF SupportedFeatures, ... } An alternative approach would be to add a neededFeatures field at the highest level of the Setup-UUIE ASN.1 instead of inside the conferenceGoal structure, similar to the way the desirededFeatures and supportedFeatures fields will be added (see TD-50), like this: Setup-UUIE ::= SEQUENCE { [snip] --> neededFeatures SEQUENCE OF SupportedFeatures OPTIONAL, desiredFeatures SEQUENCE OF SupportedFeatures OPTIONAL, supportedFeatures SEQUENCE OF SupportedFeatures OPTIONAL } The motivation for adding neededFeatures to the conferenceGoal field was to force a call failure when trying to setup a call to pre-v4 endpoint and there is some v4 or later feature that is *required* for the call. The mechanism is intended to work like this: o The v4 EP sends Setup to the pre-v4 endpoint, and specifies some required feature in the neededFeatures field of the conferenceGoal. o The pre-v4 EP doesn't recognize the neededFeatures field as a supported CHOICE for a conferenceGoal, so it sends Release Complete. There would not be any conflicts with H.450, as suggested in the meeting report, because if the callIndependentSupplementaryService was needed, it would still be specified. The difference is that, if a neededFeature was also required, the H.450 goals would be specified inside the NeededFeatureGoal structure, which v4 and later endpoints would be aware of. These are the pros and cons of adding neededFeatures to the conferenceGoal vs. adding it to Setup-UUIE, IMO: o Advantages: - *May* force an early call release if a required feature is not supported by a pre-v4 endpoint. o Disadvantages: - ASN.1 and thus implementation would be more complex. Potentially have to check the conferenceGoal in two structures instead of one. - If pre-v4 EP sends Release Complete, there is no way to know whether it was sent because of an unrecognized conferenceGoal, because there is no ReleaseCompleteReason defined for that purpose. - H.323 does not require failing a call if the conferenceGoal is unrecognized, so the mechanism may not work at all. Although I think this mechanism is a good idea (and I supported it in Osaka), at this point I don't think it would work reliably enough to justify the added complexity. So I would prefer the alternative approach described above, adding the neededFeatures field directly to the Setup-UUIE. Okay, fire away. :-) Regards, Rich -------------------------------------------------------------------- Richard K. Bowen Cisco Systems, Inc. VoIP Session Protocols Research Triangle Park, NC, USA -------------------------------------------------------------------- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 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

V.18 and H.248 Annex F: Documents for Q9/16 meeting in Edinburgh
by Gunnar Hellstrom 20 Jun '00

20 Jun '00

For the coming ITU-T Q9/16 meeting in Edinburgh June 28-30, I have uploaded the Q9 documents to the ITU Informal ftp site ties.itu.int/tsg16/sg16/wp1/q9/00-06_Edinburgh As well as www.omnitor.se/English/standards The documents are: ------------------ q09160001 Agenda and schedule q09160002 V.18 Text telephone modem, version 3, white document candidate q09160003 H.248 Annex F, Facsimile, Text conversation and Call discrimination packages, white doc candidate. Regards ------------------------------------------ Gunnar Hellstrom LM Ericsson E-mail gunnar.hellstrom(a)omnitor.se Tel +46 8 556 002 03 Mob +46 708 204 288 fax +46 8 556 002 06 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

Re: H.323 URL
by Callaghan, Robert 19 Jun '00

19 Jun '00

Chip, Thanks for the clarification as to how a URL works. Bob -----Original Message----- From: Chip Sharp [mailto:chsharp@CISCO.COM] Sent: Monday, June 19, 2000 1:44 PM To: ITU-SG16(a)mailbag.cps.intel.com Subject: Re: H.323 URL A few observations on the current proposal for an H.323 URL: URL Registration: If you want to define a new URL (i.e., H323:), please consider if you want a new registration tree for ITU or if you want to use the IETF registration tree. You might want to start an ITU registration tree, or even a ITU-SG16 registration subtree with IANA. See ftp://ftp.isi.edu/in-notes/bcp/bcp35.txt (BCP35) for more info on what I mean. Principle of "least surprise": If you click on the URL above for BCP35 you will probably expect your mail application to open an ftp application and download the file to your computer. If I click on a URL "telnet://foo.bar.com" I'd expect a telnet application to open that would telnet me to "foo.bar.com". I would expect an H.323 URL to do the same thing. For example if I click on the URL "h323:paulej@packetizer.com" given below, I would expect my H.323 application to open and attempt to call Paul using the address given (paulej(a)packetizer.com) My H.323 app would have to be configured with certain default parameters for operation (e.g., voice call, G.711 codec, etc.) as well as default operation for resolving the name to an IP address (e.g., use DNS to find the gatekeeper based on "packetizer.com" and use the identified gatekeeper to find Paul's IP address based on "paulej"). These may be defined in the H.323 URL definition. If you want H.323 URL to be used ubiquitously by end-users I'd recommend making its operation as simple as possible and as close as possible to other URLs. See Section 2 of ftp://ftp.isi.edu/in-notes/rfc2543.txt for how the SIP URL is defined as an example. email-id: I'm assuming when saying something should be in format defined in RFC822 that you mean the "addr-spec" production as defined in Appendix D of RFC822 since RFC822 also defines all the mail headers used in SMTP. I believe an H.323 URL could be encoded to be consistent with RFC822, but you have to take into account the escaping of special characters (e.g., ":" and "/") as well as semantics. I noticed the ABNF in one of the emails below substantially copies from RFC822 the definition of "addr-spec". If you do this, you might want to check the procedures for copying text from IETF RFCs as defined in A.5. What field to use: IMHO the only field a URL should be put into is the URL-id field. A URL is self-identifying in terms of application (e.g., "mailto:" -> email, "ftp:" -> FTP, "http:" -> HTTP, etc.). Putting a URL into one of the other fields would require careful definition of the interaction of the semantics of the field name and the URL type. Of course, there may be advantages of putting URLs into other fields that I'm not aware of. ABNF reference: To be consistent with other recommendations (e.g., H.248), reference ftp://ftp.isi.edu/in-notes/bcp/rfc2234.txt (RFC2234) for the definition of ABNF instead of RFC822. This is the IETF Standards Track RFC defining ABNF. Also, a nit about the ABNF in TD40 is that RFC2234 (and RFC822) use a "/" instead of "|" to denote a choice. This is a common mistake. KISS principle: Related to principle of least surprise, I'll echo Bob's concern buried in this thread that making the URL too complex (especially at the front end) will minimize its usefulness. A user should have the same level of expectation of what will happen if they click on an H.323 URL as they do for a HTTP URL. Chip At 03:15 AM 6/19/00 -0400, Paul E. Jones wrote: >Francois, > >If I want to provide a means of allowing somebody to call me by placing a >URL on a web page, I need to provide something that can be resolved >universally by H.323 endpoints. Bob mentioned querying a database-- >that's certainly a possibility, assuming that that database contains all >of the information it needs to resolve an address. > >What I am afraid of here is that we are introducing syntax to reach a >resource without defining any procedure. > >If I see this url: ><mailto:h323:paulej@packetizer.com>h323:paulej@packetizer.com > >What does that tell the H.323 entity? Is there a GK that is expecting a >LRQ, AccessRequest, or is it something else entirely? Perhaps the right >solution is to define (in normative text) the procedure for using SRV DNS >records to query the packetizer.com domain. > >As Pete rightfully pointed out, an H.323 URL would be the perfect place to >place conference identifiers for multipoint conferences: > ><mailto:h323:conf-server1@packetizer.com;cid:XXXX-XXXX-XXXX-XXXX>h323:conf- server1@packetizer.com;cid:XXXX-XXXX-XXXX-XXXX > >I think we need to work on the procedural part of this now. Who is >working on that? > >Paul > >>----- Original Message ----- >>From: <mailto:audet@NORTELNETWORKS.COM>Francois Audet >>To: <mailto:ITU-SG16@mailbag.cps.intel.com>ITU-SG16(a)mailbag.cps.intel.com >>Sent: Friday, June 16, 2000 11:48 AM >>Subject: Re: H.323 URL >> >>I would agree with Bob here. >> >>Using an H.323 URL for a telephone number would imply that you can only be >>reached using H.323. Is this you intention? >> >> > -----Original Message----- >> > From: Callaghan, Robert >> [<mailto:Robert.Callaghan@ICN.SIEMENS.COM>mailto:Robert.Callaghan@ICN.SIEMEN S.COM] >> >> > Sent: Friday, June 16, 2000 5:39 AM >> > To: <mailto:ITU-SG16@MAILBAG.INTEL.COM>ITU-SG16(a)MAILBAG.INTEL.COM >> > Subject: Re: H.323 URL >> > >> > >> > Paul, >> > >> > I think that this is getting complicated. >> > >> > I did not envision the use of the H.323-URL to encompase a >> > telephone number. >> > I only conceede for the purpose of progress. >> > >> > I saw the H.323-URL to be an identifier that would be used to access a >> > database. The DNS portion would identify the database, the >> > userID would be >> > the entry in the database. The database would then return >> > the necessary >> > information to complete the call. It is highly propable that this >> > information would include an E.164 or PNP address. This is >> > especially true >> > when the call must be ompleted over the SCN. >> > >> > I saw telephone numbers being defined in the "Tel:" URL >> > defined in RFC2806. >> > This URL covers many of optional fields needed to make an SCN >> > call which are >> > not presently covered in H.323. >> > >> > If we are to have multiple forms of an H.323 URL, I would >> > prefer to have >> > multi-URL IDs. >> > >> > Bob >> > >> > P.S. (By the way, the complex, cover everything, is where the >> > last try at an >> > H.323 URL diaappeared.) >> > >> > ------------------------------------------------------------------ >> > Robert Callaghan >> > Siemens Enterprise Networks >> > Tel: +1.561.923.1756 Fax: +1.561.923.1403 >> > Email: Robert.Callaghan(a)ICN.Siemens.com >> > ------------------------------------------------------------------ >> > >> > >> > -----Original Message----- >> > From: Paul E. Jones >> [<mailto:paulej@packetizer.com>mailto:paulej@packetizer.com] >> > Sent: Friday, June 16, 2000 3:11 AM >> > To: Callaghan, Robert; 'Orit Levin' >> > Cc: Mailing list for parties associated with ITU-T Study Group 16 >> > (E-mail) >> > Subject: Re: H.323 URL >> > >> > >> > Bob, >> > >> > I'm still surprised that you don't want to see the URL expanded... >> > especially to address party number types. Here is is currently: >> > >> > H323-URL = "H323:" user ["@" hostport] >> > user = username | phone-number >> > username = *( unreserved | escaped | "&" | "=" | "+" >> > | "$" | "," ) >> > hostport = host [ ":" port ] >> > host = hostname | IPv4address >> > hostname = *( domainlabel "." ) toplabel [ "." ] >> > domainlabel = alphanum | alphanum *( alphanum | "-" ) alphanum >> > toplabel = alpha | alpha *( alphanum | "-" ) alphanum >> > IPv4address = 1*digit "." 1*digit "." 1*digit "." 1*digit >> > port = *digit >> > reserved = ";" | "/" | "?" | ":" | "@" | "&" | "=" | >> > "+" |"$" | "," >> > digits = 1*DIGIT >> > >> > However, to be useful, information that follows the "h323:" should be >> > something in a form that an H.323 Gatekeeper can resolve. >> > Those things >> > include: >> > dialedDigits >> > h323-ID >> > email-ID >> > partyNumber >> > or one of the transportAddress types. >> > >> > This seems to be a reasonable syntax: >> > >> > H323-URL = "H323:" Address >> > Address = AliasAddress / TransportAddress >> > AliasAddress = dialedDigits / h323-ID / email-ID / partyNumber >> > dialedDigits = "dialedDigits=" 1*digit >> > h323-ID = "h323-ID=" 1*OCTET ; UTF-8 string represting the >> > BMPString >> > email-ID = "email-ID=" email-ID-spec >> > partyNumber = e164Number / dataPartyNumber / telexPartyNumber / >> > privateNumber >> > / nationalStandardPartyNumber >> > email-ID-spec = mailbox / group >> > group = phrase ":" [ mailbox ] ";" >> > phrase = 1*word >> > word = atom / quoted-string >> > atom = 1*CHAR ; any CHAR except specials, SPACE and CTLs >> > specials = "(" / ")" / "<" / ">" / "@" ; Must be in quoted- >> > / "," / ";" / ":" / "\" / <"> ; string, to use >> > / "." / "[" / "]" ; within a word. >> > quoted-string = >> > mailbox = addr-spec / phrase route-addr >> > addr-spec = local-part "@" domain >> > local-part = word *("." word) >> > domain = sub-domain *("." sub-domain) >> > sub-domain = domain-ref / domain-literal >> > domain-ref = atom >> > domain-literal = "[" *(dtext / quoted-pair) "]" >> > dtext = 1*CHAR ; Any CHAR excluding "[", "]", "\" & CR, >> > ; & including linear-white-space> >> > linear-white-space = 1*([CRLF] LWSP-char) >> > LWSP-char = SP / HTAB >> > quoted-pair = "\" CHAR >> > phrase = 1*word >> > route-addr = "<" [route] addr-spec ">" >> > route = "@" domain ":" >> > e164Number = "e164Number=" publicTypeOfNumber "," digits >> > digits = 1*(DIGIT / "#" / "*" / ",") >> > publicTypeOfNumber = "unknown" / "internationalStandard" / >> > "nationalNumber" >> > / "networkSpecificNumber" / "subscriberNumber" / >> > / "abbreviatedNumber" >> > dataPartyNumber = "dataPartyNumber=" digits >> > telexPartyNumber= "telexPartyNumber=" digits >> > privatePartyNumber = "privatePartyNumber=" >> > privateTypeOfNumber "," digits >> > privateTypeOfNumber = "unknown" / "level2RegionalNumber" / >> > "level1RegionalNumber" >> > / "pISNSpecificNumber" / "localNumber" / >> > "abbreviatedNumber" >> > TransportAddress = ipAddress / ipSourceRoute / ipxAddress / ip6Address >> > / netBios / nsap / nonStandardAddress >> > ipAddress = ip ":" port >> > ip = 1*DIGIT "." 1*DIGIT "." 1*DIGIT "." 1*DIGIT >> > port = 1*DIGIT >> > ipSourceRoute = ip ":" port "," ip *1("," ip) ";" ("strict" >> > / "loose") >> > ipxAddress = 1*DIGIT ":" 1*DIGIT ":" 1*DIGIT >> > ip6Address = 1*HEXDIGIT 14*(":" [1*HEXDIGIT]) 1*HEXDIGIT >> > HEXDIGIT = DIGIT / "A" / "B" / "C" / "D" / "E" / "F" >> > netBios = ;; and so forth >> > nsap = >> > nonStandardAddress = >> > >> > Now, there may be an error or two in there, but at least it >> > is more complete >> > and an H.323 system knows how to work with these. (Note I >> > did not address >> > the new V4 alias "mobileIUM") >> > >> > If we used this grammar, I don't think we would need a lot of >> > strange rules >> > about what you do with the URL. Basically, you take it apart >> > according to >> > its internal parts to form an alias address that a Gatekeeper >> > can resolve. >> > >> > Paul >> > >> > ----- Original Message ----- >> > From: "Callaghan, Robert" <Robert.Callaghan(a)icn.siemens.com> >> > To: "'Orit Levin'" <orit(a)radvision.com>; "'Paul E. Jones'" >> > <paulej(a)PACKETIZER.COM> >> > Cc: "Mailing list for parties associated with ITU-T Study >> > Group 16 (E-mail)" >> > <ITU-SG16(a)mailbag.cps.intel.com> >> > Sent: Wednesday, June 14, 2000 3:50 PM >> > Subject: RE: H.323 URL >> > >> > >> > > Orit, >> > > >> > > In my opinion, an email-ID alias conforms to RFC-822 and is >> > interpreted >> > > according the rules stated in H.225.0. An H.323-URL-ID conforms to >> > > TD-40a/Osaka and is interpreted according to the rules >> > stated in TD-40a. >> > An >> > > H.323-ID is a character string without any rules of >> > interpretation. I see >> > > no need to blend these contexts. All three addressing >> > modes can be use; >> > > each in its own context. >> > > >> > > However, these are my opinion. Maybe more work is needed >> > in Portland. >> > > >> > > Bob >> > > >> > > ------------------------------------------------------------------ >> > > Robert Callaghan >> > > Siemens Enterprise Networks >> > > Tel: +1.561.923.1756 Fax: +1.561.923.1403 >> > > Email: Robert.Callaghan(a)ICN.Siemens.com >> > > ------------------------------------------------------------------ >> > > >> > > >> > > -----Original Message----- >> > > From: Orit Levin [<mailto:orit@radvision.com>mailto:orit@radvision.com] >> > > Sent: Wednesday, June 14, 2000 11:45 AM >> > > To: Callaghan, Robert; 'Paul E. Jones' >> > > Cc: Mailing list for parties associated with ITU-T Study Group 16 >> > > (E-mail) >> > > Subject: Re: H.323 URL >> > > >> > > >> > > Hello Bob and Paul! >> > > I don't see backwards compatibility problem, when the URL >> > says explicitly >> > > H323-URL. An appropriate change may be to state, that the >> > default meaning >> > of >> > > url, encoded into email-ID alias, is according to RFC-822. >> > > Now, I feel a need to put a chapter explaining what is the >> > meaning of >> > email >> > > URL (apart from its syntax) when used in H.323 Network. >> > There is some >> > > explanation in H.225.0 Appendix IV. Do you find it clear >> > and sufficient? >> > > Orit Levin >> > > RADVision Inc. >> > > 575 Corporate Drive Suite 420 >> > > Mahwah, NJ 07430 >> > > Tel: 1 201 529 4300 (230) >> > > Fax: 1 201 529 3516 >> > > www.radvision.com >> > > orit(a)radvision.com >> > > -----Original Message----- >> > > From: Callaghan, Robert <Robert.Callaghan(a)icn.siemens.com> >> > > To: 'Paul E. Jones' <paulej(a)PACKETIZER.COM>; 'Orit Levin' >> > > <orit(a)radvision.com> >> > > Cc: Mailing list for parties associated with ITU-T Study >> > Group 16 (E-mail) >> > > <ITU-SG16(a)mailbag.cps.intel.com> >> > > Date: Wednesday, June 14, 2000 9:56 AM >> > > Subject: H.323 URL >> > > >> > > >> > > >Paul, >> > > > >> > > >I have a backward compatibility item for you to think about. >> > > > >> > > >TD-40/Osaka states that the H323-URL may be coded into the >> > email-ID for >> > > >alias address. However, H.225.0 states that the email-ID >> > shall conform >> > to >> > > >RFC822. This is an exclusionary requirement in that other >> > standards may >> > > not >> > > >be used. Also, Note 4 of the BNF definition of the >> > H323-URL clearly >> > states >> > > >that that the H323-URL is *not* compatible with RFC822. >> > > > >> > > >Therefor, I propose that the H323-URL cannot be coded into >> > the email-ID >> > for >> > > >alias address because of compatibility problems. >> > > > >> > > >Bob >> > > > >> > > >------------------------------------------------------------------ >> > > >Robert Callaghan >> > > >Siemens Enterprise Networks >> > > >Tel: +1.561.923.1756 Fax: +1.561.923.1403 >> > > >Email: Robert.Callaghan(a)ICN.Siemens.com >> > > >------------------------------------------------------------------ >> > > > >> > > >> > >> > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ >> > For help on this mail list, send "HELP ITU-SG16" in a message to >> > listserv(a)mailbag.intel.com >> > ------------------------------------------------------------------- Chip Sharp CTO Consulting Engineering Cisco Systems Reality - Love it or Change it. http://www.netaid.org ------------------------------------------------------------------- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 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

Re: H.323 URL
by Callaghan, Robert 19 Jun '00

19 Jun '00

Paul, I think that this is getting complicated. I did not envision the use of the H.323-URL to encompase a telephone number. I only conceede for the purpose of progress. I saw the H.323-URL to be an identifier that would be used to access a database. The DNS portion would identify the database, the userID would be the entry in the database. The database would then return the necessary information to complete the call. It is highly propable that this information would include an E.164 or PNP address. This is especially true when the call must be ompleted over the SCN. I saw telephone numbers being defined in the "Tel:" URL defined in RFC2806. This URL covers many of optional fields needed to make an SCN call which are not presently covered in H.323. If we are to have multiple forms of an H.323 URL, I would prefer to have multi-URL IDs. Bob P.S. (By the way, the complex, cover everything, is where the last try at an H.323 URL diaappeared.) ------------------------------------------------------------------ Robert Callaghan Siemens Enterprise Networks Tel: +1.561.923.1756 Fax: +1.561.923.1403 Email: Robert.Callaghan(a)ICN.Siemens.com ------------------------------------------------------------------ -----Original Message----- From: Paul E. Jones [mailto:paulej@packetizer.com] Sent: Friday, June 16, 2000 3:11 AM To: Callaghan, Robert; 'Orit Levin' Cc: Mailing list for parties associated with ITU-T Study Group 16 (E-mail) Subject: Re: H.323 URL Bob, I'm still surprised that you don't want to see the URL expanded... especially to address party number types. Here is is currently: H323-URL = "H323:" user ["@" hostport] user = username | phone-number username = *( unreserved | escaped | "&" | "=" | "+" | "$" | "," ) hostport = host [ ":" port ] host = hostname | IPv4address hostname = *( domainlabel "." ) toplabel [ "." ] domainlabel = alphanum | alphanum *( alphanum | "-" ) alphanum toplabel = alpha | alpha *( alphanum | "-" ) alphanum IPv4address = 1*digit "." 1*digit "." 1*digit "." 1*digit port = *digit reserved = ";" | "/" | "?" | ":" | "@" | "&" | "=" | "+" |"$" | "," digits = 1*DIGIT However, to be useful, information that follows the "h323:" should be something in a form that an H.323 Gatekeeper can resolve. Those things include: dialedDigits h323-ID email-ID partyNumber or one of the transportAddress types. This seems to be a reasonable syntax: H323-URL = "H323:" Address Address = AliasAddress / TransportAddress AliasAddress = dialedDigits / h323-ID / email-ID / partyNumber dialedDigits = "dialedDigits=" 1*digit h323-ID = "h323-ID=" 1*OCTET ; UTF-8 string represting the BMPString email-ID = "email-ID=" email-ID-spec partyNumber = e164Number / dataPartyNumber / telexPartyNumber / privateNumber / nationalStandardPartyNumber email-ID-spec = mailbox / group group = phrase ":" [ mailbox ] ";" phrase = 1*word word = atom / quoted-string atom = 1*CHAR ; any CHAR except specials, SPACE and CTLs specials = "(" / ")" / "<" / ">" / "@" ; Must be in quoted- / "," / ";" / ":" / "\" / <"> ; string, to use / "." / "[" / "]" ; within a word. quoted-string = mailbox = addr-spec / phrase route-addr addr-spec = local-part "@" domain local-part = word *("." word) domain = sub-domain *("." sub-domain) sub-domain = domain-ref / domain-literal domain-ref = atom domain-literal = "[" *(dtext / quoted-pair) "]" dtext = 1*CHAR ; Any CHAR excluding "[", "]", "\" & CR, ; & including linear-white-space> linear-white-space = 1*([CRLF] LWSP-char) LWSP-char = SP / HTAB quoted-pair = "\" CHAR phrase = 1*word route-addr = "<" [route] addr-spec ">" route = "@" domain ":" e164Number = "e164Number=" publicTypeOfNumber "," digits digits = 1*(DIGIT / "#" / "*" / ",") publicTypeOfNumber = "unknown" / "internationalStandard" / "nationalNumber" / "networkSpecificNumber" / "subscriberNumber" / / "abbreviatedNumber" dataPartyNumber = "dataPartyNumber=" digits telexPartyNumber= "telexPartyNumber=" digits privatePartyNumber = "privatePartyNumber=" privateTypeOfNumber "," digits privateTypeOfNumber = "unknown" / "level2RegionalNumber" / "level1RegionalNumber" / "pISNSpecificNumber" / "localNumber" / "abbreviatedNumber" TransportAddress = ipAddress / ipSourceRoute / ipxAddress / ip6Address / netBios / nsap / nonStandardAddress ipAddress = ip ":" port ip = 1*DIGIT "." 1*DIGIT "." 1*DIGIT "." 1*DIGIT port = 1*DIGIT ipSourceRoute = ip ":" port "," ip *1("," ip) ";" ("strict" / "loose") ipxAddress = 1*DIGIT ":" 1*DIGIT ":" 1*DIGIT ip6Address = 1*HEXDIGIT 14*(":" [1*HEXDIGIT]) 1*HEXDIGIT HEXDIGIT = DIGIT / "A" / "B" / "C" / "D" / "E" / "F" netBios = ;; and so forth nsap = nonStandardAddress = Now, there may be an error or two in there, but at least it is more complete and an H.323 system knows how to work with these. (Note I did not address the new V4 alias "mobileIUM") If we used this grammar, I don't think we would need a lot of strange rules about what you do with the URL. Basically, you take it apart according to its internal parts to form an alias address that a Gatekeeper can resolve. Paul ----- Original Message ----- From: "Callaghan, Robert" <Robert.Callaghan(a)icn.siemens.com> To: "'Orit Levin'" <orit(a)radvision.com>; "'Paul E. Jones'" <paulej(a)PACKETIZER.COM> Cc: "Mailing list for parties associated with ITU-T Study Group 16 (E-mail)" <ITU-SG16(a)mailbag.cps.intel.com> Sent: Wednesday, June 14, 2000 3:50 PM Subject: RE: H.323 URL > Orit, > > In my opinion, an email-ID alias conforms to RFC-822 and is interpreted > according the rules stated in H.225.0. An H.323-URL-ID conforms to > TD-40a/Osaka and is interpreted according to the rules stated in TD-40a. An > H.323-ID is a character string without any rules of interpretation. I see > no need to blend these contexts. All three addressing modes can be use; > each in its own context. > > However, these are my opinion. Maybe more work is needed in Portland. > > Bob > > ------------------------------------------------------------------ > Robert Callaghan > Siemens Enterprise Networks > Tel: +1.561.923.1756 Fax: +1.561.923.1403 > Email: Robert.Callaghan(a)ICN.Siemens.com > ------------------------------------------------------------------ > > > -----Original Message----- > From: Orit Levin [mailto:orit@radvision.com] > Sent: Wednesday, June 14, 2000 11:45 AM > To: Callaghan, Robert; 'Paul E. Jones' > Cc: Mailing list for parties associated with ITU-T Study Group 16 > (E-mail) > Subject: Re: H.323 URL > > > Hello Bob and Paul! > I don't see backwards compatibility problem, when the URL says explicitly > H323-URL. An appropriate change may be to state, that the default meaning of > url, encoded into email-ID alias, is according to RFC-822. > Now, I feel a need to put a chapter explaining what is the meaning of email > URL (apart from its syntax) when used in H.323 Network. There is some > explanation in H.225.0 Appendix IV. Do you find it clear and sufficient? > Orit Levin > RADVision Inc. > 575 Corporate Drive Suite 420 > Mahwah, NJ 07430 > Tel: 1 201 529 4300 (230) > Fax: 1 201 529 3516 > www.radvision.com > orit(a)radvision.com > -----Original Message----- > From: Callaghan, Robert <Robert.Callaghan(a)icn.siemens.com> > To: 'Paul E. Jones' <paulej(a)PACKETIZER.COM>; 'Orit Levin' > <orit(a)radvision.com> > Cc: Mailing list for parties associated with ITU-T Study Group 16 (E-mail) > <ITU-SG16(a)mailbag.cps.intel.com> > Date: Wednesday, June 14, 2000 9:56 AM > Subject: H.323 URL > > > >Paul, > > > >I have a backward compatibility item for you to think about. > > > >TD-40/Osaka states that the H323-URL may be coded into the email-ID for > >alias address. However, H.225.0 states that the email-ID shall conform to > >RFC822. This is an exclusionary requirement in that other standards may > not > >be used. Also, Note 4 of the BNF definition of the H323-URL clearly states > >that that the H323-URL is *not* compatible with RFC822. > > > >Therefor, I propose that the H323-URL cannot be coded into the email-ID for > >alias address because of compatibility problems. > > > >Bob > > > >------------------------------------------------------------------ > >Robert Callaghan > >Siemens Enterprise Networks > >Tel: +1.561.923.1756 Fax: +1.561.923.1403 > >Email: Robert.Callaghan(a)ICN.Siemens.com > >------------------------------------------------------------------ > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

2 1

Re: H.323 Annex O
by Skran, Dale 19 Jun '00

19 Jun '00

Thanks for the kind words about SG16 rapporteurs. Dale Skran Q13 Rapporteur -----Original Message----- From: Scott Bradner [mailto:sob@HARVARD.EDU] Sent: Wednesday, May 31, 2000 8:46 AM To: ITU-SG16(a)MAILBAG.INTEL.COM Subject: Re: H.323 Annex O some notes on Chip's message at ">>" Scott (ISOC VP-Standards) ------------ At 09:59 AM 5/30/00 -0400, Roy, Radhika R, ALARC wrote: ...snip... >There are also no mechanisms in the ITU-T SG16 to accept the contributions >for the companies that can afford to communicate via emails only. I guess >that the best way is to have the RFC from the IETF that will have all inputs >from all companies that invented the interworking solution. The SG16 can >then have the RFC for their use to make a formal standard (with more >additions if needed). It is true that SG16 still operates mainly on the basis of written contributions to meetings and not on mail lists like IETF WG. It is also true that non-ITU members have a hard time participating in ITU SG work. Even if a company is an ITU member, attending all the meetings around the world is a travel burden on small companies (even big companies). However, an IETF WG can submit a written contribution to SG16 via existing mechanisms. Usually, this is initiated via consensus of the WG and/or by WG chair via the ISOC VP - Standards. Of course, it requires someone to represent that contribution at the SG16 meetings. The SG16 Rapporteurs have been very open in the past to inviting non-ITU member experts to Rapporteur Meetings to further the work. The SG16 mail list has been one of the more active SG mail lists in actually discussing technical issues. And SG16's working documents are available for review as well (at least from Rapporteur's Meetings). It will be nice if ITU could codify some of these examples at WTSA. >> in addition working group chairs can request that individuals be >> appopinted formal ISOC (IETF) representives to ITU-T meetings >> by the ISOC VP-standards working with the IAB (teh ISOC is an ITU-T >> member) I understand the desire to do the work in one place. It is also true that SG16 can reference an IETF RFC in its recommendations. However, if it is an informational RFC, it can't be a normative reference in ITU. >> nor should it be since an RFC with informational status carries no >> implication of IETF review, support or approval ...snip... >If you think that any improvements need to be done in the solutions proposed >in the contributions of the IETF (please see the references provided in my >email), please submit the proposal in the IETF. We can then use the >Informational RFC as an input for a formal standard in the SG16. In this >way, we can get the best the both worlds having a "single common standard >for SIP-H.323 Interworking". Remember an ITU Recommendation cannot make a normative reference to an Informational RFC. If there is no new protocol work being done, the H.323-SIP interworking could conceivably become a BCP (Best Current Practice) some day. >The key is that the SG16 cannot use the interworking solution that has been >"invented" by the other companies or institutions without their consent and >participation. I personally feel very strongly that the SG16 cannot not >"invent" a NEW interworking solution of its own that will NOT include the >solutions proposed by others in the IETF. The ITU can incorporate by (normative or non-normative) reference to any RFC. The IETF has an IPR policy that isn't too different from ITU (I don't think). Current A.5 procedures require that IETF provide a written agreement to allow normative references to an RFC (I don't remember ever seeing one of these, but there may be a blanket agreement). There are proposals to drop this requirement in the next version of A.5. >> the ISOC gave a blanket approval years ago Any IPR contained in IETF RFCs are covered by IETF IPR policy. It is true that a company that has declared IPR in an IETF RFC may not know it is being referenced in ITU and therefore may not submit an IPR statement to ITU. Therefore the IPR would only be covered by the IETF IPR statement (this brings up interesting legal questions, but I'll leave that up to the lawyers.). This should only be a real problem if the invention were included in the ITU Recommendation by some means other than reference. So the bottom line is that there are mechanisms to share work in ITU and IETF even without all the formal mechanisms worked out between Megaco and Q.14. However, if the work is going to be cooperative, such an agreement is probably desirable. >> specifically - the process worked out for megaco is described in A.5 >> but it is listes as the least desirable way to work together - it is >> far cleaner for one organization to take respoinsibility for publishing >> the document (with input from the other) and the other organization >> create a simple document that points to the offical document ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 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

Re: H.323 URL
by Francois Audet 19 Jun '00

19 Jun '00

I would agree with Bob here. Using an H.323 URL for a telephone number would imply that you can only be reached using H.323. Is this you intention? > -----Original Message----- > From: Callaghan, Robert [mailto:Robert.Callaghan@ICN.SIEMENS.COM] > Sent: Friday, June 16, 2000 5:39 AM > To: ITU-SG16(a)MAILBAG.INTEL.COM > Subject: Re: H.323 URL > > > Paul, > > I think that this is getting complicated. > > I did not envision the use of the H.323-URL to encompase a > telephone number. > I only conceede for the purpose of progress. > > I saw the H.323-URL to be an identifier that would be used to access a > database. The DNS portion would identify the database, the > userID would be > the entry in the database. The database would then return > the necessary > information to complete the call. It is highly propable that this > information would include an E.164 or PNP address. This is > especially true > when the call must be ompleted over the SCN. > > I saw telephone numbers being defined in the "Tel:" URL > defined in RFC2806. > This URL covers many of optional fields needed to make an SCN > call which are > not presently covered in H.323. > > If we are to have multiple forms of an H.323 URL, I would > prefer to have > multi-URL IDs. > > Bob > > P.S. (By the way, the complex, cover everything, is where the > last try at an > H.323 URL diaappeared.) > > ------------------------------------------------------------------ > Robert Callaghan > Siemens Enterprise Networks > Tel: +1.561.923.1756 Fax: +1.561.923.1403 > Email: Robert.Callaghan(a)ICN.Siemens.com > ------------------------------------------------------------------ > > > -----Original Message----- > From: Paul E. Jones [mailto:paulej@packetizer.com] > Sent: Friday, June 16, 2000 3:11 AM > To: Callaghan, Robert; 'Orit Levin' > Cc: Mailing list for parties associated with ITU-T Study Group 16 > (E-mail) > Subject: Re: H.323 URL > > > Bob, > > I'm still surprised that you don't want to see the URL expanded... > especially to address party number types. Here is is currently: > > H323-URL = "H323:" user ["@" hostport] > user = username | phone-number > username = *( unreserved | escaped | "&" | "=" | "+" > | "$" | "," ) > hostport = host [ ":" port ] > host = hostname | IPv4address > hostname = *( domainlabel "." ) toplabel [ "." ] > domainlabel = alphanum | alphanum *( alphanum | "-" ) alphanum > toplabel = alpha | alpha *( alphanum | "-" ) alphanum > IPv4address = 1*digit "." 1*digit "." 1*digit "." 1*digit > port = *digit > reserved = ";" | "/" | "?" | ":" | "@" | "&" | "=" | > "+" |"$" | "," > digits = 1*DIGIT > > However, to be useful, information that follows the "h323:" should be > something in a form that an H.323 Gatekeeper can resolve. > Those things > include: > dialedDigits > h323-ID > email-ID > partyNumber > or one of the transportAddress types. > > This seems to be a reasonable syntax: > > H323-URL = "H323:" Address > Address = AliasAddress / TransportAddress > AliasAddress = dialedDigits / h323-ID / email-ID / partyNumber > dialedDigits = "dialedDigits=" 1*digit > h323-ID = "h323-ID=" 1*OCTET ; UTF-8 string represting the > BMPString > email-ID = "email-ID=" email-ID-spec > partyNumber = e164Number / dataPartyNumber / telexPartyNumber / > privateNumber > / nationalStandardPartyNumber > email-ID-spec = mailbox / group > group = phrase ":" [ mailbox ] ";" > phrase = 1*word > word = atom / quoted-string > atom = 1*CHAR ; any CHAR except specials, SPACE and CTLs > specials = "(" / ")" / "<" / ">" / "@" ; Must be in quoted- > / "," / ";" / ":" / "\" / <"> ; string, to use > / "." / "[" / "]" ; within a word. > quoted-string = > mailbox = addr-spec / phrase route-addr > addr-spec = local-part "@" domain > local-part = word *("." word) > domain = sub-domain *("." sub-domain) > sub-domain = domain-ref / domain-literal > domain-ref = atom > domain-literal = "[" *(dtext / quoted-pair) "]" > dtext = 1*CHAR ; Any CHAR excluding "[", "]", "\" & CR, > ; & including linear-white-space> > linear-white-space = 1*([CRLF] LWSP-char) > LWSP-char = SP / HTAB > quoted-pair = "\" CHAR > phrase = 1*word > route-addr = "<" [route] addr-spec ">" > route = "@" domain ":" > e164Number = "e164Number=" publicTypeOfNumber "," digits > digits = 1*(DIGIT / "#" / "*" / ",") > publicTypeOfNumber = "unknown" / "internationalStandard" / > "nationalNumber" > / "networkSpecificNumber" / "subscriberNumber" / > / "abbreviatedNumber" > dataPartyNumber = "dataPartyNumber=" digits > telexPartyNumber= "telexPartyNumber=" digits > privatePartyNumber = "privatePartyNumber=" > privateTypeOfNumber "," digits > privateTypeOfNumber = "unknown" / "level2RegionalNumber" / > "level1RegionalNumber" > / "pISNSpecificNumber" / "localNumber" / > "abbreviatedNumber" > TransportAddress = ipAddress / ipSourceRoute / ipxAddress / ip6Address > / netBios / nsap / nonStandardAddress > ipAddress = ip ":" port > ip = 1*DIGIT "." 1*DIGIT "." 1*DIGIT "." 1*DIGIT > port = 1*DIGIT > ipSourceRoute = ip ":" port "," ip *1("," ip) ";" ("strict" > / "loose") > ipxAddress = 1*DIGIT ":" 1*DIGIT ":" 1*DIGIT > ip6Address = 1*HEXDIGIT 14*(":" [1*HEXDIGIT]) 1*HEXDIGIT > HEXDIGIT = DIGIT / "A" / "B" / "C" / "D" / "E" / "F" > netBios = ;; and so forth > nsap = > nonStandardAddress = > > Now, there may be an error or two in there, but at least it > is more complete > and an H.323 system knows how to work with these. (Note I > did not address > the new V4 alias "mobileIUM") > > If we used this grammar, I don't think we would need a lot of > strange rules > about what you do with the URL. Basically, you take it apart > according to > its internal parts to form an alias address that a Gatekeeper > can resolve. > > Paul > > ----- Original Message ----- > From: "Callaghan, Robert" <Robert.Callaghan(a)icn.siemens.com> > To: "'Orit Levin'" <orit(a)radvision.com>; "'Paul E. Jones'" > <paulej(a)PACKETIZER.COM> > Cc: "Mailing list for parties associated with ITU-T Study > Group 16 (E-mail)" > <ITU-SG16(a)mailbag.cps.intel.com> > Sent: Wednesday, June 14, 2000 3:50 PM > Subject: RE: H.323 URL > > > > Orit, > > > > In my opinion, an email-ID alias conforms to RFC-822 and is > interpreted > > according the rules stated in H.225.0. An H.323-URL-ID conforms to > > TD-40a/Osaka and is interpreted according to the rules > stated in TD-40a. > An > > H.323-ID is a character string without any rules of > interpretation. I see > > no need to blend these contexts. All three addressing > modes can be use; > > each in its own context. > > > > However, these are my opinion. Maybe more work is needed > in Portland. > > > > Bob > > > > ------------------------------------------------------------------ > > Robert Callaghan > > Siemens Enterprise Networks > > Tel: +1.561.923.1756 Fax: +1.561.923.1403 > > Email: Robert.Callaghan(a)ICN.Siemens.com > > ------------------------------------------------------------------ > > > > > > -----Original Message----- > > From: Orit Levin [mailto:orit@radvision.com] > > Sent: Wednesday, June 14, 2000 11:45 AM > > To: Callaghan, Robert; 'Paul E. Jones' > > Cc: Mailing list for parties associated with ITU-T Study Group 16 > > (E-mail) > > Subject: Re: H.323 URL > > > > > > Hello Bob and Paul! > > I don't see backwards compatibility problem, when the URL > says explicitly > > H323-URL. An appropriate change may be to state, that the > default meaning > of > > url, encoded into email-ID alias, is according to RFC-822. > > Now, I feel a need to put a chapter explaining what is the > meaning of > email > > URL (apart from its syntax) when used in H.323 Network. > There is some > > explanation in H.225.0 Appendix IV. Do you find it clear > and sufficient? > > Orit Levin > > RADVision Inc. > > 575 Corporate Drive Suite 420 > > Mahwah, NJ 07430 > > Tel: 1 201 529 4300 (230) > > Fax: 1 201 529 3516 > > www.radvision.com > > orit(a)radvision.com > > -----Original Message----- > > From: Callaghan, Robert <Robert.Callaghan(a)icn.siemens.com> > > To: 'Paul E. Jones' <paulej(a)PACKETIZER.COM>; 'Orit Levin' > > <orit(a)radvision.com> > > Cc: Mailing list for parties associated with ITU-T Study > Group 16 (E-mail) > > <ITU-SG16(a)mailbag.cps.intel.com> > > Date: Wednesday, June 14, 2000 9:56 AM > > Subject: H.323 URL > > > > > > >Paul, > > > > > >I have a backward compatibility item for you to think about. > > > > > >TD-40/Osaka states that the H323-URL may be coded into the > email-ID for > > >alias address. However, H.225.0 states that the email-ID > shall conform > to > > >RFC822. This is an exclusionary requirement in that other > standards may > > not > > >be used. Also, Note 4 of the BNF definition of the > H323-URL clearly > states > > >that that the H323-URL is *not* compatible with RFC822. > > > > > >Therefor, I propose that the H323-URL cannot be coded into > the email-ID > for > > >alias address because of compatibility problems. > > > > > >Bob > > > > > >------------------------------------------------------------------ > > >Robert Callaghan > > >Siemens Enterprise Networks > > >Tel: +1.561.923.1756 Fax: +1.561.923.1403 > > >Email: Robert.Callaghan(a)ICN.Siemens.com > > >------------------------------------------------------------------ > > > > > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > For help on this mail list, send "HELP ITU-SG16" in a message to > listserv(a)mailbag.intel.com >

3 2

H.245 Draft White paper uploaded to server
by Mike Nilsson 19 Jun '00

19 Jun '00

I have uploaded a draft of the H.245 Version 7 White paper to ftp://standard.pictel.com/avc-site/Incoming/h245wcmm.zip (Mr Okubo will move this in due course). I will submit the white paper to the ITU next week - so please review as soon as possible. Best regards Mike -------------------- Mike Nilsson Internet and Multimedia Applications B81 Room 102 pp14 BT Advanced Communications Technology Centre Adastral Park, Martlesham Heath, Ipswich, IP5 3RE, UK Tel: +44 1473 645413 Mobile: +44 7808 635412 Fax: +44 1473 646589 Email: mike.nilsson(a)bt.com ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

Good news from TSAG on Informative References
by Chip Sharp 19 Jun '00

19 Jun '00

I understand from the June TSAG meeting that A.5 has been revised so we no longer have to write up justifications for Informative References. I'm not sure when this goes into effect though. :-) Chip ------------------------------------------------------------------- Chip Sharp CTO Consulting Engineering Cisco Systems Reality - Love it or Change it. http://www.netaid.org ------------------------------------------------------------------- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0