Issues in voipeer BoF IETF 63 – Paris, August 2005

advertisement
Issues in
Numbering, Naming and Addressing
voipeer BoF
IETF 63 – Paris, August 2005
Richard Stastny
ÖFEG
August 2005
IETF 63 VOIPEER
1
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
August 2005
IETF 63 VOIPEER
2
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, …)
August 2005
IETF 63 VOIPEER
3
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
August 2005
IETF 63 VOIPEER
4
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
August 2005
IETF 63 VOIPEER
5
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
August 2005
IETF 63 VOIPEER
6
„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)
August 2005
IETF 63 VOIPEER
7
Some VoIP Scenarios
ENUM
DNS
Internet
DB
NGN A
NP
DB
PSTN
DB
Missing: corporate nets, transit
nets, virtual nets, extranets, …
August 2005
NGN B
IETF 63 VOIPEER
8
Which Scenarios?
• Which of these scenarios are in- and out-ofscope?
• 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?
August 2005
IETF 63 VOIPEER
9
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)
August 2005
IETF 63 VOIPEER
10
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?
August 2005
IETF 63 VOIPEER
11
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.
August 2005
IETF 63 VOIPEER
12
Thank you
More questions?
August 2005
IETF 63 VOIPEER
13
Download