Presentation is loading. Please wait.

Presentation is loading. Please wait.

August 2005IETF 63 VOIPEER1 Issues in Numbering, Naming and Addressing voipeer BoF IETF 63 – Paris, August 2005 Richard Stastny ÖFEG.

Similar presentations


Presentation on theme: "August 2005IETF 63 VOIPEER1 Issues in Numbering, Naming and Addressing voipeer BoF IETF 63 – Paris, August 2005 Richard Stastny ÖFEG."— Presentation transcript:

1 August 2005IETF 63 VOIPEER1 Issues in Numbering, Naming and Addressing voipeer BoF IETF 63 – Paris, August 2005 Richard Stastny ÖFEG

2 August 2005IETF 63 VOIPEER2 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

3 August 2005IETF 63 VOIPEER3 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, …)

4 August 2005IETF 63 VOIPEER4 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

5 August 2005IETF 63 VOIPEER5 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

6 August 2005IETF 63 VOIPEER6 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

7 August 2005IETF 63 VOIPEER7 „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)

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

9 August 2005IETF 63 VOIPEER9 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?

10 August 2005IETF 63 VOIPEER10 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)

11 August 2005IETF 63 VOIPEER11 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?

12 August 2005IETF 63 VOIPEER12 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.

13 August 2005IETF 63 VOIPEER13 Thank you More questions?


Download ppt "August 2005IETF 63 VOIPEER1 Issues in Numbering, Naming and Addressing voipeer BoF IETF 63 – Paris, August 2005 Richard Stastny ÖFEG."

Similar presentations


Ads by Google