Requirements for Resource Priority Mechanisms for the Session Initiation Protocol draft-ietf-ieprep-sip-reqs-01 Henning Schulzrinne Columbia University IEPREP/SIPPING working group IETF 55 (November 2002, Atlanta)

Meta-Overview Protocol requirement document = input to SIP(PING) WG –SIP may (or may not) decide to enhance or modify protocol based on these requirements –there’s lots of information in SIP that most parties are free to ignore, so hopefully not too hard currently, in WG last call –SIPPING group aware of last call –no known WG open issues

Overview Priority in SIP-based systems, primarily for VoIP systems that have gateways into a CSN (including, but not limited to, the PSTN) –needed for emergency telecommunications systems Resources: –gateway resources (trunks) –CSN resources away from the gateway –IP network resources -- out of scope –receiving end system resources (ACD) –SIP proxy resources (sometimes)

Network assumptions Full control –all aspects of the protocol stack can be tuned Transparent –forwards all valid IP packets –can't modify network elements SIP/RTP transparent –SIP calls go out –but can't rely on anything else Restricted SIP –no 'unknown' header fields, methods, body types, URI schemes, … –3G networks

Requirements REQ-1: Not specific to one scheme or country –not just GETS or US REQ-2: Independent of particular network architecture –not just, say, 3GPP REQ-3: Invisible to network (IP) layer REQ-4: Mapping of existing schemes REQ-5: No loss of information REQ-6: Extensibility REQ-7: Separation of policy and mechanism –really, abstraction  don't try to provide detailed recipe

Requirements REQ-8: Request-neutral –should work beyond INVITE REQ-9: Default behavior REQ-10: Address-neutral REQ-11: Identity-independent REQ-12: Independent of network location REQ-13: Multiple simultaneous schemes REQ-14: Discovery REQ-15: Testing REQ-16: 3PCC REQ-17: Proxy-visible (added)

Security Requirements SEC-1: More rigorous SEC-2: Attack protection SEC-3: Independent of mechanism SEC-4: Non-trusted end systems SEC-5: Replay SEC-6: Cut-and-paste SEC-7: Bid-down SEC-9: Confidentiality SEC-10: Anonymity SEC-11: Denial-of-service SEC-12: Minimize resource use by unauthorized users SEC-13: Avoid amplification

Call routing Request destination may depend on priority indication –different gateways (e.g., not all IXCs support GETS)

"9-1-1" calls Not related to 911/112 calls Also, if priority is desired, destination already identifies such calls –reduces mistakes or attempts to subvert

Changes since 00 edition Clarification of role in SIP proxies added network configurations and their resources (CSN-to-IP, etc.) clarified network constraints: –pre-configured for ETS –transparent –SIP/RTP transparent –restricted SIP/RTP wordsmithed policy/mechanism discussion

Next steps IEPREP WGLC Residence time in SIPPING? As for History, discuss initial solutions in SIPPING? Charter?

A survey of the solution space ApproachRemarks out-of-band indicator (RSVP, etc.) destination may not match – destination may depend on indicator! doesn't work in SIP/RTP-transparent networks too late in call new SIP methodfails REQ-8 URI parameter (tel or SIP URI), e.g., CPC parameter priority is property of call, not identifier or property of person Call-Info headerdoesn't fit: not a URL SIP body (e.g., SDP)can't be used by proxies (REQ-17) header + Accept-*seems ok caller preferencesmight also be useful; sufficient?

Generalizing the problem Some properties are for instance, other for AOR! –most seem of the instance kind (even language can vary if secretary registers for user) Have three kinds of properties: –caller or calling station properties "operator", "prison", "payphone" vs. – currently using JFK payphone –callee or called station properties registration, caller preferences –call properties Priority, resource priority