1. 17 February 2016 SIPPING - IEPREP Joint Meeting Fred Baker - IEPREP co-chair Rohan Mahy - SIPPING co-chair

2. 17 February 2016 SIP Architecture review  Proxies are call stateless -- in the Internet proxies don’t have any linkage with QoS, or call counting  Proxies are fast -- standardizing prioritization inside a proxy has questionable value (implementation specific)  User Agents (Gateways, Phones, Media Servers) are responsible for requesting priority or preemption and “doing the right thing” (ex: preempting focus, requesting QoS) when receiving it

3. 17 February 2016 Making a call in a hybrid network PSTN “Internet” Issues: Policy in call acceptance: call waiting, preemption (SIP) Policy in bandwidth admission preferential reservation of bandwidth (RSVP) Exchange with PSTN: encoding and values

4. 17 February 2016 SIP-to-PSTN security requirements for prioritized access to PSTN resources Henning Schulzrinne Columbia University

5. 17 February 2016 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)  Need to authorize any assertion of priority and authenticate the originator

6. 17 February 2016 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?

7. 17 February 2016 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

8. 17 February 2016 Other open requirements questions  Call routing based on support of resource priority –support of specific IEPREP namespace? –SIP URI of gateway enough? –or "call # using FOO priority service"  no need to know gateway address avoid two-stage dialing  Caller needs to discover support for namespaces –may require different authentication

9. 17 February 2016 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?