voip peering – a snapshot

May 22, 2006

VoIP peering – a snapshot

Henning Schulzrinne

w/Charles Shen

Dept. of Computer Science

Columbia Universityhttp://www.cs.columbia.edu/~hgs

May 22, 2006

Overview

• Review: What is VoIP peering?• Why VoIP peering?• Scaling peering to millions of users• Challenges for VoIP peering• Beyond PSTN replacement• Resources

May 22, 2006

What is VoIP peering?

• Definitions from IETF SPEERMINT Working Group:– “Peering … refers to the negotiation of reciprocal interconnection

arrangements, settlement-free or otherwise, between operationally independent service providers.” (draft-ietf-speermint-res-and-terminology-01)

– Layer 5 peering refers to interconnection of two service providers for the purposes of exchanging SIP signaling. Note that in the layer 5 peering case, there is no requirement for any intervening "Layer 5 Transit Network". Each service provider is expected to interconnect directly with other service providers, although a service provider is allowed to interconnect through another domain

(ex: a federation) to act on its behalf. (SPEERMINT, IETF 65)

• Cable Labs– “The notion of IP Service Peering (and VoIP Peering) … extends the relationship

between network operators above the IP layer, by handling the IP-based services and applications that can be exchanged.”

May 22, 2006

Why VoIP peering?

• Near-term motivations– avoid PSTN hops between VoIP service providers– codify provider trust relationships– bridge wait until global ENUM

• Longer term motivations– no PSTN in the middle

• advanced signaling services

• no transcoding better audio quality

• wideband audio codecs

• video, IM, …

– possibly increase in trust• smaller number of players spam, spit

May 22, 2006

Why is VoIP peering needed?

• Non-reasons– SIP: providers can talk directly to each other if SIP URIs are

available• sip:[email protected] look up SIP server for example.com

(NAPTR, SRV) and connect• email-like no email peering

– L3: probably best to avoid triangle routing

• Reasons– E.164 numbering: who serves the customer with +1 212 555

1234?• absence of global ENUM

– interoperability– billing

May 22, 2006

Session interconnect

E.164number

SIPURI

host name

IPaddress

MACaddress

peer discovery

ENUM lookup of NAPTR in DNS

aka call routing data (CRD) derived from ENUM record

service location (lookup of NAPTR and SRV) in DNS

lookup of A and AAAA in DNS

addressing and session establishment

routing protocols, ARP, …

May 22, 2006

Peering evolution

PSTN PlanePSTN Plane

VSPVSP

VSPVSP

VSPVSPVSPVSP

VSPVSP

VoIP Service Providers interconnect via PSTN using E.164 numbers for addressing

+4315056416

Otmar Lendl, March 2006 (SPEERMINT)

May 22, 2006

PSTN PlanePSTN Plane

Messy reality

VSPVSP

VSPVSP

VSPVSPVSPVSP

VSPVSPsip:[email protected]

Public InternetPublic Internet

Private Interconnection NetworkPrivate Interconnection Network Private Interconnection NetworkPrivate Interconnection Network

Closed SIP federationClosed SIP federation

Otmar Lendl, March 2006 (SPEERMINT)

May 22, 2006

Example: Cable operators

• MSOs want to avoid PSTN traversal• Call Management Server Signaling (CMSS) = SIP

Administrative Domain 1



MSO AZone 1

MSO AZone 2

MSO BZone 3

MSO CZone 4

PSTN Gateway PSTN

PSTN Gateway PSTN

PSTN Gateway PSTN

`

`

`

``

CMS

ManagedIP Backbone

CMS

CMS

CMS

SIPServers

SIP

CMSS

SIP

CMSS

SIP

CMSS

Jean-François Mulé, IETF 63

May 22, 2006

Peering: decomposed model

domain A domain B

draft-penno-message-flows-02

May 22, 2006

Peering: collapsed model

~~~~~~~~

~~~~~~~~

domain A domain B

B2BUA


May 22, 2006

Peering authorization

• On-demand– “email model”– as needed when exchanging

SIP messages– usually, mutual TLS

authentication– proposed

SUBSCRIBE/NOTIFY key exchange

• Static– established ahead of

signaling– e.g., TLS or IPsec– proposed

SUBSCRIBE/NOTIFY key exchange

INVITE

SUBSCRIBE w/PeerAuth

401 Unauthorized

SUBSCRIBE w/auth

100 Trying

202 Accepted

NOTIFY w/P2key

INVITE

401 Unauthorized

INVITE + P2Key

100 Trying

INVITE

P1 P2


May 22, 2006

Role of ENUM in peering

• Core service: look up provider for E.164 number• ENUM models

– Public ENUM: e164.arpa– Private ENUM: limited access to DNS records (e.g., by VPN)– Carrier ENUM:

• Options:– resolve to subscriber SIP URI

• +1 212 555 1234 sip:[email protected];user=phone

– resolve to neutral peering provider• +1 212 555 1234 sip:[email protected];user=phone• peering.com proxy translates to actual provider

– resolve to carrier ENUM DNS server• +1 212 555 1234 enum.vsp.com NAPTR query on enum.vsp.com

– service provider identifier (SPID)• +1 212 555 1234 NXXX

May 22, 2006

• Take an E.164 number

• Convert it to FQDN

• Query DNS for NAPTRs

• Apply resulting regexs to get list of URIs:

ENUM in a Nutshell

+1-734-913-4257

7.5.2.4.3.1.9.4.3.7.1.e164.arpa.

sip:[email protected]:[email protected]:[email protected]

e164.arpa.

1.e164.arpa.

4.3.7.1e164.arpa. x.x.x.1.e164.arpa.

Ben Teitelbaum, John Todd, Dennis Baron:“ISN Numbers: Fast, Free, and Forever Yours” March 16, 2006 Spring VON, San Jose, CA

May 22, 2006

Who serves an E.164 number?

• Find “point of interconnection” (PoI) for given E.164 number

• Peering provider can answer question locally• Likely to have dozens of such peering exchanges and

federations– each provider will be a member of some subset of these

• Kludge: originating provider asks all its peering providers in parallel– via DNS ENUM lookup

• Possibly federate peering providers– flood number information, pointing to peering ENUM– multiple resolutions can’t be DNS

May 22, 2006

Carrier (infrastructure) ENUM

• User ENUM– “entity or person having the right-to-use of an E.164 number has

the sole discretion about the content of the associated domain and thus the zone content” (draft-haberler-carrier-enum-02)

– end user as registrant

• Carrier (now, infrastructure) ENUM– "carrier of record" (COR) as registrant

• Proposal: branch under e164.arpa:– 4.9.7.1.carrier.e164.arpa or– 4.9.7.carrier.1.e164.arpa

May 22, 2006

Carrier ENUM

• COR = registrant– block holder allocated by National Regulatory Authority (NRA)– "International Networks" (+882) or "Universal Personal

Telecommunications (UPT)" (+878) allocated by ITU– recipient of a port (service provider)– has been contracted by a user to route a number assigned to a

user directly (without COR being in the number assignment path)

• corporate network numbers

• 800/900 type numbers in many countries

• Include all E.164 numbers in block– avoid ability to detect listed vs. unlisted numbers

May 22, 2006

Provider hiding

• Some providers worry about exposing their identity to competitors– competitors could target customers for marketing efforts– unclear if more than theoretical issue

• Solution:– send calls to peering provider SIP proxy, not directly to VSP

proxy• ENUM: [email protected]

– peering provider does database (or internal ENUM) lookup

May 22, 2006

Challenge: provisioning ENUM entries

• Dynamic DNS not suitable: security, scaling• Options:

– bulk upload via ftp, HTTP, …– EPP (Extensible Provisioning Protocol) – RFC 3730

• XML-based protocol designed originally for domain number management

May 22, 2006

SPEERMINT discussion: federations

• A federation is a group of VoIP service providers / enterprises which– agree to receive calls from each other via SIP– agree on a set of administrative rules for such calls (settlement, abuse-

handling, ...), and – agree on specific rules for the technical details of the interconnection

• Federations have a unique identifier• TLS-based

– Public Internet, SIP over TLS, federation acts as X.509 Certification Authority.

• Private network– Federation builds its own network; members connect directly over this

network.• SIP hubs / transit networks

– Calls are routed via a central SIP proxy

Otmar Lendl, “The Domain Policy DDDS Application”, IETF 65, March 2006

May 22, 2006

Domain Policy DDDS basics

• The domain is the key to the destination policy– Use the DNS as rule store– No special translation rules necessary– Infrastructure is in place

• Example:example.com. IN NAPTR 10 50 "U" "D2P+SIP:fed"

"!^.*$!http://sipxconnect.example.org/!" .

“Regarding SIP, example.com is a member of the federation identified by this URI.”

• Non-terminal NAPTR for customer domains referring to provider domains

• Protocol agnostic– SIP is just a special case

Otmar Lendl, “The Domain Policy DDDS Application”, IETF 65, March 2006

May 22, 2006

Longer-term opportunities for peering

• Enterprise trunk backup management– PSTN as primary, VoIP as backup (or vice versa)

• Spam/SPIT prevention– accountable carriers– trustable user identification (“caller ID”)– exchange of abuse information

• Billing and settlements– if per-call billing

May 22, 2006

ENUM performance

• Busy hour traffic estimate:– 0.1 Erlang 2 calls/hour/user– 100 mio users roughly 55,000 calls/second lookup rate

• Post-dial delay bounds: few seconds– includes signaling latency– DNS unlikely to be a significant contributor (except if packet loss)

• DNS server platform:– OS: Linux version 2.6.11– 1 or 2 Intel Pentium 4 CPU 3.00GHz, 1 GB memory

• DNS servers:– BIND– PowerDNS (PDNS)

• Open Source Authoritative Nameserver • Used by 50% of .de and 20% rest of the world, including e164.org.• Runs on Linux, FreeBSD, NetBSD, OpenBSD, Solaris• Serves data from MySQL, PostgreSQL, LDAP, BIND zone files, …

– Nominum ANS

May 22, 2006

Preliminary Black Box Test

ENUM server

Client 1

Client 2

Client 3

Client 4

Client 5

May 22, 2006

Black-box Comparison Results

IRT BIND 9.3.2

NominumBIND 9.3.0

IRTPDNS + BIND

NominumPDNS+BIND

IRTPDNS+MySQL

NominumPDNS+MySQL

Nominum ANS *

10 M RecordsLoad

Pass Pass Pass Fail Pass Not Tested Pass

Queries per Second

521 143 9,208 N/A 2,051 Not Tested 43,135

Average Latency (s)

0.190 0.618 0.011 N/A 0.048 Not Tested 0.0016

•All columns denoted as Nominum are from the Nominum white paper “ENUM Scalability and Performance Testing”. •The last column, Nominum ANS is tested with 200M records, all the rest are tested with 10M records.•PDNS test uses its default settings.

May 22, 2006

PDNS response time – record exists

May 22, 2006

PDNS: Throughput – record exists

May 22, 2006

Throughput: PDNS and caching

May 22, 2006

Throughput – BIND

May 22, 2006

Throughput - ANS

May 22, 2006

ITAD Subscriber Numbers (ISN)

• 4257*260

• ITADs– Defined by Telephony Routing over IP (TRIP) [RFC3219]– Globally unique – Lots of them (256 through 232-1)– IANA is already set up to allocate

• ISN resolution works just like ENUM

Ben Teitelbaum et al, March 2006

locallyassigned

Internet Telephony Administrative Domain (ITAD)

May 22, 2006

• Take an ISN

• Convert it to FQDN

• Query DNS for NAPTRs

• Apply resulting regexs to get list of URIs:

ISN in a Nutshell

4257*260

7.5.2.4.260.freenum.org.

freenum.org.

260.freenum.org.

sip:[email protected]:[email protected]:[email protected]

Note: We are working to ensure that the ISN root zone will be administered on behalf of the ISN user community by a neutral, non-profit organization. Following the trial, the root may or may not be “freenum.org”.


May 22, 2006

ISN vs ENUM vs SIP AOR

ISN ENUM SIP AORExample 7031*260 +1-734-352-7031 [email protected]

Familiarity Huh? Phone numbers Email address

Delegating Authority

IANA ITU, national government, …

ICANN, TLD registrars

Address Structure local*domain Hierarchical / geographical local@domain

Portability With domain owner’s cooperation

Varies by country???

With domain owner’s cooperation

Fragmentation One space Public ENUM + multiple private ENUMs

One space


May 22, 2006

Conclusion

• Peering as crucial next step for large-scale VoIP– weaning off the PSTN…– needed to get beyond black-phone service

• ENUM as core peering service– needed as long as phone numbers are in use– slow transition from private to public ENUM

• Peering is ENUM +– security associations– privacy protections (for carrier and users)– billing and settlements?

• Peering issues– provisioning of E.164 records– which peer?

• Need for high-performance service architecture

May 22, 2006

Resources

• ENUM: RFC 3761– carrier ENUM: draft-haberler-carrier-enum-02

• tel URIs: RFC 3966• IETF SPEERMINT working group

– definitions and terminology: draft-ietfs-speermint-reqs-and-terminology-01

– message flows: draft-penno-message-flows-02

• CableLabs VoIP Peering RFI• GSMA GRX/IPX Requirements• ECMA/TISPAN Next-Gen Corporate-Core Interconnection

Requirements• SIP Forum IP PBX / Service Provider Interoperability• ISNs: http://www.internet2.edu/sip.edu/isn/

voip peering – a snapshot

Documents