[Bug 24905] Emergency call identification

bugzilla-daemon at freedesktop.org bugzilla-daemon at freedesktop.org
Sat Feb 20 00:54:30 CET 2010


http://bugs.freedesktop.org/show_bug.cgi?id=24905





--- Comment #2 from Andres Salomon <dilinger at collabora.co.uk>  2010-02-19 15:54:29 PST ---
(In reply to comment #1)
> Some comments on the Maemo interfaces with a view to generic applicability:
> 
> Connection.Interface.Emergency -- rename to EmergencyContacts for extra
> disambiguation and to reflect the purpose better?
> 

I would suggest something even more generic.  While the Emergency stuff is what
we care about, there are other service URNs that GSM and SIP may use.  I'd
suggest ServiceCall or ServiceAP (ie, Public Service Answering Point).  The
idea being that you're connected to some form of service, which has some
defined categories (see below).


> The type Emergency_Service: Are all fields necessary? Is exposure of URNs
> appropriate with other protocols in Telepathy (which operates with opaque
> "string IDs" elsewhere)? Are the values of the alias list meant to be other
> URNs or human-readable strings? If the latter, is it too much information,
> compared to use of aliases elsewhere in Telepathy?


Agreed on the string ID bit.  The string IDs can be "urn:service:sos", rather
than specifying that it must be a URN.  Giving a service URN as an example in
the spec would probably be a good idea.

I'd also suggest an enum w/ a type (that can be extended in the future) w/ each
stringID.  The first type is pretty obvious: Service_Emergency.  Rfc5031
defines urn:service:counseling* as well, so we could have Service_Counseling
and Service_Other, with the enum being added to in the future as more services
are added.



> 
> The property Channel.Interface.Emergency.InitialEmergencyService should be
> recommended to be made requestable, this being the recommended way to request
> an emergency call. Then one could have a separate connection (and even a
> separate connection manager) for emergency calls, clearly designated as such
> through requestable channel classes and contact capabilities.
> 
> The contacts retrieved from Connection.Interface.Emergency could provide the
> property discussed above in their capabilities.
> 
> Documentation for Channel.Interface.Emergency.EmergencyServiceChanged leaves it
> unclear when the signal is initially emitted as a "tag" signal for emergency
> calls, as the documentation elsewhere suggests. Should it be treated as "the
> moment when it becomes clear that the call is directed to a particular
> emergency service"? Is it a use case relevant for telephony?
> 

Note that this sort of thing has been suggested for other protocols besides
telephony; for example, SMS and IM via
http://iptcomm.org/iptcomm2009papers/1569204635.pdf .

It probably makes sense to add this as a channel interface that doesn't depend
upon StreamedMedia or Call..


-- 
Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.



More information about the telepathy-bugs mailing list