1 / 15

Requirements for prioritized access to PSTN resources

Requirements for prioritized access to PSTN resources. Henning Schulzrinne Columbia University. superset of draft-schulzrinne-ieprep-resource-req-00. Assumptions/Scope. SIP endpoint wants to access restricted (prioritized) resources on a circuit-switched network

fbraggs
Download Presentation

Requirements for prioritized access to PSTN resources

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. Requirements for prioritized access to PSTN resources Henning Schulzrinne Columbia University superset of draft-schulzrinne-ieprep-resource-req-00

  2. Assumptions/Scope • SIP endpoint wants to access restricted (prioritized) resources on a circuit-switched network • Does not indicate request of IP resource priority • may not be available • may not be necessary • Examples: GETS, MLPP, eMLPP, ... • Nothing to do with 112/911 • Also, possibly call from PSTN into SIP network

  3. Scenarios RP-capable gateway SIP PSTN w/MLPP GETS, ... INVITE sip:1-212-...@gets.ncs.gov INVITE tel:1-212-... INVITE sip:command@navy.mil SIP ISUP GSM does not know destination network (type)

  4. Assumptions • Call resource priority vs. call human priority • resource priority  indicated by caller (callee can't see) • priority of call to caller: indication ("Priority", content labeling) + callee call handling policy  out of scope • Resources: • IP-to-PSTN gateway channels • end-to-end PSTN circuits (PSTN network congestion, not access congestion)

  5. Assumptions • Call destination network type may be unknown to caller • Call destination does not identify PSTN resource priority • May want to reach "any of IEPREP type 1, type 2, ..." • May have several orthogonal indications of resource priority (eMLPP + GETS?)

  6. System assumptions • What do we assume about the IP side? • purpose-built: require certain capabilities (signaling, resource reservation, security, ...) • any network: use SIP application on standard platform or plug in own SIP phone • no network changes • firewalls  may not allow protocols beyond SIP and RTP • any SIP (pay) phone • no modifications to SIP phone • not much beyond two-stage dialing possible?

  7. General requirements • Not specific to one domain (e.g., GETS) • Not tied to existing PSTN authentication mechanisms • Use existing namespaces  different authorities that manage • Allow for default behavior • Separation of indication and policy • by reference (policy "flash"), not by value ("preempt all except class 'immediate', queue in relationship to GETS calls, but cut off after 3 minutes and only allow low-bit rate audio")

  8. Requirement: Discovery and negotiation • Caller must be able to discover PSTN resource priority capabilities • determines authentication "hat" • gateway needs for challenge • "Resource priority FOO level 7 requires use of BAR authentication" • Network may disallow discovery administratively  importance of call routing

  9. Requirement: Testing • Must be able to test largest possible part of the system without ringing actual destination • Systems only used during emergencies are less likely to work • Exercise authentication and authorization • Exercise call routing

  10. Requirement: Call routing • Combine with call routing: • req: specify logical destination, not physical gateway • resource priority requirement may enlarge or constrain set of destinations • e.g., additional special GETS-only gateway • only certain gateways (carriers) are capable of particular calls • note: TRIP property? • note: cf. SIP caller preferences

  11. Security requirements • End-to-end strong authentication and authorization of caller • not just theft of service, but system stability/performance issue • Intermediate (proxy?) authentication • delegate responsibility • not all VoIP gateways may be authentication-capable (many aren't) • harden authentication  DOS attacks

  12. Security requirements • Support authentication and authorization beyond existing PIN schemes • Authentication must be DOS-resistant • Allow "early" authentication  cannot wait until inside PSTN! • authentication consumes packets vs. circuits • minimize pre-authentication resource use • authenticate call signaling, not just resource signaling

  13. Security requirements • Do not tie resource priority namespace to one authentication scheme • different hardware types • hard/soft SIP phone • SIM-equipped cell phone • from any black phone with dial pad to smartcard- and biometrics-equipped

  14. Security requirements • Cross-domain • IP endpoint may be in different admin. domain than gateway • Require secrets not to be pre-installed • useability from any device • Authentication of PSTN gateway • desirable; required?

  15. Privacy requirements • Call content • very likely  separate docs • Signaling (resource and/or call setup) • reveals communication relationships • cannot rely on hop-by-hop • Fact of IEPREP call • sensitivity likely same (or lower) as call signaling

More Related