[Sipping] Comments on draft-schulzrinne-sipping-emergency-req-00

["Drage, Keith (Keith)" <[e-mail]>]

a)	Section 3 definitions. I am unsure of the need to distinguish between "Basic emergency service" and "Enhanced emergency service". What I understood for emergency calls was that ideally all information available (i.e. carried in the normal call signalling) about the caller should be delivered. If the information was unavailable, the call should still be delivered.

b)	Section 4, M2: "Call setup delay: The call setup delay MUST NOT be no larger than for existing analog trunks." translates as "Call setup delay: The call setup delay MUST NOT be smaller than for existing analog trunks ..., which is obviously not the meaning.

c)	Section 4, M3: Why not just refer here to the transfer of standard E164 addresses. E.164 specifies a maximum length for these addresses.

d)	Section 4, M4 and M5 specify the need for certain additional services. There should also be requirements to be able to override other services so that that service is not imposed. For example, if there is a SIP version of the closed user group service ever invented, then it would be inappropriate for the network of the ECC to allow this to be used on an emergency call. However, I would suggest this is expressed generally, rather than in a service specific manner.

e)	Section 5.1, A2: We have discussed before that there are really two levels of requirements here. The first level concerns those numbers that are used somewhere for emergency calling purposes, but that are not used elsewhere in the world for any other purposes. These should always be emergency calls. The second level concerns numbers that are used elsewhere for emergency calls, and do not conflict with local usage for some other purpose, or represent local usage for some other purpose in the terminal owners normal home environment. Where the service provider provides a device for insertion in the terminal, or where this information can be downloaded to the terminal, these can also be made by the terminal as emergency calls. Such calls should be specifically tagged as emergency calls, and presumably made using the emergency SIP URL rather than using the normal emergency digits.

f)	Additionally to the above, if the transport mechanism provides specific indications for emergency calls, e.g. to allow special routeing or special QoS, then those should be used where a call is identified as an emergency call. E.g. 3GPP is likely to define special characteristics of a PDP context that is solely used for emergency calls. Primarily this is expected to have a routeing impact.

g)	Section 6, S1: The term "unauthenticated emergency calls" is not correct as it implies that the user has to authenticate with the ECC in order to make an emergency call. Prefer "...allow an unauthencicated user to call the emergency call centre."

regards

Keith


Keith Drage
Lucent Technologies
Tel: [phone]
Email: [e-mail] 
_______________________________________________
Sipping mailing list  https://www1.ietf.org/mailman/listinfo/sipping
This list is for NEW development of the application of SIP
Use [e-mail] for questions on current sip
Use [e-mail] for new developments of core SIP