- sg16-avd - lists.packetizer.com

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

19 Jun '00

Paul, I fully agree with your that we need procedures to support the H.323-URL. However, before we have the procedures, we goals and objectives. We currently have a full set of telephone addresses (E.164, PNP, etc.). These addresses can easily transport the adress provided in a "TEL:" URL. For a voice only call the format of this URL is better that that proposed for the H.323 URL, in that it is telephony oriented with the options that maybe required for this type of call. We have an e-mail structured address that is not used as e-mail. The procedure proposed by Orit reads very similar to the procedure for using and e-mail address. What is the objective of a new address format? I agree that the H.323 URL should support the needs of multi-media H.323 connections (calls). What are they? You talk about Conference ID. What about media control (If video then.. else..)? What about application sharing control? What about support features (H.450, packages,...)? Do we include everything in one very complicated URL or do we have multiple URL covering various areas of H.323? I agree that we need a lot of discussion. This discussion will flow into Portland. (At least Orit and I agree this is the case.) A preliminary discussion on the mailing list will be useful, but we still need the decisions 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: Paul E. Jones [mailto:paulej@PACKETIZER.COM] Sent: Monday, June 19, 2000 3:15 AM To: ITU-SG16(a)mailbag.cps.intel.com 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 >

1 0

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

19 Jun '00

RE: H.323 URLDear 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 >

1 0

H.323 Annex J white contribution uploaded
by Euchner Martin 19 Jun '00

19 Jun '00

H.323 Annex J White Contribution has been sent to the ITU-T TSB; the zip file has been placed in the incoming directory of the avc-site. 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

AW: TD-54a/Osaka: New ReleaseCompleteReason for Annex M?
by Klaghofer Karl ICN SIB NL D1 19 Jun '00

19 Jun '00

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

1 0

AW: TD-50/Osaka - Changes to the conferenceGoal field
by Klaghofer Karl ICN SIB NL D1 19 Jun '00

19 Jun '00

Rich, I agree with your summary and to your alternative proposal (i.e. to add the neededFeatures field directly to the Setup-UUIE). Regards, Karl Klaghofer Siemens > -----Ursprüngliche Nachricht----- > Von: Rich Bowen [SMTP:rkbowen@CISCO.COM] > Gesendet am: Sunday, June 18, 2000 23:14 > An: ITU-SG16(a)mailbag.cps.intel.com > Betreff: 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

1 0

TD-50/Osaka - Changes to the conferenceGoal field
by Rich Bowen 19 Jun '00

19 Jun '00

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

2 1

SG16 meeting on 15 June
by Sakae OKUBO 18 Jun '00

18 Jun '00

Dear Q12-14/16 experts, This is to forward Mr. Freundlich's message regarding the subject matter. 1) H.248 was approved. 2) Two day meeting on 9-10 November was approved. This will be run according to the Rapporteur meeting procedures, not those of SG16 meeting. 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

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

18 Jun '00

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

1 0

H.248 Annex F, Facsimile, text conversation and call discrimination packages, white doc candidate for Q9/16 meeting
by Gunnar Hellstrom 18 Jun '00

18 Jun '00

Attached you can find a revised version of the H.248 packages for fax, text and call discrimination. They are to be reviewed in the Q9/16 and Q4/16 meeting in Edinburgh June 28-30. Comments from Q4/8 for fax are incorporated. Expected output: A white doc for proposed decision in November. Please review. The documents for the Q9/16 meeting are also available in www.omnitor.se/English/standards Regards Gunnar Hellstrom ------------------------------------------ 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

1 0

White contributions for the November 2000 meeting of SG16
by Sakae OKUBO 17 Jun '00

17 Jun '00

Dear Q12-14/16 experts, Draft Recommendations for decision in November 2000 are placed at the following directory: ftp://standard.pictel.com/avc-site/0011_Gen/ or http://standard.pictel.com/ftp/avc-site/0011_Gen/ H.323 Annex M.1 and H.450.9 texts have been moved there. 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

Auto Replied Message
by eltonj＠SAMSUNG.CO.KR 16 Jun '00

16 Jun '00

Hello, Thank you for the message . . . I am away from office (maybe on a business trip). However, I have an e-mail access (both Single and regular e-mail) wherever I am (as far as I have a phone line). Let me just get back to you shortly. BTW, I might be reached at (XXX) XXX-XXXX. Thank you, DS ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

H.323 Annex M.1 White Paper
by Francois Audet 16 Jun '00

16 Jun '00

I have sent the Whitepaper for H.323 Annex M.1 on QSIG tunnelling to Mr. Bigi. The document is available in: ftp://standard.pictel.com/avc-site/Incoming/. ----- François Audet Tel:+1 408 565 5675 mailto:audet@NortelNetworks.com Nortel Networks Fax:+1 408 565 2375 http://www.NortelNetworks.com

1 0

H.450.9 Whitepaper Call Completion service
by Klaghofer Karl ICN SIB NL D1 16 Jun '00

16 Jun '00

As agreed in the Osaka meeting, I have sent my input for the Whitepaper to Mr. Bigi already today. The document I sent to ITU as my whitepaper input is a clean copy of the document I have put on the pictel site for your review on May 31 ( ftp://standard.pictel.com/avc-site/0011_Gen/ ). I.e. there had been no changes since that. Regards, Karl Klaghofer, Siemens AG - Editor of H.450.9 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 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 16 Jun '00

16 Jun '00

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.323+java clients
by Apoorv Misra 15 Jun '00

15 Jun '00

Does H.323 support JAVA clients? Shachi Singh, Developer, PARSEC Technologies India Ltd. India. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

2 1

Revised report of the Osaka meeting
by Sakae OKUBO 14 Jun '00

14 Jun '00

Dear Q12-14/16 experts, I have placed the Osaka meeting report at the following place: ftp://standard.pictel.com/avc-site/0005_Osa/APC-1871a.zip or http://standard.pictel.com/ftp/avc-site/APC-1871a.zip This is a revision to APC-1871.zip having been in /Incoming with correction of an editorial error advised by Mr. Fortinsky and change of status to "confirmed by the participants." 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

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

14 Jun '00

Bob! On theoretical basis, I COMPLETELY agree with your statement. >From practical point of view (how many, and what type of aliases, the end user has the access to) we may need more work in Portland. 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: '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> Date: Wednesday, June 14, 2000 3:51 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

1 0

Re: H.245 Terminates Fast Connect
by Helpdesk MIS 14 Jun '00

14 Jun '00

From: Paul E. Jones Pete, We do have one more Rapporteur's meeting, so we can try to introduce some corrective text to address this issue and then put that forward as a delayed contribution or a Rapporteur's TD (latter preferred if we can come to an agreement). I may be missing your point in (2), but perhaps this will address the question: H.323v2 says that if an endpoint initiates H.245 (tunneled or a separate connection) before getting a response to Fast Connect, Fast Connect is terminated. However, there is no such rule with H.323v3/4. An H.323v2 device could initiate a Fast Connect call and then send an H.245 message to a V3 device to terminate Fast Connect, but the V3 device would not recognize that as a termination of Fast Connect. Thus, we have two devices that are out of sync. Between two V2 devices, we have a race condition, because one side could send an H.245 message to terminate FC, while the other side returns a message with fastStart to accept Fast Connect. Again, the two are out of sync. This is what we tried to address by removing the text, but we did not address the V2/V3 interoperability issue. So, we still have a potential problem. We could resolve this by simply stating noting the V2 behavior and discouraging a V3+ device from sending an H.245 message to a V2 device prior to learning whether FC was accepted. As a worst case, if it did send an H.245 message, it should assume that it is terminating Fast Connect in the V2 device and that a race condition may exist. For V3 and V4, FC is not terminated in this way as the text now stands-- endpoints are free to start H.245 in parallel. In addition, fast connect can be explicitly rejected, which gives an endpoint the "go ahead" to do logical channel signaling to get audio and video channels open prior to CONNECT. There may be additional, more complex issues-- I may be over-simplifying the interoperability issues here in this reply. It seems simple on the surface, but I know that I have heard from more than one vendor that they were not happy with these changes. However, I think that if we could add some explanatory text to H.323v3/4 to describe the V2 behavior and document the issues, I think we can move forward with the text as it is now, but I do not want to make that conclusion without others also taking a serious look at this issue. Paul ----- Original Message ----- From: "Pete Cordell" <pete(a)TECH-KNOW-WARE.COM> To: <ITU-SG16(a)mailbag.cps.intel.com> Sent: Tuesday, June 13, 2000 9:39 AM Subject: Re: H.245 Terminates Fast Connect > Paul, > > Two things... > > 1) What will be the procedure used in Geneva to decide v4. Will we have the > opportunity to put a delta document in? If we are, the correct (not > necessarily sensible!) procedure is to have the white paper as agreed in > Osaka, and un-do it (as a result of further information) in Geneva. > > 2) Fast start is limited to working on session IDs 1 and 2. As long as > H.245 specifies other session IDs with its OLC I believe this can get around > the alleged race condition. Does this make any sense? > > Pete. > > ============================================= > Pete Cordell > Tech-Know-Ware > pete(a)tech-know-ware.com > +44 1473 635863 > ============================================= > > ----- Original Message ----- > From: Paul E. Jones <paulej(a)PACKETIZER.COM> > To: <ITU-SG16(a)mailbag.cps.intel.com> > Sent: 13 June 2000 11:17 > Subject: H.245 Terminates Fast Connect > > > > Folks, > > > > As you know, we added some text to the H.323 Implementers Guide (section > > 6.1.7) removing the text from 8.2.1/H.323 that used to state: > > > > ``The sending of encapsulated H.245 messages or the initiation of the > > separate H.245 connection by either endpoint prior to the sending of a > Q.931 > > message containing fastStart by the called endpoint terminates the Fast > > Connect procedures.'' > > > > There was also some further supporting text added to the IG, but removed > > before the final agreed document that read (this is somewhat out of date > now > > that H.323v4 devices that use Fast Connect *shall* tunnel, but text is > > necessary for V2 and V3 entities): > > ``It is possible to switch to H.245 procedures before the Fast Connect > > procedure completes. If h245Tunneling is enabled, the terminating party > may > > start using tunneling as described in 8.2.1. If H.245 transport address > is > > included in the Setup message, then the terminating party may start the > > switch to H.245 as described in 8.2.3. In either case the Fast Connect > > procedure is terminated.'' > > > > Unfortunately, removing this text (particular the text that was already > > existing the H.323) has caused all kinds of grief, as there are > > implementations that do, in fact, behave according to this text found in > > H.323v2 and H.323v3. I know a few people have discussed reversing this > > decision, but no formal proposal has been submitted. > > > > We need to have a discussion on this topic. I want to propose that the > > H.323v4 white paper *not* have this text removed. If people agree with > > that, I will bring a contribution that will propose reinstating this text. > > > > Part of the reason for its removal is that there is a race condition that > > can occur. For example, if the caller sends a Setup with fastStart and > then > > later initiates H.245 while at the same time, the called endpoint returns > a > > message with fastStart, what state is H.245 in? > > > > I believe that we can resolve the issues by documenting the fact that a > race > > condition exists and introducing a few new rules. For example, we could > say > > > > that if, as in this example above, the calling endpoint initiates H.245 > and > > then gets a fastStart element in a message, the caller shall recognize the > > fact that Fast Connect was accepted. Hopefully, no logical channel > > signaling will have taken place. If it has, the called party should > reject > > any conflicting channels, so the calling endpoint can recognize that a > > rejected channel is the result of Fast Connect being accepted and the > > channel is actually open (as per the FC received). > > > > I would like to see if we can come to any kind of agreement on this issue > > and a recommendation for a direction forward. > > > > Best Regards, > > Paul > > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > 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

1 0

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

14 Jun '00

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 >------------------------------------------------------------------ >

1 0

H.323 URL
by Callaghan, Robert 14 Jun '00

14 Jun '00

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

H.245 Terminates Fast Connect
by Paul E. Jones 13 Jun '00

13 Jun '00

Folks, As you know, we added some text to the H.323 Implementers Guide (section 6.1.7) removing the text from 8.2.1/H.323 that used to state: ``The sending of encapsulated H.245 messages or the initiation of the separate H.245 connection by either endpoint prior to the sending of a Q.931 message containing fastStart by the called endpoint terminates the Fast Connect procedures.'' There was also some further supporting text added to the IG, but removed before the final agreed document that read (this is somewhat out of date now that H.323v4 devices that use Fast Connect *shall* tunnel, but text is necessary for V2 and V3 entities): ``It is possible to switch to H.245 procedures before the Fast Connect procedure completes. If h245Tunneling is enabled, the terminating party may start using tunneling as described in 8.2.1. If H.245 transport address is included in the Setup message, then the terminating party may start the switch to H.245 as described in 8.2.3. In either case the Fast Connect procedure is terminated.'' Unfortunately, removing this text (particular the text that was already existing the H.323) has caused all kinds of grief, as there are implementations that do, in fact, behave according to this text found in H.323v2 and H.323v3. I know a few people have discussed reversing this decision, but no formal proposal has been submitted. We need to have a discussion on this topic. I want to propose that the H.323v4 white paper *not* have this text removed. If people agree with that, I will bring a contribution that will propose reinstating this text. Part of the reason for its removal is that there is a race condition that can occur. For example, if the caller sends a Setup with fastStart and then later initiates H.245 while at the same time, the called endpoint returns a message with fastStart, what state is H.245 in? I believe that we can resolve the issues by documenting the fact that a race condition exists and introducing a few new rules. For example, we could say that if, as in this example above, the calling endpoint initiates H.245 and then gets a fastStart element in a message, the caller shall recognize the fact that Fast Connect was accepted. Hopefully, no logical channel signaling will have taken place. If it has, the called party should reject any conflicting channels, so the calling endpoint can recognize that a rejected channel is the result of Fast Connect being accepted and the channel is actually open (as per the FC received). I would like to see if we can come to any kind of agreement on this issue and a recommendation for a direction forward. Best Regards, Paul ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

2 2

RE: H.245 Terminates Fast Connect
by Callaghan, Robert 13 Jun '00

13 Jun '00

Paul, If the agreement was clearly to remove the text, how can you not remove it? This is true even if you have difficulties agreeing with the decision. Yes there is a race condition, but only regarding the pending OLCs. A simple statement is that OLC activity cannot be done until the FastStart terminates or is explicity rejected. Other H.245 activity should be fine. 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: Paul E. Jones [mailto:paulej@PACKETIZER.COM] Sent: Tuesday, June 13, 2000 6:17 AM To: ITU-SG16(a)mailbag.cps.intel.com Subject: H.245 Terminates Fast Connect Folks, As you know, we added some text to the H.323 Implementers Guide (section 6.1.7) removing the text from 8.2.1/H.323 that used to state: ``The sending of encapsulated H.245 messages or the initiation of the separate H.245 connection by either endpoint prior to the sending of a Q.931 message containing fastStart by the called endpoint terminates the Fast Connect procedures.'' There was also some further supporting text added to the IG, but removed before the final agreed document that read (this is somewhat out of date now that H.323v4 devices that use Fast Connect *shall* tunnel, but text is necessary for V2 and V3 entities): ``It is possible to switch to H.245 procedures before the Fast Connect procedure completes. If h245Tunneling is enabled, the terminating party may start using tunneling as described in 8.2.1. If H.245 transport address is included in the Setup message, then the terminating party may start the switch to H.245 as described in 8.2.3. In either case the Fast Connect procedure is terminated.'' Unfortunately, removing this text (particular the text that was already existing the H.323) has caused all kinds of grief, as there are implementations that do, in fact, behave according to this text found in H.323v2 and H.323v3. I know a few people have discussed reversing this decision, but no formal proposal has been submitted. We need to have a discussion on this topic. I want to propose that the H.323v4 white paper *not* have this text removed. If people agree with that, I will bring a contribution that will propose reinstating this text. Part of the reason for its removal is that there is a race condition that can occur. For example, if the caller sends a Setup with fastStart and then later initiates H.245 while at the same time, the called endpoint returns a message with fastStart, what state is H.245 in? I believe that we can resolve the issues by documenting the fact that a race condition exists and introducing a few new rules. For example, we could say that if, as in this example above, the calling endpoint initiates H.245 and then gets a fastStart element in a message, the caller shall recognize the fact that Fast Connect was accepted. Hopefully, no logical channel signaling will have taken place. If it has, the called party should reject any conflicting channels, so the calling endpoint can recognize that a rejected channel is the result of Fast Connect being accepted and the channel is actually open (as per the FC received). I would like to see if we can come to any kind of agreement on this issue and a recommendation for a direction forward. Best Regards, Paul ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

2 1

AW: Use of two Calling Party Number IEs
by Klaghofer Karl ICN SIB NL D1 13 Jun '00

13 Jun '00

The requirement of TD-9 from Mr. Blin in Osaka was the support of two calling party numbers in H.323 (and NOT two Calling Party Number Information Elements) ! There was no agreement to intruduce a second Calling Party Number IE in H.225.0 (of course it is allowed due to the general H.323 statement that a GWY may pass on any Q.931 Information elements towards the LAN). The agreement was that such a requirement of TD-9 from Osaka is already covered by H.323 anyway, since there are at least two fields already available (Calling Party Number IE and SourceAddress) to which e.g. two Calling Party Number IEs from the SCN could be mapped to or which may be used by an originating H.323 endpoint if there is the need to signal different calling party numbers. The agreement was that the editor would add add some clarifying text (e.g. a sentence basically telling that Calling Party Number IE and SourceAddress may be used in the same SETUP message to carry different calling party numbers, if required). Regards, Karl > -----Ursprüngliche Nachricht----- > Von: Rich Bowen [SMTP:rkbowen@CISCO.COM] > Gesendet am: Sunday, June 11, 2000 16:24 > An: ITU-SG16(a)mailbag.cps.intel.com > Betreff: Use of two Calling Party Number IEs > > Mr. Blin, > > In Osaka, it was agreed as you proposed in TD-09 to add clarifying text > to H.225.0 regarding the use of two calling party number IEs. Would the > following clarification address this concern? > > A note would be added to the Setup message IE table concerning use of > the Calling Party Number IE that would state: > > Multiple Calling Party Number IEs may be present in order to > support, for example, the "Two Calling party number information > elements delivery option" defined in Annex A/Q.951 or the > interworking of H.323 and ISUP supplementary services as described > in Annex C/H.246. > > Regards, > Rich > -------------------------------------------------------------------- > Richard K. Bowen Cisco Systems, Inc. > rkbowen(a)cisco.com Research Triangle Park, NC > -------------------------------------------------------------------- > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > 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: Use of two Calling Party Number IEs
by Callaghan, Robert 13 Jun '00

13 Jun '00

Rich, As you pointed out, the information can be passed in H.225.0 v1 when it is presented at an ISDN gateway. By extension this can be true for ISUP. Therefor, there is no need for any changes. As I understand it, FT need was to have a secure Calling Party address presented to a gateway when routing from H.323 to SCN. If this is true, the case of information provided by an incoming ISDN gateway is trivial. It appears to be more important that the H.323 network providers also be able to add a secure address. On the other hand, there are better security methods available in the H.323 world (tokens) such that a secure address may not be needed for gateway security. Seperate, some IVR functions need a secure address in order to work even when a User blows a configuration. 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: Rich Bowen [mailto:rkbowen@cisco.com] Sent: Tuesday, June 13, 2000 12:53 AM To: Callaghan, Robert Cc: 'Mailing list for parties associated with ITU-T Study Group 16' Subject: Re: Use of two Calling Party Number IEs Bob, I think I understand your concern now, and I agree that there apparently has not been much consideration given to how these features would extend to H.323 terminals. My understanding of the result of the Osaka discussion is that H.225.0 should basically state, "There can be 2 Calling Party Number IEs", which is already stated in H.246 and is allowed by the statement about Q.931 transport. Do you think FT was asking for more than this? It sounds like you would prefer to see this change incorporated only as part of a broader solution that includes terminals. Would this broader solution change the fact that 2 Calling Party Number IEs could be present? I'm wondering if the terminal issue could be addressed separately. - Rich "Callaghan, Robert" wrote: > > Rich, > > Yes, this is allowed under the clause that allows any information arriving > from an ISDN gateway to be transported over the Q.931 portion of H.225.0. > It is not to be generated by any H.323 terminal. On the other hand, how > many stacks would think of this. > > The essence of France Telecom's proposal is to allow transport of a user > provided number and a secure network provided number with ISUP and ISDN as > examples. It should not be limited to ISUP or ISDN provided numbers. It > should be allowed when secure network is H.323. This requires that the > numbers be generated by H.323 terminals. This is contray to the clause > referenced in the first paragraph. Also this only works for E.164 type > numbers in that H.225.0 can only transport this type of number in the > Calling Party Number Ie. Other forms of numbers (e.g. Private Number, URL) > must be transported in ASN.1 coding. It is possible to tranport more that > one number in the Calling Party Number field; but how do you mark one as > user provided and the other network provided? > > 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: Rich Bowen [mailto:rkbowen@cisco.com] > Sent: Monday, June 12, 2000 4:37 PM > To: Callaghan, Robert > Cc: 'Mailing list for parties associated with ITU-T Study Group 16' > Subject: Re: Use of two Calling Party Number IEs > > Bob, > > Annex A/Q.951, for some good editorial reason I'm sure, is between > Clauses 3 and 4 in Q.951.3. > > My understanding from the discussion was that this option is already > allowed in H.225.0, and that we just needed to clarify that it is > allowed. > > For the ISUP case, Note 1 at the bottom of Table 56 of H.246 Annex C > states that two Calling Party Number IEs are sent in H.225.0 if the > option is supported, or that only the generic number is forwarded if the > option is not supported. For the Q.931 case, I assumed the same > approach would apply. > > I'm not sure I understand the issues about multiple private numbers or > URLs. I don't think the scope of this contribution included URLs, etc. > It was only addressing the case of receiving two calling party number > IEs from the SCN. > > - Rich > > "Callaghan, Robert" wrote: > > > > Rich, > > > > We did not agree to a delivery method in Osaka. I certainly would like to > > review any proposed method before agreeing. > > > > I could not fine Annex A/Q.951; could you help. > > > > In all probability, it proposes the duplication of the Calling Party > Number > > IE; each with individual presentation and screening controls. How does > this > > map to H.225.0? How do you have private number each with individual > > presentation and screening controls? Does this include multiple URLs, > > E-mail address, etc.? > > > > 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: Rich Bowen [mailto:rkbowen@CISCO.COM] > > Sent: Sunday, June 11, 2000 10:24 AM > > To: ITU-SG16(a)mailbag.cps.intel.com > > Subject: Use of two Calling Party Number IEs > > > > Mr. Blin, > > > > In Osaka, it was agreed as you proposed in TD-09 to add clarifying text > > to H.225.0 regarding the use of two calling party number IEs. Would the > > following clarification address this concern? > > > > A note would be added to the Setup message IE table concerning use of > > the Calling Party Number IE that would state: > > > > Multiple Calling Party Number IEs may be present in order to > > support, for example, the "Two Calling party number information > > elements delivery option" defined in Annex A/Q.951 or the > > interworking of H.323 and ISUP supplementary services as described > > in Annex C/H.246. > > > > Regards, > > Rich > > -------------------------------------------------------------------- > > Richard K. Bowen Cisco Systems, Inc. > > rkbowen(a)cisco.com Research Triangle Park, NC > > -------------------------------------------------------------------- > > > > ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > 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. > rkbowen(a)cisco.com Research Triangle Park, NC > -------------------------------------------------------------------- ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ For help on this mail list, send "HELP ITU-SG16" in a message to listserv(a)mailbag.intel.com

1 0

Final Corrections to H.225.0v3
by Paul E. Jones 13 Jun '00

13 Jun '00

Folks, As many of you know, there were a number of errors found in the H.225.0v3 ASN.1. Attached to this e-mail, please find a Microsoft Word file that contains revision marks for the ASN.1 portion of the Decided H.225.0v3 document. I have prepared an ASN.1 file that *should* contain the complete and up-to-date H.225.0v3 ASN.1. You can find it here: http://www.packetizer.com/iptel/h323/ *Please* if you find any errors in these ASN.1 files, let me know *now*. There are a number of Implementers who are planning to bring their V3 products to the SuperOp next month. More importantly, H.323v3 has been in a decided state for quite some time now and folks need to be aware of these errors, because products are shipping! These errors represent every known error that needs to be applied to the H.225.0v3 ASN.1. If any errors are found in the future, we will likely not fix them unless backward compatibility is completely broken. As you all know, making changes to the ASN.1 once a product is in the customer's hands is not the best way to go about pleasing a customer :-) Best Regards, Paul E. Jones Editor, H.323 and the H.323-series Implementers Guide

1 0