210 likes | 219 Views
Gateway Location. Jonathan Rosenberg Bell Laboratories 8/24/98. Some terms. Gateway (GW) Device with some sort of PSTN connectivity and IP connectivity, capable of terminating/initiating IP telephony signaling protocols, and terminating/initiating PSTN signaling protocols User Agent (UA)
E N D
Gateway Location Jonathan Rosenberg Bell Laboratories 8/24/98
Some terms • Gateway (GW) • Device with some sort of PSTN connectivity and IP connectivity, capable of terminating/initiating IP telephony signaling protocols, and terminating/initiating PSTN signaling protocols • User Agent (UA) • An entity with IP connectivity which wishes to place a call from an IP network to a user connected only via a telephone network. This entity can be an individual at a PC, a local gateway for phone to phone, or an intelligent IP device • Location Server (LS) • A logical entity with IP connectivity which has knowledge of gateways which can be used to terminate calls. The LS is generally a point of contact for user agents for completing calls to the telephone network. An LS may also be responsible for propagation of gateway information to other LS’s. An LS may frequently be an H.323 gatekeeper or SIP server
Intra domain All gateways managed by same provider There are multiple LS’s, each needs to learn about gateways Gateways go up, come down, change attributes, need to update these in LS Policy not an issue Some kind of flooding protocol (mcast, SCSP) appropriate Inter vs. Intra domain gwloc protocol GW LS UA
Inter domain (1) Provider A needs to learn about gateways of other providers Providers generally have pre-established relationships Protocol used to automatically propagate new gateways, changes in attributes, to provider A Provider A may not wish to accept all gateways from other providers - provider policy Provider A makes all gateways it knows about to its customers, “hiding” the fact that they may be provided as a result of contracts Provider knows about its own gateways via intra-domain protocol Intra vs. Inter domain GW LS UA ??intra-d protocol gwloc
Inter domain (2) More “open market model” No need for intermediate provider, work directly with actual gateway provider Protocol is an advertisement protocol - gateways or proxies for them Clients directly can listen Still supports intermediate provider model - an LS can listen Some kind of multicast needed Intra vs. Inter domain LS gwloc UA
Inter domain (3) Introduce telephone numbers into existing routing infrastructure Requires all routers to understand and aggregate E.164 Affects even non-IPTEL AS’s Overloads an already overloaded infrastructure BAD IDEA Intra vs. Inter Domain
Inter-domain feature An LS receives and propagates gateways learned from other providers May aggregate Much like todays routing models Allows for multi-level subcontractor-like arrangements between providers Multi-hop, one gateway
Call signaling will generally follow routing path Just like regular routing (-) Client can’t usually communicate directly with gateway Actual gateway address lost in aggregation If no aggregation, then you may be able to go direct (+) Caller may not have billing arrangement with final provider, so may need to sending signaling through intermediary (-) May be able to handle billing arrangements w/o intermediary signaling Issues
Pictorially 110/2 100/2 100/1 Signaling Path Client calls 101
More issues • Can we aggregate • Gateway > Router • terminates many complex application layer protocols with many optional features and services • Heterogeneity natural here • Many attributes • codecs, protocols, crypto, administrator, capacity, cost structures, vendor, call features (transfer, multi party, ISDN video??…), vendor-specific • Aggregating the unaggregatable • Force aggregation by ignoring certain attributes? • May impact final service - call can be routed to gateway which doesn’t meet requirements • Leave it to policy and the marketplace?
Multiple hops on and off telephone network Example uses? Drawbacks Multiple transcodings Many signaling conversions Loss of information Complexity Can just treat telephone connection as a modem link running IP Makes it look like single gateway case Why not use IP for intermediate PSTN hops? IP connectivity must exist for protocol operation anyway Multiple gateways PSTN
Provider Signaling Protocols SIP, H.323 Codecs G.723, G.729, …… Call Features Transfer, hold, multi-party calls Additional Services Encryption, authentication, accounting Billing capabilities payment methods Reachability Phone numbers willing to be called Cost for each (can be complex!!) Capacity Box vendor? Obscure? features ISDN video Gateway Attributes
What set of phone numbers will a gateway be able to reach? Only local? Quality (on PSTN for long time) may dictate large calling areas Unusual billing irregularities More calls, better for provider “Sales” on calls to remote destinations Its a matter of business policy - SHOULD ALLOW ANYTHING Calling area range
Red line ignored until now How does the user actually make use of service? Many models.. What about the user LS gwloc UA
User sends signaling message to LS containing destination address as telephone number Gateway location process transparent - clean User doesn’t care about which gateway is used Users can’t express preferences Same as previous, but signaling messages contain preferences Call-Disposition header in SIP Non-standard params in H.323 limited expressiveness, better than previous User interaction possibilities Call-Disposition: cheapest;provider=MCI
Explicit queries User formulates a query, sends it to LS Query contains requirements for gateway service Can be LDAP, SQL, SLP…. Can be very expressive Response is address of gateway Drawbacks Difficulties if there’s aggregation - queries may need to traverse routing path Doesn’t make sense in multiple gateway case User interaction
Web LS creates dynamic web pages from tables learned Users browse web and can select gateway Multicast Gateway info flooded into domain Users can build up database and made decisions CPL Upload policy in CPL Two pieces back-end: protocol to distribute gateway information among LS’s front-end: way users access information obtained by LS may be many front-ends keep them separate model common We develop back end Other approaches
Back-end/front-end model has implications on policy Service provider policy executes first to filter out gateways User policy executes on resulting gateway set Both policies may be based on same or different attributes gwloc must carry attributes relevant to both Policy interactions gateways gwloc Provider Policy provider gateway set User policy final gateway
Web search model Search engines collect pages, classify/filter them (provider policy), use back-end protocol (Harvest, etc.) users indicate search requirements, executed at provider engine (user policy), using front end protocol (http) SLP model DA collects services from SA’s, may discard some (provider policy) UA sends query to DA, executes on DA and returns result (user policy) Model is common
Makes available services to some set of gateways Gateways may be owned by provider Gateways may be made available from other providers through service agreements Gateways may be made available to other providers through service agreements If a provider only makes available some sets of gateways, or chooses not to honor certain client policies, thats part of its service Can always use other provider Provider can just be clearinghouse - not own any of its own gateways Provider must at least have LS What is a provider?
Aggregating phone numbers • Differing numbering plans may make phone number aggregation hard • Is there an issue?