H.323 URL Specification

Paul E. Jones paulej at PACKETIZER.COM
Fri Sep 1 10:49:58 EDT 2000

For those who are interested in CPL work and other IPTEL activities, I am attaching the "IPTEL minutes" from IETF48 by J. Rosenberg. I am also posting the SG-16 "CPL liaison" (TD-44d) on the IPTEL reflector. 
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
orit at radvision.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.packetizer.com/pipermail/sg16-avd/attachments/20000901/3023c4a9/attachment-0001.htm>
-------------- next part --------------
Minutes taken by: Flemming Andreasen
                  Hussein Salama
Minutes Edited by: Jonathan Rosenberg

IPTEL met for a single 2.5 hour session during IETF 48 in Pittsburgh.


  *     Agenda bashing
  *     CPL open issues, Jonathan Lennox
  *     TRIP ope issues, Hussein Salama
  *     TRIP-GW update, Jonathan Rosenberg
  *     transit networks in TRIP, Dave Walker
  *     H.323 URL, Orit Levin
  *     Service Routing, Jonathan Rosenberg

CPL Open Issues

Jonathan started by describing the changes in revision 2 of the CPL
specification. THe main changes were:

  *     Time handling reworked: matches iCal
  *     H.323 mappings
  *     XML and MIME types
  *     New string switches: language , display
  *     Enhancements of Node

Time handling was the biggest change:

  *     moved from crontab format to iCal (RFC 2445 - Proposed Standard)
  *     makes it easy to create CPL srcitps automatically from calendars
  *     rich syntax
  *     complicated to evaluate (interoperatbility problems reported,
  some bugs in spec) 

Jonathan expressed concerns about complexity - was it really worth it?
He asked for pseudo-code implementation to see implementation
feasibility and ambiguity. Are there translation problems between
formats (e.g. calendar to iCal). Long term we probably need the
capabilities it provides us with, but really need to implement and see
that it works unambigously. Don't want to have lots of different
formats (SDP, iCAL, something else)

Further time change: time zones.

Time zones also derived from 2445.
Time-switch nodes have two new attributes:
  *     tzid (time zone identifier: server-local or from a
  to-be-defined IANA registry) 
  *     tzuel (time zone URL: reference to a RFC 2445 VTIMEZONE)
  <time-switch= tzid="America/New-York"

VTIMEZONE is basically the same (semantic) rules as new time definition
Work is (slowly) in progress to create an IANA iCal timezone registry
based on the Olson TZ database. 

Jonathan Rosenberg (JR): Is this (iCal) really going to happen ? Real
problem that people in different tz. wants to upload CPL scripts and
if iCal doesn't happen we then don't have nothing.  
Henning Schulzrinne (HS): We don't have anything else
realistically. Even Windows uses something similar. 
JR: There needs to be pseudo-code to show how to do this. If we get
that, then we will continue with this proposal. 
JR: As for timezone, sync up with iCal people - we need something that
works now (consensus on this) 

Another change: H.323 bindings: address types

  *     Mappings defined for H.323 address types.
  *     H.323 has addresses both in Q.931 part and H.323 UUIE
  part. Not clear which one takes precedence, but server should use
  same rules for CPL as it uses for routing. 

Orit Levin: Complicated issue in H.323 (there are other compl. issues
in H.323 as well). Shouldn't this be done in conjunction with the
H.323 community.  
Jonathan Lennox (JL): Tried doing it on the list. 
Orit: Annex O work to begin in SG-16 in two weeks (looking at
Internet). Should submit this to SG-16 and ask for feedback. 
JR: Prepare a list of questions to SG-16, give to Orit for resolution.

Specific H.323 mappings
  *     H.323 alias address have ~8 different possible formats
  *     Define mappings for each of these into CPL address subfields (done)
  *     also define new alias-type address subfield for H.323 servers
  *     Based on H.323v4, to be publishd in November; introduces H.323
  URL scheme. Is this a problem for last call ? 

OL: Once you have H.323 URLs, why would you want to take the URL apart
and map into different address subfields 
JL: Because we still have the old stuff around.
OL: Some more comments about mapping concern between H.323 and SIP
(addresses and messages) 
OL: SG-16 should talk about how to use H.323 with CPL (better qualified)
JL: Agreed that there should be joint work here. If ITU wants to help
then fine; we have been asking for their input for a while.

It was agreed that we would not hold up CPL waiting for the H.323v4 or
H.323 URL work. Scott confirmed that a proposed RFC cannot have
normative references even to other standards work that is not
complete. So, H.323 URL and other newer stuff will be relegated into
an optional appendix.

Another change: Mime Registration

Added MIME registration section
Media type application/cpl+xml

Conforms to format of XML types in draft-murata-xml-06.txt.

Another change: Parameters, considereations, file extensions

Specified XML public identifier "-//IETF

Specified XML namespace
"http://www.ietf.orginternet-drafts/draft-ietf/iptel-cpl-02.txt" to be
"http://www.rfc-editor.org/rfc/rfcxxxx.txt" when we go to RFC 

New string-switch fields

New string-switch field: language. This is the language caller wants
to receive.

display-field: corresponds to Q.931 display IE

Changes to location nodes

Documented attribute clear of location and lookup nodes. 
  *     Is this really ncessary, given remove-location location ="*"

changes to proxy and reidirect nodes

added output redirection to proxy nodes

Other changes

  *     Weakened server support for scripts that do not conform to the
  DTD from SHOULD to MAY 
  *     Clarifications
  *     More examples
  *     DTD updated

Todo and proposed enhancements
  *     Add q parameter to location nodes (needed for priority order)
  *     Draft asserts H.323 has no equivalents 
  *     Clarify how extensions should work: XML namespaces. 
  *     Complaints about default timeout value for proxy being
  dependent on whether noanswer output is present or not. Jonathan
  R. initially raised this concern but has relented, as it makes the
  most sense. So, we will specify that the default timeout value is
  dependent on the presence of noanswer. 

HS: So where are we ? Ongoing implementations, not a lot of
operational experience, let people go home and code. Recommend be last
IETF presentation before Last Call. May not be the final answer for
CPL, but should suffice for version 1.0 

HS: Related work: currently non-overlapping, but may change: Voice-XML. Two concepts from vXML to look at (didn't catch what they were, variables (?) ).
JR: Agreed. Fix up the H.323 and timezone stuff. No more
presentations. Namespaces allow us to add stuff later.  
OL: Who is going to implement the H.323 stuff and verify it. 
JR: We can leave it in there. If nobody implements, then can remove
before going go Draft Standard. Soliciting input from H.323 community,
have done for 1+ year, continue to do, don't know what more we can do.  
OL: What if it turns out that changes are needed to be suitable for H.323
JR: We'll have to see what the outcome is.
Scott Bradner (SB): Can always modify and recycle as Proposed Standard
if changes needed 
JR: Better to get it before going to Proposed. 
HS: Let's set a deadline for people to move forward
JL: what about H.323 URLs 
SB: can't be a normative reference if still not a standard
(H.323v4). Move reference to an appendix. Can always move back when
H.323v4 solid.  

TRIP Open Issues
Hussein Salama

Hussein Salama prsented the recent changes and Open Issues for TRIP.

Next Hop Server Format
  *     Comment from Adelaide: to represent the next hop server by
  domain name or IP address in DNS format 
  *     Open issue: Transport type: UDP/TCP
  (proxy.ietf.org.transport-tcp).. do what SIP does. 
  *     Open issue: Representation of IPv6 addresses in TRIP. 

JR: Do what SIP does for transport; for IPv6, there is an rfc that
defines the representation of IPv6 inside of URLs, which works for us.


  *     Currently: route types supported and Send Receive Capability
  *     IANA considerations
  *     Reserved capability code 0
  *     Capability codecs 32768 to 65535 for vendor-specific capabilities
  *     Open Issue: making "route types supported" mandaty
  E.g. may only be interested in SIP or H.323 routes.
  *     Open Issue: adding "Capability Mismatch" error code

Communities Membership Capability
Based on BGP communities
Permits an LS (Location Server) to announce to its peer the
communities it is interested in. The peer then only advertises to the
LS routes of those communities.

Attribute Type Codes
Assigned type codes to all attributes.
IANA considerations.
Reserved type codes 224 to ?

Application Protocols
Added two new apl. protocols RAS and H.323 Annex G.

Address Families
Letters other than 10 digits used in Europe.
Had to deviate from IANA's standard set of address families.
Define two address families
  *     POTS numbers: private, local, national, and internation (0-9)
  *     routing numbers: mainly for European LNP (0-9, A-F)
IANA considerations
May want to deifne other address families in the future, e.g. URL. 

ITAD numbers
Reserved ITAD numbers 0 and 65535
ITAD numbers 64512 to 65534 are for private use
IANA considerations
Proposal: Use domain names instead of ITAD numbers. Issues:
  *     No need for IANA registration
  *     ITAD topology restrictions
  *     Effect on AdvertisementPath and RouterPath attributes (domain
  name would imply long attribute names) 

SB: Running into trouble with 16-bit fields for AS. Change to
something bigger for ITAD. 

MED and Tie Breaking Rules
Removed inconsistency

  *     MED usage consistent. Higher MED is preferable
  *     Changed tie breaking rules to favor internal routes over
  external routes 

Secuurity considerations
Protection of peer sessions using IPSec
  *     Transparent mode security association
  *     Either AH or ESP

Protect route itself over multiple hops:
  *     Sign critical attributes of the route
  *     Include list of signatures in Authentication attribute. If
  intermedia changes, must remove signature and resign itself 
  *     Open Issue: What signature mechanism to use ? 

UPDATE Rate Limiting
not yet updated (Adelaide issue - check) 

Application Protocol Manipulation
ex: receive SIP route, want to advertise as Q.931 route.
not manipulating an attribute, really chaning the route, not really
comfortable with this, what could be the possible side-effects be ?  

JR: Difference between this and TRIP is that TRIP is an app protocol
Jon Peterson: Concern about feature transparency loss due to
translation (wouldn't be visible from routing info). 
JR: Maybe there's another attribute needed to signal whether
transparency loss may result.  
Hussein: Could add an attibute similar to what we do for route aggregation
JR: OK, consensus is to add that to the spec. 

Multiple TRIP Ids per LS
An LS MUST use the same TRIP ID with all internal peers.
Question: what's the significance of TRIP ID between external
peers. Can we have a different TRIP ID with different external peers?

JR: In the interest of KISS, since we can't think of a reason to do
it, just keep as single ID (consensus) 

ITAD boundaries
follows BGP model. Two possibilities:

* On the link between two LSs
* On the LS itself. Splits the LS box into two (or more) virtual
LSs. Permits route summarizatioin of TRIP-Lite routes. 

Allows integrating TRIP-Lite with TRIP. No changes to protocol seems
to be required.  Seems straightforward - would like to allow it.  

JR: Work has been going on for a while. Only minor stuff
remains. Finish off for next meeting (similar to CPL).

TRIP for Gateways (TRIP-LITE)
Jonathan Rosenberg

Got mixed feedback in Adelaide, want to convince everybody it's a good idea.

Gateway Management
Problem: need a way to manage routing of calls to heterogenous
gatewasy within service provider 
  *     Depends on liveness
  *     Depends on availability (capacity, etc.)
  *     Depends on matching capabilities of call
  *     codecs
  *     extensions
  *     Depends on cost of termination

Can TRIP be used ?
TRIP provides routing exchange inter-domain
Very similar problem
  *     keepalives
  *     prefix propagation
  *     attributes and capabilites
Scope of information restricted due to scale
Scale issues different intra-domain
  *     Can add additional information needed to support GW management
  *     Can update information more frequently

Thus, need a profile of TRIP

Not a new protocol
Profile of TRIP
  *     Used particular components
  *     No aggregation or redistribution - that's normal TRIP
  *     Additional attributes for this configuration

SB: It really shouldn't be called anything saying TRIP (marketing
confusion). Profiles are a way to say that the original protocol was
to complicated. Call it something else 
Jon Peterson: Are you sure you want to disallow aggregation? What if I
want to build a complex intra-domain network with routes propagated
and aggregated among LS's within the domain?
JR: Well, then you are really entering TRIP territory. On the other
hand not clear how that would work if you had a single ITAD
number. Need to think a little more about it.  
Sinnreich: Helps avoid provisioning.

Benefits of TRIP-GW
Information readily exported to normal TRIP interdomain
Allows rapid detection of gateway failures and rerouting 
Supports heterogenous gateway farms

Huitema: Defining internal BGP for telephony and that's not a good
idea. BGP is lousy for that. Really want to have some kind of special
purpose. Doesn't seem like the right tool for the job 
JR: Has benefits beyond provisioning. 
HS: Not clear this is a good fit. SLP would seem a much better
fit. Service discovery is what you want 
JR: Disagree - SLP is a pull mechanism. Want a push mecanism. 
HS: No. can do service advertisement (at a small scale)
JR: Not convince SLP the right tool, e.g. keepalives
HS: Disagree. May be that a service push protocol is needed, but
really not clear that TRIP is the right choice.  
Sinnreich: Need to differ between architecturally correct solutions
versus short term deployable mechanisms that may not be perfect, but
are usable. 

WG proposal

JR: Not consensus obviously. Think about the intra-domain routing
problem. Two questions 
1.      Is this problem something we want to address. 
2.      What are the requirements?

Rohan:          Go ahead and use TRIP
Orit:           Really a problem. 
Hussein:        Really two problems. Gateway registration, internal
routing, external routing 
Jon Peterson:   May want to have multi-criteria routing
Radhika Roy:    May not want to use TRIP. 

JR: Problem can be split into two:
  *     Propagation of information to proxy from a gateway
  *     Propagation of information between proxies

JR: Consensus to adopt this problem as a working group item (not using
TRIP, but looking at problem)? YES.
Transit Networks
Dave Walker, SS8

TRIP distributes routes based on E.164 numbers

Sometimes need to route based on carrier however.
Transit network selection indicates (ordered sequence of) preferred carriers
  *     Q.931 setup, ISUP IAM
National identification plans
  *     ANSI ISUP: 4 digits (0-9, B,C) administered by NANPA

Why should this matter to IPTEL? In the near future, have to allow
users access to both IP and PSTN based carriers. Could try to route to
gateway nearest destination, then local PSTN call, but
want to provide "best" route into the specified network.

TRIP based solutions:

Proposal 1 - New address family
route on TN reagardless of dialed number (excl CAC)
new database key value (currently POTS, RoutedNumber)
  *     POTS, RN still advertised separately (useful if TN not selected)

issue: call signaling may be sup-optimal
  *     correct route may require both E.164

Proposal 2 - new attribute type
TN is an optional attribute of E.164 ReachableRoute
  *     flexible
  *     reachign all E.164 (ie. "*") equivalent to new address family
can use existing TRIP DBs with addition of new key

issue: complexity
  *     affects E.164 aggregation

What's next
chose best proposal
ensure all national plans satisfied
clarify intra- & inter-domain behavioral differences
  *     e.g. does carrier prefer internal gw to TN over own external 
meet requirements of section 5.12 for new attribute specification
describe use of TN is SIP-URLs

Hussein: Three questions:
  *     Why always have country-code as part of identifier. Answer:
  May look into that 
  *     Using attributes proposal: problem is you get two routes and
  TRIP would drop one of them. Answer:  draft explains this. route
  selection would have to change 
  *     First proposal with separate AF. We would need to correlate
  them somehow.  

JR: This seems a clearcut case of a new attribute (your second

Jon Peterson: Would be nice if you could like at the TRIP-GW problem. 

Dave: Draft just intended to introduce problem and get discussion going. 
Henning: Country code poor selection as many providers exist in
multiple countries. Think about roaming.  
Dave: Many scary scenarios. E.g. if going to Europe and carrier is US,
then may end up routing calls back to US. Can talk about all this
stuff in a future draft. 

We agreed that the second proposal is better. However, the proposal
requires more work, mainly in two areas:
        - specify how aggregation will work
        - specify how "searching the RIB" will be affected. Previously
the two search keys were address and application protocol. Now the CIC
attribute is a third search key. Significant change.

H.323 URL
Orit Levin

  *     publish H.323-URL definition as an Informational RFC
  *     Register H.323-URL with IANA

H.323-URL use
A pointer to H.323 "service"
  *     To be carried in H.323 messages
  *     To be used in web-pages
  *     etc.

H.225.0 "Alias" Definition
H.323 URL part of H.225.0 Alias

H.323v4 to be decided in November.

H.323-URL Syntax
Have a definition proposed and would like to solicit comments
URL can only have a user-part and a host-part. 
H.323 URL resolution not based on DNS resolution solely (obviously).
  *     The H.323 URL host portion is Case Insensitive
  *     The host numbers are defined to be used without square brackets
H.323 specific issues
  *     GK identifier as a part of "host" portion (using UNICODE, so will probably have to restrict to ASCII use)

Rohan: Any parameters proposed ?

H.323-URL will be included in H.323v4
H.323v4 discussion/decision due by the end of August 2000
H.323-URL will be maintained and developed as a part of H.323 Annex O "Internet Technologies Complementary to H.323"
Additional parameters are for consideration

Registration of the URL scheme
According to BCP-35 (RFC 2717)
Two alternatives for registration of the "scheme name"
  *     IETF tree
  *     An alternate (ITU ?) tree

Would like to get some guidance on which way to go here. 

HS: What's the practical implication on having an ITU tree ? Answer: don't know
HS: Talk to Patrik Faltstrom for guidance
HS: User-name or host-name missing distinction was unclear. Problem is
that <SIP: foo> will mean something different than <H323:foo>. SIP
will refer to host foo, where as H.323 will refer to user foo. Of
course clear within each scheme, but somewhat confusing. 
OL: Well, the scheme-name makes it clear what it means. 
Lennox: Conventional to write URL-schemes in lower-case (h323 rather
than H.323).  
Lennox: H.323 has slew of alias addresses. Scheme wouldn't allow all
of these to be represented in the URL, e.g. "call this E.164 number".  
OL: Discussed, but couldn't reach consensus. 
Lennox: Add text explaining this in draft.
Lennox: How do you use it ? Send it to the GK which then goes through
the whole 323 enchilada. Should describe that a little in the draft.  
OL: Annex O describes this.
Huitema: IETF or ITU tree question: Should go for the IETF tree. RFC
publish will guaranteee IETF review. URL not used only within
H.323. Could very well be used in SIP e.g. to place a call to an H.323
Huitema: Can enter any kind of URL ? 
OL: Yes. So can easily map between SIP and H.323 URLs.  (Not sure I
captured this discussion correctly) 
OL: prefer IETF tree as well. would like IETF review as well. Will
contact Patrik and ask for his input.  
OL: registration process is urgent

JR: take what you have, resubmit with lower case, inform IESG that you
would like published as Proposed Standard (not Informational), they
will look a working group/people to review it.  

Service Routing
Out of time. Will post to the list. 

Meet at the IETF message board for the security meeting

More information about the sg16-avd mailing list