1 / 35

VoIP peering – a snapshot

VoIP peering – a snapshot. Henning Schulzrinne w/Charles Shen Dept. of Computer Science Columbia University http://www.cs.columbia.edu/~hgs. Overview. Review: What is VoIP peering? Why VoIP peering? Scaling peering to millions of users Challenges for VoIP peering Beyond PSTN replacement

holt
Télécharger la présentation

VoIP peering – a snapshot

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

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

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

  3. 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. 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. 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. Session interconnect E.164 number peer discovery ENUM lookup of NAPTR in DNS SIP URI aka call routing data (CRD)  derived from ENUM record service location (lookup of NAPTR and SRV) in DNS host name addressing and session establishment lookup of A and AAAA in DNS IP address routing protocols, ARP, … MAC address

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

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

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

  10. Peering: decomposed model domain A domain B draft-penno-message-flows-02

  11. Peering: collapsed model ~~~~  ~~~~ ~~~~  ~~~~ B2BUA domain A domain B draft-penno-message-flows-02

  12. Peering authorization P1 P2 INVITE • 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 100 Trying SUBSCRIBE w/PeerAuth 401 Unauthorized SUBSCRIBE w/auth 202 Accepted NOTIFY w/P2key INVITE 401 Unauthorized INVITE + P2Key INVITE 100 Trying draft-penno-message-flows-02

  13. 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. sip:bdr@internet2.edu mailto:bdr@internet2.edu sip:bobr_621@att.sbc.com ENUM in a Nutshell +1-734-913-4257 • Take an E.164 number • Convert it to FQDN • Query DNS for NAPTRs • Apply resulting regexs to get list of URIs: 7.5.2.4.3.1.9.4.3.7.1.e164.arpa. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. Preliminary Black Box Test ENUM server Client 5 Client 1 Client 4 Client 2 Client 3

  25. Black-box Comparison Results • 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. PDNS response time – record exists

  27. PDNS: Throughput – record exists

  28. Throughput: PDNS and caching

  29. Throughput – BIND

  30. Throughput - ANS

  31. 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 Internet Telephony Administrative Domain (ITAD) locallyassigned Ben Teitelbaum et al, March 2006

  32. sip:bdr@internet2.edu mailto:bdr@internet2.edu sip:bobr_621@att.sbc.com ISN in a Nutshell 4257*260 • Take an ISN • Convert it to FQDN • Query DNS for NAPTRs • Apply resulting regexs to get list of URIs: 7.5.2.4.260.freenum.org. freenum.org. 260.freenum.org. 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. ISN vs ENUM vs SIP AOR Ben Teitelbaum, John Todd, Dennis Baron: “ISN Numbers: Fast, Free, and Forever Yours” March 16, 2006 Spring VON, San Jose, CA

  34. 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. 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/

More Related