H.323 URL

Callaghan, Robert Robert.Callaghan at icn.siemens.com
Fri Jun 16 08:38:59 EDT 2000


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



More information about the sg16-avd mailing list