1 / 8

draft-lendl-speermint-background

IETF69 Otmar Lendl. draft-lendl-speermint-background. Why speermint?. Context: PSTN replacement type services SIP has been adopted by the market. Intra-domain part (RFC3263/ENUM) has failed. # of phones using SIP # of phones reachable via SIP (from other SPs)

fconcetta
Download Presentation

draft-lendl-speermint-background

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. IETF69 Otmar Lendl draft-lendl-speermint-background IETF69 speermint-background

  2. IETF69 speermint-background Why speermint? • Context: PSTN replacement type services • SIP has been adopted by the market. • Intra-domain part (RFC3263/ENUM) has failed. • # of phones using SIP • # of phones reachable via SIP (from other SPs) • IMHO: Speermint is supposed to fix that.

  3. IETF69 speermint-background What went wrong? • RFC 3263 SIP implies the email model • Destination needs to accept calls from anybody to get worldwide reachability. • Pre-arranged peerings are optional. • No termination fees • Fear of SPIT • No QoS guarantees • DoS protection • Caller-ID regulations • Legal requirement • Carriers are very reluctant to open up their ingress elements • If not the email model, then what?

  4. IETF69 speermint-background Transit • Not every pair of SPs will talk to each other • We need worldwide reachability (just relying on the PSTN won’t cut it) • Trying to convince SPs to open their ingress elements is a fool’s hope. • We need transit

  5. IETF69 speermint-background Routing • Corollary: • The moment we accept transit as necessary, we have a text-book routing problem. • Find a way • Find the best way • Potentially even more dynamic than BGP • RFC3263 won’t cut it any more.

  6. IETF69 speermint-background Route on what? • Telephone numbers? • Aggregation properties are getting worse every day. • Routing table size is *huge* • Been tried (TRIP) • How to cope with non-E.164 numbers? • Domains (from SIP URIs)? • No aggregation • # of domains? • Something else?

  7. IETF69 speermint-background Suggestion • We need some sort of identifier to base the routing protocol / policy decision on. • We need two lookup mechanisms: • Telephone number => Routing ID • SIP URI => Routing ID

  8. IETF69 speermint-background David • Three (logical) steps: • Lookup step • Map number to who owns the number • Policy step • Can I directly peer? • Do I need to go via transit SP? • Not reachable? • Location function • How do I determine the IP-address/port/TLS-setting of my next hop?

More Related