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@ICN.Siemens.com
------------------------------------------------------------------
-----Original Message-----
From: Paul E. Jones [mailto:paulej@PACKETIZER.COM]
Sent: Monday, June 19, 2000 3:15 AM
To: ITU-SG16@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@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@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@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@icn.siemens.com>
To: "'Orit Levin'" <orit@radvision.com>; "'Paul E. Jones'"
<paulej@PACKETIZER.COM>
Cc: "Mailing list for parties associated with ITU-T Study
Group 16 (E-mail)"
<ITU-SG16@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@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@radvision.com
-----Original Message-----
From: Callaghan, Robert <Robert.Callaghan@icn.siemens.com>
To: 'Paul E. Jones' <paulej@PACKETIZER.COM>; 'Orit Levin'
<orit@radvision.com>
Cc: Mailing list for parties associated with ITU-T Study
Group 16 (E-mail)
<ITU-SG16@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@ICN.Siemens.com
------------------------------------------------------------------
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
For help on this mail list, send "HELP ITU-SG16" in a message to
listserv@mailbag.intel.com