Public Safety Answering Point (PSAP) Callback
RFC 7090
Yes
No Objection
Note: This ballot was opened for revision 12 and is now closed.
(Richard Barnes; former steering group member) Yes
(Adrian Farrel; former steering group member) No Objection
(Barry Leiba; former steering group member) (was Discuss) No Objection
Version -13 addresses my comments, and thanks very much for that. When I asked for changes to the example domains, to follow the recommendations in 2606, I had intended changing "town.com" and "state.org" to "town.example" and "state.example" to keep the sense of the relationship (rather than "example.com" and "example.net", which don't). Of course, the change that was made does follow 2606, so if you're happy, I'm happy. You're certainly right that it's a pity that 2606 didn't reserve a shorter TLD, such as "xmp", for examples. Waddyagonnado?
(Benoît Claise; former steering group member) No Objection
While these are non blocking comments regarding the document publication, let's have a discussion about those.
Note: I already discussed those two points with Hannes over the phone.
1.
In the case where the SIP
Priority header value, 'psap-callback', is supported by the SIP UA,
it would override user interface configurations, such as vibrate-only
mode, to alert the caller of the incoming call.
Is it a good idea?
I'm witnessing a crime: I call or page the police, put the silent mode, hide in a corner while waiting for the police, and now the police calls me back: no more silent mode. I'm now dead.
2.
In the SIP proxy case, what prevents the VoIP provider to use this mechanism for support calls.
It's not emergency, but it will save the VoIP provider time and money. So they might tempted to use it.
Richard's new sentence:
The indicator described in Section 4 can be inserted by any SIP entity, including attackers. So it is critical that the indicator only lead to preferential call treatment in cases where the recipient has some trust in the caller, as described in the next section.
I've have some trust in my VoIP provider, but it doesn't mean that he should get priority to call me back, by-passing all my policies.
What prevents some state/government to say: "I'm important. I want this priority feature when I call one of my citizen".
I believe that you need to impose, that, even in the proxy case, this mechanism only works in case of callback.
Editorial:
- Not sure what LoST is:
In
this scenario we consider a SIP UA that uses LoST to learn the next
hop destination closer to the PSAP.
(Brian Haberman; former steering group member) No Objection
I support Barry's and Stephen's DISCUSS positions.
(Gonzalo Camarillo; former steering group member) No Objection
(Jari Arkko; former steering group member) No Objection
(Joel Jaeggli; former steering group member) No Objection
One thought. When there is a local relationship between the VoIP provider and the PSAP then populating the whitelist is fairly simple. For SIP UAs there is no need to maintain a list of PSAPs. Instead SIP UAs are assumed to trust the correct processing of their VoIP provider, i.e., the VoIP provider processes the PSAP callback marking and, if it cannot be verified, the PSAP callback marking is removed. If it is left untouched then the SIP UA should assume that it has been verified successfully by the VoIP provider and it should therefore be obeyed. This seems to presume that UA's in fact have trust with respect to what their voip provider does when in fact that may not be the case. if this facility can be abused and can't be ignored it will become untenable rather quickly.
(Martin Stiemerling; former steering group member) No Objection
(Pete Resnick; former steering group member) No Objection
I share Barry's concerns regarding security. It sounds like that DISCUSSion is moving along. I implore you to take Barry's advice regarding the Introduction. Please shorten it.
(Sean Turner; former steering group member) No Objection
I'm going to support Stephen and Barry here.
(Spencer Dawkins; former steering group member) No Objection
I agree with Barry's Discuss concerns on Security Considerations. I'm not a Discuss because I think the problems Barry identified are more general than the problems ECRIT is chartered to solve. For example, a STIR Secure Telephony Identity would help prevent spoofed use of psap-callback, but is much more broadly applicable than just assisting with PSAP Callbacks. The conversations I've had with carriers make me think penalizing spoofed psap-callbacks by doing anything worse than treating them as ordinary calls is too risky to deploy. But I'd love to be wrong, and I look forward to learning during the discussion.
(Stephen Farrell; former steering group member) (was Discuss) No Objection
Thanks for handling my discuss & comment
(Stewart Bryant; former steering group member) No Objection