Re: [Sipping-emergency] Emergency Scenarios Document

[Henning Schulzrinne <[e-mail]>]

>    4.2 SIP Phone Deployment Scenarios 
> 
>       This section identifies the SIP phone deployment scenarios to be 
>       considered with regards to the fundamental requirements identified in 
>       3.2.  The numbers in parenthesis associated with each scenario are 

Section 3.2

>       used to reference the scenarios during the detailed analysis 
>       presented in section 4.3.  

Section 4.3

>       network.  The following diagram highlights the fundamental 

without VPNs and dial-in

>       +-------+                                              
>       |  SIP  |  *Known Location                                       
>       | Phone |                                         
>       +-------+                                                                       

Not just known, but fixed location. The location of lots of things are 
known to the user...

>       The final scenario deals with a nomadic SIP phone which attaches to 
>       an IP sub-network remote from the SIP network where it is recognized. 

geographically remote

>       This scenario would be typical of a remote office, such as 
>       telecommuters or a satellite office.   

Or somebody traveling and connecting via VPN to the home office - that's 
probably the most difficult scenario. After all, satellite offices are 
probably fairly stationary (unless they are true earth-orbiting 
satellites...) and I could just assign a block of IP addresses to that 
office.



>       emergency number.  In this last case, the ready made solution is to 
>       form the Request-URI directly from the user input.   

How? This always requires a dialplan since you can't just do

INVITE 911 SIP/2.0

>       -  the user at configuration time 
>       -  the DHCP server, using a SIP-specific option 
>       -  the SIP registrar, using an appropriate header field in its reply 
>          to carry the information. 

Or other SIP configuration information.

>       There is still the problem of distinguishing between voice and text 
>       emergency calls.  If the user enters an actual emergency number, that 
>       can be the one that serves the user's needs.  If the configuration is 
>       by DHCP or SIP registrar, it may be that selection of the appropriate 
>       number is based on pre-configuration of the SIP phone as voice or 
>       text based.   

Unless I'm really off my rocker, the number is the same for TDD calls. 
See http://www.nena.org/PR_Pubs/9-1-1QandA.htm for evidence.

> 
>       Pre-configuration also applies if the "sos" solution in [4] is used, 
>       and consideration must be given to how the protocol will indicate a 
>       routing to the text rather than voice emergency service.  This could 
>       be done based on the session description in the request body, but 
>       that implies that the correct routing is done at the gateway rather 
>       than at a proxy.   One alternative is to provide the indication 
>       somewhere in the SIP header, but this is probably wrong on principle. 
>       Another alternative is to reserve a specific "sos" subaddress for 
>       text services (e.g. sos.text) in the same way that subaddresses are 
>       reserved for fire, police and other specific services.  

Caller preferences is the right solution here. It fits the application 
perfectly, as it allows media selection. Since the routing (terminating 
gateway) is always exactly the same, there is no need for a distinction. 
Now, there is the problem that the gateway has to either be able to 
transparently convey 300 baud TTY (I think that survives even G.729...) 
or translate some text chat into TTY. I think this topic requires far 
more attention, since both solutions are viable:

- Old-style TTY connected via analog line interface (Cisco ATA 186, say) 
to gateway. Result: in-band 'tone' signaling (maybe even 2833...). No 
difference as far as the gateway is concerned.

- SIMPLE text chat.


>       Routing the call may present difficulties, because of the requirement 
>       to route to the ECC in jurisdiction.  To achieve this, the routing 
>       entity must generally have some notion of the caller's location.  
>       Caller location is a separate requirement, discussed below, so for 
>       purposes of the present discussion it is simply assumed that the 
>       caller's location is available to any proxies and gateways handling 
>       the call.  [This assumption may have to be revisited.] 

A more precise formulation is needed here. For routing, only rather 
crude location information is needed - in some cases, county or 
large-chunk-of-state will get you to the right place. (In New Jersey, 
every town is its own fiefdom, but NJ is not typical - I hope). For the 
call taker, knowing the county isn't particularly helpful in dispatching 
service.

> 
>       There are two basic possibilities to consider.  In some countries, it 
>       may be possible for a gateway to route an emergency call to a non-
>       local ECC.  (At least one commercial service to enable this is 
>       available in the USA.)  In these cases the selection of the gateway 
>       is not critical, although it would be desirable to have one as close 
>       as possible to the ECC in jurisdiction.  The gateway must have access 

Why? Is there an advantage to having the correct state or county? (I 
think so, but this should be stated. My reasoning is that somebody in 
the same county or state is probably familiar with the general geography 
and less likely to confuse Lexington, MA and Lexington, KY.)

>       A fourth case is one where the telephone network itself is able to 
>       process the calling party number to determine the ECC in 
>       jurisdiction.  This reduces the criticality of gateway selection, but 
>       is subject to the limitations of the telephone network (e.g. 

e.g. is always followed by a comma. See 
http://www.cs.columbia.edu/~hgs/etc/writing-bugs.html


>       If the phone is configured with the required number, then it has to 
>       pass this number in call signalling, presumably in the From header 
>       field.  Correlation at the far end with location data is a separate 
>       discussion, dealt with in the next section. 

Not necessarily. Phones might use a SIP URI like [e-mail]. 
Should they be required to use the phone number when dialing an 
emergency number? (This assumes that they can always recognize such a 
number.)

>       a Global Positioning System, or because DHCP (or some other external 
>       system) has told it what its location is (for example, based on the 

Cite James Polk and my DHCP drafts here.

>       This requirement should be achievable for the majority of Scenarios 
>       (1, 2, 3 and 4), whereby the network and the user connectivity are 
>       managed and more fixed. Scenario 5 introduces the element of the 
>       local network, which has no way to be aware of the need for this 
>       support.  From one point of view, since there are no SIP elements 
>       involved, there is no requirement on the local network.  This 
>       requirement does, however, highlight the need for some guaranteed 
>       level of service (in terms of call setup delay) from the SIP phone to 
>       the first SIP proxy that recognizes this as an emergency call.    

You could cite the R-P work :-)

>       configuration of the emergency Request-URI where the caller does not 
>       dial the emergency number, configuration of emergency call routing in 

See above. Numbers always have to be translated somehow - there is no 
'raw' number to SIP translation. Among other things, you need to choose 
whether dialing 911 becomes tel:911;phone-context=... or 
sip:911@somewhere;user=phone, and provide either the context or the 
'somewhere'.


>       the right gateways.  One possibility is that the SIP telephones are 
>       assigned to outgoing proxies based on their location, with the result 
>       that onward routing from the proxy is straightforward. 

How assigned?


>    6  Security Considerations 
> 
>       Security requirements have been identified in the requirements 
>       discussion throughout this document.  In particular, the need to 
>       ensure the caller identity can be vouched for by trusted identities 
>       has been identified.  This is to ensure the caller can be held 
>       accountable for any misuse of the system. 

The converse is: How can the user be sure that they have been connected 
to an ECC number instead of having the proxy translate tel:911 to the 
local number run by the friendly call taker impersonator from the 
Sopranos? (I think if somebody wanted to prevent me from placing an 
emergency call and has access to the signaling or media path, there are 
more effective and less likely to be discovered ways of doing this, but 
this issue has come up repeatedly.)

>        
>       In addition, in those scenarios where an external entity (e.g. DHCP) 

e.g.,

>       communicates location information to the SIP phone, it must be 
>       possible to ensure the confidentiality, integrity and authentication 
>       of this information. 


_______________________________________________
Sipping-emergency mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/sipping-emergency