1 / 13

Issues in Numbering, Naming and Addressing voipeer BoF IETF 63 – Paris, August 2005

Issues in Numbering, Naming and Addressing voipeer BoF IETF 63 – Paris, August 2005. Richard Stastny ÖFEG. Note Well. The Internet is (or is intended to be) a network without central intelligence –> a stupid network The Internet is based on the end-to-end principle

Download Presentation

Issues in Numbering, Naming and Addressing voipeer BoF IETF 63 – Paris, August 2005

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. Issues inNumbering, Naming and Addressingvoipeer BoFIETF 63 – Paris, August 2005 Richard StastnyÖFEG IETF 63 VOIPEER

  2. Note Well • The Internet is (or is intended to be) a network without central intelligence –> a stupid network • The Internet is based on the end-to-end principle • Every user may reach any other user via the IP address • All “services” may be offered anywhere and may be accessed from everywhere • This is of course also valid for voice and other communication “services” • Voice and other communications do not need a “service” provider at all, they are applications. • Jon Peterson, ITU-IETF NGN Workshop, Geneva, May 2005 IETF 63 VOIPEER

  3. A Basic Requirement • Any connection that originates on IP and terminates on IP should stay on IP end-to-end • No additional cost for PSTN by-pass • Improved QoS for native IP connections • improved functionality (BB codecs, IM, video, conferencing, presence, …) IETF 63 VOIPEER

  4. What are we talking about? • VoIP peering? • Reachability between SIP Servers? • Where is the problem? Use SIP AoR and the DNS • Will there be mail, ftp, web, … peering BoFs in Vancouver? • VoIP Service Provider Interconnect? • Reachability between “networks”? • using IP-based technology, SBC, SIP AoR and/or E.164 numbers IETF 63 VOIPEER

  5. Some Definitions • What is required to establish a communication? • Identification of the user to the service provider • e.g. a UserID, an IMSI, „private“ User Identity, etc. • Provides mobility, not portable • Address mapped to the current user device • e.g. IP-address, E.164 number • Network-specific, used for L3-routing, not portable • Name related to the service • e.g. URI, AoR, e-mail address, E.164 number, „public“ User Identity • mapped to the current address of the device where the user has identified himself, used for application-level routing • for the convenience of the calling party • needs to be public • portability is depending on service IETF 63 VOIPEER

  6. Mapping • To find the address, a name resolution is required (e.g. by DNS) • If different addressing schemes or different address spaces are used, an additional mapping is required (e.g. NAT, SBC, …) • If different naming schemes are used, an additional mapping is required (e.g. ENUM) • or all of these IETF 63 VOIPEER

  7. „Types“ of VoIP • freely accessible servers (proxies) on the public Internet (ala e-mail) • servers on the public Internet, but requiring authentication • servers in private networks, accessible from the public Internet via a Session Border Controller (SBC) • servers in private networks, accessible from the public Internet via a Session Border Controller, requiring authentication • servers in private networks, accessible only via SBC from other private networks, eventually via a commonly shared network (extranet) • servers in private networks only reachable via the PSTN • users on a PSTN network which is connected to the Internet via gateway acting as SBC. • etc. • Note: “private” networks may be end-user networks, corporate networks or “NGNs” (service provider networks) IETF 63 VOIPEER

  8. Some VoIP Scenarios DNS ENUM Internet DB NGN A NP DB PSTN DB Missing: corporate nets, transit nets, virtual nets, extranets, … NGN B IETF 63 VOIPEER

  9. Which Scenarios? • Which of these scenarios are in- and out-of-scope? • How to route calls between the two „end“-servers? • Routing of calls implies to find out in the originating network the destination network and, • if no direct interconnection between originating network and destination network exists, • transit networks are required to interconnect. • Are transit networks in-scope? • Transit for L3 also or only for the application layer? IETF 63 VOIPEER

  10. How Public is Public? • Routing of calls is done normally by analyzing the "public" identifier of the called party entered by the calling party. • It is obvious that on IP-based networks IP-based names and addresses will be used for routing, so: • What are the "public" identifiers an end-user will enter? • Or to make it simple: What identifiers does one put on his business card? • Do I have to put on my business card:sip:richard.stastny@a1.net (valid only within vodafone networks) IETF 63 VOIPEER

  11. Which Public Identifiers? • There are the following choices: • E.164 numbers • SIP AoR in the format sip:user@foo.bar • or both (e.g. sip:+43123456@foo.bar) • If it is E.164 numbers only, these E.164 numbers are translated by some magic (e.g. ENUM) to internal identifiers e.g. a SIP AoR to enable routing. • Note: This ENUM cannot be USER ENUM because if the carriers services rely on this mapping, it must be independent from the end-user. • If it is SIP AoRs, an additional question comes up: • is an end-user restricted to public identifiers given out by providers such as richard.stastny@vodafone.de • or is it possible also to "port in” identifiers such as richard@stastny.com? IETF 63 VOIPEER

  12. Conclusion • Depending on the scenarios the • naming and addressing schemes • the required mappings and • the access to DNS and IP addresses • need to be investigated and defined. IETF 63 VOIPEER

  13. Thank you More questions? IETF 63 VOIPEER

More Related