Subject: [Enum] For context around the carrier enum discussion - voip peering BoF in Paris

From: Allison Mankin <[email-masked]>
Date: Fri, 08 Jul 2005 10:35:52 -0400

Hi,

We're interested in your input and participation in this,
and think it's important context for this discussion of
enum use by the carriers.   

We're making sure it's scheduled not to conflict with
either enum or the major working groups pertinent to 
VoIP.

Please jump in...

Allison

(Your AD)

VoIP Peering and Interconnect BOF (voipeer)
August, 2005

Name:                VoIP Peering and Interconnect BoF (voipeer)
Chairs:              Dave Meyer

AGENDA:
--------
 5 min   Agenda bashing                               Chair(s)
10 min   Goal and purpose of the BOF                  Chair(s) (+ ADs?)
25 min   Description of the problem/problem space     TBD
30 min   Other presentations, to be confirmed         TBD
80 min   Open Discussion                              All

DESCRIPTION:
---------------

The term "VoIP Peering" has been used to describe many different
aspects of provider interconnect and the delivery of SIP call
termination over that interconnection. Further, since VoIP
peering focuses on how to identify and route calls at the
application level, it does not (necessarily) involve the exchange
of packet routing data. Given that VoIP peering is about routing
calls, it includes (among other things) the accounting of costs
that may be incurred in the use of any of these routes, the
actual transport protocol of those media streams (or the details
of those media streams), the IP network or criteria for the
transport IP network,the signaling protocol that is used for
transporting call-routing information, etc. Thus, given the broad
scope of the topic, this BOF proposes to focus on the following
objectives:

(i).	To initiate long term discussion on VoIP Peering and
	Interconnect among the Internet's operational
	community, with the goal of understanding the existing
	and future requirements for VoIP Peering and
	Interconnect. In particular, since VoIP peering is really
	about how to identify and route calls at the application
	level, it brings requirements from both transport
	providers and application vendors, as well as many other
	third parties. One possible outcome of this would be to
	charter a VoIP Peering and Interconnect Working Group
	(area TBD).

(ii).	To address the near-term need to document the
	requirements and associated use-cases for VoIP
	interconnect. Such requirements can be used to inform
	protocol groups working on relevant protocol mechanisms.

The focus of the proposed work will be on documenting VoIP
Peering and Interconnect use cases, defining their requirements,
and describing what can be done in support of those use-cases and
requirements with the Internet technology (and its dual, namely,
what can't be done with the Internet technology).

Issues for voipeer include (but are not limited to):

 (a).	Call Routing

	That is, how to figure out who to route calls to. Options
	include SIP, ENUM (public v. private ENUM, carrier ENUM,
	etc). Further, several protocols have been proposed to
	carry enhanced call routing information, such as RFC3219
	(TRIP). Are these necessary, and if so, are there
	complexity concerns?

 (b).	ENUM

	How ENUM is currently being deployed/used, what are the
	barriers to deployment, if any, and how can we further
	facilitate its deployment. Other related topics include
	number portability, as well as directory and other
	enhanced routing requirements. 

 (c).	Security

	Includes topology and provider hiding, DoS prevention,
	authorization, and VoIP Spam mitigation (e.g., SPIT).

 (d).	Accounting

	That is, how to track calls made to and from each peer,
	including TOD, duration, packets send and received, etc.

 (e).	Audit

	Including how to determine where in the call path a fault
	lies, per-call accounting of call quality (most providers
	are looking for end-to-end call quality). Accounting of
	ASRs (and other PSTN call metrics, for PSTN termination
	peers only).

 (f).	PSTN Fallback

	Issues here include what to do if the IP network is
	congested, how to do PSTN fallback, and interaction with
	call routing and IP network congestion measurement and
	monitoring.=20

 (g).	Feature Interoperability=20

 (h).	Lawful Intercept

	Will be discussed within the IETF's RAVEN principles.

 (i).	Interaction of (a)-(h) with current/future Session Border
	Controller (SBC) deployments

MAILING LIST:
-------------
voipeer at lists.uoregon.edu

To subscribe, visit
http://darkwing.uoregon.edu/~llynch/voipeer.html or send
mail to majordomo at lists.uoregon.edu and subscribe voipeer

DRAFTS
------
None

_______________________________________________
enum mailing list
enum at ietf.org
https://www1.ietf.org/mailman/listinfo/enum

---

From: Richard Shockey <[email-masked]>
Date: Fri, 08 Jul 2005 12:05:00 -0400

At 10:35 AM 7/8/2005, Allison Mankin wrote:
Hi,
We're interested in your input and participation in this,
and think it's important context for this discussion of
enum use by the carriers.
We're making sure it's scheduled not to conflict with
either enum or the major working groups pertinent to
VoIP.
Please jump in...
Allison
Well Allison - Dave ...first thing ..would the BOF want a status report 
from the ENUM WG on A. Where 3761 deployment actually is and B.  what the 
ENUM WG is actually discussing on the interconnect peering issues?

That is now practically our entire agenda for Paris.
We could also discuss why have certain (to remain nameless) equipment 
suppliers been reluctant to incorporate 3761 compliant DNS resolvers into 
their service processing logic. I'm sure lots of folks would be interested 
in that topic :-)

(Your AD)
Name:                VoIP Peering and Interconnect BoF (voipeer)
Chairs:              Dave Meyer
First thing I would say is this is not just about VoIP ..its about advanced 
service peering and interconnection among service providers.

As anyone in this WG knows the entire issue of Infrastructure  ENUM was in 
part initiated by some very serious requirements coming out of the wireless 
industry for MMS as well as IP based SMS routing.

What was manifestly self evident to the wireless industry was the existing 
SS7 signalling and transport infrastructure was not designed for this class 
of peering nor did anyone have the desire to expand the scope of SS7 handle 
large either real-time or store and forward data objects. Consequently 
numerous vendors and equipment suppliers saw in 3761 technology a quick and 
technically effective solution to the problem.

Numerous vendors and service providers quickly responded to the market 
opportunity and now there is a vigorous and competitive market for Carrier 
ENUM services in the MMS routing market and this BTW had nothing to do with 
SIP .. MMS transport is generally delivered via SMTP URI's. Though I'm one 
who believes that SIP signalling would have actually been more effective in 
overcoming the data normalization issues.

AGENDA:
--------

Richard Shockey, Director - Member of Technical Staff
NeuStar Inc.
46000 Center Oak Plaza  -   Sterling, VA  20166
sip:rshockey(at)iptel.org   sip:57141 at fwd.pulver.com
ENUM +87810-13313-31331
PSTN Office +1 571.434.5651 PSTN Mobile: +1 703.593.2683,  Fax: +1 815.333.1237
<mailto:richard(at)shockey.us> or <mailto:richard.shockey(at)neustar.biz>
<http://www.neustar.biz> ; <http://www.enum.org>
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
_______________________________________________
enum mailing list
enum at ietf.org
https://www1.ietf.org/mailman/listinfo/enum