Presentation is loading. Please wait.

Presentation is loading. Please wait.

May 22, 2006 VoIP peering – a snapshot Henning Schulzrinne w/Charles Shen Dept. of Computer Science Columbia University

Similar presentations


Presentation on theme: "May 22, 2006 VoIP peering – a snapshot Henning Schulzrinne w/Charles Shen Dept. of Computer Science Columbia University"— Presentation transcript:

1 May 22, 2006 VoIP peering – a snapshot Henning Schulzrinne w/Charles Shen Dept. of Computer Science Columbia University http://www.cs.columbia.edu/~hgs

2 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

3 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.”

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

5 May 22, 2006 Why is VoIP peering needed? Non-reasons –SIP: providers can talk directly to each other if SIP URIs are available sip:alice@example.com  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

6 May 22, 2006 Session interconnect E.164 number SIP URI host name IP address MAC address 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, …

7 May 22, 2006 Peering evolution PSTN Plane VSP VoIP Service Providers interconnect via PSTN using E.164 numbers for addressing +4315056416 Otmar Lendl, March 2006 (SPEERMINT)

8 May 22, 2006 PSTN Plane Messy reality VSP sip:office@enum.at Public Internet Private Interconnection Network Closed SIP federation Otmar Lendl, March 2006 (SPEERMINT)

9 May 22, 2006 Example: Cable operators MSOs want to avoid PSTN traversal Call Management Server Signaling (CMSS) = SIP Jean-François Mulé, IETF 63

10 May 22, 2006 Peering: decomposed model domain Adomain B draft-penno-message-flows-02

11 May 22, 2006 Peering: collapsed model ~~~~  ~~~~  ~~~~ domain Adomain B B2BUA draft-penno-message-flows-02

12 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 P1P2 draft-penno-message-flows-02

13 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:12125551234@vsp.com;user=phone –resolve to neutral peering provider +1 212 555 1234  sip:12125551234@peering.com;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

14 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:bdr@internet2.edu mailto:bdr@internet2.edu sip:bobr_621@att.sbc.com 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

15 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

16 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

17 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

18 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: 12125551234@peering.com –peering provider does database (or internal ENUM) lookup

19 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

20 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

21 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

22 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

23 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

24 May 22, 2006 Preliminary Black Box Test ENUM server Client 1 Client 2 Client 3 Client 4 Client 5

25 May 22, 2006 Black-box Comparison Results IRT BIND 9.3.2 Nominum BIND 9.3.0 IRT PDNS + BIND Nominum PDNS +BIND IRT PDNS +MySQL Nominum PDNS +MySQL Nominum ANS * 10 M Records Load Pass FailPassNot TestedPass Queries per Second 5211439,208N/A2,051Not Tested43,135 Average Latency (s) 0.1900.6180.011N/A0.048Not Tested0.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.

26 May 22, 2006 PDNS response time – record exists

27 May 22, 2006 PDNS: Throughput – record exists

28 May 22, 2006 Throughput: PDNS and caching

29 May 22, 2006 Throughput – BIND

30 May 22, 2006 Throughput - ANS

31 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 2 32 -1) –IANA is already set up to allocate ISN resolution works just like ENUM Ben Teitelbaum et al, March 2006 locally assigned Internet Telephony Administrative Domain (ITAD)

32 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:bdr@internet2.edu mailto:bdr@internet2.edu sip:bobr_621@att.sbc.com 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”. Ben Teitelbaum, John Todd, Dennis Baron: “ISN Numbers: Fast, Free, and Forever Yours” March 16, 2006 Spring VON, San Jose, CA

33 May 22, 2006 ISN vs ENUM vs SIP AOR ISNENUMSIP AOR Example7031*260+1-734-352-7031ben@internet2.edu FamiliarityHuh?Phone numbersEmail address Delegating Authority IANAITU, national government, … ICANN, TLD registrars Address Structurelocal*domainHierarchical / geographicallocal@domain PortabilityWith domain owner’s cooperation Varies by country ??? With domain owner’s cooperation FragmentationOne spacePublic ENUM + multiple private ENUMs One space Ben Teitelbaum, John Todd, Dennis Baron: “ISN Numbers: Fast, Free, and Forever Yours” March 16, 2006 Spring VON, San Jose, CA

34 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

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


Download ppt "May 22, 2006 VoIP peering – a snapshot Henning Schulzrinne w/Charles Shen Dept. of Computer Science Columbia University"

Similar presentations


Ads by Google