• Rohan: We have 65 minutes of material in a 150-minute slot.
• Hannes: we have time to talk ...
   

http://www.ietf.org/internet-drafts/draft-schulzrinne-sipping-emergency-req-01.txt
http://www.ietf-ecrit.org/cache/draft-schulzrinne-sipping-sos-04.txt
 

• Idea was to collect core requirements for emergency calling, independent of technology and national considerations
• Sipping draft has been around for a bit - cutting out trunk replacement in ECRIT
• Number provisioning
• Identification of emergency calls
• Location determination
• Call routing
• Focus here is protocol-related requirements only, not operational requirements (which also matter)
• Some requirements protocol-specific
• Steve Norris - Network resiliency? Priority indication?
• Hannes - these may be operational requirements, important but not in scope for this working group - we aren't doing system design at IETF
• James Polk - Prioritization is specifically out of scope for this working group
• Not sure how much we need to do here on number provisioning - idea is that users dial familiar numbers, but we don't use these as routing identifiers
• Network boundaries may not match identifier boundaries, but this is typically national-scale, not local network scale issue
• Roaming - need to provide both visited and home numbers
• Support multiple emergency services (more common outside North America)
• Call identification requirements are reasonable but contradictory - need to figure out what actually fits
• Universal system-visible identifier, local emergency identifiers
• All entities along a path must identify emergency calls
   
• Richard - how does this work if you have identifier translation along a path? which is also a requirement
• Requirement is actually for multiple intermediate translations along the path
• Backwards compatibility - UACs that don't understand identifiers? Outbound proxies may not understand identiers - assume that home AOR does, that's what you actually know about and have control over
   
• Rohan - software clients are still being updated regularly - don't assume this constraint - but SBCs have a business case of protocol repair
• Jonathan - the problem is that you don't control the things you need to talk to
• Not worrying about hotel outbound proxies, etc. at this time
• Location requirements - multiple location providers, by reference, end party, third party. Assuming home provider is what we need to deal with now
• Rohan - distinct providers of SIP services and IP connectivity? if we're going to support this, call it out explicitly - it's the fastest-growing form of SIP services
• Michael - additional complexity with 802.11 mobility - need to call this out explicitly as well - as long as provider can provide location information, that's what we need to provide the service - we have to go down to layer two to solve this
• James Polk - large-scale layer-two networks are more problematic - is this IEEE scope?
• Civic and geographic information are done?
• PIDF-LO is done?
• Michael - large-scale layer-two networks need to be in scope to meet real regulartory requirements - but we don't need to say how providers know where the location actually is
• Rohan - resounding consensus from layer two is to provide raw information and let IETF define actual protocols - we need to define this if we care about it - but this is GeoPriv material, not ECRIT material - but do we need to set requirements for GeoPriv here?
   
• James - we need routing to the right PSAP to be in scope!
   
• Jon Peterson - there are already drafts circulating in other working groups - requirements don't need to be done here, but we can discuss this - seems hard to do requirements without an architecture design that we don't have yet - there is a broader problem that we decided to slice into solvable parts, including this WG's charter
• James Winterbottom- assuming that we already have a dependable source of location
• Brian Rosen - if we don't have someone responsible for the big picture, we don't know where to go - someone has to have the big picture; if we don't, who does? - do we need to get something out quickly, or work on an architecture? Don't cycle on this for two years before we can do something
• Jon - we are building a tool, not a solution, and it would be presumptious to do that in the IETF
• Brian - we can't build national systems, we can only build international systems, and there's no venue to do this
• Jon - we are not the UN, we can convince people our tools are useful, not sure we can do more
• Richard - we are talking requirements, not solutions - let's focus on requirements before we do anything else
• Rohan - national groups are looking to the IETF - we aren't the UN, but nations are asking for help -
   
• * - if we don't decide, it will be decided nationally
• Call routing has basic robustness requirement- UA or outbound proxy or home proxies or other proxies need to be able to routing, even if other entities don't understand non-SIP URIs
• Non-controversial requirements for routing
• Possibly controversial - choice of PSAP (campus vs city police), traceable resolution? for caller? or just for PSAP?
• Steve Norris - Don't understand choice of PSAP (this is a college requirement, among other places - industrial, security firms) - we're talking about getting to the "real" PSAP, right?
• Support for mutiple signalling protocols? Most people are worried about SIP - can others say something on the mailing list so we don't get blind-sided?
• Media-capability-based routing? TDD, IM
• Language-based routing? James Polk - this is a good idea - we would need  non-SIP directory services that support this - would this work within a PSAP network for additional routing after the call gets to the PSAP?  - Jon Peterson - if this is low-hanging fruit, fine, we just need to think more about this
   
• Patrik - "lookup must be fast" - Sweden requirement is to minimize the number of reroutings based on guessing the language
• Michael - if you can identify the words, there are other ways to do this - hints OK, but don't make this an operational requirement
• Caller identification requirements - language identification? Identification of supported media? We mostly know how to do these today
• Patrik - is call-back in these requirements? No, but it should be
• Call Setup - Authentication override? Mid-call features (outside the scope of this working group?)?
• SIP is external interface - allow MGCP, Skinny, H.323 within administrative domains?
• Rohan - stimulus-oriented protocols aren't appropriate because these devices usually also speak SIP, H.323 etc.
• Steve Norris - we're talking about voice service - that's the requirement - but we work on protocols, not on services
• Henning - protocol choice drives idenifier discussion
   
• Is PSAP OK terminology? Steve Norris - ETSI has had problems with PSAP - this is a function, not a box or a person - PSAP isn't the only problematic term we're dealing with, need to scrub this
• Patrik - what about receive-side call blocking? What is interaction with authentication override? Need to at least discuss this - haven't had contributions on threats - but you'll get one from Sweden soon!
• James Polk - protocol within PSAP doesn't matter. SIP and H.323 are the only choices for call routing. Focus on SIP? Jon Peterson - how much does our work here assume SIP at the requirements level? Would any URI work?
• Jonathan Rosenberg - might be dependent on protocol, or not - can we break the problem into pieces that are mostly NOT dependent on a protocol? Use a URN instead of a SIP URI?
   

• Requirements from a draft MIC report, focused on VoIP specifically
• Want VoIP emergency services to be equivalent to existing PSTN environment
• Stu Gallman - how is priority override actually performed today? This question is actually out of scope - offline?
• James Polk - actually, may be relevant - overloaded proxy, etc. Japan worries about this, don't ignore it
• Pointing out that PSAP is the only party that can end emergency calls - includes reversing call from PSAP
   
• Pointing out requirement for redirection to altenative PSAP if original PSAP is unavailable
• Calling-line ID must be presented unless an override code is dialed

http://www.ietf.org/internet-drafts/draft-rosen-nena-ecrit-requirements-00.txt

 

• Requirements from NENA VoIP/Packet technical committee
• 6134 PSAPs with irregular boundaries in North America - routing based on side of streets or worse
• Lots of effort to keep civic addresses accurate
• Current system has good accountability for every entity along the path - matters when something goes wrong, because you debug problems in life-threatening situations
• Need to know what happened with signalling
• Got to be able to call 911, although other numbers could work
• Need to have calls go to H.164 numbers if you aren't served by 911
• James Polk - is signalling trace like History-Info? Yeah, and Vias - don't drop Vias at SBCs, for instance
• We assume soft phones get location and provide location on incoming calls - what if the PSTN comes into a gateway - what's the way to make those scenarios work?
• Need congestion controls everywhere - don't avalanche problems downstream elements - congestion control in the SIP sense, and this is at the endpoint level, not at the intermediate node level
   
• Multiple locations in a call? Gotta route based on one location - know tower location plus measured location - this does happen today, and is legitimate
   
• Location provider may not be communication service provider
• Need defaults for location when information is missing - choosing "somewhere"
   
• Eric Rescola - what is scope of default route? there is a hierarchy of defaults
• Rohan - 911 calls on cell phones in California go to Sacramento
• Steve Norris - can't hold up emergency calls for location information
• * - what happens if you provide coordinates instead of street addresses? Hours of discussion on this, but existing service uses both and doesn't do conversion well - what about going forward with GPS-capable devices?
• Address hierarchies - tenants at a location, etc. URI in the database would be enough
• Additional information about a person - URI would be enough
• Validate before you call - location exists in the database before you use it to route. Validation databases are also multiple and often map to PSAP boundaries in North America
   
• James Polk - who is "you"? - doesn't matter - UA must validate? Or location information system - place burden on the location server to validate? doesn't matter, still needs to be validated - UA can validate, but location service must validate
   
• Hannes - need to be very precise about what we're trying to accomplish here - we're skating along the edge of the charter. Additionally, the term validation is used with two different meanings.
• Henning - we have at least two mental pictures of validation - not just a terminology problem, but confusion - does an address exist, and am I actually at that location - how do I know a street address is correct? But this is clearly out of scope
• Postal address isn't actual community name - need to know which one we've got
• Some PSAP boundaries are incredibly irregular - river course, all of a city except for two streets
• Lots of entities will route - routing data must be secure, reliable in the face of massive failure
• Callback identifier must be reliable
• "No hangup" mechanism - no BYEs!
• Distribute route failure information and related diagnostic information
• Want one requirements document quick - either this one or a design team draft

http://www.ietf.org/internet-drafts/draft-stastny-ecrit-requirements-00.txt
 

• Draft intention was to step back to high level
• Updating based on list discussion
• Don't want operators to withhold location information (even because they want to sell it)
• Must verify path to PSAP/ECC periodically
• Steve Norris - get location information from user at last resort? Mobile phones are doing this by voice now in Europe, thinking about better mechanisms
• James Polk - 802.11 phones in a home won't have their own locations; $500 boxes may ask users to provide information (although this won't be reliable) - this is a policy question
   
• Communication established by external events (is this out of scope? certainly a user interface issue)
• Indication whether you are allowed to make an emergency call (no location, no authentication, etc.)
• Have added home and visited emergency URI requirement
• Have added recognition of emergency calls by intermediate devices
• Steve Norris - 3GPP also has requirements for downloading roamed-to emergency numbers automatically
• Jon Peterson - being able to designate a gateway for emergency calls is actually in scope, but going beyond this is probably out of scope
• Some SHOULDs are MUSTs in some countries

• VoIP needs the same assurances for PSAPs that they have from POTS information today
• Location tied to a device, not to a user, at the time that a call is made
• Location needs to be a real place - postal vs jurisdictional location
• Patrik - location needs to be what a fire truck is using, whether it is right or wrong
• Brian - same for information that's used to route
• Need accountability for location providers
• Reliability may not be in scope for Ecrit, but it needs to be in scope for somebody
• Steve Norris - if you have two pieces of location, both of them are required
• James Polk - Access provider is probably actually providing location, not service provider

• Jon Peterson - we were talking about scope when we did charter - how is the protocol depending on the validation of location information, if we understand that error conditions are included in the protocol?
• Henning - if there's a one-step resolution protocol, this is probably OK - if it's not one step, if multiple steps of resolution are required and visible outside the PSAP, the protocol needs to know about validity
• Brian Rosen - it is in scope to require location validation before you route emergency calls based on location - why is this controversial? It's a North American requirement, for sure
• Henning - Imagine an MSAG that wouldn't route to a real PSAP - confirms that a location is valid, but you can't tell that a PSAP assignment is reasonable or not. Location is more complicated than just "does it exist", and these requirements are stronger.
• <>Brian Rosen - Patrik was right - what people care about is what Patrik said; what people care about is whether locations work for dispatching fire trucks - location will be used for routing AND given to the PSAP for PSAP response</>

• Hannes: We have seen a number of drafts about requirements, some more mature than others. We need to come up with requirements really soon. Henning's document is the most complete one (and available for a long time already). It needs to be updated and have terminology scrubbed. Can other document authors contribute to one document? Can we pick an editor?
   
• Brian Rosen - this is actually more collaborative, but I agree
• Roger Marshall and Brian Rosen volunteered to be editors - Roger will take the lead here
   
• Rohan - who are these requirements for? All of the drafts have requirements on all sorts of entities - need to organize the requirements by who they reply to.
• Rohan - security analysis - need to do much more work in this area.
• Steve Norris - NGN TiSPAN group has IMS requirements that are 90-percent overlap with 3GPP. Emergency services have requirements, too (provider call release, etc.)