H.323 Annex M.1 White Paper
Francois Audet
audet at NORTELNETWORKS.COM
Fri Jun 16 14:22:26 EDT 2000
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 at ICN.SIEMENS.COM]
> Sent: Friday, June 16, 2000 5:39 AM
> To: ITU-SG16 at 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 at ICN.Siemens.com
> ------------------------------------------------------------------
>
>
> -----Original Message-----
> From: Paul E. Jones [mailto:paulej at 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 at icn.siemens.com>
> To: "'Orit Levin'" <orit at radvision.com>; "'Paul E. Jones'"
> <paulej at PACKETIZER.COM>
> Cc: "Mailing list for parties associated with ITU-T Study
> Group 16 (E-mail)"
> <ITU-SG16 at 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 at ICN.Siemens.com
> > ------------------------------------------------------------------
> >
> >
> > -----Original Message-----
> > From: Orit Levin [mailto:orit at 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 at radvision.com
> > -----Original Message-----
> > From: Callaghan, Robert <Robert.Callaghan at icn.siemens.com>
> > To: 'Paul E. Jones' <paulej at PACKETIZER.COM>; 'Orit Levin'
> > <orit at radvision.com>
> > Cc: Mailing list for parties associated with ITU-T Study
> Group 16 (E-mail)
> > <ITU-SG16 at 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 at ICN.Siemens.com
> > >------------------------------------------------------------------
> > >
> >
>
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> For help on this mail list, send "HELP ITU-SG16" in a message to
> listserv at mailbag.intel.com
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.packetizer.com/pipermail/sg16-avd/attachments/20000616/7cbe9437/attachment-0001.htm>
More information about the sg16-avd
mailing list